On 10 August 2015 at 08:06, Anselm R Garbe <garb...@gmail.com> wrote: > On 9 August 2015 at 21:31, <non...@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
