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

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

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>

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>