Re: KDE not in Debian?
Joseph Carter [EMAIL PROTECTED] writes: On Wed, Jan 26, 2000 at 04:22:27PM -0500, Thomas Bushnell, BSG wrote: In these cases where there are grey areas, I wouldn't really trust our opinions to be all that valid. Just as we might not trust a lawyer's advice on how to implement a technical issue, maybe we should consider having a lawyer looking at something that falls under their area of expertise before we go off half-cocked. =20 Quite right. I believe this step has already been taken. You wish. =3D RMS has commented on the opinions of the FSF lawyer(s), but that's the extent anyone has really looked into the matter other than individual dists asking their lawyers will distributing this get us sued? So David Walton said someone should ask a lawyer. I said I believe someone *has* asked a lawyer. And you first: say you wish as if nobody had asked a lawyer, and then second: describe what two different groups of lawyers said in response to some questions on the subject. As I said, someone has. And the answer is: 1) Illegal 2) The KDE people probably won't sue. Mind you, if they had taken *my* GPL'd code and were linking it with QPL'd code, I very well might consider a lawsuit. Thomas
Re: KDE not in Debian?
Marc van Leeuwen [EMAIL PROTECTED] writes: By the way, I assume that Microsoft does not forbid distribution of binaries for programs that run under MS Windows (that would certainly decrease the popularity of their platform). Is this because they explicitly gave permission, or simply because their permission is not required? I honestly don't know, but I would bet it is the second possibilty. Does anybody have more definite information on such issues? As a general rule, the people who make those runtime libraries give away certain rights in the license. You usually get it with the compiler. Typically, when you by some proprietary compiler+libraries, you will find an explicit license where they have agreed to let you distribute linked programs using their library; typically you might be able to distribute linked binaries without limitation as long as it's non-profit. If you are making a profit, then sometimes the library author wants a cut too, though different compiler-package-vendors differ. Thomas
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: KDE not in Debian?
On Wed, Feb 02, 2000 at 01:46:45AM -0500, Andreas Pour wrote: (a) copyright law prevents copying of protected works without permission from the copyright holder; (b) that permission to copy can be given in a document, whether it is called a license or a permission notice or whatever, so long as in substance it permits copying; (c) if someone grants such permission, you can only copy in compliance with the grant of permission; (d) XFree grants permission to copy the code subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. (e) The reference to this permission notice in the above quote is to the license, called a permission notice in the XFree source code files, which permits copying XFree in the first place. (f) By requiring you to include the license in the XFree code you distribute, that means that license applies to the XFree code (but not any additional code) which you distribute. (g) XFree code, or substantial portions thereof, can only be redistributed under the XFree license. (h) If someone adds code to XFree, they are free to license it under whatever terms they choose, including a proprietary license, since XFree does not have any requirements for code added to XFree by a third party. (i) Point (h) above does not, however, change the license of the XFree code, it only changes the permissions on the combined code. All correct, with the nitpicky point of s/XFree/XFree86/. But how you get from here to the XFree86 [MIT] license is incompatible with the GPL is quite beyond me. Kindly explain in words of one syllable, and please make an effort to keep your reply under 100 lines. And, if it wouldn't be too much trouble, please get your line lengths under control. -- G. Branden Robinson| To stay young requires unceasing Debian GNU/Linux | cultivation of the ability to unlearn [EMAIL PROTECTED] | old falsehoods. roger.ecn.purdue.edu/~branden/ | -- Robert Heinlein pgpyXqAu4o13o.pgp Description: PGP signature
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: New ways to evade copyright law (was Re: Vicarious liblity (was: KDE not in Debian?))
Raul Miller wrote: On Fri, Feb 04, 2000 at 01:30:50PM -0500, Brian Ristuccia wrote: Distributing two separate works for which you have authorization, on the other hand, is perfectly ok even if you don't have permission to distribute the combination of the two. Any combination of those works would be done by the end user. Only if the end user chooses to distribute the result would they (not you) be in violation of the copyright. But the only reason you have permission to distribute a GPLed executable is if you're distributing the source under appropriate terms (terms that let you modify and redistribute that source code with no restrictions beyond those imposed by the GPL). And that includes the source for any needed modules. ^^ No, as I recently observed in another post, that is not what the GPL says. It says: all the source code for all modules [the executabe work being distributed] contains. To contain is something different from to need. While statically and dynamically linked executables eventually will need the same set of modules, they don't contain the same set. I agree that what the GPL seems to want to say is the modules needed, and that the FSF gives it this interpretation, but in fact the GPL doesn't say it. Now I am not advocating to use this weakness of the GPL to ignore the problem that QPL does not permit what GPL requires; however other distributors will (and do) do just that, and if any GPL author would ever try to press charges against them, those distributors will have no difficulty pointing out this subtlety in court. (Alternatively they could argue that Qt is normally distributed with the kernel of the operating system, and not with the GPL-ed appliction, which could well be true in their case.) What I do not understand is that when I make an attempt to suggest a stronger definition, specifically 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; you just dismiss that by saying I've just defined the executable code as the source code. (Where did I define executable code? I'll gladly admit my formulation is not perfect and maybe I've goofed up completely by overlooking something, but I did try to define complete source code as all sources needed for a working program.) So what is your position? On the one hand your analysis of the situation hinges on an interpretation of one clause of the GPL, but you object to changing that clause to more unambiguously support that interpretation. This leaves me a bit puzzled. 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
Vicarious liblity (was: KDE not in Debian?)
Raul Miller [EMAIL PROTECTED] wrote: On Thu, Feb 03, 2000 at 12:38:51PM +0100, Marc van Leeuwen wrote: I maintain that unless the distribution of dynamically linked binaries itself is considered a copyright infringement, there's no vicarious liability either. And to come back to the static/dynamic distinction: an obvious and relevant difference with distribution of statically linked binaries is that the user can execute those without also having the library object file. Ok, let's pretend for a minute that distributing kghostscript is legal. What does that mean? Well, for one thing, it should be legal to make trivial changes to the source and redistribute. For example, adding -static to the CFLAGS in the makefile and redistributing should be perfectly legal. You've granted this right under the GPL. I'll stop the example here because I think we are talking at cross purposes. I do not want to discuss whether or not QPL'ed code enjoys the permissions that the GPL demands for complete sources. Even less do I maintain that one could distribute Qt with a GPL licence or kghostscript with a QPL licence. And interpreting the example would at the very least require an interpretation of complete source as defined in GPL section 3 with respect to dynamically linked executables; I've just discussed that in another message. The discussion in this branch of the thread (can one say that?) had, as far as I could see, taken a different angle, namely whether statically and dynamically linked binaries are different from the point of view of copyright law, and if vicarious liability play a role there. Your example is too full of distracting details (and unclear on some relevant ones) to single out those questions very well. I'll just make this one comment. If your point is that a distribution that in itself is not infringing on anybody's copyright, could be considered vicariously liable of such infringement because, after tweaking the makefile a bit, and then using it to create an executable that is essentially different from anything present in the original distribution, recipients could infringe copyright by distributing that executable, then I must say this interpretation of vicarious liability seems unacceptable to me. By the same token distributing source code of a very plain GPL-ed C program would be vicariously liable of copyright infringement, because (even without changing the makefile) users could compile and link it on a platform with a proprietary libc, to create an executable, whose distribution would not only violate the GPL of the C source, but the copyright of the author of the libc as well. (The point I think should be clear: creating and running the executable is fine, distributing it is not.) The fact that the GPL grants you permission to modify and redistribute under certain conditions does not mean you are allowed to do so if that is illegal for other reasons. I'll give an example that illustrates my point clearly, even if it is a bit extreme. Suppose a company FdSE[*] distributes from its WWW-server a program QRS in source form with the following copyright notice Copyright 2000, Fin du Siecle Entreprises All rights reserved. Copying or redistributing this software, in source or binary, in original or modified form, in any form, by anybody other than Fin du Siecle Entreprises, are NOT authorised, and are prohibited by copyright law. This prohibition does not affect your freedom to handle this copy in any way you please within the confines of your personal equipment. See the README file for some suggestions. The README file says something like You can use the C program as test input for your compiler; some dummy header files are provided for this purpose. You may find more enjoyment however if you procure yourself the Qt library, which is distributed by Troll Tech (http://www.troll.no/) and many independent redistributors. If you do not already have this library installed, but you have Internet connection, you can achieve this by typing make download-Qt. Then you can then compile and link QRS by typing make with-Qt. If after playing around with QRS you find you get tired of retyping the same input again and again, you may want to try adding the marvellous readline library developed by the Free Software Foundation to your program. Again this library is available for free from many independent redistributors. To make it easy for you, you can download it automatically by typing make download-readline. Then you can build a new version of QRS by typing make with-Qt-and-readline. Please remember that while you can play with them as you like, you may not transfer the resulting programs beyond the confines of your private equipment; you would be infringing the copyrights of FdSE and others if you did. If you want to take a copy elsewhere you must transfer a new copy of the sources directly from the FdSE server and recompile.
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: Vicarious liblity (was: KDE not in Debian?)
On Fri, Feb 04, 2000 at 03:52:31PM +0100, Marc van Leeuwen wrote: If your point is that a distribution that in itself is not infringing on anybody's copyright, could be considered vicariously liable of such infringement because, after tweaking the makefile a bit, and then using it to create an executable that is essentially different from anything present in the original distribution, recipients could infringe copyright by distributing that executable, then I must say this interpretation of vicarious liability seems unacceptable to me. Of course, that particular example is only relevant in the context of the GPL, it's not relevant for copyrights in general. By the same token distributing source code of a very plain GPL-ed C program would be vicariously liable of copyright infringement, because (even without changing the makefile) users could compile and link it on a platform with a proprietary libc, to create an executable, whose distribution would not only violate the GPL of the C source, but the copyright of the author of the libc as well. No, because that would be a different program which contains different elements. (The point I think should be clear: creating and running the executable is fine, distributing it is not.) The fact that the GPL grants you permission to modify and redistribute under certain conditions does not mean you are allowed to do so if that is illegal for other reasons. Certainly. However, this particular change does *not* alter the source code, or the introduce any new components which would not already be present. It just alters their form. The fact is: when kghostscript is running, it contains QPL and GPLed code. Pretending that that's not what's happening is a fraud. The -static example is merely an illustration. -- Raul
New ways to evade copyright law (was Re: Vicarious liblity (was: KDE not in Debian?))
Apparently, some people think that the introduction of some new distribution mechanism will confuse the people who enforce copyright law think that distribution isn't happening. So, let's say that I come up with a new way of distributing text: I'll send all the vowels in one file (it will be downloaded from the web), I'll send all the consonants in a set of different files (one per consonant -- they will be emailed), and I'll send the punctuation in a third file (it will be posted as news). And, let's say that I include enough meta-information in these files such that they will just happen to combine themselves to create the original text. No one file, taken individually, could be mistaken for a copyrighted work -- only by taking the files as a group which would be pieced together by individual effort could I be said to be distributing a copyrighted work. Do people think that would be legal? If not, why not? -- Raul
Re: New ways to evade copyright law (was Re: Vicarious liblity (was: KDE not in Debian?))
There is one way you can redistribute copyrighted works within the law. Paraphrase them, and cite them. Its done in schools every day and is perfectly legal. If you take a paragraph of a book, and rewrite its meaning, cite the original source in a bilbiography, and pass it on, that is perfectly within the law. Similarly, you could take written software code, write the specfications down, and send that instead of the original code (to get around any liscensing issues). Trying to claim random chance as a reason for a copyright violation is a little like saying you had ten chimps randomly type up Hamlet in one week. While theoretically possible, noone would take you seriously, and law is all about being taken seriously. Similarly, you won't convince twelve jurours that sendmail accidentally sent out 50,000 emails, which when put together in reverse order and rot13'd, for example, inadvertently became Applied Cryptography. --- David Graham [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] GEECS.org administrator, CSClub.cis.uoguelph.ca administrator, frosh, BComp This .signature is dynamically rebuilt 1440 times a day. At Group L, Stoffel oversees six first-rate programmers, a managerial challenge roughly comparable to herding cats. -- The Washington Post Magazine, 9 June, 1985 On Fri, 4 Feb 2000, Seth David Schoen wrote: Raul Miller writes: [...] No, because the law concerns itself with judging intent. If you distribute random data which _truly accidentally_ could be interpreted to violate some law, then that's no problem; but if you had the intent to violate copyright law by a _series of related actions_ -- no one of which violated a copyright -- then it might easily be established that the overall design and pattern of your activity was a deliberate violation. Someone could argue in court about the probability that it was just an accident. In most cases in which you actually violated a copyright on purpose, it's not very likely that it would end up looking like a plausible accident (if you intended for some other person to be able to reconstruct the original information, then a court can probably reconstruct it, too, especially given any instructions that you or someone in concert with you happened to give out). Using statistical arguments to estimate probabilities that copyright violations are accidental is not a new idea. In fact, the whole point of digital watermarking is simply to make that easier, and make it dramatically less likely that you can realistically claim that a certain similarity is merely co-incidental. So, what about the situation in which 5,000 people distribute something which they would otherwise not be allowed to distribute by taking random excerpts? E.g. I say At offset 8354, value 0x98c4076d, and post that in some public place. Well, if some of these people actually intended that the result of their joint activity would be the effective transmission of whatever they were not allowed to transmit, they could be accused of conspiracy. -- Seth David Schoen [EMAIL PROTECTED] | And do not say, I will study when I Temp. http://www.loyalty.org/~schoen/ | have leisure; for perhaps you will down: http://www.loyalty.org/ (CAF) | not have leisure. -- Pirke Avot 2:5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: KDE not in Debian?
On Wed, Feb 02, 2000 at 05:49:10PM +0100, Marc van Leeuwen wrote: And run-time is post-distribution while compile-time is pre-distribution, in the case of distribution of dynamically linked binaries. And no copyright-based licence has anything to say about what end users can do with the code they legally obtained (except redistribution). We're not talking about an isolated personal action here. We're talking about many thousands, if not millions of copies which are distributed by people who know what the end result is going to be. To see what that means, check out http://www.ladas.com/NII/CopyrightInfringement.html#con Yep, I checked it out. Here it is c. CONTRIBUTORY AND VICARIOUS LIABILITY Direct participation in infringing activity is not a prerequisite for infringement liability, as the Copyright Act grants to copyright owners not only the right to exercise the exclusive rights, but also the right to authorize the exercise of those rights. The inclusion of the right to authorize was intended to avoid any questions as to the liability of contributory infringers -- those who do not directly exercise the copyright owner's rights, but authorize others to do so. [...] exercise the copyright owner's rights means basically copying and distributing the copyrighted material. But my main point here is that dynamically loading into virtual memory an executable image from a legally obtained copy of a library object file and an application executable that was (by the distributor) dynamically linked against a copy that same library object file and thereafter legally distributed to the user, does not infringe the copyright owner's [of the library] rights. We're talking about libraries that can be publically distributed, or maybe about libraries that are not free but which the user has purchased. Really the act of loading is not in itself illegal. It would be if the end result would be distributed without permission from the author of the library, but that is not the case. And a million times no copyright infringement still makes no copyright infringement. I repeat my question: could Microsoft forbid our tax the distribution of binaries that are executable under MS Windows? To complete the quote: If someone has the right and ability to supervise the infringing action of another, and that right and ability coalesce with an obvious and direct financial interest in the exploitation of copyrighted materials -- even in the absence of actual knowledge that the infringement is taking place -- the supervisor may be held vicariously liable for the infringement. Vicarious liability is based on a connection to the direct infringer (not necessarily to the infringing activity). infringing action, infringement, infringer, infringing activity, its clear that without infringement there's no vicarious liability. The best known copyright cases involving vicarious liability are the dance hall cases, where vicarious liability was found when dance hall owners allowed the unauthorized public performance of musical works by the bands they hired, even when the owners had no knowledge of the infringements and had even expressly warned the bands not to perform copyrighted works without a license from the copyright owners. I maintain that unless the distribution of dynamically linked binaries itself is considered a copyright infringement, there's no vicarious liability either. And to come back to the static/dynamic distinction: an obvious and relevant difference with distribution of statically linked binaries is that the user can execute those without also having the library object file. Marc van Leeuwen Universite de Poitiers http://wwwmathlabo.univ-poitiers.fr/~maavl/
Re: KDE not in Debian?
Marcus Brinkmann [EMAIL PROTECTED] wrote On Wed, Feb 02, 2000 at 05:49:10PM +0100, Marc van Leeuwen wrote: By the way, I assume that Microsoft does not forbid distribution of binaries for programs that run under MS Windows (that would certainly decrease the popularity of their platform). If they run without using Microsoft code (for example libraries), Microsoft has no say in it. However, no serious windows program does. Is this because they explicitly gave permission, or simply because their permission is not required? I honestly don't know, but I would bet it is the second possibilty. Does anybody have more definite information on such issues? Your question is answered by looking at the relevant licenses in MS development kits. For example the Visual Basic runtime library has a very restrictive license. You are allowed to distribute it with a VB program only. Of course, you must not reverse engineer etc. Thanks for the information (though I haven't any development kits to look at). Unfortunately it doesn't answer my question, or more exactly, shows that my question wasn't the one I was really after. If MS really is able (or think they are able) to bind people to a contract before they can even begin to make a Windows application, then they don't need to invoke copyright law, and so their position does not illuminate the possiblities of that law. I was thinking of a program that was freely developed and compiled to run under Windows (i.e., with the Windows API), but which does not require any other MS product (like the VB runtime library) to accompany it. Maybe such programs cannot legally exist, and the question becomes meaningless. Unless there is maybe some other proprietary platform, where users can actually get to own their copy of the software... Marc van Leeuwen
Re: KDE not in Debian?
On Thu, Feb 03, 2000 at 01:03:35PM +0100, Marc van Leeuwen wrote: Thanks for the information (though I haven't any development kits to look at). Unfortunately it doesn't answer my question, or more exactly, shows that my question wasn't the one I was really after. If MS really is able (or think they are able) to bind people to a contract before they can even begin to make a Windows application, then they don't need to invoke copyright law, and so their position does not illuminate the possiblities of that law. Well, this is not what I was saying, but read on. I was thinking of a program that was freely developed and compiled to run under Windows (i.e., with the Windows API), How can you use the Windows API without including for example Window header files? You can't if you don't have a fully compatible replacement library, which is not only API compatible, but also ABI compatible, so you don't need to recompile (eg a program which can be linked to Windows DLLs at runtime without using any MS licensed source code). As Ideas can't be copyrighted, only patented, under such circumstances MS would have no way to forbid redistributing such a hypothetical binary. It is really the same discussion as with a non-GPLed readline replacement. but which does not require any other MS product (like the VB runtime library) to accompany it. There is no legal difference between VB runtime libraries, header files and DLLs. It does matter how you produced your binary. If you can write a binary that can make use of the VB runtime lib without being compiled with Visual Basic, the situation is the same as above. Maybe such programs cannot legally exist, and the question becomes meaningless. Unless there is maybe some other proprietary platform, where users can actually get to own their copy of the software... Those programs can exist, but are difficult to produce. You would have to avoid carefully any reference to other peoples copyrighted material as header files etc. However, I can't see how this point is of interest in this discussion. Thanks, Marcus
Re: KDE not in Debian?
On Tue, 1 Feb 2000 13:56:07 -0500 Raul Miller [EMAIL PROTECTED] wrote: In my opinion, the biggest conflict isn't 6c (though 6c could be a problem to someone doing a local distribution in a third-world country). The biggest conflict is the combination of 3b and 4c. 3b says that Qt is proprietary to Troll (they own the code and can re-release it under any license whatsoever). 4c makes 3b a restriction on distribution. Just a tiny precision to avoid any confusion. As almost everybody except Andreas Pour seems to agree, the condition in GPL 2b that every part of the complete sources be licensed.. to all third parties under the terms of this License means that third parties should have all permissions given by the GPL with respect to them, not that they couldn't possibly also have more or broader permissions. Similarly QPL section 4c: 4. You may distribute machine-executable... provided that: c. You must ensure that all modifications included in the machine-executable forms are available under the terms of this license. only says that you may not deny any of QPL's permissions when distributing executables. The fact that you may not grant any additional permissions either (e.g., by removing restriction 3b on modifications) is simply a consequence of the fact that as Troll owns copyright on the executables, you cannot lift the conditions they place on distributing them. So 3b alone gives your conflict. Marc van Leeuwen Universite de Poitiers
Re: KDE not in Debian?
On Thu, Feb 03, 2000 at 12:38:51PM +0100, Marc van Leeuwen wrote: I maintain that unless the distribution of dynamically linked binaries itself is considered a copyright infringement, there's no vicarious liability either. And to come back to the static/dynamic distinction: an obvious and relevant difference with distribution of statically linked binaries is that the user can execute those without also having the library object file. Ok, let's pretend for a minute that distributing kghostscript is legal. What does that mean? Well, for one thing, it should be legal to make trivial changes to the source and redistribute. For example, adding -static to the CFLAGS in the makefile and redistributing should be perfectly legal. You've granted this right under the GPL. Now, let's say that I take this modified version of the sources for kghostscript and decide to chop out some of Qt, add in some code in from the Gimp, and in the process wind up creating a Qt variant where any display element will renders postscript. Imagine that, after a couple years of development, the resulting widget set is extracted out of the program and achieves great popularity. So Troll decided to exercise their rights, takes a copy of that widget set, cleans it up, and sells it under their professional license. Would you agree that each of these steps would be legal as a consequence of kghostscript being licensed under the GPL? Would you agree that this would be legal as a consequence of kghostscript being licensed under Qt? If not, why not? [By the way, I'm not trying to predict the future here -- feel free to treat kghostscript, Gimp and postscript as metasyntactic variables.] -- Raul
Re: KDE not in Debian?
Chris Lawrence wrote: If you have something to say, say it to the lists. Sorry, I was trying to get you to respond to the particular issues I had made rather than continue to make the generalized statements It just isn't so or The GPL requires this w/out bothering to indicate where in the GPL this is required. But, alas, I have failed :-(. While I could respect your different reading of the GPL, I cannot see how your reading of the GPL allows linking with XFree code but not Qt code. To date, nobody has explained this to me, except by claiming that the XFree code can be licensed under the GPL. When I went through a thorough exercise of showing why this in fact can't be done (my post bearing Message-ID [EMAIL PROTECTED]), nobody has responded, perhaps b/c you agree that I am right. So you really have a dilemna here: how can you read the GPL to permit linking GPL code with X code while at the same time preventing linking GPL code with QPL code? (This will be my last post on this topic, barring egregious factual errors that need correction---mine or those of others.) You haven't required it, AFAIK, from Gnome or other programs that link with X. And under your reading of the GPL (at least if you agree with the others I have been debating this issue with), if Qt is incompatible with the GPL, so is XFree. Oh right, it would really suck if you couldn't distribute XFree, so you can just ignore that transgression. Or am I missing something? (Please respond to my post with Message-ID [EMAIL PROTECTED] so I don't have to drown this list in repeating it). XFree is not distributed under a license more restrictive than the GPL. Qt is. That's it. End of story. Hmm, the problem I have is that I do not see language in the GPL that says anything about code being more restrictive being a criteria; you wishing it to say that does not make it so. If you refer to Section 6's requirement that you impose no additional restrictions, here again is the language: Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Now, let's look at this closely. The provisions kick in when you distribute the Program or any work based on the Program. The former part would be distributions under Section 1 and the second part distributions under Section 2 (and of course both could apply to Section 3, depending on whether changes were made). Now what happens when you do this? The recipient gets a license from the Program author (i.e., for the GPL'd code) to copy, distribute or modify the Program, subject to the terms and conditions. This would not include the added part, as is obvious since the original licensor cannot grant a license w/r/t the added part, not being the author. Next, it says you cannot impose further restrictions on the rights granted herein. My question is, where does Qt impose further restrictions on the rights granted herein? Well, that boils down to this question: what rights does the GPL grant with respect to the added code? This is where the heart of this debate is. Some people see Section 2 as requiring that the modified part be licensed under the GPL. However, as I have pointed out in my other e-mails, and which nobody has credibly disputed, XFree code cannot be licensed under the GPL. Thus, if you read Section 2 thus, you cannot distribute X code with GPL code. However, Debian does this. The other way to read Section 2 is how I do, that it only requires that the source to the modified code be made freely available to all third parties and that no charges be made for redistributing the modified code. Both Qt and X code comply with these requirements. So I am interested to know, even if I agreed with the statement, why it is relevant that XFree is not distributed under a license more restrictive than the GPL. Qt is. Even if that is true, you have not given any reason why that would make a difference under the GPL. I realize this license exercise is not simple. If you don't understand how all this fits together, that's OK. But in that case you should not criticize others for their reading of it, or claim that they are doing something wrong. From section 2 of the GPL: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the
Re: KDE not in Debian?
On Tue, Feb 01, 2000 at 08:16:36PM -0500, Andreas Pour wrote: While I could respect your different reading of the GPL, I cannot see how your reading of the GPL allows linking with XFree code but not Qt code. To date, nobody has explained this to me, except by claiming that the XFree code can be licensed under the GPL. When I went through a thorough exercise of showing why this in fact can't be done (my post bearing Message-ID [EMAIL PROTECTED]), nobody has responded, perhaps b/c you agree that I am right. The basic issue is that the XFree code doesn't impose any restrictions on the resulting program that the GPL doesn't already apply while Qt does impose some additional restrictions. Your first paragraph in the [EMAIL PROTECTED] message said: I think you stated at some other point that if a right is not granted you don't have it. I think we agree that under copyright law you normally do not have a right to make copies and redistribute. The BSD license says you can redistribute. To go from that to say you can redistribute under any terms, rather than continuing to distribute under the original terms, you want is IMHO a stretch. Maybe a court would rule so if the situation arose, but as you appear to be concerned about the threat of a lawsuit and/or complying with a social contract I would think this uncertainty would trouble you as well. The point is not that BSD code is being redistributed under any terms, but it's being distributed under terms which don't grant any rights beyond those which were originally present. Likewise, for the GPLed case, no rights are being asserted beyond those which were originally present. And (this is particularly important when talking about the GPL), the BSD license does not *remove* any of the rights which are available for the GPLed code. [This last issue doesn't matter for the BSD license by itself -- I've got BSD code running which I can't get the source for because it's being distributed under terms which don't give me a right to access the source code.] -- Raul
Re: KDE not in Debian?
Raul Miller wrote: You don't see what the problem is. You *refuse* to accept even bug fixes that are GPLed, but you don't see what the problem is. I take it that there's no basis for your refusal then? I think we're talking two languages here. I would have to refuse any GPLd bugfix since it would be applied *inside* my application. I would be forced to distribute my own application according to your terms. This is legally untenable. To accept a GPLd bugfix is to change my license. Accepting a modification that resided only in a separate source file may be a different matter though, and I would be open to discuss such a scheme with a submitter. Would you accept a QPLd bugfix to a LGPL library? The KDE/Qt situation is much different. Qt is outside of KDE. They have distinct copyright holders. They only make contact through dynamic linkage. The QPL does not impose its own license terms upon applications that link to it (only that they be open source). Accepting a QPLd bugfix to Qt does not suddenly make KDE a QPLd application. If Troll Tech chooses to only accept bugfixes assignable to Troll Tech, it affects nobody but Troll Tech. David Johnson
Re: KDE not in Debian?
On Tue, Feb 01, 2000 at 10:07:37AM -0800, David Johnson wrote: My belief is that the provisions that might require you to give your source code to Troll, even if the binary code is not distributed to others, were the most egregious (the GPL only obligates you to give source code to people you give binaries to; if you don't give someone binaries, you don't have to give them source either). Section 6c, which talks about giving a copy to Troll Tech, only applies to section 6, which is concerned with distribution. Basically, if and only if you distribute such a program, then Troll Tech also gets a copy if they ask. The QPL is completely silent on personal uses, disallows private distributions, and is hunky-dory with public distributions. Troll Tech indicates it is their intention to catch people who are not distributing code to cough up a copy. Stark contrast to what you claim here. Their intent seems to be about 9/10 of what a license on a piece of software means in the US at least, based on what little case law there is on the matter. -- 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 If we want something nice to get born in nine months, then sex has to happen. We want to have the kind of sex that is acceptable and fun for both people, not the kind where someone is getting screwed. Let's get some cross fertilization, but not someone getting screwed. -- Larry Wall pgpNeffcfuf39.pgp Description: PGP signature
Re: KDE not in Debian?
Joseph Carter wrote: Section 6c, which talks about giving a copy to Troll Tech, only applies to section 6, which is concerned with distribution. Basically, if and only if you distribute such a program, then Troll Tech also gets a copy if they ask. The QPL is completely silent on personal uses, disallows private distributions, and is hunky-dory with public distributions. Troll Tech indicates it is their intention to catch people who are not distributing code to cough up a copy. Stark contrast to what you claim here. Their intent seems to be about 9/10 of what a license on a piece of software means in the US at least, based on what little case law there is on the matter. The only thing I am claiming is what is written in the license, since I have nothing else to go by. But I am curious, how do they intend to find out which people are not distributing code? How could they possibly know? I think what they are attempting to do with Section 6c is to eliminate private distributions. The Corel beta test comes to mind. IMHO, it's a lot less irksome than those freeware licenses that say for personal use only. David Johnson
Re: KDE not in Debian?
On Tue, Feb 01, 2000 at 07:06:04PM -0800, David Johnson wrote: Section 6c, which talks about giving a copy to Troll Tech, only applies to section 6, which is concerned with distribution. Basically, if and only if you distribute such a program, then Troll Tech also gets a copy if they ask. The QPL is completely silent on personal uses, disallows private distributions, and is hunky-dory with public distributions. Troll Tech indicates it is their intention to catch people who are not distributing code to cough up a copy. Stark contrast to what you claim here. Their intent seems to be about 9/10 of what a license on a piece of software means in the US at least, based on what little case law there is on the matter. The only thing I am claiming is what is written in the license, since I have nothing else to go by. But I am curious, how do they intend to find out which people are not distributing code? You pose an interesting question, one I think has been asked. I don't recall if there as an answer, much less if it was a good one. = How could they possibly know? I think what they are attempting to do with Section 6c is to eliminate private distributions. The Corel beta test comes to mind. IMHO, it's a lot less irksome than those freeware licenses that say for personal use only. Right, but it's still a GPL compatibility contention as written. It can be REwritten to say exactly what you interpret it to say without conflicting with the GPL. I'll offer language which I believe would do that if it'll actually be given a fair reading... (and I also want people to check it for GPL compatibility in case I miss something...) -- 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 * Culus fears perl - the language with optional errors pgpzMjQbNTS9R.pgp Description: PGP signature
Re: KDE not in Debian?
On Tue, Feb 01, 2000 at 06:06:13PM -0800, David Johnson wrote: Would you accept a QPLd bugfix to a LGPL library? No more than I'd accept a Qt support patch to a GPLed program. The KDE/Qt situation is much different. Qt is outside of KDE. They have distinct copyright holders. They only make contact through dynamic linkage. So? When the program is running, both the GPLed code and the Qt code exist together in the same virtual memory image. Ultimately, there's no difference between run-time linking and compile-time linking except that run-time linking happens at run time while compile-time linking happens at compile time. I don't know why you pretend ignorance of this. -- Raul
Re: KDE not in Debian?
On Tue, 1 Feb 2000, Andreas Pour wrote: Chris Lawrence wrote: If you have something to say, say it to the lists. Sorry, I was trying to get you to respond to the particular issues I had made rather than continue to make the generalized statements It just isn't so or The GPL requires this w/out bothering to indicate where in the GPL this is required. But, alas, I have failed :-(. While I could respect your different reading of the GPL, I cannot see how your reading of the GPL allows linking with XFree code but not Qt code. To date, nobody has explained this to me, except by claiming that the XFree code can be licensed under the GPL. When I went through a thorough exercise of showing why this in fact can't be done (my post bearing Message-ID [EMAIL PROTECTED]), nobody has responded, perhaps b/c you agree that I am right. Scanning through your posts, all indications are that you refuse to listen. It is certainly possible to distribute XFree86 (and any derivatives) under the GPL or practically any license (as long as it preserves the copyright notice) under the sublicensing permission. In particular, the XFree86 copyright notice's permissions only apply to (a) copies you get without another license, and (b) to the original work (not derivatives). The fact that it permits copying of their code is a waiving (mostly) their copyright protections. It doesn't invalidate any other agreements you may entered regarding the code. It also doesn't invalidate different licenses on derivative works, particularly those with sufficient copyrightable content to be protectable. Furthermore, it is perfectly legal to distribute the exact same expression under multiple copyright licenses. I don't have to re-license all currently existing versions of the code to comply with the GPL on a version that includes or is derivative of some GPL'ed work. I only have to distribute that version under the GPL. You should really either (a) consult a lawyer, (b) do some legal reading on IP/contract law/torts, and/or (c) take some law classes. If you insist on continuing to debate what many of us consider obvious (e.g. that X licensed code may be redistributed under a proprietary license) then it would be best for you to post (in a relatively short way) your basic assumptions that are leading you to your conclusions. My wager is that we'll disagree with one of your assumptions, so maybe we'll get somewhere more fruitful (no guarantees though). Lynn
Re: KDE not in Debian?
Joseph Carter wrote: [ ... ] Section 6c, which talks about giving a copy to Troll Tech, only applies to section 6, which is concerned with distribution. Basically, if and only if you distribute such a program, then Troll Tech also gets a copy if they ask. The QPL is completely silent on personal uses, disallows private distributions, and is hunky-dory with public distributions. Troll Tech indicates it is their intention to catch people who are not distributing code to cough up a copy. Well, if that were the case, why does Section 6 kick in only when there is a distribution? Stark contrast to what you claim here. Their intent seems to be about 9/10 of what a license on a piece of software means in the US at least, based on what little case law there is on the matter. That may be, but it's not their inner thoughts that count, but their intent *as evidenced by the language chosen in the contract. So since Section 6 clearly indicates there must first be a distribution, that's their intent. No shortage of case law on that. Regards, Andreas
Re: KDE not in Debian?
Lynn Winebarger wrote: On Tue, 1 Feb 2000, Andreas Pour wrote: Chris Lawrence wrote: If you have something to say, say it to the lists. Sorry, I was trying to get you to respond to the particular issues I had made rather than continue to make the generalized statements It just isn't so or The GPL requires this w/out bothering to indicate where in the GPL this is required. But, alas, I have failed :-(. While I could respect your different reading of the GPL, I cannot see how your reading of the GPL allows linking with XFree code but not Qt code. To date, nobody has explained this to me, except by claiming that the XFree code can be licensed under the GPL. When I went through a thorough exercise of showing why this in fact can't be done (my post bearing Message-ID [EMAIL PROTECTED]), nobody has responded, perhaps b/c you agree that I am right. Scanning through your posts, all indications are that you refuse to listen. It is certainly possible to distribute XFree86 (and any derivatives) under the GPL or practically any license (as long as it preserves the copyright notice) under the sublicensing permission. The XFree license also says you have to include the XFree license in any copies you redistribute. I suppose you might argue there is no reason for that and we can safely ignore that rather critical condition. In that case it is you that appears not to listen. In particular, the XFree86 copyright notice's permissions only apply to (a) copies you get without another license, and (b) to the original work (not derivatives). Wrong, it says you need to include the notice with any substantial portion of the code. Notice that this license applies to each *file*, not the entire XFree build tree. So including any substantial portion of any file (however much that is), requires you to include their license. And since Debian redistributes basically all of their files untouched, there is no question that Debian has to include the XFree copyright notice and the XFree license (which is referred to as the permission notice). The fact that it permits copying of their code is a waiving (mostly) their copyright protections. Wrong. Go learn about copyright law, then come back. It doesn't invalidate any other agreements you may entered regarding the code. It also doesn't invalidate different licenses on derivative works, particularly those with sufficient copyrightable content to be protectable. No it does not, and I have never claimed it does.You can license additions to XFree code under your own license, and when someone distributes the combined work they have to comply with the XFree license and your license. The XFree code, however, at all times remains under the XFree license. Furthermore, it is perfectly legal to distribute the exact same expression under multiple copyright licenses. For the author, sure. For a recipient under a particular license, absolutely not. Otherwise I could take my MS Word and distribute it under the GPL, couldn't I? I don't have to re-license all currently existing versions of the code to comply with the GPL on a version that includes or is derivative of some GPL'ed work. I only have to distribute that version under the GPL. What does that mean? You can't distribute any version of the XFree code (i.e., if you copy a substantial portion of it) under the GPL, it remains under the XFree code license. You should really either (a) consult a lawyer, (b) do some legal reading on IP/contract law/torts, and/or (c) take some law classes. I can assure you that I don't need to, but thanks for asking. BTW, have you considered doing these things? If you insist on continuing to debate what many of us consider obvious (e.g. that X licensed code may be redistributed under a proprietary license) then it would be best for you to post (in a relatively short way) your basic assumptions that are leading you to your conclusions. My wager is that we'll disagree with one of your assumptions, so maybe we'll get somewhere more fruitful (no guarantees though). Well: (a) copyright law prevents copying of protected works without permission from the copyright holder; (b) that permission to copy can be given in a document, whether it is called a license or a permission notice or whatever, so long as in substance it permits copying; (c) if someone grants such permission, you can only copy in compliance with the grant of permission; (d) XFree grants permission to copy the code subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. (e) The reference to this permission notice in the above quote is to the license, called a permission notice in the XFree source code files, which permits copying XFree in the first place. (f) By requiring you to include the
Re: KDE not in Debian?
On Wed, 2 Feb 2000, Andreas Pour wrote: Lynn Winebarger wrote: Scanning through your posts, all indications are that you refuse to listen. It is certainly possible to distribute XFree86 (and any derivatives) under the GPL or practically any license (as long as it preserves the copyright notice) under the sublicensing permission. The XFree license also says you have to include the XFree license in any copies you redistribute. I suppose you might argue there is no reason for that and we can safely ignore that rather critical condition. In that case it is you that appears not to listen. No. I'm saying the X license allows other interests to be attached in the form of licenses, and the X copyright notice only notifies you of their (the copyright holder's) permissions. Wrong, it says you need to include the notice with any substantial portion of the code. Notice that this license applies to each *file*, not the entire XFree build tree. So including any substantial portion of any file (however much that is), requires you to include their license. And since Debian redistributes basically all of their files untouched, there is no question that Debian has to include the XFree copyright notice and the XFree license (which is referred to as the permission notice). The notice has to go in. However, the original authors cannot give permissions for modifications of the code - they don't have the sole copyright interest in derivative works. The copyright notice also does not claim it is the sole license for the code. For example, author A distributes his work W to person B. Now B gives a copy to C with a license that has additional restrictions X, Y, and Z. Now, the X license gives the permission of A for person C to exercise the rights of the copyright monopoly. That, however, does not invalidate the additional restrictions B has placed on the license for the copy. Only B can waive those restrictions. I don't see anywhere in the X license claiming that it contains the sole terms of the license to C. Quite the opposite in fact (... including without restriction the rights to ... sublicense ...). While I don't know whether a court would enforce such restrictions on the unmodified code without the intervention of the author, the X license certainly allows such additional restrictions. Here's an example of how such a sublicense might appear: You may not copy, modify, or distribute this software. XYZ Software Co. Copyright (C) 1996 X Consortium Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium. X Window System is a trademark of X Consortium, Inc. - There is no contradiction. X grants you their permission, XYZ denies you theirs, as is their right under the X license. This sublicense won't apply to other copies you get (unless they carry the same sublicense, of course). It doesn't invalidate any other agreements you may entered regarding the code. It also doesn't invalidate different licenses on derivative works, particularly those with sufficient copyrightable content to be protectable. No it does not, and I have never claimed it does.You can license additions to XFree code under your own license, and when someone distributes the combined work they have to comply with the XFree license and your license. The XFree code, however, at all times remains under the XFree license. No, the permissions explicitly allow you to attach a license to the unmodified code. You can enter agreements with respect to that code, completely unmodified. You can license the whole of any derivative work you create as you want (subject to the minor conditions of the X license). The X license
Re: KDE not in Debian?
Lynn Winebarger wrote: On Wed, 2 Feb 2000, Andreas Pour wrote: Lynn Winebarger wrote: Scanning through your posts, all indications are that you refuse to listen. It is certainly possible to distribute XFree86 (and any derivatives) under the GPL or practically any license (as long as it preserves the copyright notice) under the sublicensing permission. The XFree license also says you have to include the XFree license in any copies you redistribute. I suppose you might argue there is no reason for that and we can safely ignore that rather critical condition. In that case it is you that appears not to listen. No. I'm saying the X license allows other interests to be attached in the form of licenses, and the X copyright notice only notifies you of their (the copyright holder's) permissions. Agreed -- the XFree license applies only to the XFree code. Wrong, it says you need to include the notice with any substantial portion of the code. Notice that this license applies to each *file*, not the entire XFree build tree. So including any substantial portion of any file (however much that is), requires you to include their license. And since Debian redistributes basically all of their files untouched, there is no question that Debian has to include the XFree copyright notice and the XFree license (which is referred to as the permission notice). The notice has to go in. However, the original authors cannot give permissions for modifications of the code - they don't have the sole copyright interest in derivative works. The copyright notice also does not claim it is the sole license for the code. It is the sole license for the XFree code, but not for a derivative work. For example, author A distributes his work W to person B. Now B gives a copy to C with a license that has additional restrictions X, Y, and Z. Now, the X license gives the permission of A for person C to exercise the rights of the copyright monopoly. That, however, does not invalidate the additional restrictions B has placed on the license for the copy. I don't see how they are enforceable. The copyright holder, A, has said C can do certain things, B can't change what A has permitted C to do. But in the event this is not clear enough, XFree code specifically says you can sublicense XFree code, but only if you include the XFree license. If that were to mean that B can change the license however B wants, what would be the point of forcing B to include the XFree license? This important ir not critical condition -- in fact about the only condition -- to sublicensing is not going to be read to mean nothing by any fair-minded reader, but your reading precisely makes it mean nothing. Only B can waive those restrictions. I don't see anywhere in the X license claiming that it contains the sole terms of the license to C.Quite the opposite in fact (... including without restriction the rights to ... sublicense ...). Right, but the right to sublicense is subject to the obligation to include the X Copyright and the X license in the copy B distributes. Again, if the License means nothing, and in fact C cannot deal in the Software without limitation (as the X license provides), what is the point in including the license in the copy that's distributed? Please explain that to me. While I don't know whether a court would enforce such restrictions on the unmodified code without the intervention of the author, the X license certainly allows such additional restrictions. I don't see where it does. The fact that X license does not explicitly prohibit changing the license does not imply a right to change it. The fact that the X license affirmatively requires copies of the code to include the license is more than enough. Here's an example of how such a sublicense might appear: You may not copy, modify, or distribute this software. XYZ Software Co. Copyright (C) 1996 X Consortium Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
Re: KDE not in Debian?
On Wed, 2 Feb 2000, Andreas Pour wrote: Lynn Winebarger wrote: I don't see how they are enforceable. The copyright holder, A, has said C can do certain things, B can't change what A has permitted C to do. But in the event this is not clear enough, XFree code specifically says you can sublicense XFree code, but only if you include the XFree license. If that were to mean that B can change the license however B wants, what would be the point of forcing B to include the XFree license? This important ir not critical condition -- in fact about the only condition -- to sublicensing is not going to be read to mean nothing by any fair-minded reader, but your reading precisely makes it mean nothing. They may be enforceable to the extent that A has told B they are enforceable (by allowing sublicensing without limitation). Unless you have case law references, it's fairly useless to debate whether or not it's enforceable. There are valid arguments both ways (when it comes to unmodified works). Right, but the right to sublicense is subject to the obligation to include the X Copyright and the X license in the copy B distributes. Again, if the License means nothing, and in fact C cannot deal in the Software without limitation (as the X license provides), what is the point in including the license in the copy that's distributed? Please explain that to me. The purpose is to indicate that party A gives you permission, not to say that every party with an interest has given you permission. You'll notice the statement starts with Permission is hereby granted not A license is hereby granted. I don't see where it does. The fact that X license does not explicitly prohibit changing the license does not imply a right to change it. The fact that the X license affirmatively requires copies of the code to include the license is more than enough. It explicitly allows sublicensing. If you can't understand this point, then there's not much point in continuing. Here's an example of how such a sublicense might appear: You may not copy, modify, or distribute this software. XYZ Software Co. Copyright (C) 1996 X Consortium Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium. X Window System is a trademark of X Consortium, Inc. - There is no contradiction. X grants you their permission, XYZ denies you theirs, as is their right under the X license. I don't agree. Where does the X license specifically grant the right to alter the license? It doesn't --you imply this rather powerful right to sublicense under any terms you want from the mere absence of an explicit prohibition against doing that, all the time ignoring the purpose of the requirement that the sublicensor include the original You must have missed it: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation ^ the rights to use, copy, ^ modify, merge, publish, distribute, sublicense, and/or sell copies of the ^^ Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: I have not implied a thing: it's right there. license. Note, incidentally, that the X license does not require the sublicensor to include the dislcaimer of warranty, only the License. Why is this so? I would guess they believe any
Re: KDE not in Debian?
Lynn Winebarger wrote: On Wed, 2 Feb 2000, Andreas Pour wrote: Lynn Winebarger wrote: I don't see how they are enforceable. The copyright holder, A, has said C can do certain things, B can't change what A has permitted C to do. But in the event this is not clear enough, XFree code specifically says you can sublicense XFree code, but only if you include the XFree license. If that were to mean that B can change the license however B wants, what would be the point of forcing B to include the XFree license? This important ir not critical condition -- in fact about the only condition -- to sublicensing is not going to be read to mean nothing by any fair-minded reader, but your reading precisely makes it mean nothing. They may be enforceable to the extent that A has told B they are enforceable (by allowing sublicensing without limitation). Enforceable by B?On what basis? The license is not a contract -- it's a license. It is a grant of permission from an owner to do something that otherwise is prohibited. For B to be able to enforce anything against C, there must be a right of B that C has violated. If C violates the no-copy provision B put there and B sues C, wh Unless you have case law references, it's fairly useless to debate whether or not it's enforceable. There are valid arguments both ways (when it comes to unmodified works). Well, there certainly is no case law reference that Qt is incompatible with GPL, is there? I thought the uncertainly is what bothers Debian. Looks like at best we have thick uncertainty here. Right, but the right to sublicense is subject to the obligation to include the X Copyright and the X license in the copy B distributes. Again, if the License means nothing, and in fact C cannot deal in the Software without limitation (as the X license provides), what is the point in including the license in the copy that's distributed? Please explain that to me. The purpose is to indicate that party A gives you permission, not to say that every party with an interest has given you permission. What interest does B have? And, moreover, why is it relevant that A has granted this permission, if someone else took it away and thus you in fact don't have that permission? I hardly think that providing this type of information warrants the only condition to redistribution and copying, do you? I mean, you really have reduced it to nothing more than, Oh by the way, this was the original license, though it doesn't apply to you, even though of course it doesn't say that, yet including this meaningless phrase is, under your reading, the sole condition to copynig and redistributing the work. So if I am the person writing this license, I must be thinking, here's all this great code I wrote, I want to give it away to everyone. To do that I am writing this tiny little license. Now I will let everyone go and change the code all they want, but I won't let them change the license, and I will make them include it in each copy! But don't worry, the license doesn't mean anything, since anyone can change the license however they please, but I am so darned proud of that tiny little license, I want everyone to be able to see it in its splendid glory. Perhaps the author of this license was the tooth fairy. You'll notice the statement starts with Permission is hereby granted not A license is hereby granted. Let's not get caught up in magic words. You don't have to say the magic word license (e.g., a ticket to a movie is a license, as is a stay in a hotel, but it does not say license on the movie ticket or the hotel key). Bear in mind that if in fact the permission notice is not a license, not even B could copy the code. I don't see where it does. The fact that X license does not explicitly prohibit changing the license does not imply a right to change it. The fact that the X license affirmatively requires copies of the code to include the license is more than enough. It explicitly allows sublicensing. If you can't understand this point, then there's not much point in continuing. Again, there is a huge difference between allowing sublicensing, and allowing it on any terms you see fit. Moreover, XFree requires you to include its license. Here's an example of how such a sublicense might appear: You may not copy, modify, or distribute this software. XYZ Software Co. Copyright (C) 1996 X Consortium Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the
Re: KDE not in Debian?
Andreas Pour [EMAIL PROTECTED] wrote: I cannot see how your reading of the GPL allows linking with XFree code but not Qt code. To date, nobody has explained this to me, except by claiming that the XFree code can be licensed under the GPL. When I went through a thorough exercise of showing why this in fact can't be done (my post bearing Message-ID [EMAIL PROTECTED]), nobody has responded, perhaps because you agree that I am right. Did you read my rather long message On interpreting licences? Maybe that was no explicit response to the message you cited, but it does contain implicitly the explanation you talk about. Let me try to make this very clear. I do agree with you that XFree (source) code cannot be licensed under the GPL, in the sense that nobody can impose the conditions of the GPL on distribution of XFree (except its authors, who obviously don't). All identical copies of a work are the same intellectual property, and only the author gets to state conditions for permitting distribution. Now suppose we want to distribute an executable that is obtained from a GPL-ed application App compiled and statically linked against an XFree library. Separation of the X and App parts of the binary being impossible, both the GPL-author and XFree86 get to state conditions on its distribution. Those of XFree86 are easily met by including their licence in the binary distribution, obviously indicating that their conditions are not the complete set applicable. Now the GPL conditions, which are more subtle. The immediately relevant part reads 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of 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; So we must accompany the binary with the sources of App and X (or do something equivalent by alternatives b,c). Moreover that distribution must be under the terms of GPL sections 1 and 2. Which does not mean that X be relicensed under GPL, but that the conditions sections 1 and 2 impose on distribution must be applied to this particular distribution of App and X (as I have said, a distributor can be bound by more conditions than stated in the licence of the product distributed, and for this X source distribution, that is the case). So we must see if the App and X sources can be so distributed, in order to allow our binary to be distributed. GPL section 1 says copyright notices must be conserved; that's OK. Section 2 says distribution of modifications or work [based on the Program] is subject to conditions, of which the most relevant one is b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Or work is the complete... source code of the binary, which we were required to distribute by section 3, so we _must_ consider it to be a single whole here; that whole contains App so that this clause applies. The explanation following indicates explicitly that the terms apply to sections of the work [that] are not derived from the Program, and [that] can be reasonably considered independent and separate works in themselves if (and only if) those are distributed as part of a whole which is a work based on the Program. This is the case for the X sources we are going to distribute, as the complete source code for the binary obviously is a work based on App. So we must cause the App and X sources to be licensed as a whole at no charge to all third parties under the terms of this License. I've already commented on the word cause; in the ordinary sense of cause and effect this is not possible: as distributor, being author of neither X nor App, we have no say in third party's rights to the App and X sources. But those rights being fixed, we may check whether third parties do in fact receive the licence formulated in the GPL. For the App sources this is clear; for the X sources third parties in fact have licence to do anything the X licence permits, but since this includes all permissions given in the GPL, and not with stricter conditions, we may conclude that third parties receive full GPL licence with respect to the complete sources, and condition 2b is satisfied. So we can distribute the full sources and therefore the binary and everybody is happy. N.B. This analysis does seem to imply that we have to accompany the binary with complete sources as a whole, possibly by reference (3b,c). Strictly speaking it will not do to give individual references to App sources and X sources. But this is not going to cause any fundamental problems. Now you may do the same
Re: KDE not in Debian?
Marc van Leeuwen wrote: Andreas Pour [EMAIL PROTECTED] wrote: I cannot see how your reading of the GPL allows linking with XFree code but not Qt code. To date, nobody has explained this to me, except by claiming that the XFree code can be licensed under the GPL. When I went through a thorough exercise of showing why this in fact can't be done (my post bearing Message-ID [EMAIL PROTECTED]), nobody has responded, perhaps because you agree that I am right. Did you read my rather long message On interpreting licences? Maybe that was no explicit response to the message you cited, but it does contain implicitly the explanation you talk about. Let me try to make this very clear. I do agree with you that XFree (source) code cannot be licensed under the GPL, in the sense that nobody can impose the conditions of the GPL on distribution of XFree (except its authors, who obviously don't). All identical copies of a work are the same intellectual property, and only the author gets to state conditions for permitting distribution. Now suppose we want to distribute an executable that is obtained from a GPL-ed application App compiled and statically linked against an XFree library. Separation of the X and App parts of the binary being impossible, both the GPL-author and XFree86 get to state conditions on its distribution. Those of XFree86 are easily met by including their licence in the binary distribution, obviously indicating that their conditions are not the complete set applicable. Now the GPL conditions, which are more subtle. The immediately relevant part reads 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of 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; So we must accompany the binary with the sources of App and X (or do something equivalent by alternatives b,c). Moreover that distribution must be under the terms of GPL sections 1 and 2. Which does not mean that X be relicensed under GPL, but that the conditions sections 1 and 2 impose on distribution must be applied to this particular distribution of App and X (as I have said, a distributor can be bound by more conditions than stated in the licence of the product distributed, and for this X source distribution, that is the case). So we must see if the App and X sources can be so distributed, in order to allow our binary to be distributed. GPL section 1 says copyright notices must be conserved; that's OK. Section 2 says distribution of modifications or work [based on the Program] is subject to conditions, of which the most relevant one is b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Or work is the complete... source code of the binary, which we were required to distribute by section 3, so we _must_ consider it to be a single whole here; that whole contains App so that this clause applies. The explanation following indicates explicitly that the terms apply to sections of the work [that] are not derived from the Program, and [that] can be reasonably considered independent and separate works in themselves if (and only if) those are distributed as part of a whole which is a work based on the Program. This is the case for the X sources we are going to distribute, as the complete source code for the binary obviously is a work based on App. So we must cause the App and X sources to be licensed as a whole at no charge to all third parties under the terms of this License. I've already commented on the word cause; in the ordinary sense of cause and effect this is not possible: as distributor, being author of neither X nor App, we have no say in third party's rights to the App and X sources. Right, but you forget about Section 7 of the GPL. It says there that if for whatever reason -- including patent law -- you cannot comply with the GPL, you cannot redistribute/copy. Since you cannot cause it to happen, you can't redistribute: If, as a consequence of a court judgment or allegation of patent infringement or *for any other reason* (not limited to patent issues), conditions are imposed on you (whether by court order, *agreement* *or otherwise*) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License *and any other pertinent obligations*, then as a consequence you may not distribute
Re: KDE not in Debian?
Andreas Pour [EMAIL PROTECTED] wrote Marc van Leeuwen wrote: So we must cause the App and X sources to be licensed as a whole at no charge to all third parties under the terms of this License. I've already commented on the word cause; in the ordinary sense of cause and effect this is not possible: as distributor, being author of neither X nor App, we have no say in third party's rights to the App and X sources. Right, but you forget about Section 7 of the GPL. It says there that if for whatever reason -- including patent law -- you cannot comply with the GPL, you cannot redistribute/copy. Since you cannot cause it to happen, you can't redistribute: [...] The part about complying is obvious, this is the base of everything I've been saying. Yes, if you take cause to mean to take some action that achieves the stated effect and without which that effect would not have been achieved, then this is impossible, and the condition cannot be satisfied. But that would mean it can NEVER be satisfied, because the you in 2b does not own full copyright to the work; if he did there would be no need to abide by the GPL in the first place. So yes I do give a non-obvious meaning to this phrase. I did state that I was not happy with the formulation. Do you actually read what I write? I only bend the meaning here because the more obvious reading makes no sense: if the GPL is to contain conditions that can never be satisfied, it is useless, and that was not its intention. So I am entitled to try a reading that is maybe a bit less obvious, but which makes sense out of the GPL. Besides, I wonder if my interpretation is so non-obvious. If by some chance I run into the obligation to cause the sun to rise in the morning, wouldn't a judge find that I have fulfilled this obligation if in fact the sun did rise, without requiring me to demonstrate that I could have done anything to prevent it? Really this is all I've done, replaced a causal relationship by just a verication that the required effect does indeed take place. But those rights being fixed, we may check whether third parties do in fact receive the licence formulated in the GPL. For the App sources this is clear; for the X sources third parties in fact have licence to do anything the X licence permits, but since this includes all permissions given in the GPL, and not with stricter conditions, we may conclude that third parties receive full GPL licence with respect to the complete sources, and condition 2b is satisfied. Everything was going so well until you hit this point. In particular, the statement since [the X license] includes all permissions given in the GPL, and not . . . stricter conditions, we may conclude that third parties receive full GPL [license] with respect to the complete sources. As I have made abundantly clear I interprete the verb license as giving permission under conditions and the noun licence as conditional permission (I've even tried to maintain the conventional British difference in orthography, but this subtlety was probably wasted on you); just to be clear I've also added (permission) after licence at key points. The upshot is that I can give you a particular licence (permission) implicitly by in fact giving you a broader licence (permission). This is were the no stricter comes from, not from any particular words in any licence. So if I give you permission (license you) to distribute under the conditions of the X licence, I implicitly give you permission (licence you) to distrubute it under the stricter conditions of the GPL. First of all, they do not in fact receive a full GPL license; if that were the case, then they would not be able to make a binary-only distribution of the X code which is distributed as part of the package, which they can under the X license (which you agreed applies to the X code). How can having permission to do something (make binary-only distribution) prove I did not receive some other permission (full GPL)? As I see it, the phrase licensed as a whole at no charge to all third parties under the terms of this License can have only two possible meanings. One is, the whole must be licensed completely under the GPL. We both agree that does not work with XFree code. OK you've managed to completely piss me off. I won't reply to or even read your messages any more, don't bother even to write them. I've spent some considerable time to give a very detailed description of how I read that phrase, and you elect to completely ignore that and just stick to your two readings of which the second is so absurd that I can't even start to understand it. The other is, only the terms that apply explicitly to the entire whole apply to the added code. One of those terms is in Section 2(b), which requires distribution of the whole at no charge to all third parties. Not distribution at no charge, not even the GPL requires that. Being licensed (obtaining permission) at
Re: KDE not in Debian?
On Wed, Feb 02, 2000 at 08:38:07AM -0500, Andreas Pour wrote: Everything was going so well until you hit this point. In particular, the statement since [the X license] includes all permissions given in the GPL, and not . . . stricter conditions, we may conclude that third parties receive full GPL [license] with respect to the complete sources. First of all, they do not in fact receive a full GPL license; if that were the case, then they would not be able to make a binary-only distribution of the X code which is distributed as part of the package, which they can under the X license (which you agreed applies to the X code). The license allows everything that the GPL requires. You seem to be overlooking the part where the GPL states that the separately licensed software can be distributed under the original license without any of the GPLed protections as long it's being distributed by itself. -- Raul
Re: KDE not in Debian?
Marc van Leeuwen wrote: Andreas Pour [EMAIL PROTECTED] wrote Marc van Leeuwen wrote: So we must cause the App and X sources to be licensed as a whole at no charge to all third parties under the terms of this License. I've already commented on the word cause; in the ordinary sense of cause and effect this is not possible: as distributor, being author of neither X nor App, we have no say in third party's rights to the App and X sources. Right, but you forget about Section 7 of the GPL. It says there that if for whatever reason -- including patent law -- you cannot comply with the GPL, you cannot redistribute/copy. Since you cannot cause it to happen, you can't redistribute: [...] The part about complying is obvious, this is the base of everything I've been saying. Yes, if you take cause to mean to take some action that achieves the stated effect and without which that effect would not have been achieved, then this is impossible, and the condition cannot be satisfied. But that would mean it can NEVER be satisfied, because the you in 2b does not own full copyright to the work; if he did there would be no need to abide by the GPL in the first place. So yes I do give a non-obvious meaning to this phrase. I did state that I was not happy with the formulation. Do you actually read what I write? I only bend the meaning here because the more obvious reading makes no sense: if the GPL is to contain conditions that can never be satisfied, it is useless, and that was not its intention. Of course it can be satisfied. It's more difficult, obviously, when using a third party's source, but if you are modifying a GPL'd program and the modifications are yours this does not present a problem (you cause your own code to comply by releasing it under an appropriate license and you cause the GPL code to comply by distributing it, which by virtue of Section 6 of the GPL grants the appropriate rights). Incidentally, you can also cause it to be true with third-party source, by taking whatever action is required by the third party (which may be sublicensing, simply distributing the third-party work or whatever) to cause the statement to be true. However, I accept your interpretation, since I agree it is enough if the consequence is true regardless of your efforts. So I am entitled to try a reading that is maybe a bit less obvious, but which makes sense out of the GPL. Besides, I wonder if my interpretation is so non-obvious. If by some chance I run into the obligation to cause the sun to rise in the morning, wouldn't a judge find that I have fulfilled this obligation if in fact the sun did rise, without requiring me to demonstrate that I could have done anything to prevent it? Really this is all I've done, replaced a causal relationship by just a verication that the required effect does indeed take place. But those rights being fixed, we may check whether third parties do in fact receive the licence formulated in the GPL. For the App sources this is clear; for the X sources third parties in fact have licence to do anything the X licence permits, but since this includes all permissions given in the GPL, and not with stricter conditions, we may conclude that third parties receive full GPL licence with respect to the complete sources, and condition 2b is satisfied. Everything was going so well until you hit this point. In particular, the statement since [the X license] includes all permissions given in the GPL, and not . . . stricter conditions, we may conclude that third parties receive full GPL [license] with respect to the complete sources. As I have made abundantly clear Guess it wasn't abundant enough -- where did you make it 'abundantly' clear? I interprete the verb license as giving permission under conditions and the noun licence as conditional permission (I've even tried to maintain the conventional British difference in orthography, but this subtlety was probably wasted on you); Bloody right, as I'm not British, nor do I speak British English. just to be clear I've also added (permission) after licence at key points. The upshot is that I can give you a particular licence (permission) implicitly by in fact giving you a broader licence (permission). This is were the no stricter comes from, not from any particular words in any licence. OK, so you did make it up. It's not in the GPL. So if I give you permission (license you) to distribute under the conditions of the X licence, I implicitly give you permission (licence you) to distrubute it under the stricter conditions of the GPL. I thought we agreed we cannot change the license of the X code. Where is this coming from? Just to be clear, to distribute the X code under the stricter conditions of the GPL means you have to forbid the recipient from doing a binary-only distribution (for example) of the X code. So, as an
Re: KDE not in Debian?
On Wed, Feb 02, 2000 at 01:46:45AM -0500, Andreas Pour wrote: The XFree license also says you have to include the XFree license in any copies you redistribute. So does the GPL, for the cases where a GPLed program includes XFree licensed code. -- Raul
Re: KDE not in Debian?
Raul Miller wrote: On Wed, Feb 02, 2000 at 01:46:45AM -0500, Andreas Pour wrote: The XFree license also says you have to include the XFree license in any copies you redistribute. So does the GPL, for the cases where a GPLed program includes XFree licensed code. Right, b/c both require the code (whether it be XFree or GPL) to remain under its license: GPL requires you to include the GPL b/c the GPL'd code remains under the GPL when you redistribute, and XFree requires you to include the XFree license b/c the XFree code remains under the XFree license. Makes sense to me, I'm glad you agree now ;-). Ciao, Andreas
Re: KDE not in Debian?
On Wed, Feb 02, 2000 at 06:21:07AM -0500, Andreas Pour wrote: Well, there certainly is no case law reference that Qt is incompatible with GPL, is there? I thought the uncertainly is what bothers Debian. Looks like at best we have thick uncertainty here. The problem isn't uncertainty so much as the problem is the lack of explicit permission. Good author relations says hands off if the author isn't up front and direct about wanting us to distribute their code. If the author doesn't give us DFSG code (where we all have legal permission to maintain and distribute it), then we don't distribute it. Note that generally we'll refuse to distribute code, even if we have a legal right to, if the author asks that we not distribute it. In the long run, this solves a lot of problems. [This is particularly important for beta software, but it's also relevant for other transition times.] In the case of KDE, unfortunately, there's too many contradictions for us to be happy about distributing the code. There are many, many authors for KDE software, and these authors do not seem to agree on the distribution conditions they want for their part of the programs. However, it appears that many KDE authors do want us to distribute their code, so when these licensing issues get straightened out we should be able to distribute the code written by those authors. -- Raul
Re: KDE not in Debian?
On Wed, Feb 02, 2000 at 08:38:07AM -0500, Andreas Pour wrote: Everything was going so well until you hit this point. In particular, the statement since [the X license] includes all permissions given in the GPL, and not . . . stricter conditions, we may conclude that third parties receive full GPL [license] with respect to the complete sources. First of all, they do not in fact receive a full GPL license; if that were the case, then they would not be able to make a binary-only distribution of the X code which is distributed as part of the package, which they can under the X license (which you agreed applies to the X code). Raul Miller wrote: The license allows everything that the GPL requires. On Wed, Feb 02, 2000 at 10:20:01AM -0500, Andreas Pour wrote: Which would be what? Unless you're concerned about some specific issue, I'd have to recommend that you read the GPL. You seem to be overlooking the part where the GPL states that the separately licensed software can be distributed under the original license without any of the GPLed protections as long it's being distributed by itself. No, I am not overlooking that. But isn't it you who seems not to tire of reminding me that the provision of Section 2 to which you refer does not apply if you actually distribute the other work together with the GPL'd code?, which Debian does with X. Er.. for most provisions of Section 2, it's not if ... with but when ... without. However, if you're talking about the exception which lets GPLed software be distributed to run on proprietary operating systems, then yes, that might be me. [Where you have to link with a proprietary libc, or whatever.] But that particular exception doesn't make any sense in this context: X is not an operating system, and it's not proprietary. -- Raul
Re: KDE not in Debian?
Raul Miller [EMAIL PROTECTED] wrote: So? When the program is running, both the GPLed code and the Qt code exist together in the same virtual memory image. Ultimately, there's no difference between run-time linking and compile-time linking except that run-time linking happens at run time while compile-time linking happens at compile time. And run-time is post-distribution while compile-time is pre-distribution, in the case of distribution of dynamically linked binaries. And no copyright-based licence has anything to say about what end users can do with the code thay legally obtained (except redistribution). Despite what some licences pretend (e.g., QPL section 5). Nobody is going to distribute a post-dynamic-linkage virtual memory image, so its composition is rather irrelevant. If a dynamically linked object file contains no actual code from the library (which I am assuming; I'm no expert at this) then the copyright of the library does not directly affect the object file's distribution any more than the copyright of a web page I am linking to affects the (web-)distribution of my web pages. The copyright of the library (sources) may still come into scope indirectly via section 2 of the GPL (or some similar clause of a different licence, if that applies), but that is a slightly different issue that I don't intend to discuss here. The point is, there is a good basis for making the distinction between static and dynamic linkage, in some cases. By the way, I assume that Microsoft does not forbid distribution of binaries for programs that run under MS Windows (that would certainly decrease the popularity of their platform). Is this because they explicitly gave permission, or simply because their permission is not required? I honestly don't know, but I would bet it is the second possibilty. Does anybody have more definite information on such issues? Marc van Leeuwen Universite de Poitiers http://wwwmathlabo.univ-poitiers.fr/~maavl/
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
Re: KDE not in Debian?
So? When the program is running, both the GPLed code and the Qt code exist together in the same virtual memory image. Ultimately, there's no difference between run-time linking and compile-time linking except that run-time linking happens at run time while compile-time linking happens at compile time. On Wed, Feb 02, 2000 at 05:49:10PM +0100, Marc van Leeuwen wrote: And run-time is post-distribution while compile-time is pre-distribution, in the case of distribution of dynamically linked binaries. And no copyright-based licence has anything to say about what end users can do with the code thay legally obtained (except redistribution). We're not talking about an isolated personal action here. We're talking about many thousands, if not millions of copies which are distributed by people who know what the end result is going to be. To see what that means, check out http://www.ladas.com/NII/CopyrightInfringement.html#con -- Raul
Re: KDE not in Debian?
On Wed, Feb 02, 2000 at 01:46:45AM -0500, Andreas Pour wrote: The XFree license also says you have to include the XFree license in any copies you redistribute. Raul Miller wrote: So does the GPL, for the cases where a GPLed program includes XFree licensed code. On Wed, Feb 02, 2000 at 10:22:09AM -0500, Andreas Pour wrote: Right, b/c both require the code (whether it be XFree or GPL) to remain under its license: GPL requires you to include the GPL b/c the GPL'd code remains under the GPL when you redistribute, and XFree requires you to include the XFree license b/c the XFree code remains under the XFree license. Makes sense to me, I'm glad you agree now ;-). The problem in the case of GPLed code + Qt is that there are contradictory requirements. Which means that not all of the requirements can be satisfied. Which means (see section 7 again), that the GPLed program can't be legally distributed. [Um.. let me guess.. you already knew I was going to say this and you're just trying to see if I'm so sick of repeating myself that I'm not going to post anymore?] -- Raul
Re: KDE not in Debian?
On Wed, Feb 02, 2000 at 05:49:10PM +0100, Marc van Leeuwen wrote: By the way, I assume that Microsoft does not forbid distribution of binaries for programs that run under MS Windows (that would certainly decrease the popularity of their platform). If they run without using Microsoft code (for example libraries), Microsoft has no say in it. However, no serious windows program does. Is this because they explicitly gave permission, or simply because their permission is not required? I honestly don't know, but I would bet it is the second possibilty. Does anybody have more definite information on such issues? Your question is answered by looking at the relevant licenses in MS development kits. For example the Visual Basic runtime library has a very restrictive license. You are allowed to distribute it with a VB program only. Of course, you must not reverse engineer etc. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: KDE not in Debian?
sorry, it needed debian weekly news to get this message: ... If the KDE folks would make a reasonably solid statement of permission, [something that counts as a legal grant of permission] we could probably distribute most of KDE (last time I checked, there were only six packages which had problems -- nontrivial packages, but only six of them). ... we discussed this with several kde core developers, and kame to exactly the same conclusion: - lgpl is not a problem - gpl´ed but written by kde people: a statement that linking with qt is ok, and it can go in. - gpl´ed but written by someone else: don´t put it into debian. try to get the same statement from everyone involved into the program, then maybe try again. this was about nine months ago at the linuxtag in germany. the kde people gave all necessary statemtens as far as i can see, but if you want something special: you name it, you get it. so please, tell me how i can help to get kde into debian. i´m a gnome fan. but most parts of kde are open source software, and i want the user to have the choice to use those. regards, andreas former debian developer for kde. anytime again if you need me. stuck in debian new maintainer queue.
Re: Was Re: KDE not in Debian?
Raul Miller wrote: If all the relevant authors sign off on the statement, there would be no problem. But if some authors don't sign off then that would be a problem. But this doesn't explain why kdelibs are not (or will not be) included. The license in question here is LGPL instead of GPL. And once they are included, non-GPL KDE apps can be included as well, such as a lot of KOffice, Cervisia, etc. Why has this stuff been left out? David Johnson
Re: Was Re: KDE not in Debian?
Raul Miller wrote: If all the relevant authors sign off on the statement, there would be no problem. But if some authors don't sign off then that would be a problem. On Mon, Jan 31, 2000 at 04:14:56PM -0800, David Johnson wrote: But this doesn't explain why kdelibs are not (or will not be) included. The license in question here is LGPL instead of GPL. And once they are included, non-GPL KDE apps can be included as well, such as a lot of KOffice, Cervisia, etc. Why has this stuff been left out? I don't know anything specific about the kdelibs package. You'd have to ask the package maintainer. -- Raul
Re: KDE not in Debian?
If you have something to say, say it to the lists. (This will be my last post on this topic, barring egregious factual errors that need correction---mine or those of others.) You haven't required it, AFAIK, from Gnome or other programs that link with X. And under your reading of the GPL (at least if you agree with the others I have been debating this issue with), if Qt is incompatible with the GPL, so is XFree. Oh right, it would really suck if you couldn't distribute XFree, so you can just ignore that transgression. Or am I missing something? (Please respond to my post with Message-ID [EMAIL PROTECTED] so I don't have to drown this list in repeating it). XFree is not distributed under a license more restrictive than the GPL. Qt is. That's it. End of story. From section 2 of the GPL: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. There are no provisions of the XFree license that stop XFree code from being aggregated with GPLed code (the result being GPLed). By contrast, the QT FREE EDITION LICENSE (which is what Qt 1 is distributed under) specifically forbids the modification of Qt: Your software does not require modifications to Qt Free Edition. Nothing in the X license forbids modification of X by third parties. You are also forbidden from distributing modified versions of Qt1; nothing in the XFree license prohibits distribution of modified versions (see, for example, xfs-xtt, which is based on XFree's xfs implementation). As far as the QPL (Qt2) license goes, I leave the discussion to Joseph Carter, who actually helped Troll write it (with the specific intent of allowing Qt2 applications to be pure GPL) before the lawyers got involved. My belief is that the provisions that might require you to give your source code to Troll, even if the binary code is not distributed to others, were the most egregious (the GPL only obligates you to give source code to people you give binaries to; if you don't give someone binaries, you don't have to give them source either). For example, if I modify Emacs, RMS can't demand that I give him my changes unless I give him a binary of my modified Emacs; however, if I make a modified Qt2 (to create my own whizz-bang desktop that only I use), or even a program based on Qt2, Troll can demand a copy of it. That seems more restrictive than the GPL to me; I'm amazed it even meets the DFSG. Anyway, if you've followed this thread, you know that Debian has also thrown out (or not let in) other software with ambiguous license terms. XForms and Motif-based programs have gotten the same treatment (as have Qt-based programs from people other than KDE). Chris -- = |Chris Lawrence | Get rid of Roger Wicker this year!| | [EMAIL PROTECTED]| http://www.lordsutch.com/ms-one/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
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: KDE not in Debian?
Chris Lawrence wrote: My belief is that the provisions that might require you to give your source code to Troll, even if the binary code is not distributed to others, were the most egregious (the GPL only obligates you to give source code to people you give binaries to; if you don't give someone binaries, you don't have to give them source either). Section 6c, which talks about giving a copy to Troll Tech, only applies to section 6, which is concerned with distribution. Basically, if and only if you distribute such a program, then Troll Tech also gets a copy if they ask. The QPL is completely silent on personal uses, disallows private distributions, and is hunky-dory with public distributions. David Johnson
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
