Re: GPL and OpenSSL in libs3
On Sat, Aug 16, 2008 at 9:31 AM, Simon Josefsson <simon@josefsson.org> wrote:
> "Bryan Donlan" <bdonlan@gmail.com> writes:
>
>> Hi,
>>
>> I've recently been discussing[1] with another developer his libs3
>> library - a library to access amazon's S3. It is licensed under the
>> GPLv3, but links to curl, which in turn links to openssl. It's
>> possible to port libs3 to use curl+libgnutls instead (although not as
>> easy as rebuilding curl, as libs3 makes use of certain cryptographic
>> primitives itself), but the result breaks on windows.
>
> Which symbols does libs3 need from openssl? There is a GPLv3
> libgnutls-openssl which provides some additional OpenSSL symbols.
> Possibly it is sufficient. If not, patches to improve the library are
> always welcome. Then you could link libs3 to libcurl-gnutls and
> libgnutls-openssl.
It only uses the SHA1-HMAC implementation. It's simple enough to port,
but the problem is on windows - apparently gnutls doesn't work too
well there. While it's probably possible to make it conditionally
compilable, I'm worried that would only confuse the situation more -
if someone writes code against it under only GPLv3, the result would
be undistributable /only on windows/... I'd be more inclined to drop
in the SHA-1 reference C code (which is copyright-free as it is a
product of the US federal government, I believe?)
>> 1) If the library is conditionally compilable against either
>> curl+openssl or curl+gnutls, only dynamically links against either
>> (neither the library nor user executables would directly reference
>> openssl or its symbols), and doesn't make direct use of the library
>> (the aforementioned crypto primitives can be replaced with public
>> domain reference implementations), wouldn't this be sufficient to make
>> the library's users not derivative works of openssl, and thus allow
>> ordinary GPL code to link?
>
> That needs to depend on the "system library" clause in the GPL for
> libssl, and libssl isn't considered a system library in Debian as far as
> I understand.
However, if the library links against only libcurl (on any platform),
and does not use any symbols from, nor does it have a dynamic linker
reference to openssl, then $app+$library in a vacuum has no reference
to either gnutls or openssl - how could this be considered a license
violation when the offending element is introduced by the end-user,
and GPLv3 explicitly allows the end-user to do whatever they wish
without redistribution? Of course, this would mean it can't be
distributed along with a libcurl with SSL support, which is
unfortunate...
If submitted to debian it would of course use libcurl-gnutls; again,
the worry I have here is again the confusion with windows.
>> 2) If not, is there a recommended way to deal with this situation?
>
> Link to libcurl-gnutls and solve any problem it brings. Make libs3 use
> libgcrypt if it needs low-level cryptographic primitives, for example.
Unfortunately I'm not enough of a windows programmer to fix whatever
problems upstream had with gnutls :)
Reply to: