Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Fri, Jul 22, 2005 at 07:15:18PM +0200, Elimar Riesebieter wrote: > On Mon, 18 Jul 2005 the mental interface of > Domenico Andreoli told: > > [...] > > i doubt seriously a new package like libcurl3-gnutls is appropriate, > > but let me know your opinion. > > > > is this stuff urgent? > Yes! unfortunately heimdal bug #316980 makes curl FTBS :( regards 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: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, 18 Jul 2005 the mental interface of Domenico Andreoli told: [...] > i doubt seriously a new package like libcurl3-gnutls is appropriate, > but let me know your opinion. > > is this stuff urgent? Yes! Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Wed, 20 Jul 2005 the mental interface of Marco d'Itri told: > On Jul 20, sean finney <[EMAIL PROTECTED]> wrote: [...] > i know i'm repeating myself here, but the real fix is to politely > > solicit the upstream author to change or add a clause to their license > > that makes such allowances. that, or change the build options of the > No, the real fix is to convert as many programs as possible from openssl > to gnutls, starting with libraries. Right, let's start! Elimar -- Experience is something you don't get until just after you need it! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Jul 20, sean finney <[EMAIL PROTECTED]> wrote: > i think that would solve the problem by muting the symptoms. what happens > when the next free-but-not-quite-gpl-compatible licensed software is > linked against libcurl (or something similar)? Not relevant, gnutls is LGPL'ed. > i know i'm repeating myself here, but the real fix is to politely > solicit the upstream author to change or add a clause to their license > that makes such allowances. that, or change the build options of the No, the real fix is to convert as many programs as possible from openssl to gnutls, starting with libraries. -- ciao, Marco signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
hi, On Mon, Jul 18, 2005 at 09:45:09PM +0200, Domenico Andreoli wrote: > i saw the bug report, i'm sorry to not have commented the request which > i find absolutely reasonable. i'll try to figure out if curl may suffer > from limitations due to the use of gnutls in place of openssl. i would guess that there aren't any, though that is making the perhaps naïve assumption that libcurl-dev properly compartmentalizes away the ssl code from its own api. > i doubt seriously a new package like libcurl3-gnutls is appropriate, > but let me know your opinion. i think that would solve the problem by muting the symptoms. what happens when the next free-but-not-quite-gpl-compatible licensed software is linked against libcurl (or something similar)? i know i'm repeating myself here, but the real fix is to politely solicit the upstream author to change or add a clause to their license that makes such allowances. that, or change the build options of the gpl packages that are linking (directly or indirectly) against such libraries so that they do not. if you want to switch support for libcurl to gnutls in the meantime, it would be a very nice thing of you to do, but it neither solves the problem in the larger scheme of things nor would i consider it an obligation on your part to do so. sean -- signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote: > On Sun, Jul 17, 2005 at 09:04:57PM +0200, Elimar Riesebieter wrote: > > Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a > > NMU? > > this is definitely NOT a reason to NMU libcurl. remember that it is > your package that is "broken". of course you could still file a > wishlist bug against libcurl asking to compile against gnutls > instead, but it's up to the maintainer in question to decide. oh, many thanks for the stop :) i saw the bug report, i'm sorry to not have commented the request which i find absolutely reasonable. i'll try to figure out if curl may suffer from limitations due to the use of gnutls in place of openssl. i doubt seriously a new package like libcurl3-gnutls is appropriate, but let me know your opinion. is this stuff urgent? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
* sean finney <[EMAIL PROTECTED]> [050717 21:20]: > On Sun, Jul 17, 2005 at 09:04:57PM +0200, Elimar Riesebieter wrote: > > Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a > > NMU? > > this is definitely NOT a reason to NMU libcurl. remember that it is > your package that is "broken". of course you could still file a > wishlist bug against libcurl asking to compile against gnutls > instead, but it's up to the maintainer in question to decide. Well, linking against openssl where gnutls support seems to be available is at least an annoyance. The alternative is to upload an alternative libcurl, duplicating the source code, making it harder for everyone involved. So it is more than just a avarage wishlist-bug where the maintainer's opinion is the last word. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
hi, On Mon, Jul 18, 2005 at 03:40:30PM +0200, Olaf van der Spek wrote: > On 7/18/05, sean finney <[EMAIL PROTECTED]> wrote: > > yes, and the same with libmysqlclient, which is why there's no longer ssl > > support in the mysql packages :( > > Wouldn't it be possible to support SSL transparently in such a way > that the original package doesn't need to be modified? not without some major dlopen-style hackery, which i don't imagine upstream would support and neither christian nor i have the time/interest/desire to see done in debian-specific patches. On Mon, Jul 18, 2005 at 04:36:52PM +0200, Torsten Landschoff wrote: > On Mon, Jul 18, 2005 at 09:29:46AM -0400, sean finney wrote: > > yes, and the same with libmysqlclient, which is why there's no longer ssl > > support in the mysql packages :( > > That kind of ... sucks!? No hope have the support GnuTLS or something? it's totally feasible that it (and any other ssl-needing library) could be patched to use gnutls instead of openssl, but i'm not familiar enough with either API and would really prefer upstream to approve/include the functionality. if somebody did the hard work and provided a patch, and the mysql folks sounded somewhat postitive about it, i'd consider the possibility. of course this would all be moot if upstream authors got a clue about the full ramifications of the GPL with their software... On Mon, Jul 18, 2005 at 07:57:11PM +0200, Bernhard R. Link wrote: > Well, linking against openssl where gnutls support seems to be > available is at least an annoyance. The alternative is > to upload an alternative libcurl, duplicating the source code, > making it harder for everyone involved. So it is more than just > a avarage wishlist-bug where the maintainer's opinion is the last > word. the problem, from what i understand and from what istr, is that the API's aren't bit-for-bit compatible. given that openssl is not likely to change their license scheme any time soon, moving to something like gnutls does seem the preferable way to go supposing that someone is willing to do and maintain the work. however, it still very much is ultimately the maintainer's perogative whether or not to accept such an option, at least in the situation where upstream only supports openssl. if upstream supports both, you probably won't have a hard time convincing them to change over, and if not you'd at least have a leg to stand on with the technical comittee. sean -- signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, Jul 18, 2005 at 09:29:46AM -0400, sean finney wrote: > > The same issues as with libcurl applied to libldap2. They were > > considered a bug in libldap2 back then because half the distribution > > links it. Gave me a lot of recurring head aches. > > yes, and the same with libmysqlclient, which is why there's no longer ssl > support in the mysql packages :( That kind of ... sucks!? No hope have the support GnuTLS or something? Greetings Torsten signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On 7/18/05, sean finney <[EMAIL PROTECTED]> wrote: > hi, > > On Mon, Jul 18, 2005 at 11:06:13AM +0200, Torsten Landschoff wrote: > > On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote: > > > this is definitely NOT a reason to NMU libcurl. remember that it is > > > your package that is "broken". of course you could still file a > > > > The same issues as with libcurl applied to libldap2. They were > > considered a bug in libldap2 back then because half the distribution > > links it. Gave me a lot of recurring head aches. > > yes, and the same with libmysqlclient, which is why there's no longer ssl > support in the mysql packages :( Wouldn't it be possible to support SSL transparently in such a way that the original package doesn't need to be modified?
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
hi, On Mon, Jul 18, 2005 at 11:06:13AM +0200, Torsten Landschoff wrote: > On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote: > > this is definitely NOT a reason to NMU libcurl. remember that it is > > your package that is "broken". of course you could still file a > > The same issues as with libcurl applied to libldap2. They were > considered a bug in libldap2 back then because half the distribution > links it. Gave me a lot of recurring head aches. yes, and the same with libmysqlclient, which is why there's no longer ssl support in the mysql packages :( sean -- signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, Jul 18, 2005 at 05:16:27AM -0500, Peter Samuelson wrote: > > [Bartosz Fenski] > > Seems that part of developers think that indirect linking with > > OpenSSL is ok, and part think it's not. > Yeah. Well. Stand back and look at why this 'linking' thing matters > in the first place. The point is to determine whether one work is a > "derivative" of another work. False. This is a requirement imposed by section 3 of the GPL, which makes no mention of derivative works. > If it is not, copyright law doesn't let the author of the second work > have any influence on the licensing of the first. It lets the author of the second work control the circumstances under which you are allowed to distribute *that work*. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
[Bartosz Fenski] > Seems that part of developers think that indirect linking with > OpenSSL is ok, and part think it's not. Yeah. Well. Stand back and look at why this 'linking' thing matters in the first place. The point is to determine whether one work is a "derivative" of another work. If it is not, copyright law doesn't let the author of the second work have any influence on the licensing of the first. If you link to libldap2 or libcurl3 but your program would work just as well whether or not those libraries have openssl support, it's really hard to argue that *you* are deriving your code from Eric Young or the OpenSSL project. Or vice versa. You wrote your code to call LDAP functions, or web downloading functions, you didn't care then and don't care now how those functions work. Didn't care then and don't care now whether they can utilize https:// or ldaps:// at runtime. The functions themselves were licensed to you in a manner you could use. The whole "linking is deriving" thing is shaky for other reasons too. For instance, it's pretty widely known or believed that mere interfaces can't be copyrighted. And when you get right down to it, when your program uses a library, it's really just using the published interface. But that's an argument for another day, and probably another list. > What is an official statement? There is none. Debian generally errs very conservatively with regard to license violations, though, because of the Tentacles of Evil principle. That is: if we ship some software and the authors don't mind how we're doing it but we're technically in violation of some license provision - and later one of the authors is bought out by some Big Evil Corporation - then the B.E.C. can cause a lot of trouble for Debian and our users. This is a situation Debian tries very hard to avoid. signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, Jul 18, 2005 at 11:07:41AM +0200, Torsten Landschoff wrote: > > > apt-get remove --purge libssl0.9.7 gives me tons of packages. Just > > > an estimation: We need to repack half of all packages then? > > > > NO.[1] > > > > All that needs to happen is that GPLed packages without an OpenSSL > > linking exception either need to: > > > > 1) Get a linking exception. > > 2) Stop linking with OpenSSL. > > How about indirect linking with OpenSSL? I'd really like to have libldap > use OpenSSL again but I was told this breaks the LDAP support of a lot > of packages since linking LDAP would pull OpenSSL. Seems that part of developers think that indirect linking with OpenSSL is ok, and part think it's not. What is an official statement? regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, Jul 17, 2005 at 11:09:04PM +0300, Don Armstrong wrote: > On Sun, 17 Jul 2005, Elimar Riesebieter wrote: > > apt-get remove --purge libssl0.9.7 gives me tons of packages. Just > > an estimation: We need to repack half of all packages then? > > NO.[1] > > All that needs to happen is that GPLed packages without an OpenSSL > linking exception either need to: > > 1) Get a linking exception. > 2) Stop linking with OpenSSL. How about indirect linking with OpenSSL? I'd really like to have libldap use OpenSSL again but I was told this breaks the LDAP support of a lot of packages since linking LDAP would pull OpenSSL. Greetings Torsten signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote: > > Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a > > NMU? > > this is definitely NOT a reason to NMU libcurl. remember that it is > your package that is "broken". of course you could still file a The same issues as with libcurl applied to libldap2. They were considered a bug in libldap2 back then because half the distribution links it. Gave me a lot of recurring head aches. Basically I'd vote for avoiding license bombs like this in our archive. Most software is GPL and upstream seldom knows about those issues. Greetings Torsten signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Mon, Jul 18, 2005 at 01:02:53AM -0500, Peter Samuelson wrote: > > [Don Armstrong] > > All that needs to happen is that GPLed packages without an OpenSSL > > linking exception either need to: > > 3) For indirect dependencies: make sure you're only using the bits >of the (for example) libcurl ABI which work whether or not it is >compiled against openssl. In that case it's really hard to >argue you're "linking to openssl". This is true for MOC, like for ogg123 whis is also licensed using "pure" GPL. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
[Don Armstrong] > All that needs to happen is that GPLed packages without an OpenSSL > linking exception either need to: > > 1) Get a linking exception. > 2) Stop linking with OpenSSL. 3) For indirect dependencies: make sure you're only using the bits of the (for example) libcurl ABI which work whether or not it is compiled against openssl. In that case it's really hard to argue you're "linking to openssl". signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, 17 Jul 2005, Elimar Riesebieter wrote: > apt-get remove --purge libssl0.9.7 gives me tons of packages. Just > an estimation: We need to repack half of all packages then? NO.[1] All that needs to happen is that GPLed packages without an OpenSSL linking exception either need to: 1) Get a linking exception. 2) Stop linking with OpenSSL. Nothing more needs to be done. Don Armstrong 1: This has been seriously discussed in hideous detail at least 10 times already. The list archives are your friend. -- Grimble left his mother in the food store and went to the launderette and watched the clothes go round. It was a bit like colour television only with less plot. -- Clement Freud _Grimble_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, 17 Jul 2005 the mental interface of sean finney told: > On Sun, Jul 17, 2005 at 08:21:00PM +0200, Elimar Riesebieter wrote: > > I don't see a gpl'd alternative to curl for internet streaming. I am > > thinking about to build moc --without-curl then :( > > or you could always contact the author and inform them of their > self-inflicted license violation. in my experience, many authors > don't realize the licensing problem and are more than willing to > relicense/dual license/add exceptions for stuff like openssl. > > > What about the fbi-package, raptor-utils-package and others who are using > > libcurl3 as well? > > if they are strict gpl and use libcurl, you should report bugs against them. apt-get remove --purge libssl0.9.7 gives me tons of packages. Just an estimation: We need to repack half of all packages then? Elimar -- Planung: Ersatz des Zufalls durch den Irrtum. -unknown- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, Jul 17, 2005 at 09:04:57PM +0200, Elimar Riesebieter wrote: > Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a > NMU? this is definitely NOT a reason to NMU libcurl. remember that it is your package that is "broken". of course you could still file a wishlist bug against libcurl asking to compile against gnutls instead, but it's up to the maintainer in question to decide. sean -- signature.asc Description: Digital signature
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, 17 Jul 2005 the mental interface of sean finney told: > On Sun, Jul 17, 2005 at 08:21:00PM +0200, Elimar Riesebieter wrote: > > I don't see a gpl'd alternative to curl for internet streaming. I am > > thinking about to build moc --without-curl then :( > > or you could always contact the author and inform them of their > self-inflicted license violation. in my experience, many authors > don't realize the licensing problem and are more than willing to > relicense/dual license/add exceptions for stuff like openssl. > > > What about the fbi-package, raptor-utils-package and others who are using > > libcurl3 as well? > > if they are strict gpl and use libcurl, you should report bugs against them. Damian can't. I asked him. Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a NMU? Elimar -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, Jul 17, 2005 at 08:21:00PM +0200, Elimar Riesebieter wrote: > I don't see a gpl'd alternative to curl for internet streaming. I am > thinking about to build moc --without-curl then :( or you could always contact the author and inform them of their self-inflicted license violation. in my experience, many authors don't realize the licensing problem and are more than willing to relicense/dual license/add exceptions for stuff like openssl. > What about the fbi-package, raptor-utils-package and others who are using > libcurl3 as well? if they are strict gpl and use libcurl, you should report bugs against them. sean -- signature.asc Description: Digital signature
