May I recommend replacing The Unlicense with CC0? (<a href="https://creativecommons.org/publicdomain/zero/1.0/legalcode" rel="nofollow">https://creativecommons.org/publicdomain/zero/1.0/legalcode</a>). It has all the same bullet points except is a bit tighter in countries where a public domain release is not legally valid.<p>Unfortunately it is more difficult to release works into the public domain than The Unlicense addresses. The Unlicense is likely sufficient for all foreseen cases in countries except Germany and France (to my knowledge), but CC0 is written beautifully with a double-fallback to completely waiver all rights in all jurisdictions.<p>Here are some analyses:<p>- <a href="https://creativecommons.org/2011/04/15/using-cc0-for-public-domain-software/" rel="nofollow">https://creativecommons.org/2011/04/15/using-cc0-for-public-...</a> Why this is okay to use for software.<p>- <a href="https://rd-alliance.org/sites/default/files/cc0-analysis-kreuzer.pdf" rel="nofollow">https://rd-alliance.org/sites/default/files/cc0-analysis-kre...</a> concludes that it is sufficient in German law.<p>- <a href="https://www.gnu.org/licenses/license-list.html#PublicDomain" rel="nofollow">https://www.gnu.org/licenses/license-list.html#PublicDomain</a> It is recommended by the FSF as a prefered method for releasing source code into the public domain.
Some of these licenses are like kryptonite for enterprises. For example, I once wrote an ip address manager in python and licensed it AGPLv3. Two companies reached out to me through Github not to talk about features or bugs, but to demand I change the license to BSD. after a dozen or so random bug reports insisting I had no right to use AGPL, AGPL was not a real license, and even a handful of Outlook meeting invites copied and pasted to me for a face-to-face negotiation of new licensing terms, I eventually deleted the repo.
There's a disturbing trend that's similar to Microsoft's Shared Source [1] initiative from last decade, used by GitLab Enterprise [2] and Greensock [3]. The code is available for anyone to download, but is not under an Open Source license. They have the option of accusing their competitors of looking at their source code.<p>[1] <a href="https://en.wikipedia.org/wiki/Shared_source" rel="nofollow">https://en.wikipedia.org/wiki/Shared_source</a><p>[2] <a href="https://gitlab.com/gitlab-org/gitlab-ee/" rel="nofollow">https://gitlab.com/gitlab-org/gitlab-ee/</a><p>[3] <a href="https://github.com/greensock/GreenSock-JS" rel="nofollow">https://github.com/greensock/GreenSock-JS</a>
This is the same one built into GitHub's onboarding flow. It greatly aids understanding by laypeople, and goes a long way towards bridging the awkward divide between making one's labor permissively available, and navigating the very specialized field of intellectual property rights.<p>I do wish the drilldown for placing software into the public domain would suggest CC0 over the Unlicense. CC0 is more precise, is backed by both a foundation and large organizations, and pre-dates it by several years.
Good comments on each license, but misses a major point about sharing and community.<p>Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate. A larger code base that contains a GPL component must also be GPL. This is a nonstarter for most business users.<p>If you want to encourage a variety of developers to adopt, modify, and share changes, you are much better off with a permissive license such as MIT or Apache.<p>Paradoxically, the fact that you aren't forcing developers to share changes to the code encourages more use and makes it more likely you'll get a community contributing to the project.<p>Good examples of open source projects with diverse developer communities and permissive licenses include Hadoop, Apache webserver, Tomcat, NPM, Kubernates, TensorFlow and many more.<p>If you want to keep tight control over the code base and dictate all future changes, choose GPL. This was the choice for the JDK, MySQL, and many other projects controlled by corporate entities with little outside contribution.<p>(Yes, Gnu/Linux is a major exception as a GPL licensed ecosystem with diverse contributor base. But it's the exception rather than the rule).
Why not turn this around and default to GPL as "nice and simple"? The introduce the "I don't care about sharing improvements" option for BSD style licenses?
I used this page for years as a recommendation to people asking about licensing. It explains in simple checks many details and is very helpful.<p>However, I think especially license interpretation (like how to integrate GPL the right way or how to apply license summaries the right way or copyright statements in source headers) do deserve a far more extensive page.
MIT/X11 come from a kindler, gentler era, and so lack a patent release, which is a huge flaw nowadays. Is there <i>any</i> legitimate reason one would select MIT/X11 over Apache?
Needs more peer production license.<p><a href="http://wiki.p2pfoundation.net/Peer_Production_License" rel="nofollow">http://wiki.p2pfoundation.net/Peer_Production_License</a><p>c. You may exercise the rights granted in Section 3 for commercial purposes only if:<p><pre><code> i. You are a worker-owned business or worker-owned collective; and
ii. all financial gain, surplus, profits and benefits produced by the business or collective are distributed among the worker-owners</code></pre>
I would love to see a filter here, so I can pick and choose the attributes of a license that are important to me, and see which ones from the full list might be a good fit.
I prefer copyfree licenses<p><a href="http://copyfree.org/" rel="nofollow">http://copyfree.org/</a><p>and usually release stuff under the Copyfree Open Innovation License (COIL)<p><a href="http://coil.apotheon.org/" rel="nofollow">http://coil.apotheon.org/</a>
As an alternative, please see the Free Software Foundation’s license recommendations guide:<p><a href="https://www.gnu.org/licenses/license-recommendations" rel="nofollow">https://www.gnu.org/licenses/license-recommendations</a>