Re: [dev] MIT/BSD licensed ELF linker?

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Tue, 11 Aug 2015 20:48:00 +0200

On 10 August 2015 at 08:06, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> On 9 August 2015 at 21:31, <noname_AT_inventati.org> wrote:
>> On Thu, Aug 06, 2015 at 07:50:30AM +0200, Anselm R Garbe wrote:
>>> I need to investigate further. But probably I will rather go with a
>>> static gold linked against glibc to produce smaller binaries and to be
>>> GPL compliant....
>>
>> I do not understand what the problem is.
>>
>> It is ok to compile GPL program (gold) with MIT licensed libraries
>> (musl). In this case you have a GPL licensed binary `gold'. You can use
>> it to link MIT licensed programs and get MIT licensed binaries as
>> output. How is it different from using GPLed compiler? BSD systems are
>> using GCC without any problems.
>
> I presume that you are referring to the system library exception[0] of GPL?
>
> The concern I have is not about compiling, but about _statically_
> linking and distributing binaries that contain mixed license .o's.

I checked with the FSF on this topic and they confirmed that it is
fine to distribute statically linked _binaries_ under the terms of GPL
in case that the source consists of mixed GPL and GPL-compatible
licenses[0] (like MIT/X). So, I will just publish such binaries under
the terms of GPL.

In all other cases I will publish the binaries under MIT/X as long as
possible in mixed license cases.

There are cases though, where a GPL-incompatible license like the
OpenSSL license (also used by libressl) might come into play. In such
cases we aren't allowed to distribute GPL portions in a mixed static
binary under the terms of GPL of course... Not sure if we will hit
this case, but it could happen in case of a browser... will see. In
such cases I'm tempted to use the hack, that the end-user must perform
the final linkage of the binary, so that stali is free of this problem
from a distribution point of view.

Best regards,
Anselm
Received on Tue Aug 11 2015 - 20:48:00 CEST

This archive was generated by hypermail 2.3.0 : Tue Aug 11 2015 - 21:00:06 CEST