Re: GPL and OpenSSL in libs3
"Bryan Donlan" <bdonlan@gmail.com> writes:
> 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.
There is <http://josefsson.org/gnutls4win/> and I'd be interested to
learn what's it is missing. ;)
> 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/...
This is not uncommon, many projects can be linked against openssl,
gnutls or any other TLS library with other licensing conditions. People
building the software must pay attention to the license of the various
libraries involved.
> 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?)
There are plenty of HMAC-SHA1 implementations around, so that may indeed
be simpler.
>>> 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?
End users can do whatever they want, GPL is mostly related to when you
redistribute the software.
> Of course, this would mean it can't be distributed along with a
> libcurl with SSL support, which is unfortunate...
Right.
> If submitted to debian it would of course use libcurl-gnutls; again,
> the worry I have here is again the confusion with windows.
There is no confusion, just some complexity. The license situation can
be described in the documentation. Unfortunately, this is a fairly
common problem, so the solutions are relatively well understood
engineering-wise.
>>> 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 :)
Darn.
/Simon
Reply to: