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