Hi, On Wed, 2019-03-20 at 16:31 +0100, Ansgar Burchardt wrote: > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger > than just libpq5: just looking at a small sample of the direct rdeps > of > libssl1.1, one can find the following GPL-licensed programs linking > it: > > cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete > > Also amanda-client, validns as they contain patches in d/patches > licensed under the GPL. > > There are probably lots more, especially when you start looking at > libraries (and their whole dependency trees). > > There is also cups which was reported to switch to Apache-2 which is > also GPL-2-incompatible... That has lots of rdeps too (including for > example all GTK applications).
Also Python programs which often use libssl and are GPL-licensed. > Fedora treats OpenSSL as a "system library"[1]. I would guess they > might do the same for libcups too. I also came up with another interesting problem: libgcc and other low- level runtime libraries are licensed under GPL-3+-with-some-exception. However for a GPL-2-only program FOO with *no* system library exception, the complete source code would include libgcc and would require libgcc do be available under a GPL-2-compatible license... The runtime exception from libgcc doesn't help as FOO would need an exception... (I.e. the same problem just with libgcc instead of libssl) Ansgar
