Chris Lattner via llvm-dev
2016-Nov-02 23:01 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
> On Nov 1, 2016, at 12:21 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Sep 12, 2016 at 09:16:47AM -0700, Chris Lattner via llvm-dev wrote: >> The goals of this effort are outlined in the previous email but, in short, we aim to: >> - encourage ongoing contributions to LLVM by preserving low barrier to entry for contributors. >> - protect users of LLVM code by providing explicit patent protection in the license. >> - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. >> - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. > > Hi Chris, > let me go back to this with some of the thoughts from the last Berlin > Social.Thanks! FWIW, if you or anyone else is going to be at the LLVM Dev Meeting and are interested in relicensing, then please come to the LLVM Foundation BoF. I’ll give an update there, and it’s a great place for general questions and discussion.> Ignoring the question of what license to choose, I see three > different components mangled together: > > (1) Coherent licensing between "build time" and "run time" components. > This part does need a license change one way or another.Right.> (2) LLVM contributors grant permissions to use their patents as far as > necessary for their contributions. The desirability of this is > unquestionable either.I’m not sure what you mean by "unquestionable either”. Do you mean "unquestionable good”? If we don’t achieve this, then we run the heightened risk of someone being sued for using LLVM. This isn’t good for the community.> (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.> 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 still stand by my position that (2) isn't served alone by the APSL, > since it isn't clear who the contributing entity is. A click-thru CLA > for individual contributors would server the purpose for those, IMO.A CLA was carefully considered and has numerous problems depending on which one you’re talking about. The most common proposal is to use an Apache CLA (aka Google CLA), which introduces several problems we discussed in the relicensing round a year ago: it increases the barrier to entry to contribution, makes it “too easy” to relicense the code later, etc.> For non-natural legal entities as contributors, I still maintain my > position that at least under German law a proper legal agreement is > necessary to ensure that any obligations are actually enforceable.I’m not sure what you’re suggesting here. -Chris
David Chisnall via llvm-dev
2016-Nov-03 10:18 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
> On 2 Nov 2016, at 23:01, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Nov 1, 2016, at 12:21 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Mon, Sep 12, 2016 at 09:16:47AM -0700, Chris Lattner via llvm-dev wrote: >>> The goals of this effort are outlined in the previous email but, in short, we aim to: >>> - encourage ongoing contributions to LLVM by preserving low barrier to entry for contributors. >>> - protect users of LLVM code by providing explicit patent protection in the license. >>> - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. >>> - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. >> >> Hi Chris, >> let me go back to this with some of the thoughts from the last Berlin >> Social. > > Thanks! FWIW, if you or anyone else is going to be at the LLVM Dev Meeting and are interested in relicensing, then please come to the LLVM Foundation BoF. I’ll give an update there, and it’s a great place for general questions and discussion. > >> Ignoring the question of what license to choose, I see three >> different components mangled together: >> >> (1) Coherent licensing between "build time" and "run time" components. >> This part does need a license change one way or another. > > Right. > >> (2) LLVM contributors grant permissions to use their patents as far as >> necessary for their contributions. The desirability of this is >> unquestionable either. > > I’m not sure what you mean by "unquestionable either”. Do you mean "unquestionable good”? > > If we don’t achieve this, then we run the heightened risk of someone being sued for using LLVM. This isn’t good for the community.I’m still not completely convinced by this argument, given that the majority of patent lawsuits come from NPEs. 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. The Apache 2 License does nothing to prevent this, though Clause 5 of the Apache CLA would prevent it. 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.>> (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.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): 1. Company A adopts project X 2. X becomes an important part of A’s product line 3. Company B (competitor to A) contributes code infringing A’s patents to X 4. Company B sues A for infringement of another (unrelated) patent 5. Company A can’t use their patent to countersue without losing the ability to distribute X>> 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 covers all pull requests and currently gives us far more protection than any other mechanism that we have for receiving patches.>> I still stand by my position that (2) isn't served alone by the APSL, >> since it isn't clear who the contributing entity is. A click-thru CLA >> for individual contributors would server the purpose for those, IMO. > > A CLA was carefully considered and has numerous problems depending on which one you’re talking about. The most common proposal is to use an Apache CLA (aka Google CLA), which introduces several problems we discussed in the relicensing round a year ago: it increases the barrier to entry to contribution, makes it “too easy” to relicense the code later, etc.It would perhaps have been helpful for these to have been more widely enumerated. There seemed to be a lot more support both in the thread and in offline discussions for a CLA than for relicensing, yet there’s subsequently been a big push for relicensing and no discussion of a CLA. I don’t have strong objections to the Apache 2 license, but I don’t like the precedent that we’d be setting by relicensing under a less permissive license. I was happy to give permission for code that I’d contributed to be relicensed under the MIT license for inclusion in libc++, but a move in the opposite direction seems harder to accept. 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. Please compare the runtime exemption to the GPLv3 - you’ll note that it’s a lot longer, for good reason. David
Joerg Sonnenberger via llvm-dev
2016-Nov-03 13:48 UTC
[llvm-dev] RFC #2: Improving license & patent issues in the LLVM community
On Wed, Nov 02, 2016 at 04:01:34PM -0700, Chris Lattner wrote:> > Hi Chris, > > let me go back to this with some of the thoughts from the last Berlin > > Social. > > Thanks! FWIW, if you or anyone else is going to be at the LLVM Dev > Meeting and are interested in relicensing, then please come to the LLVM > Foundation BoF. I’ll give an update there, and it’s a great place for > general questions and discussion.Wrong continent for me.> > (2) LLVM contributors grant permissions to use their patents as far as > > necessary for their contributions. The desirability of this is > > unquestionable either. > > I’m not sure what you mean by "unquestionable either”. Do you mean "unquestionable good”?This is what we are trying to do already and something we want to keep doing. [snip of parts covered already by David]> > For non-natural legal entities as contributors, I still maintain my > > position that at least under German law a proper legal agreement is > > necessary to ensure that any obligations are actually enforceable. > > I’m not sure what you’re suggesting here.We still need to keep track of what legal entity is doing the contribution. The easiest case is a lone programmer -- let him/her say so once and the problem is solved until he/she gets employed and changes his/her status. For corporate entries as contributor it is somewhat more involved. I don't know what form of authorisation lawyers on both sides are happy with. It can be as simple as a company like Google or Apple signing paper work once that they agree to the patent use and that all contributions from a @google.com or @apple.com address are fine. They might want to keep track of permitted individuals, I don't know. Assuming the Github moves happens, it could be tight to the github IDs. I know some projects are already using automated checks for pull requests for proof of origin. It can be a bit work for people with multiple github accounts, but that's a different issue. Joerg
Daniel Berlin via llvm-dev
2016-Nov-03 14:50 UTC
[llvm-dev] 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 CLAWhen 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>
Apparently Analagous Threads
- RFC #2: Improving license & patent issues in the LLVM community
- RFC #2: Improving license & patent issues in the LLVM community
- RFC: Improving license & patent issues in the LLVM community
- RFC #2: Improving license & patent issues in the LLVM community
- RFC: Improving license & patent issues in the LLVM community