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

> 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

> On 2 Nov 2016, at 23:01, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
>> 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.
I’m still not completely convinced by this argument, given that the majority of
patent lawsuits come from NPEs.  We’d still be in the situation where a
malicious contributor could:

1. Spin up a new company to act as a NPE
2. Transfer ownership of the relevant patent(s) to the NPE
3. Contribute code to LLVM that infringes the patent, safely abiding by the
terms that they’re licensing all of the patents that they own.
4. Watch the NPE sue everyone and laugh.

The Apache 2 License does nothing to prevent this, though Clause 5 of the Apache
CLA would prevent it.  Even the CLA wouldn’t protect anyone against being sued
by dubious patents filed by NPEs that were accidentally infringed, which seems
to be by far the biggest patent threat to any open source project.
>> (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’m surprised that all of the companies are happy with it, given that neutering
defensive patents was one of the big objections we saw to GPLv3.  In particular,
various corporate lawyers were worried about this scenario that neuters
defensive patents):

1. Company A adopts project X
2. X becomes an important part of A’s product line
3. Company B (competitor to A) contributes code infringing A’s patents to X
4. Company B sues A for infringement of another (unrelated) patent
5. Company A can’t use their patent to countersue without losing the ability to
distribute X
>> 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 disagree.  The GitHub CLA covers all pull requests and currently gives us far
more protection than any other mechanism that we have for receiving patches.
>> 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.
It would perhaps have been helpful for these to have been more widely
enumerated.  There seemed to be a lot more support both in the thread and in
offline discussions for a CLA than for relicensing, yet there’s subsequently
been a big push for relicensing and no discussion of a CLA.

I don’t have strong objections to the Apache 2 license, but I don’t like the
precedent that we’d be setting by relicensing under a less permissive license. 
I was happy to give permission for code that I’d contributed to be relicensed
under the MIT license for inclusion in libc++, but a move in the opposite
direction seems harder to accept.

I’m also not completely convinced that the exemption to 4.d actually does what
we’d need with respect to libc++.  In FreeBSD, we compile most packages with
clang, but a few with gcc (and all with gcc on a couple of architectures).  We
use libc++ for all C++ code, irrespective of how it was compiled.  When we are
not compiling with clang[1], we’d still be covered by 4.d and so every package
that uses C++ (a few thousand) would need to include the attribution.  Updating
all of this and ensuring compliance would probably block us from updating libc++
for about a year after the license switch.  At the very least, I think this
exemption needs a lot more explicit clarification.  Please compare the runtime
exemption to the GPLv3 - you’ll note that it’s a lot longer, for good reason.

David

On Wed, Nov 02, 2016 at 04:01:34PM -0700, Chris Lattner
wrote:
> > 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.
Wrong continent for me.
> > (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”?
This is what we are trying to do already and something we want to keep
doing.

[snip of parts covered already by David]
> > 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.
We still need to keep track of what legal entity is doing the
contribution. The easiest case is a lone programmer -- let him/her say so
once and the problem is solved until he/she gets employed and changes
his/her status.

For corporate entries as contributor it is somewhat more involved. I
don't know what form of authorisation lawyers on both sides are happy
with. It can be as simple as a company like Google or Apple signing
paper work once that they agree to the patent use and that all
contributions from a @google.com or @apple.com address are fine. They
might want to keep track of permitted individuals, I don't know.

Assuming the Github moves happens, it could be tight to the github
IDs. I know some projects are already using automated checks for pull
requests for proof of origin. It can be a bit work for people with
multiple github accounts, but that's a different issue.

Joerg

>
>
>
> I’m still not completely convinced by this argument, given that the
> majority of patent lawsuits come from NPEs.

That is not necessarily where the majority of patent lawsuit *danger* comes
from, and i'd argue, pretty strongly, it's not the most likely case for
LLVM.

>   We’d still be in the situation where a malicious contributor could:
>
> 1. Spin up a new company to act as a NPE
> 2. Transfer ownership of the relevant patent(s) to the NPE
> 3. Contribute code to LLVM that infringes the patent, safely abiding by
> the terms that they’re licensing all of the patents that they own.
> 4. Watch the NPE sue everyone and laugh.
>
There are literally attempts at loopholes one could play with literally
every legal scenario ever, no matter what is done.
I'll go further:
It's literally not possible to have a GPL compatible license and avoid some
of these loopholes.
That is the price we pay


>
> The Apache 2 License does nothing to prevent this, though Clause 5 of the
> Apache CLA would prevent it.

Actually, it does not.
The Apache CLA does not, in any way, shape, or form, prevent this issue.
Trust me, i answer questions about the CLA pretty much every day.

> Even the CLA wouldn’t protect anyone against being sued by dubious patents
> filed by NPEs that were accidentally infringed, which seems to be by far
> the biggest patent threat to any open source project.
>
Based on what data?
This is, IMHO,  simply not correct in an open source project that involves
cooperation among a large set of competitors.
Additionally, the ability for NPEs to affect a space like compilers is
small, because of the wide variety of algorithm choice, etc.

NPEs choose spaces where they can cover the field.  Compilers are also old,
have very well documented histories (GCC has source code going back to
1983), and most things that happen get published.

All of which makes it not a great target for NPEs.

>
> >> (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.
>
> This is correct.
> I’m surprised that all of the companies are happy with it, given that
> neutering defensive patents was one of the big objections we saw to GPLv3.

> In particular, various corporate lawyers were worried about this scenario
> that neuters defensive patents):
>
 Lawyers see risk everywhere, so i'll just go with "various corporate
lawyers are concerned about everything, ever".
Clearly, for the majority, the prediction that those concerns would not
outweigh the desire to use the software came true.

> >> 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 disagree.  The GitHub CLA

When you say "the github cla", do you mean the modified Apache CLA
they
have at cla.github.com?

Because if you are worried about loopholes, you can pretty much drive
trucks through that document because of what they removed (and things like
ripping out the warranty disclaimer make it significantly worse for both
users, and corporations)

Or do you mean something else?
>
> I’m also not completely convinced that the exemption to 4.d actually does
> what we’d need with respect to libc++.  In FreeBSD, we compile most
> packages with clang, but a few with gcc (and all with gcc on a couple of
> architectures).  We use libc++ for all C++ code, irrespective of how it was
> compiled.  When we are not compiling with clang[1], we’d still be covered
> by 4.d and so every package that uses C++ (a few thousand) would need to
> include the attribution.  Updating all of this and ensuring compliance
> would probably block us from updating libc++ for about a year after the
> license switch.  At the very least, I think this exemption needs a lot more
> explicit clarification.

FWIW, the consensus on the open source legal counsel mailing lists i belong
to, when they saw it (IE on the public mailing lists), was basically that
it looked great and others want to use it.

Not a single person (and the list includes many zealous people of all
kinds) mentioned they believed there were any serious issues achieving it's
goals, or that it needed further clarifications.


> Please compare the runtime exemption to the GPLv3 - you’ll note that it’s
> a lot longer, for good reason.
>
Actually, as a guy who helped write it, i'm going to say "no it's
not for
good reason" :)
Really.

Most of the exception exists to try to define what exactly an IR or plugin
is to the compiler, and it doesn't do an amazing job of doing that because
of non-legal concerns.

It also has significantly surprising effects for people, not achieving that
goal either.

So while it's okay, it's not "better because it's longer"
for users, and
the parts that are longer, don't help.

To name an example surprising effect:

If you statically link libstdc++, you have no serious obligations in your
distributed binary.

If you dynamically link libstdc++, you have no serious obligations in your
distributed binary, however, you must abide by the GPLv3 for the shared
libstdc++.so you ship.

(including distribution of source for libstdc++ and installation
information like signing keys necessary to install modified versions of the
.so).

I have yet to meet a corporate counsel or person who is not surprised by
this behavior (but the FSF will happily verify it is correct for you :P)

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/660801a0/attachment-0001.html>