[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Providing an openssl-linked pycurl

Guido Trotter wrote:
> According to my understandment:
> - OpenSSL is released under a license which is GPL incompatible, unless an
>   exception to the GPL is used in the software compiled with it. Debian cannot
>   distribute GPL software released under the unmodified GPL and linked against
>   OpenSSL.
> - pycurl is released under the LGPL (2.1 or later) or a MIT/X derivative
>   license based on the one of curl itself. Neither of these licenses is
>   incompatible with OpenSSL, and as for curl itself we should be able to
>   provide a version of pycurl which uses openssl.
> Am I correct up to here?

suggests so.

> Now, what would be the status of (unmodified) GPL python software which imports
> pycurl? Is this considered the same as linking, and would it have to make sure
> it uses the GNUTLS version, by depending on it?

What GNUTLS version?  Oh, it looks like that's the current version.

As I understand it, if the GPL python software were derived from
openssl in some way, then there would be a problem.  Otherwise, not.
If it worked with a GNUTLS version of pycurl
unmodified/interchangably, I think it's unlikely there's a problem.

But then the GNUTLS version must exist to be sure things work, so why
not use the GNUTLS version?  In the case of bug 515200, the report
about www1.banking.first-direct.com has a solution in bug 532752
(which maybe could be used by some setopt call in pycurl?), while the
dynamic routing firewall problem awaits more information in bug 532752
since June 2009.

If there are bugs in GNUTLS or remote servers, please try to help
their maintainers to debug them, rather than rebuilding every single
gnutls-using package to use openssl and spread a licensing can of
worms which gnutls helps to keep closed.

Also, is rebuilding even a proper fix for 515200?  It looks like
www1.banking.first-direct.com might have a problem and I suspect maybe
if/when openssl supports whatever feature is causing connection
problems (TLS1.1?), it might fail too then.

> This might open discussions about how to provide the feature tecnically (different module
> names in python, conflicting packages, etc) and make sure legality is kept, but
> in the meantime we'd just like a legal opinion on what would or would not be
> ok. (also considering it's OK for a user to use GPL+OpenSSL software if he
> wants, it's just not OK for us to distribute it).

To be clear: I do not offer a legal opinion.  I am not a lawyer.  Ask
one if you want legal opinion.  If you want the debian project to ask,
I think you need to persuade some official (ftp-master or leader seem
most likely) to request it.

Hope that explains,
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

Reply to: