13

Update: Sept, 2 The answers of @mysterycommand and @Hiroto gave some good insight and prompted me to be more clear. I've rephrased my question with explicit details; the intent is the same, hopefully clearer now.

As a freelance software developer I've run into a contract with a "Work For Hire" clause that effectively renders me an employee of my client. I have not signed this contract but it got me thinking:

At what point do you need your employer's permission to contribute to open source code you use on the job? (see scenarios below)

In software development it's common to use open source, permissively licensed software, i.e. ok for commercial reuse. The company you work for is not involved in open source but you choose to use it on the job (an application framework, blog, cms for instance). In the US, it's assumed your employer generally owns the copyright on work done on the job. In the course of doing your job, you write some code that you want to contribute back to the community — outlined are some examples:

  • You find a bug in a some open source code you're using at work and you fix the bug. You've changed a few lines at most, maybe even just a few characters. Do you need your employer's permission to submit a pull request to contribute your change back into the project's public repo?
  • You have a half finished piece of open source code you've started on your own time. During the course of your work on the job, you end up seeing the utility of your code so you choose to use your own previously written code. You end up needing to tweak the code, fix a function, or add a new feature so you can effectively complete your job. Do you need your employer's permission to publish the changes you made to the module you started on your own time but improved in the course of your work for the company?

The above two cases seem very grey to me, so insight would be helpful. Following is an example which seems less grey in terms of getting permission (it seems like an obvious yes) but takes the question to the next logical step:

  • In the course of you work on the job you see the utility in creating a reusable module that will save you time in future projects at work. You write this module and realize that it's a pretty good bit of software and other people (outside your job) may find it useful too and may even help you make it better. When you work for a company that is not active in the open source space, how does one approach conversations about the benefits of open sourcing work made on the job?

Asking this question has made me realize that it's important to be on the same page as your client. As freelancers, we can specifically walk away from projects which don't meet our standards (for instance I'm not sure Work For Hire is going to work for me). Also, it generally seems better to retain the rights to work created on the job in the case you want to contribute back to the open source community. As freelancers, we may need to take a WFH job (fiscally compelled) or have jumped into a contract without understanding ahead of time.

2
  • 3
    I'm pretty sure the best advice is to talk to a lawyer and have them draft up a contract specifically for this. As for which EULA model to stick to, I am not good enough to know the differences between most; hopefully, another user can chime in
    – Canadian Luke
    Commented Sep 2, 2013 at 4:19
  • 1
    If the particular open source licence forces you to publish modifications, and the clause in your contract forbids you to do so, it means that you are not allowed to modify open source licence for the needs of that project... You should make the client aware of that fact. Commented Sep 4, 2013 at 7:52

2 Answers 2

9

Disclaimer: Always read contracts you sign multiple times. Regardless of whether or not a contract is enforceable, be sure you do not agree to anything you disagree with.

Do you need your employer's permission to submit a pull request to contribute your change back into the project's public repo?

Nope. this is a straight up "no", regardless. You are contributing to an open source project. For your employer/client to claim copyright over your contributions to an open-source project would violate absolutely every single FOSS license that has, can, does or will exist (bold statement in some countries, but you should really adhere to this).

If you are employed, pull request in your own time, away from work (as technically your employer can claim copyright and thus your pull request can be denied/invalidated, depending on license)

If you are freelancing, just pull request. Unless you accepted a contract which sold your soul to your client for every waking moment until the date your project is finished, there are no problems with contributing to open-source projects as a freelancer.

Do you need your employer's permission to publish the changes you made to the module you started on your own time but improved in the course of your work for the company?

Something very, very important to note here is that you do not create the code as part of your client's module/program. Create it and license it, and you will own the copyright regardless of outcome. Just don't write it while on the client's premises.

You should also publish it somewhere well in advance, and use it as a library in the client's code. Be sure the license is compatible.

When you work for a company that is not active in the open source space, how do you approach conversations about the benefits of open sourcing work you made on the job?

You should publish code you intend to reuse under a permissive license and then include them as libraries. Any other course of action can (and probably will) result in upset from software consumers who dislike open-source. I recall asking a Marketing Manager at Microsoft UK what his stance on open-source was and he looked at me like I'd just grown another head.

If the company wants "proprietary information" in a program, then they will not make it open sourced, period (with a few exceptions).

However, if they do decide to open source some of the work that you do, you can just agree to be a contributor or agree to be attributed in the contract; this entire negotiating area is quite daunting.

There's a few rules that govern this, but if in doubt, always consult a lawyer or a government legal aide.

If:

  • You are using an open-source framework that:
    • allows commercial use, and
    • doesn't force open-source (read: most licenses with the exception of the GPL), and
    • your client is asking for an application that you will be writing

Then it is entirely reasonable (and even enforced in countries such as the USA) that they own copyright and licensing for that work. They can also enforce an NDA on the code you are writing, but this must be in the contract when you agree to write the software if they wish to enforce it.

2
  • the first paragraph is misleading. claiming ownership over a contribution to a Free Software project is NOT a violation of the license. the license states under what conditions the software may be used, modified and shared, it does not define who is to own the modifications, nor do Free Software licenses require contribution to upstream or sharing with anyone who is not a user, so it is perfectly fine for an employer to claim ownership over a modification. and they may also control how to share the modification.
    – eMBee
    Commented May 16, 2017 at 4:20
  • in work done for hire, the company, and not you, is the licensee, and they decide how to share the modifications. if the modified product is only used in-house then they may prevent any employee from sharing it outside the company
    – eMBee
    Commented May 16, 2017 at 4:20
2

I'm not sure what the question is. Are those 4 things reasonable? Yeah, of course. Also, it sounds a bit like you're being asked to WFH contract to work on an open source (or "to be open sourced at some future date") project, which seems like two very different copyright models. Work on open source code anonymously? No thanks.

I've never run into a WFH clause in a contract, and I would be equally hesitant to sign it. I think a simple "no compete" clause would do the trick here, especially if it's going to be on open source or partially open source code. I worked on some software for a guy a while back who was cool with giving the code away, but wanted me to sign a non-disclosure, non-compete agreement that I wouldn't work with any of his competitors for 3 years or something.

So, yeah, non-disclose/non-compete seems like it would protect your client from what they're worried about, but WFH seems to me like an overwrought way of doing that.

Anyway, yeah, talk to a lawyer.

1
  • 1
    Sorry, I was a little unclear. I meant that I'll be using an open source application framework and under WFH the language is such that hypothetically if during the course of the project I fixed a bug or wrote a useful module (that was generic, and contained no trade secrets) that I'd need to ask my clients permission to contribute it back, since my client is the copyright holder of the work. Just seems like a clunky model for software.
    – Mark Fox
    Commented Sep 2, 2013 at 15:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.