Re: transitive GPL (exim4, OpenSSL, mySQL and others)
On Thu, 15 Nov 2007 09:00:56 +1100, Ben Finney [EMAIL PROTECTED] wrote: In my view, the ideal solution from a reduce-licensing-headaches perspective is to get all the code in a work licensed compatibly with no need for exception clauses, either by relicensing some parts or by replacing parts with equivalents under compatible licenses. The former is not an option for OpenSSL (has probably been tried millions of times), and the latter is, in the majority of users' opinion, not an option because GnuTLS has major interoperability issues to be actually useable. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
Marc Haber [EMAIL PROTECTED] writes: The former [relicensing component parts under compatible licenses] is not an option for OpenSSL (has probably been tried millions of times) Never say never; popular works do sometimes change licenses from community pressure to be compatible. I haven't tried it myself in the case of OpenSSL, though, so I can't gainsay your specific statement of multiple attempts. and the latter [replacing components with functional equivalents under compatible licenses] is, in the majority of users' opinion, not an option because GnuTLS has major interoperability issues to be actually useable. I keep seeing this claim made, but the specifics elude me. This thread isn't really the place to detail it, though. Is there a clearing-house site showing exactly what the problems are for a project wanting to move from OpenSSL to GnuTLS, and why those problems are so insurmountable that GnuTLS cannot be improved to overcome them despite the majority of users wanting those improvements? -- \ Quidquid latine dictum sit, altum viditur. (Whatever is | `\said in Latin, sounds profound.) —anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
On Fri, 09 Nov 2007 23:35:55 +0100, Josselin Mouette [EMAIL PROTECTED] wrote: Le jeudi 08 novembre 2007 à 19:27 +0100, Marc Haber a écrit : (1) Is it ok to change exim's SSL library to OpenSSL in the current setup without violating the GPL for some of the library currently in use It would be nice to get explicit permission from the Exim developers to link with Perl code under the Artistic license, but it seems to me that this whole mess is already legally redistributable. I have filed an upstream bug (http://bugs.exim.org/show_bug.cgi?id=629) asking for this permission. (3) Is this violation maybe already happening by virtue of linking indirectly to OpenSSL via libpq? It would, if exim and libmysqlclient's exceptions weren't so broad. Let me understand this in Theory. Given the following link tree: - | program P | - / \ / \ - - | library L | | library M | - - | - | OpenSSL | - If both M and P were GPL with OpenSSL exception, but L were GPL without OpenSSL exception, this linking would be a violation of L's license?`By virtue of P linking to M and L and M linking to OpenSSL? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
Marc Haber [EMAIL PROTECTED] writes: If both M and P were GPL with OpenSSL exception, but L were GPL without OpenSSL exception, this linking would be a violation of L's license?`By virtue of P linking to M and L and M linking to OpenSSL? That's my understanding, yes. This is why things like OpenSSL exclusion clause are a stop-gap measure only; the license incompatibility continues to be a problem for any new code combined with the work, and it's easy to overlook that. In my view, the ideal solution from a reduce-licensing-headaches perspective is to get all the code in a work licensed compatibly with no need for exception clauses, either by relicensing some parts or by replacing parts with equivalents under compatible licenses. -- \For fast acting relief, try slowing down. -- Jane Wagner, | `\ via Lily Tomlin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
This one time, at band camp, Marc Haber said: Let me understand this in Theory. Given the following link tree: - | program P | - / \ / \ - - | library L | | library M | - - | - | OpenSSL | - If both M and P were GPL with OpenSSL exception, but L were GPL without OpenSSL exception, this linking would be a violation of L's license?`By virtue of P linking to M and L and M linking to OpenSSL? I have been under the impression that the answer is no. You're not linking L to OpenSSL. It could be argued that this was an attempt at defeating the GPL if P was a thin shim layer between L and OpenSSL, but I don't think anyone can reasonably argue that for our default MTA. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Marc Haber said: If both M and P were GPL with OpenSSL exception, but L were GPL without OpenSSL exception, this linking would be a violation of L's license?`By virtue of P linking to M and L and M linking to OpenSSL? I have been under the impression that the answer is no. You're not linking L to OpenSSL. It could be argued that this was an attempt at defeating the GPL if P was a thin shim layer between L and OpenSSL, It doesn't need to be an attempt at defeating the GPL; I don't think that question is relevant. but I don't think anyone can reasonably argue that for our default MTA. That would appear to have even less relevance: whaetheer the program is a Hello, World or our default MTA wouuld seem to have no bearing on the question of its status as a derived work of OpenSSL. What's relevant is whether L is considered, under copyright law, to be a derivative work of those works it is linked with. If M and P are to be considered derivative of OpenSSL, I don't see the legal theory that makes L somehow *not* a derivative work of OpenSSL. -- \ The optimist thinks this is the best of all possible worlds. | `\The pessimist fears it is true. -- J. Robert Oppenheimer | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
Stephen Gran wrote: I have been under the impression that the answer is no. You're not linking L to OpenSSL. It could be argued that this was an attempt at defeating the GPL if P was a thin shim layer between L and OpenSSL, but I don't think anyone can reasonably argue that for our default MTA. Imagine a statically linked P. I do not see how such a thing could be anything less than a combined work of L and OpenSSL (and the rest). Dynamic linking is a bit tougher, and there has been some controversy over it. Debian's policy, as I understand it, is to be as risk-averse as possible, and assume dynamic linking and static linking are equivalent for all relevant purposes without some explicit statement to the contrary. Thus, for Debian's purposes, the task is to prove that statically linking L and OpenSSL as part of the process of constructing the P static executable does not cause that resulting executable to be a derivative work of both L and OpenSSL under copyright law. Frankly, I suspect that it would be impossible to prove such a thing, if only because such a decision would have a massive negative effect on those who make their living from aggressive copyright-mongering, such as the RIAA. But I could be wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
Marc Haber writes (transitive GPL (exim4, OpenSSL, mySQL and others)): (1) Is it ok to change exim's SSL library to OpenSSL in the current setup without violating the GPL for some of the library currently in use You mentioned libpq and mysql. What other libraries are involved ? All of the licences must be compatible. (2) Will it be a violation of the GPL to link exim to a GPL-without-OpenSSL-exemption-clause library in the future? Yes. (3) Is this violation maybe already happening by virtue of linking indirectly to OpenSSL via libpq? Does libpq pull in OpenSSL ? What is the licence of libpq ? I think we could give you a better answer if you provided a full run-down of the facts: a complete list of all of the libraries and programs which are used when you compile exim in this way, how they relate to each other, and what their licenses are. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
On Fri, 9 Nov 2007 19:16:49 +, Ian Jackson [EMAIL PROTECTED] wrote: Marc Haber writes (transitive GPL (exim4, OpenSSL, mySQL and others)): (1) Is it ok to change exim's SSL library to OpenSSL in the current setup without violating the GPL for some of the library currently in use You mentioned libpq and mysql. What other libraries are involved ? I am quite interested in the general case. (3) Is this violation maybe already happening by virtue of linking indirectly to OpenSSL via libpq? Does libpq pull in OpenSSL ? libpq-dev depends on libssl-dev, yes. What is the licence of libpq ? | Permission to use, copy, modify, and distribute this software and its | documentation for any purpose, without fee, and without a written agreement | is hereby granted, provided that the above copyright notice and this | paragraph and the following two paragraphs appear in all copies. (two no warranty disclaimers deleted, see /usr/share/doc/libpq-dev/copyright) I think we could give you a better answer if you provided a full run-down of the facts: a complete list of all of the libraries and programs which are used when you compile exim in this way, how they relate to each other, and what their licenses are. Is there a tool that follows the library link path and at least lists all libraries depended on, or do I need to spend days to collect this manually? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: transitive GPL (exim4, OpenSSL, mySQL and others)
Hi, Le jeudi 08 novembre 2007 à 19:27 +0100, Marc Haber a écrit : (1) Is it ok to change exim's SSL library to OpenSSL in the current setup without violating the GPL for some of the library currently in use As you said, libmysqlclient and exim are OK with linking with OpenSSL. The one problem that could remain is that of libperl. It is OK to link libperl with libssl because libperl is dual-licensed under the GPL and the Artistic license, which is compatible with the OpenSSL license, but that makes another GPL incompatibility. Fortunately, libmysqlclient also allows linking with code under the Artistic license. As for Exim's exception, it is so broad that practically speaking, it is as if it was licensed under the LGPL: In addition, for the avoidance of any doubt, permission is granted to link this program with OpenSSL or any other library package and to (re)distribute the binaries produced as the result of such linking. It would be nice to get explicit permission from the Exim developers to link with Perl code under the Artistic license, but it seems to me that this whole mess is already legally redistributable. (2) Will it be a violation of the GPL to link exim to a GPL-without-OpenSSL-exemption-clause library in the future? Yes. (3) Is this violation maybe already happening by virtue of linking indirectly to OpenSSL via libpq? It would, if exim and libmysqlclient's exceptions weren't so broad. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
