Chris Lattner via llvm-dev
2016-Sep-12 16:16 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
Hello everyone, This email is a continuation of a discussion from almost a year ago, started back here: lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html As described in that email, this is a complicated topic and deals with sensitive legal issues. I am not a lawyer, and this email is not intended to be legal advice in the formal sense. That said, I have spoken with many lawyers about this, and the LLVM Foundation hired Heather Meeker (a prominent OSS licensing attorney) to represent the interests of the LLVM Community. This proposal incorporates all of their feedback, and Heather has further refined and approved this approach. The goals of this effort are outlined in the previous email but, in short, we aim to: - encourage ongoing contributions to LLVM by preserving 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. Here we are discussing what the best end game is -- not the logistics of how to get from here to there. The email from last year proposed relicensing the LLVM project under the Apache 2 License, and using a runtime exception clause to avoid the binary attribute requirement of the Apache 2 license. The advantage of this approach is that it avoided developing an entirely novel license (which would introduce problems outlined in the original email), it keeps the liberal nature of the LLVM license (you can take and use it for lots of different kinds of projects without being required to publish your downstream code), it does not require a “contributor license agreement” (CLA) which would introduce a higher barrier of entry and increase uncertainty for contributors, and it solves the compiler/runtime library schism by allowing us to license everything uniformly under the same license. After extensive discussion on the mailing list (see the archives if you missed it), the community generally agreed with the approach, but had a major concern: Many folks believe the Apache 2 license to be incompatible with the GPLv2 license. This is problem because there are a number of important GPLv2 projects that use LLVM (e.g. QEMU) or projects that are "GPLv2 or later” but which prefer to be used under the terms of the GPLv2 license (e.g. FreePascal). This strong voice inspired us to go back and look for ways to solve this problem. This problem really is specific to GPLv2 (it doesn’t affect any other commonly used licenses), but it turns out that this is a surprisingly difficult problem to solve. For example, many prominent open source lawyers consider the GPLv2 and Apache 2 licenses to be compatible already, which means that there is no problem to solve. The problem for us as a community is that this issue hasn’t been tested in court, and there are other lawyers that believe that the two could be considered incompatible. As such, we recommend taking a pragmatic and conservative approach that defends against incompatibility if it eventually arises, instead of optimistically assuming that they are compatible. After extensive discussion involving many lawyers with different affiliations, we recommend taking the approach of using the Apache 2.0 license, with the binary attribution exception (discussed before), and add an additional exception to handle the situation of GPL2 compatibility if it ever arises. Specifically, this is the proposed wording: ---- Exceptions to the Apache 2.0 License: —— As an exception, if you use this Software to compile your source code and portions of this Software are embedded into the binary product as a result, you may redistribute such product without providing attribution as would otherwise be required by 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. ---- end --- The first paragraph is the exact same one proposed in the previous discussion (addressing the compiler / runtime schism), and the second addresses the GPLv2 concerns. It is structured the way it is for a number of reasons: - We want to conservatively protect the community if the licenses are found to be incompatible. - The LLVM community should not take a position on whether the licenses are compatible or not. - We want to make it clear that the exception only applies if you’re using GPL2 code: if not, you can ignore it. - Allowing retroactive waiving makes it unlikely that an LLVM user could be expected to pay damages (if the two licenses are ever found to be incompatible). In the process of discussing this issue, we considered many different approaches, and I believe that this is the best approach: it provides the compatibility and protection that we seek, and Heather Meeker (legal representative for the LLVM Foundation) has contributed to and approved its wording. With that as background I’d love to hear what the rest of you think: do you have any concerns? If you are yourself a lawyer or work for a company with them, does your legal counsel have any concerns? If you’d prefer not to discuss this on a public mailing list, feel free to email me personally. Once we reach an agreement on the path to take, we can start talking about logistics of how to get there. Thank you! -Chris
Ed Schouten via llvm-dev
2016-Sep-12 17:10 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
Hi Chris, 2016-09-12 18:16 GMT+02:00 Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>:> ---- Exceptions to the Apache 2.0 License: —— > > As an exception, if you use this Software to compile your source code and portions of this Software are embedded into the binary product as a result, you may redistribute such product without providing attribution as would otherwise be required by Sections 4(a), 4(b) and 4(d) of the License. > > [...] > > ---- end ---Just to make sure I get this straight, I can substitute 'this Software' by the names of components provided by the LLVM project. For example:> As an exception, if you use LLVM, Clang and/or DragonEgg to compile your source code and portions of compiler-rt, libc++, libc++abi and/or libunwind are embedded into the binary product as a result, you may redistribute such product without providing attribution as would otherwise be required by Sections 4(a), 4(b) and 4(d) of the License.I've got a couple of questions about this. - Now that we're also in the business of providing other kinds of tools that are not compilers (e.g., LLD being a linker), are we sure that this will cover all of our needs? - What about derived software? Would this also apply if I'd be using the Swift compiler to generate an executable that contains some bits from compiler-rt? What if I'd be using GCC, but added a tiny fraction of LLVM's source code to it? What about a stock version of GCC that is linked against compiler-rt? Sorry if some of these questions may seem hypothetical or silly; I'm merely interested in knowing where the boundary is and how this licensing exception will work in practice. Best regards, -- Ed Schouten <ed at nuxi.nl> Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717
Chris Lattner via llvm-dev
2016-Sep-12 17:58 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
On Sep 12, 2016, at 10:10 AM, Ed Schouten <ed at nuxi.nl> wrote:>> >> ---- end --- > > Just to make sure I get this straight, I can substitute 'this > Software' by the names of components provided by the LLVM project.This is the literal license text that will be included with each of these projects, so no, you cannot literally make that substitution. However, yes, this will cover all parts of the LLVM project including LLVM, Clang, LLDB, libc++ etc if that’s what you’re asking.> For > example: > >> As an exception, if you use LLVM, Clang and/or DragonEgg to compile your source code and portions of compiler-rt, libc++, libc++abi and/or libunwind are embedded into the binary product as a result, you may redistribute such product without providing attribution as would otherwise be required by Sections 4(a), 4(b) and 4(d) of the License.The license specifically does not make a distinction between LLVM/clang and libc++/compiler-rt. You should be able to embed LLVM or clang code into a binary without having to provide attribution.> I've got a couple of questions about this. > > - Now that we're also in the business of providing other kinds of > tools that are not compilers (e.g., LLD being a linker), are we sure > that this will cover all of our needs?Yes, I don’t see anything functionally or use-case different between LLD and Clang or LLDB.> - What about derived software?You need to specify what you mean by derived, I’ll answer the specific questions below to the best of my knowledge. However, it would be great for someone like DannyB to confirm this.> Would this also apply if I'd be using > the Swift compiler to generate an executable that contains some bits > from compiler-rt?Yes, the runtime exception clause covers the code being embedded (compiler-rt) not relating to how it got embedded. FWIW, Swift already uses the Apache 2 license with the runtime exception clause, but that isn’t important for the question.> What if I'd be using GCC, but added a tiny fraction > of LLVM's source code to it? What about a stock version of GCC that is > linked against compiler-rt?Both are fine, the compiler-rt code is covered regardless of how it gets embedded. You could use a fully proprietary compiler like Intel’s ICC and that would also be fine.> Sorry if some of these questions may seem hypothetical or silly; I'm > merely interested in knowing where the boundary is and how this > licensing exception will work in practice.No problem at all, -Chris
Jonas Maebe via llvm-dev
2016-Sep-25 16:43 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
On 12/09/16 18:16, Chris Lattner via llvm-dev wrote:> ---- Exceptions to the Apache 2.0 License: —— > > As an exception, if you use this Software to compile your source code and portions of this Software are embedded into the binary product as a result, you may redistribute such product without providing attribution as would otherwise be required by 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. > > ---- end --- > > > The first paragraph is the exact same one proposed in the previous discussion (addressing the compiler / runtime schism), and the second addresses the GPLv2 concerns.Looks great to me, thanks a lot for taking our (and others') concerns into consideration! Jonas (Free Pascal Compiler developer; just got back from holidays and catching up with LLVM mails)
Joerg Sonnenberger via llvm-dev
2016-Nov-01 19:21 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
On Mon, Sep 12, 2016 at 09:16:47AM -0700, Chris Lattner via llvm-dev wrote:> The goals of this effort are outlined in the previous email but, in short, we aim to: > - encourage ongoing contributions to LLVM by preserving 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.Hi Chris, let me go back to this with some of the thoughts from the last Berlin Social. Ignoring the question of what license to choose, I see three different components mangled together: (1) Coherent licensing between "build time" and "run time" components. This part does need a license change one way or another. (2) LLVM contributors grant permissions to use their patents as far as necessary for their contributions. The desirability of this is unquestionable either. (3) Revocation of copyright and patent use permissions in case of litigation. I think this is the part about a potential move to APSL2 that is most highly contented. I want to make sure that those are the goals used to justify a (potential) license change. I still stand by my position that (2) isn't served alone by the APSL, since it isn't clear who the contributing entity is. A click-thru CLA for individual contributors would server the purpose for those, IMO. For non-natural legal entities as contributors, I still maintain my position that at least under German law a proper legal agreement is necessary to ensure that any obligations are actually enforceable. Joerg
Chris Lattner via llvm-dev
2016-Nov-02 23:01 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
> On Nov 1, 2016, at 12:21 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Sep 12, 2016 at 09:16:47AM -0700, Chris Lattner via llvm-dev wrote: >> The goals of this effort are outlined in the previous email but, in short, we aim to: >> - encourage ongoing contributions to LLVM by preserving 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. > > Hi Chris, > let me go back to this with some of the thoughts from the last Berlin > Social.Thanks! FWIW, if you or anyone else is going to be at the LLVM Dev Meeting and are interested in relicensing, then please come to the LLVM Foundation BoF. I’ll give an update there, and it’s a great place for general questions and discussion.> Ignoring the question of what license to choose, I see three > different components mangled together: > > (1) Coherent licensing between "build time" and "run time" components. > This part does need a license change one way or another.Right.> (2) LLVM contributors grant permissions to use their patents as far as > necessary for their contributions. The desirability of this is > unquestionable either.I’m not sure what you mean by "unquestionable either”. Do you mean "unquestionable good”? If we don’t achieve this, then we run the heightened risk of someone being sued for using LLVM. This isn’t good for the community.> (3) Revocation of copyright and patent use permissions in case of > litigation. I think this is the part about a potential move to APSL2 > that is most highly contented.That isn’t my impression. Everyone that I have spoken to is in favor of the patent termination clauses (including the FSF: gnu.org/licenses/license-list.en.html#apache2). The only complexity I’ve heard is that it introduces is a potential compatibility issue with GPL2 (GPL3 and other licenses are fine), which is addressed by the exception clause.> I want to make sure that those are the goals used to justify a > (potential) license change.There are additional goals. Our current structure is broken in various ways (which I don’t want to enumerate in public), including potential legal issues with patches that come in from people who do not have commit access. If we don’t address these issues, then (in my personal opinion) it would be irresponsible to allow pull requests (assuming LLVM moves to github, which is still up in the air of course).> I still stand by my position that (2) isn't served alone by the APSL, > since it isn't clear who the contributing entity is. A click-thru CLA > for individual contributors would server the purpose for those, IMO.A CLA was carefully considered and has numerous problems depending on which one you’re talking about. The most common proposal is to use an Apache CLA (aka Google CLA), which introduces several problems we discussed in the relicensing round a year ago: it increases the barrier to entry to contribution, makes it “too easy” to relicense the code later, etc.> For non-natural legal entities as contributors, I still maintain my > position that at least under German law a proper legal agreement is > necessary to ensure that any obligations are actually enforceable.I’m not sure what you’re suggesting here. -Chris
Reasonably Related Threads
- RFC #2: Improving license & patent issues in the LLVM community
- RFC #3: Improving license & patent issues in the LLVM community
- RFC #3: Improving license & patent issues in the LLVM community
- RFC #3: Improving license & patent issues in the LLVM community
- RFC #2: Improving license & patent issues in the LLVM community