<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
</span>I’m still not completely convinced by this argument, given that the majority of patent lawsuits come from NPEs.</blockquote><div><br></div><div>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.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  We’d still be in the situation where a malicious contributor could:<br>
<br>
1. Spin up a new company to act as a NPE<br>
2. Transfer ownership of the relevant patent(s) to the NPE<br>
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.<br>
4. Watch the NPE sue everyone and laugh.<br></blockquote><div><br></div><div>There are literally attempts at loopholes one could play with literally every legal scenario ever, no matter what is done.</div><div>I'll go further:<br>It's literally not possible to have a GPL compatible license and avoid some of these loopholes.</div><div>That is the price we pay</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The Apache 2 License does nothing to prevent this, though Clause 5 of the Apache CLA would prevent it. </blockquote><div><br></div><div>Actually, it does not.</div><div>The Apache CLA does not, in any way, shape, or form, prevent this issue.</div><div>Trust me, i answer questions about the CLA pretty much every day.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br></blockquote><div><br></div><div>Based on what data?</div><div>This is, IMHO,  simply not correct in an open source project that involves cooperation among a large set of competitors.<br></div><div>Additionally, the ability for NPEs to affect a space like compilers is small, because of the wide variety of algorithm choice, etc.</div><div><br></div><div>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.</div><div><br></div><div>All of which makes it not a great target for NPEs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>> (3) Revocation of copyright and patent use permissions in case of<br>
>> litigation. I think this is the part about a potential move to APSL2<br>
>> that is most highly contented.<br>
><br>
> That isn’t my impression.  Everyone that I have spoken to is in favor of the patent termination clauses (including the FSF: <a href="https://www.gnu.org/licenses/license-list.en.html#apache2" rel="noreferrer" target="_blank">https://www.gnu.org/licenses/<wbr>license-list.en.html#apache2</a>).<br>
><br>
> 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.<br>
<br></span></blockquote><div>This is correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>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.  </blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In particular, various corporate lawyers were worried about this scenario that neuters defensive patents):<br></blockquote><div> Lawyers see risk everywhere, so i'll just go with "various corporate lawyers are concerned about everything, ever".</div><div>Clearly, for the majority, the prediction that those concerns would not outweigh the desire to use the software came true.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>> I want to make sure that those are the goals used to justify a<br>
>> (potential) license change.<br>
><br>
> 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).<br>
<br>
</span>I disagree.  The GitHub CLA </blockquote><div><br></div><div>When you say "the github cla", do you mean the modified Apache CLA they have at <a href="http://cla.github.com">cla.github.com</a>?</div><div><br></div><div>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)</div><div><br></div><div>Or do you mean something else?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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. </blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please compare the runtime exemption to the GPLv3 - you’ll note that it’s a lot longer, for good reason.<br></blockquote><div><br></div><div>Actually, as a guy who helped write it, i'm going to say "no it's not for good reason" :)</div><div>Really.</div><div><br></div><div>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.</div><div><br></div><div>It also has significantly surprising effects for people, not achieving that goal either.</div><div><br></div><div>So while it's okay, it's not "better because it's longer" for users, and the parts that are longer, don't help.</div><div><br></div><div>To name an example surprising effect:<br><br></div><div>If you statically link libstdc++, you have no serious obligations in your distributed binary.</div><div><br></div><div>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.</div><div><br></div><div>(including distribution of source for libstdc++ and installation information like signing keys necessary to install modified versions of the .so).</div><div><br></div><div>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)</div><div><br></div><div>--Dan</div><div><br></div><div><br></div></div></div></div>