Re: curl situation is intolerable
On 9/13/05, Peter Samuelson [EMAIL PROTECTED] wrote: [Olaf van der Spek] I thought that if the interface matches the user can link whatever he wants, because he doesn't (re)distribute the results. [Steve Langasek] There isn't universal agreement on this point, and it's never actually been tested in court. There isn't? I thought this has been standard GPL lore for a very long time - if you link to an *interface* which has a GPL-compliant implementation, it does not matter if you also are incidentally runtime- compatible with a non-GPL-compatible implementation. Some have argued back and forth about how useful or bug-free the GPL-compliant implementation must be before it counts, but that seems not to be an issue here - both SSL backends are said to be functional, if not 100% feature- and bug-equivalent. From a common-sense standpoint, it's pretty hard to argue that some software is derived from openssl if any user could run the same binary with only gnutls on his system. The next question would then be: is it allowed to implement an interface without that requireing anything of your license?
Re: curl situation is intolerable
On Sep 13, Olaf van der Spek [EMAIL PROTECTED] wrote: There isn't? I thought this has been standard GPL lore for a very long time - if you link to an *interface* which has a GPL-compliant implementation, it does not matter if you also are incidentally runtime- compatible with a non-GPL-compatible implementation. Agreed. The next question would then be: is it allowed to implement an interface without that requireing anything of your license? Yes. Next? -- ciao, Marco signature.asc Description: Digital signature
Re: curl situation is intolerable
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell Steve BSG wrote: I don't care about the callback. The package maintainers have the job of deciding whether the packages implement the same ABI or not. DECIDE. If the answer is yes, then they should both be drop-in replacements, and Provide the same virtual package. Steve That isn't really an option so long as we have the Steve GPL/OpenSSL license issue to deal with, regardless of Steve whether the ABI matches. If you take this argument to its extreme, then there would be a problem with package X if the administrator set it up to use PAM modules that use incompatible libraries. I don't know if any case exists in Debian, and don't want to search (in case the response is to remove the package in question) but note that libpam-heimdal depends on heimdal which depends on kerberos4kth which depends on openssl. An administrator could setup libpam-heimdal in an application that has a GPL licence... I mean... if the administrator wants to use a library that happens to have an incompatible licence, isn't this his/her business? Can't we just say use the gnutls version as the default? If I misunderstood the concern in anyway, then I apologise. I am running on the assumption that it would be possible to have both packages implement the same ABI and become drop in replacements for each other. Oh, BTW, gnutls isn't a complete 100% solution either, IIRC packages exist that require openssl because the license is GPL incompatible. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
On Sep 13, Brian May [EMAIL PROTECTED] wrote: Oh, BTW, gnutls isn't a complete 100% solution either, IIRC packages exist that require openssl because the license is GPL incompatible. No, it has been LGPL'ed since a long time. -- ciao, Marco signature.asc Description: Digital signature
Re: curl situation is intolerable
On Tue, Sep 13, 2005 at 09:50:00PM +1000, Brian May wrote: Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell Steve BSG wrote: I don't care about the callback. The package maintainers have the job of deciding whether the packages implement the same ABI or not. DECIDE. If the answer is yes, then they should both be drop-in replacements, and Provide the same virtual package. Steve That isn't really an option so long as we have the Steve GPL/OpenSSL license issue to deal with, regardless of Steve whether the ABI matches. If you take this argument to its extreme, then there would be a problem with package X if the administrator set it up to use PAM modules that use incompatible libraries. Mmm, I didn't actually *give* an argument here; the argument has been made many times before on -legal, and it amounts to, if we distribute packages that cause a GPL-incompatible implementation to be pulled in and used *by default*, how is this different from distributing binaries statically linked against that library? So no, the above concern about GPLed PAM modules doesn't follow from the argument, because administrators can do whatever they want on their own systems, and Debian never enables GPL-licensed PAM modules automatically. I mean... if the administrator wants to use a library that happens to have an incompatible licence, isn't this his/her business? Can't we just say use the gnutls version as the default? Do you not give packages any option at all to specify that they want the OpenSSL-enhanced version, then? If you do, what happens if you have a core package that *does* depend on that version, thus effectively changing the default? If you *don't* give them an option, to what extent does it actually benefit us to have the OpenSSL version packaged? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: curl situation is intolerable
On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote: Paul TBBle Hampson [EMAIL PROTECTED] writes: Mind you, the license/OpenSSLCallback conflict neccessarily segregates the packages into two camps, those which are GPL, and those which need the callback only supplied by the OpenSSL-linked libcurl. You misunderstand my complaint. I suspect I did not, but I possibly misdirected my answer. What I complain is that, once the packages have been so segregated, it is now *impossible* to even install both kinds on the same Debian system at the same time. *That* is intolerable. I totally agree. Somehow the _current_ situation managed to be worse than any of the three solutions I proposed. And the dlopening of libldap.so bug is prolly still present, going by the package long description... -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpGafDZIXuz9.pgp Description: PGP signature
Re: curl situation is intolerable
On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote: I don't care about the callback. The package maintainers have the job of deciding whether the packages implement the same ABI or not. DECIDE. If the answer is yes, then they should both be drop-in replacements, and Provide the same virtual package. That isn't really an option so long as we have the GPL/OpenSSL license issue to deal with, regardless of whether the ABI matches. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: curl situation is intolerable
On 9/12/05, Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote: I don't care about the callback. The package maintainers have the job of deciding whether the packages implement the same ABI or not. DECIDE. If the answer is yes, then they should both be drop-in replacements, and Provide the same virtual package. That isn't really an option so long as we have the GPL/OpenSSL license issue to deal with, regardless of whether the ABI matches. Really? I thought that if the interface matches the user can link whatever he wants, because he doesn't (re)distribute the results.
Re: curl situation is intolerable
On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote: Paul TBBle Hampson [EMAIL PROTECTED] writes: Mind you, the license/OpenSSLCallback conflict neccessarily segregates the packages into two camps, those which are GPL, and those which need the callback only supplied by the OpenSSL-linked libcurl. You misunderstand my complaint. I do not care that a given package cannot link to SSL and also be GPLd. That's a hassle, but it's endurable. What I complain is that, once the packages have been so segregated, it is now *impossible* to even install both kinds on the same Debian system at the same time. *That* is intolerable. I don't care about the callback. The package maintainers have the job of deciding whether the packages implement the same ABI or not. DECIDE. If the answer is yes, then they should both be drop-in replacements, and Provide the same virtual package. If the answer is no, then they should install different files in the Debian namespace and should not Conflict with each other. DECIDE, and then do whichever. But the current solution is utterly unacceptible. Thomas, i'm aware of the poor (non-)solution currently realized. yesterday i was rolling a new upload with a modified name for libcurl3-gnutls to allow both the packages to be installed at the same time when i finally understood why i probably need versioned symbols. then i looked for some kind soul (Matthias Urlichs) who introduced me to the world of versioned symbols. so my next favourite solution is: curl openssl libcurl3 openssl, versioned symbols libcurl3-dev openssl libcurl3-gnutlsgnutls, versioned symbols libcurl3-gnutls-devgnutls libcurl3-dbg openssl will libcurl3 with versioned symbols break existing packages linked to it? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
Folks, *please* consider to help with the implementation of the real solution for libcurl4, i.e. several SSL backends to just one libcurl.so front-end, without installation conflicts, modular and compatible with all licenses. See the second half of http://curl.haxx.se/legal/distro-dilemma.html. I am rather swamped with lots of other things. Daniel (curl upstream) sounds like he will accept a patch to implement this, but he will probably not do any work on this himself. Also see http://curl.haxx.se/mail/lib-2005-09/0066.html, a first, very incomplete patch by me. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
On Mon, Sep 12, 2005 at 11:34:22AM +0200, Domenico Andreoli wrote: will libcurl3 with versioned symbols break existing packages linked to it? It will not. It would be best to coordinate with upstream to get symbol versioning added there as well, so that binaries built against the symbol-versioned Debian lib can also be run on other systems. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: curl situation is intolerable
Scripsit Domenico Andreoli [EMAIL PROTECTED] yesterday i was rolling a new upload with a modified name for libcurl3-gnutls to allow both the packages to be installed at the same time when i finally understood why i probably need versioned symbols. However unacceptable the current situation is, wouldn't fixing it now introduce a library transition? And wouldn't it be a good idea to postpone that until the current large transitions are done with? -- Henning Makholm The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
On Sep 12, Richard Atterer [EMAIL PROTECTED] wrote: Folks, *please* consider to help with the implementation of the real solution for libcurl4, i.e. several SSL backends to just one libcurl.so front-end, without installation conflicts, modular and compatible with all licenses. See the second half of http://curl.haxx.se/legal/distro-dilemma.html. I do not believe that it's worth the effort, there are no really good reasons to use OpenSSL in the long time. Development effort should be focused on fixing any eventual gnutls bugs (either in the library itself or in the libcurl glue). -- ciao, Marco signature.asc Description: Digital signature
Re: curl situation is intolerable
On Mon, Sep 12, 2005 at 11:09:31AM +0200, Olaf van der Spek wrote: On 9/12/05, Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote: I don't care about the callback. The package maintainers have the job of deciding whether the packages implement the same ABI or not. DECIDE. If the answer is yes, then they should both be drop-in replacements, and Provide the same virtual package. That isn't really an option so long as we have the GPL/OpenSSL license issue to deal with, regardless of whether the ABI matches. Really? I thought that if the interface matches the user can link whatever he wants, because he doesn't (re)distribute the results. There isn't universal agreement on this point, and it's never actually been tested in court. Debian generally plays it safe, though, there doesn't seem to be much reason to be a test case for this given that at least some copyright holders of GPL works don't want their code used with OpenSSL. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: curl situation is intolerable
On Mon, Sep 12, 2005 at 02:05:23PM +0200, Marco d'Itri wrote: On Sep 12, Richard Atterer [EMAIL PROTECTED] wrote: Folks, *please* consider to help with the implementation of the real solution for libcurl4, i.e. several SSL backends to just one libcurl.so front-end, without installation conflicts, modular and compatible with all licenses. See the second half of http://curl.haxx.se/legal/distro-dilemma.html. I do not believe that it's worth the effort, there are no really good reasons to use OpenSSL in the long time. Development effort should be focused on fixing any eventual gnutls bugs (either in the library itself or in the libcurl glue). Well, how much is in the long run? It could be years. Furthermore, OpenSSL is simply much more popular, plus it will stay the primary SSL implementation for curl upstream for the foreseeable future. Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
Steve Langasek [EMAIL PROTECTED] writes: On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote: I don't care about the callback. The package maintainers have the job of deciding whether the packages implement the same ABI or not. DECIDE. If the answer is yes, then they should both be drop-in replacements, and Provide the same virtual package. That isn't really an option so long as we have the GPL/OpenSSL license issue to deal with, regardless of whether the ABI matches. I'm not sure I see what that is, but regardless, if it is so, then they must be separate libraries with nonconflicting packages. All this dithering about which way to go is the problem, not the solution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
Richard Atterer [EMAIL PROTECTED] writes: Folks, *please* consider to help with the implementation of the real solution for libcurl4, i.e. several SSL backends to just one libcurl.so front-end, without installation conflicts, modular and compatible with all licenses. See the second half of http://curl.haxx.se/legal/distro-dilemma.html. Fine, and when that's done, we can do that. UNTIL that is done, the two libcurls *must not conflict*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
On Sep 12, Richard Atterer [EMAIL PROTECTED] wrote: I do not believe that it's worth the effort, there are no really good reasons to use OpenSSL in the long time. Development effort should be focused on fixing any eventual gnutls bugs (either in the library itself or in the libcurl glue). Well, how much is in the long run? It could be years. Furthermore, One year at most, considering that so far I have not seen reports of major problems with libcurl+libgnutls. OpenSSL is simply much more popular, plus it will stay the primary SSL So what? implementation for curl upstream for the foreseeable future. Again, who cares? If Debian will use gnutls by default it will get more than enough testing. -- ciao, Marco signature.asc Description: Digital signature
Re: curl situation is intolerable
[Olaf van der Spek] I thought that if the interface matches the user can link whatever he wants, because he doesn't (re)distribute the results. [Steve Langasek] There isn't universal agreement on this point, and it's never actually been tested in court. There isn't? I thought this has been standard GPL lore for a very long time - if you link to an *interface* which has a GPL-compliant implementation, it does not matter if you also are incidentally runtime- compatible with a non-GPL-compatible implementation. Some have argued back and forth about how useful or bug-free the GPL-compliant implementation must be before it counts, but that seems not to be an issue here - both SSL backends are said to be functional, if not 100% feature- and bug-equivalent. From a common-sense standpoint, it's pretty hard to argue that some software is derived from openssl if any user could run the same binary with only gnutls on his system. signature.asc Description: Digital signature
Re: curl situation is intolerable
On Sat, Sep 10, 2005 at 10:21:51PM -0300, Otavio Salvador wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: There should be TWO libcurls, with DIFFERENT names, and then applications can simply link against whichever one they want, instead of the current approach, which totally breaks, violates policy, and doesn't really help much of anyone. I really need to support your request. I agree (and had already suggested such) but it seems to have been ignored out of hand. Hence my later suggestion, which is suboptimal buts seems to be verbose enough to not be ignored. ^_^ Unless I missed something earlier in my search for users of those callbacks, or the gnuTLS support in libcurl is broken (apart from not supporting the callbacks which are the root of this discussion) I don't see why gnuTLS cannot be just slipped in underneath libcurl with no packages the wiser. gnuTLS has versioned symbols, right? -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpvG7o0OjBJm.pgp Description: PGP signature
Re: curl situation is intolerable
On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote: It is *absolutely intolerable* to declare such conflicts for shared libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT HAVE DIFFERENT NAMES. The package has to build libraries with differently versioned symbols as well, to avoid total app meltdown if both libraries are loaded into the same address space. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote: It is *absolutely intolerable* to declare such conflicts for shared libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT HAVE DIFFERENT NAMES. The package has to build libraries with differently versioned symbols as well, to avoid total app meltdown if both libraries are loaded into the same address space. Yes, but I don't mind that nearly as much. That's a much rarer obstacle than one which simply segregates Debian packages into two separate camps, and every use must pick one or the other. That's what the current solution amounts to. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
On Sun, Sep 11, 2005 at 08:59:11PM -0700, Thomas Bushnell BSG wrote: Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote: It is *absolutely intolerable* to declare such conflicts for shared libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT HAVE DIFFERENT NAMES. The package has to build libraries with differently versioned symbols as well, to avoid total app meltdown if both libraries are loaded into the same address space. Yes, but I don't mind that nearly as much. That's a much rarer obstacle than one which simply segregates Debian packages into two separate camps, and every use must pick one or the other. That's what the current solution amounts to. Mind you, the license/OpenSSLCallback conflict neccessarily segregates the packages into two camps, those which are GPL, and those which need the callback only supplied by the OpenSSL-linked libcurl. The difficulty lies in handling those which aren't in either group so they can link to whatever libcurl3 is present, without fear or favour. The secondary difficulty is making sure that no Sarge packages which use the callback find themselves broken by a partial upgrade (although a conflicts could be used to force both parts to migrate if neccessary) The first mitigating factor is that both present the same API to the program, and the same ABI to the linker. (The missing callback just returns -EFAIL if you try to set it on a non-OpenSSL version of libcurl) so it's very possible to link things that can load either library. I like the suggestion for versioning the symbols of libcurl depending on what that lib's linked to. The second mitigating factor is that I couldn't find any code in Debian sid or experimental that sets this callback. I didn't check Sarge, though. So once the gnuTLS support in libcurl is sufficiently featureful to meet it's promised API, it may be able to be just slipped in underneath with no one the wiser, assuming gnuTLS has versioned symbols, which I believe it has. -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgp0cWJ8rBR7o.pgp Description: PGP signature
Re: curl situation is intolerable
Paul TBBle Hampson [EMAIL PROTECTED] writes: Mind you, the license/OpenSSLCallback conflict neccessarily segregates the packages into two camps, those which are GPL, and those which need the callback only supplied by the OpenSSL-linked libcurl. You misunderstand my complaint. I do not care that a given package cannot link to SSL and also be GPLd. That's a hassle, but it's endurable. What I complain is that, once the packages have been so segregated, it is now *impossible* to even install both kinds on the same Debian system at the same time. *That* is intolerable. I don't care about the callback. The package maintainers have the job of deciding whether the packages implement the same ABI or not. DECIDE. If the answer is yes, then they should both be drop-in replacements, and Provide the same virtual package. If the answer is no, then they should install different files in the Debian namespace and should not Conflict with each other. DECIDE, and then do whichever. But the current solution is utterly unacceptible. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: curl situation is intolerable
Thomas Bushnell BSG [EMAIL PROTECTED] writes: There should be TWO libcurls, with DIFFERENT names, and then applications can simply link against whichever one they want, instead of the current approach, which totally breaks, violates policy, and doesn't really help much of anyone. I really need to support your request. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
