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

>
>
>
> I’m still not completely convinced by this argument, given that the
> majority of patent lawsuits come from NPEs.

That is not necessarily where the majority of patent lawsuit *danger* comes
from, and i'd argue, pretty strongly, it's not the most likely case for
LLVM.

>   We’d still be in the situation where a malicious contributor could:
>
> 1. Spin up a new company to act as a NPE
> 2. Transfer ownership of the relevant patent(s) to the NPE
> 3. Contribute code to LLVM that infringes the patent, safely abiding by
> the terms that they’re licensing all of the patents that they own.
> 4. Watch the NPE sue everyone and laugh.
>
There are literally attempts at loopholes one could play with literally
every legal scenario ever, no matter what is done.
I'll go further:
It's literally not possible to have a GPL compatible license and avoid some
of these loopholes.
That is the price we pay


>
> The Apache 2 License does nothing to prevent this, though Clause 5 of the
> Apache CLA would prevent it.

Actually, it does not.
The Apache CLA does not, in any way, shape, or form, prevent this issue.
Trust me, i answer questions about the CLA pretty much every day.

> Even the CLA wouldn’t protect anyone against being sued by dubious patents
> filed by NPEs that were accidentally infringed, which seems to be by far
> the biggest patent threat to any open source project.
>
Based on what data?
This is, IMHO,  simply not correct in an open source project that involves
cooperation among a large set of competitors.
Additionally, the ability for NPEs to affect a space like compilers is
small, because of the wide variety of algorithm choice, etc.

NPEs choose spaces where they can cover the field.  Compilers are also old,
have very well documented histories (GCC has source code going back to
1983), and most things that happen get published.

All of which makes it not a great target for NPEs.

>
> >> (3) Revocation of copyright and patent use permissions in case of
> >> litigation. I think this is the part about a potential move to
APSL2
> >> that is most highly contented.
> >
> > That isn’t my impression.  Everyone that I have spoken to is in favor
of
> the patent termination clauses (including the FSF:
> https://www.gnu.org/licenses/license-list.en.html#apache2).
> >
> > The only complexity I’ve heard is that it introduces is a potential
> compatibility issue with GPL2 (GPL3 and other licenses are fine), which is
> addressed by the exception clause.
>
> This is correct.
> I’m surprised that all of the companies are happy with it, given that
> neutering defensive patents was one of the big objections we saw to GPLv3.

> 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.

> >> I want to make sure that those are the goals used to justify a
> >> (potential) license change.
> >
> > There are additional goals.  Our current structure is broken in
various
> ways (which I don’t want to enumerate in public), including potential legal
> issues with patches that come in from people who do not have commit
> access.  If we don’t address these issues, then (in my personal opinion) it
> would be irresponsible to allow pull requests (assuming LLVM moves to
> github, which is still up in the air of course).
>
> I disagree.  The GitHub CLA

When you say "the github cla", do you mean the modified Apache CLA
they
have at cla.github.com?

Because if you are worried about loopholes, you can pretty much drive
trucks through that document because of what they removed (and things like
ripping out the warranty disclaimer make it significantly worse for both
users, and corporations)

Or do you mean something else?
>
> 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.


> Please compare the runtime exemption to the GPLv3 - you’ll note that it’s
> a lot longer, for good reason.
>
Actually, as a guy who helped write it, i'm going to say "no it's
not for
good reason" :)
Really.

Most of the exception exists to try to define what exactly an IR or plugin
is to the compiler, and it doesn't do an amazing job of doing that because
of non-legal concerns.

It also has significantly surprising effects for people, not achieving that
goal either.

So while it's okay, it's not "better because it's longer"
for users, and
the parts that are longer, don't help.

To name an example surprising effect:

If you statically link libstdc++, you have no serious obligations in your
distributed binary.

If you dynamically link libstdc++, you have no serious obligations in your
distributed binary, however, you must abide by the GPLv3 for the shared
libstdc++.so you ship.

(including distribution of source for libstdc++ and installation
information like signing keys necessary to install modified versions of the
.so).

I have yet to meet a corporate counsel or person who is not surprised by
this behavior (but the FSF will happily verify it is correct for you :P)

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/660801a0/attachment-0001.html>

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.  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?  If not, what prevents this?
>> 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?

I’m willing to accept that I’m wrong here if you can point out why, but if I’m
not then this is going to require that we audit around 30,000 software packages
that we distribute, which is going to cause a lot of pain and suffering for us
(to the extent that it would probably mean that we’d start actively looking for
an alternative to libc++).

David

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>