Open Source License Helper Tool
choosealicense.com
choosealicense.com
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.
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.
The Unlicense sometimes causes issues with software being accepted into larger collections. CC0 is much more thoroughly drafted, and more widely accepted.
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.
It's also officially recognized by the OSI.
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.
Google publishes it's open source docs, so you can just look: https://opensource.google.com/docs/using/agpl-policy/
We also banned patching agpl projects, I'm just too lazy to find that link for you.
NPM or Nuget under more restrictive license regimes would never get off the ground.
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.
under most CyA lawyer regimes.
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.
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.
Still, it's an uphill battle to fight with bosses that don't understand the licensing, and are gunshy of liability.
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.
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 ideology comes from very practical concerns about users being able to know and control what their computers are actually doing.
[1] https://en.wikipedia.org/wiki/Shared_source
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.
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.
Edit: clarity
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.
The term was coined by Christine Peterson who was not part of OSI, AFAIK. [1]
[1] https://opensource.com/article/18/2/coining-term-open-source...
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
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.
For an example of things going the other way, Qt relicensed all their proprietary libraries to LPGLv3 just a few years back.
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.
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).
Personally I just go with MIT/X11 but there are good reasons to want to use a GPL-type license
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.
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?
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.
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.
"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."
https://www.cio.com/article/3112582/linux/linus-torvalds-say...
MPL, on the other hand, is per-source file.
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.
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?
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.
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.
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.
http://wiki.p2pfoundation.net/Peer_Production_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-ownersOverly 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.
and usually release stuff under the Copyfree Open Innovation License (COIL)
The point of the home page is to make it easy to choose a license, not to list every possible choice.
(I occasionally help maintain https://github.com/github/choosealicense.com which is the source for the site.)
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.)
[0]: http://edwards.dk/thesis.pdf (p. 120, 231)