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

I don’t have a link off hand.  Two major points:

1) CLA’s in general require an additional approval step, which reduces
contributions.
2) The apache CLA in general gives too much power (e.g. the power to relicense
arbitrarily going forward) to the organization (in this case, llvm.org
<http://llvm.org/>) which can deter contributions from folks who don’t
want relicensing to be a simple act.

-Chris

> On Apr 28, 2017, at 5:46 AM, Rafael Avila de Espindola via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 
> 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/2015-October/091536.html>
>  http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.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
<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
<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
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> 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/20170428/8b8f168b/attachment.html>

Chris Lattner <clattner at llvm.org> writes:
> I don’t have a link off hand.  Two major points:
>
> 1) CLA’s in general require an additional approval step, which reduces
contributions.
Yes, that is the cost I mention in the email. I think it is better to
take this cost than to impose a new license on the users.
> 2) The apache CLA in general gives too much power (e.g. the power to
relicense arbitrarily going forward) to the organization (in this case, llvm.org
<http://llvm.org/>) which can deter contributions from folks who don’t
want relicensing to be a simple act.
But that is a property of only some CLAs, no? We don't need or want (I
hope) that property. We just want to make sure contributions can be used
without worrying about patents.

Cheers,
Rafael

> On Apr 29, 2017, at 8:03 AM, Rafael Avila de Espindola via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 
> Chris Lattner <clattner at llvm.org> writes:
> 
>> I don’t have a link off hand.  Two major points:
>> 
>> 1) CLA’s in general require an additional approval step, which reduces
contributions.
> 
> Yes, that is the cost I mention in the email. I think it is better to
> take this cost than to impose a new license on the users.
For a variety of reasons, we need to change the license.  “Just adding a CLA on
top of what we have” isn’t an option.
> 
>> 2) The apache CLA in general gives too much power (e.g. the power to
relicense arbitrarily going forward) to the organization (in this case, llvm.org
<http://llvm.org/>) which can deter contributions from folks who don’t
want relicensing to be a simple act.
> 
> But that is a property of only some CLAs, no? We don't need or want (I
> hope) that property. We just want to make sure contributions can be used
> without worrying about patents.
Rafael, I appreciate your interest in this topic, but all of these ideas were
discussed in the first round.  Please refer back to that thread, which I linked
to in the first post on this thread.

-Chris