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

Thu Apr 27 22:12:10 PDT 2017

Hi Rafael,

I believe that all of these points are covered in the first round of discussion, including the FreeBSD team’s position.

-Chris

> On Apr 27, 2017, at 2:43 PM, Rafael Espíndola via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Sorry for the delay, I was on vacations.
> 
> Ed, what is the FreeBSD position about the apache version 2 in base? A
> quick search only shows it in contrib/ and crypto/openssl.
> 
> If I understand the issue, we can achieve the desired results with a
> license change that handles patents or by keeping a minimal license
> for runtime and llvm, but requiring a contributor agreement in the
> project before we accept changes. Am I correct?
> 
> Not requiring a contributor agreement is awesome. It makes it really
> easy for people to join the project or send one time fixes. It also
> saves committers from having to check some database before committing
> a patch by someone else.
> 
> On the other hand, at least for me, one of the main motivations for
> wanting to contribute to llvm projects is how widely used they are. I
> understand that an effort was made for gpl2 compatibility, but that is
> a bit of innovation that we were trying to avoid. More importantly, it
> is hard to say that is the only issue one will ever find.
> 
> Also, at least the OpenBSD project is reluctant to use the Apache2
> license. From where I stand it doesn't really matter if their concerns
> with the license are unfounded: until they are convinced otherwise the
> change is undesirable from the perspective of making llvm used as much
> as possible.
> 
> Given the situation I would prefer to penalize the development process
> a bit and have a contributor agreement instead of the license change.
> 
> Cheers,
> Rafael
> 
> On 17 April 2017 at 10:37, Chris Lattner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Hello everyone,
>> 
>> This email is a continuation of a discussion started in October 2015, and continued in September 2016:
>> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
>> http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
>> 
>> As with those emails, 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, Heather Meeker (a prominent and distinguished OSS licensing attorney) has agreed to represent the interests of the LLVM Community as independent counsel.  This proposal incorporates all of their feedback.
>> 
>> 
>> The goals of this effort are outlined in the first 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.
>> - ensure that LLVM runtime libraries may be used by other open source and proprietary compilers.
>> 
>> Here we are discussing what the best end game is -- not the logistics of how to get from here to there.
>> 
>> 
>> In case you haven’t been following, here is an attempt at quick recap the history, leading to today:
>> 
>> The first email thread addressed the issue of how to structure the new LLVM license, what the problem to be solved is, and rationale for a general approach.  We decided and converged on using the approach of the industry standard Apache 2 License, with exceptions to correct problematic cases for the LLVM community (specifically, the issue of runtime libraries that are implicitly linked into an application by the compiler).  The concern there is that users of LLVM compilers (e.g. Clang) would not necessarily know that runtime libraries are implicitly linked into their application, and thus fail to attribute the LLVM project in binaries.  The LLVM project generally isn’t widely concerned with binary attribution, but widespread noncompliance with license terms can lead to problems enforcing other terms in the license.
>> 
>> That first discussion recognized the binary attribution issue, but a second concern was raised by some who believe the Apache 2 and GPL version 2.0 licenses are incompatible.  The second email thread addressed that compatibility concern by introducing a second exception clause.  In the second email thread, those concerned about GPL2 were satisfied, but an additional issue was raised about the first binary attribution clause: specifically, we aim for the LLVM runtime libraries to be used very permissively, even by proprietary compilers and linkers.  This led to another round of intense (offline) discussion about the concrete wording of the exceptions, which brings us to today.
>> 
>> 
>> Today we’re proposing a new wording, in line with the previous approach: we use the Apache 2.0 license with two exceptions, one to address binary attribution issues and one to address concerns about GPL2 compatibility.  In addition, we have striven to align the wording and legal terminology with those in the Apache 2.0 license.  For general rationale and framing for why these approaches are important, I’ll refer you back to the first and second threads.  Here is our new proposed wording:
>> 
>> 
>> ---- Exceptions to the Apache 2.0 License: ——
>> 
>> As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of 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 —
>> 
>> 
>> Despite the effort required to reach this point, this is only a small shift from the second round proposal.  We believe that this will resolve the issue of LLVM runtime libraries being used by proprietary and other non-LLVM compilers, and the wording has been carefully vetted by a team of super-smart legal folks, led by Heather (who represents the interests of the LLVM community).
>> 
>> We expect that we will need to have a name for this wording, and propose the name "Apache 2.0 License with LLVM Exception” to align the naming with the other exception clauses listed in the SPDX database (https://spdx.org/licenses/exceptions-index.html).  Several other approaches to naming were considered, but we believe that, in this case at least, the most obvious answer is the best.
>> 
>> At this point, we’re fairly confident that this wording covers all of the known bases.  That said, we welcome comments and questions on this thread, because while we know that it is impossible to please everyone, we want to know if we’ve missed the mark in a significant way.
>> 
>> If the LLVM community is generally on board with this approach, we’ll ask the LLVM Foundation Board of Directors to approve this, and we can move on to the logistical discussion of how to enact a new license structure: itself a difficult act.
>> 
>> Thanks,
>> 
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev