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

[Chris Lattner via llvm-dev]

On Oct 19, 2015, at 10:53 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
>>>> 2) We could require new contributors to sign the Apache CLA.
>>> 
>>> To me, this is the most acceptable option of the listed terms.
>> 
>> Please explain: why?
> 
> First part for me is that switching the code to a different license
> doesn't address some of the legal concerns regarding "tainted" code.

I’m not sure what you mean by that.  Because LLVM uses a distributed approach to copyright (i.e., all contributors, or their employer, own the copyright for their work), you must contact each of them to relicense the code under a new license.  As part of this contact, you get them to agree to relicense under the new license.  If they don’t, you aren’t allowed to retain the code.

This seems clean to me, even if it is a huge amount of work, and even if it means that you may not get to keep 100% of the code in the tree.

> A CLA can formalise this part and as long as the process is not too
> obnoxious, it doesn't create a significant hurdle. While a click-through
> CLA might not doable for individual contributors, a process like "sign
> this, scan it, mail Chris a copy by email and post" sounds quite
> acceptable as compromise.

As I outlined, this is not how simple it would be.  Please read the CLAs in question, particularly the corporate one.  Keep in mind that the majority of LLVM patches are from corporate contributors.

> Second part is the mentioned issue of patents. Let's say a
> non practicing entity submits a uboot patch to LLVM and later starts to
> sue LLVM users. I'm not clear on the APL2 by itself would help resolve
> this case.

I am not going to argue about legal issues on a mailing list, and I am not a lawyer.  However, the belief of the lawyers I have spoken with is that this is covered.

> Third part is the re-licensing question. This might be in some cases the
> most troublesome part as you mentioned.

Yes, unquestionably this will be a lot of work.

> Two considerations here. First
> is that the CLA (not necessarily the Apache one) should provide
> irrevocable license conditions for all contributors under the license at
> the time contribution.

This suggestion is too vague for me to understand.  What specific CLA are you proposing?  I’m not interested in novel solutions for reasons that I outlined before.  I and several lawyers went through many options, but perhaps you’re aware of one that we missed.  If so, while your choice may not be well known, it could still be a good option.

> Fourth, the management overhead for corporate contributors. A given
> contributor is responsible for either clearing with their employer that
> they can contribute to Open Source projects and it is not considered to
> be IP of the company. The patent question is the same as for any
> non-employed contributor then.

This claim is factually incorrect with the Apache CLA.  Perhaps you’re thinking of a different CLA, if so, please specify.

> I think a combination of good faith and providing appropiate tools is enough. 

I am personally a huge believer in good faith and good intentions, and that approach has served LLVM well for many years.  However, it is undeniably true that motives can be mixed, and particularly as the LLVM community grows over the years that we cannot rely on it forever.

>>>> 3) We could relicense all of LLVM under the Apache 2.0 license and add a runtime exception.
>>> 
>>> This one I would consider a regression over the status quo. Your list is
>>> missing "the license is significantly longer and harder to read”.
>> 
>> To repeat Danny’s point, this doesn’t seem like a concern to me.
>> Please explain your concern: does this affect users of llvm,
>> contributors to llvm, or someone else?  How?
> 
> Users, primarily. The more complicated it is to understand the license,
> the more likely it is to distract folks. Not everyone has a resident
> corporate lawyer to explain things and for a software license, quantity
> is certainly not a good thing. I certainly agree that the APL2 is much
> more readable than e.g. the GPL, but it is still significantly longer
> and complicated than the license we currently have.

Ah, I see what you mean.  I completely agree with you on that, and I wish it were as short as the (e.g.) MIT license.  That said, we need an option that solves the problems that I outlined in my earlier email.  Do you have an alternative suggestion that achieves these aims while still being shorter?

The advantage of the Apache 2 license is that it has been around unmodified for a long time (over a decade) and has thus stood the test of time quite well.  It has a number of “written for human” articles that explain it, e.g. (randomly picked):
http://oss-watch.ac.uk/resources/apache2
http://programmers.stackexchange.com/questions/56927/what-are-the-real-life-implications-for-an-apache-2-license
https://www.quora.com/Whats-the-different-between-Apache-v2-0-and-MIT-license
http://arstechnica.com/uncategorized/2007/11/why-google-chose-the-apache-software-license-over-gplv2/

etc.  These are all on the first page of hits for a search of “apache 2 license” on a popular search engine.

-Chris