
The Lil License - jashkenas
http://lillicense.org/v1.html
======
dmm
Please just use the ISC license. It's a permissive license that is as short as
modern law allows. It's well understood and accepted. It's the default license
for node.js packages and the preferred license for OpenBSD.
[https://en.wikipedia.org/wiki/ISC_license](https://en.wikipedia.org/wiki/ISC_license)

Here it is in it's entirety:

Copyright <YEAR> <OWNER>

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

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.

~~~
CuriousSkeptic
I prefer the zero clause BSD license because it gets rid of the annoying
requirement to keep the copyright notice around.

Any arguments against?

~~~
jashkenas
The argument against is that someone who then encounters the code without the
notice will have no idea what license the code is under. They won't be aware
of the BSD rights and disclaimers that otherwise should apply to them.

What we do here instead is explicitly say that you can include the Lil License
text, or link to it instead — as we tend to do in these modern times.

~~~
CuriousSkeptic
That's just the thing. I want a license that is clear about my intentions when
I provide them a copy. What ever copy they receive from someone else is not,
and should not, be my problem in any way, I want nothing to do with that
transaction.

------
jordigh
While I appreciate the intent, patents are complicated, and the reason more
complicated and weak licenses like the Apache license version 2 exist are
precisely to address the complexity of patents.

Software nerds don't like complicated licenses just because they're not
lawyers, but legal complexity is inherent in human affairs and cannot be
simplified too much. The shortest license isn't necessarily the most desirable
one. Writing a new license just because the Apache license is tl;dr is just
not a good idea. Saying that you'll just ignore the law because you disagree
with it will actually probably work out for a while until you're big enough
for the law to no longer ignore you in return.

We've had amateur licenses written many times before. GPLv1 and the first Perl
license are examples. They both had to be rewritten once someone who actually
knows law looked them over.

In other words, kids, don't try this at home. There are professionals who can
do this for you.

~~~
jashkenas
Totally. And if it's a terrible idea, then it will die a quiet death, and that
will be fine. But there's a little more here than just "don't try this at
home."

The Apache license is a wonderful license. If you want to use it, you
absolutely should use it.

But people don't use it. They prefer to use something they can understand,
something that doesn't have to be interpreted by a legal team, and something
that they can feel comfortable imposing on the users of their code.

According to a 2015 survey conducted by Github, MIT and BSD simple licenses
are nearly five times more often used than Apache. Out of the top ten most
starred open source projects, nine of them use MIT/BSD, and only one uses
Apache.

Clearly, there's a desire — in the actual practice of sharing open source —
for something that explains your legal and social obligations in as plain an
English as we can muster, while still being crystal clear in legal terms.

~~~
jordigh
I'm pretty sure that's because Github encouraged, and to some extent still
does, for people to completely ignore licenses. This attitude spreads and
explains why people want the least amount of license posible.

The solution isn't to make licenses more "user-friendly". That user
friendliness can be a dangerous illusion. The solution is to not forget the
legal lessons that we already lived back before free software was renamed to
open source in 1998.

~~~
jashkenas
Github is fairly aggressive these days about alerting you to put a standard
license in your repository.

But they still remain with the problem that most folks choose the user-
friendly MIT (I would, and 9 out of 10 of the top projects do). This leaves
them with an issue: It's not clear that contributions submitted to an MIT
project grant permission to incorporate those contributions under the same
terms. We understand it socially, but it's not legally explicit.

Github has been trying to address this in their Terms of Service, by saying
that simply by using the site, you agree that "inbound=outbound":
[https://help.github.com/articles/github-terms-of-
service/#6-...](https://help.github.com/articles/github-terms-of-
service/#6-contributions-under-repository-license)

But the Github TOS isn't really the right place to be legislating that. For
more, see: [https://writing.kemitchell.com/2017/02/16/Against-
Legislatin...](https://writing.kemitchell.com/2017/02/16/Against-Legislating-
the-Nonobvious.html)

~~~
carussell
> It's not clear that contributions submitted to an MIT project grant
> permission to incorporate those contributions under the same terms. We
> understand it socially, but it's not legally explicit.

Given that GitHub works only through forks and pull requests, this is not a
problem. There are two repos A and B published under the MIT License. There is
no need to address what happens when the contributor behind B sends you a pull
request. (There is no need for contributor who published B to even send you a
pull request; in theory, you could "reach over" and start incorporating
anything from B into A without any participation from the person behind B—just
like you [probably] did with all your vendored libraries.)

Worrying about this is one of the cargo cultiest memes, second only to all the
videos on YouTube who think they're protected by a notice that says, "I don't
claim ownership of this video; all rights belong to X".

------
jashkenas
Friends, I totally get the initial instinct to think "Aieeee! Not another
amateur open source software license! Those things breed like flies!"

But if you wouldn't mind taking two minutes to read the text of the license
before giving in to that feeling — I think you'll find that it might put you
more at ease than what you're currently using — if you're using MIT.

Like MIT and ISC, it's short and sweet and comprehensible, and like Apache it
tries to establish common standards around potential patent use and
contributions back to the codebase. It hits a sweet spot that, for me, doesn't
exist in anything currently on the OSI's long list of licenses.

I did run it by a couple of lawyers and a couple of open source developers
before publishing it this morning. But I don't believe that review should
matter too much to you: An OSS license is an agreement between the author and
the user of the software. If they can both easily understand it to mean the
same thing, then we can feel that we're on solid ground. That's why we use MIT
today.

~~~
tptacek
Unfortunately, I've been conditioned by the scary stories 'DannyBee tells here
to worry about new license language that doesn't come directly from lawyers.

It sounds like you've actually had lawyers look at it. A blurb anywhere on
this page indicating that it's been vetted this would be pretty powerful!

~~~
jashkenas
It may be pretty powerful, but I'm uncomfortable believing that it really
should be. For starters, every lawyer has a different opinion, a different
style of preferred phrasing, and a different understanding of what open source
software is. Ultimately the parties involved are you, your users and your
contributors. Most of us don't have lawyers.

That said, I think it might be effective to put some short legal opinions,
from experts in this particular field, into the FAQ. If anyone's listening:
that would make for a great pull request.

The goal here is to make this thing as shipshape, watertight and bulletproof
as possible, while remaining "simpler than MIT". Then it becomes the license I
would have always wanted to use.

~~~
tptacek
I see your concern. I think _one qualified lawyer_ would put this issue to
bed. Surely there's one we can just pay a couple hundred to to scan it?

This license sure _looks_ great. It probably is! It would be neat if we could
just know that.

It's a cool thing to publish either way. :)

~~~
jashkenas
Let's do it. I think it's mostly a matter of picking not just a qualified
lawyer, but one of the best possible lawyers for the job: ideally, someone
well known who has dealt with OSS licenses and lawsuits in the past.

I've opened a ticket for it: [https://github.com/jashkenas/lil-
license/issues/3](https://github.com/jashkenas/lil-license/issues/3)

~~~
tptacek
'DannyBee, I blame you for this, so do you have any recommendations?

Jeremy, not that you need the help, but I think this is really neat and if you
want to pass the hat around to pay for something formal I'm happy to chip in.

------
adrianN
Having a nonstandard licence on your code basically ensures that no
corporation will use your project. Internal clearing processes become _a lot_
more expensive if it's not one of the approved licences.

~~~
schindlabua
Bit off topic, but is the WTFPL considered a standard licence? If I want to
give people the ability to do whatever the fuck they want to with my code, is
the WTFPL considered a good choice?

~~~
burntsushi
I used it for a while in a project. Just about everybody was fine with it
except for Google. I got several emails from Google employees over the years
saying that they could not use it unless I changed the license.

~~~
raphlinus
This is true, and now there's public documentation that explains a little more
of the rationale:
[https://opensource.google.com/docs/thirdparty/licenses/#wtfp...](https://opensource.google.com/docs/thirdparty/licenses/#wtfpl-
not-allowed)

~~~
cdelsolar
Is the JSON license allowed?

------
nobodyorother
Please stop making new licenses. You do not need a new license, you need to
understand how to use the existing ones and how they interact with one
another.

The number of license interactions you need to mange on any project is the
_factorial_ of the number of licenses in the project. With even just 4
licenses (pretty easy when you're _just trying to make it work_ ), that's 24
sets of interactions. Just wait till you get to 7 licenses.

------
Flimm
> Check out License Zero. It helps open source software stay free for use and
> modification for non-commercial purposes, while commercial users can be
> required to pay after a trial period.

I would delete the words "open source" from this sentence. License Zero is not
an open source license, as open source licenses cannot discriminate against
commercial uses. See the Open Source Definition by the OSI.

~~~
jashkenas
Thanks for the correction. I've made the change in the FAQ to not describe
License Zero as an open source license. On its own website, it's very careful
not to.

~~~
ZenoArrow
Open source or not, thank you for bringing it to my attention, I can see some
potential benefits of Licence Zero, especially for larger projects where
funding is more important.

The Lil licence looks promising too.

~~~
kemitchell
Thank you both for your interest!

For completeness: The original License Zero Public License, now dubbed the
License Zero Noncommercial Public License (L0-NC), is admittedly _not_ an Open
Source license per OSI's definition.

There is now also a draft, alternative public license for L0 projects, The
License Zero Reciprocal Public License (L0-R). It's a hair-trigger copyleft-
style license, built in much the same way, from a BSD-2-Clause base:

[https://github.com/licensezero/licensezero-reciprocal-
public...](https://github.com/licensezero/licensezero-reciprocal-public-
license/blob/master/LICENSE.mustache)

More here:

[https://medium.com/licensezero/a-hacker-public-
license-d2805...](https://medium.com/licensezero/a-hacker-public-
license-d28053038b45)

I believe L0-R _is_ an Open Source license, and have submitted to OSI for
approval. I also believe it will be as, if not more effective than L0-NC in
driving industrial users to purchase private licenses.

------
rbehrends
Hmm. As I understand, the primary purpose here is to have a permissive license
with a patent grant. Some problems I see:

1\. If you're actually have patent claims to your name (a minority of people,
while every author is ipso facto a copyright holder), you will probably want
to use an expressly vetted, narrowly drafted patent grant.

2\. The way the license is worded, it may ask you to do things that you can't
do, e.g. if you have the rights to use a patent claim, but not to (sub)license
it. (Contrast this with how the Apache license words its patent grant.)

3\. It's not clear how broad the patent grant is. It's not inconceivable to
read it so that once somebody uses the software, they get an unlimited right
to your patent claims, even outside that specific piece of software.

4\. You may be waiving your right to use software patents for defensive
purposes, too.

5\. There's lots of fuzziness in the wording. What are the "usage rights that
the author hold on [the software]"? US patent law grants rights to _exclude_
others from making, using, selling, or importing the patented invention; it
does not grant a right to exploit the patented invention. (Unlike copyright,
which creates an exclusive right for authors to use and distribute the work.)

6\. How compatible is the license with other licenses with patent grants?

~~~
jashkenas
Thanks for the list of concerns, it's very much appreciated. If you care
enough to open any of them up as an issue on Github, it would be great to
discuss them there. But for now, in short:

1\. Yes. If you actually own a patent portfolio that you value highly, you may
want to use a custom, narrowly worded grant. This license might not be for
you. This license is for the 50+% of open source projects currently using MIT.

2\. I don't quite follow the problem you're outlining here. The Apache license
tries to scope its patent license only to actions that "necessarily infringe"
on the Work and the Contributions to it. I'm not sure how you mean for
(sub)licensing to fit in.

3\. The patent grant is intentionally simpler and broader than, say, Apache.
There's no clawback provision, and in short, it gives you: "usage rights to
any patents the authors may hold on the software." It doesn't give you the
right to use the authors' unrelated patents. The balance here is struck to
give more protection and confidence to the user of the open source, not to
rigidly protect the potential software patent holder. I think that's the right
way to lean.

4\. This rhetoric around offensive and defensive uses of software patents is
what's keeping Facebook in such hot water with GraphQL and React right now.
The only way to use a software patent against someone is offensively — it's a
MAD-style threat of legal action. If you want mutually assured patent
annihilation, then don't use LIL to release open-source software that uses
your patents. It's not a great mix.

5\. In US patent law, you can _sell_ your patent, _prevent_ other people from
making use of it, or _license_ usage rights to it. The latter is what we're
doing in this case. ([https://www.legalzoom.com/articles/selling-your-patent-
what-...](https://www.legalzoom.com/articles/selling-your-patent-what-you-
need-to-know))

6\. That is a great question. And it would be good to eventually have a wiki
page, detailing compatibility with various alternative popular licenses. As a
permissive license (more permissive than Apache), my best guess is that it
would be generally compatible — but we should look into it further.

~~~
rbehrends
Some clarifications:

1\. My larger point is that this license simply is not going to interest a lot
of people because they don't have patents to begin with. Only a minority of
contributors will have patent claims, and almost all of them will be
commercial contributors. They will simply not be interested in such a license
and not contribute to a project using it; for people who don't have patents,
the additional patent grant does not make a difference, other than that
they're possibly scaring away contributors who do have patents.

2\. The point here is that the license may _require_ you to grant rights that
you can't grant, ergo you can't contribute work under the license. The license
requires you to grant any rights that you hold, but you may not have the right
to grant such a sublicense. The Apache license, in contrast, only requires you
to grant a license for patent claims that you can actually license.

3\. My point here is that the patent grant may be uncomfortably broad
especially for commercial contributors in that they give up rights that
they're not willing to give up.

4\. This is quite different from the Facebook situation. It's one thing to
allow others to use your patents; patent holders may be much more reluctant to
unilaterally disarm defensively, too. In order to get them to accept such a
broad patent grant, you have to convince them that this in their best
interest, too. That you can convince people without patents to their name to
use the license is irrelevant, as it does not matter whether they use a
license with or without a patent grant. If I were a patent holder, why would I
give up my defensive rights against third parties along with a patent grant
for using the software? How would that serve my interests?

5\. So, what are the usage rights if you believe that this is a well-defined
legal term? Can you be more specific? How are they related to patent claims?
Have you researched whether this would include sublicensing rights and whether
sublicensing scenarios need to be considered separately?

~~~
jashkenas
Let's keep digging in!

1\. I feel entirely the opposite way about the appeal of an MIT-style license
that includes a patent grant. It's not primarily about making the author feel
comfortable — as the author probably doesn't have patents, and doesn't intend
to. It's about giving the _user_ of the software confidence. Because the user
has no idea what patents the author may or may not hold. At this moment, this
is playing out to dramatic effect in Facebook's open source projects — you can
see an example here:
[https://github.com/facebook/graphql/issues/351](https://github.com/facebook/graphql/issues/351)

Being able to give users of my software fuller confidence under the Lil
License also makes me more interested in using it as an author. It's a
virtuous cycle.

2\. I'm afraid I still don't quite see the issue you're describing here. If
I'm following correctly, the hypothetical case is a contributor who writes a
bit of code that exercises a patent that she has a license to, but not
permission to sublicense, and then wants to submit that code to an LIL-
licensed project. If she's not allowed to sublicense, then she can't
contribute that code. She wouldn't be able to contribute it to an Apache
project either.

3\. It might be. I think that its width is more suitable for most open source
projects than the narrower Apache and MPL, but that's something that would
make for a good discussion. I'll open a ticket.

4\. Again, we're talking past each other a bit. This isn't really trying to
appeal to the Facebooks of the world — it's trying to appeal to us regular
folk. That I might be able to convince people without patents to use the
license is not irrelevant, it's exactly the point. Those people are the target
audience. From a user's point of view, the patent grant is still important —
_because I never know for certain when an author may or may not hold a patent
on the code_.

5\. If I grant you usage rights to a patent, I grant you a license to make,
use, sell, import and otherwise transfer implementations of the invention
described in that patent. If you think we need to spell out all of those words
explicitly, perhaps throwing in "have made" and "offer to sell" as well, feel
free to open a ticket and we'll talk about it further.

~~~
rbehrends
1\. This wouldn't have changed anything about the GraphQL situation. Unlike
with copyrights, getting a patent is expensive. Companies don't do that for
fun and they don't give their just acquired patent claims away for free. They
may grant a limited license (narrowly scoped to include only the specific
software or excluding use for defensive purposes), but there's no point in
first paying for a patent and then giving it away for free.

2\. Correct, she's barred from contributing, and if she accidentally does so,
anyway, she may get into further trouble, because she's violating one license
or the other. And no, Apache does not have the problem, because that patent
grant is specifically limited to patent claims that contributors have the
right to license. Same goes for the OSI BSD+Patent license (not to be confused
with Facebook's BSD+Patents license, which has a similar name, but a totally
different purpose).

4\. And a license will not protect you from that, because unlike with
copyright, innocent infringement does not preclude liability. See the folks
that are building React variants to avoid the Facebook license: they risk
infringing upon patent claims, anyway (as long as they use similar
algorithms), and won't have a patent grant to protect them. They can grant any
patent-related rights they want, and it'll result in zilch protection.
Granting rights only matters if you can actually grant the rights. Without
being the actual patent holder, you cannot indemnify anyone.

5\. "Opening tickets" is fruitless, because you still end up with a crayon
license. What you should do is consult actual lawyers specialized in the field
and let them draft a license to your specification.

[1]
[https://opensource.org/licenses/BSDplusPatent](https://opensource.org/licenses/BSDplusPatent)

------
YorickPeterse

        > Permission is hereby granted by the authors of this software, to any person
    

Person as in what, a natural person? What about non persons such as legal
entities?

    
    
        > and including usage rights to any patents the authors may hold on it
    

So the license allows you to use any patents (held by the project author)
included in the project, but it doesn't cover anything about patents used by
contributors when submitting changes. OK...

    
    
        > Any modification to the software submitted to the authors may be incorporated into the software 
        > under the terms of this license.
    

May? That seems like something that should really be changed to "Any
modification to the software submitted [...] will be incorporated into [...]"
or something similar that _doesn't_ let people decide about this on the fly.

This license as a whole is rather vague, leaving a lot up to interpretation.
This isn't something you want from the only thing that stands between you and
a potential legal nightmare. Just use good existing licenses such as the MPL
2.0, Apache, GPL (or some flavour of it), or even the MIT license (though I
would strongly recommend not using it without a CLA).

~~~
jashkenas

      > Person as in what, a natural person?
    

Person as in a legal person. This includes entities like corporations,
organizations, representatives and so on: [http://legal-
dictionary.thefreedictionary.com/person](http://legal-
dictionary.thefreedictionary.com/person)

    
    
      > but it doesn't cover anything about patents used by contributors...
    

It tries to. Any change contributed to the project grants permission to
incorporate that change under the same terms of the license, which includes
the patent grant. This is how people generally tend to behave with open
source.

    
    
      > May? That [...] should really be changed to [...] will
    

I also considered "will" and "shall" and "grants permission to" and a few
other options, but "may" fits most precisely and succinctly. Submitted
contributions aren't necessarily going to be merged into the project, but they
may be, and if they are, the act of submission back to the project grants
permission to incorporate them under the same terms of the license.

[http://legal-dictionary.thefreedictionary.com/may](http://legal-
dictionary.thefreedictionary.com/may)

~~~
YorickPeterse

        > Person as in a legal person. This includes entities like corporations,
        > organizations, representatives and so on:
        > http://legal-dictionary.thefreedictionary.com/person
    

This may be the case for US law ("person" including both individuals and
organisations), but it might also not be the case for all countries across the
world. For example, Dutch law seems to define "person" as the individual (e.g.
you and me) and seems to use a separate term for legal entities and the likes.
It's possible that in practise the two are considered the same but I haven't
been able to find such an example.

Exactly because of this it's better to be explicit. For example, the MPL 2.0
explicitly defines this:

    
    
        > 1.1. "Contributor"
        >
        >      means each individual or legal entity that creates, contributes to the
        >      creation of, or owns Covered Software.
    

Here the term "contributor" is used, but the same could apply to the term
"person".

    
    
        > It tries to. Any change contributed to the project grants permission to
        > incorporate that change under the same terms of the license, which
        > includes the patent grant.
    

The patent grant states that any patents owned by the author can be used by
the software's users:

    
    
        > and including usage rights to any patents the authors may hold on it
    

However, nowhere is it stated that patents used for contributions
automatically belong (or can be used by) the authors and can thus also be used
by the users. Defining what "authors" means could clear things up, though
you'll probably want to separate the definition from "contributors" since you
probably don't want random "contributors" to also be an "author" (this could
give them too much power for example).

Again the MPL 2.0 is a good example since it does cover this, albeit not in a
single place and in a somewhat hard to grok way.

~~~
jashkenas
Right — I think this is the central point I'm trying to make:

If you want a license where every noun in the license is rigorously defined at
the top, where every possible use of the software is spelled out explicitly,
and where every eventuality is considered in advance, then the Lil License
isn't for you. It's not supposed to be. We already have Apache 2.0 and MPL 2.0
for that, and they're great. Use 'em.

Instead, the goal here is to cover the bases we know we need to cover in 2017
(contributions and patents), while remaining as simple as or simpler than MIT
— which is the license that everyone actually uses. It's a different goal.

~~~
ksec
So Lil is basically either

MIT + Patents Grant

or

Apache 2.0 but much simplified in wording and length.

Am i correct in the grand overview?

------
slfront
Try the COIL instead, if the main reason for this license is a patent clause.

[http://copyfree.org/content/standard/licenses/coil/license.t...](http://copyfree.org/content/standard/licenses/coil/license.txt)

edit: Please stop advertising for AL2. It's not as good a license as people
think. It contains some fiddly terms that many people don't even know are
there, or don't understand, and is distressingly easy for people to casually
violate by accident. Its complexity adds to the problem as well, by offering
many opportunities for unintended legal effects in (so far hypothetical)
future lawsuits to arise from interactions between parts of the license, a
problem with any long license, and AL2 has severe license incompatibility
issues as well.

~~~
JamesFM
I've never heard of this license before. Has it been vetted the OSI or the
FSF?

Also what specifically is bad about the Apache 2 license?

~~~
slfront
I AM NOT A LAWYER.

THIS IS NOT LEGAL ADVICE.

It is not certified by either FSF or OSI. The process of getting it evaluated
by the OSI and certified involves a lot of money, unless it is such a popular
license that the OSI is politically backed into a corner about it. The FSF's
politics around such things get downright strange; I'm not even sure what it
would take for the FSF to consider a non-GNU license.

AL2 contains restrictions such as a requirement to perform bookkeeping when
making changes (notes for every modified file about who changed it) and
restrictions against changing another file. The bookkeeping restriction is
violated with stunning regularity; so far, nobody has been sued over it, as
far as I know, but that's true of the majority of license violations anyway.

AL2 also, as I mentioned, has some serious license incompatibility problems.
Some patent and indemnification material in AL2 is considered incompatible
with GNU licenses prior to v3, for instance. In fact, any license that
includes a restriction against any connected work being "more restrictive" in
some way (which includes GNU licenses, among others) is likely to suffer some
significant compatibility issues with any license that has weird quirks like
the previously mentioned issues of AL2 (bookkeeping, invariant file), too. The
patent termination part of AL2 is unlikely to cause incompatibility with most
licenses (GNU licenses are weird, in that regard) unless they come with a
restriction on "restrictions" and have a less restrictive patent clause than
AL2 (no patent termination, for instance), but the edge cases in AL2 can cause
issues with other licenses.

I'm not a lawyer (and this is not legal advice), but I think a case could be
made in court that AL2 and GPLv3 are actually not compatible at all, because
of those clauses, despite what ASF and FSF say.

Beyond that, there's just the simple fact of complexity. You've probably heard
that software tends toward X bugs per Y lines of code, and that's true for the
most straightforward, linear software designs. As the complexity of the design
of the software increases, though, the possible unexpected interactions
between parts of it increases as well. The result is that, in practical terms,
the likelihood of bugs actually increases faster than the number of lines of
code. The same effect occurs with legal licensing terms, to some degree; the
more complex a software license, the more likely you are to run afoul of
unexpected legal effects of the license. AL2 is a rather complex license, much
simpler than GPLv3, but significantly more complicated than something like the
COIL, especially given the inclusion of the terms I mentioned earlier, which
are radical departures from the most widely-used, best-understood "state of
the art" of license design.

------
jstimpfle
I've had the impression lately that people are overly scared of licenses.
Like, on the level that a forgotten dot or so at the end could completely
change the meaning as seen by jurisdiction.

IANAL, but I don't feel that's the case. I'm actually pretty sure you could
just put "You're free to use this software for whatever you want" in a
somewhat obvious central location, and your users would be good. The obvious
intent counts. The BSD licenses don't seem to do more (besides adding a few
restrictions for the user).

WTFPL is another good example license. I haven't really heard that it's a bad
or jurisdictionally "invalid" license.

(But sure, for "big" stuff I guess the comment by adrianN applies).

~~~
nerdponx
AFAIK there are certain rights that copyright holders can't actually waive in
certain jurisdictions.

~~~
jstimpfle
Yes, I have heard that the term "public domain" doesn't exist in some places
and that might technically mean no rights are granted to the user at all, or
something along these lines. And for that reason, some projects have some kind
of dual-license ("this code is in the public domain, or totally free in case
there is no such concept in your country").

But again I feel like that's acting and being scared without any evidence.
(And it seems really silly to me that an author would actually have to adopt
to the country of the _user_ ).

There is very little official statements to find on the internet. All I've
ever heard about is these big corporations taking nasty fights, and that seems
to scare people with their little tinker projects to death.

Realistically, I would be surprised if e.g. the MIT license was actually more
user-friendly than the WTFPL.

I'd love to hear about these thoughts from actual lawyers!

~~~
slfront
I AM NOT A LAWYER.

THIS IS NOT LEGAL ADVICE.

The problems with public domain dedication across jurisdictional lines, as I
understand them, are:

1\. Users (who are aware of how the law works, in general terms) in a country
that doesn't recognize a right to relinquish copyright to the public domain
will be afraid of getting sued, so they won't use the software. It might as
well not be open source for them.

2\. Contributors to your public domain software from those countries are not
allowed to relinquish copyright in their works to the public domain, and as a
result you're actually accepting work under copyright into your otherwise-
public-domain software, which means it's not really public domain software any
longer, because of mutual copyright observance agreements between those
countries. Thus, for instance, because the US recognizes German copyrights,
and Germany doesn't allow dedication of copyrightable works to the public
domain, a German contributing code to a public domain work in the US actually
contaminates the public domain work with code covered by copyright, thus
making it no longer a (pure) public domain work, even in the US, because of US
recognition of German copyrights.

If the German in the above example actually transfers the copyright to you,
then YOU dedicate the work to the public domain, that might work. I'm just
guessing, though, and I'm pretty sure it would require some explicit legally
binding (and provable) statements about transferring copyright to you.

~~~
germanier
To make this more complicated, in Germany copyright is not transferable at
all. The best you can do is assign exclusive rights to someone else (doing
that correctly is non-trivial). Even worse: There are some rights that belong
to the creator alone and they cannot give them away.

~~~
slfront
Yeah, international copyright law is a damned bomb crater. It's nothing but
devastation and wreckage, and threat of imminent demise.

------
amelius
> Permission is hereby granted by the authors of this software, (...) and
> including usage rights to any patents the authors may hold on it, (...)

But what if the source code is modified? Will the users still get the usage
right of the patents? And what if the source code is modified so much that the
original code is barely recognizable? It seems to me that using this license
means you're giving away your patents for free.

~~~
belorn
> original code is barely recognizable

Will the original authors still have copyright over it?

If yes: Then clearly in the mind of the law the original work is still
present.

If no: Then the license choice of the original authors is not longer relevant.

~~~
amelius
Let me rephrase: users could use the software only to gain free access to the
patents. Thus this license is like giving away access to the patents.

~~~
jashkenas
The intent is to provide users of the software with full confidence that by
using the software, they will not be held liable for infringing on the patents
that the authors of and contributors to the software might hold on the
software.

Other licenses, like Apache, include patent grant withdrawal clauses, where
you can lose the right to use the patent if you initiate a lawsuit.

The notorious Facebook BSD+PATENTS license includes a similar withdrawal of
patent grant, but for any Facebook patent, not just something related to the
software in question, and also only if you sue Facebook or a subsidiary — the
Apache withdrawal applies to "any entity".

Here, there are no withdrawal provisions, hopefully giving you that full
confidence as a user. As an author, if you have a patent on something, and
then you release an open source project under LIL that uses that patent, you
give up the right to sue anyone for infringing on your patent by using your
open source project, period.

I think that's more in the spirit of open source.

~~~
carussell
> The notorious Facebook BSD+PATENTS license includes a similar withdrawal of
> patent grant [...] only if you sue Facebook or a subsidiary

This is not true. The Facebook PATENTS grant terminates if a patent assertion
relating to the software is made against against "any party".

------
102030485868
"distribute and sell": but what if I just want to distribute?

Oxford commas are important.

See: [https://www.nytimes.com/2017/03/16/us/oxford-comma-
lawsuit.h...](https://www.nytimes.com/2017/03/16/us/oxford-comma-
lawsuit.html?mcubz=0)

~~~
jstimpfle
This is not a situation where Oxford commas are needed to disambiguate. The
way you see it, I think an Oxford comma would force you to do even more things
at the same time. But that's silly; this statement is granting you rights, and
it's your choice on whether you want to exercise them or not. If some rights
can be exercised only conditionally, the text needs to make that clear.

------
jwilk
Don't roll your own crypto, er, I mean legal.

------
Dayshine
What did your lawyers say?

------
beefhash
A tech project or project that is related to tech that does not have its
primary domain serving HTTPS? It's hosted on GitHub Pages. Every single time.

------
amattn
The contributor statement is new to me and definitely the highlight of this
license:

> Any modification to the software submitted to the authors may be
> incorporated into the software under the terms of this license.

I'd love something like this become a little more common. Making contributors
sign paperwork is a tremendous hassle. Hopefully the OSI
([https://opensource.org/licenses](https://opensource.org/licenses)) will take
a crack at this one soon. If it shows up on their list, I can see adoption
ramping up.

------
joseluisq
It looks like a fix to fb license issue...

"and including usage rights to any patents the authors may hold on it"

------
maxlybbert
I thought the open source community had matured beyond the need for everybody
to write their own license.

~~~
yellowapple
I thought the open source community had matured beyond the need for everybody
to use a single one-size-fits-all license in complete ignorance of their
actual needs and goals.

~~~
maxlybbert
They grew out of that before they realized there's little value in writing a
new license when there are already so many to chose from.

I was just starting out when Google Code announced it would only host projects
that used an approved license, and Google had a very short list of approved
licenses. Sourceforge was more flexible than that, but they still discouraged
people from striking out on their own.

It took me a while, but I was eventually grateful to Google for being so
effective at hitting the brakes. Opensource.org currently lists 83 approved
licenses. Fsf.org has a similar list. For a new license to be valuable to me
it has to be measurably better than each of those 83 licenses in some way that
matters to me. Otherwise it's an annoyance, at best.

------
akerro
Is this the opposite of react native license?

------
andrepd
Gray on gray text... Just why?

------
brotherjerky
Obvious XKCD is obvious: [https://xkcd.com/927/](https://xkcd.com/927/)

I really admire the goals here, and I read through the FAQ ... but I feel like
this just adds to the noise.

As much as a respect Jeremy, I'd be a little cautious about using this text
written by a non-lawyer.

------
xena
Why not CC0?

~~~
Flimm
Creative Commons advise users against using CC0 for code. CC0 also got caught
in a technicality, causing it to never get approved or disapproved as an open
source license by the OSI.

~~~
insertnickname
CC does not advise against using CC0 for software, only their regular CC
licenses. See:
[https://wiki.creativecommons.org/wiki/CC0_FAQ#May_I_apply_CC...](https://wiki.creativecommons.org/wiki/CC0_FAQ#May_I_apply_CC0_to_computer_software.3F_If_so.2C_is_there_a_recommended_implementation.3F)

------
0xbear
Just use Apache 2.0. Don’t invent new licenses, there are way too many
already. Unless your project offers something extraordinary, a custom license
not written by an IP lawyer == no use of your code in any project where
lawyers have to review the licensing.

