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

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 19 15:48:01 PDT 2017

LGPLv2.1 has no real compatibility issues with anything, because it allows
additional restrictions and license of choice (as long as they meet two
requirements that apache can meet).


On Wed, Apr 19, 2017 at 3:44 PM, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Let me say first that I personally am awed and gratified by the
> effort, patience and persistence of the people who have been
> pursuing the licensing topic.  I have some idea what it's like.
> One question came up internally, which I am passing back to the
> interested parties.  While it is clear about the intent of the
> clause to address compatibility with GPLv2, what is the state of
> compatibility with respect to LGPLv2.1?
> Thanks,
> --paulr
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> Chris Lattner via llvm-dev
> Sent: Monday, April 17, 2017 7:37 AM
> To: llvm-dev
> Subject: [llvm-dev] RFC #3: Improving license & patent issues in the LLVM
> community
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170419/bfe34006/attachment-0001.html>

More information about the llvm-dev mailing list