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

On Thu, Nov 3, 2016 at 8:03 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk>
wrote:
> On 3 Nov 2016, at 14:50, Daniel Berlin <dberlin at dberlin.org>
wrote:
> >> In particular, various corporate lawyers were worried about this
> scenario that neuters defensive patents):
> >  Lawyers see risk everywhere, so i'll just go with "various
corporate
> lawyers are concerned about everything, ever".
> > Clearly, for the majority, the prediction that those concerns would
not
> outweigh the desire to use the software came true.
>
> Without a CLA, I don’t see anything in the Apache 2 license that prevents
> this scenario.

Again, the scope and coverage of the CLA grant is essentially identical to
the license.

> If I want to use an Apple or Google patent, is it enough for me to commit
> some code that infringes it to LLVM and watch them lose their license to
> distribute LLVM if they try to sue me?
No.

First, neither the CLA nor the license terminate all rights, only patent
rights. So the only thing that could happen is *someone else could sue them
for patent infringement*.
So no matter what, they will not have "lost their license to distribute
LLVM".  It just may be risky to do so :)


>   If not, what prevents this?
>
Because the patent grant is based on the state of the software as of the
time of your contribution.
It's even covered in the Apache license FAQ:
"Q1: If I own a patent and contribute to a Work, and, at the time my
contribution is included in that Work, none of my patent's claims are
subject to Apache's Grant of Patent License, is there a way any of those
claims would later become subject to the Grant of Patent License solely due
to subsequent contributions by other parties who are not licensees of that
patent.
A1:No."
So if i make contribution  that does *not* cover patent A (a patent i own)
You add stuff later that would cause users to infringe patent A.
I never contribute again.
That does not grant anyone rights from me to patent A.


The reason this is what occurs is pretty simple.
The wording on which claims are granted is  "That are necessarily infringed
by their Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted."

Clearly, the first part does not apply, because I did not contribute it.
The "work" to which such contributions was submitted is the
copyrightable
work of authorship.
That's LLVM, as of the date you contributed it.
Later contributions are not part of the "work" to which you submitted
your
contribution, and thus, clearly not covered by the grant.



> >> I’m also not completely convinced that the exemption to 4.d
actually
> does what we’d need with respect to libc++.  In FreeBSD, we compile most
> packages with clang, but a few with gcc (and all with gcc on a couple of
> architectures).  We use libc++ for all C++ code, irrespective of how it was
> compiled.  When we are not compiling with clang[1], we’d still be covered
> by 4.d and so every package that uses C++ (a few thousand) would need to
> include the attribution.  Updating all of this and ensuring compliance
> would probably block us from updating libc++ for about a year after the
> license switch.  At the very least, I think this exemption needs a lot more
> explicit clarification.
> >
> > FWIW, the consensus on the open source legal counsel mailing lists i
> belong to, when they saw it (IE on the public mailing lists), was basically
> that it looked great and others want to use it.
> >
> > Not a single person (and the list includes many zealous people of all
> kinds) mentioned they believed there were any serious issues achieving
it's
> goals, or that it needed further clarifications.
>
> For clarification: Is my interpretation incorrect?  If I compile code with
> GCC, which uses templates from libc++ headers and therefore results in
> libc++ code being inserted into the resulting binary, am I required to
> abide by clause 4 of the Apache license and include the libc++ attribution?
>
Yes.
But, AFAIK, this is deliberate.  IE the view is that in this case, you
*should* be giving attribution.
So this is at least "not a bug", regardless of whether it's liked
or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/aa2ce33a/attachment.html>

>
>
> First, neither the CLA nor the license terminate all rights, only patent
> rights.
>
(and before anyone asks, it is not possible to terminate all rights,
including copyright, and remain GPLv2 compatible.
This is the one perennial problems of trying to write gplv2 compatible
licenses)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/02ab5a37/attachment.html>

On 3 Nov 2016, at 15:28, Daniel Berlin <dberlin at dberlin.org>
wrote:
> 
>  If not, what prevents this?
> 
> Because the patent grant is based on the state of the software as of the
time of your contribution.
> It's even covered in the Apache license FAQ:
> "Q1: If I own a patent and contribute to a Work, and, at the time my
contribution is included in that Work, none of my patent's claims are
subject to Apache's Grant of Patent License, is there a way any of those
claims would later become subject to the Grant of Patent License solely due to
subsequent contributions by other parties who are not licensees of that patent.
> A1:
> No.”
Thanks, that makes sense.  I had assumed the termination was closer to GPLv3.
> For clarification: Is my interpretation incorrect?  If I compile code with
GCC, which uses templates from libc++ headers and therefore results in libc++
code being inserted into the resulting binary, am I required to abide by clause
4 of the Apache license and include the libc++ attribution?
> 
> Yes.
> But, AFAIK, this is deliberate.  IE the view is that in this case, you
*should* be giving attribution.
> So this is at least "not a bug", regardless of whether it's
liked or not.
I believe that this would be a show-stopper for FreeBSD’s use of libc++ and
compiler-rt.  As such, I would strongly oppose this and would not consent to any
of my code in libc++ being relicensed under the proposed terms.  This would
require that we audit all 30K packages, find the ones that will (when we ship
binaries) link libc++, and add the attribution in the right places.

Whose view is ’the view'?  I and the other libc++ contributors were all
happy to have our code relicensed under the MIT license (or contribute it under
those terms originally), so there is some pretty clear evidence that we
explicitly did *not* require this attribution.  Indeed, we relicensed under the
MIT license (after long discussion) specifically to avoid this requirement. 
This seems like a step that is directly contrary to the intentions of the
original authors.

David

>
>
> > For clarification: Is my interpretation incorrect?  If I compile code
> with GCC, which uses templates from libc++ headers and therefore results in
> libc++ code being inserted into the resulting binary, am I required to
> abide by clause 4 of the Apache license and include the libc++ attribution?
> >
> > Yes.
> > But, AFAIK, this is deliberate.  IE the view is that in this case, you
> *should* be giving attribution.
> > So this is at least "not a bug", regardless of whether
it's liked or not.
>
> I believe that this would be a show-stopper for FreeBSD’s use of libc++
> and compiler-rt.  As such, I would strongly oppose this and would not
> consent to any of my code in libc++ being relicensed under the proposed
> terms.  This would require that we audit all 30K packages, find the ones
> that will (when we ship binaries) link libc++, and add the attribution in
> the right places.
>
> Whose view is ’the view'?

The consensus i saw here and elsewhere. I'm happy to be shown to be wrong.

> I and the other libc++ contributors were all happy to have our code
> relicensed under the MIT license (or contribute it under those terms
> originally), so there is some pretty clear evidence that we explicitly did
> *not* require this attribution.

That license does, in fact, require attribution:
"The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software. "

Indeed, we relicensed under the MIT license (after long
discussion)
> specifically to avoid this requirement.

If we did, we screwed it up then. We probably meant the zlib license, which
does not require attribution  ;)

> This seems like a step that is directly contrary to the intentions of the
> original authors.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/3af0a355/attachment.html>

Hi David,

I think Danny has covered most of the issues that has come up, one thing I want
to clarify:

On Nov 3, 2016, at 8:42 AM, David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> For clarification: Is my interpretation incorrect?  If I compile code with
GCC, which uses templates from libc++ headers and therefore results in libc++
code being inserted into the resulting binary, am I required to abide by clause
4 of the Apache license and include the libc++ attribution?
>> 
>> Yes.
>> But, AFAIK, this is deliberate.  IE the view is that in this case, you
*should* be giving attribution.
>> So this is at least "not a bug", regardless of whether
it's liked or not.
> 
> I believe that this would be a show-stopper for FreeBSD’s use of libc++ and
compiler-rt.  As such, I would strongly oppose this and would not consent to any
of my code in libc++ being relicensed under the proposed terms.
DannyB is right that this is what is required by RFC#2, but that was already
pointed out as a major problem with #2.  I agree with you that it would be a
show-stopper for major LLVM users if libc++/compiler-rt/etc required this sort
of attribution.  Our goal is to allow other compilers (including proprietary
compilers like ICC, MSVC, etc) to use LLVM runtimes without attribution.  I’m
actively iterating with folks (which, as usual, is a very slow process) to fix
this.

I have no believable ETA for an update (but I hope for the next month or two),
but I’ll post RFC #3 with our next attempt at revising this.  This is the only
open issue that we’re working on at the moment.  I’m hopeful that once we
resolve it that we’ll have a final draft - but, of course, some other issue may
come up and require a #4.

-Chris