Re: Java, GPL and CDDL
On 13/11/2007, Ben Finney [EMAIL PROTECTED] wrote: Yves Combe [EMAIL PROTECTED] writes: I am wondering if Java GPLed application can link with CDDL classes? Case looks like the cdrecord question i saw in the archive. To understand whether there's a license conflict, there needs to be an understanding of whether copyright is invoked by linking. In many jurisdictions, this boils down to whether the action of distributing a work, Foo, that links to work Bar, is thus distributing a derivative work of Bar. ISTM the key issue is whether the CDDL classes would constitute part of the Corresponding Source (in GPL v3 language) of the Java application, rather than a dynamic vs static linking issue. That in turn hinges on whether the CDDL classes would be regarded as forming part of the System Libraries for the work. The questions to ask are then: a. Are the CDDL libraries included in the normal form of packaging a Major Component, but ... not part of that Major Component? (Would the Major Component here be the JDK?) b. If so, do these serve only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form? If the answer to both those questions is yes then the CDDL-licensed classes are not required to be distributed as part of the Corresponding Source for the GPLed code. If, however, the answer to either (or both) of those questions is no then the classes will form part of the Corresponding Source of the application, and will need to be distributed under the GPL. (It's worth noting that the GPL v3 appears to be more helpful here than GPL v2, which defines the major components exception more narrowly.) CarMetal uses colorchooser https://colorchooser.dev.java.net/ wich is CDDL licensed. Is that ok for dfsg ? As mentioned above, I think what needs to be done is to ask those two questions about whether colorchooser forms part of the System Libraries for CarMetal. If colorchooser is not normally included in the Sun JDK(?) - and the fact it is made available for separate download suggests to me it isn't - then I'd say there is a licensing problem here. This isn't a DFSG problem so much as a GPL/CDDL incompatibility issue more generally. If colorchooser is strikedistributed/strike conveyed under the GPL then this will breach the CDDL. If colorchooser is not included with the Corresponding Source of CarMetal then this will breach the GPL. If I've wildly missed the point somewhere along the line - I'm still new here - then I'm sure someone will point this out, so I'd wait to see if anyone leaps in now! John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The legality of wodim
On Sat, 10 Nov 2007 20:32:01 +0100, Oliver Vivell [EMAIL PROTECTED] wrote: And if you use terms, please translate them into english, that everybody understands them, so don't use Urheberrecht but the english term Intellectual property rights. I have to defend Jörg here. Urheberrecht is a German legal term which has a lot of implicit meaning, and since cdrecord was written in Germany, Jörg is entitled to the rights written in there. So, I think that he is correctly using the German terms. 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)
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: The legality of wodim
On Wed, Nov 14, 2007 at 03:41:21PM +0100, Marc Haber wrote: On Sat, 10 Nov 2007 20:32:01 +0100, Oliver Vivell [EMAIL PROTECTED] wrote: And if you use terms, please translate them into english, that everybody understands them, so don't use Urheberrecht but the english term Intellectual property rights. I have to defend Jörg here. Urheberrecht is a German legal term which has a lot of implicit meaning, and since cdrecord was written in Germany, Jörg is entitled to the rights written in there. Hrm, this doesn't follow automatically. I'm aware of international treaties covering reciprocation of *copyrights*, but none that would mean Urheberrecht has force outside of Germany regardless of where the work was written. Do you have a reference for this? For all I know he does have a legitimate claim under German law that cdrkit infringes his Urheberrecht, but cdrkit is not a German product per se. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The legality of wodim
Steve Langasek wrote: Hrm, this doesn't follow automatically. I'm aware of international treaties covering reciprocation of *copyrights*, but none that would mean Urheberrecht has force outside of Germany regardless of where the work was written. Do you have a reference for this? Urheberrecht is basically a strict implementation of Berne. The term means author's right in English, which is the phrase that most of the world uses to denote this type of legal protection. For historical reasons English uses copyright instead. It's actually US copyright law that's deviating from the norms of international copyright treaties. Berne provides for moral rights for almost all categories of works (art. 6bis), but 17 USC 106A only provides this right for a work of visual art. Arnoud -- Arnoud Engelfriet, Dutch European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ Arnoud blogt nu ook: http://blog.iusmentis.com/ -- 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 [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: DFSG-freeness of any license that fixes the ASP loophole
Shriramana Sharma [EMAIL PROTECTED] wrote: I just discovered that the people I was trying to help to migrate to the GPL might be hesitating because they don't want their software to be used to provide a service over the network without the source being release, claiming that their service does not count as distribution (the ASP loophole). Licences that 'fix' the ASP 'loophole' have two problems: 1. they are a massive distraction from the real problem - if someone evil(?) is using your software, the version they offer for download will not be the version they are running anyway, or they'll hide their innovations in an external program that the ASP'd one communicates with and they won't have to distribute, or any of the other 1001 loopholes in ASP clauses; 2. most break DFSG 1, 2, 3, 4, 5, 6 and/or 9 in some way. http://www.funambol.com/blog/capo/files/HPL_draft.txt Since everyone on this list (I presume) can get the GPL at /usr/share/common-licenses/GPL-2, I provide only the additional clause: d) For the purposes of determining the right to obtain copies of the source code (as well as the right to modify and distribute such source code and object code), the term distribution shall include the communication of the Program or work based on the Program which is intended to interact with third party users (meaning anyone other than you or if you are an entity such as a corporation and not an individual, that corporation), through a computer network and the user shall have the right to obtain the source code of the Program or work based on the Program. This provision is an express condition for the grants of license hereunder and any such communication shall be considered a distribution under Section 1, 2 and 3. So does that mean any binary package must also install the source code, in order to offer the right to obtain it? IIRC, that fails DFSG 3. The same is true of the simplification. Now, what software is this about? 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: Policy on Binary Firmware Fetching in Main (e.g. foo2zjs)
To use a rough analogy, compiz doesn't work on certain graphics cards unless one uses the proprietary driver for that card, but that doesn't in itself make compiz non-free. right, but this situation is different. so lets assume that foo2zjs is analogous to compiz and the printer firmware is analogous to a non-free video driver. then the analogous situation that we have is a compiz package that includes a script that the user can invoke to download and install the non-free driver. i conjecture that most would quite disapprove of this situation. they would rightfully want the non-free driver to be in its own package and reside in the non-free archive that is unsupported. If compiz automatically downloaded and installed the appropriate driver as part of installation then that would seem to make it non-free. If compiz had such a download as a post-installation option that could be skipped, then would that mean it remained free? i don't see a difference. if any part of the package requires access to non-free data to function correctly, then the entire package should be considered to depend on non-free. this is different from the compiz situation where the package can make use of non-free stuff if it's already provided by some other package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Policy on Binary Firmware Fetching in Main (e.g. foo2zjs)
Stephen Gran wrote: does getweb function correctly if the external files are unable to be downloaded? That's not a very useful question - does a web browser function 'correctly' when it gets a 404? It depends entirely on what you mean by correctly, and that starts to feel like there's no bright line test for it. this analogy does not apply to the thought experiment. the question in my email was used as a logical starting point for the entire paragraph, and is quite meaningless out of context. to make a reasonable counter-argument, you must respond to the entire paragraph, not just one sentence. btw, the point of that argument was solely to prove that getweb depends on non-free data, which should be quite obvious, but arguments are somehow being made against that fact. That being said, packages that exist solely to download external non-free content have traditionally been considered contrib material. If this is just a helper script that nothing else in the package uses, it seems perfectly fine to me to keep it in main, but ship the script in examples/ or something. getweb can be considered a helper script, but it also exists solely to download non-free content. so it falls in to both of your categories. the rest of the package does not invoke getweb, but can make use of the stuff that is download given that the user has invoked the script himself or herself first. regards, mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Policy on Binary Firmware Fetching in Main (e.g. foo2zjs)
You are missing the point: some printers may or may not work, but the program itself still has the same capabilities and is not influenced by what getweb does. that's why it is ok for most of the program to be in main. its just getweb that depends on non-free data. No, it does not. you missed my email with the logical proof that there is a dependency: does getweb function correctly if the external files are unable to be downloaded? if the answer is no, then the script must be considered to depend on those files. and since those external files contain non-free data, then the script must be considered to depend on non-free data. you need to show me the flaw in this logic rather than just saying no, you're wrong. prove to me that you're right. No, this sounds like you are not aware of how this kind of programs has been evalued by the ftpmasters for about the last 10 years. just because its aways been done like this, does not necessarily make it right. for the longest time, non-free documentation was fine in main, but not any more. as circumstances arise, and experience is gained, one must reevaluate how things are done, and adapt. otherwise, progress will never be made. regards, mike -- 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]
