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