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

Fri Apr 28 05:46:26 PDT 2017

I didn't find the advantage for the license change over a CLA. Can you please point me to it?

Cheers,
Rafael

On April 28, 2017 1:12:10 AM EDT, Chris Lattner <clattner at llvm.org> wrote:
>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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170428/39dc5758/attachment.html>