For those out of the loop like me, the Apache 2.0 license exceptions they are addding are:
> 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.
Sorry, but I have trouble understanding such legalese. Can someone please translate this into more common language? Thanks! I do not want to guess what this could mean.
The first bit says effectively "this doesn't apply to compiler libraries [1] we link into your code". The second bit effectively says "you can use this with GPLv2 code" (normal Apache v2 only is compatible with GPLv3).
[1] e.g., code to implement a 64-bit division operation on platforms that don't have an instruction for that.
It looks like the first bit might also imply that you can use LLVM as the basis for a JIT compiler without having to license your code as Apache 2.0 or include the attribution notices.
No, that would not be "as a result of compiling", but you can do that anyway (with attribution and patent though), as incorporating Apache code into other code is fine in general.
Doesn't this just allow an end-run around the license by allowing you to distribute a program that embeds LLVM, whose only purpose is to be an LLVM wrapper to avoid those sections of the license?
What it allows is portions of the compiler runtime library to be embedded into your program without changing any licensing effects of your program. GCC has a similar exception to their GPL for similar reasons.
I'm pretty sure the intention is that it does not allow that. Notice that they say "as a result of your compiling your source code".
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.
It's blurry to me what it mean for including a libc++ header though? This is not "your source code" but LLVM inline code. How is it different from including a header from LLVM itself?
Anything which might get some runtime artifacts from the compiler. For instance some compiler intrinsic called from your code might use some code the compiler injects instead of only translating your source to opcodes.
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).
"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”).
The interesting thing is that the vast majority (and for the first year+ all) of the contributors to LLVM who donated massive amounts of time and resources to make the relicensing happen were not from any company that was blocked from contributing.
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.
That doesn't change the reasons stated in the proposal email. Even if the final legwork was orchestrated by individual contributors, it's clear that the reasons were to appease corporations and not the community at large.
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.
"That doesn't change the reasons stated in the proposal email. Even if the final legwork was orchestrated by individual contributors, it's clear that the reasons were to appease corporations and not the community at large."
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.
> it's clear that the reasons were to appease corporations and not the community at large.
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 seems like you're making a dichotomy between corporations and the community. However corps are a big part of the community! They are leveraging LLVM in many different products, and individuals in the community are frequently paid by various companies to work on LLVM to improve these products.
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.
I assume you intended that as a personal swipe. That's not ok on HN, regardless of how strongly you feel about a topic. Please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here.
So I guess that's a no.
It was fun discussing it with you anyway. I do hope next time you choose to try to paint others in bad faith, you have a bit more evidence and a bit less conjecture.
Or just stop assuming bad faith and try to understand other perspectives than the one you have.
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.
de Raadt's scenario about submitting no-signoff content has already happened: de Espindola doesn't agree [1]. Though this was probably predictable given his objections raised before his departure. Presumably the foundation has a plan for resolving this problem.
Honestly, if a project is so blinded by zealotry that even a non-copyleft license like Apache 2.0 isn't free enough, then I don't see any reason to engage with them in any form.
This isn't a new policy. It's largely the same reason OpenBSD shipped with a fork of Apache 1.3.x for many years before ultimately writing their own httpd(8). The Apache 2.0 intertwines US Contract law with Copyright law, and that is considered wholly "not permissive enough".
"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."
> This isn't a new policy. It's largely the same reason OpenBSD shipped with a fork of Apache 1.3.x for many years before ultimately writing their own httpd(8).
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.
You're correct that were architectural reasons initially for why Apache httpd 2.0 not considered, but the license also played a significant role in later years, when it became obvious that Apache 1.3.x was showing its age.
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.
> the OpenBSD developers were grognards who rejected it because they weren't interested in a web server that deviates from tradition
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.
Licenses that have legal compatibility problems with other licenses are problematic. In fact, that's one of the reasons copyleft licenses are problematic: legal incompatibility with many other licenses. In that respect, AL2 is as problematic as some copyleft licenses.
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.
huh. I assumed it was already Apache 2 and they were adding an exemption. This does change the reading quite a bit. They're asking all their contributors for a pretty big relicensing.
> [...] 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.
And considering all the interesting work that OpenBSD is doing to Clang, i.e: retguard [0] [1], ROP gadget reduction framework [2]. Ignoring the fact that two major open source *BSD operating systems use and ship LLVM/Clang as their default system compiler. Their entire system compiled with clang, LLD as the default linker for an increasing number of supported platforms. A ports tree with between 10,000 (OpenBSD) to 30,000 (FreeBSD) ports compiled with Clang, maintaining patches upstreams won't take..
.. 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.
FreeBSD is OK with the license, so AFAIK, it is just OpenBSD.
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 think I know what you mean when you say "consensus" here, but that's not what "consensus" really means. Perhaps you want a word more like "majority".
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?
The last objection doesn't make any sense. This is a license, so it is a grant of rights under contract law no matter what rights are granted or terminated. If you sue someone for breach of copyright, inevitably the case will be "dragged into contract law" if the defendant claims to have a license to the copyright. I don't believe there is a distinction between patent and copyright here, as a grant of either via a license is a contract.
Software licensing is not necessarily related to contract law. Many software licenses do not fully qualify as contracts, because they are just a grant subject to qualification, rather than an (assumed) agreement between parties about terms of exchange or something to that effect.
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.
Although Apache-2 is sometimes seen as a license-of-choice by major proprietary software companies like Google, the license itself is actually well-written. It explicitly offers a patent clause to protect contributors and distributors from patent lawsuits from the copyright holder. I found even RMS recommends using Apache-2 as a permissive license for minor programs that don't need copyleft. So unless you explicitly support BSD/ISC, perhaps you could give some consideration of using it as a license for your next program.
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.
Apache 2.0 is not a great choice if you care about license compatibility, unless you include an exception as LLVM is doing here.
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.)
IMHO the license incompatibilty problem is rather minor:
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.
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.
FWIW, Apache2 has other really useful aspects such as being self executing. We looked at options very similar to BSD w/ a patents clause and they ended up being less good on several fronts. Of course, YMMV, this was specifically in the context of LLVM.
From having dealt with some legal departments in the past, the reason they like these licenses is that they create clarity. For them patents are an orthogonal issues. Having licenses that may or may not affect their own patents or any patents of their competitors is hugely important when considering whether to use particular software, whether to contribute to particular software, etc. At the minimum, it increases the workload for them and worst case there are all sort of things that suddenly have to be considered. Doing legal checks is super tedious.
My personal license choice at the moment is to dual-license my work under both MIT and Apache 2.0. This way the user can decide which license to use.
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.
FWIW, we definitely looked at a dual-license style approach.
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. =/
I didn't actually realize Apache 2.0 was "self-executing". That's pretty neat. My usual tactic is to just have a section in the README that says
> 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.
FWIW, Microsoft used to prefer AL for its open source projects early on in its F/OSS forays (after experimenting with its own custom licenses), but has since moved to MIT as the default.
TypeScript has a similar problem, where depending on some compilation flags you end up inheriting their license on your compiled output. I've been trying to get them to fix it but it is stuck in lawyer limbo:
I just want to say, it's slightly mind-boggling to see two Googlers on a thread talking about how to adapt legal work done for a mostly Apple-owned project to improve the licensing of a Microsoft product.
This looks mostly harmless, yet this made me pause: "The effort has been overseen by Heather Meeker".
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.
Heather is "just" a (fantastic) lawyer. She isn't providing the "here is what would be good for the project" direction, the community and the foundation are doing that. She is helping ensure that we understand the legal implications and requirements of achieving the direction set by the community. And she does (IMO) a fantastic job of that.
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.
As i've mentioned in other threads - Heather is a hired gun.
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.
It's not really surprising that companies wanting a new software license hire a world-class expert in the field to help draft it. Any evidence she "started the whole..." instead of doing her job as a lawyer?
I have trouble making sense of your words, but the question is whether Meeker started this trend—as in, personally decided this would be a good thing and convinced people to accept it—or simply happened to be the lawyer for others who started that trend.
Wouldn't you say the companies that asked her to help create these licenses "started it"? I think for the question if another effort is suspect just because it involves her the source of the motivation is IMHO relevant.
The TechCrunch article you linked indicates that it's the article's author, Salil Deshpande, who's responsible for the Commons Clause. Heather Meeker was just the lawyer tapped for this.
Can someone explain how the current licence is a problem for the following:
* 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.
It's why the D language is all Boost licensed. We would have made it public domain, but that isn't a legal concept in some countries. Boost is the closest we could find to public domain and corporate lawyer approved.
We are successfully moving towards the next bug milestone which will put the new license in place going forward. This is likely among the most potentially disruptive steps as we need to ensure subsequent contributions are under the new license (additionally). We're targeting mid January pretty firmly now to make the cutover. We'll be sending a detailed message to the LLVM lists about this today.
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.
I don't understand how licenses that make claims about patent lawsuits (GPLv3, apache) can be re-using code from licenses that don't make patent claims (BSD, etc.). I didn't promise not to sue anyone for royalties.
Their license doesn't bind your behavior, since you didn't release your code under that license. However, it is probably the case that your code was also not released under any license that forbids reuse by a downstream that does make patent promises. (Does such a poison-pill anti-patent-promise license even exist? I'm not aware of it.)
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.
I misread this this morning, thought this was a backdoor for tivoization, which I am strongly against, and made a too hasty and terse comment, so I really have to eat crow. Sorry everyone.
I wonder if LLVM has a code of conduct? It would be an interesting project to develop a new open source CoC whose mere existence is a violation of itself. :-)
> 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.