Re: Providing an openssl-linked pycurl (reviving 2010 thread)
On 25/09/14 04:18, Andrew Erickson wrote: Could an 'official' person make a ruling on Guido's email from 2010 (link below)? debian-legal does not control or enforce Debian's official position on licensing or what can go into the archive. We can offer opinions and advice, but that's about it. The relevant factors are: * (for main and contrib) is it Free Software according to the DFSG? * (for main, contrib and non-free) is the proposed situation something we can legally distribute? and the people with the final word on both these topics are the ftpmasters, Cc'd here. ftpmasters, the thread on which Andrew would like a ruling is this: https://lists.debian.org/debian-legal/2010/06/msg00016.html The bug mentioned (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515200) has lingered due to no official response. It's still very much an issue and it would be great to have a solution. Regards, S -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5423ea3d@debian.org
Re: Providing an openssl-linked pycurl
В Sat, 03 Jul 2010 10:23:16 +0100, MJ Ray написа: Yavor Doganov wrote: Not necessarily. The program may not be using OpenSSL/GnuTLS functions at all; it may link with another library (or 2 different libraries) which hide/abstract these. If the GPL program links with another library, why does it need ifdefs or configure options? Surely that's left to the library? Well, the program can check for the presence of libcurl-gnutls and libcurl, and conditionally link with it. Or, in the hypothetical case, it can conditionally use libfoo or libbar, either of which can be linked against OpenSSL/GnuTLS/NSS/etc. LuserNET doesn't use any OpenSSL functions at all. [...] Then I don't see why it's a bug in LuserNET, According to FSF's linking theory, which Debian seems to support/agree with, it is. http://lists.debian.org/debian-legal/2002/11/msg00253.html Certainly, the only way to fix this issue in lusernet.app itself is the copyright holder to grant the OpenSSL exception. Which is probably harder than some hacking on Pantomime :-) It feels more like a bug in libpantomime1.2 linking against libssl for SSL support even when that support is not required. Pantomime certainly needs SSL support to call itself framework for mail handling. Naturally, the library cannot anticipate what classes/functionality applications may need. I agree with you that it is a bug (non-RC) in pantomime that it links against OpenSSL, because this has the annoying effect that every GPL'ed app must come with the OpenSSL exception. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i0sech$8t...@dough.gmane.org
Re: Providing an openssl-linked pycurl
Yavor Doganov wrote: Sat, 03 Jul 2010 10:23:16 +0100, MJ Ray If the GPL program links with another library, why does it need ifdefs or configure options? Surely that's left to the library? Well, the program can check for the presence of libcurl-gnutls and libcurl, and conditionally link with it. Or, in the hypothetical case, it can conditionally use libfoo or libbar, either of which can be linked against OpenSSL/GnuTLS/NSS/etc. Good point (I've not been hacking C much recently). If it's using libfoo which can be linked against OpenSSL/GnuTLS, is the source of the GPL program derived from OpenSSL, though? If not, we can still distribute the version that doesn't link against libssl. I agree with you that it sounds like an awkward bug in most Pantomime-using GPL applications and wish you well with the alternative version. Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100705150907.3fc84f7...@nail.towers.org.uk
Re: Providing an openssl-linked pycurl
Yavor Doganov wrote: Thu, 01 Jul 2010 20:09:19 +0100, MJ Ray Yavor Doganov wrote: I see no difference between this scenario and a classic C program that supports both OpenSSL and GnuTLS via #ifdef's and `configure' options. In the C-ifdef scenario, the GPL program is derived from both OpenSSL and GnuTLS. That is, its programmer obviously knows about OpenSSL's functions. Not necessarily. The program may not be using OpenSSL/GnuTLS functions at all; it may link with another library (or 2 different libraries) which hide/abstract these. If the GPL program links with another library, why does it need ifdefs or configure options? Surely that's left to the library? [...] Consider a real world example. lusernet.app links against libpantomime1.2, which links against libssl for SSL support. $ ldd /usr/bin/LuserNET | grep ssl libssl.so.0.9.8 = /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb6dc2000) This is a serious bug in my book. LuserNET doesn't use any OpenSSL functions at all. [...] Then I don't see why it's a bug in LuserNET, nor how LuserNET is derived from OpenSSL. It feels more like a bug in libpantomime1.2 linking against libssl for SSL support even when that support is not required. [...] On the other hand, Pantomime can be ported to GnuTLS (it's in my TODO actually, because of the above issue), in which case it matters not from the app author's view how the library implements internally TCP connection, SSL handshake, etc. [...] That would be a great thing to do. More power to your elbow! Thanks -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100703092316.55758f7...@nail.towers.org.uk
Re: Providing an openssl-linked pycurl
В Thu, 01 Jul 2010 20:09:19 +0100, MJ Ray написа: Yavor Doganov wrote: I see no difference between this scenario and a classic C program that supports both OpenSSL and GnuTLS via #ifdef's and `configure' options. In the C-ifdef scenario, the GPL program is derived from both OpenSSL and GnuTLS. That is, its programmer obviously knows about OpenSSL's functions. Not necessarily. The program may not be using OpenSSL/GnuTLS functions at all; it may link with another library (or 2 different libraries) which hide/abstract these. In the pycurl scenario, the GPL program is derived from pycurl. The difference is that the GPL-using programmer need not know about OpenSSL's functions, so I don't see how it can be said to be derived from it. It would even be written the same in a world without OpenSSL, as long as pycurl is the same whether it's a version derived from OpenSSL or a version derived from GNUTLS. Can you explain why the GPL program using pycurl is derived from OpenSSL, please? Consider a real world example. lusernet.app links against libpantomime1.2, which links against libssl for SSL support. $ ldd /usr/bin/LuserNET | grep ssl libssl.so.0.9.8 = /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb6dc2000) This is a serious bug in my book. LuserNET doesn't use any OpenSSL functions at all. Now, it would be fairly trivial to modify the program to add NNTPS support, without resorting to OpenSSL, and without even using Pantomime's SSL-specific methods. On the other hand, Pantomime can be ported to GnuTLS (it's in my TODO actually, because of the above issue), in which case it matters not from the app author's view how the library implements internally TCP connection, SSL handshake, etc. The programmer need not know about OpenSSL/GnuTLS functions per se. This is practically the same situation as the one you describe for pycurl. So, as long as debian usually installs the gnutls-linked variant, no problem, right? It's up to the user if they want to modify their system to install the variant that may cause distribution/licensing problems. Merely having it available doesn't seem like a problem to me. Yes, this issue is a real problem only for distributors. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i0kck7$1k...@dough.gmane.org
Re: Providing an openssl-linked pycurl
MJ Ray m...@phonecoop.coop writes: I think the suggestion is that software using python-pycurl would not change if they were using openssl or gnutls. I don't understand how the GPL'd software is derived from openssl if it works interchangably with gnutls on the other side of pycurl. Can you explain? Even if it was legal, I would strongly object against replacing python-pycurl with the OpenSSL version. In that case one would have to comply to different license requirements depending on the functions one uses within pycurl. Even if properly documented, this is asking for undistributable code to be written, which might take ages to resolve. Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86tyojhf2b@mid.gienah.enyo.de
Re: Providing an openssl-linked pycurl
В Wed, 30 Jun 2010 21:35:45 +0100, MJ Ray написа: I think the suggestion is that software using python-pycurl would not change if they were using openssl or gnutls. I don't understand how the GPL'd software is derived from openssl if it works interchangably with gnutls on the other side of pycurl. Can you explain? I see no difference between this scenario and a classic C program that supports both OpenSSL and GnuTLS via #ifdef's and `configure' options. Or a C program linking against an LGPL'ed library which links against libssl. If the library is modified to use GnuTLS instead, the program would still continue to work with that variant of the library interchangably (provided it is API/ABI compatible, of course). If the program is using the gnutls-linked variant of the library, it needs no exception. If it is using the openssl-linked variant, it does because of the indirect linking with libssl. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i0hkej$9o...@dough.gmane.org
Re: Providing an openssl-linked pycurl
Yavor Doganov wrote: Wed, 30 Jun 2010 21:35:45 +0100, MJ Ray I think the suggestion is that software using python-pycurl would not change if they were using openssl or gnutls. I don't understand how the GPL'd software is derived from openssl if it works interchangably with gnutls on the other side of pycurl. Can you explain? I see no difference between this scenario and a classic C program that supports both OpenSSL and GnuTLS via #ifdef's and `configure' options. In the C-ifdef scenario, the GPL program is derived from both OpenSSL and GnuTLS. That is, its programmer obviously knows about OpenSSL's functions. In the pycurl scenario, the GPL program is derived from pycurl. The difference is that the GPL-using programmer need not know about OpenSSL's functions, so I don't see how it can be said to be derived from it. It would even be written the same in a world without OpenSSL, as long as pycurl is the same whether it's a version derived from OpenSSL or a version derived from GNUTLS. Can you explain why the GPL program using pycurl is derived from OpenSSL, please? Or a C program linking against an LGPL'ed library which links against libssl. If the library is modified to use GnuTLS instead, the program would still continue to work with that variant of the library interchangably (provided it is API/ABI compatible, of course). If the program is using the gnutls-linked variant of the library, it needs no exception. If it is using the openssl-linked variant, it does because of the indirect linking with libssl. So, as long as debian usually installs the gnutls-linked variant, no problem, right? It's up to the user if they want to modify their system to install the variant that may cause distribution/licensing problems. Merely having it available doesn't seem like a problem to me. I repeat that I feel the best solution is to bugfix GNUTLS, broken software or broken servers, before they break the OpenSSL variant too. Rebuilding pycurl seems like a dirty/uncertain workaround. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100701190919.78b4ef7...@nail.towers.org.uk
Re: Providing an openssl-linked pycurl
On Tuesday 29 Jun 2010, Guido Trotter wrote: [snip] 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? Without having any idea about the specific issues between Python and OpenSSL and their licences, would this have any bearing on your question? The issues appear to be related: http://search.cpan.org/~pmqs/BerkeleyDB-0.31/BerkeleyDB.pod#COPYRIGHT Have a look at the boxed text. Standard disclaimers apply. Regards, -- Raj -- Raj Mathurr...@kandalaya.org http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F PsyTrance Chill: http://schizoid.in/ || It is the mind that moves -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006301200.30476.r...@linux-delhi.org
Re: Providing an openssl-linked pycurl
On Wed, Jun 30, 2010 at 12:00:30PM +0530, Raj Mathur (राज माथुर) wrote: Hi, Without having any idea about the specific issues between Python and OpenSSL and their licences, would this have any bearing on your question? The issues appear to be related: http://search.cpan.org/~pmqs/BerkeleyDB-0.31/BerkeleyDB.pod#COPYRIGHT Have a look at the boxed text. Standard disclaimers apply. Thanks. I think this doesn't quite solve the issue, as IIRC the problem is not that you can't link GPL and Openssl (if you do it yourself, you can) but that you can't redistribute the result, if you're the same entity that distributes openssl itself. But again, the issue at hand was more related to the library, and I think there are no doubts on its status (since it's LGPL or MIT/X anyway, and not GPL). As long as the gnutls version also stays nobody should be unhappy. Thanks, Guido -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630081157.gb20...@gg.studio.tixteam.net
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 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630080852.ga20...@gg.studio.tixteam.net
Re: Providing an openssl-linked pycurl
В Tue, 29 Jun 2010 14:57:24 +0100, Guido Trotter написа: - 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? Yes. Now, what would be the status of (unmodified) GPL python software which imports pycurl? According to the FSF licensing team, such software must be under GPL+OpenSSL exception. http://lists.debian.org/debian-legal/2009/04/msg00038.html -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i0f16m$he...@dough.gmane.org
Re: Providing an openssl-linked pycurl
Yavor Doganov wrote: Tue, 29 Jun 2010 14:57:24 +0100, Guido Trotter Now, what would be the status of (unmodified) GPL python software which imports pycurl? According to the FSF licensing team, such software must be under GPL+OpenSSL exception. http://lists.debian.org/debian-legal/2009/04/msg00038.html Where such software is gajim which was using the Python OpenSSL bindings. I think the suggestion is that software using python-pycurl would not change if they were using openssl or gnutls. I don't understand how the GPL'd software is derived from openssl if it works interchangably with gnutls on the other side of pycurl. Can you explain? Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630203545.66d83f7...@nail.towers.org.uk
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? http://packages.debian.org/changelogs/pool/main/p/pycurl/current/copyright 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, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630021105.d2986f7...@nail.towers.org.uk
