llvm dev - Nov 2016 - RFC #2: Improving license & patent issues in the LLVM community

Hello everyone,

This email is a continuation of a discussion from almost a year ago, started
back here:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html

As described in that email, 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, and the LLVM Foundation hired Heather Meeker (a prominent OSS licensing
attorney) to represent the interests of the LLVM Community.  This proposal
incorporates all of their feedback, and Heather has further refined and approved
this approach.


The goals of this effort are outlined in the previous 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.

Here we are discussing what the best end game is -- not the logistics of how to
get from here to there.


The email from last year proposed relicensing the LLVM project under the Apache
2 License, and using a runtime exception clause to avoid the binary attribute
requirement of the Apache 2 license.  The advantage of this approach is that it
avoided developing an entirely novel license (which would introduce problems
outlined in the original email), it keeps the liberal nature of the LLVM license
(you can take and use it for lots of different kinds of projects without being
required to publish your downstream code), it does not require a “contributor
license agreement” (CLA) which would introduce a higher barrier of entry and
increase uncertainty for contributors, and it solves the compiler/runtime
library schism by allowing us to license everything uniformly under the same
license.

After extensive discussion on the mailing list (see the archives if you missed
it), the community generally agreed with the approach, but had a major concern:
Many folks believe the Apache 2 license to be incompatible with the GPLv2
license.  This is problem because there are a number of important GPLv2 projects
that use LLVM (e.g. QEMU) or projects that are "GPLv2 or later” but which
prefer to be used under the terms of the GPLv2 license (e.g. FreePascal).  This
strong voice inspired us to go back and look for ways to solve this problem.


This problem really is specific to GPLv2 (it doesn’t affect any other commonly
used licenses), but it turns out that this is a surprisingly difficult problem
to solve.  For example, many prominent open source lawyers consider the GPLv2
and Apache 2 licenses to be compatible already, which means that there is no
problem to solve.  The problem for us as a community is that this issue hasn’t
been tested in court, and there are other lawyers that believe that the two
could be considered incompatible.  As such, we recommend taking a pragmatic and
conservative approach that defends against incompatibility if it eventually
arises, instead of optimistically assuming that they are compatible.

After extensive discussion involving many lawyers with different affiliations,
we recommend taking the approach of using the Apache 2.0 license, with the
binary attribution exception (discussed before), and add an additional exception
to handle the situation of GPL2 compatibility if it ever arises.  Specifically,
this is the proposed wording:


---- Exceptions to the Apache 2.0 License: ——

As an exception, if you use this Software to compile your source code and
portions of this Software are embedded into the binary product as a result, you
may redistribute such product without providing attribution as would otherwise
be required by 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 ---


The first paragraph is the exact same one proposed in the previous discussion
(addressing the compiler / runtime schism), and the second addresses the GPLv2
concerns.  It is structured the way it is for a number of reasons:

- We want to conservatively protect the community if the licenses are found to
be incompatible.
- The LLVM community should not take a position on whether the licenses are
compatible or not.
- We want to make it clear that the exception only applies if you’re using GPL2
code: if not, you can ignore it.
- Allowing retroactive waiving makes it unlikely that an LLVM user could be
expected to pay damages (if the two licenses are ever found to be incompatible).


In the process of discussing this issue, we considered many different
approaches, and I believe that this is the best approach: it provides the
compatibility and protection that we seek, and Heather Meeker (legal
representative for the LLVM Foundation) has contributed to and approved its
wording.

With that as background I’d love to hear what the rest of you think: do you have
any concerns?  If you are yourself a lawyer or work for a company with them,
does your legal counsel have any concerns?  If you’d prefer not to discuss this
on a public mailing list, feel free to email me personally.

Once we reach an agreement on the path to take, we can start talking about
logistics of how to get there.

Thank you!

-Chris

Hi Chris,

2016-09-12 18:16 GMT+02:00 Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org>:
> ---- Exceptions to the Apache 2.0 License: ——
>
> As an exception, if you use this Software to compile your source code and
portions of this Software are embedded into the binary product as a result, you
may redistribute such product without providing attribution as would otherwise
be required by Sections 4(a), 4(b) and 4(d) of the License.
>
> [...]
>
> ---- end ---
Just to make sure I get this straight, I can substitute 'this
Software' by the names of components provided by the LLVM project. For
example:
> As an exception, if you use LLVM, Clang and/or DragonEgg to compile your
source code and portions of compiler-rt, libc++, libc++abi and/or libunwind are
embedded into the binary product as a result, you may redistribute such product
without providing attribution as would otherwise be required by Sections 4(a),
4(b) and 4(d) of the License.
I've got a couple of questions about this.

- Now that we're also in the business of providing other kinds of
tools that are not compilers (e.g., LLD being a linker), are we sure
that this will cover all of our needs?

- What about derived software? Would this also apply if I'd be using
the Swift compiler to generate an executable that contains some bits
from compiler-rt? What if I'd be using GCC, but added a tiny fraction
of LLVM's source code to it? What about a stock version of GCC that is
linked against compiler-rt?

Sorry if some of these questions may seem hypothetical or silly; I'm
merely interested in knowing where the boundary is and how this
licensing exception will work in practice.

Best regards,
-- 
Ed Schouten <ed at nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717

On Sep 12, 2016, at 10:10 AM, Ed Schouten <ed at nuxi.nl>
wrote:
>> 
>> ---- end ---
> 
> Just to make sure I get this straight, I can substitute 'this
> Software' by the names of components provided by the LLVM project.
This is the literal license text that will be included with each of these
projects, so no, you cannot literally make that substitution.

However, yes, this will cover all parts of the LLVM project including LLVM,
Clang, LLDB, libc++ etc if that’s what you’re asking.
> For
> example:
> 
>> As an exception, if you use LLVM, Clang and/or DragonEgg to compile
your source code and portions of compiler-rt, libc++, libc++abi and/or libunwind
are embedded into the binary product as a result, you may redistribute such
product without providing attribution as would otherwise be required by Sections
4(a), 4(b) and 4(d) of the License.
The license specifically does not make a distinction between LLVM/clang and
libc++/compiler-rt.  You should be able to embed LLVM or clang code into a
binary without having to provide attribution.

> I've got a couple of questions about this.
> 
> - Now that we're also in the business of providing other kinds of
> tools that are not compilers (e.g., LLD being a linker), are we sure
> that this will cover all of our needs?
Yes, I don’t see anything functionally or use-case different between LLD and
Clang or LLDB.
> - What about derived software?
You need to specify what you mean by derived, I’ll answer the specific questions
below to the best of my knowledge.  However, it would be great for someone like
DannyB to confirm this.
> Would this also apply if I'd be using
> the Swift compiler to generate an executable that contains some bits
> from compiler-rt?
Yes, the runtime exception clause covers the code being embedded (compiler-rt)
not relating to how it got embedded.

FWIW, Swift already uses the Apache 2 license with the runtime exception clause,
but that isn’t important for the question.
> What if I'd be using GCC, but added a tiny fraction
> of LLVM's source code to it? What about a stock version of GCC that is
> linked against compiler-rt?
Both are fine, the compiler-rt code is covered regardless of how it gets
embedded.  You could use a fully proprietary compiler like Intel’s ICC and that
would also be fine.
> Sorry if some of these questions may seem hypothetical or silly; I'm
> merely interested in knowing where the boundary is and how this
> licensing exception will work in practice.
No problem at all,

-Chris

On 12/09/16 18:16, Chris Lattner via llvm-dev wrote:
> ---- Exceptions to the Apache 2.0 License: ——
>
> As an exception, if you use this Software to compile your source code and
portions of this Software are embedded into the binary product as a result, you
may redistribute such product without providing attribution as would otherwise
be required by 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 ---
>
>
> The first paragraph is the exact same one proposed in the previous
discussion (addressing the compiler / runtime schism), and the second addresses
the GPLv2 concerns.
Looks great to me, thanks a lot for taking our (and others') concerns 
into consideration!


Jonas
(Free Pascal Compiler developer; just got back from holidays and 
catching up with LLVM mails)

On Mon, Sep 12, 2016 at 09:16:47AM -0700, Chris Lattner via llvm-dev
wrote:
> The goals of this effort are outlined in the previous 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.
Hi Chris,
let me go back to this with some of the thoughts from the last Berlin
Social. Ignoring the question of what license to choose, I see three
different components mangled together:

(1) Coherent licensing between "build time" and "run time"
components.
This part does need a license change one way or another.

(2) LLVM contributors grant permissions to use their patents as far as
necessary for their contributions. The desirability of this is
unquestionable either.

(3) Revocation of copyright and patent use permissions in case of
litigation. I think this is the part about a potential move to APSL2
that is most highly contented.

I want to make sure that those are the goals used to justify a
(potential) license change.

I still stand by my position that (2) isn't served alone by the APSL,
since it isn't clear who the contributing entity is. A click-thru CLA
for individual contributors would server the purpose for those, IMO.
For non-natural legal entities as contributors, I still maintain my
position that at least under German law a proper legal agreement is
necessary to ensure that any obligations are actually enforceable.

Joerg

> On Nov 1, 2016, at 12:21 PM, Joerg Sonnenberger via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> On Mon, Sep 12, 2016 at 09:16:47AM -0700, Chris Lattner via llvm-dev wrote:
>> The goals of this effort are outlined in the previous 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.
> 
> Hi Chris,
> let me go back to this with some of the thoughts from the last Berlin
> Social.
Thanks!  FWIW, if you or anyone else is going to be at the LLVM Dev Meeting and
are interested in relicensing, then please come to the LLVM Foundation BoF. 
I’ll give an update there, and it’s a great place for general questions and
discussion.
> Ignoring the question of what license to choose, I see three
> different components mangled together:
> 
> (1) Coherent licensing between "build time" and "run
time" components.
> This part does need a license change one way or another.
Right.
> (2) LLVM contributors grant permissions to use their patents as far as
> necessary for their contributions. The desirability of this is
> unquestionable either.
I’m not sure what you mean by "unquestionable either”.  Do you mean
"unquestionable good”?

If we don’t achieve this, then we run the heightened risk of someone being sued
for using LLVM.  This isn’t good for the community.
> (3) Revocation of copyright and patent use permissions in case of
> litigation. I think this is the part about a potential move to APSL2
> that is most highly contented.
That isn’t my impression.  Everyone that I have spoken to is in favor of the
patent termination clauses (including the FSF:
https://www.gnu.org/licenses/license-list.en.html#apache2).

The only complexity I’ve heard is that it introduces is a potential
compatibility issue with GPL2 (GPL3 and other licenses are fine), which is
addressed by the exception clause.
> I want to make sure that those are the goals used to justify a
> (potential) license change.
There are additional goals.  Our current structure is broken in various ways
(which I don’t want to enumerate in public), including potential legal issues
with patches that come in from people who do not have commit access.  If we
don’t address these issues, then (in my personal opinion) it would be
irresponsible to allow pull requests (assuming LLVM moves to github, which is
still up in the air of course).
> I still stand by my position that (2) isn't served alone by the APSL,
> since it isn't clear who the contributing entity is. A click-thru CLA
> for individual contributors would server the purpose for those, IMO.
A CLA was carefully considered and has numerous problems depending on which one
you’re talking about.  The most common proposal is to use an Apache CLA (aka
Google CLA), which introduces several problems we discussed in the relicensing
round a year ago: it increases the barrier to entry to contribution, makes it
“too easy” to relicense the code later, etc.
> For non-natural legal entities as contributors, I still maintain my
> position that at least under German law a proper legal agreement is
> necessary to ensure that any obligations are actually enforceable.
I’m not sure what you’re suggesting here.

-Chris