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

[David Chisnall via llvm-dev]

> 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