LLVM Relicensing Effort
llvm.org
llvm.org
> As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
> In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.
That is intended to mean that if the compiler copies in some binary code (to implement a compiler primitive or the like), that it doing so does not require you to treat that code like it is licensed under the LLVM terms.
Note that the LLVM source code is not "your source code", so simply copying in the LLVM source and compiling it will not trigger this exception.
That is not to say that there might not be a loophole. E.G., modifying LLVM to always copy all of its binary code into the resulting exececutable (and licensing those changes under this license), and then compiling a program that wants to embed LLVM. I'd like to think that courts would refuse to allow such abuse, but who really knows.
[1] e.g., code to implement a 64-bit division operation on platforms that don't have an instruction for that.
Maybe?
Theo de Raadt: https://news.ycombinator.com/item?id=12617881
These objections have been largely glossed over by the LLVM community. It's no secret that a handful of corporations are pushing for this change, and not the best interest of the open source community. Especially the larger ones using LLVM, like *BSD. LLVM is already under a permissive BSD-like license (NCSA), as pointed out by jwilk: https://news.ycombinator.com/item?id=18700258
OpenSSL is similarly attempting the same thing with newer versions of OpenSSL, which they went about in a particularly legally dubious way: https://lwn.net/Articles/717996/ (For context, OpenBSD maintains LibreSSL).
"In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law, which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict."
From what I recall, Apache httpd 2.0 came out a long time before Apache License 2.0. A quick check of Wikipedia confirms it:
> The Apache HTTP Server codebase was relicensed to the Apache 2.0 License (from the previous 1.1 license) in January 2004, and Apache HTTP Server 1.3.31 and 2.0.49 were the first releases using the new license.
If OpenBSD wanted to use httpd 2.x without switching to the new license, they could have forked 2.0.48. Their reasons for not using httpd 2.x were entirely technical. Architecturally, 2.x was a major departure from 1.x, and the OpenBSD developers were grognards who rejected it because they weren't interested in a web server that deviates from tradition. And since Apache still maintained 1.3.x for ages after 2.0 came out, it made their decision easier (well, until the license change hit).
And this is a huge digression anyway: I honestly don't see a reason to cater to a group of people who would cut off their nose to spite their face. The LLVM team has better things to do with their time.
nginx was initially considered, but the upstream wasn't receptive to patches that OpenBSD worked on, including a chroot(2) support and security patches, i.e: reallocarray to protect against arithmetic overflows. At the time, Nginx cared more about it's Nginx PLUS offering and less about the community.
That doesn't seem like a fair description of what happened. I think it was more that the OpenBSD project didn't want Apache 2.x in the base system, and thought that if people wanted it they could get it from the package manager. There might also have been some licensing issues in the sense that they'd prefer no Apache license at all, but that was apparently secondary to the changes in Apache code that contributed to the decision.
It also comes with some weird bookkeeping issues, like having to mark changed files in ambiguous circumstances, and requirements for how a file with a particular name (NOTICE) must legally be treated. These kinds of things can add to the burdens involved in building derived works, maintaining modified forks, or borrowing code.
This is not actually true, and needs citation/data.
This is actually the foundation trying to keep peace, and in a good way.
"and not the best interest of the open source community"
And this is an unsourced assumption of bad faith.
It's also demonstrably false.
It's stated as much in the initial proposal.
"1) Some contributors are actively blocked from contributing code to LLVM."
> These contributors have been holding back patches for quite some time that they’d like to upstream. Corporate contributors (in particular) often have patents on many different things, and while it is reasonable for them to grant access to patents related to LLVM, the wording in the Developer Policy can be interpreted to imply that unrelated parts of their IP could accidentally be granted to LLVM (through “scope creep”).
Also, you elided the other 2 large reasons given, which don't support your point at all.
For example, GCC has an exception for its runtime libraries that it now applies universally for the exact same reasons - desire to share code, etc.
It has that problem even reusing code from other GNU projects as well!
You were saying?
I happen to know because I was one person who donated my time. I was not in any way blocked. We were trying to find a way to help more people (and yes, companies, because companies tend to pay people) contribute to LLVM because that is one of the things that makes the project stronger.
So saying that the change was driven by these handful of contributors seems really off base. And in fact, my experience during the process was that the most motivated people were individual contributors, if anything pushing and pulling companies along (by finding good ways to address their potential concerns with any change like this).
Anyways, that was my experience from being involved in the process. YMMV of course.
It would be unlikely for any open source project to begin such a massive undertaking to re-license, from an already permissive license, without at least some corporate incentive/initiative to do so. No doubt lawyers were paid.
I understand what you're saying, but it is also being disingenuous.
Except it's not, since the community was the one who desired those contributions in the first place.
Seriously. You are going off making a lot of assertions without knowledge, evidence, or data.
Truthfully, if this is how the community you belong to operates, i'm somewhat glad they will no longer use LLVM.
That's a pretty uncharitable interpretation. The reality is there are companies who want to upstream their changes, but can't given the current license.
It's better for the community as a whole if more people/teams contribute their changes back, and that would be one of the benefits of the relicense.
It is a privilege as a community member to be able to be paid to work on a project like LLVM. I'm so grateful the community has such a healthy relationship with both academia and corporations.
Many community members at the yearly conference mention that they have custom patches that they can't upstream because of licensing issue. Improving this means to me that we can extend the community and make it stronger.
Of course, you are off asserting a whole bunch of stuff with no data or knowledge, so i don't think that will stop you.
Additionally, you keep asserting/repeating it's "not for the benefit of the community at large" or "in the interests or desire of the community".
Can you please cite any evidence of that?
No, it's a reasonable interpretation of a definitive open-source project pushing back hard.
It's also one portion of an example of people disagreeing about what's best for "the community", or in other words an example of where politics comes from. And you're showing another angle on that, which is people assuming the worst of eachother.
[1] http://lists.llvm.org/pipermail/llvm-dev/2018-December/12860...
(He worked for Google for a while while working on LLVM, etc).
It's (a BSD-like) University of Illinois/NCSA Open Source License:
Sure, apache 2 has the patent stuff, but I fail to see how anyone would object to it.
OpenBSD is objecting to it like so[1]:
> [...] In particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent.
> A license can only be considered fully permissive if it allows use by anyone for all the future without giving up any of their rights. If there are conditions that might terminate any rights in the future, or if you have to give up a right that you would otherwise have, even if exercising that right could reasonably be regarded as morally objectionable, the code is not free.
> In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law, which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict.
FWIW, this is really the only strong objection we've heard to the overall direction of this change.
.. You might think that objection would be listened to more readily, or do the interest of a handful of corporations hold greater weight?
OpenBSD will undoubtedly be forced to fork LLVM 8, and likely have to take on the burden of asking individual developers to dual-license contributions they backport going forward. This will place them in a similar position they had with GCC, since the GPLv3 license change.
[0] https://github.com/openbsd/src/commit/e688c2b0648a80551cf735...
[1] https://github.com/openbsd/src/commit/9866f44de26a847eaed067...
[2] https://github.com/openbsd/src/commit/c0f0c565f0b312e55b410b...
Mark Kettenis formal rejection on behalf of the OpenBSD project: http://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.h...
We did listen, but we have specific goals that after a great deal of discussion are best addressed with the approach of the Apache 2 license. The objection was to those goals in many ways, not to the particular mechanisms.
And we really did listen to the concerns about the goals (specifically providing strong protection against patent issues) but there was strong consensus in the community that this was a real problem we wanted to address, and so we moved forward.
I am truly sad that this will cause issues w/ the OpenBSD community, but we had consensus and needed to make progress.
I'm not entirely sure how patent grant drags in contract law, though. It might be the fact that it implies reciprocal patent grants. You might have to ask a lawyer for the distinguishing issue here.
The reason for relicensing were to do with Patents.
Do ALL Patents have be under Contract law and not under Copyright law?
Or it is actually possible to have a license that fits the spirit of BSD, with GPL compatibility while having patents protection without the objection of OpenBSD ideals?
AFAIK, whether ISC/BSD/MIT style licenses offer a patent clause is still unsettled.
UPDATE: See JoshTriplett's post, Apache-2 has license compatibility issues that prevent some code reuse, now I think BSDplusPatent license instead of Apache-2 is a better idea for small programs.
Another good choice is https://opensource.org/licenses/BSDplusPatent , which combines the 2-clause BSD license with the explicit patent clause from Apache 2.0. That gives you GPLv2-compatibility as well.
(Note that this is unrelated to the unfortunately similarly named license from Facebook, which is not a FOSS license.)
I was always searching for this license, but I had previously only found The Clear BSD License, the BSD license with a PATENTS-NOT-INCLUDED clause (oops), and the Universal Permissive License, which is a general permissive license WITH a patent clause, but too obscure to inspire confidence among other developers.
Now I'm going to recommends BSDplusPatent instead of Apache 2. Simply and clear.
Please elaborate.
Firstly, AFAIK all of the licenses that ALv2 is incompatible with are obsolete and superseded versions.
Secondly, the ALv2 is file-scoped, so you can typically combine a library licensed ALv2 and another one with an incompatible permissive or weak copyleft license.
In practice this means that you'll have a problem combining ALv2 with old versions of strong copyleft licenses, e.g., something licensed GPLv2-only.
This is certainly an issue to consider for a project like LLVM, but of lesser importance for the majority of smaller scoped libraries.
What is it missing?
Personally, one of my favorite things about Apache 2.0 is the license doesn't include any references to the copyright holder or year, so the exact same license text can be used everywhere, so if you have 20 dependencies all covered by Apache 2.0 you only need 1 copy of the license text rather than 20 nearly-identical copies.
One thing that I keep pointing out is that the Apache provides a way for the license to be self-executing. This is really cool (although also one source of objections) and IMO super important for an Open Source project like LLVM. It avoids the need for us to force every person who ever posts a patch to sign a legal agreement before we incorporate the patch because the Apache license itself handles those kinds of issues.
Unfortunately, we wouldn't get that w/ a dual-license approach. And we would add a lot of complications due to the duality. =/
> Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be dual licensed as above, without any additional terms or conditions.
immediately after the section for the licenses, though I have no idea if this is remotely enforceable. Though it hardly matters, as while my libraries have users, they don't generally get pull requests.
The same Heather Meeker that started the whole "let's relicense FOSS projects with confusing non-FOSS licenses because we don't like that AWS is using our code"-buzz that's been debated a lot lately.
I'm not sure how that's a contradiction. Of course she can start something while doing her job.
Evidence: https://commonsclause.com/ "The Commons Clause is a license condition drafted by Heather Meeker" https://techcrunch.com/2018/11/29/the-crusade-against-open-s... "Heather Meeker wrote both solutions, supported by feedback organized by FOSSA."
This also means that if we gave her really bad direction (for the community or project), she would also be fantastic at it. The fault there lies in the direction, not the legal advice.
Depending on what she is doing some people have moral objections to her work (as you appear to), and to what they see as moral flexibility on her part.
But in the end she is a great lawyer who understands this stuff very well, and tries to help her clients understand how to achieve their interests/goals.
That is very separate from whether those are good goals/not.
* Encourage ongoing contributions to LLVM by preserving a low barrier to entry for contributors.
* Protect users of LLVM code by providing explicit patent protection in the license.
* Protect contributors to the LLVM project by explicitly scoping their patent contributions with this license.
* Eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them.
* Ensure that LLVM runtime libraries may be used by other open source and proprietary compilers.
Is it because the other license is relatively unknown? Can anyone shed light on why they didn't opt to go for BSD or MIT license? (is it the patent protection stuff?)
In particular, the Apache license is a very clear and more importantly very well-accepted mechanism of licensing relevant patents and not irrelevant ones. The BSD and MIT licenses may or may not license patents depending on how you (or the courts, really) interpret "Permission to use ... is hereby granted ...."
They also had a custom scheme for dual-licensing the runtime libraries that get linked into compiled binaries. The new scheme grants a non-attribution license based on the fact that it ended up in your code after running clang, not which repo it was in, which makes it easier for LLVM to refactor code between repos.
And as the other responder mentioned, part of this has involved directly contacting all committers in the last two years (more recent committers more than once) to ensure we have everything we need to minimize disruption and make the cut over.
It might be a communications issue, that users of the downstream might assume they won't get sued by you. If such users have money, they should hire competent legal assistance.
> The requested URL /LICENSE.txt was not found on this server.
It does indeed. It was mostly non-controversial, except for [AFAIK] one notable departure, de Espindola [1]. Lattner's response [2].
> ... new open source CoC whose mere existence is a violation of itself.
I can't tell if you're just being silly or if you're referring to an actual contradiction related to relicensing and/or the CoC.
[1] http://lists.llvm.org/pipermail/llvm-dev/2018-May/122922.htm...