Re: On interpreting licences (was: KDE not in Debian?)
On Mon, 14 Feb 2000 13:03:38 -0500, Raul Miller [EMAIL PROTECTED] wrote: Are you now claiming that it's legal to distribute kghostscript? On Mon, Feb 14, 2000 at 03:21:44PM +0100, Marc van Leeuwen wrote: Yes, definitely, if you are distributing sources; from your remarks I conclude that even you would agree to this. One could include scripts to compile and link (say statically, just to get the worst case) those sources onto a complete executable; since all the tools necessary to do that could also be (and are in fact) legally distributed by the same distributor, the effect is that this executable will be identical, bit by bit, to an executable that the distributor could assemble. So the exact same effect is achieved, although slightly less efficiently, as if the distributor had directly distributed that executable file. But, we agree, the latter would certainly not be permitted. If the exact same affect is achieved -- if no user intervention is required -- then there's no legal protection gained by automatically building the executables for the customer on their machine. You'd still be distributing executables, you'd just be using a different technology to deliver them. [...] There's a difference between simply distributing GPLed sources and distributing the sources as a part of a system which automatically builds working executables. In the latter case it's pretty obvious that you are distributing executables. In fact I wasn't necessarily thinking about generating the executables in a 100% automated way (although that might be a possibility), just about ensuring that the executables will be 100% identical to what the distributor has. But your remark reveals an interesting line of thought, one that would never have occurred to me. It considers any inconvenience, caused to the recipients by having to distribute sources, not as an inevitable by-product of having to abide by the conditions of the licence, but rather as a condition that in and by itself is necessary for the legality of the distribution. This raises the further question as to how much inconvenience is necessary for that legality. Obviously having to wait a couple of minutes for gcc to complete doing its thing is not sufficient. Why, the user might even be enjoying a cappucino at the same time! Would it suffice to have to click on a button labelled Compile and install the program (some consider something similar sufficient to enter into a legally binding contract, so why not)? Nah, too easy! Although you would have to come dangerously close to your computer, you could manage to do that without even putting down your cappucino. To have to type Y to a prompt Do you want to install the program [y/N]? . Same difference! Having to type make? Here I would personally put down my cup, but I guess with some practice, it can still be done without; it's still too easy! Having to read through a README file to find that the proper incantation is to type: I would like to compile and install this program now, please. (exact spelling and punctuation required, the README could be in pdf to prevent cheating by cut-and-paste)? That ought to do it: even if you do manage to do that while holding on to your cup, it would be cold by the time you finished. Of course I'm being silly here. The real measure of inconvenience has nothing to do with coffee. The inconvenience just should be great enough to allow the conclusion therefore there is just no way that we can include KDE in Debian. As long as conclusions are being used to find the arguments, no wonder people can't ever seem to agree on those arguments. Now apart from distributing sources and distributing a statically linked executable, there are other methods to give users access to an executable, varying in the amount of work do be done at the recipients end. Offhand I can think of distributing compiled but unlinked object files, or distributing dynamically linked object files; maybe other possibilities exist as well. Please take a look at http://www.debian.org/Lists-Archives/debian-legal-0002/msg00211.html for a historical example of shipping unlinked object files. I had almost cited that case (of NeXT and Objective C/gcc) in my original message to show how opinions can vary in these matters, but had decided not to do so because that case is dual to KDE/Qt (non-GPL on top of GPL rather than GPL on top of non-GPL), and therefore does not quite match the example. Marc van Leeuwen Universite de Poitiers http://wwwmathlabo.univ-poitiers.fr/~maavl/
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 15, 2000 at 12:00:51PM +0100, Marc van Leeuwen wrote: But your remark reveals an interesting line of thought, one that would never have occurred to me. It considers any inconvenience, caused to the recipients by having to distribute sources, not as an inevitable by-product of having to abide by the conditions of the licence, but rather as a condition that in and by itself is necessary for the legality of the distribution. This raises the further question as to how much inconvenience is necessary for that legality. It's not inconvenience that's relevant. What's relevant is what the distributor intended to distribute, and what decisions are available to the end user. If the distributor intends to distribute a working copy of kghostview and the end user has only one option -- which involves libqt -- in receiving that working copy, in that case there's not much of a legal question about what's going on. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, 15 Feb 2000 08:10:57 -0500 Raul Miller [EMAIL PROTECTED] wrote: It's not inconvenience that's relevant. What's relevant is what the distributor intended to distribute, and what decisions are available to the end user. If the distributor intends to distribute a working copy of kghostview and the end user has only one option -- which involves libqt -- in receiving that working copy, in that case there's not much of a legal question about what's going on. Do you mean that distributing sources of kghostview, not for the purpose of literary enjoyment of reading the sources, and in practical absence of any alternatives for libqt, would be equally illegal as distributing binaries, even without automated building of exectables? Marc van Leeuwen
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 15, 2000 at 04:16:07PM +0100, Marc van Leeuwen wrote: Do you mean that distributing sources of kghostview, not for the purpose of literary enjoyment of reading the sources, and in practical absence of any alternatives for libqt, would be equally illegal as distributing binaries, even without automated building of exectables? I can't say without knowing more of the specifics of the situation. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Fri, 11 Feb 2000 12:34:29 -0500, Raul Miller [EMAIL PROTECTED] wrote: On Fri, Feb 11, 2000 at 05:26:47PM +0100, Marc van Leeuwen wrote: Nobody in this discussion is claiming (as far as I can see) that by some subtle shuffling of pieces you can get a (composite) program from A to B without requiring permissions from all copyright owners. It seems to me that that's exactly what people are saying when they claim that it's legal to distribute kghostscript. The point is that the complex conditions in the licences, in partcular GPL, may lead to a situation where such permission may be obtained for some particular method of distribution, but not for some other method. For instance, you may distribute in source form (and under GPL) a GPL-ed an application that links to Qt (because then there is no requirement to distribute complete sources), while also distributing Qt (in source and binary) under QPL; the recipient could compile and link an executable program which does not happen to spring into existence, and which was the goal of distributing the GPL sources, yet which could not have been legally distributed directly. Certainly: it's only if you distribute executables or object code that there's any requirement to distribute the complete source for the program. I think you put forward yourself another example (a Solaris-linked GPL binary and Solaris itself), where the components might be legally distributed separately (assuming permission from Sun) but not together. Right: that was an example of a situation which takes advantage of the special exception in section 3 of the GPL. So please don't suggest any more that people are trying to evade copyright law when in fact they are trying (maybe by jumping through hoops) to abide by the conditions put forth in the licence(s). Are you now claiming that it's legal to distribute kghostscript? Yes, definitely, if you are distributing sources; from your remarks I conclude that even you would agree to this. One could include scripts to compile and link (say statically, just to get the worst case) those sources onto a complete executable; since all the tools necessary to do that could also be (and are in fact) legally distributed by the same distributor, the effect is that this executable will be identical, bit by bit, to an executable that the distributor could assemble. So the exact same effect is achieved, although slightly less efficiently, as if the distributor had directly distributed that executable file. But, we agree, the latter would certainly not be permitted. Probably your question was about another method of distribution than in source form. But instead of diving for the umpteenth time into matters about which we (and many others) have already amply demonstrated to have differences of opinion, let me just restate that on which we do seem to agree. If our goal is to give users access to an executable version of kghostscript, then there is a reliable method of doing that (distributing sources) that satisfies all the requirements in the relevant licences, while there is another method (distributing the statically linked executable file directly) that does not satisfy all requirements, in particular not those of the GPL. We arrived at this conclusion not by trying to evade copyright law, but merely by reading carefully the conditions of the GPL. Now apart from distributing sources and distributing a statically linked executable, there are other methods to give users access to an executable, varying in the amount of work do be done at the recipients end. Offhand I can think of distributing compiled but unlinked object files, or distributing dynamically linked object files; maybe other possibilities exist as well. Somewhere in this range of possibilities there is a dividing line between legally possible and not legally possible. If you ask me where I personally would put the line, then I would say: probably between the dynamically and the statically linked files; I arrive at this conclusion not by general considerations of copyright law, but by carefully reading the text of the GPL. I will accept that differences of opinion can exist here, in particular since it would seem that the GPL (and LGPL) was formulated without the distinction between static and dynamic linking in mind, making it highly unlikely that it was intended that one case be covered but the other not. But even if an advocate of legally possible would give up the position of dynamically linked executables (did anybody ever give up a position in this discussion?:-) he could still maintain that of unlinked object files with fresh arguments (such as: GPL 3 starts with You may copy... the Program... in object code OR executable form and later For an executable work, complete source code means... which apparently does not apply to unlinked object code). And then I don't even mention the possibilities of actually modifying the kghostscript
Re: On interpreting licences (was: KDE not in Debian?)
So please don't suggest any more that people are trying to evade copyright law when in fact they are trying (maybe by jumping through hoops) to abide by the conditions put forth in the licence(s). Are you now claiming that it's legal to distribute kghostscript? On Mon, Feb 14, 2000 at 03:21:44PM +0100, Marc van Leeuwen wrote: Yes, definitely, if you are distributing sources; from your remarks I conclude that even you would agree to this. One could include scripts to compile and link (say statically, just to get the worst case) those sources onto a complete executable; since all the tools necessary to do that could also be (and are in fact) legally distributed by the same distributor, the effect is that this executable will be identical, bit by bit, to an executable that the distributor could assemble. So the exact same effect is achieved, although slightly less efficiently, as if the distributor had directly distributed that executable file. But, we agree, the latter would certainly not be permitted. If the exact same affect is achieved -- if no user intervention is required -- then there's no legal protection gained by automatically building the executables for the customer on their machine. You'd still be distributing executables, you'd just be using a different technology to deliver them. Probably your question was about another method of distribution than in source form. But instead of diving for the umpteenth time into matters about which we (and many others) have already amply demonstrated to have differences of opinion, let me just restate that on which we do seem to agree. If our goal is to give users access to an executable version of kghostscript, then there is a reliable method of doing that (distributing sources) that satisfies all the requirements in the relevant licences, while there is another method (distributing the statically linked executable file directly) that does not satisfy all requirements, in particular not those of the GPL. We arrived at this conclusion not by trying to evade copyright law, but merely by reading carefully the conditions of the GPL. There's a difference between simply distributing GPLed sources and distributing the sources as a part of a system which automatically builds working executables. In the latter case it's pretty obvious that you are distributing executables. But I will grant that this is not a technique which linux distributors are currently using to distribute kde executables. Now apart from distributing sources and distributing a statically linked executable, there are other methods to give users access to an executable, varying in the amount of work do be done at the recipients end. Offhand I can think of distributing compiled but unlinked object files, or distributing dynamically linked object files; maybe other possibilities exist as well. Please take a look at http://www.debian.org/Lists-Archives/debian-legal-0002/msg00211.html for a historical example of shipping unlinked object files. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
(please don't drop debian-legal from the Cc list) On Sun, Feb 13, 2000 at 08:39:13PM +1100, Don Sanders wrote: On Sun, 13 Feb 2000, Anthony Towns wrote: Third, I challenge you to find a relevant case that says a program is the same work, for copyright purposes, with a dynamically loaded library when it is not running. *shrug* So show me some precedents for considering them separately. This is pretty much a null argument. MS windows programming is a good example of that. Programming on Windows requires linking to MS dlls. Note that `MS windows programming' is not a court case. And again this is completely irrelevant: it's not an issue for the GPL because the GPL exempts these as being distributed with major components of the OS; and it's not an issue for anyone writing software for Windows because Microsoft specifically gives you permission to redistribute it. Of course, if that were the case, then every single MS Windows program would be a derived work of MS Windows dlls and would require the consent of Microsoft to be distributed. And just to clarify: whether Microsoft's consent is required or not doesn't particularly matter: Microsoft have *given* their consent. That is, it didn't differentiate between statically linked executables (which clearly makes a combined work under copyright law), and dynamically linked binaries (which is less clear). I should add: and as such, there's probably a reasonable chance that a court would be willing to extrapolate the existing terms to cover a new possibility that wasn't considered explicitly. No comment. But see the list archives. Let me guess: Andreas Pour thinks differently, and as a KDE supporter is an authority in the matter? Please, feel free to cite a case (a court case, not a kde-licensing debate) where it was ruled that a license that didn't consider a technique or technology that became common a few years later, but had considerations for a somewhat analogous technique or technology could not be extrapolated. It doesn't have to be related to computers at all. Anything will be fine. Now with dynamically liked GPL software we have three cases: (c) A GPLed binary linked against a GPL-incompatible library (dynamic linking in all cases) We'll note that in no case is the library a derived work (in any sense) based on the binary (it doesn't include any code from the binary, it's perfectly usable without the binary having ever been written, and so on). The final case, (c), which is what KDE fits under, doesn't have as easy an out, though. This assumes that Qt is GPL-incompatible. I may or may not agree with that, it could really mean a wide range of things. It means that it can't be distributed under the terms of sections 1 and 2 of the GPL. It means you can't make a statically linked binary linking to it and distribute it. Etc. The important question is when applying the GPL to a KDE application is QT part of the Program (and please see the definition of the Program given in Section 0). If is then QT can't be distributed under the terms of sections 1 and 2. If QT isn't part of the Program then it can and must (if you believe QT is as part of the complete source) be distributed under the terms of Sections 1 and 2. Erm, what? ``If Qt isn't part of the Program then it can and must be distributed under the terms of Sections 1 and 2'' ? Are you trying to say that since Qt doesn't have `GPLed' labelled on it somewhere, then it's not the Program and since terms 1 and 2 only apply to the Program, they don't apply to Qt, even when term 3 says it does apply? ie, are you trying to say that section 3a is technically meaningless, because the complete source code won't be labelled GPLed, and hence won't be distributable under sections 1 and 2? And because it's technically meaningless it can be completely struck at and conveniently ignored? Or am I reading too much into a typo somewhere? Qt *cannot* be distributed under terms 1 and 2 of the GPL: term 2 gives your more freedom in how you make your modifications than the QPL permits. Only Troll have the right to give that extra permission, no one else does. If the GPL *requires* you to distribute Qt under terms 1 and 2 of the GPL in order to do something (distribute binaries, eg), then you *can't* do that someting because you *can't* distribute Qt under terms 1 and 2 of the GPL. See also the Xfree license issue. It's highly relevant. There is no `Xfree license issue'. I'm allowed to distribute a program using code under both licenses as long as I: * conspicuously and appropriately put an appropriate copyright notice and disclaimer of warranty somewhere * keep the GPL and disclaimer of warranty intact * i may charge a fee * if i modify it, i have to add notices * i have to make sure everyone can use it according to the GPL
Re: On interpreting licences (was: KDE not in Debian?)
Around 1989, NeXT wanted to release the Objective C front end as just object files, and tell the user to link them with GCC. Since this would clearly be against the goal of the GPL, I asked our lawyer whether we had grounds to object. He said that what NeXT proposed to do would be tantamount to distributing a larger program which contains GCC, and therefore would violate the GPL. I conveyed this to NeXT, and they released the Objective C front end as free software. An executable in which the GPL-covered code is linked as a shared library or dynamically linked is an even stronger case. The point is that the users are being told to run the non-free code in combination with the GPL-covered code. If, on the other hand, two programs don't need to be linked together and are distributed for use separately, and a user decides on his own initiative to link them together and run them, the GPL permits that because the combination is in no sense being distributed.
Re: On interpreting licences (was: KDE not in Debian?)
On Sun, 13 Feb 2000, Anthony Towns wrote: (please don't drop debian-legal from the Cc list) On Sun, Feb 13, 2000 at 08:39:13PM +1100, Don Sanders wrote: On Sun, 13 Feb 2000, Anthony Towns wrote: Third, I challenge you to find a relevant case that says a program is the same work, for copyright purposes, with a dynamically loaded library when it is not running. *shrug* So show me some precedents for considering them separately. This is pretty much a null argument. MS windows programming is a good example of that. Programming on Windows requires linking to MS dlls. Note that `MS windows programming' is not a court case. I'm not going to cite a case, but there is a precedent. If linking a Windows program to an MS dll makes the program a derived work of the MS dll then all 3rd part application vendors on the MS platform are guilty of copyright violation. (As they distribute those derived works without permission from MS). And again this is completely irrelevant: it's not an issue for the GPL because the GPL exempts these as being distributed with major components of the OS; and it's not an issue for anyone writing software for Windows because Microsoft specifically gives you permission to redistribute it. Of course, if that were the case, then every single MS Windows program would be a derived work of MS Windows dlls and would require the consent of Microsoft to be distributed. And just to clarify: whether Microsoft's consent is required or not doesn't particularly matter: Microsoft have *given* their consent. Wrong. Microsoft are very choosy about which dlls they allow 3rd part application developers to distribute. 3rd party MS windows developers can only distribute a few MS dlls that MS chooses. There are dlls that MS allows developers to link against but not to distribute. But this argument wasn't about distribution it was about whether linking a program to a library makes the program a derived work of the library. These are seperate issues. That is, it didn't differentiate between statically linked executables (which clearly makes a combined work under copyright law), and dynamically linked binaries (which is less clear). I should add: and as such, there's probably a reasonable chance that a court would be willing to extrapolate the existing terms to cover a new possibility that wasn't considered explicitly. No comment. But see the list archives. Let me guess: Andreas Pour thinks differently, and as a KDE supporter is an authority in the matter? Please, feel free to cite a case (a court case, not a kde-licensing debate) where it was ruled that a license that didn't consider a technique or technology that became common a few years later, but had considerations for a somewhat analogous technique or technology could not be extrapolated. It doesn't have to be related to computers at all. Anything will be fine. Which portions of KDE were written when dynamic linking was not common. If there are none then I don't think this is relevant. *But I could be wrong*. Now with dynamically liked GPL software we have three cases: (c) A GPLed binary linked against a GPL-incompatible library (dynamic linking in all cases) We'll note that in no case is the library a derived work (in any sense) based on the binary (it doesn't include any code from the binary, it's perfectly usable without the binary having ever been written, and so on). The final case, (c), which is what KDE fits under, doesn't have as easy an out, though. This assumes that Qt is GPL-incompatible. I may or may not agree with that, it could really mean a wide range of things. It means that it can't be distributed under the terms of sections 1 and 2 of the GPL. It means you can't make a statically linked binary linking to it and distribute it. Etc. The important question is when applying the GPL to a KDE application is QT part of the Program (and please see the definition of the Program given in Section 0). If is then QT can't be distributed under the terms of sections 1 and 2. If QT isn't part of the Program then it can and must (if you believe QT is as part of the complete source) be distributed under the terms of Sections 1 and 2. Erm, what? ``If Qt isn't part of the Program then it can and must be distributed under the terms of Sections 1 and 2'' ? Yes, because Qt is part of the complete source code, section 3 requires the complete source code to be distributed under the terms of Sections 1 and 2 (of the GPL). Are you trying to say that since Qt doesn't have `GPLed' labelled on it somewhere, then it's not the Program and since terms 1 and 2 only apply to the Program, they don't apply to Qt, even when term 3 says it does apply? You're almost there. distributing the complete source code under Sections 1 and 2 of the GPL does not
Re: On interpreting licences (was: KDE not in Debian?)
On Mon, Feb 14, 2000 at 01:20:22AM +1100, Don Sanders wrote: Qt *cannot* be distributed under terms 1 and 2 of the GPL: term 2 gives your more freedom in how you make your modifications than the QPL permits. Only Troll have the right to give that extra permission, no one else does. I disagree. However, section 6 of the GPL conflicts with sections 3b [plus 4c] of the QPL. You can't legally distribute code which has all of these restrictions placed on it. Sections 0, 1, 2 and 3 of the GPL are important in understanding why kghostview has all of these restrictions placed on it. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
Anthony Towns wrote: (debian-legal brought back into the Cc list) On Sat, Feb 12, 2000 at 04:02:35PM -0500, Andreas Pour wrote: Anthony Towns wrote: For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Emphasis yours. The intention of the authors (GNU and rms) is fairly clear, and they make their interpretation fairly clear in the LGPL's (written by the same authors) preamble: When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. [...] As such, I'm not really sure how you can say ``But that's not what RMS meant, coz that's not what he wrote, see, this is what the dictionary says and everything!'' and expect to be taken seriously. First of all, what RMS thinks is not relevant [...] But what you think is, of course. To the extent I try to comply with relevant legal obligations, what I think is most relevant. But anyway that's not the issue. My interpretations are only as convincing as my reasoning and my explanations. RMS' reasoning and explanations can of course be convincing as well. The problem with your quote is, there was no reasoning or explanation, just a conclusory assertion. I would expect my conclusory assertions not to convince anyone either. Basically it's a matter of epistemology. I gain little knowledge from pronouncements from the mountain top. I learn from debate, reflection and critical analysis. Do you not concede that RMS is something of an expert both in relation to software in general, and in relation to the GPL? The former, yes. The latter, I am not sure. My take on it is that he has a view about what he wants/wanted it to say, that most heavily guides his interpretation of what in fact it does say. In other words, I do not believe he is objective in interpreting the language. FWIW, I very much respect RMS as a programmer, and as an evangelist, but not as a lawyer. In fact I still hope that something positive can come out of this debate -- that the loopholes/mistakes in the GPL can be fixed. Why is it that you appear to be so against admitting the problems with the GPL and fixing them? As such, do you not think he might understand some of the nuances in the language of the GPL better than, say, the authors of your dictionary? Absolutely not. When a court tries to interpret the license (since you agree it's a legal document, in the end only a court's interpretation matters) the court will look to a dictionary -- this is a quite common practice when courts interpret legal agreements. That will be evidence in the case. RMS will not. His testimony will not be allowed, most likely (things being different if his code is in fact at issue). This is for the exact same reason that when the meaning of a statute is in question Congressmen are not called in to testify as to its meaning. The contract is generally interpreted objectively (and if any subjective component comes in it is that of the licensor -- the code author -- rather than the lawyer or organization that did the drafting). Using a dictionary to interpret a license is objective -- using RMS' opinion (or mine or anyone else's) is not. Does it not seem even with the realm of possibility that it might be the case? Does it seem even within the realm of possibility that I know what I am talking about? Your second and third points are just restatements of this. Third, I challenge you to find a relevant case that says a program is the same work, for copyright purposes, with a dynamically loaded library when it is not running. *shrug* So show me some precedents for considering them separately. This is pretty much a null argument. Are you sure? At least I have obvious reasons for considering them separately. First, they are not in fact part of the same work. It is no different than if you write a book, and then I write a book reviewing yours. My book depends on your book, yet it is a totally different work (assuming I only make fair use of excerpts from your book). Same holds true for software. My program (kghostview) is a totally separate work from Qt, *especially* in source code form. Second, everyday practice confirms my point. Obviously MS prohibits people from distributing Windows DLLs w/out their consent. Yet tons of companies and individuals distribute libraries linked to their DLLs w/out their consent. Under your theory, Apache would need the consent of MS to distribute Apache for NT, as would all other GPL'd
Re: On interpreting licences (was: KDE not in Debian?)
Date forwarded: 13 Feb 2000 11:23:26 - Date sent: Sun, 13 Feb 2000 04:23:21 -0700 (MST) From: Richard Stallman [EMAIL PROTECTED] To: aj@azure.humbug.org.au Copies to: debian-legal@lists.debian.org Subject:Re: On interpreting licences (was: KDE not in Debian?) Send reply to: [EMAIL PROTECTED] Forwarded by: debian-legal@lists.debian.org Around 1989, NeXT wanted to release the Objective C front end as just object files, and tell the user to link them with GCC. Since this would clearly be against the goal of the GPL, I asked our lawyer whether we had grounds to object. He said that what NeXT proposed to do would be tantamount to distributing a larger program which contains GCC, and therefore would violate the GPL. I conveyed this to NeXT, and they released the Objective C front end as free software. [cut] I am not an expert in comon law, I only knew something about continental law but the case described above look for me as difrerent from the one which is discussed here. In the NEXT case the proprietary license was linked on GPL. In Trol Tech case we are talking about GPL linked on non-fully-free licence. For me this is totaly diferent story. If I am right? zakend navigare necesse est even on the web
Re: On interpreting licences (was: KDE not in Debian?)
On Thu, Feb 10, 2000 at 12:53:02PM -0500, Raul Miller wrote: Either the program uses readline or it doesn't. If it does use readline, and it's distributed with readline, then, strictly-speaking, it contains readline. I disagree.. If it was not built using one piece of readline (ie, none of readline's headers) it does not contain readline until it is run. The GPL doesn't say that a program has to be built using headers. You're right, it doesn't. I just don't see how the GPL has the right to affect use of the software (as opposed to development) given that use of software is beyond the GPL's scope. The GPL has no power to apply to non-GPL'd works which are not derivative in source or binary form from GPL'd works. We have already established this as true else the GPL would have failed the DFSG. In order for you to apply the GPL's terms to this hypothetical program you must first establish that a derivative work is being distributed. In the case of a GPL'd KDE app that's easy. In the case of an app linked against GPL'd headers, that's easy again. An app which is not GPL'd and does not fall into either of the above categories is a bit more difficult---I don't see the derivision. Your claim would mean that if, for example, I use a hex editor on a program to alter the libraries it uses, that I would be able to build programs that are built on GPLed code but which aren't bound by the GPL. I may not fully grasp the connection here, so let me extend this example to be sure I do actually understand your point: Instead of very late binding as mentioned previously, you would use late binding (ie, dynamic linking) by #include'ing say myreadline/readline.h or whatever files and have -lmyreadline in the makefile's LDFLAGS... This would produce a program linked against libmyreadline.so which happens to share GNU readline's ABI. Then to make it instead use GNU readline you would modify it such that ld.so would load the equivalent libreadline.so, much as I modified the pre-source release glquake binary to use libGL.so.1 in place of libMesaGL.so.2.6.. You are saying that this would not sit well with the GPL on GNU readline and be considered infringement. You might be right---I could not even begin to guess at how this would be handled. It's IMO right on the borderline and without a legal decision (it wouldn't have to be case law necessarily as this discussion is academic more than it is legal being that we're not lawyers) I'd say it's too close to call. If you've got a reference to a decision I'd love to read it though. In the case of very late binding, it seems to be a little bit past that line IMO.. I think it would have to be decided by a judge on a case by case basis until there was some case law which firmly considered very late binding to be the same as dynamic binding (which clearly is the same as static binding because of the GPL'd API and the ABI symbols read from the shared object library.. I am curious how you think the BSDish readline would stack up in these examples. The BSDish readline replacement uses the name libreadline. It also places its headers in where GNU readline would. Essentially, they are two different libraries which do share a common interface in terms of API, ABI, and soname. I believe it can even be built as a wrapper for the BSD equivalent of readline to provide almost full feature compatibility. This is a case where there are two alternatives for a library. One is GPL'd and is usually found on Linux systems, the other is not and _can_ be found on Linux systems but probably wouldn't be. It may or may not be found on other systems. The GPL can't control usage, only distribution. True. Which is why I pointed out that it matters how the program is being distributed. Agreed. I am of the opinion that static vs dynamic linking is irrelivant because in Qt's case the inclusion of Qt happens before linking. I'm of the opinion that it doesn't matter because working copies of the program are being distributed, and those working copies contain both QPL and GPL licensed code. Even in a late binding situation the ABI symbols and headers are linked in. If you replace the headers you still have the symbols. If you replace the shared lib, well you have a more complex situation. libGL for example, if the API and ABI are the same for all Linux GL implementations, the fact that some of them may be under the GPL or other licenses cannot force binaries built against the generic API/ABI to be GPL'd. That'd just be seriously overreaching. The GPL doesn't care how the program is built -- that's not something that matters to the GPL. Agreed. However the GPL has no say (whether it would care or not) if there is no derived work being distributed. It seems that very late binding would screw that up because there is never a derivision, not even headers or symbols. -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer
Re: On interpreting licences (was: KDE not in Debian?)
On Thu, Feb 10, 2000 at 12:53:02PM -0500, Raul Miller wrote: Either the program uses readline or it doesn't. If it does use readline, and it's distributed with readline, then, strictly-speaking, it contains readline. I disagree.. If it was not built using one piece of readline (ie, none of readline's headers) it does not contain readline until it is run. The GPL doesn't say that a program has to be built using headers. On Thu, Feb 10, 2000 at 06:41:11PM -0800, Joseph Carter wrote: You're right, it doesn't. I just don't see how the GPL has the right to affect use of the software (as opposed to development) given that use of software is beyond the GPL's scope. The GPL has no power to apply to non-GPL'd works which are not derivative in source or binary form from GPL'd works. We have already established this as true else the GPL would have failed the DFSG. Are you claiming that a working copy of kghostscript is an example of a non-GPL'd work which is not derivative in source or binary form from GPL'd works? If not, what relevance is the above line of thought? In order for you to apply the GPL's terms to this hypothetical program you must first establish that a derivative work is being distributed. In the case of a GPL'd KDE app that's easy. In the case of an app linked against GPL'd headers, that's easy again. An app which is not GPL'd and does not fall into either of the above categories is a bit more difficult---I don't see the derivision. The distinction between compile time and run time is artificial -- it's technology dependent. Build a new language, or maybe a new environment, and you have a new set of distinctions to work with. There's nothing fundamentally relevant to copyright law in this sort of distinction. If you somehow manage to decide that you have a way of coming up with a working copy of a program which is never distributed, you could apply the same underlying principle to any other copyrighted work. If a work only exists when the program is running, but millions of copies of that work exist in the hands of millions of users, do you really think that a court of law would accept the sleight of hand argument that those copies were never distributed -- that they just happened to spring into existence, by coincidence? Your claim would mean that if, for example, I use a hex editor on a program to alter the libraries it uses, that I would be able to build programs that are built on GPLed code but which aren't bound by the GPL. I may not fully grasp the connection here, so let me extend this example to be sure I do actually understand your point: Instead of very late binding as mentioned previously, you would use late binding (ie, dynamic linking) by #include'ing say myreadline/readline.h or whatever files and have -lmyreadline in the makefile's LDFLAGS... This would produce a program linked against libmyreadline.so which happens to share GNU readline's ABI. Then to make it instead use GNU readline you would modify it such that ld.so would load the equivalent libreadline.so, much as I modified the pre-source release glquake binary to use libGL.so.1 in place of libMesaGL.so.2.6.. You are saying that this would not sit well with the GPL on GNU readline and be considered infringement. You might be right---I could not even begin to guess at how this would be handled. It's IMO right on the borderline and without a legal decision (it wouldn't have to be case law necessarily as this discussion is academic more than it is legal being that we're not lawyers) I'd say it's too close to call. If you've got a reference to a decision I'd love to read it though. Making the modification is fine as long as you don't go about distributing the result. If you're distributing lots of these the technical details about how you did it are irrelevant. The point is that you're distributing modified copies. The details of how you accomplished the modifications are irrelevant. [Unless you accept the idea that you can build technology to build distribution channels which are beyond the reach of copyright law.] In the case of very late binding, it seems to be a little bit past that line IMO.. I think it would have to be decided by a judge on a case by case basis until there was some case law which firmly considered very late binding to be the same as dynamic binding (which clearly is the same as static binding because of the GPL'd API and the ABI symbols read from the shared object library.. If a document only exists when it's being displayed, but millions of users get a copy of that document, would copyright law apply to it? I am curious how you think the BSDish readline would stack up in these examples. The BSDish readline replacement uses the name libreadline. It also places its headers in where GNU readline would. Essentially, they are two different libraries which do share a common interface in terms of
Re: On interpreting licences (was: KDE not in Debian?)
I'll give it just one more shot... Raul Miller [EMAIL PROTECTED] spake: On Thu, Feb 10, 2000 at 06:41:11PM -0800, Joseph Carter wrote: The GPL has no power to apply to non-GPL'd works which are not derivative in source or binary form from GPL'd works. We have already established this as true else the GPL would have failed the DFSG. Are you claiming that a working copy of kghostscript is an example of a non-GPL'd work which is not derivative in source or binary form from GPL'd works? Of course not, he was discussing an example of the dual situation, a non-GPL program linking to a GPL-ed library (readline); this point was brought up for comparison in Anthony Towns' excellent post of 9 Feb. It is that case in which the question is relevant whether or not copyright law requires GPL's conditions to be respected (i.e., whether or not there is a GPL-derived work). The distinction between compile time and run time is artificial -- it's technology dependent. Build a new language, or maybe a new environment, and you have a new set of distinctions to work with. There's nothing fundamentally relevant to copyright law in this sort of distinction. If you somehow manage to decide that you have a way of coming up with a working copy of a program which is never distributed, you could apply the same underlying principle to any other copyrighted work. If a work only exists when the program is running, but millions of copies of that work exist in the hands of millions of users, do you really think that a court of law would accept the sleight of hand argument that those copies were never distributed -- that they just happened to spring into existence, by coincidence? Yes, a court of law would accept that those copies were never distributed, even thought they did not just happen to spring into existence either. In particular, in the case where Galoob sold patches (Galoob's Game Genie) to Nintendo cartidges, lots (maybe millions) of users were running patched copies of the Nintendo software, that were as such never distributed: the court ruled that Galoob did not infringe Nintendo's copyrights. In this case Galoob must obviously have been using the original Nintendo software in order to create the patches, yet I suppose the patches themselves were free of any Nintendo code. No subtleties about licences here, a simple no copying policy. Nor any question that using the Galoob's Game Genie required purchase of a Nintendo cartidge. ``Having paid Nintendo a fair return, the consumer may experiment with the product and create new variations of play, for personal enjoyment, without creating a derivative work.'' (http://cr.yp.to/softwarelaw.html) On the other hand, if all parts of the final program are being distributed by the same distributor, as would be the case for a QPL library and a GPL application, there is no question of evading copyright issues for part or all of that program: permission for distribution of all copyright owners must be obtained. By setting your subject to New ways to evade copyright law in some other branch, you suggested that I was doing just that; while this has already been refuted by me and others, I'll do so again here. Nobody in this discussion is claiming (as far as I can see) that by some subtle shuffling of pieces you can get a (composite) program from A to B without requiring permissions from all copyright owners. The point is that the complex conditions in the licences, in partcular GPL, may lead to a situation where such permission may be obtained for some particular method of distribution, but not for some other method. For instance, you may distribute in source form (and under GPL) a GPL-ed an application that links to Qt (because then there is no requirement to distribute complete sources), while also distributing Qt (in source and binary) under QPL; the recipient could compile and link an executable program which does not happen to spring into existence, and which was the goal of distributing the GPL sources, yet which could not have been legally distributed directly. I think you put forward yourself another example (a Solaris-linked GPL binary and Solaris itself), where the components might be legally distributed separately (assuming permission from Sun) but not together. So please don't suggest any more that people are trying to evade copyright law when in fact they are trying (maybe by jumping through hoops) to abide by the conditions put forth in the licence(s). Marc van Leeuwen Universite de Poitiers http://wwwmathlabo.univ-poitiers.fr/~maavl/
Re: On interpreting licences (was: KDE not in Debian?)
On Fri, Feb 11, 2000 at 05:26:47PM +0100, Marc van Leeuwen wrote: Nobody in this discussion is claiming (as far as I can see) that by some subtle shuffling of pieces you can get a (composite) program from A to B without requiring permissions from all copyright owners. It seems to me that that's exactly what people are saying when they claim that it's legal to distribute kghostscript. The point is that the complex conditions in the licences, in partcular GPL, may lead to a situation where such permission may be obtained for some particular method of distribution, but not for some other method. For instance, you may distribute in source form (and under GPL) a GPL-ed an application that links to Qt (because then there is no requirement to distribute complete sources), while also distributing Qt (in source and binary) under QPL; the recipient could compile and link an executable program which does not happen to spring into existence, and which was the goal of distributing the GPL sources, yet which could not have been legally distributed directly. Certainly: it's only if you distribute executables or object code that there's any requirement to distribute the complete source for the program. I think you put forward yourself another example (a Solaris-linked GPL binary and Solaris itself), where the components might be legally distributed separately (assuming permission from Sun) but not together. Right: that was an example of a situation which takes advantage of the special exception in section 3 of the GPL. So please don't suggest any more that people are trying to evade copyright law when in fact they are trying (maybe by jumping through hoops) to abide by the conditions put forth in the licence(s). Are you now claiming that it's legal to distribute kghostscript? -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Feb 08, Andreas Pour wrote: Now, please explain how the executable work which I am distributing (kghostview which is dynamically linked to Qt) has in it, holds, encloses or includes, has the capacity for holding, or is equal or equivalent to, the Qt library. Sure, the Qt library can later be added to it -- like sugar to the gallon of water -- but is not contained in it. A dynamically-linked kghostview is completely non-functional without the Qt library. Qt is irrevocably bound up in that executable, whether or not any of Qt's code is actually contained in kghostview. (Besides which, some of Qt's code will be contained in the executable, due to Qt's slot concept which [IIRC] requires preprocessing of the source.) Hypothetical: I build something under a proprietary license, and then use the dl*() calls to access a GPLed library (let's use Readline for example). Even though my software doesn't strictly-speaking contain Readline, it doesn't function without it being present. I'm clearly going beyond mere aggregation or using a fork-exec. That's why when you distribute a dynamically-linked kghostview you don't have to distribute Qt source code. Now of course this executable work no more contains Qt if it is distributed on the same CD. (However, in case it is on the same CD, the special exception would not apply.) Qt is normally distributed in the same kit as KDE in a Linux distribution; whether or not it physically resides on the same disk is irrelevant. You're distributing the one with the other. The only way around this is to require people to pick up Qt from someone else and/or at a different time. If you don't like that result, I suggest you talk to FSF about changing the language of the GPL. The result doesn't follow logically from your premises. Two flaws in this analysis. First, you don't have to distribute a working copy of kghostscript; in fact it would defeat the idea of dynamic linking to do so. Kghostscript will not work w/out libc, libstdc++, libX and a bunch of other libs which generally are distributed separately, unless of course you are the OS vendor. In case you are the OS vendor, of course, you are subject to the exception. Any Linux distributor is, by definition, the OS vendor; this means you can't distribute the infringing component and the GPLed software together. Second, insofar as you do not distribute a working copy, you don't have to distribute the source code to the working copy. The source code, as I quoted above, is only to the executable work you are distributing. That's why if you distribute just, say, The Gimp, you are under no obligation to make the X and libc source code available (in case you want to argue that you are, then I will point out then that virtually *everybody* violates the GPL, w/out protest from the FSF, and that's been going on since the GPL was first released, so its a pretty untenable argument). If you distribute the Gimp in binary form, you are obligated (by the GPL) to provide the source for the Gimp if anyone asks for it. Since X and libc6 are covered by the XFree86 license and LGPL respectively, they do not contaminate the Gimp binary in any meaningful way. However, if someone specifically asks for the source to GNU libc, you have to give it to them (since it's LGPLed). You are under no such obligation with XFree86, though it's probably on the same source CD you're using to fulfill the GPL and LGPL requirement anyway. Now, if you linked the Gimp against Readline (a GPLed library), and distributed that modified Gimp, you would have to provide the source for both the Gimp and Readline. Actually, all it says is that you don't have to distribute the source code. It doesn't say anything about not having to be licensed under the GPL. If in fact Section 2(b) requires you to license the full source code under the GPL, this would apply to the component as well -- the special exception only relieves you of the obligation to distribute the source code, not of any other obligation the GPL has with respect to that component. Section 2(b) requires the combined work to be usable under the terms of the GPL. It does not require the individual components to be licensed under the GPL, but it does require that the aggregation (end product) be subject to the terms of the GPL (and no terms that contradict the GPL). By aggregation, I refer to the common sense definition of aggregation (sticking things together to create a bigger thing; linking, if you will), not the GPL's mere aggregation (which is being distributed on the same media). For example, I have written some software that is licensed under an extremely liberal license (the Python license). I have created a front-end to it that uses Readline (GPLed). Since I have permitted people to modify and/or use the software for any purpose, with or without modification, the front end satisfies the requirements of 2(b), even though the front end ITSELF is
Re: On interpreting licences (was: KDE not in Debian?)
On Wed, Feb 09, 2000 at 08:51:03PM -0600, Chris Lawrence wrote: A dynamically-linked kghostview is completely non-functional without the Qt library. Qt is irrevocably bound up in that executable, whether or not any of Qt's code is actually contained in kghostview. (Besides which, some of Qt's code will be contained in the executable, due to Qt's slot concept which [IIRC] requires preprocessing of the source.) I'll agree with you here. Hypothetical: I build something under a proprietary license, and then use the dl*() calls to access a GPLed library (let's use Readline for example). Even though my software doesn't strictly-speaking contain Readline, it doesn't function without it being present. I'm clearly going beyond mere aggregation or using a fork-exec. I don't agree with you here. The GPL doesn't say that. This is one of those cases where you're deliberately trying to work around the GPL and in this case it is my (non-professional layman's) opinion that you would have succeeded. Of course you do that and we'll have to lynch you or something because we're at times a militant lot and you'd be doing something the GPL's spirit condemns, even if its letter permits.. There is a BSDish readline clode whose interface matches readline's.. If you wrote your dl*() access of libreadline using that non-GPL'd interface definition, you would have succeeded in circumventing the GPL. Now if you pulled something like that with a M$ EULA (much harder to do, they cover all bases better) you'd get sued anyway because M$ would know that you would run out of money first. And even if you didn't, they could argue that you were essentially doing what you were---trying to find a loophole to allow you to do something you are not permitted to do. They would argue your intent makes you guilty of violating the EULA whether you violated its letter or not. They'd have a chance at winning it too, even thouch contract law pretty much says quite the opposite (ie, that if their contract DOESN'T provide for such a case, it's their own fault, etc) The law is not applied universally in this case. A lot of lattitude is granted to computer industry companies to protect their software that doesn't apply to Copyrights on books or anything else for that matter. You or I could not sue someone for violating the spirit of a license and win, but someone like M$ could. (I pick on them because they're an easy target...) It doesn't have to make sense.. I am talking about US law related to computers and technology. The people making the laws are clueless. The people upholding the laws equally so. It is almost always a case of best lawyer wins, regardless of the laws on the books. A sorry state of affairs. I could delve further into your message, but the primary point I need to address is that there are no points for violating the spirit of the GPL here. We're not big software companies so we're not going to have much leeway to claim a violation of the spirit means anything except that the GPL doesn't cover the case in question properly. -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 I am ecstatic that some moron re-invented a 1995 windows fuckup. -- Alan Cox pgpqCnjhKUeKS.pgp Description: PGP signature
Re: On interpreting licences (was: KDE not in Debian?)
On Wed, Feb 09, 2000 at 08:51:03PM -0600, Chris Lawrence wrote: Hypothetical: I build something under a proprietary license, and then use the dl*() calls to access a GPLed library (let's use Readline for example). Even though my software doesn't strictly-speaking contain Readline, it doesn't function without it being present. I'm clearly going beyond mere aggregation or using a fork-exec. Either the program uses readline or it doesn't. If it does use readline, and it's distributed with readline, then, strictly-speaking, it contains readline. On Wed, Feb 09, 2000 at 09:28:29PM -0800, Joseph Carter wrote: I don't agree with you here. The GPL doesn't say that. This is one of those cases where you're deliberately trying to work around the GPL and in this case it is my (non-professional layman's) opinion that you would have succeeded. Of course you do that and we'll have to lynch you or something because we're at times a militant lot and you'd be doing something the GPL's spirit condemns, even if its letter permits.. There is a BSDish readline clode whose interface matches readline's.. If you wrote your dl*() access of libreadline using that non-GPL'd interface definition, you would have succeeded in circumventing the GPL. Here, the biggest issue is: what's being distributed? If the program is being distributed with the BSDish readline, and not the GPLed readline, then there's no issue. But if the program is distributed with the GPLed readline, and not the BSDish readline, then it's pretty obvious that there's an issue. If the program is being distributed with both, then it comes down to which the program is configured to use. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Thu, Feb 10, 2000 at 12:22:47PM -0500, Raul Miller wrote: Hypothetical: I build something under a proprietary license, and then use the dl*() calls to access a GPLed library (let's use Readline for example). Even though my software doesn't strictly-speaking contain Readline, it doesn't function without it being present. I'm clearly going beyond mere aggregation or using a fork-exec. Either the program uses readline or it doesn't. If it does use readline, and it's distributed with readline, then, strictly-speaking, it contains readline. I disagree.. If it was not built using one piece of readline (ie, none of readline's headers) it does not contain readline until it is run. The GPL can't control usage, only distribution. This is different than the KDE and Qt situation in which Qt's headers are included and compiled in the traditional manner. I am of the opinion that static vs dynamic linking is irrelivant because in Qt's case the inclusion of Qt happens before linking. There is a BSDish readline clode whose interface matches readline's.. If you wrote your dl*() access of libreadline using that non-GPL'd interface definition, you would have succeeded in circumventing the GPL. Here, the biggest issue is: what's being distributed? If the program is being distributed with the BSDish readline, and not the GPLed readline, then there's no issue. But if the program is distributed with the GPLed readline, and not the BSDish readline, then it's pretty obvious that there's an issue. If the program is being distributed with both, then it comes down to which the program is configured to use. The hypothetical program above is one which was built using unformation from (but not source code for) a BSDish readline replacement, but would at run time (not link time) find GNU readline and bind do it using the dl* functions. The GPL doesn't even consider such a thing possible. There is almost no difference in what is done here between dlopen() of GNU readline and Corel's package front in forking a dpkg binary controlled through its command line interface---something we have agreed (I hope) is beyond the GPL's scope. The fact that this can be used as a convoluted way to circumvent the GPL's control over readline's linking does not automatically mean that a judge would find this a GPL violation. In fact, I think a judge would determine this to be outside the scope of the GPL since there is no logical way in this example for one to conclude that the program was derived from readline before the user ran it and the program took steps at runtime to bind readline's functions. This is part of the reason it is possible to create a GPL'd netscape plugin, for example. If you do this, netscape does not suddenly become a derived work of that plugin which AOL must suddenly release full GPL'd source code for. The fact that in this example's program the author would have specifically intended for their program to use GNU readline is almost irrelivant because the license just doesn't say anything about it. I could be wrong, but I don't think a Copyright license could---you'd have to go to a shrinkwrap style license. I consider those immoral and possibly illegal if you ever got a judge with a fraction of a clue... -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 2.3.1 has been released. Folks new to this game should remember that 2.3.* releases are development kernels, with no guarantees that they will not cause your system to do horrible things like corrupt its disks, catch fire, or start running Mindcraft benchmarks. -- Slashdot pgpb3nT6UrD9P.pgp Description: PGP signature
Re: On interpreting licences (was: KDE not in Debian?)
On Thu, Feb 10, 2000 at 12:22:47PM -0500, Raul Miller wrote: Hypothetical: I build something under a proprietary license, and then use the dl*() calls to access a GPLed library (let's use Readline for example). Even though my software doesn't strictly-speaking contain Readline, it doesn't function without it being present. I'm clearly going beyond mere aggregation or using a fork-exec. Either the program uses readline or it doesn't. If it does use readline, and it's distributed with readline, then, strictly-speaking, it contains readline. On Thu, Feb 10, 2000 at 09:47:44AM -0800, Joseph Carter wrote: I disagree.. If it was not built using one piece of readline (ie, none of readline's headers) it does not contain readline until it is run. The GPL doesn't say that a program has to be built using headers. Your claim would mean that if, for example, I use a hex editor on a program to alter the libraries it uses, that I would be able to build programs that are built on GPLed code but which aren't bound by the GPL. The GPL can't control usage, only distribution. True. Which is why I pointed out that it matters how the program is being distributed. This is different than the KDE and Qt situation in which Qt's headers are included and compiled in the traditional manner. It's not that headers are a non-issue, but they're not the only issue. I am of the opinion that static vs dynamic linking is irrelivant because in Qt's case the inclusion of Qt happens before linking. I'm of the opinion that it doesn't matter because working copies of the program are being distributed, and those working copies contain both QPL and GPL licensed code. The GPL doesn't care how the program is built -- that's not something that matters to the GPL. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Thu, Feb 10, 2000 at 12:22:47PM -0500, Raul Miller wrote: If the program is being distributed with the BSDish readline, and not the GPLed readline, then there's no issue. But if the program is distributed with the GPLed readline, and not the BSDish readline, then it's pretty obvious that there's an issue. If the program is being distributed with both, then it comes down to which the program is configured to use. What if it's distributed with neither of them, and it just build-depends on the readline API? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: On interpreting licences (was: KDE not in Debian?)
On Thu, Feb 10, 2000 at 12:22:47PM -0500, Raul Miller wrote: If the program is being distributed with the BSDish readline, and not the GPLed readline, then there's no issue. But if the program is distributed with the GPLed readline, and not the BSDish readline, then it's pretty obvious that there's an issue. If the program is being distributed with both, then it comes down to which the program is configured to use. On Thu, Feb 10, 2000 at 08:09:41PM +0200, Antti-Juhani Kaijanaho wrote: What if it's distributed with neither of them, and it just build-depends on the readline API? That sounds like an artificial situation. Who is going to distribute non-working executables? Why? Most likely, this would really represent working copies -- take a look at the working copies to see what's really happening. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Thu, Feb 10, 2000 at 03:13:22PM -0500, Raul Miller wrote: On Thu, Feb 10, 2000 at 08:09:41PM +0200, Antti-Juhani Kaijanaho wrote: What if it's distributed with neither of them, and it just build-depends on the readline API? That sounds like an artificial situation. Who is going to distribute non-working executables? Why? Ah, you were talking about executables, not source. Sorry about that. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: On interpreting licences (was: KDE not in Debian?)
On Thu, Feb 10, 2000 at 10:34:52PM +0200, Antti-Juhani Kaijanaho wrote: Ah, you were talking about executables, not source. Sorry about that. Of course. There's no requirement that you consider the program as a whole if you're not dealing with executables/object code. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
This is an expanded version of my original response to this message. Andreas indicated that he didn't understand why what I was saying was significant. On Mon, Feb 07, 2000 at 07:10:32PM -0500, Andreas Pour wrote: What does it mean for a program to accompany itself? Why do you raise this point? It's not that the program accompanies itself. The paragraph of Section 3 in question deals in terms of components and modules, not entire executables. The GPL uses the term module exactly once, and component and components once each. Here's the paragraph where this happens: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Note that this paragraph follows a couple clauses which require the complete corresponding source code for an executable before you can distribute the executable: Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, ... If you bother to read that, you'll see that (*) The source code must be complete. (*) The source code must correspond to the machine code. (*) Source code must be provided for every piece of the program. (*) There's a special exception for a proprietary libc if that libc accompanies a major component of the operating system which is not distributed with the GPLed program. The requirement that the source code must be complete conflicts with the idea that you can distribute a working copy of kghostscript yet fail to distribute all the source code for a working copy of kghostscript. I suppose that Andreas imagines that kghostscript being split up into multiple files somehow makes a difference. So, when Andreas says: So in the hypothetical case we discuss, libc is a component (although statically linked, the library is a separate binary inside the executable, if I understand the linking process correctly) which accompanies the GPL'd component inside the executable. I must assume that he's misread the GPL, because libc is not a component in the sense that the GPL uses the term. And (looking at the phrase GPL'd component) the way the GPL uses the term, a component wouldn't be licensed under the GPL. In the terms of the GPL, a proprietary libc would be an anything that is normally distributed with a major component of the operating system. There's really no point discussing the logic of this sentence that Andreas wrote -- it just plain doesn't relate to the GPL in any meaningful fashion. If I rewrote it so that we called libc a module which accompanies the GPLed module inside the executable, then the sentence would make sense. But in that case it doesn't make any interesting points... Andreas goes on to say: In any event, as I look up the definition of accompany in Webster's New Universal Unabridged Dictionary (2d ed. 1983), I get: (1) to go with or attend as a companion or associate on a journey, a walk, etc.; as, a man *accompanies* his friend to church, or on a tour. (2) to be with, as connected; to attend; as, pain *accompanies* disease. Syn: attend I have no disagreements with this, and am only quoting it so that Andreas can't claim that I've ignored it. And attend means (taking the only relevant definition): (3) to accompany as a circumstance or result; to be consequent to, from connection of cause, as fever *attends* a cold; a measure *attended* with ill effects. Likewise I have no problem with this as a definition. Looking to the first definition of accompany, I think it fair to say that the libc goes with or attends as a companion the GPL executable as it is distributed. No problem there. But why would this be relevant, and to what? The answer to that question seems to reside in Andreas's confusion about what a major component of the OS is that the GPLed program must
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: [ ... ] On Mon, Feb 07, 2000 at 07:10:32PM -0500, Andreas Pour wrote: What does it mean for a program to accompany itself? Why do you raise this point? It's not that the program accompanies itself. The paragraph of Section 3 in question deals in terms of components and modules, not entire executables. The GPL uses the term module exactly once, and component and components once each. Here's the paragraph where this happens: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Note that this paragraph follows a couple clauses which require the complete corresponding source code for an executable before you can distribute the executable: Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, ... If you bother to read that, you'll see that (*) The source code must be complete. Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. (2) to have the capacity for holding. (3) to be equal or equivalent to; as, a gallon *contains* four quarts; Now, please explain how the executable work which I am distributing (kghostview which is dynamically linked to Qt) has in it, holds, encloses or includes, has the capacity for holding, or is equal or equivalent to, the Qt library. Sure, the Qt library can later be added to it -- like sugar to the gallon of water -- but is not contained in it. That's why when you distribute a dynamically-linked kghostview you don't have to distribute Qt source code. Now of course this executable work no more contains Qt if it is distributed on the same CD. (However, in case it is on the same CD, the special exception would not apply.) If you don't like that result, I suggest you talk to FSF about changing the language of the GPL. (*) The source code must correspond to the machine code. (*) Source code must be provided for every piece of the program. Of course this depends on how you define program. As Section 3 defines it, Program is the GPL'ed work, and work based on the Program would be kghostview (but not Qt, since that is not a work based on ghostview). If this is confusing, bear in mind that the Program refers only to source code -- the ghostview code in the example is source code, and it has been modified by adding some more code, but Qt has not been added to it. For copyright purposes, kghostview source code is not a derived work of Qt, any more than the Yahoo directory is a derived work of the Internet. (*) There's a special exception for a proprietary libc if that libc accompanies a major component of the operating system which is not distributed with the GPLed program. Lbc *is* a major component of the OS. The requirement that the source code must be complete conflicts with the idea that you can distribute a working copy of kghostscript yet fail to distribute all the source code for a working copy of kghostscript. Two flaws in this analysis. First, you don't have to distribute a working copy of kghostscript; in fact
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: If I may pick a nit: For an executable work, complete source code means all the source code for all modules it contains, *plus any associated interface definition files*, plus the scripts used to control compilation and installation of the executable. So a dummy library would indeed fill this requirement. However such a dummy library would be an open admission there's a problem. As such, I suspect we'll never see one. This overglorified legal language pissing contest has gone on long enough. Everybody arguing at this point is pretty much repeating themselves. Right or wrong, the others arguing back are no longer listening if ever they were. And at any rate, it seems this list's audience is much smaller than it was. Due to misconfiguration or whatever else I cannot say--I've had people tell me they're on this list (kde-licensing) and have still not seen this thread appear there. Specifically representatives from Troll Tech are not present to my knowledge. In other words, you're all arguing syntactics and semantics for your own benefits, rather than the benefit of KDE, Debian, Troll Tech, or the Free Software community. Give it a rest people. This issue is not going to be resolved here in this forum. You're all wasting your breath on all sides and only adding fuel to the fires. Keep it up and someone is going to burn down the forest. -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 * Knghtbrd crosses his toes Knghtbrd (if I crossed my fingers it would be hard to type) pgp7jvacOB35k.pgp Description: PGP signature
Re: On interpreting licences (was: KDE not in Debian?)
I share similar views to Mr. Hutton. Allegations have been made that KDE is responsible of GPL abuse and copyright violation. The fact that the GPL is generally misunderstood has served to amplify these allegations. It took me a considerable amount of time to find Andreas Pour's arguments in the sea of confusion that surrounds this issue. Now having found them and being convinced by them that no GPL abuse or copyright violation exists I feel that instead of being silenced he very much deserves to be heard. BFN, Don. On Wed, 09 Feb 2000, Steve Hutton wrote: On Tue, 08 Feb 2000, Joseph Carter wrote: This overglorified legal language pissing contest has gone on long enough. Everybody arguing at this point is pretty much repeating themselves. Right or wrong, the others arguing back are no longer listening if ever they were. And at any rate, it seems this list's audience is much smaller than it was. Due to misconfiguration or whatever else I cannot say--I've had people tell me they're on this list (kde-licensing) and have still not seen this thread appear there. Nobody else is listening, therefore the posters should quit arguing with each other? Interesting hypothesis and conclusion :-) I for one have rather enjoyed Mr. Pour's eloquent and reasoned analysis. The GPL is one of the most vague pieces of text of I've ever read, and the fact that these arguments about what it means go on for so long just underscore the point. I find it particularly amusing when people continually declare the GPL says this or that, and Mr. Pour points out that the license in fact contains no such language. More humorous are the frequent implications that the GPL is some kind of mutable license, subject to grow and change depending upon what its author says he meant when he wrote it. I take that back. It's more sad than funny. Steve
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides Could you please limit your line lengths to around 75 characters? Anything else makes it painful to read and awkward to quote. For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Emphasis yours. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. (2) to have the capacity for holding. What does (2) mean? ``This bucket contains four gallons of water. No, it doesn't have any water in it, but it has the capacity for holding four gallons, so therefore it contains four gallons.'' That doesn't make sense at all in this context as far as I can see. Leaving that aside, though... The intention of the authors (GNU and rms) is fairly clear, and they make their interpretation fairly clear in the LGPL's (written by the same authors) preamble: When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. [...] As such, I'm not really sure how you can say ``But that's not what RMS meant, coz that's not what he wrote, see, this is what the dictionary says and everything!'' and expect to be taken seriously. Hmmm. Actually, that's not entirely the whole story. The LGPL (Library GPL) version 2, dated June 1991 (which is the same as the GPL), had the following text in the preamble: The reason we have a separate public license for some libraries is that they blur the distinction we usually make between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and is analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such. That is, it didn't differentiate between statically linked executables (which clearly makes a combined work under copyright law), and dynamically linked binaries (which is less clear). Now with dynamically liked GPL software we have three cases: (a) A GPLed binary linked against a GPLed library (b) A GPL-incompatible binary linked against a GPLed library. (c) A GPLed binary linked against a GPL-incompatible library (dynamic linking in all cases) We'll note that in no case is the library a derived work (in any sense) based on the binary (it doesn't include any code from the binary, it's perfectly usable without the binary having ever been written, and so on). It's probably arguable whether the binary is a derived work based on the library or not. At best, it may contain portions of the library's interface definitions (header files and what-not), however these are probably not copyrightable [0]. Now, for (a) presumably we don't have any issues at all, and everyone's happy. Of course, it would only apply to KDE if there was a (L)GPLed Qt clone about. Now (b) is clearly not the case for KDE. However it's probably the most questionable one. Clearly, there aren't any issues with distributing the library on its own. As far as distributing the binary is concerned, it seems to me that you'd have to make one of the following arguments to get the GPL to apply: (1) the dynamically linked binary is a derived work (under copyright law) of the library, as well as the binary's source code, because it includes portions of the headers in the resultant binary. (section 0 of the GPL) (2) the dynamically linked binary is a derived work (under copyright law) of the library, because it doesn't work without the library. (3) static linking is obviously bad, and since dynamic linking is just the same as static linking except for a command line option, and some random techincal things, both must be bad. (4) while it's okay to distribute the binary and the library, once you've got them you're not allowed to
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: (*) The source code must be complete. Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. ^^^ What about the Qt header files, which are included at compile time? (2) to have the capacity for holding. (I am not sure if I get all details of the english language correct, but the kde exectuable has the capacity to hold the qt libs). Marcus
Re: On interpreting licences (was: KDE not in Debian?)
Marcus Brinkmann wrote: On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: (*) The source code must be complete. Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. ^^^ What about the Qt header files, which are included at compile time? Right. And those are distributed in source form. I think you are taking this debate a bit out of context. Raul is trying to convince me why a statically linked kghostview is not OK but a statically linked ghostview on Solaris is. What you seem to be addressing here is the question of whether a KDE/Qt binary can satisfy the GPL at all, which was a whole other debate. To bring the point home, it is also true that proprietary libc header files are enclosed in a Solaris ghostview (or pick another GPL'd/proprietary libc program). (2) to have the capacity for holding. (I am not sure if I get all details of the english language correct, but the kde exectuable has the capacity to hold the qt libs). I don't think you got this right -- this doesn't mean the theoretical capacity but the actual. Otherwise you could say the sun contains Andreas since theoretically it can, but that would not generally be considered a correct statement. Ciao, Andreas
Re: On interpreting licences (was: KDE not in Debian?)
Marcus Brinkmann wrote: What about the Qt header files, which are included at compile time? On Wed, Feb 09, 2000 at 09:08:16AM -0500, Andreas Pour wrote: Right. And those are distributed in source form. Not under terms which satisfy the GPL. The GPL requires that there be no proprietary restrictions on the modification and redistribution of the source for any part of the program. The QPL requires that Troll can put whatever proprietary restrictions they like on the distribution of future modified versions of the program. I think you are taking this debate a bit out of context. Then again, the above issue has been pointed out to you many times, yet you choose to ignore that particular issue whenever you feel like it. Raul is trying to convince me why a statically linked kghostview is not OK but a statically linked ghostview on Solaris is. Well, yes, that's one point I'm currently trying to make. But, I'm begining to think that I couldn't convince you that paper can burn, even if I had unlimited time, unlimited dry paper, unlimited dry air and unlimited dry matches. What you seem to be addressing here is the question of whether a KDE/Qt binary can satisfy the GPL at all, which was a whole other debate. And if you light a match and hold it up to a piece of paper, which is sufficiently dry, and hold it there long enough for the paper to catch -- which isn't usually more than a few seconds, though I'm sure you could come up with some papers that wouldn't burn -- it's possible for the paper to catch on fire. To bring the point home, it is also true that proprietary libc header files are enclosed in a Solaris ghostview (or pick another GPL'd/proprietary libc program). (2) to have the capacity for holding. (I am not sure if I get all details of the english language correct, but the kde exectuable has the capacity to hold the qt libs). I don't think you got this right -- this doesn't mean the theoretical capacity but the actual. Otherwise you could say the sun contains Andreas since theoretically it can, but that would not generally be considered a correct statement. See program. See program run. Run program, run. I think that if you examine an operating program -- not any specially modified program, but the sort of program which any random user of kghostscript might have -- and you took a look at what copyrightable works comprised that program -- you'd have a pretty good idea of what went into that program. Of course, some people have raised the objection that the GPL doesn't care how you use the program. Which means that it would be legal to run the program if it was being distributed legally. But the only way to believe that the program was distributed legally is by pretending that a working copy of kghostscript is just some coincidence -- not something that's being distributed. Of course, once you've made that leap of fantasy (that working copies of kghostscript are not being distributed), I suppose that it's pretty easy to deny the meaning of any contradictory legal language. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, Feb 08, 2000 at 09:14:55PM -0500, Andreas Pour wrote: Right, but for the analysis to be complete you must include the definition of what the complete source code is. This is provided in the second sentence of the ultimate para. in Section 3, which provides For an executable work, complete source code means all the source code for all modules it *contains*, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. That's part of the definition -- it's not reasonable to claim that this somehow excludes any other definitional material from the GPL (or, for that matter, any other definitional material from common english usage). The key part being the reference to all modules it *contains*, rather than all modules which may at run-time be linked to it. This is a distinction you've introduced, not something that's ever stated in the GPL. To substantiate the point, I again refer to my Webster's New Universal Unabridged Dictionary (2d ed. 1983) and look-up contain, quoting the relevant definitions: (1) to have in it; hold; enclose or include. 2) to have the (capacity for holding. 3) to be equal or equivalent to; as, a (gallon *contains* four quarts; Now, please explain how the executable work which I am distributing (kghostview which is dynamically linked to Qt) has in it, holds, encloses or includes, has the capacity for holding, or is equal or equivalent to, the Qt library. I don't know which copy of kghostscript you're distributing, but let me ask you this: do you expect that copy to work? Sure, the Qt library can later be added to it -- like sugar to the gallon of water -- but is not contained in it. We're not dealing with laws about the distribution of sugar water. We're dealing with copyright laws in the context of a work which was designed to include material licensed under the GPL as well as under the QPL. And yet you continue to hold that it's just a coincidence that a running copy of kghostscript is going to just happen to include the QPL licensed material. That's why when you distribute a dynamically-linked kghostview you don't have to distribute Qt source code. Now of course this executable work no more contains Qt if it is distributed on the same CD. (However, in case it is on the same CD, the special exception would not apply.) I presume that by contain you're not refering to any sort of physical topology. After all, it's just bits represented on a piece of plastic. There's no inside or outside in the physical sense. You've got a few bits over here which happen to represent (to an informed person) this concept of a filename. Near those bits are a few more bits that happen to indicate some other region of bits which happen to represent the contents of a file. And, on that CD, there are literally thousands of these collections of bits which we think of as files. But, the GPL doesn't make any sort of claim that only a single file is considered to be the program. Whenever it refers to files, it's very clearly refering to multiple files. But somehow you've gotten this idea in your head that the program kghostscript is exactly the same thing as the file which happens to have the name kghostscript. But you've never offered any evidence for that belief. Please present some evidence that that one file represents the whole program. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: Marcus Brinkmann wrote: What about the Qt header files, which are included at compile time? On Wed, Feb 09, 2000 at 09:08:16AM -0500, Andreas Pour wrote: Right. And those are distributed in source form. Not under terms which satisfy the GPL. Says you :-). The GPL requires that there be no proprietary restrictions on the modification and redistribution of the source for any part of the program. The QPL requires that Troll can put whatever proprietary restrictions they like on the distribution of future modified versions of the program. I think you are taking this debate a bit out of context. Then again, the above issue has been pointed out to you many times, yet you choose to ignore that particular issue whenever you feel like it. I don't ignore it, I disagree with it. I have spent lots of e-mails explaining why. Raul is trying to convince me why a statically linked kghostview is not OK but a statically linked ghostview on Solaris is. Well, yes, that's one point I'm currently trying to make. But, I'm begining to think that I couldn't convince you that paper can burn, even if I had unlimited time, unlimited dry paper, unlimited dry air and unlimited dry matches. The feeling is mutual. So let's agree to disagree, OK? And I won't respond to what you wrote below -- you get the last word :-). Ciao, Andreas
Re: On interpreting licences (was: KDE not in Debian?)
On Wed, Feb 09, 2000 at 04:02:29PM -0500, Andreas Pour wrote: Then again, the above issue has been pointed out to you many times, yet you choose to ignore that particular issue whenever you feel like it. I don't ignore it, I disagree with it. I have spent lots of e-mails explaining why. Yet every one of these emails has contained significant errors. You've claimed that these errors are inconsequential, but I've yet to see you post an explanation that didn't contain errors of fact. What I want to know is: if all those errors are so inconsequential, why did you bother writing them in the first place? -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: On Mon, Feb 07, 2000 at 06:14:15PM -0500, Andreas Pour wrote: Where does it say that (in the GPL, that is). It only says you have to make available the complete source code to what you are in fact distributing. I don't think we're disagreeing on this point. However, I think that you are imagining that people are distributing kghostscript executables and not distributing Qt. That's certainly not what Debian would do, if Debian included kghostscript in main. So don't put the binary in main :-); it's not so hard to have users compile the 2-3 apps that fall within the KDE developers borrowed GPL code from another project category. The next sentence reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. No, it would not, b/c then you would actually be distributing the executable proprietary libc, and the next clause kicks in (the exception (unless . . .) to the special exception) to require the source code to be distributed for the libc part as well. Yes, you would be distributing the proprietary libc. But that's legal if (1) the libc would also be distributed with a major component of the operating system, and (2) that major component of the operating system would not accompany the GPLed executable. Right, but if it's statically linked by definition it does accompany the executable. it meaning the GPLed program? Right. If so, why do you use the phrase accompany the executable? Aren't you talking about the executable of the GPLed program? Right. What does it mean for a program to accompany itself? Why do you raise this point? It's not that the program accompanies itself. The paragraph of Section 3 in question deals in terms of components and modules, not entire executables. So in the hypothetical case we discuss, libc is a component (although statically linked, the library is a separate binary inside the executable, if I understand the linking process correctly) which accompanies the GPL'd component inside the executable. In any event, as I look up the definition of accompany in Webster's New Universal Unabridged Dictionary (2d ed. 1983), I get: (1) to go with or attend as a companion or associate on a journey, a walk, etc.; as, a man *accompanies* his friend to church, or on a tour. (2) to be with, as connected; to attend; as, pain *accompanies* disease. Syn: attend And attend means (taking the only relevant definition): (3) to accompany as a circumstance or result; to be consequent to, from connection of cause, as fever *attends* a cold; a measure *attended* with ill effects. Looking to the first definition of accompany, I think it fair to say that the libc goes with or attends as a companion the GPL executable as it is distributed. If you look at Section 3, it refers to For an executable work, complete source code means all the source code for all *modules* it contains, with an exception for anything that is normally distributed . . . with the major *components* . . . of the operating system . . . , unless that *component* itself accompanies the executable. OK, so you need all source code to all modules except for modules normally distributed with the major components of the OS, unless that component accompanies-- goes with -- the executable. In our hypothetical, the module is libc. Hence, you need the source code to libc, except if libc is normally distributed with the OS and it does not accompany -- go with -- the executable. The problem with your reading of accompany is that a lesser cannot accompany a greater. However, this is not the case: I can accompany my family, although I am part of my family, a component of my family. Similarly, when you have a set of components/modules, any one can accompany the others, even if they are all linked together. This is even more the case with GPL, since it is in copyright universe, and certainly if you have a book composed of essays you can say each essay accompanies the book, although each essay forms part of the book it is accompanying. Under your reading, even the OS vendor could get away distributing GPL'd code with a static proprietary libc or other system library, so long as there is no dynamic libc (and perhaps, depending on your reading, no program which is non-GPL'd using
Re: On interpreting licences (was: KDE not in Debian?)
On Mon, Feb 07, 2000 at 07:10:32PM -0500, Andreas Pour wrote: So don't put the binary in main :-); it's not so hard to have users compile the 2-3 apps that fall within the KDE developers borrowed GPL code from another project category. We're not putting it in main. What does it mean for a program to accompany itself? Why do you raise this point? It's not that the program accompanies itself. The paragraph of Section 3 in question deals in terms of components and modules, not entire executables. So in the hypothetical case we discuss, libc is a component (although statically linked, the library is a separate binary inside the executable, if I understand the linking process correctly) which accompanies the GPL'd component inside the executable. Component, in the GPL, refers to major component of the operating system. The word is only used twice, and both occurrences are in the same sentence (this sentence is part of the special exception which lets GPLed code be used on proprietary operating systems). And, the GPL explicitly gives the kernel and the compiler as explicit examples of what it means in that context. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: It's not that the program accompanies itself. The paragraph of Section 3 in question deals in terms of components and modules, not entire executables. So in the hypothetical case we discuss, libc is a component (although statically linked, the library is a separate binary inside the executable, if I understand the linking process correctly) which accompanies the GPL'd component inside the executable. Component, in the GPL, refers to major component of the operating system. The word is only used twice, and both occurrences are in the same sentence (this sentence is part of the special exception which lets GPLed code be used on proprietary operating systems). And, the GPL explicitly gives the kernel and the compiler as explicit examples of what it means in that context. On Tue, Feb 08, 2000 at 04:26:32PM -0500, Andreas Pour wrote: Does non-sequitor mean anything to you? Weren't you the one that said, 'libc is a component'? Or are you trying to suggest that this wasn't in the context of the GPL? Your curt replies to detailed, reasoned arguments just leave me guessing as to what you mean, which is why I will stop wasting my time and this thread. Ciao, Andreas
Re: On interpreting licences (was: KDE not in Debian?)
On Sat, Feb 05, 2000 at 12:04:52AM +0100, Marc van Leeuwen wrote: If you insist... I hope I get the details right though. So the scenario is: kghoststript is being distributed as executable of a GPL-ed source dynamically linked against the Qt object library; the distributors read all the source code for all modules it contains to mean all the source code for kghostscript proper (not the library), and they dutifully accompany the executable by this source, both with the GPL licence; they also distribute Qt as usual in source and object format, both with QPL licence. The sources for kghostscript are the exact ones used to build the executable, so CFLAGS does not contain -static. Except that by your logic, the kghostscript executable won't execute. Who do you think you're fooling? -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Sun, Feb 06, 2000 at 12:39:51AM -0500, Andreas Pour wrote: Making that change under the scenario described by Marc would violate the GPL, but so would lots of other things, such as linking a GPL program with a proprietary libc. Nope, because there's a special exception in the GPL that allows people to use a proprietary libc. This exception is limited (you couldn't by the proprietary libc in conjunction with the GPLed program, nor could they ship together), but it does exist. Just search for special exception in the text of the GPL. I note in this regard that Section 3 of the GPL defines complete source code as: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Notice that it lists only modules it *contains*, not all modules it contains or links to or all modules it contains during execution (the latter being relevant b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? The next sentence reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. Normally you would distribute the major component w/ the executable only if it is statically linked, in which case you are required to include the source of that component; but if dynamically linked, you are not required to distribute the source. Even if it's statically linked you're not required to distribute the source for a proprietary libc. As long as libc is distributed with the kernel or the compiler for the operating system, and as long as the kernel or the compiler is *not* distributed with kghostscript, there's no problem with also distributing some of that proprietary libc with kghostscript. I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. As to your -static flag, I think you agree, from your past postings, that someone can distribute a GPL'd program dynamically linked against a proprietary Solaris libc, but that this person could not compile it statically by adding the '-static' flag and then distribute the program. So really I don't see how your kghostview example is any different from what is already allowed and done. I did not agree to any such thing. It's perfectly legal to distribute a GPLed program which is statically linked against a Solaris libc. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Mon, 7 Feb 2000, Raul Miller wrote: b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? The executing program isn't relevant because the GPL doesn't specify the conditions the program can be run under. It only specifies the conditions the program can be distributed under. I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. I think it does, by implication if not directly. If you link statically with a proprietary library which is not part of the operating system then you cannot distribute under the GPL. But you can if you link dynamically, because you aren't distributing any proprietary code at all. You're just assuming that the required proprietary code will already be on the target system.
Re: On interpreting licences (was: KDE not in Debian?)
On Mon, 7 Feb 2000, Raul Miller wrote: b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? On Mon, Feb 07, 2000 at 12:53:51PM -0500, William T Wilson wrote: The executing program isn't relevant because the GPL doesn't specify the conditions the program can be run under. It only specifies the conditions the program can be distributed under. The GPL is what gives permission to distribute that program. The GPL only gives permssion to distribute the program if you also make available the complete source code for that program (where that source has to be available under terms and conditions that satisfy the GPL). You're claiming that the complete source code doesn't contain a part of the program which is necessary for it to run? I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. I think it does, by implication if not directly. If you link statically with a proprietary library which is not part of the operating system then you cannot distribute under the GPL. But you can if you link dynamically, because you aren't distributing any proprietary code at all. You're just assuming that the required proprietary code will already be on the target system. Ok, so your assertion is that code which is necessary for the program to run -- which is included in the executing program -- is not a part of the program? -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). On Mon, 7 Feb 2000, Raul Miller wrote: You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? On Mon, Feb 07, 2000 at 12:53:51PM -0500, William T Wilson wrote: The executing program isn't relevant because the GPL doesn't specify the conditions the program can be run under. It only specifies the conditions the program can be distributed under. That's fine: as long as you give the complete source code for the executable program you can execute it under whatever conditions you please. But linking with Qt isn't some random example of some unusual circumstances for running the program. Linking with Qt is the only way you can have a complete copy of the program. And you have to distribute the complete source for the program even if you're not distributing all of the object code. And, of course, that source has to be distributed in a way that meets the terms of the GPL. I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. I think it does, by implication if not directly. If you link statically with a proprietary library which is not part of the operating system then you cannot distribute under the GPL. Linking statically with a proprietary library is perfectly legal if (1) the library is distributed with the OS, and (2) the GPLed program is not. Linking dynamically doesn't give any additional permissions. But you can if you link dynamically, because you aren't distributing any proprietary code at all. You're just assuming that the required proprietary code will already be on the target system. Distribute with/without code only matters for that special exception that lets people link (statically or dynamically) with a proprietary libc. And even there you've not understood the requirement. Except for that special exception, you have to distribute the complete source for the program under the GPL even if you're only distributing part of the object code yourself. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
William T Wilson wrote: On Mon, 7 Feb 2000, Raul Miller wrote: b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? The executing program isn't relevant because the GPL doesn't specify the conditions the program can be run under. It only specifies the conditions the program can be distributed under. The program as _distributed_ contains portions of Qt, even if dynamically linked. Macros. Data structures. Method definitions. All are parts of Qt necessary for compilation, and which are included in the final executable. I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. I think it does, by implication if not directly. If you link statically with a proprietary library which is not part of the operating system then you cannot distribute under the GPL. But you can if you link dynamically, because you aren't distributing any proprietary code at all. You're just assuming that the required proprietary code will already be on the target system. Dynamic linking has been the exception rather than the rule for most of the history of computing. Most libc's, even proprietary, allow distribution of static binaries. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -- d2deek at pmail.net | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.dhis.net is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.net/~deek/
Re: On interpreting licences (was: KDE not in Debian?)
You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? On Mon, Feb 07, 2000 at 05:17:56PM -0500, Andreas Pour wrote: Well, this is funny indeed. When it suits your desired interpretation, you can change words rather freely; yet at other times you insist on strict reading of the words. Although it is obvious, I will repeat myself: I said executable work, as used in the GPL, not executing program. The reference to executable work in Section 3, which I quoted above, must be the Program . . . in . . . executable form mentioned in the beginning of Section 3 (why? b/c the quoted sentence is defining the term). In short, the term refers only to what is being copied and distributed, rather than what the user ends up executing. If you read Section 3 with a fair eye I think you will see what I mean. It's true that you do not have to distribute in object form everything that's going to go into the complete program. However, it's also true that you must distribute the source for the complete program. I'm asserting that kghostscript without Qt is not the complete program. You do not appear to be disagreeing with me on that point. Instead, you appear to be quibbling that the GPL doesn't require that the entire executable be distributed. The next sentence reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. No, it would not, b/c then you would actually be distributing the executable proprietary libc, and the next clause kicks in (the exception (unless . . .) to the special exception) to require the source code to be distributed for the libc part as well. Yes, you would be distributing the proprietary libc. But that's legal if (1) the libc would also be distributed with a major component of the operating system, and (2) that major component of the operating system would not accompany the GPLed executable. There's nothing in that exception which says that libc can't accompany the GPLed executable. The requirement is that the GPLed executable can't be accompanied by the major component of the operating system which includes the cannonical copy of libc. Stated even more informally, that exception says: you can use a proprietary libc if everyone already has it, but then the the OS vendor (who stuck everyone with this proprietary libc) can't distribute the GPLed program. The underlying idea is that the OS vendor ought to have the capability to fix the license on the proprietary libc, but users of that OS wouldn't be able to fix the license. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? On Mon, Feb 07, 2000 at 05:17:56PM -0500, Andreas Pour wrote: Well, this is funny indeed. When it suits your desired interpretation, you can change words rather freely; yet at other times you insist on strict reading of the words. Although it is obvious, I will repeat myself: I said executable work, as used in the GPL, not executing program. The reference to executable work in Section 3, which I quoted above, must be the Program . . . in . . . executable form mentioned in the beginning of Section 3 (why? b/c the quoted sentence is defining the term). In short, the term refers only to what is being copied and distributed, rather than what the user ends up executing. If you read Section 3 with a fair eye I think you will see what I mean. It's true that you do not have to distribute in object form everything that's going to go into the complete program. However, it's also true that you must distribute the source for the complete program. Where does it say that (in the GPL, that is). It only says you have to make available the complete source code to what you are in fact distributing. I'm asserting that kghostscript without Qt is not the complete program. You do not appear to be disagreeing with me on that point. Instead, you appear to be quibbling that the GPL doesn't require that the entire executable be distributed. That for sure it does not -- the only complete requirement pertains to source code. The next sentence reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. No, it would not, b/c then you would actually be distributing the executable proprietary libc, and the next clause kicks in (the exception (unless . . .) to the special exception) to require the source code to be distributed for the libc part as well. Yes, you would be distributing the proprietary libc. But that's legal if (1) the libc would also be distributed with a major component of the operating system, and (2) that major component of the operating system would not accompany the GPLed executable. Right, but if it's statically linked by definition it does accompany the executable. There's nothing in that exception which says that libc can't accompany the GPLed executable. Of course it can, but then you have to include the source code. The requirement is that the GPLed executable can't be accompanied by the major component of the operating system which includes the cannonical copy of libc. Stated even more informally, that exception says: you can use a proprietary libc if everyone already has it, but then the the OS vendor (who stuck everyone with this proprietary libc) can't distribute the GPLed program. I don't see any reference to OS vendor, whether explicit or implicit, in the language of Section 3 of the GPL. The only distinction on the system component exception is whether the system component accompanies the executable or not: if not, you are excused from including the source code for that component, if it does, you are not excused The underlying idea is that the OS vendor ought to have the capability to fix the license on the proprietary libc, but users of that OS wouldn't be able to fix the license. While I may agree that this is a nice theory, it is not reflected in the language of the GPL. This only goes to prove how poorly the GPL is drafted, as we can disagree even on this relatively elementary point. Ciao, Andreas
Re: On interpreting licences (was: KDE not in Debian?)
On Mon, Feb 07, 2000 at 06:14:15PM -0500, Andreas Pour wrote: Where does it say that (in the GPL, that is). It only says you have to make available the complete source code to what you are in fact distributing. I don't think we're disagreeing on this point. However, I think that you are imagining that people are distributing kghostscript executables and not distributing Qt. That's certainly not what Debian would do, if Debian included kghostscript in main. The next sentence reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. No, it would not, b/c then you would actually be distributing the executable proprietary libc, and the next clause kicks in (the exception (unless . . .) to the special exception) to require the source code to be distributed for the libc part as well. Yes, you would be distributing the proprietary libc. But that's legal if (1) the libc would also be distributed with a major component of the operating system, and (2) that major component of the operating system would not accompany the GPLed executable. Right, but if it's statically linked by definition it does accompany the executable. it meaning the GPLed program? If so, why do you use the phrase accompany the executable? Aren't you talking about the executable of the GPLed program? What does it mean for a program to accompany itself? Why do you raise this point? If it doesn't mean the GPLed program, what is it that you say would be statically linked? There's nothing in that exception which says that libc can't accompany the GPLed executable. Of course it can, but then you have to include the source code. Sure -- you not only have to include the source code, but you have to make sure it's distributed under GPL terms... but then we wouldn't be talking about that proprietary libc. The requirement is that the GPLed executable can't be accompanied by the major component of the operating system which includes the cannonical copy of libc. Stated even more informally, that exception says: you can use a proprietary libc if everyone already has it, but then the the OS vendor (who stuck everyone with this proprietary libc) can't distribute the GPLed program. I don't see any reference to OS vendor, whether explicit or implicit, in the language of Section 3 of the GPL. The only distinction on the system component exception is whether the system component accompanies the executable or not: if not, you are excused from including the source code for that component, if it does, you are not excused It seems to me that you'd call someone distributing major components of a proprietary OS an OS vendor. I'm sure you could construct examples which are exceptions to that rule. But I made it very clear that I was talking informally -- I was talking about the usual case, not trying to be so general that I was covering all potential issues. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: On Fri, Feb 04, 2000 at 11:31:48AM +0100, Marc van Leeuwen wrote: That point is: why does GPL section 3 not say something like the following? For object code or other kinds of executable work, complete source code means the full source text for all executable code that will be executed as a direct consequence of executing the work, and whose presence on the same computer as the work is a prerequisite for proper execution of the work; in addition it includes any associated interface definition files, plus the scripts used to control compilation and installation of the executable. That wouldn't work -- you've just defined the executable code as the source code. Meanwhile, I've not gotten any real feedback on whether adding -static to CFLAGS is legal, let alone any of the more complicated changes I proposed... Making that change under the scenario described by Marc would violate the GPL, but so would lots of other things, such as linking a GPL program with a proprietary libc. In the latter case, it does not even require chaning any Makefile, simply the fact of having a different libc on the compiling system will result in the violation (of course only to the extent a static binary is distributed). I note in this regard that Section 3 of the GPL defines complete source code as: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Notice that it lists only modules it *contains*, not all modules it contains or links to or all modules it contains during execution (the latter being relevant b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). The next sentence reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. This sentence can easily be read to support the dynamic/static distinction. Normally you would distribute the major component w/ the executable only if it is statically linked, in which case you are required to include the source of that component; but if dynamically linked, you are not required to distribute the source. I.e., the GPL does distinguish b/w dynamic and static linking. As to your -static flag, I think you agree, from your past postings, that someone can distribute a GPL'd program dynamically linked against a proprietary Solaris libc, but that this person could not compile it statically by adding the '-static' flag and then distribute the program. So really I don't see how your kghostview example is any different from what is already allowed and done. Ciao, Andreas
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: Meanwhile, I've not gotten any real feedback on whether adding -static to CFLAGS is legal, let alone any of the more complicated changes I proposed... If you insist... I hope I get the details right though. So the scenario is: kghoststript is being distributed as executable of a GPL-ed source dynamically linked against the Qt object library; the distributors read all the source code for all modules it contains to mean all the source code for kghostscript proper (not the library), and they dutifully accompany the executable by this source, both with the GPL licence; they also distribute Qt as usual in source and object format, both with QPL licence. The sources for kghostscript are the exact ones used to build the executable, so CFLAGS does not contain -static. Now somebody receives this distribution and for some reason adds -static to the CFLAGS, as properly is his right, and rebuilds. He finds himself with a substantially bigger object file than in the distribution, but otherwise no dramatic changes occur. The change is highly unlikely to flow back to the first distributor, but even if by some accident their source distribution would have its CFLAGS altered, it would just mean that these sources no longer correspond exactly to the distributed binaries. No illegality yet. Now the recipient makes a more substantial improvement to the kghostscript sources and decides to share it with the world; he puts his modified sources on his ftp server (GPL-ed, as always). Now anybody downloading these improved sources will have their executables built too large by default, if they don't find out and remove the -static; that's a pity but no disaster. Next thing, our hacker becomes so popular that demand arises for distribution of binaries. At this point he may have forgotten that his binaries, unlike the original ones, contain parts of the Qt library and simply put them up for distribution, with the GPL licence, just like his sources. This is illegal, and he could be sued. Whether he can be sued by Troll is not entirely clear to me: while the binary is certainly derived work from Qt in the copyright sense, it does not seem to classify as modified version of Qt in the sense of QPL (which systematically distinguishes modified versions and third-party application programs based on Qt) so QPL4a (requiring a QPL notice) and QPL4c (requiring modifications (all of kghostscript?) to enjoy the permissions of QPL) probably do not apply; in any case QPL6 is not violated because it merely requires sufficiently free sources, not the precise permissions of QPL. But our forgetful hacker can certainly be sued by the author of kghostscript, since he cannot guarantee the GPL permissions with respect to the Qt sources (which he does not distribute, but which are definitely nowhere distributed other than with QPL); in particular recipients of his binaries have no right to modify and redistribute the Qt sources (QPL3, like QPL5, is giving no permissions for things that require permission). It is not quite clear what suing would achieve though (certainly not release of Qt under GPL); more likely the kghostscript author, if at all bothered about the situation, would urge for reversion to distribution of dynamically linked executables. On the other hand our hacker may think wait, I'm becoming a serious distributor, let's check the licences. He reads GPL carefully, understands that he must release all sources under the terms of the GPL, checks that his binaries include the Qt library, fetches its sources, reads the QPL and understands by QPL2 that he must leave the QPL notice in. If he understands the situation well he may give up here and decide that he cannot satisfy GPL this way, and refrain from distribution, or revert to distributing dynamic execs. Or he may naively plant the GPL flag next to the QPL licence, and leave it to his recipients to figure out what their rights are. This is pretty bad. ...? I'm sorry, maybe it's because I'm not much of a story teller, but I still can't figure out how to get to the part where the Evil Troll emerges from the shadows, and wields the powers bestowed on it by QPL3b to mercilessly rip an originally GPL-ed piece of kghostscript (or Gimp) out of this software for abuse in its own proprietary software, while enjoying immunity from being sued by the respective authors for copyright infringement. Maybe somebody else can continue? Marc van Leeuwen
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, 1 Feb 2000 I wrote: So in this case distribution of non-GPL-ed source code must still be subject to [GPL section 2], if that source is part of the complete sources of the binary distributed, and the exception for OS components does not apply. I suppose that a program dynamically linked against a library does not contain any of the code of that library, so does the source for that library count as part of the complete source for the dynamically linked executable? GPL says For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Possibly the letter allows exclusion of the sources for the library in this case, because the binary does not contain any modules of the library, and even the interface definition files for the library may be considered to not be associated to the modules that are included in the binary (even if they are used by those modules). However, such reading does seem to violate the spirit of the GPL, since (1) the term complete sources itself does not suggest this reading, (2) it rests on a somewhat technical distinction between dynamically linked and statically linked executables, (3) what would the purpose of requiring inclusion of scripts be, other than to allow using them to recreate a modified binary after changing the sources, requiring at least access to the interface definition files of the library, and (4) such reading makes the exception for OS components mostly unnecessary (do executables usually contain modules that also classify as anything that is normally distributed... with the major components... of the operating system on which the executable runs?). As for reason (2), how would the intent of the GPL, which is clearly to ensure that anybody using GPL-derived programs is able and free to improve the sources and redistribute, be served by allowing dynamically linked binaries where it forbids statically linked ones? Yet, why has nobody recently put forward this way of resolving the KDE/Qt issue? I've seen drastic bending of the meaning of much more unambiguous parts of the GPL. Maybe this was discussed and resolved long ago, or maybe I'm just too blind too see the obvious? Anybody please explain. To which David Johnson replied: I have put this opinion forth (that Qt is distinct from the application and not a module) in the past, but [...] I have become gun shy and have refrained from stating what I see as obvious. Then Raul Miller responded: [...] So copyright law grants some fairly broad protections. Without broad protections, you could never prove copyright violation. [Which, some people might argue, is a good reason for getting rid of copyright laws -- but that's a whole different discussion.] And, at least in the U.S., you don't actually have to make the illegal copies to be guilty of copyright violation: you just have to make it easy for the illegal copies to be made. So treating unlinked code as independent works doesn't cut it, not when the usual practice is to use these independent pieces together on the target machine. I would like to note that the discussion has by now made a strange turn. I was discussing the interpretation of complete sources in GPL section 3. Everybody agrees that one has to meet the conditions of GPL in order to distribute an executable built from GPL-ed sources; the ordinaray protections of copyright law will guarantee that. So section 3 could require whatever it likes, and define complete sources in any way it finds suitable. My only observation was that the language it uses taken literally does not seem to include sources for the library in the case of distribution of dynamically linked executables. Now I know this is not what the FSF wants it to mean; I already noted the interpretation seems to run contrary to the spirit of the GPL, and on http://www.fsf.org/philosophy/license-list.html, the FSF says: Since the QPL is incompatible with the GNU GPL, you cannot take a GPL-covered program and Qt and link them together, no matter how. That is an overstatement since the GPL itself admits: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. But again that is besides the current point. That point is: why does GPL section 3 not say something like the following? For object code or other kinds of executable work, complete source code means the full source text for all executable code that will be executed as a direct consequence of executing the work, and whose presence on the same computer as the work is a prerequisite for proper execution of the work; in addition it includes any associated interface definition files, plus the scripts used to control compilation and installation of the executable. That would
Re: On interpreting licences (was: KDE not in Debian?)
On Fri, Feb 04, 2000 at 11:31:48AM +0100, Marc van Leeuwen wrote: That point is: why does GPL section 3 not say something like the following? For object code or other kinds of executable work, complete source code means the full source text for all executable code that will be executed as a direct consequence of executing the work, and whose presence on the same computer as the work is a prerequisite for proper execution of the work; in addition it includes any associated interface definition files, plus the scripts used to control compilation and installation of the executable. That wouldn't work -- you've just defined the executable code as the source code. Meanwhile, I've not gotten any real feedback on whether adding -static to CFLAGS is legal, let alone any of the more complicated changes I proposed... -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Wed, 2 Feb 2000, Marc van Leeuwen wrote: Scripsit Lynn Winebarger [EMAIL PROTECTED] There's a difference. You'd have to do some work to show me that in all cases a function call is equivalent to a footnote - footnotes you don't need to see to understand the text, a non-standard API I need to know at least the documentation for the library implementation (which probably describes, but not defines, the API). Uh? Where does copyright law talk about meaning and understanding? If I write a book about (say) The Rolling Stones or Microsoft Windows one can't really understand the text without accessing (or having had access to) their music respectively software, but that does not give them any copyrights to my book! Well, let's look at the case of fiction. If you use a character from a copyrighted text, your work may be derivative of that. Why? Because you're relying on the work of the author of the first text to provide the meaning/context for this character in your book. You're not just using the name as a reference. The question is not whether copyright law explicitly says such and such will constitute being derivative, the question is what will a judge/jury decide after seeing the two texts. Yes, I know software isn't fiction. But fiction does set the stage for an argument based on meaning and context. In nonfiction, generally a reference is given not to provide meaning to a statement, but to provide extra detail concerning a statement. With software, the reference is the statement, and is meaningless without knowing the function's code or documentation. And no, I don't think you need access to the Rolling Stones music or MS Windows in order to read and understand a book about them (this may depend on the quality of the text). So portable code is unaffected by any implementation's copyrights but non-portable code is affected? This would be quite interesting (and absurd). Depends on what you mean by portable and non-portable. Using readline, for example, doesn't make your code non-portable, though it does make it derivative of the readline library. While it may be absurd from a technical viewpoint, I don't believe it is so if you're looking at the code solely as a form of expression (as the copyright has 0 to do with any functionality it may have). There may, of course, be restrictions on how an OS vendor may apply any copyright interest they may have in application from antitrust law. An example that you might be more familiar with is the WWW. Think of what it would mean if linking to a webpage would give the (intellectual) owner of that page copyrights over that page containing the link. And of course by extension to any page linking to that page, etc. Well I'm pretty sure it would mean I have copyrights over the entire WWW (and so would you). Yet it remains even more true than for function calls that one cannot determine the meaning of a weblink without following it. Nonsense. A link is simply a reference - there is no need to look at it for the referring page to be completely meaningful. Lynn
On interpreting licences (was: KDE not in Debian?)
This is partly in reply to messages of Andreas Pour [EMAIL PROTECTED] on Fri, 28 Jan and of Jeff Licquia [EMAIL PROTECTED] on Sun, 30 Jan. But mainly it is about interpreting licences in general and in particular the GPL. This is not an easy matter, and if differences of opinion arise this is most likely a consequence of that difficulty, rather than of the other partly being a moron or simply unwilling to understand the obvious, so I will avoid to make such implications. I would also like to note that it is not my intention to attack or defend KDE or Debian or whoever, just to sort things out for myself. One may note that at some points I express ideas that contradict what I have said before; don't hold this against me, it just indicates that the enormous load of words poured out over me this weekend wore not entirely wasted. My concern is to try to find a way I can read licences that allows me to answer questions about issues concerning them in a somewhat systematic way. The first point is the status of licences. As I have said: A licence is just a statement from the copyright holder conditionally lifting the default prohibition of copying of copyrighted material. That's simple enough. But let me make some definitions to simplify the discussion. I'll call a copyright holder the author, the copyrighted material his work, somebody who wishes to copy and distribute that work the distributor, and the person who is to receive such a copy the user. I'll assume the author wishes to allow the distributor to do so under certain circumstances, to which end he gives a licence that gives permission to make and distribute copies under certain conditions. Note that in principle the user is no party in the licence. What complicates matters, at least in case of the GPL, is that the conditions themselves mention the users, and in part are concerned with allowing them to become distributors. This also makes terms like restrictive ambiguous; for instance in order to guarantee certain freedoms for users (and possibly future distributors), the GPL has to be restrictive with respect to (current) distributors. I'll try to avoid complications by talking only of obligations of distributors, directly prescribed by the conditions of the licence. For the sake of simplicity let us assume this permission is not given exclusively to a specific distributor, but to the public in general (all licences considered here use generic language like Redistribution and use... are permitted... or You may copy and distribute... without mention of specific names). One may infer that the author wishes to grant the same permission to whoever possesses a legally obtained copy of the work: for copyright law all different copies of the work are embodiments of just a single item of intellectual property owned by the author, and although the copyright pertains to the right to multiply those physical copies, it does not really matter which instantiation serves in the duplication process. The identity of the distributor is important only to the extent that it is the person responsible for the conditions being met. [Consequently, I don't agree with the idea of a licence being an attribute of some copy of the work.] Firstly, from this it follows that _only_ the author has the right to define the terms of the licence. Nobody can arbitrarily modify the licence by adding or removing conditions; in this sense relicensing is not possible. Secondly it follows that anybody having a legally obtained copy of the work receives the same conditional permissions formulated in the licence, without the need of an explicit act to that effect; in a sense these permissions were already given before he received that copy. The fact that many licences state that the licence has to be preserved when making the copy is therefore logical, in order that the recipient know his rights, but it is not an act of _giving_ those rights to the recipient (like it is not the copyright notice itself which makes the work copyrighted). On the other hand it does not follow that the distributor is bound only by the conditions of the licence; there may be other conditions, legal or otherwise, that he has to satisfy and that can affect his possibility to distribute. A more difficult situation arises when works with different authors are combined into a single work. It is a situation not really treated in much detail in copyright law (certainly not with the complications particularly relevant for computer software in mind), but it is clear that every original author still has some copyright in the combined work. A case explicitly addressed by law is that of a compilation of works (not in the computer sense), where each author contributes some clearly identifiable portion and the editor only holds copyright on the way these are combined; in software however things may not be as easy to separate (like when someone rewrites pieces of existing code, or in case of an executable built from
Re: On interpreting licences (was: KDE not in Debian?)
Marc van Leeuwen wrote: Yet, why has nobody recently put forward this way of resolving the KDE/Qt issue? I've seen drastic bending of the meaning of much more unambiguous parts of the GPL. Maybe this was discussed and resolved long ago, or maybe I'm just too blind too see the obvious? Anybody please explain. I have put this opinion forth (that Qt is distinct from the application and not a module) in the past, but each and every time I have met with immense disagreement and vile language, so that I have become gun shy and have refrained from stating what I see as obvious. David Johnson
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: On Tue, Feb 01, 2000 at 10:48:20AM -0800, David Johnson wrote: I have put this opinion forth (that Qt is distinct from the application and not a module) in the past, but each and every time I have met with immense disagreement and vile language, so that I have become gun shy and have refrained from stating what I see as obvious. Please don't confuse the immense disagreement with any vile language. I haven't. I have received both. So treating unlinked code as independent works doesn't cut it, not when the usual practice is to use these independent pieces together on the target machine. Copyright law doesn't grant any special excemption for dynamic linking. Oh, but it does! I'm sorry that I can't quote the relevant law to you, not being a lawyer or anything. But there have been court cases in the past that have determined that APIs cannot be copyrighted. A footnote containing a chapter or page reference is the prose equivalence to an API. For a program, a reference to call a function elsewhere is analogous to a footnote and the #include qapplication.h statement is analogous to any entry in a bibliography. The GPLd portions of the KDE source code, as long as it remains source code, contains zero elements of Qt. After it is compiled into a binary, there is only a miniscule amount of Qt code, and what there is consists of the translated/compiled API. Anything within KDE that belongs to Qt is easily covered under copyright law as a reference or fair use. Now a license may impose further restrictions to the user beyond what copyright disallows. But I don't see the GPL doing this. It only refers to all the source code for all modules it contains plus scripts and makefiles and such. I don't see Qt as being contained within KDE (except for the API) as it is external to it. Of course, RMS (politely) disagrees with me on this, but as it is written, it is not clear at all that Qt is a module of KDE as defined in GPL version 2. [Also, there's the Objective C situation (where gcc mods were distributed as .o files and the end user was given instructions on how to build the modified gcc)... Statically linking NeXT's object files into gcc in the user's private environment is a far cry from dynamic linkage, and has little bearing upon KDE/Qt. David Johnson
Re: On interpreting licences (was: KDE not in Debian?)
On Tue, 1 Feb 2000, David Johnson wrote: Oh, but it does! I'm sorry that I can't quote the relevant law to you, not being a lawyer or anything. But there have been court cases in the past that have determined that APIs cannot be copyrighted. A footnote containing a chapter or page reference is the prose equivalence to an API. For a program, a reference to call a function elsewhere is analogous to a footnote and the #include qapplication.h statement is analogous to any entry in a bibliography. If you want someone to believe you when you say an API cannot be copyrighted, you should include a legal reference to support your claim. Secondly, the claim is not that the API is copyrighted, it's that the code calling it is derivative of the implementation of the API. There's a difference. You'd have to do some work to show me that in all cases a function call is equivalent to a footnote - footnotes you don't need to see to understand the text, a non-standard API I need to know at least the documentation for the library implementation (which probably describes, but not defines, the API). In the case of a standard, the function call gets its meaning from the standard's definition rather than that of any particular implementation, so the calling code's meaning is independent of that library implementation. Lynn
