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

[Chris Lattner via llvm-dev]

> On Oct 20, 2015, at 9:58 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 20 Oct 2015, at 17:55, Daniel Berlin <dannyb at google.com> wrote:
>> 
>> On Tue, Oct 20, 2015 at 9:53 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
>> On 20 Oct 2015, at 17:46, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> You could ship the non-combined program.
>>> IE  You can ship an llvm jit and a gpl2 program, and jit the program
>>> on the user's machine.
>> 
>> NeXT believed that shipping the GPL-incompatible bit as a shared library that was linked on the end user’s system was enough.  
>> 
>> This is fairly different, but it delves very far into the grey area of what a derivative work is, and is likely not worth getting into on the mailing list.
>> What i suggested above is in fact, specifically foreseen and allowed by the GPL, AFAIK, and requires no tricky legal thinking.
> 
> I’m not sure about v3,

GPLv3 is fully compatible with Apache 2, which means that so is any “GPL 2 or later” code.

> but v2 only permits this if the LLVM JIT is in a separate process (which is also why GDB speaks a simple text process).

It’s not really related to your point, but I think that there are important technical issue if you’re concerned with the linux kernel specifically: linking LLVM into it is probably a really really bad idea anyway.  LLVM is not “security hardened” like you’d want from code in the kernel  address space, it is quite large (which means you’ll get a lot of non-swappable text pages, for example), and depends on a lot of user space APIs.

Ignoring licensing issues, while you could probably get an LLVM JIT to work in kernel space if you put enough effort into it, it is (IMO) an architecturally better design to put it into a user space daemon or something.  It is much easier to handle fallibility of the compiler, resource exhaustion and other issues that the compiler can hit if you do this.

>  One of the unfortunate problems with v2, which was not fully addressed in v3, is that it makes a lot of assumptions about the linkage model of C code on a UNIX-like system and so becomes very difficult to interpret when people try to use it for other languages.

There are several problems (w.r.t. patents) in GPL2.  The most significant of which is that it is apparently (reminder, IANAL) incompatible with *any* license that provides the sort of patent guarantees that we’re looking for.  The number of projects that are GPL2 but not GPL2-or-later are vanishingly small.  Just MHO, but this tradeoff seems like an easy decision to me.

-Chris