"Bryan Donlan" <[EMAIL PROTECTED]> 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. > 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. > 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. Hope this helps, /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
