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

[Chris Lattner via llvm-dev]

> 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