LLVM wants to switch from a BSD-style license to Apache 2.0, with a few exceptions, one allowing use with GPLv2 code, another allowing the bits of compiler-rt and other components that get built into binaries to be redistributed without restriction.

The main benefit of Apache 2.0 is that it includes a patent grant as well. Right now, LLVM relies on a custom "developer agreement" for anyone who contributes code that includes a grant of patent rights, but it's kind of vague and fuzzy and so makes it hard for some people to contribute, and the license itself doesn't actually mention patents at all:

http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536...

Theo objects to any license that applies more restrictions than the original BSD license. OpenBSD makes an exception for GPLv2 licensed utilities that have been traditionally shipped with BSDs that there's not a good replacement for, but has stopped upgrading things that have moved to GPLv3 and apparently objects to the Apache license as well.

The existing patent agreements seem to make the current license not comparable BSD but instead comparable to an awkward or even apparently extreme Apache 2.0, so isn't this about in practice removing restrictions, not adding restrictions? (This thought process is backed up by their stated reasoning and the kinds of contributors that are supposedly complaining.)

"Additional restrictions" can be funny. You may recall the FSF's position that the app store EULA placed "additional restrictions" on the GPL, a position that was and remains controversial.

In this case, it is a little harder to understand OpenBSD's interpretation of additional restrictions because they haven't listed their objections in any centralized place, but from reading around, they seem to believe:

* "You must cause any modified files to carry prominent notices stating that You changed the files" is an additional restriction * "any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License" is an additional restriction * The sheer length and complexity of the Apache license suggests to them there are other additional restrictions buried in there somewhere

> You may recall the FSF's position that the app store EULA placed "additional restrictions" on the GPL, a position that was and remains controversial.

I don't think that the position was contraversial, I just think that people took it the wrong way. The Apple EULA objectively has clauses in it that state that users must follow the "acceptable usage policy" and it is enforced regardless of any external agreements -- this would mean that Apple would be violating the GPL if they distribute any GPL software in their store.

You can add additional terms that permit distribution in the Apple store (as Signal has done), but the stock GPL does not permit distribution in the Apple store because the "acceptable use policy" is one of the things the GPL was made to fight against (the idea that users must act in an "acceptable" way to Apple when running software on their own computing devices).

> The Apple EULA objectively has clauses in it that state that users must follow the "acceptable usage policy" and it is enforced regardless of any external agreements -- this would mean that Apple would be violating the GPL if they distribute any GPL software in their store.

And Red Hat EULA objectively has clauses in it that you may not redistribute RHEL.

There is a slippery slope here, the FSF has decided for whatever reason that RHEL's restrictions "weren’t really restrictive, because they were so easy to comply with" [0] but there is really nothing "objective" about that determination.

[0] https://www.gnu.org/licenses/quick-guide-gplv3.html

You're being a tad disingenuous here. RHEL's EULA[1] is basically the same as SLE's, openSUSE's, Ubuntu's and so on. It only states that you are not allowed to use the RedHat trademarks when you redistribute RHEL -- and since RHEL (and the other distributions I mentioned) puts all of their trademarked components in a single "branding" package then it is not practically restrictive to make such a requirement. RHEL has no requirement that you cannot distribute some software (in fact, the distribution is under GPLv2 much like openSUSE and SLE).

Apple's EULA restricts users to only being able to use software they distribute under their "acceptable use policy". This is simply a violation of the GPL, with no wiggle room for discussion.

[1]: https://www.redhat.com/en/about/red-hat-end-user-license-agr...

The existing patent agreements are a contributor agreement, not part of the license. So, they restrict people from contributing, but don't actually provide any guaranteed protection for downstream users, as far as I can tell.

However, I'm not a lawyer and not involved, was just trying to summarize as well as I could, so I could be wrong.

Thank you very much for the detailed description. Makes sense now.

It's not very clear to me either, this seem to be it: http://programmers.stackexchange.com/a/263232/12944

LLVM is considering switching to the Apache 2.0 License.

As a matter of policy, OpenBSD does not ship software that uses the Apache 2.0 License.

It's not entirely clear why that is their policy, but it seems to come down to some combination of the patent clause and the additional complexity of the license.

> It's not entirely clear why that is their policy

> The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. (http://www.openbsd.org/policy.html)

Right, which is clear as mud and not really an explanation. It's roughly equivalent to just saying they don't like the license.

According to the link I posted their goal is to publish OpenBSD under the terms of the original BSD license (so 2-Clause BSD, 3-Clause BSD, MIT, ISC, etc. are all fine).

The Apache license v2 is more restrictive than BSD-style licenses so they can't include code licensed under it.

Its not clear that there is any legal restriction on them doing so.

In the sense that it would be perfectly legal for them to include Apache v2 licensed code? What in the world would restrict them from doing so? They can include Apache v2 code, GPLed code, proprietary code, any code they want, really. Their goal however is to build an OS that can be used under the terms of a BSD-style license similar to Debian's goal to build an OS that is "free."

But if they're already shipping GPLv2 code then they've already failed at this goal.