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

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 20 22:15:11 PDT 2015

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? 


More information about the llvm-dev mailing list