Your requirements restrict the use of the software, so at least by the definition of open source from the OSI (definition of open source), it is therefore not open source, so you will find no help in open source licenses. So forget AGPL, GPL, BSD, Apache, MIT, etc.
I also looked at the Aladdin license as suggested by @thiton. This does not restrict commercial use, only sale (just as @thiton pointed out). If that is not strong enough, you may want to start with the wording from, say, MIT license and add you restrictions (but don't call it the MIT license of course, and don't call it open source).
Like crypto, licensing is hard, and rolling your own is tricky. The world doesn't like more licenses (they add friction), and is part of why OSI exists - to catalog and promote existing "good" licenses for open source so people don't roll their own. Hope it works out.
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:
- 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.
- Nothing "forces" you, the copyright owner, to make the code public in any way just because you attach a license to it.
- 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.
- 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)
- 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.
- 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.
- 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.
Best Answer
#include <ianal.h>Document style licenses are often a poor fit for source code. Of these, the ones that are a gift (and that is a word with legal implications) are the most problematic.
Public domain, as seen in the US, is a gift. In particular, a gift may be revoked for any reason. This makes something that is in the public domain possibly treacherous for open source - when the gift is revoked, it suddenly has back its full copyright protections.
There are also countries that don't recognize public domain at all. According to a creative commons survey countries such as Belgium, Denmark, France, Germany (and the list goes on and on) don't recognize public domain at all, or only recognize it after the copyright has expired. Of the countries that do recognize public domain, many allow the revocation of it if the copyright hasn't expired.
There are anecdotes (I can't find it at the moment) of an open source project that was completely released under public domain that wasn't useable at all in those countries - and so for people there to use and modify the source, they had to get a commercial license (which cost $$$).
So, on to CC0. The key to CC0 is that it has some wording in there to make it a license rather than a gift.
Note the 'permanently' and 'irrevocably' words being used. CC0 cannot be revoked. It also goes on to state that the heirs cannot revoke it either (an issue with public domain).
Background reading: http://www.rosenlaw.com/lj16.htm
As to the core question of if CC0 can be sublicensed? GNU.org lists licenses that are compatible with the GPL on Various Licenses and Comments about Them lists the GPL as a compatible license. They also list public domain as being compatible tough note the issues that I raised in the first part... I'm sure that GNU has good lawyers who will fight if something is revoked or there are issues in those countries (on the other hand, I don't and would be vary wary of accepting public domain donations to an open source project).
All that said, CC0 still strikes me as awkward in that the license is different for different countries recognizing different parts being contrary to local law (I know that Creative Commons has done a great job to the best of their ability in crafting this). There are places where parts of the permissive license for CC0 would have difficulty (France - Right to withdrawal or reconsider I am still not a lawyer, much less one versed in French law written in English).
The thing is, programmers who are going to be caring at all about the license already know how to deal with the MIT, or BSD, or GPL. Other licenses require some legal reading for the project as to if you can include them or not.
I'd also point to http://choosealicense.com/licenses/ - scrolling down to the bottom for the "public domain" one, note that the unlicense allows for sub licensing while CC0 does not.
Give http://www.rosenlaw.com/lj19.htm a read for background (note that this reading of derative works is in conflict with the GPL's understanding - but since we're not talking about the GPL the reading of it is much more common sense).
There are several ways to address the approach. You could put the function in another library and point out that library is a derivative work, licensed under however it was obtained (which is compatible with the rest of the project). The copyright of the rest of the project is not a derivative work (GPL questions of static and dynamic linking aside - they try to make the derivative work extend to as many things as possible).
For example, if code snippet
foowas from an BSD licensed work, you could stickfooin its own library. That would be a derivative work of an apache product and licensed under BSD license. Then the rest of your code would be MIT licensed (for example) and not a derivative work. And since the BSD and MIT licenses are compatible, thats the end of the story.I just used BSD as an example for your license, but really it could be anything as long as it was compatible with the license I'm using. And while CC0 is compatible with everything - there are other, better understood licenses for software that are similarly nearly universally compatible. The BSD 2 clause or MIT, or Apache 2.0 licenses are ones people understand.
To get the widest use of your code, you should use a license that people know and understand. If you chose something that is less well understood programmers may be less likely to use it because of the possible legal implications that they'd have to ask a lawyer about. If you have to check if CC0 is sub licensable or not, you don't use it. If you see a BSD license, you know what you can do with it.
You could always go with WTFPL.
I am still not a lawyer.