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

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

--Dan

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>