Is it ok to use my open-source projects as dependencies at work?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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?).

Answer 7

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.

Answer 8

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.