Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)
Le mardi, 28 janvier 2014, 16.07:34 Daniel Kahn Gillmor a écrit : On Sun 2013-12-22 14:12:40 -0500, Andreas Metzler wrote: #3 Hope that GMP is relicensed to GPL2+/LGPLv3+ On Tue 2014-01-14 04:53:51 -0500, Didier 'OdyX' Raboud wrote: 2) GnuTLS 2.x is useable but deprecated, 3.x is GPLv3+ through GMP. We're back to talk to the FSF to license GMP back to LGPLv2+ I think OdyX is asking for more from GMP than is necessary; note that Andreas earlier pointed out that GMP just needs to be GPL2+/LGPLv3+. Ah yeah, good point. I was merely asking for a revert of the change that broke the GPLv2-only uses. I had overlooked that GPLv2+/LGPLv3+ would also be okay; thanks for having pointed that out. This is exactly what libgmp (in particular, Torbjorn Granlund t...@gmplib.org) appears to have decided to do as of yesterday: Changelog: https://gmplib.org/repo/gmp/rev/02634effbd4e Huge diff with licensing changes: https://gmplib.org/repo/gmp/rev/da670a8513db So i believe this makes the GPLv2-only CUPS re-distributable again when linked to modern versions of GnuTLS. That's quite awesome news! Let's see if that makes it to a public release (which I don't doubt) and we'll have a clean way forward after GnuTLS 2.x ! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)
On Sun 2013-12-22 14:12:40 -0500, Andreas Metzler wrote: #3 Hope that GMP is relicensed to GPL2+/LGPLv3+ On Tue 2014-01-14 04:53:51 -0500, Didier 'OdyX' Raboud wrote: 2) GnuTLS 2.x is useable but deprecated, 3.x is GPLv3+ through GMP. We're back to talk to the FSF to license GMP back to LGPLv2+ I think OdyX is asking for more from GMP than is necessary; note that Andreas earlier pointed out that GMP just needs to be GPL2+/LGPLv3+. This is exactly what libgmp (in particular, Torbjorn Granlund t...@gmplib.org) appears to have decided to do as of yesterday: Changelog: https://gmplib.org/repo/gmp/rev/02634effbd4e Huge diff with licensing changes: https://gmplib.org/repo/gmp/rev/da670a8513db So i believe this makes the GPLv2-only CUPS re-distributable again when linked to modern versions of GnuTLS. Happy Hacking, --dkg pgpxiOPBSQOhM.pgp Description: PGP signature
Re: CUPS is now linked against OpenSSL
On Mon, Jan 13, 2014 at 11:03:04PM -0500, Daniel Kahn Gillmor wrote: Alternately, does anyone know anyone from the polarssl community who we could cajole into patching that TLS implementation into CUPS? I'd like to point out that PolarSSL doesn't correctly implement TLS 1.0 since it doesn't support the mandatory cipher suite. That isn't a practical problem, since nobody implements only that cipher suite, but it is a conformance issue that needs to be addressed. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)
Le lundi, 13 janvier 2014, 17.38:12 Didier Raboud a écrit : Le samedi, 11 janvier 2014, 14.22:28 Daniel Kahn Gillmor a écrit : 0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL exception) As asking generally can't hurt, I have filed https://cups.org/str.php?L4337 on the upstream bugtracker to discuss that. I'll keep the list posted. The answer came back faster than I expected and is public [1], I'm quoting it here for completeness' sake: Le lundi, 13 janvier 2014, 14:24:33 Michael Sweet a écrit : We cannot, for a number of legal and (Apple) liability reasons, relicense CUPS as [L]GPL2+. It will never happen. OpenSSL support has been removed from the CUPS 2.0 source code and is not an option. That leaves you with using GnuTLS ([L]GPL2/3) or porting Apple's CDSA/Security code (Apache license), although the Apache license may not be GPL3 compatible according to the FSF. Given that GnuTLS is included with basically every Linux distribution as a standard OS component, it SHOULD automatically fall under the [L]GPL2/3 exception for system libraries (just as OpenSSL should have fallen under the same exception...) If not, then I humbly suggest you talk to the FSF. Now, for the set of options he described: 1) OpenSSL As he claims that OpenSSL has been removed from the master CUPS branch, I think that this, by itself, disqualifies the linking of libcups2 against OpenSSL, as it would be a dead end. 2) GnuTLS 2.x is useable but deprecated, 3.x is GPLv3+ through GMP. We're back to talk to the FSF to license GMP back to LGPLv2+ 3) Apple CDSA / libsecurity From [1], this is currently being deprecated by Apple from OSX v10.7. Also, it licensed under the APSL [Apple Public Source License] which is incompatible with the GPL. It isn't packaged in Debian as far as I could find. So in the current situation, I don't see any good long-term solution but a port to another license-compatible library such as polarssl… Cheers, OdyX [1] And GPG-signed: http://www.cups.org/pipermail/cups-devel/2014-January/014768.html signature.asc Description: This is a digitally signed message part.
Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)
Le mardi, 14 janvier 2014, 10.53:51 Didier '' Raboud a écrit : 3) Apple CDSA / libsecurity From [1], this is currently being deprecated by Apple from OSX v10.7. Meh. The link should have been https://developer.apple.com/library/mac/documentation/security/conceptual/cryptoservices/CDSA/CDSA.html It is apparently replaced by CommonCrypto signature.asc Description: This is a digitally signed message part.
Re: CUPS is now linked against OpenSSL (and will stay GPLv2-only)
On Tue, Jan 14, 2014 at 10:53 AM, Didier 'OdyX' Raboud o...@debian.org wrote: Le lundi, 13 janvier 2014, 17.38:12 Didier Raboud a écrit : Le samedi, 11 janvier 2014, 14.22:28 Daniel Kahn Gillmor a écrit : 0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL exception) As asking generally can't hurt, I have filed https://cups.org/str.php?L4337 on the upstream bugtracker to discuss that. I'll keep the list posted. The answer came back faster than I expected and is public [1], I'm quoting it here for completeness' sake: Le lundi, 13 janvier 2014, 14:24:33 Michael Sweet a écrit : We cannot, for a number of legal and (Apple) liability reasons, relicense CUPS as [L]GPL2+. It will never happen. OpenSSL support has been removed from the CUPS 2.0 source code and is not an option. That leaves you with using GnuTLS ([L]GPL2/3) or porting Apple's CDSA/Security code (Apache license), although the Apache license may not be GPL3 compatible according to the FSF. Given that GnuTLS is included with basically every Linux distribution as a standard OS component, it SHOULD automatically fall under the [L]GPL2/3 exception for system libraries (just as OpenSSL should have fallen under the same exception...) If not, then I humbly suggest you talk to the FSF. Now, for the set of options he described: 1) OpenSSL As he claims that OpenSSL has been removed from the master CUPS branch, I think that this, by itself, disqualifies the linking of libcups2 against OpenSSL, as it would be a dead end. 2) GnuTLS 2.x is useable but deprecated, 3.x is GPLv3+ through GMP. We're back to talk to the FSF to license GMP back to LGPLv2+ 3) Apple CDSA / libsecurity From [1], this is currently being deprecated by Apple from OSX v10.7. Also, it licensed under the APSL [Apple Public Source License] which is incompatible with the GPL. It isn't packaged in Debian as far as I could find. 4/ Port to lib nss using comptability layer. So in the current situation, I don't see any good long-term solution but a port to another license-compatible library such as polarssl… Cheers, OdyX [1] And GPG-signed: http://www.cups.org/pipermail/cups-devel/2014-January/014768.html -- debian-science-maintainers mailing list debian-science-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAYVsY1qLW2x7RYZ+6thoT=r48xqgrdt-qkzer8rrmm...@mail.gmail.com
Re: CUPS is now linked against OpenSSL
* Daniel Kahn Gillmor d...@fifthhorseman.net, 2014-01-13, 23:03: if the only axis we're measuring along is cryptographic security, then protecting against passive attackers (eavesdroppers) is clearly better than not doing so. but if people think that CUPS' TLS protects them against active attackers, and they use that to do things like send confidential information over the link, they have been lulled into a false sense of security. Hear, hear. So, how would people feel about the following policy: TLS clients must either: - validate server certificates; - or prominently document that they don't do that? ? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114113150.ga11...@jwilk.net
Re: CUPS is now linked against OpenSSL
On Tue, 14 Jan 2014, Jakub Wilk wrote: * Daniel Kahn Gillmor d...@fifthhorseman.net, 2014-01-13, 23:03: if the only axis we're measuring along is cryptographic security, then protecting against passive attackers (eavesdroppers) is clearly better than not doing so. but if people think that CUPS' TLS protects them against active attackers, and they use that to do things like send confidential information over the link, they have been lulled into a false sense of security. Hear, hear. So, how would people feel about the following policy: TLS clients must either: - validate server certificates; - or prominently document that they don't do that? As in log unsafe TLS connection to foo? Because anything less than that would not be effective at all. -- 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 debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114114323.gb31...@khazad-dum.debian.net
Re: CUPS is now linked against OpenSSL
Hi Daniel, and thanks for the insightful response, Le samedi, 11 janvier 2014, 14.22:28 Daniel Kahn Gillmor a écrit : There is a fourth way forward -- loath though i am to propose it -- which is to avoid enabling TLS in CUPS at all until upstream gets their act together and does something sensible, both licensing-wise and crypto-wise. That would be quite a bold move to take. The one aspect that puzzles me most is: in which ways no TLS security is better than incompletely secure TLS? Now some CUPS bugs are probably not known widely enough and we could warn about using CUPS's TLS support in the packaging, wording welcome. Also, TLS is enabled in all actually our supported src:cups uploads. Introducing this regression is a move for which I would need quite a strong encouragement to proceed with. last i checked, cups does not support certificate validation or checking [0], making the crypto vulnerable to any active attacker: [0] http://www.cups.org/str.php?L1616 According to the roadmap [0] this is due on the 2.0 branch, but i haven't seen it yet. [1] http://www.cups.org/roadmap.php Quite bad indeed. I have pinged that bug to see whether a fix could happen earlier. The idea of opening RC bugs against everything that links to libcups2 to demand an OpenSSL exception sounds really, really ugly to me. what about the packages that link to those packages? I'd rather see less OpenSSL, not more, because of its mutual incompatibility with the GPL. Frightening can of worms. 0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL exception) As asking generally can't hurt, I have filed https://cups.org/str.php?L4337 on the upstream bugtracker to discuss that. I'll keep the list posted. 1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change in 4.2.2). Does anyone have a strong relationship with GMP maintainers who could open this conversation with them? I don't, but would hope the libgmp maintainers could ask the question; I've hereby CC'ed Steve. 2) turn off TLS support in CUPS until upstream works things out and actually provides some cryptographic defense against an active attacker For now, I will rather revert the switch to OpenSSL and … 5) ask dozens of packages which already have reasonable copyleft licensing to make openssl execptions, iterating until we've covered everything contaminated with this mess. … try to see what this can of worms looks like. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: CUPS is now linked against OpenSSL
On 01/13/2014 11:38 AM, Didier 'OdyX' Raboud wrote: That would be quite a bold move to take. The one aspect that puzzles me most is: in which ways no TLS security is better than incompletely secure TLS? if the only axis we're measuring along is cryptographic security, then protecting against passive attackers (eavesdroppers) is clearly better than not doing so. but if people think that CUPS' TLS protects them against active attackers, and they use that to do things like send confidential information over the link, they have been lulled into a false sense of security. And: cryptographic security is not the only axis we should be measuring on. The other axis is difficulty of license compliance, and CUPS licensing is currently in a state that i would consider it difficult to ship effectively with any sort of well-maintained cryptographic support and remain in compliance with all the relevant licenses. Does this make CUPS less useful than it used to be? Is this a regression? yes, and yes. That's why we should try to get one project (either CUPS or GMP) to change their licensing to fix the issue rather than trying to get dozens of projects to change their licensing. Alternately, does anyone know anyone from the polarssl community who we could cajole into patching that TLS implementation into CUPS? --dkg signature.asc Description: OpenPGP digital signature
CUPS is now linked against OpenSSL (was: Re: GnuTLS in Debian)
Hi all, this GnuTLS in Debian thread triggered my switch of the src:cups package from linking against GnuTLS to now link against OpenSSL. CUPS is GPL-2 only with an OpenSSL exception. Today, Andreas rightly pointed to me that this induces a problem (for Debian) for all GPL-without-OpenSSL-exception programs linked against libcups2. As far as I understand our current stance on that problem, GPL-licensed programs without an OpenSSL exception are absolutely forbidden to link with it, even indirectly. Now, for the actual situation: I initially switched cups following my option 0) aka: 0) move away from GnuTLS as its newer versions are incompatible with GPL-2, use OpenSSL as cups is allowed to be linked against it … but I had overlooked the indirect linking problem. Now, as far as I understood the thread, there are suggestions floating around to stop caring about this incompatibility and just consider as a project that OpenSSL is a system library, but this decision hasn't been formally taken yet. So as far as CUPS is concerned, I see three ways forward: 1) revert the switch to OpenSSL and link against GnuTLS 2. This basically postpones the question to the moment when GnuTLS 2 is removed from Debian. As I understood the thread, GnuTLS 2 is likely to be removed from testing before the freeze, right? 2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and CUPS is GPL-2 only. 3) report RC bugs against all packages linking against libcups2 which licenses don't allow indirect linking to OpenSSL (mostly GPL- -without-OpenSSL-exception) and hope that fixes can be found license- -wise. There are = 38 packages build-depending on libcups2-dev and = 120 packages depending on libcups2. Also, I am not aware of tools to detect this incompatibility automatically. I also doubt we'll be able to find solutions for all packages; yet libcups2 is quite important in desktop stacks. So there is apparently no good solution on the long-term if the need for OpenSSL exceptions isn't waived. For now, I'm leaning towards solution 1) to avoid willingly introducing dozens of RC bugs in testing when libcups2 enters testing (unless I create a maintainer RC bug blocked by all the 3)-created bugs). I would really welcome opinions and advices on this matter. Many thanks in advance, cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: CUPS is now linked against OpenSSL (was: Re: GnuTLS in Debian)
On Sat, 2014-01-11 at 17:55 +0100, Didier 'OdyX' Raboud wrote: Hi all, this GnuTLS in Debian thread triggered my switch of the src:cups package from linking against GnuTLS to now link against OpenSSL. CUPS is GPL-2 only with an OpenSSL exception. Today, Andreas rightly pointed to me that this induces a problem (for Debian) for all GPL-without-OpenSSL-exception programs linked against libcups2. As far as I understand our current stance on that problem, GPL-licensed programs without an OpenSSL exception are absolutely forbidden to link with it, even indirectly. [...] I think this is an absurd interpretation. It is certainly not being applied to linux-tools, where we have perf linked against libpython linked against OpenSSL. Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Re: CUPS is now linked against OpenSSL (was: Re: GnuTLS in Debian)
On Sat, 2014-01-11 at 17:55 +0100, Didier 'OdyX' Raboud wrote: Hi all, this GnuTLS in Debian thread triggered my switch of the src:cups package from linking against GnuTLS to now link against OpenSSL. CUPS is GPL-2 only with an OpenSSL exception. Now, as far as I understood the thread, there are suggestions floating around to stop caring about this incompatibility and just consider as a project that OpenSSL is a system library, but this decision hasn't been formally taken yet. So as far as CUPS is concerned, I see three ways forward: 1) revert the switch to OpenSSL and link against GnuTLS 2. This basically postpones the question to the moment when GnuTLS 2 is removed from Debian. As I understood the thread, GnuTLS 2 is likely to be removed from testing before the freeze, right? 2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and CUPS is GPL-2 only. What are the chances of cups re-licensing (dual-licensing) to GPL2+? This would be a step in the right direction. (in worst case use some other software package than cups as default for printing) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1389462256.3662.22.camel@PackardBell-PC
Re: CUPS is now linked against OpenSSL
Svante Signell svante.sign...@gmail.com wrote: [...] What are the chances of cups re-licensing (dual-licensing) to GPL2+? This would be a step in the right direction. (in worst case use some other software package than cups as default for printing) I'd guess minimal, iirc Apple has no love for GPLv3. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98e8qa-1uu@argenau.downhill.at.eu.org
Re: CUPS is now linked against OpenSSL
2014/1/11 Andreas Metzler ametz...@bebt.de: Svante Signell svante.sign...@gmail.com wrote: [...] What are the chances of cups re-licensing (dual-licensing) to GPL2+? This would be a step in the right direction. (in worst case use some other software package than cups as default for printing) I'd guess minimal, iirc Apple has no love for GPLv3. Changing this would only mean that CUPS forks have the option to be distributed under GPLv3. I don't see a reason why Apple should be against this. But I guess a decision like this would run with low priority over there... Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKNHny-x=3wjuhq1spxdy6htsbwkxtckzpnoocqkopk7plu...@mail.gmail.com
Re: CUPS is now linked against OpenSSL
Matthias Klumpp matth...@tenstral.net writes: Changing this would only mean that CUPS forks have the option to be distributed under GPLv3. I don't see a reason why Apple should be against this. Apple appears to be against anything containing the phrase GPLv3, to the extent that their employees were even forbidden from reading GCC mailing lists once the project started considering GPLv3 patches. Presumably their lawyers freaked out about something in the license, possibly the patent handling. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874n5axsx5@windlord.stanford.edu
Re: CUPS is now linked against OpenSSL (was: Re: GnuTLS in Debian)
On Sat, Jan 11, 2014 at 05:24:16PM +, Ben Hutchings wrote: On Sat, 2014-01-11 at 17:55 +0100, Didier 'OdyX' Raboud wrote: Hi all, this GnuTLS in Debian thread triggered my switch of the src:cups package from linking against GnuTLS to now link against OpenSSL. CUPS is GPL-2 only with an OpenSSL exception. Today, Andreas rightly pointed to me that this induces a problem (for Debian) for all GPL-without-OpenSSL-exception programs linked against libcups2. As far as I understand our current stance on that problem, GPL-licensed programs without an OpenSSL exception are absolutely forbidden to link with it, even indirectly. [...] I think this is an absurd interpretation. It is certainly not being applied to linux-tools, where we have perf linked against libpython linked against OpenSSL. $ ldd /usr/bin/perf_3.12 |grep ssl $ This is not an analogous situation. libpython does *not* link against OpenSSL; it merely supports dynamically loading libssl on behalf of python programs that request it. So perf is not loading OpenSSL into memory, and there is no GPL problem here. I would suggest dropping the disclaimer from the copyright file, as it's not really applicable. Had the situation actually been analogous, with perf calling into openssl code via libpython, I would have filed a serious bug against linux-tools in response to your message. This is not a matter that maintainers are entitled to exercise their own opinions on; if Debian were to decide to no longer hold itself to the letter of the GPL, that's a decision for the project to make as a whole. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: CUPS is now linked against OpenSSL
El sáb, 11 de ene 2014 a las 10:41 , Russ Allbery r...@debian.org escribió: Matthias Klumpp matth...@tenstral.net writes: Changing this would only mean that CUPS forks have the option to be distributed under GPLv3. I don't see a reason why Apple should be against this. Apple appears to be against anything containing the phrase GPLv3, to the extent that their employees were even forbidden from reading GCC mailing lists once the project started considering GPLv3 patches. Presumably their lawyers freaked out about something in the license, possibly the patent handling. It seems like it was the tivo-ization stuff. They license a lot of their stuff under the Apache v2 license, so I do not think it is the patent provisions that frighten them. -- Cameron Norman
Re: CUPS is now linked against OpenSSL
On 01/11/2014 11:55 AM, Didier 'OdyX' Raboud wrote: So as far as CUPS is concerned, I see three ways forward: 1) revert the switch to OpenSSL and link against GnuTLS 2. This basically postpones the question to the moment when GnuTLS 2 is removed from Debian. As I understood the thread, GnuTLS 2 is likely to be removed from testing before the freeze, right? 2) switch to GnuTLS 3. This is not allowed because GnuTLS 3 is GPL-3 and CUPS is GPL-2 only. 3) report RC bugs against all packages linking against libcups2 which licenses don't allow indirect linking to OpenSSL (mostly GPL- -without-OpenSSL-exception) and hope that fixes can be found license- -wise. There are = 38 packages build-depending on libcups2-dev and = 120 packages depending on libcups2. Also, I am not aware of tools to detect this incompatibility automatically. I also doubt we'll be able to find solutions for all packages; yet libcups2 is quite important in desktop stacks. There is a fourth way forward -- loath though i am to propose it -- which is to avoid enabling TLS in CUPS at all until upstream gets their act together and does something sensible, both licensing-wise and crypto-wise. last i checked, cups does not support certificate validation or checking [0], making the crypto vulnerable to any active attacker: [0] http://www.cups.org/str.php?L1616 According to the roadmap [0] this is due on the 2.0 branch, but i haven't seen it yet. [1] http://www.cups.org/roadmap.php This is a terrible solution, but an encryption layer that silently fails open in the presence of an adversary is a bad thing too, especially if it introduces all sorts of licensing gymnastics. The idea of opening RC bugs against everything that links to libcups2 to demand an OpenSSL exception sounds really, really ugly to me. what about the packages that link to those packages? I'd rather see less OpenSSL, not more, because of its mutual incompatibility with the GPL. Modern versions of GnuTLS could be GPL2+ if GMP relaxes their licensing, which would also solve this situation, and would be a better win for copyleft and free software all around. If we're willing to go around asking folks for changes to their licensing, my preferences would be (highest preferences first): 0) ask CUPS to move from GPL2 to GPL2+ (with or without OpenSSL exception) 1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change in 4.2.2). Does anyone have a strong 2) turn off TLS support in CUPS until upstream works things out and actually provides some cryptographic defense against an active attacker 3) drive bamboo shoots under my fingernails 4) patch CUPS to use some other GPL2-compatible TLS implementation (libnss? polarssl?) 5) ask dozens of packages which already have reasonable copyleft licensing to make openssl execptions, iterating until we've covered everything contaminated with this mess. (ok, maybe 3 and 4 are actually tied) happy hacking, --dkg signature.asc Description: OpenPGP digital signature
Re: CUPS is now linked against OpenSSL
On 01/11/2014 02:22 PM, Daniel Kahn Gillmor wrote: 1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change in 4.2.2). Does anyone have a strong Bah. This was supposed to say Does anyone have a strong relationship with GMP maintainers who could open this conversation with them? i'd be willing to participate to that discussion if someone can make good introductions to get the ball rolling. Regards, --dkg signature.asc Description: OpenPGP digital signature
Re: CUPS is now linked against OpenSSL
Daniel Kahn Gillmor d...@fifthhorseman.net writes: On 01/11/2014 02:22 PM, Daniel Kahn Gillmor wrote: 1) ask GMP to switch back from LGPLv3+ to LGPLv2+ (it made the change in 4.2.2). Does anyone have a strong Bah. This was supposed to say Does anyone have a strong relationship with GMP maintainers who could open this conversation with them? i'd be willing to participate to that discussion if someone can make good introductions to get the ball rolling. Isn't GMP an official GNU project? I thought the FSF had an organization-wide policy to relicense all of their packages to v3 or later. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txdaw9y0@windlord.stanford.edu
Re: CUPS is now linked against OpenSSL
Russ Allbery writes (Re: CUPS is now linked against OpenSSL): Isn't GMP an official GNU project? I thought the FSF had an organization-wide policy to relicense all of their packages to v3 or later. Perhaps we might be able to persaude them to make an exception for GMP. The FSF certainly recognise that licensing decisions are a question of tactics. The argument I would make (because I believe in it) is that lack of good cryptographic software is a bigger threat to the freedom of users than tivoisation (and, the other downsides of GPLv2 compared to v3). I'm no fan of TLS but it is very unfortunate that we are considering further weakening security provisions in printing protocols, for example, because of this kind of licensing problem. (This is true even though a GPLv2+ GMP can be used as _part of_ a cryptographically enforced tivoisation setup, whereas a GPLv3+ GMP can only be part of such a system at the mater rather than slave end.) For vaguely analogous reasons we (the free software world) try to make our codecs have very liberal licences. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21201.52641.560191.663...@chiark.greenend.org.uk
Re: CUPS is now linked against OpenSSL
Hi Ian, On Sonntag, 12. Januar 2014, Ian Jackson wrote: The argument I would make (because I believe in it) is that lack of good cryptographic software is a bigger threat to the freedom of users than tivoisation (and, the other downsides of GPLv2 compared to v3). absolutly agreed! Please go for it! I'm no fan of TLS but it is very unfortunate that we are considering further weakening security provisions in printing protocols, for example, because of this kind of licensing problem. [...] For vaguely analogous reasons we (the free software world) try to make our codecs have very liberal licences. also. cheers, Holger signature.asc Description: This is a digitally signed message part.
