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.
I find the Zero Clause BSD [0] the simplest for the purpose.
Here it is in its entirety:
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Yes, they selected the relevant license for pretty much all reasonable desired uses except for this one. I really appreciate that they list just MIT, Apache 2.0, and GPLv3 on the front page.
The Unlicense sometimes causes issues with software being accepted into larger collections. CC0 is much more thoroughly drafted, and more widely accepted.
I find it so strange that this is a problem... like the top legal minds of Germany can't figure out how to interpret the concept of public domain from another jurisdiction in a way that's consistent with German law? They can't just make a ruling that says, "OK, everyone consider public domain from other jurisdictions to be the most permissive possible license under German law" and be done with it?
If I understand correctly, the issue is moral rights (https://en.wikipedia.org/wiki/Moral_rights). In some jurisdictions, including Germany, these rights cannot be waived.
For example, in such a jurisdiction, if I release a piece of code under a public domain equivalent license, you would have to give me credit as the author even if the license explicitly says you don't have to: the right to be identified as the author is a moral right that I cannot waive, legally.
Under Australian law public domain exists but only after the full copyright term expires. There's no legal mechanism for an author to relinquish their copyright over their works and dedicate it directly to the public domain.
Germany and France are not necessarily the cause of something like CC0, because even if all countries honored public domain as an alternative to copyright law, it's a concept that lives in a different legal dimension. Declaring that a work is in the public domain doesn't remove copyright---it assigns a different legal code to your work. Using CC0 does remove copyright, through its fantastic double-fallback causes (2) and (3), so only one legal system needs to be assumed for CC0 to work: copyright (which conveniently most countries follow since the Berne Convention.)
I wrote the first bulleted link, should have included a gigantic caveat: CC0-1.0 expressly excludes any patent grant. That makes it dangerous for non-trivial software, is why CC eventually withdrew it from consideration for OSI approval, and why it isn't highlighted on choosealicense.com which is primarily about software -- though it is mentioned on https://choosealicense.com/non-software/
I think the reason choosealicense.com originally featured Unlicense relative to other unconditional license options is that one of the creators of the Unlicense (bhuga) was also one of the creators of choosealicense.com. But previous paragraph is why it's still there.
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.
Sounds like the license did its job quite nicely. If those companies cared enough to negotiate new license terms, they could pay you for such a license.
It's not only companies who ask for license changes, Google and other employees ask licences to be changes too simply because the corporation they work for forbids even looking at the source otherwise. For example: https://github.com/pebble-dev/rebblestore-api/pull/31
That is what the commenter claims, but the link provided for support refers only to submitting patches that cover work Google owns. I found nothing about a prohibition on reading code, not a prohibition on using those licenses for personal projects.
In my view, that’s more an unexpected feature. I can give people freedom to do what they need to do with the software I write, at the same time as I can, in effect, prevent Google from even reading it? Sign me up!
GPL is kryptonite if you want anybody outside a narrow slice of developers to use or care about your work. Unless idealogical purity trumps practicality in your mind, it's a nonstarter.
NPM or Nuget under more restrictive license regimes would never get off the ground.
The hyperbole in this comment is unwarranted. Furthermore, the GPL isn't even developer-focused. It's downstream, end-user focused. There's a reason many of the most prominent free/libre/open programs are GPL: GIMP, Audacity, Linux kernel, so many others…
GPL for developer-focused libraries and tools etc. is where the tension comes in because so many developers want to benefit from the open resources but not pass on the freedoms downstream.
Well, I'm a developer, and I'm looking at this from the perspective of my upstream dependencies. If your cool library to do xyz is GPL, that means my project that wants to use your library needs to be GPL. If it's MIT or Apache or MSPL, party on.
If I, as an upstream developer, license my library in GPL, it is exactly because I don't want any random developer to use my library and don't pass on the same freedom to end users. I intentionally want anyone using my library to be in the same freedom sphere (for lack of a better word).
If you think this as problematic/cancerous then it's a pity. This license was designed to retain freedom of software users.
The Apache Software Foundation doesn't allow LGPL dependencies for one because the LGPL stipulation that it must be possible to replace the LGPL component imposes a requirement which is not present in the ALv2 -- thus the the ALv2 cannot subsume the LGPL and a bundled package including the LGPL dependency cannot be distributed as ALv2.
This is a policy issue, not a legal one. Such a package would still be legal to distribute, but it would not meet the ASF policy that all ASF products be distributed under the ALv2.
Its obviously not that problematic since it is quite common for both large and small game developers to use LGPLv2 and v3 for PC games.
The static vs dynamic aspect of LGPL is rather simple: the FSF has somewhat said that they will enforce C programs in the GNU project that is under LGPL based on the distinction of static vs dynamic. It can also be seen as the promoted "best practice".
The license however do not mention static and dynamic, so like any other copyright license it is up to the copyright author to decide when and how to protect their work. The license text of LGPLv2.1 calls the distinction a "work that uses the Library" vs distributing a "portion or derivative of it". LGPLv3 skips it all together and instead describe instead a "suitable shared library mechanism", which is very open to non-C languages. Basically any package distribution system with dependencies should work for LGPLv3 if the work is independently packaged.
It depend on the industry and how competitive it is. It is relative known that the game industry is rather saturated and delaying a launch for a few months can be extremely costly, so its a rather costly mistake to re-implement a parsing library when there is a free alternative that is compatible with the business model. If its not compatible, it is still cheaper on the average to have a lawyer/developer send a email asking the project authors for an exception. For PC games its not uncommon to see third-party license text that is larger than the credits, occasionally put after the credits or in a file in the install directory.
Not all industries are like that, and places like Google and Apple can afford to put years of developer time on re-implementing stuff for which they don't even know the outcome of. If you are dominant enough then delaying a product by months or years is not a big deal, and as seems common, companies like that has a reputation for throwing money and employees at the problem. I would guess that it is easier, quicker and "cheaper" for a Google project leader to get more people on a team rather than get a custom software license through the approval process.
How would a GPL licensed NPM affect anything? Are you in the habit of including NPM in your software and shipping a closed source version of it to paying customers? Is this a common way of using NPM?
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.
I'd rather this over proprietary software that you simply cannot verify what it does, to be fair. There's nothing inherently wrong with proprietary licensing, IMHO, so being able to be clear about what's in it is nice.
That accusation is possible even with code that's been decompiled, so it's not really any different: A legal claim still requires some sort of proof.
Why do you say this is a trend? GitLab is open source with proprietary extensions and GreenSock is just plain proprietary with readable source. Those models have existed since before the term 'open source' was even coined and there have been countless examples of each over the decades.
For an example of things going the other way, Qt relicensed all their proprietary libraries to LPGLv3 just a few years back.
It's useful to note that the term "open source" does not require an OSI-approved license. It is conventional that the term implies an OSI license, but there are projects that are undeniably open source which are not issued under an OSI license. SQLite being one of the most prominent ones.
All that can be said today formally about a project is whether or not it's OSI-licensed, rather than whether it's open source. So companies such as GitLab can claim they are "open source" legitimately without using an OSI license--as can SQLite.
GitLab can only fairly claim they are "open source" because they do have a fully-functional core of the project that is truly open source.
Whether a license is specifically OSI-approved, isn't the point. The point is that "open source" means something as a term, and that is widely respected as the standard. If someone claims a license to be "open source" when it doesn't meet the definition, they can and will be rightly criticized for being deceptive in using the term wrongly.
> there are projects that are undeniably open source which are not issued under an OSI license. SQLite being one of the most prominent ones
SQLite is public domain. The OSI recommends against using a simple public domain declaration, but at the same time, does effectively say "for practical purposes it more or less works, though we recommend using a license instead": https://opensource.org/faq#public-domain
Only because it isn't trademarked. Anyone who has the slightest shred of respect for open source community uses the term properly. They coined the term.
As for SQLite, it's compatible with OSI licenses. It has been folded into a larger work that's licensed under an OSI approved license countless times. There are some projects that might throw around the term public domain but I'd have to examine the details to see if it's ready to be used as part of an open source project.
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.
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.
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.
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.
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.
Good examples of open source projects with diverse developer communities and permissive licenses include Hadoop, Apache webserver, Tomcat, NPM, Kubernates, TensorFlow and many more.
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.
(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).
> Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate.
The "freedom" references from GNU are with respect to the users of the software, not necessarily to any entity that may participate.
It's perfectly possible for a proprietary closed-source product to leverage code from a BSD/MIT project to remove user freedoms.
> 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.
I think developers should really start to question this. Why is a GPL component a problem and who is really inconvenienced by it and for what reason are they being inconvenienced by it? What do they want to do that GPL becomes a problem for them doing it?
It's not possible to devise framings which will please everyone in both the Free Software and Open Source movements. The disagreements between them are very old, and for some, embittered.
Which is why the LGPL exists. Most code that is designed to be shared & incorporated rather than complete/forked should likely be LGPL (if the GPL ideals are what is wanted).
Personally I just go with MIT/X11 but there are good reasons to want to use a GPL-type license
LGPL is sensitive to linkage, which means it has very different effects on different programming languages. For example, it's stricter for Rust and Go (as those languages are typically used) than for Java and Python (as those languages are typically used).
Yes. But the LGPL is still more restrictive as it requires you to share your changes. Not as much of a disincentive but it still discourages community.
There are two good reasons to go with a gpl or lgpl license.
One is ideological. You believe software should be free and that downstream developers must conform to your ideals. This is the Richard Stallman approach.
The second is control. You actively want to discourage forking and outside contributions. This is Oracle’s approach. This isn’t necessarily bad or evil, but it’s pragmatic. Generally a corporation doing this will offer the license under a separate paid offering as well.
I can’t think of any other good reasons to choose GPL.
> But the LGPL is still more restrictive as it requires you to share your changes. Not as much of a disincentive but it still discourages community.
Not a fan of GPL (because of developer restrictiveness), but I don't see how requiring changes to be shared implies more restrictiveness or discourages community. Can you explain the reasoning here?
In the early days of a software project, the most likely people to use it are business programmers: front line devs who have no say in corporate policy.
Typically, they want to use your code to save their own time. The code rarely does exactly what they need, so they almost always need to make changes. And since they are required under their NDA not to disclose any company related work, this prevents them from incorporating your code.
I have no feelings about this one way or another, but it's an answer to your question.
"I used to be worried about fragmentation, and I used to think that it was inevitable at some point," said Torvalds. “Everyone was looking at the history of Linux and comparing it with UNIX. People would say that it’s going to fail because it's going to fragment. That's what happened before, so why even bother?"
What made the difference was the license. "FSF and I don't have a loving relationship, but I love GPL v2," said Torvalds. "I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint."
LGPL only requires you to share changes to the LGPL code that you publish (you don't even have to submit them back, just make them available).
And yeah, that comes down to "well if you want to use our stuff and base new work on our stuff... share it to the world" but it has no effect on the wider application.
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?
> Why not turn this around and default to GPL as "nice and simple"?
Have you looked at the text of either of these licenses? (Or the MIT license? The linked page mentions the MIT license, but never any BSD license.) If you take a brief glance at both texts, the question immediately answers itself.
The GPL isn't simple at all. It restricts how your code can be relicensed and requires care in deciding to choose it. MIT is about as simple as it gets.
The GPL is anything but "nice and simple". There's a reason why it's such a huge wall of text, compared to the much shorter BSD and MIT licenses.
And FSF's preferred interpretations of the GPL, and various ambiguous things in it (especially with respect to dynamic linking and implementations of standard interfaces) make it even less "nice and simple".
Let's take an example: Django is a web framework that, among its components, includes an ORM. The ORM is mostly agnostic when it comes to what database you use (I say "mostly" because the core team has always had a preference for PostgreSQL, so there are some bundled things that either only work with PostgreSQL or become more featureful if you choose to use PostgreSQL); it comes with built-in backends that speak the SQL dialects of PostgreSQL, Oracle, MySQL and SQLite. There are third-party backends available that speak the SQL dialects of other databases.
To actually use it, you have to pair it with a DB driver module implementing PEP 249, the standard Python database API. A SQLite driver ships in Python's standard library; drivers for PostgreSQL, Oracle and MySQL are available third party.
Django's bundled MySQL backend expects to talk to a MySQL Python driver module. All currently-available Python driver modules for MySQL are GPL'd. Does the fact that the backend module for MySQL attempts to load a MySQL driver mean Django has to be GPL'd? Django and the driver will be sharing address space, after all, and FSF uses that as a clear indication of a "combined work" that must be GPL'd.
Now, the usual way around this is to point out that Django simply wants something implementing a standard API, and doesn't know in advance which implementation you'll choose to actually use; if you had some other library implementing the same standard API, it would work just as well as the GPL'd implementation. This has worked out in other domains to avoid accidentally GPL'ing things that just want to use a standard API implemented by multiple competing libraries.
But... the standard Python database API doesn't quite cover everything you might need to implement full-featured database access, especially when it comes to interrogating the version and supported features of the actual database you're talking to. Luckily these things can almost all be found out through DB-specific queries, but if Django has to hit a non-standardized bit of the driver's API to get some of that information, and if the driver is GPL'd, does that require Django to be GPL'd? And everything everyone's ever developed using Django?
As far as I can tell, the only thing used by Django's MySQL backend that isn't standardized in PEP 249 is a set of constants that label MySQL's internal column-type identifiers to allow introspection (i.e., so you can query for a table's column list and figure out that column type 7 is a TIMESTAMP, or column type 252 is a BLOB). Is that enough to GPL the entire Django ecosystem? What if FSF decides tomorrow that it is, and comes after us? What if we just copy/paste the integer values over into a file in Django? Does that list of constants even meet the requirements for copyright protection in the first place?
There is nothing "nice" or "simple" about having to navigate this. It's only "nice" if your definition of the term includes deliberately inflicting pain on people who are developing software that meets the FSF's definition of Free but which does not happen to be distributed under the FSF's preferred license. Personally I don't find that to be "nice" at all.
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.
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 any legitimate reason one would select MIT/X11 over Apache?
One or more of: one might prefer MIT's simplicity (both the text itself, and the what's needed to comply) relative to Apache-2.0, one might not like the specifics of the latter's patent terms, one might consider the former's arguable implicit patent license good enough https://opensource.com/article/18/3/patent-grant-mit-license
c. You may exercise the rights granted in Section 3 for commercial purposes only if:
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
As true as it is, I don't believe their definition is necessarily what is best for software or for developers. I don't believe that it is just that ownership of a product or its copyright, even in an open source capacity, should be transferred from developer to business owner if they're separate people.
Overly permissive licenses encourage private business to take advantage of software commons without necessarily contributing any of their changes back to it, which alienates their own developers from the changes at the moment and while at the moment it is trendy for companies to create software under these licenses, there's no mechanism to guarantee future updates will also be released in such a permissive way.
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.
Fun fact: at least one large company I worked with explicitly internally documented WTFPL-licensed software as unable to be merged into their codebase, because lawyers. Cf. MIT/BSD/Apache/ISC/CC-BY/CC0 that were all fine.
If you disagree that the WTFPL is a useable license, how does forking & relicensing work? Changing the license requires having a license that allows you to do so to the new target license (or ownership of the copyright). But if our assumption is that we reject the WTFPL as a valid license, how can we simultaneously use it to relicense?
I.e., instead of a needing a legal debate about whether the WTFPL allows you to use the code, it would seem to me you trade that for a legal debate about whether the WTFPL allows you to re-license the code.
(At any rate, the upstream relicensed to MIT, and BurntSushi sought agreement from "major contributors, where I interpreted 'major' as '100 lines of code or more.'", so the entire thing appears moot.)
Absolutely true, but the reason someone licenses their software under an open source license at all is because they want it to be open source. Some developers may erraneously think this is a good open source license, when in fact it might not have the effect they intended.
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.
Here are some analyses:
- https://creativecommons.org/2011/04/15/using-cc0-for-public-... Why this is okay to use for software.
- https://rd-alliance.org/sites/default/files/cc0-analysis-kre... concludes that it is sufficient in German law.
- https://www.gnu.org/licenses/license-list.html#PublicDomain It is recommended by the FSF as a prefered method for releasing source code into the public domain.