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

[Daniel Berlin via llvm-dev]

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