[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community

[Chris Lattner via llvm-dev]

Hello everyone,

This email is a continuation of a discussion from almost a year ago, started back here:
http://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