llvm dev - Oct 2015 - RFC: Improving license & patent issues in the LLVM community

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151020/9babf5ca/attachment.html>

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, but v2 only permits this if the LLVM JIT is in a separate
process (which is also why GDB speaks a simple text process).  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.

David

> 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