38

I work at a startup company and we're in the phase of creating some pipelines (GitHub actions) and making our program's foundations stronger.

In my spare time, I create a lot of tools for my personal open-source development flow. So for some missions and pipelines, I installed my personal open-source projects as dependencies and used them since they fit our needs perfectly.

Important to note: company and open source domain are not the same. the company domain is education, while my open-source projects' domain is infra and developers tools. Clearly not the same domain, even though they have commonalities since they are both "software" products.

The question is: is it OK to link my personal projects with my work? will that be received badly by management? Is it better to clone the code (since it's open-source anyway) and create a private fork of these libraries?

What do you think is the best professional/legal thing to do? How should I save my projects and myself legally? I don't need so much advice about security standards and things like that, more about human relations and legal ramifications.

When I got employed by the company, I requested that my open-source activity will be noted in my contract. Will this protect me from legal actions if someone tries to claim projects I created before/after being employed there?

1.2.Scope of Employment. The Employee shall devote his entire business time and attention to the business of the Company and shall not undertake or accept any other paid or unpaid employment or occupation or engage in any other business activity, except with the prior written consent of the Company. Notwithstanding the above, the Company acknowledges that the Employee is involved in the development of certain open source code that is unrelated to the Company's domains and hereby consents to the Employee's involvement in such activities and agrees that such activities will not be deemed a violation of this Section 1.2. Additionally, and without derogating from the aforesaid, it is hereby agreed that the Employee may continue to engage in musical performances both for pay and not for pay, provided that such engagements shall not conflict with Employee's undertakings and obligations towards the Company and shall not derogate from Employee's undertakings under Schedule C hereto. The execution of this Agreement shall be deemed prior written consent for the purposes of this Section 1.2.

3
  • @JoeStrazzere It's unrelated business-wise. Both my open-source projects and the company are in the "software industry". But most of my open-source tools deal with infra tools and developer tools. Nothing related to the company's business domain, but since we're working on Implementing our infrastructure and adding developer tools, that's why I say we can use it, but it's not competing with the company directly. Nov 26 '21 at 18:53
  • 2
    @DWGKNZ thank you. Not sure if that will save me, but I heard of too many people getting hurt at some point or another (sometimes 10 years later). I don't want to get into that situation, and also want the company to know I have a personal life so they won't ask me to work in the evening as much. So I ask to mention my open-source projects and saxophone performances in any contract so it will be clear from the start as much as possible Nov 26 '21 at 18:59
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Lilienthal
    Jan 4 at 21:14
122

The professional thing to do is incredibly simple: talk to your manager. Explain the situation, ask what you should do. The important thing here is to avoid any future problems, and you do that by ensuring everybody who needs to know what is going on knows what's going on.

4
  • 4
    The added bonus of this is that it puts the ball in the company's court. Once they are aware that you have a solution available the onus will fall on them to decide whether they should use it and what the risks and liabilities that need to be mitigated are.
    – DWGKNZ
    Nov 26 '21 at 18:15
  • 22
    To add to this: Don't bring your off-the-clock work into work until you have gotten an answer from management, and until the answer is in writing, you do not have an answer.
    – EvilSnack
    Nov 28 '21 at 17:59
  • 1
    When you ask that question, you want to be very clear how your work is licensed. In particular if the work is licensed under the GPL or other license that carries similar restrictions, you need to be very clear what those are.
    – Flydog57
    Nov 29 '21 at 5:18
  • 2
    Assuming you own the copyrights, and so can set licenses, you could offer to give the company a perpetual, non exclusive license of their own for the software (you'll need this drafting by a lawyer, but it's quite easy). You can go on to give it to the world on any license you like, but the company gets a "do what you want" type license. Nov 29 '21 at 13:46
35

Tread very, very carefully. Get everything in writing and signed. Your contributions will have an impact on the licensing - between you and the company for sure, and between the company and end users as well (it really depends on the terms. If you licensed you work as, say, GPL3, company may be required to in turn open-source anything that's linked to (or integrated with) your contributed components.

Even when all of the software that the business owns, is itself open source (right now, things often change quickly in startups) that does not mean you're automatically in safe legal waters.

Anectotally, I have been sued (successfully, twice) by a company who bought the first company, to whom I sublicenced open source contributions I made. The seller did not tell the buyer, and they litigated against me, after the fact, privately. They were arguing that they'd bought a closed source product with no rights reserved by third parties whatsoever. I courteoulsy hinted them to my open source repositories and told them their assumption was wrong, they went to court and had me take my open source repository down and pay hefty fines. Not something you want, be careful.

14
  • 18
    @jcm I suspect there are a lot of details missing here. Nov 27 '21 at 2:23
  • 12
    @zibadawatimmy I'm sure! I'd love to hear them.
    – jcm
    Nov 27 '21 at 2:41
  • 7
    Of course there is lots more to that story. Company B sued out a court order preventing me to talk about any details (they must be fully aware that what they did may be, well, borderline criminal). Anyway the DCMA is public.
    – dlatikay
    Nov 27 '21 at 17:19
  • 11
    What I'd like for OP to take away from this, is that they should draw a clear line between them being (1) a private contributor to some open source and (2) contributing software to the codebase of their employer, which is their employer's. I have obviously not been able to contractually stipulate and later prove that my personal contributions to C were not my employer's at the same time, and that came back to bite me.
    – dlatikay
    Nov 27 '21 at 17:21
  • 9
    @dlatikay Ho-lee-fuk. If it is really "an open source project was used by a company, a company was bought by another company, another company sued and enforced a takedown", then EFF, GNU, and Co. would be extremely thrilled to hear about it. Nov 28 '21 at 0:44
18

Dont do it. It just opens up problems. What if your boss wants you to fix something in the tool, do you do it on company time, or private time? If on company, now the company might have rights to the code, if privately then you also work in your free time for the company.

Clean solution is, you make the same tool again for the company during company time (with different code of course). Anything else is a mess.

3
  • 9
    It depends on the company's culture. Take the developer of CUPS, he was hired by Apple just to do what he did as a hobby: improving CUPS. It did not turn out to be bad for CUPS, the developer, or Apple. Apple became the biggest contributor to CUPS.
    – usr1234567
    Nov 27 '21 at 18:39
  • 1
    @usr1234567 thanks for mentioning this, I think this is a very different situation, and great Apple did that.
    – lalala
    Nov 27 '21 at 18:40
  • 1
    Upvote this 10 times if I could. Clean solution. Do company work on company time, owned by the company. Even if it is 'inspired' by research done in your own time.
    – Neil_UK
    Nov 28 '21 at 12:15
12

Before talking to anyone, check your employee handbook and your contract, check for how rights to software created during employment office hours and off hours are treated.

Even though you're doing it on your own time, your employment makes it less clear because you're accessing the company's resources and knowledge.

Depending on what is written, you may need a lawyer to clarify liability and whether you should just remove those dependencies. A good employer will try to work something out. A bad one will try to claim your code is theirs.

Update: You need to remove the dependencies due to this statement in your contract

involved in the development of certain open source code that is unrelated to the Company's domains

This is clearly related domain when you use the actual projects at work. You must either remove those dependencies, or expect to have your work owned by your company.

Even if you "write your own version" for the company, your work will be similar enough to cause significant problems. It takes tremendous skill to write code that does the same thing but are not close enough to violate copyright. Even if you are successful, that distinction is not objectively provable and your employer can probably sue you for rights to the code.

Even then, they can still sue you and claim that the exposure to their product gave you trade-secret and critical information to allow you to write your code, then you'll argue how you have already started the project before joining the company, but they can counter that you did not reveal that at the initial signing of the contract and have violated the "unrelated domain" clause... and then you'll probably be bankrupt with nothing to show for it. Stuff like this is really messy once you use the code in the company.

Your time with the lawyer may need to cover the topic of conflict of interest, and you may need to put a significant time-gap between your employment and your personal projects to lower the risk. Typically it would be around 6 months to 2 years of separation to achieve some type of "good faith" separation.

5
  • Yeah, that's part of what I'm afraid of. I added a snippet about open-source from my contract to the question. Do you think this might help? Does it at least give some legal ease regarding your answer? Thanks! Nov 26 '21 at 9:51
  • 40
    @Thatkookooguy It's going to be incredibly hard for you to claim that your open source work is "unrelated to the Company's domains" when you're proposing to use it directly in your company's work. Talk to a lawyer. Nov 26 '21 at 10:13
  • I already listed in several places that the domains are unrelated. The open-source code handle mostly infra tools while the company is in the education industry. Please don't jump to conclusions and change a perfectly good answer based on that :-) Nov 29 '21 at 5:15
  • @Thatkookooguy It sounds like you have something you want to hear and aren't going to listen to anything else, but the notion of "different domains" seems like a flimsy fiction if the code is useful enough to include.
    – Casey
    Dec 4 '21 at 8:12
  • @Casey just looking for advice that includes all the details. if the answerer included those details, all good. but it wasn't clear from this answer that they did see the details about the scope. Dec 4 '21 at 9:47
2

A conflict of interest does exist as a significant issue in the described situation. And I believe OP is aware of this issue based on the following statement.

Is it better to clone the code (since it's open-source anyway) and create a private fork of these libraries?

Cloning the dependency demonstrates integrity in mitigation of the OP potentially leaving the company and deleting the open source dependency for whatever reason.

So, yes clone it. Though, it should be clear what changes you contribute to the dependency during working hours. If your usage of the dependency at work demands changes to the dependency during working hours, then implement those specific changes in the clone and create a PR for the origin.

1

Have a look at the public documentation offered by some big companies, for example:

https://opensource.google/docs/using/

Based upon this:

Is it better to clone the code (since it's open-source anyway) and create a private fork of these libraries?

Here technical concerns and legal concerns overlap:

  1. how do you ensure that the open source libraries you're using are reliable (don't get compromised by future you, another contributor, etc.)
  2. how do you ensure that you don't negatively impact the development process inside the company?
  3. how do you ensure legal compliance (the company respects the licenses of open source libraries that it'll use)

For 1. you want at the very least to pin the specific version of your dependencies (See Nix flake lock, Yarn lockfiles, etc.).

The solution for point 1. doesn't provide a guarantee that the dependency that you're relying on will be available (point 2. ): think of unpublishing npm packages or an npm outage, github outage, maven central outage, etc...

The solution in that case, depends on the company:

  • A small startup might not care: they'll want to churn their code quickly, and eat any productivity loss due to the dependencies not being available
  • A shop which uses a single language ecosystem (or few of them) might want to setup a pypi mirror, maven mirror, etc.
  • Other companies might not simply mirror the same packages as published upstream, but they'll rather "vendor" the code in internal repositories (similar to what you described as private fork)

For point 3. some tools like Nix have configuration options to list the licenses (allowlistedLicenses) that are allowed by your company's policy, without having to vendor them. A more generic approach instead is to just vendor all your dependencies... checking that the license is allowed will be thus performed as part of your normal code review process.

Vendoring dependencies can also help for point 2.: If the library has a bug, you might work to fix it as part of your job... but every different library might have a different development process (build tools, etc.) than the one that you use internally. Developing the patch internally allows you to use the tools that your dev team is hopefully most familiar with. But just because it had been developed internally, it doesn't mean that you cannot then contribute these patches back upstream. (it doesn't have to be a hard fork)

Obviously, mirroring or vendoring has downsides: A reason for npm packages version being unpublished, for example could be if it contains an hidden backdoor (see dependency confusion) or an actively exploited vulnerability. It's harder for you to introduce these security issues if you review every update to these dependencies, but you'll then also have additional responsibilities (google's policy as an example) to keep track of these changes and maintain them.

Since you wrote:

we're in the phase of creating some pipelines (GitHub actions) and making our program's foundations stronger

I think your company is probably starting to establish policies for how to handle open source dependencies, how to contribute to them and which licenses are allowed just now.

That means that if you're involved in the process, you'll probably be able to influence the decision, or at the very least will have to solicit clarifications for what hasn't been documented in written form, yet.

So...

is it OK to link my personal projects with my work?

Yes, but how to do it depends on your company

will that be received badly by management?

Ask them.


As pointed out by other answers, you should also be mindful of the copyright. If you haven't assigned copyright for your existing projects to the company, the projects will remain yours. But (if the company asserts ownership of everything you produce while employed), if you patch the project that also means that you and the company will share ownership afterwards. That's probably not a big deal in most cases, but it would be quite hard to disentangle.

I'd also like to echo lalala's answer about not accidentally working in your free time for the company. That's something that you might accidentally end up doing. I disagree with the rest of their answer, if you found that your existing open source libraries

fit our needs perfectly

as you stated, I think that it's unprofessional not to use it. But again, a private fork is also an acceptable solution in most cases, ask yourself what will you like least after you'll have left the company:

  • your open source project losing access to the patches that you contributed while employed
  • you sharing ownership of the open source project with the company you left

That should help you make the decision.

I am not a lawyer, and so I commented just on the first part of the question (is it OK to link my personal projects with my work?, What do you think is the best professional/legal thing to do?).

1
  • Hey! Your answer talks about code standards and security compliance, but the question only regarded the situation from a human interaction standpoint. Also, the answer feels more like a mishmash of answers (quoting other people's answers) and also it feels like it missed the point of the question a bit. The question is more about the legal advice than anything. Mostly advice on how to protect myself and my projects Nov 29 '21 at 4:48
1

Regarding whether you should use your library:

Ask the question: If it were someone else's open source library, would you use it in your work project? E.g. Is the license compatible? If you can confidently say, that you would include some stranger's library as dependency, then it must certainly be okay for your own library.

Regarding the company taking possession of your library:

You should document the fact that your library pre-dates its usage in your work project, and you should clarify, that no company work time has or will be used for developing this library.

The very best advice came from @Philipp Kendall's answer: Talk to your manager. This, especially when also put in writing, can serve as a very good basis for the mentioned documentation: If your manager knows that this is/was/will be your privately developed library, it would be very hard for the company to have any claim on it.

0

I would imagine that the answer to your question would depend…. Some determining I can think of, offhand, that you’ll likely want to consider in answering this question:

  • Interoperability

  • Compliance with any standards / expectations used within your team / organization

  • Security: Make sure that it’s easily testable by any scanning tools and/or processes that your team / company would use, and that use of that dependency would adhere to the standards your team / organization uses.

1
  • 2
    Hey Zoe, this is not really a question on how to make the open source project attractive for use by the company. I already follow the rules you suggested. Mostly need legal\people advice than software advice Nov 28 '21 at 6:53

You must log in to answer this question.

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