Re: Corel's apt frontend
I think there is something that is being forgotten here. Corel are shipping several things, but presumably they are only dynamically linked. So the reason why they need a licence exemption isn't that their frontend is derivative of lib-apt, but rather that the copyright on lib-apt would require the `whole work' - ie, all the things which are bound together at runtime - to be licensed under the GPL. However, of course, lib-apt isn't the only thing that is bound together at run-time with Qt in this program. dpkg is too - the fact that the interface is program call rather than dynamic linking is an irrelevant technical detail. (This case seems similar to the one where Next wanted to ship GCC with their own Objective-C frontend, but not to release the frontend under the GPL. RMS had his laweyrs write to them and Next changed their mind.) I'm unlikely to be happy to make a licence exemption for Qt, as I have stated on numerous previous occasions. Can someone please send me contact details for someone relevant at Corel, so I can talk to them about it ? I'll try to be nice to them :-). Ian.
Re: Corel's apt frontend
On Fri, Oct 29, 1999 at 01:58:09PM +0100, Ian Jackson wrote: However, of course, lib-apt isn't the only thing that is bound together at run-time with Qt in this program. dpkg is too - the fact that the interface is program call rather than dynamic linking is an irrelevant technical detail. No, actually it's not. If the interface is by program call, than the GPL doesn't affect it. (This case seems similar to the one where Next wanted to ship GCC with their own Objective-C frontend, but not to release the frontend under the GPL. RMS had his laweyrs write to them and Next changed their mind.) But the frontend actually has to be linked to GCC. A more similar one is the M3 frontend, which evades the GPL restrictions by installing a new frontend (which is GPL), and using program calls to link to that program. -- David Starner - [EMAIL PROTECTED]
Re: Corel's apt frontend
Ian Jackson [EMAIL PROTECTED] writes: However, of course, lib-apt isn't the only thing that is bound together at run-time with Qt in this program. dpkg is too - the fact that the interface is program call rather than dynamic linking is an irrelevant technical detail. (This case seems similar to the one This is plain stupid. It would make it impossible to run GPLed software from any propitary shell implementation except maybe /bin/sh. I have non-GPLed sh, csh and a ksh on this system and only one of them can be called a major component of the system. Give a hour and I probally can make a better example. -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, The Dead Past
Re: Corel's apt frontend
Ian Jackson [EMAIL PROTECTED] writes: So the reason why they need a licence exemption isn't that their frontend is derivative of lib-apt, but rather that the copyright on lib-apt would require the `whole work' - ie, all the things which are bound together at runtime - to be licensed under the GPL. The only way the copyright on lib-apt could become an issue at all is if there is something that is derivate of lib-abt. derivitate is the magic word that makes the copyright holder have anything to say. -- Henning Makholm
Re: Corel's apt frontend
David Starner [EMAIL PROTECTED] writes: (This case seems similar to the one where Next wanted to ship GCC with their own Objective-C frontend, but not to release the frontend under the GPL. RMS had his laweyrs write to them and Next changed their mind.) But the frontend actually has to be linked to GCC. I always wondered - if NeXT really had been serious about going proprietary with their front end, what would have stopped them from creating - a fully GPL'ed GCC fork which had the ability to dynamically link to third party plug-ins for doing front-end stuff, using some appropriate open interface plus - a proprietary, binary-only Objective-C plug-in? -- Henning Makholm ... turning pussies into pies Wouldn't do in my shop just the thought of it's enough to make you sick and I'm telling you them pussy cats is quick ...
Re: Corel's apt frontend
On Fri, Oct 29, 1999 at 07:45:43PM +0200, Henning Makholm wrote: David Starner [EMAIL PROTECTED] writes: (This case seems similar to the one where Next wanted to ship GCC with their own Objective-C frontend, but not to release the frontend under the GPL. RMS had his laweyrs write to them and Next changed their mind.) But the frontend actually has to be linked to GCC. I always wondered - if NeXT really had been serious about going proprietary with their front end, what would have stopped them from creating - a fully GPL'ed GCC fork which had the ability to dynamically link to third party plug-ins for doing front-end stuff, using some appropriate open interface plus - a proprietary, binary-only Objective-C plug-in? RMS argues that that is illegal - that the plug-ins to a GPL program are derivates, and must come under the GPL. Actually, something many people have wanted to do for legimate reasons, is make the backend a seperate program, and have the frontend spit out a tree file that the backend reads in. NeXT could have done that. As I mentioned, DEC Modula 3 did something similar. I've also seen something on the compiler list that was known as GNU E (?) and was a GPL'ed frontend and completely proprietary libraries. NeXT also could have made the port in such a way that it only targeted NeXT systems, and put the real proprietary stuff in the kernel or system libraries. -- David Starner - [EMAIL PROTECTED]
Re: Corel's apt frontend
Henning Makholm writes (Re: Corel's apt frontend): The only way the copyright on lib-apt could become an issue at all is if there is something that is derivate of lib-abt. No, that's not true in this case. Read on. derivitate is the magic word that makes the copyright holder have anything to say. I'll switch from talking about lib-apt to talking about dpkg, because that's the case at hand from my POV. Corel are distributing dpkg - ie, they are making copies. Making copies is something that copyright law says only the copyright holder may give permission for. I have given permission for Corel (and others) to make copies of dpkg according to the GPL, which makes the following restriction amongst others: 2... b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. ... These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. So, even if they are not derivative works in copyright law, the GPL can still require that they be GPL'd, if they are distributed `as part of a whole which is a work based on the program'. Note that this requirement doesn't talk at all about the technology which is used to make the pieces work together. I think that the `work as a whole' clause applies in this case, others disagree. Arguing about it won't help much. We'll have to see what Corel think. It would be good if Jason could give me the relevant contact details at Corel so I don't have to fight my way through their phone firewall myself (and risk getting some legal exec who goes off half-cocked). Ian.
Re: non-free, LZW, RSA, and mp3
Brian Ristuccia writes: Also, as best I know, the only time RSA permits its tecnology to be used is in not-for-profit programs compiled with the RSAREF library. Not all the programs in non-free do this. But the programs that use RSA without RSAREF are in non-us, and using the RSA algorithm without permission from RSADSI is not illegal under local laws outside of the US. Following the same logic, perhaps the Debian project could distribute software implementing _any_ patented algorithm from servers located in a jurisdiction known not to recognize algorithm patents, period. The existence of non-us suggests some willingness to try to work around some national laws (primarily with respect to crypto), and the same thing might be done with respect to patented algorithms. Richard Stallman once gave an interesting discussion of the distinction between free software _in general_ and free software _for a particular person_. It seems to me that the distinction has not yet been clarified enough for a world with many different jurisdictions recognizing vastly different legal rights. -- Seth David Schoen [EMAIL PROTECTED] | And do not say, I will study when I http://www.loyalty.org/~schoen/| have leisure; for perhaps you will http://www.loyalty.org/ (CAF)| not have leisure. -- Pirke Avot 2:5
Re: Corel's apt frontend
David Starner [EMAIL PROTECTED] writes: On Fri, Oct 29, 1999 at 07:45:43PM +0200, Henning Makholm wrote: I always wondered - if NeXT really had been serious about going what would have stopped them from creating - a proprietary, binary-only Objective-C plug-in? RMS argues that that is illegal - that the plug-ins to a GPL program are derivates, and must come under the GPL. Ok, so we're back to that ol' familiar what is a deriviate debate. I still fail to see any coherent legal reasoning that would have that outcome, but similar questions have been discussed at length here without anyone being convinced of anything they didn't believe beforhand, so let's just drop this issue. -- Henning MakholmKurt er den eneste jeg kender der er *dum* nok til at gå i *ring* på et jernbanespor.
Re: Corel's apt frontend
(Quick summary - Ian Jackson believes that Corel's new Apt frontend which links to Qt and calls dpkg as an independent program is violating dpkg's GPL license. (The violation of Apt's GPL license was solved by the authors of Apt giving special extension.)) On Fri, Oct 29, 1999 at 07:55:01PM +0100, Ian Jackson wrote: David Starner writes (Re: Corel's apt frontend): On Fri, Oct 29, 1999 at 01:58:09PM +0100, Ian Jackson wrote: However, of course, lib-apt isn't the only thing that is bound together at run-time with Qt in this program. dpkg is too - the fact that the interface is program call rather than dynamic linking is an irrelevant technical detail. No, actually it's not. If the interface is by program call, than the GPL doesn't affect it. I don't think this is true, but I'm not here to discuss it with you. I want to discuss it politely with Corel (and possibly RMS). Wouldn't it be better to discuss it first with people who have an objective view of the matter, instead of going directly to fight the dragon? But the frontend actually has to be linked to GCC. A more similar one is the M3 frontend, which evades the GPL restrictions by installing a new frontend (which is GPL), and using program calls to link to that program. Does RMS know about this ? I suspect that RMS would take a similar view in this case. Yes, he knows about this. He was not amused, but the fact that the frontend to M3 was XFree-style licensed probably helped a little bit. -- David Starner - [EMAIL PROTECTED]
Re: Corel's apt frontend
Ian Jackson [EMAIL PROTECTED] writes: Henning Makholm writes (Re: Corel's apt frontend): I have given permission for Corel (and others) to make copies of dpkg according to the GPL, which makes the following restriction amongst others: 2... b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program A program that calls dpkg using fork() and exec() does not contain dpkg in whole. It does not contain dpkg in part. It is not derived from dpkg. Thus 2(b) has not any force on said program. So, even if they are not derivative works in copyright law, the GPL can still require that they be GPL'd, if they are distributed `as part of a whole which is a work based on the program'. But they aren't. Read on, the GPL proceeds to say: | In addition, mere aggregation of another work not based on the Program | with the Program (or with a work based on the Program) on a volume of | a storage or distribution medium does not bring the other work under | the scope of this License. I.e. you cannot, by sheer force of will and no legal case to back it with, make any random collection of two independent programs into a work to which you can apply GPL 2(b). The collection is not a work in GPL's sense, and it is certainly not a work in the sense of copyright law. -- Henning Makholm I Gudfaders navn og sønnens og den hellige ånds! Bevar os for djævelens værk og for Muhammeds, den forbandedes, underfundigheder! Med dig står det værre til end med nogen anden, thi at lytte til Muhammed er det værste af alt.
Re: Corel's apt frontend
From: Ian Jackson [EMAIL PROTECTED] I'll switch from talking about lib-apt to talking about dpkg, because that's the case at hand from my POV. Corel are distributing dpkg - ie, they are making copies. Making copies is something that copyright law says only the copyright holder may give permission for. Note the GPL language on aggregation. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. If it's not a derivative work, they are aggregating dpkg. Yes, it might be nice if copyright law considered _reference_ to be a form of derivation, but it does not. A shell script is not a work containing all of the programs it executes, nor is a client derivative of its server. And we'd be on rather shaky ground where dynamic libraries are concerned were it not for the headers. I've pointed out before that CORBA can probably be used to circumvent the GPL. When last I discussed that with RMS, he wasn't showing an interest in closing that loophole. Thanks Bruce
