llvm dev - Oct 2015 - RFC: Improving license & patent issues in the LLVM community

> On Oct 19, 2015, at 9:27 AM, Joerg Sonnenberger via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> On Mon, Oct 19, 2015 at 08:25:16AM -0700, Chris Lattner via llvm-dev wrote:
>> 1) We could introduce a novel legal solution.
> 
> Please, no.
> 
>> 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?
>> 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?

-Chris

On Mon, Oct 19, 2015 at 10:08:14AM -0700, Chris Lattner
wrote:
> 
> > On Oct 19, 2015, at 9:27 AM, Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > 
> > On Mon, Oct 19, 2015 at 08:25:16AM -0700, Chris Lattner via llvm-dev
wrote:
> >> 1) We could introduce a novel legal solution.
> > 
> > Please, no.
> > 
> >> 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.
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. It means a new contributor can start
committing decently fast and if the snail mail copy doesn't arrive in a
decent time, it should still be possible to revert the contributions as
worst case.

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 can understand the concerns of corporate contributors to
overly broad IP language in a CLA, but that's more a practical issue.
For me it seems to be more important to ensure that commits are clean
and place the burden of proof on the contributing entity.

Third part is the re-licensing question. This might be in some cases the
most troublesome part as you mentioned. 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. The second question is whether making things less
restricted is considered a problem or not. Given the existing BSDish
nature, I'm almost inclined to say no, but that can be answered by the
CLA as well.

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. If it is considered part of work, someone
has to manage such a list? I think a combination of good faith and
providing appropiate tools is enough. But before making this a huge
problem, I'd defer this point to our Apple^WGoogle^Wcompany overlords.
> 
> >> 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.

Joerg

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