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

Thu Nov 3 07:50:09 PDT 2016

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