Re: Providing an openssl-linked pycurl
On Wed, Jun 30, 2010 at 06:59:01AM +0100, MJ Ray wrote:
Hi,
> > 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?
>
> http://packages.debian.org/changelogs/pool/main/p/pycurl/current/copyright
> suggests so.
>
Thanks.
> What GNUTLS version? Oh, it looks like that's the current version.
>
The idea I think is to provide both, as curl itself does.
> 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.
Thanks for the further clue.
>
> 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.
>
I'm not aware of any specific bug; I've just been asked if under debian we would
have an option of running under pycurl with openssl on Debian by a colleague who
is looking at that part of the code for our project and I guess his reasons are
not having to make sure the code works with either GNUTLS and OpenSSL, and that
we might need to support OpenSSL anyway.
I agree with you that it's good to improve GNUTLS, but OpenSSL is still free
software and still distributed by Debian, so it's also good to have choice.
> > 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.
>
I didn't want a lawyer's opinion, just a look at the issue by -legal people to
make sure we weren't missing anything evident. Unless we have specific
guidelines that say we should, for this kind of issue, I think that the fact
that we looked at it and things seem ok ought to be enough: we would't move very
far if we had to ask a lawyer for permission on everything we do. :)
Now I guess it's up to the maintainer to see if he's willing to
do/accept/support the change, and for us to reach an agreement whether
technically it makes sense.
That said projects under the GPL without openssl exceptions which wanted to use
the pycurl library with OpenSSL can still ask for advice or refrain to do so:
this has nothing to do with the library itself anyway. :)
Thanks,
Guido
Reply to: