How to use my proprietary framework on a new job without making it open-source? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Software Engineering Stack Exchange.

Closed 5 years ago.

Improve this question

I have been working on a framework for years. It is solid, extensive and tested. It is exactly what the employer needs for the foundation of its new project. There is no point in rewriting the whole thing from scratch or using a competing open-source alternative.

My desire is to give a free, non-exclusive, non-redistributable license to the employer for access to the binaries and sources, so the employer can change the code. I understand that the employer cannot depend on closed-source code so I am willing to give my sources to the employer for free (the equivalent to two years of my work for free). I just want to protect my copyright and prevent the employer from giving the code to someone else. I believe many programmers will find themselves in this situation when starting a new job.

However, making it open-source is out of question for a variety of reasons that do not matter for the purpose of this question. I want to keep the source closed, but provide a free copy under a non-exclusive, non-redistritubable license.

So my questions are:

• When do I bring it up that I have a framework that I would like to use? Probably before I take the job because if they don't want to use it OR don't accept my license I am not taking the job.

• What kind of license should I use to make this deal with my employer?

• Any other considerations or comments?

UPDATES:

1. One thing I can say is that there are other companies using the software (with licenses) so I cannot make it open-source or simply transfer the copyright to my new employer, which is what actually happens if you use it in your job without having this discussion.

Answer 1

As the use of your framework is a condition for you in accepting the job, you really must discuss this before you (even verbally) accept any kind of offer.

As to the licensing question, the fact that you give a 'customer' access to your source code does not imply that you must make your project open-source. It is entirely possible to provide the framework (including source code) to your employer under the same license as you used for the other companies. Unless the license explicitly permits it, they can read the source code, but not modify or re-distribute it.
You can also choose to give your employer a more relaxed license that allows modification, but not re-distribution.

As for other things to consider:

• Would you give them a license if the want your framework, but don't offer an acceptable job for you?
• Have you considered the possibility that you make a nice enhancement on behalf of your employer that you might want to distribute also to your other customers? Doing so without consent from your employer might land you on a legal slippery slope.

Instead of entering into a standard employment contract and bringing your framework along, you might also consider some more unusual constructs. For example, you enter into two contracts. One is an employment contract for the work you will do for your employer, with the difference that any work you do on your framework on request of your employer is excluded from the terms of that contract, but your employer is required to give you the opportunity to perform that work under working hours. The other is a service contract for your framework under which you perform the work excluded from the regular employment contract.
The advantage of such a construct is that it remains clear that you are, and remain, in full control of the framework. In return, your employer gets their requested updates fast (as you don't have to do it in your spare time).

As this all is a rather uncommon situation, I strongly advise you to seek proper legal advise.

Answer 2

As a potential employer, this would set off a lot of red flags for me.

• Proprietary frameworks are typically significantly less used, documented and tested than their competition. More eyes = more bugs found/fixed, more documentation written, etc.
• It shows you oppose standardization in your community. What's wrong with the existing frameworks? You are assuming yours is better. Unless you're hiring for a lead role, this is usually a negative for me.
• You're already causing legal problems for you and the company. I'd only consider this if it was MIT or similar licensing (I can do whatever I want) - anything else is severely limiting in the future. Nobody wants to deal with IP issues, and creating them at hiring-time is a horrible idea. Considerations: what if the company or product changes ownership? What if they try and raise money? If you've already left, there is a potential law suit waiting to happen.
• It suggests you like to hoard knowledge and do things that better you rather than the community or your company. If you leave the team, are they left in a tight spot?

Typically, these types of frameworks are useful for you, but actually detrimental to the technical team working with it -- no matter how good it is.

Answer 3

If you won't take the job if they won't use the framework then you must bring it up before accepting an offer.

If I was the company there is no way I would use your code without a license that allows the company to do pretty much anything it wants to with the code. Restrictions that seem reasonable to you now might cause problems for the company in the future as business needs change.

The BSD or Apache license might be acceptable to the company but it sounds like that might be more free than you would like.

But, in any case, because money is involved (directly or indirectly) I would recommend you get a lawyer involved in the details of the negotiation if it gets that far.