
Open Source License Helper Tool - ethanpil
https://choosealicense.com/
======
vortico
May I recommend replacing The Unlicense with CC0?
([https://creativecommons.org/publicdomain/zero/1.0/legalcode](https://creativecommons.org/publicdomain/zero/1.0/legalcode)).
It has all the same bullet points except is a bit tighter in countries where a
public domain release is not legally valid.

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-...](https://creativecommons.org/2011/04/15/using-cc0-for-public-
domain-software/) Why this is okay to use for software.

\- [https://rd-alliance.org/sites/default/files/cc0-analysis-
kre...](https://rd-alliance.org/sites/default/files/cc0-analysis-kreuzer.pdf)
concludes that it is sufficient in German law.

\- [https://www.gnu.org/licenses/license-
list.html#PublicDomain](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.

~~~
ta76567656
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?

~~~
mycl
If I understand correctly, the issue is moral rights
([https://en.wikipedia.org/wiki/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.

------
nimbius
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.

~~~
megaman22
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.

~~~
quadrangle
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.

~~~
megaman22
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.

_under most CyA lawyer regimes.

~~~
abritinthebay
Which is why LGPL exists.

~~~
megaman22
LGPL is problematic to some extent outside the original C-ist style of static
and dynamic link libraries. At least that's what I've been told.

~~~
belorn
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.

~~~
megaman22
Thank you, that's probably the best explanation I've seen of the distinction.

Still, it's an uphill battle to fight with bosses that don't understand the
licensing, and are gunshy of liability.

~~~
belorn
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.

------
benatkin
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.

[1]
[https://en.wikipedia.org/wiki/Shared_source](https://en.wikipedia.org/wiki/Shared_source)

[2] [https://gitlab.com/gitlab-org/gitlab-ee/](https://gitlab.com/gitlab-
org/gitlab-ee/)

[3] [https://github.com/greensock/GreenSock-
JS](https://github.com/greensock/GreenSock-JS)

~~~
ternaryoperator
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.

Edit: clarity

~~~
benatkin
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.

~~~
ternaryoperator
>They coined the term.

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...](https://opensource.com/article/18/2/coining-term-open-source-
software)

~~~
benatkin
I wasn't using the terms "open source community" and OSI interchangeably.

------
niftich
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.

------
wglass
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).

~~~
abritinthebay
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

~~~
wglass
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.

~~~
daveguy
> 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?

~~~
sillysaurus3
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.

------
JetSpiegel
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?

~~~
ubernostrum
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.

~~~
icebraining
I agree with your overall point, I just want to point out that the FSF can't
come after anyone, only the copyright holders of the driver modules can.

------
stockkid
I have used this tool many times to copy & paste appropriate licenses to my
projects. Very helpful.

------
oaiey
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.

------
SeanLuke
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?

~~~
mlinksva
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](https://opensource.com/article/18/3/patent-grant-mit-license)

------
captainbland
Needs more peer production license.

[http://wiki.p2pfoundation.net/Peer_Production_License](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-owners

~~~
rectang
That's a field of use restriction, and thus incompatible with the open source
definition curated by OSI.

~~~
captainbland
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.

------
ethanpil
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.

------
callekabo
I prefer copyfree licenses

[http://copyfree.org/](http://copyfree.org/)

and usually release stuff under the Copyfree Open Innovation License (COIL)

[http://coil.apotheon.org/](http://coil.apotheon.org/)

~~~
SeanLuke
I read that entire front webpage and still have no idea what a copyfree
license is.

------
teddyh
As an alternative, please see the Free Software Foundation’s license
recommendations guide:

[https://www.gnu.org/licenses/license-
recommendations](https://www.gnu.org/licenses/license-recommendations)

------
nisabek
our team has this link pinned in slack - very useful, normal human language
used to explain!

------
recluse00
No WTFPL? I'm disappointed.

~~~
q3k
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.

~~~
dankohn1
WTFPL is not OSI-approved and so briefly held up containerd coming into CNCF.

[https://github.com/chanezon/toml#about-this-
fork](https://github.com/chanezon/toml#about-this-fork)

~~~
deathanatos
IANAL, this is not legal advice, etc.

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.)

~~~
icebraining
Yes, clearly you can't change the license of a project you don't have a valid
license to.

------
caniszczyk
I also recommend TLDRLegal: [https://tldrlegal.com](https://tldrlegal.com)

~~~
overcast
Dang. Now THAT is a helpful resource. Thank you for pointing me to this.

------
teddyh
Note that this page is owned by GitHub. Will Microsoft change this page? Will
they maybe merely stop linking to it? Who knows.

