On Sat, Jan 29, 2000 at 12:01:32AM -0500, Andreas Pour wrote: > Jeff Licquia wrote: > > > On Fri, Jan 28, 2000 at 03:00:40AM -0500, Andreas Pour wrote: > > > Jeff Licquia wrote: > > The BSD license places no restrictions on what license you can grant > > to the people you give code to. > > That may be true; but, on the other hand, it does not say that you can > sublicense the > code to anyone else. There is no "inherent" right to sublicense something, > especially > not upon any terms you want; this right must typically be specifically > granted. So it > is not at all clear that you can change the license when you distribute the > source code > to someone else.
This is all true. However, the BSD licensing terms are not being violated, are they? There is no clause in the BSD license that requires me to redistribute under the same terms; it simply gives me blanket permissions to redistribute, subject to these three conditions, none of which say anything about my right to place added restrictions. > How the binary distributors get around this I am not sure, but I > would guess they would argue they have a "compilation" copyright on the > modified binary > work, and since they don't release the source code the issue of the license > under which > the BSD code is distributed does not surface for them. However, that issue > does come > up for you, since you claim the BSD code has to be licensed under the GPL. This is curious. So you think that the BSD license actually discriminates against people who distribute source? At any rate, fortunately, none of that language is to be found in the BSD license. Proprietary vendors are allowed to enforce EULAs on BSD code the same way GPL developers can enforce the GPL - namely, they honor the BSD license's requirements, and then add extra restrictions as they see fit. > > That's why people can make > > proprietary versions of BSD-licensed code. > > Who says they can? Has a court decided this? Has a reputable law firm given > an > opinion? Or is this just your conjecture? I believe that the FSF lawyer has commented on this. And I'm sure that Sun, Microsoft, BSDI, Cisco, SCO, Hewlett-Packard, SGI, Digital/Compaq, etc. have likely received legal advice to the same effect. > Anyway, like I said, their situation is > different, b/c they don't (AFAIK) redistribute the source code under a > proprietary > license; they only do that with the binary form. And so the issue of the > license of > the source code does not come up. The BSD license does not distinguish between the rights you have to the source and the rights you have to compiled binary code. Both are placed under the same license. [Again, this is a peculiar interpretation: that the BSD license discriminates against people distributing source.] > > Now, you can do exactly what you say, remove the GPL-licensed code (or > > whatever) and redistribute under the BSD license if you want. But you > > cannot change the license of the GPLed code. So, if you want to > > distribute them together, you must license the whole under the GPL. > > I'm not sure how this license switching occurs. I guess it would be > fruitless to ask > for some legal authority on this? It's not clear to me at all how my rights > to a body > of BSD code are affected by whether or not you distribute a line of GPL code > along with > it. They aren't affected. But if you distribute the two together, you have to abide by the more restrictive license, which in this case is the GPL. Neither license makes any demands that are not compatible with the other, so it's OK. This in contrast to the KDE situation, where the QPL and the GPL make contrasting demands, and so the code bodies cannot be freely mixed. > Here's an example. There is a body of BSD code which is in separate files and > compiles to a library. You create a "main" function in a file and use it > only to call > one of the functions in the BSD library and display the results. You > distribute the > source code and the binary to me. Now I am to believe that at that point the > BSD code > is under the GPL, but merely by me redistributing that code without your > simple "main" > function it now is reconverted back to BSD? You have it exactly right. > I suppose you can say that you are > distributing the BSD code to me both under BSD and GPL, and I must comply > with both of > them. That's more correct, yes. > Then I wonder, but doesn't requiring me to comply with BSD (the advertising > restriction and the copyright notice) require me to violate the GPL? The copyright restriction and notice restrictions are echoed in the GPL: "1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program." As for the advertising restriction, that is covered by this statement in section 0: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope." > I realize reasonable arguments can be made on both sides of the BSD/GPL > debate. My > view is, maybe its allowed, maybe its not, until a relevant court decides I > don't > know. But I think the same holds true for the Qt/GPL debate, and I don't see > why you > draw a line in the sand with one (on the basis of legal uncertainty) but not > the other. Plainly, licenses do not need the weight of a favorable court decision to still have merit; otherwise, they would be useless in almost all cases. The plain language of the license itself must be considered. If the license says, "you may redistribute however you want as long as you do these three things", then that must be what the license means, barring any court's interpretation to the contrary (due to the requirements of other laws, or something). Another witness that suggests that this kind of licensing is allowed is the fact that many people have made proprietary software using BSD code, and the University of California has not sued any of them. The same is true of people who have GPLed BSD code. In fact, the most guilty transgressor in this way, Richard Stallman, is respected enough by the University that they allowed themselves to be swayed by him, and changed their license to be more friendly to the GPL. With the KDE/Qt license, the plain language of the GPL expressly forbids distribution with more restrictive licenses. Thus the controversy. > > This is no different than, say, Microsoft's Winsock library, or BSDI. > > It's just that far fewer additional restrictions are being placed. > > Has a court upheld the rights of those companies to distribute those products > without a > special license from the authors of the BSD code? Or are you saying > Microsoft is above > violating licenses (Java, Java, Java), or laws (antitrust, antitrust, > antitrust). I > mean, I can also point to the fact that RedHat, SuSE, Corel, etc. distribute > Qt and > KDE. But you argue that is not enough. Why is it enough here? Because the plain language of the license supports this interpretation, where it does not support the distribution of KDE. I cannot speak for most of those companies. Red Hat, I believe, initially refused to distribute KDE for these very reasons; only after Troll announced the QPL did they start distributing KDE, perhaps as a "good faith" reward before the fact. I can only speak for Debian, and even then, only as a person involved with the project (not as some kind of official spokesperson). > You see how this gets confusing. The only way to resolve these issues is to > have a > relevant court decide it. I actually think the KDE/Qt issue is clearer than > this one . The KDE/Qt issue generates a lot more controversy than the BSD/GPL one; I have yet to see anyone argue against BSD/GPL mixing except people with a vested interest in weakening the GPL - which, so far, has only included KDE/Qt advocates. Specifically, I haven't seen anyone with a copyright on BSD-licensed code throw a fit about incompatibilities with the GPL. To my mind, this speaks volumes about the main motivation for this digression. > > Where this makes a practical difference is this: If you link GPL and > > BSD code into a single executable, you must distribute the executable > > under the GPL. The same is true of an archive or package file with > > both kinds of files in it. If you have a program "gpl" that > > dynamically links to a "libbsd.so" (licensed according to their > > names), you can pull "libbsd.so" out and distribute it separately if > > you want, but the two together must be under the GPL. > > Right, I am just curious how you think a person downstream gets a BSD > license. If A > distributes "gpl" to B, and B to C, and C to D, and D to E, how does E then > unpack > libbsd.so and get a BSD license? Who has granted that license to E? It > can't be D, > b/c D received, and distributed, the work under the GPL; and not both > licenses, b/c > they are incompatible. Because the "appropriate copyright notice" mentioned in the GPL includes the full text of the BSD license, meaning that it must be distributed with the system as well. > > The phrase is as follows: > > > > "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." > > > > The previous sentence talks about works that are completely separate > > from the Program. Thus, when you distribute a work including GPLed > > code and separately licensed code as a whole work: > > > > - the distribution of the whole (the Program plus the separate > > component) > > > > - must be on the terms of this License (the GPL) > > This is the key question. It says "on the terms of this License". What does > that > mean? You would have it mean, "licensed as an entirey under the GPL". I > would have it > mean, "in compliance with the terms of this License which apply to a modified > work (ala > Section 2 above)". [sigh] Every other instance of "this License" is a self-referent; it refers to the text you're reading. So: "Activities other than copying, distribution and modification are not covered by THIS LICENSE; they are outside its scope." Up to this point, modification hasn't even been mentioned; does this mean that the following restrictions on modified versions are null and void, because section 0 didn't mention any of them before this statement was made? And: "You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to THIS LICENSE and to the absence of any warranty; and give any other recipients of the Program a copy of THIS LICENSE along with the Program." Are we supposed to only cut out Section 2 and distribute that, and leave out the rest, since this only occurs in section 2? Also, Section 2b says, in part: "...under the terms of this License." If "this" two paragraphs down refers to section 2b only, what does "this" mean in section 2b? Does this mean that you don't really have a license at all, because you can only distribute under the terms of section 2b alone, which by itself doesn't give you any rights at all? Or is the GPL only a BSDish license, since only section 2 applies (we assume that section 1 applies because it's specifically mentioned in section 2)? Your interpretation of this clause make a mockery out of both the GPL and the English language. "This" is clearly a self-referent, both here and the other places it is used. > I think it is a bit strange, don't you, to be coy about the > requirement to license the whole thing under the GPL? If that was the > intent, why was > it not said clearly? It was - for people who really understand English. I find it amazing that such a simple statement like: "...the distribution of the whole must be on the terms of this License..." is so difficult to understand. But it really isn't difficult to understand, is it? Because the whole legality of your project hinges on this one phrase. So it's in your best interest to corrupt, confuse, and obfuscate its meaning. If you can sow fear, uncertainty, and doubt about plain English statements in license agreements, maybe you can convince the rest of the world that sloppy licensing is OK, that only geniuses can deal with licenses. Then, your own sorry, muddled mess is excusable, since no mere mortal can write a license that makes sense. > It's really a pretty big point to require that, you would think > one would not leave the meaning ambiguous. How could it have been done > clearly? > Section 2(b) could state: > > 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 under > this > License, and you must ensure that each part of the whole contains a > statement > indicating > that such part is licensed under this License. This wording would contradict section 1's requirement that all copyright notices be transferred intact. At that point, the GPL would be internally inconsistent, and would be a mess. > It might be worth it for you to read some contracts and see how frequently > the phrase > "on ther terms of this License/Contract/Agreement" is used. And in the bulk > of cases > it does not mean the entire document, but only the particular terms which > apply in the > context to the situation. Really? So if I read a Microsoft EULA, and it states that I can't copy the main executable, and then states that the terms of the contract also apply to the documentation, does that mean that I can pick and choose which parts of the license apply to the documentation? Or is there a rule - if it's mentioned two paragraphs back or farther, it doesn't count "in the context to the situation". Who decides what the "context to the situation" is? You? Me? Some judge? In short, I don't think you are a lawyer, and I don't think you can state with any degree of certainty that "this License" doesn't really mean "this License" when you're writing a contract. I believe that the USA has a law that basically nullifies contract provisions that are, in the court's judgment, too vague for the licensee to know what (s)he is or isn't allowed to do. Were your interpretation correct, what contracts would be enforceable under this restriction? Who gets to determine how much context actually applies? So, if you're going to continue to make this wild claim, I'd like to see some proof. Show me one instance where a licensee could "pick and choose" the terms they like after signing, or where some arbitrary "context rule" was applied to a contract to nullify some condition expressly stated in it. It's not like the GPL is several hundred pages long, and makes reference to other agreements already executed but separately documented, or anything. In that case, confusion might be warranted. But this is a several page text, a large portion of which consists of explanations of the terms rather than terms themselves. Why is it so hard to understand? Oh, yeah. I forgot. It's that little "vested interest" thing again. If you understand it, you have no excuse when you violate it. > > Section 6's purpose is different. Section 2 tells you what terms you > > can distribute under, while Section 6 deals with the rights of the > > recipient - specifically, that they have the same rights you have. > > Exactly. And since you are free to redistribute GPL code w/out paying > anyone, so would > be the recipient, Why? Who says the recipient gets the same rights you do? (That is, besides section 6 of the GPL.) > and all that without regard to the "at no charge" phrase. I'll say > it again: Section 6 renders that phrase redundant, if in fact the modified > work must > be licensed under the GPL. ------ [EMAIL PROTECTED]:~$ cat sect6-gpl.txt 6. 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. [EMAIL PROTECTED]:~$ grep "at no charge" sect6-gpl.txt [EMAIL PROTECTED]:~$ ------ I'm lost. Where does section 6 talk about cost? Are we reading the same license? > > Also note that section 2b contains the same phrase: "...under the > > terms of this License". Even if you gyrate the grammar into placing > > the referent of "this License" at section 2b, you must then define > > what section 2b is referring to by "this License". > > Erhh, I believe I have identified what Section 2(b) refers to by "terms of > this > License" that apply to the modified work, namely the no-charge and the > provide-source-code terms. OK, let me get this straight: The "modified whole" section only refers to section 2b (why the rest of the license doesn't apply, we still don't know). Section 2b only refers to section 2. Section 2 refers to section 1 explicitly, which gives you blanket permission to copy however you want subject to a similar set of restrictions. And, the "modified whole" section requires this license (the parts of sections 1 and 2 above) to apply to the whole and to each part. So, if I add a line of code to a GPLed product, I can nullify all the rest of the sections? Can Microsoft legally tweak, say, Linux in a few weird ways and distribute their Linux kernel without source? After all, section 3 wouldn't apply any more, since sections 1 and 2 are the only sections that apply to the "modified whole", and this new license must be applied "to each and every part regardless of who wrote it", right? You're worried about supposedly redundant language in two different sections of the license, but you're willing to then throw out entire sections to fit your "interpretation" of the license? > The license forXFree says (http://www.xfree86.org/3.3.4/COPYRIGHT1.html#1): > > Copyright (C) 1994-1999 The XFree86 Project, Inc. All Rights Reserved. > > 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. > > So, on the one hand it permits "sublicensing" of the code, so it may seem to > be an > easier case than BSD. But wait -- it does not say you can sublicense under > any terms > of your choosing, it only says you can sublicense. If you dig a bit deeper, > in the > third paragraph it says, "The above copyright notice *and this permission > notice* shall > be included in all copies . . . of the Software". It's obvious what the > copyright > notice is -- the first paragraph. Well, what it the permission notice? It > is the > second and third paragraphs, which state "Permission is hereby granted . . > .". So, you > include all three paragraphs in the copies of the Software, that means "any > person > obtaining a copy of" the X code gets it subject to the XFree license. And > that license > says "any person" can deal with the Software "without restriction". So far, so good. > This is > incompatible with the GPL, under your reading of the GPL, since the GPL does > add > restrictions to the X code (remember, under your reading the GPL has to apply > to the > "whole", which includes, in cases like GTK and many others, the *unmodified* > XFree > source code that it links to -- yes, that's right, the X codeis unmodified, > so there is > no "code mingling" argument to make here). Except that nowhere in the X license does it forbid "sublicensing" - indeed, it explicitly allows it. Anyone can "sublicense" the code under more restrictive terms, as long as they keep the copyright notice. This allows X code to be distributed with and linked to proprietary code. So, for example, I'm sure there would be no problem with taking, say, xterm out of, say, Solaris and redistributing it. However, it would not be OK to take, say, Applix and redistribute that, even though it contains X code. The reason is that you must respect the copyright of all the contributors when you distribute, which (in the Applix case) means you must not distribute. Again, this is common practice in the business world. Many people make and sell proprietary X packages (Metro Link and XInside come to mind) that contain X Consortium code. They are not required to distribute source, or to distribute free of charge; usually, they don't, in fact. The same is true of GPLed code. When you distribute X code separately, you can sublicense it, etc., as long as you keep the notices intact. But when you combine it with GPLed code, you must distribute the combined whole under the GPL. The person receiving the X code has a license to distribute the X code separately under fewer restrictions, but that person must first remove all GPLed code. This is *exactly* the same situation as the BSD situation, even though the BSD license doesn't explicitly give a license to third parties. > So it seems that the sublicensing means, Person A can license it to Person B, > but that > the third paragraph says, the license must be on the same terms as the > original. Please point out which clause in the X license explicitly states that you "must" redistribute under the same terms. The only requirement is that the X copyright and conditions "must" be distributed with the code. > BTW, the phrase "without restriction" in the XFree license is essentially > equivalent to > the Section 6 of the GPL requirement that you not impose additional > restrictions. > Well, the GPL does impose additional restrictions -- it prevents me from > distributing a > binary-only version. XFree does not. The X license says: "Permission is hereby granted...to deal in the Software without restriction, including without limitation..." Notice: no limitations are imposed (except, of course, the copyright notice requirement later on); you are given total rights explicitly. Nowhere does it say that you "may not" do anything other than exclude the notice. By contrast, the GPL says: "You may not impose any further restrictions...". Notice that the GPL is telling you what you may not do, not telling you what you may do. To say it again, even more simply: There is a difference between "You may distribute without restriction" and "You may not restrict other people's distribution" Do you get the subtle difference? > Incidentally, one futher point that complicates your analysis is the > following. The > XFree code (on my machine at least) does not say anything about being > licensed under > the GPL. So, in fact, it is not (even if for the sake of argument I were to > agree that > it could be so sublicensed). And I think the same is probably true of almost > all > distributions, perhaps even including Debian. It does not make any such claim on Debian, either. If you're curious, the copyright file for the XFree86 packages can be found at: http://cgi.debian.org/cgi-bin/get-copyright?package=xfree86-common > So how can you say it's GPL'd? Easy. "When distributing this file as a part of the FooBar package, distribution must comply with the GNU General Public License as well as the X Consortium license." Since distributing under the GPL satisfies all the conditions of the X license, distributing under the terms of the GPL is fine. > I would presume that you at least agree that a user can compile KDE code w/out > violating the GPL? As I said before, Debian does provide such scripts for certain programs that are licensed strangely. For example, qmail cannot be distributed in binary form, and the pine distributors put lots of restrictions on distributing modified binaries. We could, perhaps, provide such a script for KDE; on the other hand, compiling KDE is a much more difficult and lengthy task than compiling pine or qmail, and the script would take a lot of effort to write. Since Debian is a volunteer organization, such a script won't get written until someone feels it important enough to do. The feeling I get is that not many people are so in love with KDE that they are willing to put out that effort. All of this may be moot, depending on what you guys give us with KDE 2.0 in terms of licensing. If this is resolved, I would expect KDE to become a part of woody. But that part is up to you. > > So I can have a functional KDE without Qt? > > How is that an issue at all? Just b/c something requires something else to > work does > not make it a derivative work, at least until they are combined. Look up the > term in > copyright law and show me where it implies that if work A requires work B in > order for > Work A to compile and be executed, that work A is therefor a derivative work > of work > B. The Copyright Act defines derivative work as > (http://www4.law.cornell.edu/uscode/17/101.html): > > A ''derivative work'' is a work based upon one or more > preexisting works, such as a translation, musical arrangement, > dramatization, fictionalization, motion picture version, sound > recording, art reproduction, abridgment, condensation, or any > other form in which a work may be recast, transformed, or > adapted. A work consisting of editorial revisions, annotations, > elaborations, or other modifications which, as a whole, represent > an original work of authorship, is a ''derivative work''. > > Now, how is KDE "based upon" Qt (in the sense of "recast[ing], > transform[ing], or > adapt[ing]" Qt)? It's totally separate code. That is true, trivially. However, source code isn't very useful to me; if I want KDE, I don't want source, I want binaries. And binaries are precisely what cannot be distributed. > > The previous author admitted that KDE incorporates Qt, which is the > > basis that I proceeded on. Trivially, it is true that KDE can be > > distributed without Qt - in source form only. Binaries, however, are > > unusable without Qt in some form, as you yourself admit. > > That is true today. It may not be true tomorrow. And in any event anyone > can take KDE > code and adapt it to work w/ another GUI toolkit. The freedom is there. The GNOME project has worked to provide an alternative desktop, one without the licensing headaches of KDE, and has largely succeeded. So, you don't have to worry; we're working hard to replace you as I speak. :-) Were KDE to remove the dependency on Qt, then KDE's licensing headaches would be over, whether licensed as it is now or with new licenses (that is, assuming you don't replace Qt with some other non-free toolkit). But that isn't happening, and at any rate we can only work with the KDE we have, not a speculative KDE of some distant future. > > Can KDE source code be a separate product from Qt code? It's an > > interesting question. > > Of course it can. That's like asking, can Adobe Photoshop be a separate > product from > Windows. Sure it requires Windows dlls to run, but it obvously is a separate > product. The licenses of Windows and Photoshop don't make any restrictions on how the two can be distributed together, so your example has no merit. Were Photoshop distributed under the GPL, the "system libraries" clause would definitely cover this use, so the question wouldn't be relevant even then. I was talking about the legal definitions applied in the GPL concerning a "work based on the Program". I would admit that it's not a settled question specifically when looking at source code; thus, my statement that "it's an interesting question". > > Were I to package and distribute KDE for Debian, and place it in main, > > then the two would definitely be a unified work, as KDE would not > > function without Qt. > > Copyright does not have this concept of one work not "functioning" without > the other > making them a "unified work". You have made this up. Huh? Where did this come from? Copyright law says that you cannot distribute without express permission to do so. The GPL outlines conditions under which you are allowed to distribute, and then says: " 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it." Thus, copyright law doesn't have to expressly talk about "functionality". Functional or not, you aren't allowed by law to distribute unless you have a license, and the license can refer to any concepts it wants, including (but not limited to) "functionality". If you're not willing to grant basic principles of copyright law, then I suppose we must agree the debate is over. > > However, it means that Debian cannot distribute KDE and Qt together, > > because the licensing contradictions do not allow it. Thus, you admit > > the main problem: that Debian cannot distribute KDE in any way because > > of the licensing mess. Correct? > > The answer is a resounding no, as I think you note a few paragraphs below, > where I > point out a few ways Debian could do it which would work even under your > reading of the > GPL. True. But it would be impossible to distribute a fully functional KDE, or even one KDE app. Correct? > > Case C above is a problem. Without an exception clause, you get into > > the license contradictions. It doesn't really matter that the > > developer "obviously" intended for the library to be linked with Qt; > > copyrights deal with explicit enumerated rights, not inferred rights. > > Why would it be so hard for the developer to put in an exception > > clause? > > Whoaaah, Nelly. Above you were arguing that the BSD license can be > "converted" to GPL > b/c there is an "inferred" right to sublicense BSD code under any terms you > please. > And it would not matter to you, I suppose, even if the BSD license > "obviously" intended > to permit sublicensing under different terms, b/c "copyrights deal with > explicit > enumerated rights, not inferred rights"? One more time: The PLAIN LANGUAGE of the BSD and X license ALLOWS (by inference with BSD, and explicitly under X) sublicensing of the code under the GPL, while the GPL EXPLICITLY DISALLOWS combining with more restricted works. You cannot infer a right that is explicitly disallowed. If I say "you cannot do this" you cannot take other statements I make and say that I "clearly" intended you to be able to do this. The most you can say is that I wasn't being consistent, and it's a toss-up as to which interpretation would be enforced in the courts. But in this case, if you're wanting to avoid a court case, you're best off not distributing at all. > But anyway, that's hogwash. Courts constantly look to the parties' > intentions when > interpreting a contract -- in fact, the goal is to determine what that intent > was -- > and need to draw inferences all the time. You can't read language w/out using > inferences. This is true - but only when something isn't explicitly spelled out, and there are blanket clauses that cover various permissions. If a license says "you cannot do X", then the court will rightfully assume that the license disallows X, even if the license also states "you can do Y, with some exceptions" and Y includes X. There is a question whether the actions of the licensor might contradict the license given, and whether a court might override a portion of the license because it is not consistent with the licensor's expectations, or some such. But let us be clear: this would be an *override* of the explicit license, caused because of the licensor's apparent confusion. And until such an override is issued by a court, we still have no assurance as to which interpretation will prevail, and prudence again dictates that, to avoid a court case, one must not distribute. I find myself again asking the question, "If this is indeed the 'obvious' intent of the developers, how hard can it be to simply make it explicit?" What is so wrong with amending your licenses? (I understand, again, that this is in the works. But it would seem here that you are actually opposed to this move, and that you think it is a bad idea. Why else would you argue so strongly for such weird ideas?) > > We do this already for several programs (qmail and pine come to mind) > > with weird licensing problems. > > > > But this doesn't help Debian; the question of separation is by no > > means settled. Qt is in main, where it belongs (the QPL is > > DFSG-free). If we distribute KDE, then the two are being distributed > > together. At that point, the "system libraries" clause kicks in. > > If you do not distribute binaries, how does the system libraries clause > (found in > Section 3 relating to the distribution of binaries) kick in? Please explain. This is a good point. I may have been in error here, from the perspective of source distribution only. Again, from the perspective of distributing a working KDE system on Debian, this isn't very helpful, but it does provide us a possible loophole. > > "Obvious" isn't something I could rely on in a court of law. If > > that's really what the developers want, let them say so. If they > > don't say so, I don't have the right. > > I hope you take that attitude with the BSD license as well. It does not say > explicitly > you can convert their code to GPL; if they meant to allow it, "let them say > so", > because "If they don't say so", you "don't have the right". Same holds for X > code. "Permission is hereby granted...without restriction, including without restriction the rights to...sublicense...subject to the following conditions:" (from X) "Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:" (from BSD) There, they've said it. I'm given the right to redistribute however I want, subject to a set of conditions that does not affect my ability to add additional restrictions. I'm happy; the BSD and X licenses both let me add additional conditions when I redistribute. End of question. (As opposed to the KDE/Qt situation, where the GPL explicitly forbids distribution with added conditions. Again, if the developers didn't really mean this, why did they put it in, or why didn't they include an exception clause?) Unless, of course, you can point out an exception that's enumerated in those licenses. Where, exactly, is what you're talking about forbidden? > What I meant by pedantic is, why not give your users the option to compile KDE > themselves? In the install program you can warn them, "installing KDE will > take 2 > hourse on a Pentium II 200 b/c we are distributing only the source code". Because no one at Debian feels like putting forth the effort to do so. At this point, this is a prudent measure, as the coming Great Relicensing will (hopefully) make the whole issue moot. I run the GNOME desktop. It is distributed in binary form on Debian, and is installable with a single command on Debian systems that don't have it. From my perspective, it seems foolish to expend so much effort on KDE's behalf when a comparable desktop is already available, especially if the whole problem is a result of stubbornness and a refusal to listen on KDE's part. Now, that doesn't mean I have veto power over someone else's possible efforts. But, I suspect, that most of us in Debian will agree to some degree, which will make it difficult at best for anyone to get such a script into Debian. > > I've seen those arguments. They assume that a corporation does not > > have the rights of a person, and cannot be a signatory to a contract, > > which is an absurd notion. > > Well, then you obviously have not seen my arguments, b/c I have not made such > a foolish > argument. My argument is of course a corporation can sign contract, b/c in > law it is a > separate entity. And, for that reason, when the corporation distributes > something to > its employees, it is a distribution, b/c it is going from one person to > another. That is equally absurd. Under your logic, when a CEO or someone signs a contract on behalf of the company for some service, and some subordinate is responsible for actually executing that contract, the subordinate does not have to follow the terms of the contract, since that person did not sign it him/herself. For example, techs in the IS department do most of the installs of software, including agreeing to the little "click-through" licenses. Does this mean, therefore, that the end user is not bound by any of the terms of that license, since that user didn't click on the agreement? Further, if an explicit license agreement is made up and signed between two companies for some software, and this license agreement states that only Corporation X may use the software, does that mean that the employees of that corporation are still not allowed to use it, since they are not covered by the corporation's copyright? What happens when the signatory of a contract for a corporation leaves the company? Does the company lose the contract? Or are its terms just nullified? What, in fact, does it mean for a corporation to agree to a contract, since the employees are not a part of that corporation? Is an employee only absorbed into the corporation for the few seconds it takes for him/her to write his name on the paper? Also, what does it mean for a corporation to agree to the terms of the GPL? Who, exactly, is doing the agreeing? Is there one person with the "license pumpkin", who is considered "the licensee" for the purposes of the GPL? How do you determine who that person is? And what happens if that person leaves; does the corporation lose their license? Or can they pass the "license pumpkin" along? If so, is it considered "distribution" under the GPL, or not, since (technically) the "corporation" is still the licensee, and has not really "given" the software to anyone when it gives the software to the new "license pumpkin" holder? And, finally, I'm sure that you can quote me some authoritative sources on all this when you give your answers. Some case law would be nice; current legislation would do if you don't have any. > > > And, of course, the provision of the QPL you mention applies > > > only if there is a distribution of the modified code (Section 6(c) of the > > > QPL > > > applies only if the work is distributed). Thus, in both the case of the > > > GPL and > > > the QPL, if you distribute a modified code, you cannot keep it out of the > > > original > > > author's hands (though of course Section 6(c) of the QPL makes it > > > *easier* for the > > > original author to get a copy). > > > > And therein lies an additional restriction to the GPL. Nowhere does > > the GPL *force* me to distribute, while the QPL does. > > Right, but if you support software freedom and giving back, what's wrong with > it? As > stated, the QPL requirement only kicks in if you distribute the changed code > to someone > else. If you did that under the GPL, nothing would prevent the recipient > from doing > the same. What's wrong with it? It's an additional restriction to the GPL. Period. You don't have to agree that something like this is a good idea; the fact that it's possible under the GPL, but not under the QPL, constitutes an additional restriction. > > If I give a copy of my GPLed Qt program to a friend, my friend has the > > right to take it (and the source) and post it on the Internet. But he > > may be someone I trust, and he may decide not to do so if I ask him to > > (not as a condition for receiving the software, but just because he > > wants to accomodate me - maybe it's a pre-test release, or I don't > > want it distributed yet because I can't support it, or whatever). > > But, under the QPL, he can be *forced* to give Troll a copy. > > Why, b/c Troll Tech has a video camera in your room and has seen you > distribute a > copy? Please, this will only come into action in cases like a corporation, > someone > like IBM, that distributes a modified program to all its employees. The > purpose is not > to invade your privacy. Again, this is only true if corporate licenses are invalid, as you assert, which is (to put it mildly) a rather unique interpretation of the law. Also, consider this: I port a GPLed product to KDE, and announce that I will be releasing it "when it's ready" and that I've got a few friends helping me with testing. Or, say, I'm part of a team doing the port (not a corporation, which according to you can't sign licenses that bind its employees anyway), and we all agree that we're not ready to release, but word gets out that we're doing it. Under the GPL, that's fine; we can decide not to distribute yet, and not even the original author can force us. But, under the QPL, Troll Tech has immediate first dibs to the code, whether we want them to have the code or not. So I am clear, I will reiterate that every team member individually would retain the rights of the GPL. I am simply describing a situation where they each choose not to exercise those rights, but end up being forced to anyway. > > > Right, but first this is only true if you distribute a binary of > kgb; a > > distribution of the source code would not trigger Section > 6 of the QPL. > > Why not? > Well, Section 6 of the QPL says: 6. You may develop application > programs, reusable components and other software items that link > with the original or modified versions of the Software. These > items, when distributed, are subject to the following requirements: > So, let's see, application progams are binary, components are binary > and software items that link with the original or modified versions > of the Software are binary. Appliation programs, reusable components, and software items are also source code. Or are you saying that software isn't software unless it's compiled? > Now maybe > Troll Tech meant to say, "software items that are designed to link with the > original or > modifed version of the Software are binary", and maybe that argument would > carry the > day in a court, but as I read it, the source code itself does not "link" with > the > "Software" so it appears not to be covered. No, but it can be, with the assistance of some tools. The tools are called "compilers" and "linkers". Nowhere in the license does it require the linking to be unaided. You're also ignoring interpreted code. What would the status be of a GPLed Perl program that hooked into KDE or Qt? > > > And > > > second, under Section 6 of the QPL, you only have to supply the binary > > > (not the > > > source code) to the original author, which does not do the original > > > author a whole > > > lot of good. And if you really don't want the original author to be able > > > to use > > > that binary, you can password- or key-protect execution. So the problem > > > is only > > > theoretical, hardly something to get agitated about. > > > > This is not spelled out anywhere that I can find in the QPL. If I > > distribute to Troll, why wouldn't condition 2 (that I must provide > > source) apply? > > Hmm, not sure how Section 2 relates to this. Of the QPL? It doesn't. The preamble defines "the Software" as, essentially, Qt itself (in this case). Terms for linking to "the Software" are outlined in section 6, which require source to be distributed and require Troll to get a copy. > > > As I mentioned, Section 6 of the QPL only applies if > > > you distribute a binary. > > > > This isn't clear from the text of the license. > > You are right, if you are determined to read it as applying to source code > you can make > an argument, but the more natural reading is to read it for what it says, not > what you > want it to say, even though, as I mentioned above, courts will often "infer" > things. > In any event, the reality is that I cannot imagine that Troll Tech would sue > you for > distributing modified code to a single close friend (if for whatever reason > Troll Tech > found out about it) if you didn't turn it over to TT, that would be a public > relations > nightmare (not to mention that they appear to lack the disposition for that). And, if your "more natural" reading (in your eyes) turns out to be wrong, and Troll sues me for believing you, I can turn around and sue you and pass on the damages, right? I'm glad that you know the Troll people so well that you feel such trust in them. I don't, so I can only go with what they tell me in their license. And that license contains a restriction that makes it incompatible with the GPL. If you can get a special exemption because you're their good friend, good for you. But how does that help me? > OK, then will you admit that the BSD license, w/ its copyright notice and > advertisement > restriction requirements, conflicts with the GPL? No. It specifically allows me to add the GPL's restrictions to its own. Why is it so hard to understand that: - A requires me to do X, but nothing else. - B, which includes A, requires me to do both X and Y, which do not conflict with each other. - Therefore, if I want to work with B, I must do both X and Y. Now, before this silly digression goes any farther, can someone please tell me what is so complicated about that? Has no one else in this community had to comply with more than one set of rules at the same time? > I don't respect selective recollection and double standards if the Pope has > them, why > should I respect them in the community? The point of a community is that it > grows and > improves, and treating each other with courtesy and respect is an improvement > over > what's been happening. [...] > Well there are certain people who IMHO have double standards who would not be > satisfied. Call me an outcast, call me a geek, I do not bow down to the > majority when > it is wrong :-). So, we're all wrong, and you're all right, and we can't tell you what to do, and shouldn't anyway (since we're wrong), so we should all just go away. And you're really, really confident of this. Wouldn't it be nice if, perhaps, you might work on the assumption that we're all not just a bunch of complete idiots? You talk a lot about respect, and about working together to achieve common goals. Well, then, let's see you practice what you preach. We've got this concern, and well, while we might not have a monopoly on the truth, we certainly believe it quite strongly, including some people who should know what they're talking about. Does it serve the community to say, "licensing isn't a big deal, you don't know what you're talking about, go away"? (This is the point where it feels like I'm having a discussion with a member of the Flat Earth society, or someone who believes Elvis is alive and likes Burger Kings in Wisconsin, or someone who thinks space aliens abducted Marilyn Monroe and JFK so they could have a baby to head the Illuminati who now is a member of the Trilateral Commission. You try to get them to give some proof, and cite some contrasting evidence, but all they seem able to say is, "The National Enquirer said it! It's possible, right?! So it must be true!!!" Sure, I suppose it's possible that the "true" interpretation of the GPL voids out over half of itself, just as I suppose the King could be munching on Whoppers in Sheboygan. But if you want to have an *intelligent* discussion, then you need to acknowledge the facts and address them, instead of simply "proving by repetition" or saying "I think you're wrong, so nyah nyah!") > > As I think I have shown, few to none of these perceptions are as > > clear-cut as you assert. By simply stating that no one's opinion > > counts but yours (as you do when dismissing licensing concerns with a > > wave of the hand), you alienate people. > > Where did I say nobody's opinion counts but my own? By asserting that nothing needs to be done. By using words like "double standards" and "selective memory" to describe those who disagree with you, to say nothing of "wrong". > Am I to take it now that we live > in a fascist open source community where the political views of the vocal > minority > should stop anyone from daring to disagree? Sorry, I don't much believe in > that; when > I say I love freedom and liberty (which is why I support free software), I > mean it. Disagree all you want. You are free to. We won't even require you to make sense when you disagree (good thing for you, eh?) But don't pretend to be a member of a cooperative community when you flame anyone who disagrees with you. If our opinion counts, then show it. You have the power to fix the licensing problems in KDE, real or not. Do it! Get off your duff and get to work! Debian has, in my opinion, done its part in respecting your position. We have a developer who is maintaining a set of KDE packages separately from Debian proper, who has taken the attitude of "I may be getting into legal trouble, but what the hell, I'll take the risk (admittedly small) to help our users and possibly encourage KDE to do the right thing." Another Debian developer worked for a long time with Troll and others to help write the QPL. We stand ready to put KDE into main the moment you fix the licensing problems, and several people have stated that it would be done. Hell, I'll even go out on a limb and say this: If you guys fix the licensing mess (by adding an exception clause to your license for Qt, or switching to LGPL or Artistic, or whatever), and if no one else in the Debian project will then package KDE for Debian, I will do it myself. So, we have done our part. If, after all is said and done, you decide that you don't find our concern worthy of your attention, you are certainly free to ignore us. Don't be surprised, however, when we object to your violating the license to our code (such as the Gimp, or gv, or Emacs, or whatever). Further, don't be surprised when we slight you, recommend your competitors, and refuse to include you in our distributions. But that will be your choice, not ours. > > Are you surprised when you > > meet resistance from these people when you expect to partner with them > > to provide great applications for your project? > > I personally have not met any resistance. Have you? The KDE project has, as I recall. Do you remember the "kimp" incident? The author of gv is, reportedly, just a little miffed as well, although I haven't heard him say anything directly. > I am not in a position to address your concerns. But what I can do is point > out your > concerns are hypocritical and don't deserve to be addressed. Such a "partnering" attitude. "You hypocrite, why should I even talk to you?" And you get all pissed when we call you names. How black am I, Mr. Pot? > There is a difference > between respecting differences of opinion (which I do), and bowing to a vocal > minority > which I believe to be wrong. And that difference would be? You can't be tolerant and divisive at the same time. If you want to be seen as respecting a difference of opinion, it helps to actually give a little respect to an actual difference of opinion. By the way, you have an opportunity right now, just in case you hadn't noticed. > If you honestly believe you are doing nothing wrong, > there is no reason to change just b/c someone says you should (and in most > cases the > people saying it have hardly a clue what the GPL in fact says). There is, in fact a very good reason to change even when you think you're right. It involves respect, and a desire to put little differences in the past by addressing concerns that you may consider petty, especially when the resolution affects very little in the long run. > And incidentally, I do not get the feeling that the opposition to KDE would > stop just > because a clause is added to the GPL licensing statement stating what is > entirely > obvious (that you can link with Qt) Perhaps not. There are nuts in every group. But you most certainly would silence the large majority of your critics. You would silence me, for example; I would likely switch over and become your defender, as would many other people. And I think that, over time, the nutcase minority would eventually die down after tiring of trotting out old rhetoric that no longer applies, and being told so again and again. But, then again, you won't know until you try it, will you? Do you think it worth a try? > > Neither would there be a need for this mudslinging if your developers > > would do the one thing that would end the fight - change your > > licensing to fit "assumed" practice. > > I suppose it is possible to do that with the understanding that the > developers are not > doing it b/c they need to for legal reasons, but b/c it would make certain > others happy > if they did. Exactly! You understand at last! I don't care if you all issue a press release stating that your licensing change was done to address some concerns by third parties and not for any real legal reasons. At that point, the question would be academic. What matters is that the change has been made, and we no longer have reason for concern. > This does raise an issue about some third-party GPL code that has wound > its way into KDE, which is not as easy to solve. It is my understanding that many of these projects would not mind writing an exception into their license allowing you to link with KDE, if you were to ask. The GPL explicitly allows for this in section 10. Who knows? The FSF even admits that it makes exceptions to the GPL when it feels that free software will be helped. Maybe they would even let you make a "kemacs" or some such. > But the bigger issue is, what > assurances/guarantees can you make that if this change is made, all of this > anti-KDE > fervor will go away? It's simple. If we list concerns 1, 2, and 3, and you meet these concerns, we're happy. As stated before, we can't control everyone. And it's possible that others may have other valid concerns; you might want to outline a plan of action publicly so others can comment and alert you to other concerns, to ensure that all bases are covered. Debian can play a part in this. For better or worse, Debian has a reputation for being very picky about licensing. Our Debian Free Software Guidelines (and their derivitive, the Open Source Definition) are nearly universally recognized as a standard litmus test for freeness. If we release a stable Debian version with KDE included in main, that will, I think, go a long way to "legitimizing" KDE in the eyes of many of your detractors. > > At the same time, you are (were) doing horrible things to that same > > community. By establishing the precedent that "licensing doesn't > > matter, only code counts", you were working to destroy the legal > > foundation that supported the amazing innovation happening in the Open > > Source community. > > Hmm, I don't agree. AFAIK it wasn't a matter of "licensing doesn't matter", > it was a > matter of "we don't see a licensing problem". Today, you might be able to make that statement (although, as I think I've shown, it isn't a slam-dunk by any means). When the KDE project started, you could not. The old Qt license was much more restrictive, and linking GPLed code to it caused a great deal more incompatibility than a concern about Troll's right to force you to distribute. Since that time, KDE has done a few things to alleviate the problem. The QPL is a gift to the free software community; there is no doubt about this. But this does not change the fact that, when you started out, you threw the entire licensing question into turmoil. No one could legitimately claim that the old licensing situation was not completely unacceptable. > You should take to heart that virtually every lawyer that has looked at the > GPL has > grave doubts about its enforceability and about what it means. So why > doesn't FSF > release a new version that clarifies the issues? Then whoever wants to can > use the new > version. Is that so? I notice that you don't give a cite. Actually, there is some pretty strong evidence to the contrary: - The GPL was drafted with the assistance of a highly respected legal scholar. - NeXT, when faced with a legal challenge based on the GPL, backed down rather than take the issue to court, and released their huge proprietary investment in gcc under the GPL. - It has been reported in at least a few cases that legal departments have forbidden use of the GPL for their companies' intellectual property, under the fear that they would lose control of it. - Other companies are using the GPL as a shield against proprietary exploitation of their intellectual property when they release it. Again, all of this is simply a dodge. You have said that you believe in the principles behind the GPL. Do you serve those principles best by attempting to destroy the GPL? Are you consciously violating the GPL, in the hopes that it will be invalidated? > > Your precedent could have (and still may) be used > > against us at some future time to attempt to show "intent" in free > > licenses that would have perverted their real intent. > > KDE was not the first precedent. Motif. BSD. XFree. And probably others. > Those > were the first. What happened in some people's judgment is that suddenly a > small set > of community members changed the rules when KDE opened shop. I have gone over the issues with those licenses already. You are grasping at straws, attempting to justify your behavior by pointing at others' "equally bad" (in your eyes) behavior, all the while refusing to cite any proof for your statement. > > If you are angry about that, the BSD license is not the one you want > > to use, since it allows far worse. > > Better or worse is a moral judgment, and I may not agree with yours. I may > want all > users of my code to have complete freedom with it, rather than comply with > the GPL. As > an author that's my decision to make, not anyone else's. If you want your users to have complete freedom, then you want them to be free to add restrictions to your code so it can be combined with code under more restrictive licenses - including the GPL. If you don't want your licensees to be able to restrict the freedom of others by combining it with more restrictive code, then you need a license which forbids that. The GPL is one of those licenses, but the BSD license is not. You don't appear to have any clue what you really want. You've said that you might want: - a license that is completely free (like BSD) - a license that is completely free, but only to people who make the code proprietary; one that discriminates against people who like to distribute source - a license that is free, but requires it to be free forever (like the GPL) - a license that is free, except that it expressly can't link to GPLed code So which is it? You have the right to do what you want, but you must be able to coherently express your wishes before we can respect them. > > If you want to allow either total BSD-like freedom or complete > > proprietariness, you should write a license that forbids any middle > > ground. It strikes me as odd that someone would be pissed about the > > GPL's restrictions yet be perfectly cool with a complete loss of > > freedom. I suppose that it takes all types. > > Well, if you looked around you will see that a bunch of people, including the > *BSDs, > still use the BSD license. Under your theory they could convert it to GPL at > a whim, > but have not done so. So what kind of "type" are they? My guess is that they are the kind of people who want to allow total freedom, including the freedom to go proprietary or cooperate with GPL code. I don't have a problem with that, and neither do they. Is it our problem that you have dug yourselves into a hole, and seek to save yourselves by dragging all of us down with you?
