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

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

On Tue, Oct 20, 2015 at 09:54:30PM -0700, Chris Lattner
wrote:
> 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.
Clearly :)
> 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.
I am not talking about the process for relicensing code. Let's assume
that part happened. The point I am trying to make is that this doesn't
solve any of the reasons why a CLA is normally introduced and I do
believe many of those are used as justification for such a license
change in first place:

(1) Clear responsibility for authorship of committed changes.
(2) Explicit contract for patent licenses.

Luckily, I don't have any legal department for pushing any corporate
agenda here, but I am a bit surprised that especially the second part is
considered a non-issue?

Joerg

>> 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.
I have to give a huge +1 here.

Having cleaned and dealt with fires due to  a *number* of these
situations before, and had to help projects that thought good
intentions were enough, the blunt truth is:
It's not.  Really
You are just getting lucky.
I wish it were not the case, but good intentions are worth precisely
squat when things go bad.
Whether things go bad is not related at all to your community, how
good the people are in it, the size of your project, or anything else.

I've seen projects large and small have issues here.
For example, the Java Model Railroad interface (See, e.g.,
https://en.wikipedia.org/wiki/Jacobsen_v._Katzer) was not exactly "a
huge community".

On Wed, Oct 21, 2015 at 5:16 AM, Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Tue, Oct 20, 2015 at 09:54:30PM -0700, Chris Lattner wrote:
>> 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.
>
> Clearly :)
>
>> 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.
>
> I am not talking about the process for relicensing code. Let's assume
> that part happened. The point I am trying to make is that this doesn't
> solve any of the reasons why a CLA is normally introduced
So let me stop you right here.
Because this statement is just flat out wrong.
Let's go through your issues:
> and I do
> believe many of those are used as justification for such a license
> change in first place:
>
> (1) Clear responsibility for authorship of committed changes.
> (2) Explicit contract for patent licenses.
Again, as stated before, both of these issues are covered by the apache license.

It has a built-in CLA that explicitly grants both copyright and patent
rights from contributors when they make contributions to the work.
>
> Luckily, I don't have any legal department for pushing any corporate
> agenda here,
I'm not sure what you are suggesting here, ...
> but I am a bit surprised that especially the second part is
> considered a non-issue?
I'm also not sure why you think it's considered a non-issue.
Instead, what you are getting told is "both of your concerns are
already covered by the relicensing option".
Because they are :)