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

[Joerg Sonnenberger via llvm-dev]

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