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

On Tue, Oct 20, 2015 at 8:59 AM, Rafael Espíndola
<llvm-dev at lists.llvm.org> wrote:
> On 19 October 2015 at 13:57, Renato Golin via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> On 19 October 2015 at 18:12, David Chisnall via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> One worry is that Apache 2 is incompatible with GPLv2 (is it
incompatible with other licenses?)
>>
>> This is interesting, I did not know that...
>>
>> http://www.apache.org/licenses/GPL-compatibility.html
>>
>> "Despite our best efforts, the FSF has never considered the Apache
>> License to be compatible with GPL version 2, citing the patent
>> termination and indemnification provisions as restrictions not present
>> in the older GPL license."
>
> :-(
>
> This means that for example using llvm for jitting stuff in a gpl2
> program is out.
No it isn't.
It means you can't grab the combined memory image out of memory and
ship that to others.

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.

;-)
> Does anyone know of a list of current gpl2 programs?
> The two that come to mind are the linux kernel and git.
Kernel is GPLv2 only as well, so for example, you have the same issue
with any GCC jit (since it's GPLv3) ;)
>
> Does anyone know if the apache 2 is compatible with the various LGPL
versions?
>
Yes, it is.

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.  The FSF’s lawyers convinced
them otherwise (which is how some truly horrible code ended up in GCC, but I
digress).  This is reason that most Linux distributions don’t ship nVidia binary
drivers on the install CD, and instead ship a shim that permits the user to
download the drivers, whereas PC-BSD can happily include the drivers on the
install media.

David

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>

> Kernel is GPLv2 only as well, so for example, you have the same issue
> with any GCC jit (since it's GPLv3) ;)
Sure. I am just trying to understand what use cases we would be
excluding in exchange for the convenience of not needing a CLA.

Would you mind doing a quick yes/no check for a few cases:

* Linking llvm statically/dynamically into a closed source program/library.
* Linking llvm statically/dynamically into a BSD/MIT program/library.
* Linking llvm statically/dynamically into a gpl2 program/library.
* Linking llvm statically/dynamically into a lgpl2.1 program/library.
* Linking llvm statically/dynamically into a lgpl3 program/library.

Thanks,
Rafael

On Wed, Oct 21, 2015 at 7:57 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> Kernel is GPLv2 only as well, so for example, you have the same issue
>> with any GCC jit (since it's GPLv3) ;)
>
> Sure. I am just trying to understand what use cases we would be
> excluding in exchange for the convenience of not needing a CLA.
>
> Would you mind doing a quick yes/no check for a few cases:
>
> * Linking llvm statically/dynamically into a closed source program/library.
Fine
> * Linking llvm statically/dynamically into a BSD/MIT program/library.
Fine
> * Linking llvm statically/dynamically into a gpl2 program/library.
Conservatively: You can do it, you can't distribute the result.
Some argue that you can do it dynamically. If you want to be
conservative, you don't link at all, if you want to be edgy, you link
dynamically, in no case do you link statically
> * Linking llvm statically/dynamically into a lgpl2.1 program/library.
Fine both statically and dynamically, assuming you ship source or
relinkable object files to your version of LLVM in the static case
(note: This is unrelated to ASL, it's a general requirement of linking
statically with LGPL). Additionally, the larger work's terms must
allow for customer modification and reverse engineering for the
purposes of debugging those modifications (again, not specific to ASL)
> * Linking llvm statically/dynamically into a lgpl3 program/library.
Same as the LGPL2.1 case, with the added proviso that in the dynamic
case, you still have to abide by the installation information
requirements (IE give folks a way to replace binaries even if on
signed images).
>
> Thanks,
> Rafael