The Lil License | Hacker News Reader

The Lil License

lillicense.org

126 pointsjashkenas131 comments

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

Here it is in it's entirety:

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.

from the FAQ: "in practice, we need just a little bit more: a declaration of the intent not to use software patents against users, and the shared understanding that contributions back to the project will be incorporated under the same terms of the license."

ISC don't have either of those. If the authors want a patent grant, why should they not be allowed to have that?

Why not apache2 then?

FAQ actually recommends it if you want something more robust. Lil is small and simple.

Maybe because it's not a great license.

What are the issues with it? Anything other than the size/complexity?

ISC, like MIT/Expat, lacks a contributor license agreement. Is it implied that any contribution to an ISC-licensed (or MIT-licensed) project is granted to the original author?

I love ISC — but you're quite on point. It also says nothing about any patents potentially held by the authors.

See this HN comment from a year ago for a fuller exploration of how that can be problematic: https://news.ycombinator.com/item?id=12597488

The Lil License kind of makes sense if you think about it as an attempt to add explicit patent protection to an ISC or MIT-style license. But only "kind of".

What the patent system gives a patentholder is the ability to selectively prohibit others from making, selling, or using some product or method protected by the patent. The Lil License is weird in that it only explicitly mentions the latter.

Its text regarding copies of the license is also very weird.

Please do not use this license.

The term 'usage rights' is a bit confusing here. I think it may be intended to refer to 'use' as defined in the previous half of the sentence, i.e. 'including the rights to run, read, copy, change, distribute and sell'.

Maybe this should be made clearer somehow, e.g. 'and including any herefore necessary license to patents the authors may hold'.

Of course not, licenses are for granting rights to use copyrighted works, not for transfering copyright.

I also don't see why open source contributors should give away the copyright to their work. All it accomplishes, is that the "original author" (= the copyright holder, usually a company) can re-license the work without agreement from all contributors. It strips contributors from parts of their rights.

So if I fix a piece of buggy open-source code and my patch is merged, then I "own" the bug fix and the author no longer owns that portion of the program? Is that really what you're proposing?

It makes sense in the case where I contribute, say, an entire new module. Then I should have the right to do with it as I please. But there needs to be a line drawn somewhere, and I sure as hell couldn't tell you where.

> So if I fix a piece of buggy open-source code and my patch is merged, then I "own" the bug fix and the author no longer owns that portion of the program? Is that really what you're proposing?

If you fix a piece of software, why would you send the fix to the original creator? To show off? The only reason I can see is for the creator to merge your fix into the project.

But it seems to me that it makes the most sense to clarify that when the creator merges the changes. I don't see why the license should include a CLA any more than it should encourage potential contributors to be nice to each other, or to look both ways before crossing the street.

You need a CLA precisely you need a default in the case (99.9999% of the time) when the author fails to license their own patches. Maybe this just has never been an issue before, or maybe there are already court precedents around it. But it seems beneficial for authors, maintainers, and users to reduce or eliminate ambiguity due to "un-licensed" contributions.

If somebody downloads source code for a project, fixes a bug, emails that fix to the maintainer, and then tries to sue for copyright infringement, you can be sure that the first question an attorney will ask is "why did you send the fix to the project?" It would be very hard to claim that the contributor didn't expect the project to distribute the fix.

With git, the contributor has an even harder case to make. A pull request is literally a request to incorporate your contribution into the project. If the pull request doesn't include a proposed change to the license, it would be very hard to claim that the fix couldn't be distributed under the terms of the existing license.

I'm not aware of any court rulings directly on the subject. The best I can think of is the Prenda Law case. They sued people for copyright infringement for downloading some porn videos. A few of the people targeted showed evidence that Prenda Law had uploaded the videos themselves, and Prenda Law immediately tried to withdraw their cases. Some of the judges were very upset about that behavior. I'm pretty confident about how a court would handle a case where somebody claimed the contents of their pull request weren't meant to be distributed.

The traditional concerns have been cases where people try to contribute code that actually belongs to their employer, which remains a concern with this CLA-in-the-license approach, or projects interpreting their own licenses in obtuse ways ( https://lists.debian.org/debian-legal/2002/11/msg00138.html ).

That makes sense. Thanks for clarifying.

I imagine this could be an issue if, say, it's a project like Firefox and they start including some binary blobs. Without an explicit CLA, couldn't a FOSS-zealot contributor now sue to have their code excised from the product?

For the record, I'm not a lawyer. If I understand the question correctly, I believe the argument would be that the contributor believed all contributors were on equal footing (e.g., all contributions had to comply with the same rules) or that the project somehow promised to behave a certain way -- and that promise may have been included in the license. Without a separate explicit promise about how the project would act in the future, I wouldn't expect the lawsuit to go anywhere, but I don't think it's a silly argument, and it may have a better chance than I believe.

Broadly speaking, the CLAs I've seen either (1) fall into the classic legal "belt and suspenders" approach of being explicit where there is arguably an implicit promise, or (2) require the contributor to transfer copyright to the project and then make promises about what the project will do with the code, including promises about relicensing, and a broad license back to the original contributor.

US copyright law sometimes assumes that there is some kind of agreement between people who collaborate on a copyrightable project, and generally speaking, the CLA looks like it serves that purpose.

Your question is based on a common assumption, that you asked about a couple of days ago. In the US, at least, there are two ways multiple people can hold copyright on something: (1) if each contribution is independent, like a magazine or encyclopedia article, you have a collective copyright; (2) if each contribution is meant to merge with the others, you have a joint copyright. The rules for collective copyrights are basically what programmers seem to expect for collaborative works: each contributor owns copyright on their particular contribution.

However, I believe most open source projects are actually joint works, and the rules for joint copyrights are wildly different from what programmers seem to expect (e.g., http://copyright.universityofcalifornia.edu/ownership/joint-... , but you can find other explanations online, including at http://copyright.gov ). It's clear to me that the law assumes people who collaborate on a joint work will have some kind of agreement between them, like a CLA. I'm not able to find it right now, but I'm aware of one case where somebody contributed to a proprietary program, declared that made him a joint copyright holder, and started selling copies of the software without permission. The court agreed that if he had been a joint owner he would have had authority to sell copies without coordinating with the other owners, but the court decided he only had copyright in his contribution, like a collective work, not because the contribution could stand alone, but because it was relatively small and easily identified.

Based on that ruling, if I maintained an open source project under some kind of restrictive license that I intended to enforce, I wouldn't worry about getting a CLA for small patches (aside from getting some statement that they had authority to offer the contribution), but I would worry about getting one from regular contributors.

There is some point when a contributor crosses a threshold and becomes a joint owner. You want a clear agreement between the joint owners, but I don't believe the license is the right place for that agreement.

GitHub terms of service for example say that there is an implicit "inbound=outbound" agreement on code that you contribute via GitHub.

> So if I fix a piece of buggy open-source code and my patch is merged, then I "own" the bug fix and the author no longer owns that portion of the program?

Yes, and it makes sense, after all you made that part of the code. The same holds true for licenses like the GPL.

Remember the shitstorm about MIR and the CLA that it required? People do not want to sign their rights away and allow a company to sell away their code.

Transferring copyright has some special consequences if a contribution is made by a company employee as a part of a job, or so I heard. This greatly limits the number of high-quality contributions.

Very, very hard to get corporate lawyers to agree to CLAs, even at companies that encourage contributions to open source.

I don't mind signing a CLA in some instances:

* if the license is permissive

* if the license is copyleft and the organization is a non profit.

Canonical fit neither of those.

Kind of OT, but why does open source software always contain a warranty disclaimer? Has someone ever been sued for releasing open source software that doesn’t do what the user expected?

I can't help you out with a history of lawsuits to cover damages from faulty open source software, but here's a great little link to explain the legal reasoning for the need for the disclaimer:

https://oss.kemitchell.com/#contract-law

Quickie TL/DR; OSS is ultimately a product offered under a license. Without a warranty disclaimer, if the code proved to be shoddy, unfit for use, buggy, or crashed and damaged your business — you would have the ability to sue: I offered you a product that claimed to do be able to do a thing, and it didn't.

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

Any arguments against?

I am not familiar with this variant. However, in civil law countries you need an explicit waiver (like the CC-0 license), otherwise the duty to preserve attribution remains there even if the license said otherwise. That's because attribution is a moral right rather than part of copyright.

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.

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.

Could somebody attach their own copyright notice and pretend to be the author of your work?

That is a good question indeed! My intent is absolutely yes. Do what you please just don't blame me for it. But I guess legally no. It's license, not a transfer, so I'm still the copyright holder, which creates some doubts, true.

The zlib license does the same thing and is OSI/FSF approved. http://zlib.net/zlib_license.html

I don't really see how it could do the same thing. It clearly has three restrictions in its text, none of which is present in 0BSD. Number 3 being the one differentiating the 0BSD license from most other licenses.

Also 0BSD is OSI approved, they call it free public license though

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.

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.

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.

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

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

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

"back before free software was renamed to open source in 1998"

That's an interesting reading of history, and one that the creators of the terms "free software" and "open source" would probably both vigorously dispute.

The creators of both terms agree. I asked them:

http://jordi.inversethought.com/blog/5-things-we-have-forgot...

And here:

https://opensource.org/faq#free-software

Sure, OSI has an official doctrine, and Perens has (or had) kind of a unique point of view within that, about the two terms being fully synonymous -- but he partly walked back that view later, and Stallman and FSF's has historically been very different:

https://www.gnu.org/philosophy/open-source-misses-the-point....

And especially:

"The two terms describe almost the same category of software, but they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement.... Most discussion of 'open source' pays no attention to right and wrong, only to popularity and success..."

And of course OSI officially wrote "We realized it was time to dump the confrontational attitude that has been associated with 'free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape." (http://web.archive.org/web/19981206185148/http://www.opensou...)

In other words, "open source" was about depoliticizing "free software" to make it more commercially palatable. (And arguably, it worked.)

Yep. It's a rebranding. And it worked.

Kind of like machine learning instead of statistics.

The "creators" are interested in securing their legacy. The term "open source" was in use before OSI got in the game:

1996:

https://groups.google.com/d/msg/no.linux/1UZo-3iv0tM/XPrPljd...

1995:

https://groups.google.com/d/msg/comp.graphics.raytracing/6oZ...

Both of those say "open source code". It's not a phrase like "open source" alone. The emphasis is on "source code" not on "open source".

While it sounds pretty brain-dead to put "open" in front of anything, to the point that it seems like the most natural thing for it, most people did not use this term and there was very little widespread understanding of what "open source" meant. If it wasn't for OSI, we'd still be saying a bunch of disjointed things instead of being universally aware of something called "open source".

Every time I have this discussion, someone comes along and thinks, "wait a minute, there's no way that OSI coined that term", but yes, they did. This is probably a Mandela effect.

https://en.wikipedia.org/wiki/Mandela_effect

You missed the hyphen in Caldera's "open-source", clearly linking them into a single term.

Well then. I guess you found the one instance of it happening. It was very rare and essentially unheard of.

For those of us that may have never learned those lessons, could you perhaps share what they were?

Basically, (1) software licenses matter, if not not today then tomorrow, and (2) just because you think the language sounds clear doesn't mean that a judge will agree with you.

You can also see this in the evolution of several licenses that have gone through more than one version. While I really hate comparing software to licenses, think of those as "bugfixes" (or perhaps, warnings to others of bad example licenses). I already gave GPLv1 and the original Artistic License as what not to do; Apache v1 is another example because of patents.

Apache also has some weird stuff about needing to clearly mark modifications to the code that frankly feels a little unneeded.

I wonder if a revision control system like Git obviates this problem, so long as you make clean patch merges.

I think that is the assumption. I’ve never encountered a change list of files on Github.

I still find it to be an odd requirement. I guess the intention is to keep people from misrepresenting your original code.

> but legal complexity is inherent in human affairs and cannot be simplified too much.

Legal systems are systems constructed by humans just like software and also contain complexity by cruft. Our law concepts are based on Roman law. For instance ownership was designed in a way to also deal with ownership over your wife and kids, slaves and debt peons.

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.

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!

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.

They are experts, we are not.

Here's a scenario: you're an IT guy, not much of a programmer. You need to do some weird data processing on 10,000 MBOX archives and you can't mess it up because there's important corporate data in there, although if you did mess up nobody would probably notice for 5 years. Just because programmers disagree on software architecture doesn't mean you shouldn't have a programmer look at your code before you try to run that Perl script.

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

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

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

It's a noble goal, some thoughts on the license.

I really wish it made clear that the license was irrevocable. I think the understanding in the community is that once you give permission for software to be used under a license you shouldn't go back on that, but other licenses, like Apache, make that clear.

The phrase "Any modification to the software submitted to the authors may be incorporated into the software under the terms of this license." could be worded better. I think Apache nails this, "Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions". This gives some wiggle room for submissions under different license, if they are explicitly called out.

Thanks for the thoughts. I considered those two issues in the drafting — revocability, and contributor submission licensing — but they can certainly be discussed further.

Do you mind opening a ticket on the Github repo to discuss them? (If you don't have time, I might do it.)

Yeah no problem

If it's a simple permissive license with patent grant, what's the advantage over BSD-2-Clause-Patent (https://opensource.org/licenses/BSDplusPatent) ?

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.

Are you really bothered about corporations not being able to use your code? Corporations generally make money from code without paying for it, which ranks them very low on my list of people to cater to with my licenses.

I want my licenses to cater to hobbyists/hackers/tinkerers and maybe small businesses first, if corporations don't like it they can pay me to relicense things for them.

When I'm choosing a library to use for a personal project, I do put some consideration if I'm likely and would be able to use it at work. If I end up contributing to the library (and I have), it's nice to be able to use the one with my own contributions in it at work as well.

That may be true, but with that attitude, we'll all still be using MIT in 2047.

The hope here is for it to become a standard license in short order, if people find it useful. That includes SPDX submission, OSI approval, and then inclusion in Github's licensing apparatus.

Specifically, I'd like to think that corporations would find it significantly more comfortable to use software under LIL than under MIT: They won't have to worry as much about unknown patents held by the authors, and they won't have to worry about future legal disputes with third-party contributors. Both of those are significant issues today — this very week, even.

That said, if you want something permissive, but lawyered-up and bulletproof, use Apache. This isn't intended to compete with Apache. It's intended to compete with what folks actually use and love, which is MIT.

I have seen many games with license text that says things like "We asked and got permission from the author". You don't get any more nonstandard than emailing some author and getting permission, yet it seems fairly common in even AAA games.

So let me theorize why that is. Game studios is always short on time, short on developers, and short on money. If doing something nonstandard will save you days/weeks/months of developer time, that is features and bug fixes that otherwise might never be done. There is no room to be religious about which license the #38 library that you use as long it don't conflict with the business model of developing and selling games. Only industries where competition is slower and there is a disconnect between development and revenue can people care strongly about having only licenses they like.

Plenty of corporations use non-standard licenses, seeing as how pretty much every non-FOSS license out there is non-standard (and in the case of enterprise software, often not even standard across every instance of a given product).

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?

A basic thing to consider about WTFPL is that it's essentially equivalent to public domain, which doesn't exist in some countries, making your software unusable in those countries. Developers seem to love this license because it's cute, short, and uses foul language, but it's a license that no one should use.

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.

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

Is the JSON license allowed?

That's a shame. Kudos to them for trying to improve the MIT license, and for explicitly incorporating a contributor license agreement.

However, it would probably behoove them to actually get an actual lawyer to take a look at the license, if only to have some kind of up-front certification for adopters that the thing won't get them sued or taken advantage of. There are several changes from the original MIT language that indicate they might not know what they're doing any more than your average Hackernews. For instance, putting warranty disclaimers in all caps is common practice and it's done for a reason [0], but they evidently didn't bother to search "warranty all caps" on DuckDuckGo and decide "you know what, it's fine, we can live with an all-caps clause." To my untrained eye, it looks fine, but who knows what might cause it to get torn up in court. Which of course proves your point: no corporation will use a LIL licensed project at least until it's been vetted or tested or reviewed somehow.

Lil license:

Permission is hereby granted by the authors of this software, to any person, to use the software for any purpose, free of charge, including the rights to run, read, copy, change, distribute and sell it, and including usage rights to any patents the authors may hold on it, subject to the following conditions:

This license, or a link to its text, must be included with all copies of the software and any derivative works.

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

The software is provided "as is", without warranty of any kind, including but not limited to the warranties of title, fitness, merchantability and non-infringement. The authors have no obligation to provide support or updates for the software, and may not be held liable for any damages, claims or other liability arising from its use.

Expat license:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[0]: http://www.partingthoughts.net/why-are-warranty-disclaimers-...

A couple of lawyers looked at it — but of course, their opinions varied. None took issue with the normally-cased warranty disclaimer.

But I certainly did think about it before using lowercase. The reasoning is this: The Uniform Commercial Code requires language opting out of implied warranties to be "conspicuous". In short, you can't bury the warranty disclaimer in the fine print. In a dozen-page long plain text license, putting the disclaimer in all caps might be a way to try and make it conspicuous. I enjoy Kyle Mitchell's take on this:

"Lawyers have long suffered under the delusion that writing anything in ALL-CAPS meets the conspicuous requirement. That isn’t true. Courts have criticized the Bar for pretending as much, and most everyone agrees all-caps does more to discourage reading than compel it."

In the Lil License, the warranty disclaimer is in normal type because the license is short, and it's meant to be read. It's a conspicuous part of the license. You noticed it right away ;)

Thanks for the reply. Good to see this isn't a fly-by-night HN karma grab.

You might want to mention that it's been vetted and that you did in fact put some serious research into it. From the tone of the FAQ, it sounds like you and your buddies drafted this over beers on a Thursday night or something.

Thanks for the suggestion. I was trying to be friendly with the tone of the FAQ. Perhaps too friendly. I'll try to make the drafting process more clear.

Indeed, it's a tactic.

Good to know, but for 99% of personal open-source projects on GitHub I think that really shouldn't matter.

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.

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

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.

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.

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

More here:

https://medium.com/licensezero/a-hacker-public-license-d2805...

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.

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?

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

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.

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?

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

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.

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

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

  > 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

  > 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

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

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.

So Lil is basically either

MIT + Patents Grant

Apache 2.0 but much simplified in wording and length.

Am i correct in the grand overview?

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

http://copyfree.org/content/standard/licenses/coil/license.t...

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.

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?

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.

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

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

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!

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.

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.

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

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

The 'software' is what is provided by the original author(s), and the rest refers to the patents held on 'it'.

What you describe would be a 'derivative work', as mentioned in the second paragraph.

It might be clearer if it was capitalized like in the MIT license, but I think it's pretty clear as it is.

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

I think the question is: What if the author has patents A, B and C, but the original code only uses A and B, and you modify it to use patent C as well? I guess it doesn't apply for derivative works unless the author incorporates the changes in the distribution of the code.

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.

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.

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

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

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.

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

What did your lawyers say?

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.

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) will take a crack at this one soon. If it shows up on their list, I can see adoption ramping up.

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

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

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

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.

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.

Their needs and goals are open source (sic) software.

Unsolving this problem would be self-defeating.

Is this the opposite of react native license?

Gray on gray text... Just why?

Obvious XKCD is obvious: 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.

Why not CC0?

The Lil license seems to have a patent grant [1]:

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

And CC0 does not [2]:

> No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.

That appears to be the motivation of this over other existing, minimal licenses.

[1]: http://lillicense.org/v1.html

[2]: https://opensource.stackexchange.com/questions/133/how-could...

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.

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

Nevertheless, I've noticed CC0 used by crypto stuff lately (keccak, Argon2).

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.

Reply on news.ycombinator.com