4 ms·

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 a

by lambda 10y ago

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

StreamBright 10y ago
Thank you very much for the detailed description. Makes sense now.
saurik 10y ago
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.)
- drewcrawford 10y ago
  "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
  - cyphar 10y ago
    > 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).
    - drewcrawford 10y ago
      > 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 https://www.gnu.org/licenses/quick-guide-gplv3.html
      - cyphar 10y ago
        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-agreements https://www.redhat.com/en/about/red-hat-end-user-license-agr...
- lambda 10y ago
  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.

by lambda 10y ago

StreamBright 10y ago

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

saurik 10y ago

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

drewcrawford 10y ago
"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
- cyphar 10y ago
  > 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).
  - drewcrawford 10y ago
    > 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 https://www.gnu.org/licenses/quick-guide-gplv3.html
    - cyphar 10y ago
      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-agreements https://www.redhat.com/en/about/red-hat-end-user-license-agr...
lambda 10y ago
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.