Chris Lattner via llvm-dev
2015-Oct-21 05:12 UTC
[llvm-dev] RFC: Improving license & patent issues in the LLVM community
Hi David, Sorry for the delay getting back to you, been a bit buried: On Oct 19, 2015, at 10:12 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:>> The TL;DR version of this is that I think we should discuss relicensing all of LLVM under the Apache 2.0 license and add a runtime exception clause. See below for a lot more details. > > I agree that this is a problem. In another community, we’ve deployed an Apache-style CLA. From a legal perspective, it’s definitely the best way forward, but it does add a significant barrier to entry (though not as big as copyright assignment, as for FSF projects). I have two concerns, one related to the Apache 2 license in general, the other related to switching license in general. > > Because LLVM has not had a policy of including copyright holders in files (something else that we should change), it’s difficult to identify copyright holders. When we relicensed libcompiler_rt and libc++ under the MIT license, there were only a few contributors and it was easy to identify us all. Over LLVM, it’s not clear that the people who have committed code on behalf of others have been good at ensuring that it’s correctly attributed. I’d be interested to hear what the Foundation’s strategy for dealing with this is (and what will happen if a contributor of a significant amount of code does not permit their code to be relicensed if the overall consensus appears to be in favour of relicensing).I’m intentionally trying to separate the discussion of “what to do” from the “how to do it” discussion (both topics are complex and could confuse the issue). If we can gain consensus on direction, then we can turn to logistics. I completely agree with you that this will be a pain and a lot of work. I have no personal experience with such an effort, but I have spoken to a few folks who have done similar things in other large scale projects to discuss the viability of this. They seem to think it is possible, and there are multiple possible paths to get from here to there if the community agrees that it is the right path.> On the Apache 2 front specifically, we’ve been slowly reducing the amount of Apache 2 code in FreeBSD and would be quite unhappy to suddenly increase it. LLVM is one of the largest bits of contrib code in our base system and, for us, it would be a step in the wrong direction. One worry is that Apache 2 is incompatible with GPLv2 (is it incompatible with other licenses?), which limits the number of places where it can be used (though possibly not to a degree worth worrying about). A related concern is that I can read the UIUC and, as a non-lawyer, be pretty sure that I understand it. I can not make the same claim about Apache 2, in spite of having read it several times. It’s probably not a show-stopper for us, but it would probably reduce LLVM contributions from within the FreeBSD community, which is something that’s been slowly increasing recently.I am truly sorry that the FreeBSD community would see this as a step backward. I believe that I have covered both of these points in other posts, but to summarize: - My understanding is that “GPL2-and-not-later” projects are extremely rare. Apache 2 is compatible with GPL3 code, and the FSF recommends use of Apache 2 for permissively licensed code (because they see the patent protection as being valuable). Is there a specific set of affected GPL2-only code that we should consider? Note that it will still be fine to *compile* GPL2 with Clang for example, it is only linking LLVM code into a GPL2-only app that would become a problem. - Apache 2 is definitely a longer and more complex license than (e.g.) MIT, BSD, or UIUC licenses. However, it is the only prominent choice that achieves our goals. If you have other suggestions for consideration, I’d welcome it. Does the FreeBSD project see any value in the patent coverage provided by the Apache 2 license, or is it really a net negative? In your opinion, would this cause the FreeBSD to look to abandon use of LLVM code, or would it just cause some amount of discomfort/unhappiness? -Chris
David Chisnall via llvm-dev
2015-Oct-21 09:10 UTC
[llvm-dev] RFC: Improving license & patent issues in the LLVM community
On 21 Oct 2015, at 06:12, Chris Lattner <clattner at apple.com> wrote:> > - Apache 2 is definitely a longer and more complex license than (e.g.) MIT, BSD, or UIUC licenses. However, it is the only prominent choice that achieves our goals. If you have other suggestions for consideration, I’d welcome it.The other alternative would be a separate patent license (Google’s VP8 is the most high-profile project that I’m aware of to use this model), so the copyright license and the patent license are orthogonal.> Does the FreeBSD project see any value in the patent coverage provided by the Apache 2 license, or is it really a net negative? In your opinion, would this cause the FreeBSD to look to abandon use of LLVM code, or would it just cause some amount of discomfort/unhappiness?I don’t think that anyone objects to the patent protection, it’s the complexity of the license and its reduced ability to compose with other licenses, combined with the perceived lack of real benefit, that people seem to object to (note: most of the opinions here I’m relaying from other FreeBSD developers - I have no strong feelings either way on the Apache 2 license. We use a modified[1] version of it at work). If I write BSDL (or MITL, or UIUCL) code, then I know that I can use it in every single place where I may wish to use it. This is less true with ASL2. In particular, though the number of GPLv2-only projects is small, there are still a lot of GPLv2 or later projects. I can accept GPLv2, modify them in a way that incorporates LLVM today and redistribute the result, and not at any point have accepted GPLv3. If I modify them to adopt ASL2 code and redistribute the result then I am accepting GPLv3, and I share your employer’s reluctance to do this. This *has* blocked me from using CLucene in a project that incorporated GPLv2 code in the past, so I don’t consider it to be much of a stretch to imagine that I’d encounter similar reservations with regard to an ASL2 LLVM. From the FreeBSD perspective (note: this is my informed opinion as a member of the the Core Team, but should not be construed as official project policy): With a license change, LLVM would still be our best option for the default toolchain and a few other things. The main difference that you’re likely so see is that the growing number of people who work on both LLVM and FreeBSD would shrink. I think that this would be bad for FreeBSD, as the overlap in contributors to both projects has been a significant benefit for us. Neither ASL2 nor the contributors’ agreement (which would be my preferred choice) protect against what I regard as the largest patent threat: code contributed by one entity that infringes the patent owned by another entity. The vast majority of patent problems that open source projects have had in the past have been of this form, typically with NPEs. No license or CLA (unless it tries to attach a requirement that the contributor indemnify the project, which would basically kill contributions from individuals) can protect against this. I think that we have three possible cases: - Contributor A submits something that infringes a patent owned by A. Even if this is not covered by estoppel, in the US at least, you can’t claim damages that occurred between being aware of the infringement and sending the C&D notice. It’s hard to argue that you weren’t aware that code that you contributed infringed a patent that you owned convincingly, so this case would be handled by reverting the patch on receiving the C&D and kicking contributor A out of the project. - Contributor A submits something that infringes a patent owned by NPE B. In this case, no license or CLA will help. Anyone who has distributed LLVM is a target for a lawsuit and it’s very messy and annoying, but not addressed by ASL2 or a CLA. - Contributor A submits something that infringes a patent owned by contributor B. The terms of the ASL2 are a bit interesting there. To take a hypothetical example, if IBM has some code in LLVM (I think that have quite a bit in the PowerPC back end now) and I decide to implement RCU with all of the go-faster stripes that are still patented in libSupport, then they can sue me, but in doing so they would immediately lose the rights to any other patents that entities own in LLVM, so now I have neatly sidestepped their [L]GPL-only patent grant for these. This isn’t totally hypothetical, by the way: there are some folks in your employer’s CoreOS team who would be very happy to see this happen... It seems as if the proposed change only protects us from the last case, by providing an explicit termination clause. A separate patent license that contained a similar termination clause would have a similar outcome. It would also be easier to deploy, as the only people who would need to agree to it retroactively are those that own any patents, which I believe is a fairly small subset of LLVM contributors. Even then, the choice between allowing third parties to contribute code that infringes your patents, or losing the rights to distribute an important piece of software for your product, is what made a lot of companies unwilling to adopt GPLv3, so I’d imagine some push-back. David [1] The Apache *Software* License is a software license, so needed extending to explicitly cover the things that we were licensing.
Jonas Maebe via llvm-dev
2015-Oct-21 12:18 UTC
[llvm-dev] RFC: Improving license & patent issues in the LLVM community
David Chisnall via llvm-dev wrote on Wed, 21 Oct 2015:> I think that we have three possible cases: > > - Contributor A submits something that infringes a patent owned by A...> - Contributor A submits something that infringes a patent owned by NPE B... There's also the combination of these two: contributor A submits something that infringes a patent owned by A, later on goes bankrupt and their patents get acquired by NPE B (or their new management is headed by Darl McBride). I think in that case the patent license also could be valuable. Jonas
Arnaud A. de Grandmaison via llvm-dev
2015-Oct-21 12:52 UTC
[llvm-dev] RFC: Improving license & patent issues in the LLVM community
Hi David,> - Contributor A submits something that infringes a patent owned by A...I think the proposal also addresses this case (the first one in your email). I believe several companies have some sort of process to ensure this does not happen (clean room, training, peer review, legal review, ...), but the risk will never be zero. And the more contributors a company has / the more contributions a company makes will only make the risk become a fact ... after some time. This proposal really acts as a risk containment: if company A erroneously contributed in this case, then company A is protected (only the necessarily infringed patents are affected) as well as the users of this contribution. Beside, this protection would be made clearly in the license file in the source tree, not in a separate web page. I think there is some merit in having all the legal blurb in a single place within the source tree as well as attempting some clarification on the patent subject. I personally see this as a step in the right direction. Kind regards, -- Arnaud> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David > Chisnall via llvm-dev > Sent: 21 October 2015 11:10 > To: Chris Lattner > Cc: llvm-dev > Subject: Re: [llvm-dev] RFC: Improving license & patent issues in the LLVM > community > > On 21 Oct 2015, at 06:12, Chris Lattner <clattner at apple.com> wrote: > > > > - Apache 2 is definitely a longer and more complex license than (e.g.) MIT, > BSD, or UIUC licenses. However, it is the only prominent choice that achieves > our goals. If you have other suggestions for consideration, I’d welcome it. > > The other alternative would be a separate patent license (Google’s VP8 is the > most high-profile project that I’m aware of to use this model), so the > copyright license and the patent license are orthogonal. > > > Does the FreeBSD project see any value in the patent coverage provided > by the Apache 2 license, or is it really a net negative? In your opinion, would > this cause the FreeBSD to look to abandon use of LLVM code, or would it just > cause some amount of discomfort/unhappiness? > > I don’t think that anyone objects to the patent protection, it’s the complexity > of the license and its reduced ability to compose with other licenses, > combined with the perceived lack of real benefit, that people seem to object > to (note: most of the opinions here I’m relaying from other FreeBSD > developers - I have no strong feelings either way on the Apache 2 license. > We use a modified[1] version of it at work). If I write BSDL (or MITL, or > UIUCL) code, then I know that I can use it in every single place where I may > wish to use it. This is less true with ASL2. > > In particular, though the number of GPLv2-only projects is small, there are > still a lot of GPLv2 or later projects. I can accept GPLv2, modify them in a way > that incorporates LLVM today and redistribute the result, and not at any > point have accepted GPLv3. If I modify them to adopt ASL2 code and > redistribute the result then I am accepting GPLv3, and I share your > employer’s reluctance to do this. This *has* blocked me from using CLucene > in a project that incorporated GPLv2 code in the past, so I don’t consider it to > be much of a stretch to imagine that I’d encounter similar reservations with > regard to an ASL2 LLVM. > > From the FreeBSD perspective (note: this is my informed opinion as a > member of the the Core Team, but should not be construed as official > project policy): With a license change, LLVM would still be our best option for > the default toolchain and a few other things. The main difference that > you’re likely so see is that the growing number of people who work on both > LLVM and FreeBSD would shrink. I think that this would be bad for FreeBSD, > as the overlap in contributors to both projects has been a significant benefit > for us. > > Neither ASL2 nor the contributors’ agreement (which would be my preferred > choice) protect against what I regard as the largest patent threat: code > contributed by one entity that infringes the patent owned by another entity. > The vast majority of patent problems that open source projects have had in > the past have been of this form, typically with NPEs. No license or CLA > (unless it tries to attach a requirement that the contributor indemnify the > project, which would basically kill contributions from individuals) can protect > against this. I think that we have three possible cases: > > - Contributor A submits something that infringes a patent owned by A. Even > if this is not covered by estoppel, in the US at least, you can’t claim damages > that occurred between being aware of the infringement and sending the > C&D notice. It’s hard to argue that you weren’t aware that code that you > contributed infringed a patent that you owned convincingly, so this case > would be handled by reverting the patch on receiving the C&D and kicking > contributor A out of the project. > > - Contributor A submits something that infringes a patent owned by NPE B. > In this case, no license or CLA will help. Anyone who has distributed LLVM is > a target for a lawsuit and it’s very messy and annoying, but not addressed by > ASL2 or a CLA. > > - Contributor A submits something that infringes a patent owned by > contributor B. The terms of the ASL2 are a bit interesting there. To take a > hypothetical example, if IBM has some code in LLVM (I think that have quite > a bit in the PowerPC back end now) and I decide to implement RCU with all of > the go-faster stripes that are still patented in libSupport, then they can sue > me, but in doing so they would immediately lose the rights to any other > patents that entities own in LLVM, so now I have neatly sidestepped their > [L]GPL-only patent grant for these. This isn’t totally hypothetical, by the way: > there are some folks in your employer’s CoreOS team who would be very > happy to see this happen... > > It seems as if the proposed change only protects us from the last case, by > providing an explicit termination clause. A separate patent license that > contained a similar termination clause would have a similar outcome. It > would also be easier to deploy, as the only people who would need to agree > to it retroactively are those that own any patents, which I believe is a fairly > small subset of LLVM contributors. Even then, the choice between allowing > third parties to contribute code that infringes your patents, or losing the > rights to distribute an important piece of software for your product, is what > made a lot of companies unwilling to adopt GPLv3, so I’d imagine some push- > back. > > David > > [1] The Apache *Software* License is a software license, so needed > extending to explicitly cover the things that we were licensing. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Daniel Berlin via llvm-dev
2015-Oct-21 15:01 UTC
[llvm-dev] RFC: Improving license & patent issues in the LLVM community
> - Contributor A submits something that infringes a patent owned by A. Even if this is not covered by estoppel, in the US at least, you can’t claim damages that occurred between being aware of the infringement and sending the C&D notice.I'm not sure why you believe this :-) In fact, the company i work for has been sued, and lost, in the past, for many millions of dollars for patents owned by people who contributed them, in code, to us, and then later claimed exactly this. This is one of the things that forced us to move to a strict CLA policy.> for has been sued in the past It’s hard to argue that you weren’t aware that code that you contributed infringed a patent that you owned convincingly,Except i have empirical evidence that it happens all the time .... ;-)> so this case would be handled by reverting the patch on receiving the C&D and kicking contributor > A out of the project.With no real offense meant: Whatever lawyer told you this is what would happen is having some serious delusions :)> > - Contributor A submits something that infringes a patent owned by NPE B. In this case, no license or CLA will help. Anyone who has distributed LLVM is a target for a lawsuit and it’s very messy and annoying, but not addressed by ASL2 or a CLA.Sure, yes.> > - Contributor A submits something that infringes a patent owned by contributor B. The terms of the ASL2 are a bit interesting there. To take a hypothetical example, if IBM has some code in LLVM (I think that have quite a bit in the PowerPC back end now) and I decide to implement RCU with all of the go-faster stripes that are still patented in libSupport, then they can sue me, but in doing so they would immediately lose the rights to any other patents that entities own in LLVM, so now I have neatly sidestepped their [L]GPL-only patent grant for these. This isn’t totally hypothetical, by the way: there are some folks in your employer’s CoreOS team who would be very happy to see this happen... > > It seems as if the proposed change only protects us from the last case, by providing an explicit termination clause. A separate patent license that contained a similar termination clause would have a similar outcome. It would also be easier to deploy, as the only people who would need to agree to it retroactively are those that own any patents, which I believe is a fairly small subset of LLVM contributors. Even then, the choice between allowing third parties to contribute code that infringes your patents, or losing the rights to distribute an important piece of software for your productThis is mostly right, with one important caveat:On termination you only lose patent rights, not copyright rights. If there are no patent rights that interest you, you can still distribute it willy-nilly without fear. Given the larger cross-licensing schemes that often exist between large companies, this may, in fact, be the case. (FWIW: i'm personally in favor of terminating all rights, but such a license is not GPLv2 or v3 compatible, sadly)> is what made a lot of companies unwilling to adopt GPLv3, so I’d imagine some push-back. >Flat out: Companies who want to retain the right to sue people over LLVM probably are not companies you want in the community. Period.
Chris Lattner via llvm-dev
2015-Oct-31 22:05 UTC
[llvm-dev] RFC: Improving license & patent issues in the LLVM community
On Oct 21, 2015, at 2:10 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:>> Does the FreeBSD project see any value in the patent coverage provided by the Apache 2 license, or is it really a net negative? In your opinion, would this cause the FreeBSD to look to abandon use of LLVM code, or would it just cause some amount of discomfort/unhappiness? > > In particular, though the number of GPLv2-only projects is small, there are still a lot of GPLv2 or later projects. I can accept GPLv2, modify them in a way that incorporates LLVM today and redistribute the result, and not at any point have accepted GPLv3.Hi David (and others), There are a number concerns around the incompatibility with GPLv2. I’m taking these seriously and will get back to you all, but it will take some time to dig into it. Thank you for your patience, I’m not ignoring this topic. -Chris