Re: KDE not in Debian?
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.
------
jeff@server1:~$ 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.
jeff@server1:~$ grep "at no charge" sect6-gpl.txt
jeff@server1:~$
------
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?
Reply to: