I don't just do software engineering as a career - I do it as a hobby as well. I now have several small open source projects, mostly released under permissive licenses.

Occasionally at work I've had projects that seem quite good fits for these libraries. But I've always been wary of any intellectual property issues or conflicts of interest.

For instance, let's say there's an edge case bug in library X that prevents me completing work project Y. Should I write the bugfix at work, or at home? If at work, do I reserve IP rights? If at home, what if I'm not paid for my overtime?

Similarly, what if my employer's interests conflict with my users' more generally? A hypothetical example would be a backdoor in a library that needs to be highly secure. Another might be a rewrite that is functionally superior but has a stricter license (e.g. GPL). We could fork the code at this point, but my employer might be dismayed to now be maintaining their own branch of the library

My instinct is that it's safer just not to bother, but this does seem a terrible shame. It also seems a dereliction of duty when building an in-house library is expensive. Is it possible to safely negotiate these issues?

  • "(which obviates the point of using third party code)" That is not obviously true. There are advantages to maintaining a fork of a third party library over not using it at all: most clearly you get a head start on writing a bunch of code. In any case your hypothetical strictly licensed rewrite (or more commonly just maintainers abandoning the project) is something that could happen to any open source code, and is actually less likely when a significant maintainer is employed by the company.
    – Josiah
    Aug 25, 2019 at 19:53
  • 1
    It's a PITA because you have to get employers sign off on carefully tailored exceptions to the language where you sign over to them the IP of your work. And then you may still have to periodically defend it if your employer "forgets to mention" to their customers that they are delivering a product built on code which they do not control copyright to, which can make for a very uncomfortable situation. I once discovered contract betw my employer and customer in which they "affirmed" no open-source code was present, which was false. Had to withdraw functionality from the product, project died
    – Pete W
    Apr 5, 2021 at 15:38

2 Answers 2


The main danger is self-dealing, representing two different parties in a single transaction. You will inevitably be representing your own interests as an independent software developer. You need to ensure your employer, as a potential user of your software, is represented by someone else.

I suggest beginning by discussing the matter with your manager. If they are interested in using your code, licensing and any maintenance agreement need to be negotiated between you and your employer, represented by someone other than you and with management approval for the agreement.

  • 2
    "need to be negotiated" seems like the take home to me. You have something of value to offer. See what terms they are willing to take.
    – Josiah
    Aug 25, 2019 at 19:55
  • What items would you say might (typically) be on the agenda for that negotiation? What kinds of pitfalls and loopholes should both parties seek to close? Aug 25, 2019 at 20:36
  • @JimmyBreck-McKye Obviously, the basic license terms. Beyond that, look at your own question. By the end of the negotiation, you should know the rules for all the issues you mention. They should either by covered by the license, by your employer's normal policies, or by explicit agreement. Aug 25, 2019 at 21:26

You would need to check the terms of your contract, but it is likely that anything you create at work, or using your employer's equipment, belongs to them.

This could lead to a legal minefield if you start producing bug-fixes as a result of work you have done on company time. Your employer could claim ownership of the bug-fix, meaning that you could not apply it to your open source code. So bugs would be left not fixed in the open-source version.

  • I don't think that's a risk, depending on the license. A bug fix cannot be copyrighted, although the exact patch can be. But that's what a license is for.
    – forest
    Aug 27, 2019 at 6:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .