> On Jun 21, 2015, at 12:29 AM, TheSin <the...@southofheaven.org> wrote: > > if the license says that pens can not be distributed in binary form wouldn’t > it only be ssl that needs to be built, couldn’t other packages which only > dynamically use the dylib still be binary distributed since it does not > contain the open ssl code or library directly it only uses and as such is > useless without it, aka it wouldn’t run unless you downloaded and build > openssl, so think like cvs and wget etc etc could still be binary available > just openssl needs to be built form source first? > > Obviously if something links ssl using a .a or static link it would then be > restrictive as well since the ssl binary is now included but dynamic link > should be fine I would imagine since none of the ssl code is in it.
Unfortunately, the GPL explicitly forbids distributing binaries that *link* to a library with a non-compatible license, even a shared library, whether or not said library is also distributed. The exception is for libraries that are part of the OS. Distributing OpenSSL binaries isn’t a problem since its license is more liberal than the GPL. It seems that the issue boils down to this: the OpenSSL license requires things that use it to contain an OpenSSL copyright notice. The GPL forbids that, therefore there’s no way to satisfy both unless the GPL’d program explicitly allows OpenSSL to be used (which many do). I believe LGPL is OK since it allows linking to even propriety code. Also, non-GPL programs are fine, e.g. subversion uses Apache 2.0 license and has no issue. Neither does python. Hopefully there’ll be more incentive for projects to use native SecureTransport now that OpenSSL is gone from 10.11. Libcurl and git have already switched. I guess we need to audit the openssl-using packages to see if they’re compatible, otherwise mark them Restricted. This was easier when we didn’t have a bindist. :) IANAL Daniel
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------
_______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel