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

[David Chisnall via llvm-dev]

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.