My situation:

  • I have written a framework before I started my new job. I own the copyright.

  • It has a bunch of boilerplate logic inside of it, like any piece of software. (duh!)

  • I don't want to use the whole framework in my new job, but I do need to re-use some parts of it in a similar framework that I am building for my new job.

  • It is impractical to re-implement / re-think all the logic from scratch. It is a lot of logic and logic is logic, you can't make it much different. For example, how many different versions of a HashMap can you code? I bet they will be very similar and the third version can claim that you violated the copyright of the first version. :(

  • It is impractical to try to re-invent the API. Can you re-invent the API of a HashMap? Maybe you can change put(k,v) to add(k,v), but not much more than that.

My idea to protect myself and my previous code:

I will tell my employer that I am building the new framework based on a previous one that I have written under the MIT license. So in the future if I use my previous framework someplace else, or even another derived version of it, that has some pieces of code similar with this new framework I am building now for the employer, they won't be able to say I am using their code, the one I wrote for them.

My questions:

  • I am not distributing my code to anyone. I don't have to distribute my MIT licensed code to anyone, if I own the copyright, correct? I mean, can someone request that I release my code that I now claim it is under MIT license? It would not be the end of the world and I would certainly agree to do that under a legal threat.

  • Does this strategy make any sense? My final goal is to be able to use a derived version of my previous coded framework without losing the copyright to it. At the same time, i do not want to distribute this code as an open-source project to anyone. I have other open-source projects, that I freely distribute, but this one I would like to keep it to myself so I can use on my jobs (not contractor jobs).

It is like claiming that you have a framework under the MIT license, without actually distributing and/or showing to anyone. If it is out there, free and easily available, my employers don't need me anymore. They can just take the code and give it to someone else to use it.


  • I have listed this framework as a previous invention before I started the job.

  • I have not released this code anywhere. It is on my private SVN repo I host in my private server.

My idea in a nutshel:

  • My plan is to keep the previous code to myself, use parts of it in this new framework I am building for the employer and tell the employer it is work derived from a MIT licensed framework I have coded before and have not distributed to anyone". I am not forced to distribute a software I coded under MIT license, am I? If later, some legal claim happens (hopefully not), i can immediately paste the license on all the sources and show/release the code.

5 Answers 5


I used to be an IP lawyer, so have experience with license-ese. I feel like the terms themselves are fairly readable and understandable, but then again, I'm marred by three years of law school and some lawyering time before getting my wits again and returning to hacking. Particularly since I'm not currently an active lawyer, this certainly isn't intended as legal advice in the slightest.

Lets start with the MIT license language itself. Then I'll lay out a few key points to understanding open source licenses, then address your questions and provide any high-level observations.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: (that they leave this notice in it. The end. )

A few key things with most open source licenses (including BSD, MIT, GPL) for copyright owners are:

  1. The license doesn't alter your ownership of the copyright itself. Its a non-exclusive license, not an assignment or forfeiture of ownership. Using an OS license is not "putting something into the public domain", although that is certainly one approach to open source.
  2. Nothing "forces" you, the copyright owner, to make the code public in any way just because you attach a license to it.
  3. But if you use an OS license, you can't prevent anyone who "obtains" your OS-licensed code from making it public in any way, which is explicitly within their rights under all of these licenses.
  4. Copyleft (e.g., GPL) licenses do require obtainers (but not the owners) to make their derived works public and open source. Permissive (MIT, BSD) don't. (this may be a bit of a simplification, but is the essential difference)
  5. There isn't a "takeback" clause to most open-source licenses (e.g., MIT) so once someone has "obtained" your code, they have the right to use it perpetually, under the license terms under which they received it.
  6. You can always distribute future versions of your code under a different license, or keep them completely proprietary. That doesn't stop someone from starting with your previous, open-source version (assuming they "obtained it") and adding on their own new parts and distributing it.
  7. You can remove a channel of "obtaining" for previous versions of your code, e.g., take it off github. However, as mentioned, that does not prevent others from using or distributing any previous versions you had open sourced, in any way.

With that basis, I'll move on to your questions.

I am not distributing my code to anyone. I don't have to distribute my MIT licensed code to anyone, if I own the copyright, correct? I mean, can someone request that I release my code that I now claim it is under MIT license? It would not be the end of the world and I would certainly agree to do that under a legal threat. ... At the same time, i do not want to distribute this code as an open-source project to anyone.

As copyright holder, you don't have to distribute any code to anyone; you wouldn't have to honor such requests (even if it was GPL). You retain all rights. However, in the situation you describe, you would be distributing to your new company and licensing it to them perpetually under an OS license. Your employer (more likely ex-employer) could paste your code to the internet, and you wouldn't be able to do a thing about it besides grumble.

I assume you mean "anyone besides my employer". If you don't want to give it to your employer "as open-source" and give them all the rights that are included in that license, including redistribution and perpetual use in whatever way they want, then you shouldn't be using an open source license. You should just licensing it directly to them under the terms you want. Bullet point out what you want, and have a lawyer bill you an hour or two to put them into a paragraph form. Or write it yourself. Licenses are just contracts which are just agreements put into words.

My final goal is to be able to use a derived version of my previous coded framework without losing the copyright to it.

You can't lose the copyright unless you assign it to someone, license it exclusively (including excluding yourself) or forfeit it. Open source license are none of these. You'll always be able to use derived versions you create, and can even license the derivations differently or retain all rights.

But, a primary, legitimate concern of yours seems to be that you continue to be able to retain copyright and use your code in the future without the employer claiming the code as theirs or that you're outside your rights to do so. The keys to this is to create an irrefutable evidence that A) you retain copyright to your previous work and are providing it to them under X license terms (MIT works, if you're ok with the open-source aspect of it described above.) B) they agree to these terms, and C) what, exactly the previous work was.

For (A) and (B) you can get them to sign or agree in writing to something that references or includes the license and that they understand that you're bringing the code to the table under those terms. As to (C) I'm not sure what the standard way of doing this would be, but be logical. If its not terribly massive you could just print the code out and include it in the addendum in copies of the agreement that both you and your employer sign. Keep your copy, with their signature on it. If it is too big to practically print, it seems like an md5 hash would come in useful here. Maybe you could refer to it as something like "the zip file named X in the private github repository /, (or ftp site, etc.), which has a md5 hash of XXXXXX... and was emailed to Y company reprentative on Z date". Then you can email it to your manager or their lawyer or whoever from your personal email account and even if they delete their copy you still keep yours and they can't argue that you predicted the future md5 hash of code that isn't written yet. That would theoretically prevent them from claiming anything else down the road.

  • That's awesome, Ben. Thanks for your help. I am already employed, so I wonder if an email to my manager stating the situation and the terms of the license from me to them would suffice. Then I would include the license (Copyright (c) MY NAME - License granted to COMPANY blah, blah, blah) on each source code I am bringing in. What do you think? Mar 2, 2013 at 17:33
  • Emails can certainly be evidence of an understanding or an agreement, e.g. a contract. If you propose bringing the code to the table under certain terms and a person with authority in the company agrees to it, that seems like it would create a contract well enough. I think your idea about the (C)/license terms in each file are a good one as well. The question is whether you will retain (C) to improvements to the files or not. If not, you'll may want to make a record of the original versions of the files which you do retain sole (C) to, e.g. with a zip file & md5 hash sent to your manager.
    – B Robster
    Mar 2, 2013 at 17:41
  • Awesome answer, thank you. Very well detailed and formulated.
    – haylem
    Sep 4, 2013 at 18:24

(I am not a lawyer.)

I see a few potential problems with this:

  • If worst comes to worst, you'll have to prove that you wrote this code before you started working there, and that when you used it in your project at work, your employer was aware that it was under your copyright and under the MIT license. As the primary goal of this is retaining your copyright, not setting redistribution terms, a written contract with your employer about the use of your previously written code seems a better idea.

  • You say you want to protect your copyright and the ability to build "even another derived version of it". Now it's likely that while at your current job, you'll have a few great ideas and implement them. It seems to me that this would get hairy when you leave your job and then 're-implement' those ideas to build another version of your library - since you can't do whatever you want with the code you wrote at your job (and to some extent, the ideas behind it).

  • 1) I plan to do this with a license file together with the company's code, stating that it is based on derived work with MIT license. To prove it was written before I plan to count with my previous invention form declaration. 2) Ideas are not copyrighted I believe, unless there is a patent. Code is copyrighted. The challenge is how to re-type / re-implement / re-use the idea without breaking the copyright from the original code that implemented. Mar 2, 2013 at 13:55
  • 2
    Its true that ideas are not copyrighted but can be considered "trade-secrets" or "know-how" or (if patentable) "patentable ideas" or other type of "intellectual property" which you have likely agreed that the company owns. Its kind of a messy area.
    – B Robster
    Mar 2, 2013 at 17:46

I am not a lawyer, but this would be my solution:

  1. Release the code under the GNU GPL v3 license in a public repository, where all are able to see.

  2. The GPL license does not allow other people to take your code and put it into their proprietary commercial software and close the code.

  3. If the code was 100% created by you and does not contain work from others or derived work, then the GPL allows you to license your code under another license as well, in which case you are allowed to use it in your jobs for proprietary commercial code. However, you must make your employer a licensee of this alternative proprietary license.

  4. This solution would prove that you wrote your code BEFORE you took the job.

  5. You can advertise that your code is available under a proprietary license for sale (for money) and then interested parties can contact you to purchase it.

  • I would not want to do 1 or to release the code in a public repository. I understand it is the easiest way to prove the code was written before. I think software professionals are missing this kind of license, one that allows them to use their code for a job without making it open source and without losing it. If you re-do everything, codes will be similar, there is no escape from that. And a clean room design is impractical for an employee. Mar 2, 2013 at 14:40
  • But your solution does allow your employer to publish your source code in a public repository. I think using an open-source license when you don't want it to be open source is unwise.
    – markijbema
    Mar 3, 2013 at 11:39

Is there a specific reason you cannot ask your employer whether it is possible that you retain copyright on general code you write for your framework (which in turn gives them some free code right now), and give them an you-can-do-everything-you-want-with-it (agreed, this is quite like MIT).

However, if you license your current code MIT, there is no reason why your employer should open source their modified version (modified by you), so I'd say it does not solve much. Even LGPL would not solve this, as long as the code isn't 'distributed'.

All in all your deal doesn't sound unreasonable: you have some framework code, and you're willing to donate them to the company, as long as you can hold on to the code, and reuse it for other projects later, so why not ask?

  • Yeah! That's always the best approach I must agree. Just be courageous and ask. If they think you are weird for asking that, then start looking for another job. As simple as that. Life is all about honesty and risks. :) Mar 3, 2013 at 17:47

IANAL, ask a real lawyer, etc.

First of all, I think you believe that when you have copyright, you can only license the product to yourself under the same terms you license it to everybody else. This is wrong: you can license it to yourself in any license suitable, and license it to somebody else under a different license.

Which means you can create a special license for the company that is about to hire you, and make the software available to them as a separate agreement. Of course, this should be done by a real lawyer.

Have your company sign the separate license, which explicitly states that you have copyright and you are giving certain rights to them, not the copyright.

As to the secondary issue, there are other ways to prove prior date, besides open-sourcing the project. For example, you could host on a publicly available server a file, that says that you indeed wrote this software, at the date specified, containing for example a few different hashes of the current version, or even the encrypted version of the project.

This means that if you're under a legal threat, you can prove prior date of usage to the judge, yet you reveal virtually nothing about the project, besides that you're the author and the date you revealed it. You should consult a lawyer about the possible validity of such an argument, but I believe it would be accepted at most courts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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