At my current job, I work on applications of machine learning to our data. Sometimes the existing machine learning libraries don't have abilities we need, and often in this cases, the best way to solve the problem is to add modifications to the library itself. However, it is not feasible to maintain private forks because the libraries we use change very fast and to keep them updated it would also be necessary to maintain the fork, which is something that would require additional resources.<p>So, the best approach for this kind of problems is to create pull requests to the libraries and get them pulled into upstream, so that they can maintain the code and we can use the code maintained by them and have all features we need without private forks.<p>I would like to just implement the required changes and create PRs when necessary, then use the upstream libraries in my work. However, my agreement (expectably) says that all the code that I create at work belongs to the employer, so right now I'm trying to create PRs on weekends to not get into troubles. My boss agrees that it is a problem and said that we can modify my agreement.<p>Although I understand that I need a lawyer the country where the company is registered to do actual modification of the agreement in a lawful way, I'm curious how is this kind of problems is solved in other companies and what keywords can be used to get more information about this.<p>I find GitHub's Balanced Employee Intellectual Property Agreement [1] somewhat close to what I want, but I find it to be not exactly clear that it would allow me to commit to open source projects that I use at work because in my understanding each feature that I might add to an open source project and then use in the company's code base can be counted as "(ii) developed for use by the Company".<p>[1] https://github.com/github/balanced-employee-ip-agreement/blob/master/Balanced_Employee_IP_Agreement.md
Most places I've worked, in the situations you're describing where you are doing bread-and-butter contributions to an open source project, submitting the PR back and contributing it was encouraged. Exceptions if we had a private fork with actual proprietary stuff or it was super-specific to our environment (but in that case, you probably did it wrong anyway).<p>For cases where we develop something internally and want to open source it, it differs a lot between places. Some won't hear of it, some think it's great, and everywhere in between. Anything to the left of "won't hear of it" it usually boils down to "prove to me it doesn't contain any proprietary business processes that would directly benefit our competitors" and it's fine.<p>Any of the more responsible shops is likely going to be pretty encouraging of actually committing back to open source projects, since that's what you're supposed to be doing in cases like this, and they'll realize that's how you ended up being able to run most of your business off of open source in the first place.
The fact your employer owns your work isn't a problem as such: you can submit a patch and it can be copyright by your company. So it's not about the fact you don't own copyright, it's about whether your company is willing to donate its copyrighted code (your patch) to these projects.