Re: KDE not in Debian?
Hi,
I apologize for any typos/grammar problems, I did not error-check very well . . .
Jeff Licquia wrote:
> 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.
I think you stated at some other point that if a right is not granted you don't have it. I
think we agree that under copyright law you normally do not have a right to make copies and
redistribute. The BSD license says you can redistribute. To go from that to say you can
redistribute under any terms, rather than continuing to distribute under the original terms,
you want is IMHO a stretch. Maybe a court would rule so if the situation arose, but as you
appear to be concerned about the threat of a lawsuit and/or complying with a social contract
I would think this uncertainty would trouble you as well.
Now in the case of UCB code in particular, IIRC they may be on public record as not
objecting to such redistributions, but that does not mean all authors who use the BSD
license concur. I would note as well that KDE developers are on public record as not
objecting to distributing their code with Qt.
> 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?
If you want to call it that.
> 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.
IIRC they don't distribute source code, please correct me if I am wrong. In any event,
insofar as the vendors have added their own source code, they can license that under another
license, and this will prevent redistributing the combined binary, but it is not b/c the BSD
code is under the proprietary license, but b/c the vendor's code is. As I understand your
argument, you require the BSD code to be licensed under the GPL as well. That's obviously a
different situation, as the vendors don't license the BSD code under a proprietary license,
only their additions to it. In the case of a binary, they are inseparable, and you cannot
distribute a "derivative work" without the consent of both the original author and the
person who modified it, so you would need the consent of the vendor (since BSD consent is
already there). But, again, the key point is, the vendor does not AFAIK put the BSD code
under a proprietary license, only their additions to it.
> >> 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.
RIght, but I think they operate under the view that their own code is proprietary, they do
not need to claim that the BSD code is proprietary (i.e., under a different license). In
your view of the GPL, that's not the case, since you insist that the BSD code itself -- even
if there are no changes -- has to be licensed under a different license, namely the GPL.
> > 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.
True. Think of it this way. I put together a book with two essays in it, one which is
copyrighted with all rights reserved and one which is in the public domain (i.e., free for
anyone to redistribute). Or let's say I write an annotated version of Plato's The
Republic. I can then put the combined work under a proprietary license -- i.e., you cannot
redistribute the book without my consent. However, that does not take Plato's work out of
the public domain and does not subject Plato's work to my proprietary license -- my license
applies only to my additions. This is how the vendors do it.
But under your reading of the GPL it is different. You claim it is required that I also
distribute Plato's The Republic itself under the GPL. That's the part I don't buy.
> [Again, this is a peculiar interpretation: that the BSD license
> discriminates against people distributing source.]
Not really. If the vendor distributed the source the vendor's contribution could be kept
proprietary, all I am saying is that the vendor cannot change the license of the BSD code
itself.
>
> > > 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.
With that I would agree, at least for the GPL code. I have no problem agreeing that the
combined work can only be redistributed under terms of both licenses. The problem only
arises under your stated interpretation of the GPL which requires that the BSD code itself
must be licensed under the GPL, that's what I do not agree is permitted by the BSD
license. In my view, if you distribute combined GPL/BSD work, you distribute the BSD part
under the BSD license and the GPL part under the GPL license. But your reading of the GPL
also requires the BSD part to be licensed under the GPL, and I do not agree that is
possible. (Well, it might be, I just don't think it's likely a court would rule that way.)
> Neither license makes any demands that are not compatible
> with the other, so it's OK.
You neglect the advertising clause of the BSD, which imposes an "additional" requirement
over the GPL. Thus, you cannot distribute a combined BSD/GPL work without violating the
GPL, since the BSD license imposes a requirement which the GPL prohibits. I should point
out that the two licenses would not be incompatible except for Section 6 of the GPL, which
states:
You may not impose any further restrictions on the
recipients' exercise of the rights granted herein.
Since the BSD imposes a further restriction -- the advertising restriction -- you cannot
distribute the combined work together without violating the GPL (that is, under your reading
of the GPL, under my reading it's not a problem).
[ ... ]
>
> > 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:
[ ... ]
I think you are right, I was a bit off-track with the copyright notice.
But the advertising restriction is still incompatible.
> > 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.
That's true for well-drafted licenses. Poorly drafted/ambiguous licenses -- i.e., licenses
that reasonable people can disagree on -- are exactly that, and until a court clarifies them
it is difficult to know what they mean.
> 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).
Right, but first the BSD license does not say "however you want", and second the right to
sublicense usu. must be explicitly granted.
> 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.
That means either that UC does not care, or that it thinks it cannot win, or perhaps
something else. I think it's the former, and, IIRC, UC at some point publicly said people
could do it, so that means by the equitable principle of 'estoppel' or the legal principle
of 'detrimental reliance' they probably cannot change their mind now. But that only applies
to BSD code authored by UC, as not every author of BSD code has made the same public
announcement.
> 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.
You mean to not pose the incompatibility problem with the advertising clause. In any event
it seems that even RMS believes the advertising clause makes BSD incompatible with the GPL.
> With the KDE/Qt license, the plain language of the GPL expressly
> forbids distribution with more restrictive licenses. Thus the
> controversy.
And the BSD code probably does the same.
[ ... ]
> > 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.
Would you care to explain to me my "vested interest in weakening the GPL"? All I am doing
is offering my interpretation of it, guided by its structure, by logic, and by its
historical use. I have no interest in weakening the GPL, I am only interested in
understanding it. The fact that it does not say what you would like it to say, and the fact
that under your reading you cannot mix BSD/GPL or XFree/GPL, is not my fault. I don't avoid
the truth b/c I don't like it. Talk to RMS, he wrote the GPL, and he can change it as well.
> Specifically, I haven't seen
> anyone with a copyright on BSD-licensed code throw a fit about
> incompatibilities with the GPL.
You're right, most people don't throw a fit, some contributors to the kde-licensing list
excepted. But that does not mean there is not a problem, it means the authors of BSD
software don't care. And I am sure they don't care if GPL code is mixed with BSD code b/c
it does not violate the BSD license -- it only violates the GPL (at least under your reading
of it).
> To my mind, this speaks volumes about the main motivation for this
> digression.
I don't mean to repeat myself, but I will tell you my motivation again. I started using
KDE, liked it, was impressed. Then I heard a bunch of people saying, KDE is unlawful/blah
blah. And I asked why? They pointed to the GPL. So I read it. I read it many times. I
spent days reading it. It's not a work of great legal draftsmanship, but I tried really
hard to understand it. And when all was said and done, I came up with my understanding that
I am posting here. There was no motive other than the search for the truth.
My motive for writing now is, I was browsing through kde-licensing a few days ago, and there
were some really, well, vicious posts about KDE developers, blah blah. Since I do not see
such fighting to be of benefit to the community, I am writing in defense of (what I see as)
the truth.
[ ... ]
> > 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:
Right, but to do something under the terms of this License does not mean you have to be
licensed under this license. Here's an example. Let's say I write code and give you an
EULA. There is a provision in the license which states where you send notices, how you send
them, etc. (e.g., must send by first class mail to a particular address), in case notices or
any other thing is required to be sent. There is another provision that says, if you make
any changes to the code you have to "provide" me with the code "under the terms of this
License". OK, in that case, what is meant is that you have to notify me in compliance with
the notice provisions, it does not mean you have to license the changes under the same
license. The key is that by saying "under the terms of this License" you don't specify
*which* terms. To figure out which terms apply you have to use "inferences" from the
language, context, structure of the document, etc.
> "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?
No, I think in that case it is clear that you should copy the entire License. But here is a
more interesting case from Section 7:
If, as a consequence of a court judgment or allegation of
patent infringement or for any other reason (not limited to
patent issues), conditions are imposed on you (whether
by court order, agreement or otherwise) that contradict
the conditions of this License, they do not excuse you
from the conditions of this License.
I think here you would agree that by "contradict the conditions of this License" it is meant
that you contradict *any* of the conditions of this License; it is not required that all the
conditions be contradicted for you not to be excused. This is by way of showing that a
reference to "this License" does not always mean the entirety of the License.
[ . . . . ].
> 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.
I'm not trying to do that, but thanks for asking.
> 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.
Actually, my efforts would more likely have the opposite effect. If in fact the license, as
I read it, is not how it was intended to be written, then this is an alarm bell that should
signal the FSF to fix this mistake. Better now than when, as will eventually happen, the
GPL goes to court.
> Then, your own sorry, muddled mess is excusable, since no mere mortal
> can write a license that makes sense.
I have read many licenses that are clearer than the GPL. The NPL is an example of a license
drafted by good lawyers. I don't think you'll find such ambiguities in there.
> > 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.
Oh, now wait, I'm not sure what your position is. Are you saying that the BSD/XFree parts
are still licensed under BSD/XFree? I though you were arguing that all the code had to be
licensed under the GPL. Now I am confused what you mean . . . .
[ ... ]
> 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 wasn't saying that. The language we are referring to is "terms of this License", and the
question is which "terms". For example, if I say you have to drive you car "in accordance
with law", it is obvious I do not mean all laws, only the laws pertaining to driving a car
(e.g., I would not be saying that you cannot listen to a bootleg CD while you are driving,
although that would violate some other non-driving-related law).
[ .. . ]
> > > 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.)
Precisely Section 6 -- it says the recipient gets GPL rights; the rest of the document (like
Sections 1-3) specify what those are, and those permit you to redistribute without paying
anyone.
> > 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?
Yes, we are. OK, here's the logic. Section 6 says the recipient receives the code under
the GPL. Sections 1-3 say the recipient can redistribute/modify, without paying anyone.
(In fact those sections do not say you do not have to pay anyone, but they do not say you
do, and requiring someone to pay you would be a "further restriction" prohibited by Section
6).
If you are seriously arguing that, but for the no-charge provision in Section 2(b), the
distributor could charge a fee for redistributions by the recipient, then you would also be
saying that if someone distributes code under Section 1 (which does not have any no-charge
language) they could charge the recipient a fee for further redistributions. You are not
saying that, are you? In fact, Section 1 explicitly states you can charge a fee for the
transfer to the recipient. If Section 6 does not guarantee that the recipient can then
redistirbute w/out paying, then there is a large "loophole" in the GPL, isn't there?
So, tell me, why do you think that the "no-charge" language is needed in Section 2(b) but
not in Section 1, if in fact the entire work has to be licensed under the GPL?
> > > 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
Which is 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.
You have not understood what I have said, perhaps you can read it again.
> So, if I add a line of code to a GPLed product, I can nullify all the
> rest of the sections?
That's not what I said either. The GPL code still remains under the GPL; it is only the
added code which does not have to be licensed under the GPL but only has to comply with two
provisions of the GPL (the no-charge and the distribute source provisions).
> Can Microsoft legally tweak, say, Linux in a
> few weird ways and distribute their Linux kernel without source?
No.
> 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?
Section 3 says if you distribute a binary which includes any GPL code you have to release
the entire source. You lost me. As to the GPL applying to each and every part, it does; it
just applies in different ways to the GPL's code and the added code, as I've explained.
> 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?
AFAIK I am not throwing anything out, and so far you have done nothing to convince me I
have.
> > 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.
Whooaahh, that is a *long* jump to make. The fact that someone authorizes you to sublicense
does not imply that you can sublicense on any terms you want. But more to the point, the X
license specifically states under what license you must sublicense, namely, the XFree
license.
> This allows X code to be distributed with and linked to
> proprietary code.
Sure it does. And that's why under my reading of the GPL you can link GPL code and X code.
But your reading requires you to sublicense the X code under the GPL, and that is not
permitted.
> 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.
Right, but that is a restriction of the Applix code, not the X code (remember my two-story
book and annotated Plato book above?).
> 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.
Exactly!
> 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.
Right, it's a combined work.
> 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.
Right, but it's not just a notice, it's a *license*. Right? It has to be -- if it were not
a license, nobody could copy X code and redistribute. The reason you can is b/c of the
license (which you are referring to as a notice, but don't be confused by the term), which
is quoted above. And the interesting part of the license for this discussion is it says you
have to include the license in all redistribution of the X code. Do you think you have to
do that as an adornment, or b/c X wants to make the file longer? No, you have to do it b/c
that is the license the X code is under when you sublicense it.
And by the way, for the X distribution to work they have to include the sublicensing
provision. Contracts always require a "chain" to the person granting a right. E.g., if
A writes code and gives it to B, and A tells B he can redistribute it, B can distribute to
C, but then that's the end of the line; C lacks the permission to redistribute, b/c only B
got the permission from A. The way the X license deals with it is it tells B that B can
sublicense to C (under the same license, of course), and that way now C can further
redistribute to D, etc.
> But when you combine it with GPLed code, you must
> distribute the combined whole under the GPL.
Under your reading of the GPL, yes. But since you cannot do that with X code -- as you must
sublicense that code under the X license -- your reading prevents linking with X code.
> 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.
Sure, but that still does not mean that the X code was ever licensed under the GPL, and in
fact it can't be.
> 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.
Gladly. Paragraph 3, which says:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
I think you are confused b/c of the term "permission notice". The permission notice is a
license. Before you disagree with that, bear in mind that without that permission notice --
errrh, license -- you could not redistribute the X code at all.
> > 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.
Right, you have to include the license. Obviously you have to include it for a reason,
right? B/c the person you transfer to gets the code under that "permission notice"/license.
> 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.
The X license tells you what you *must* do. Note that the requirement to include the
license is one of the conditions to being able to sublicense. So the X license says, in
essence, "you can sublicense this code, but only if you include our copyright and our
license with it". Now how you can read this to mean you can sublicense under any terms you
want is a huge stretch of the imagination.
> 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?
I do, but your first clause happens to omit the conditions subject to which you can
distribute without restriction.
> > 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."
Obviously when you distribute the combined work you have to comply with the copyright on all
its parts. We don't need the GPL to tell us that. The whole point of this debate we are
having is not whether you have to comply with both licenses, b/c you obviously do. The
question is whether the GPL requires that the "new" code -- what is added to the GPL code --
be GPL'd (your reading) or whether it just requires that the "new" code must comply with the
no-charge and source code provisions (my reading).
> 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.
It's been done. Just take the script that was used to make the existing KDE packages; I am
sure this is automated and if not can be quite simply since KDE makes heavy use of configure
scripts (basically its "for package in [PACKAGE_LIST]; do ./configure; make; make install;
done)".
> 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.
Have a look at ftp://ftp.us.kde.org/pub/kde/stable/1.1.2/distribution/deb/ and
http://ftp.workspot.com/pub/kde/debian/.
> 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.
"hehe, hehe, hehe, he said 'woody'." (Butthead).
> > > 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.
Well, even if they could not, like I said, it can be scripted, and if the user doesn't mind
waiting, why would you object? Clearly Debian uses want KDE -- Corel Linux and Stormix
prove that.
[ ... ]
> >
> > 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?
You could, even under your reading, distribute Qt libraries and the KDE libraries (kdelibs
and kdesupport) as binaries. You could then have a script to compile the remaining KDE
packages. In fact, to speed things up, you could do all the "configure" stuff and generate
the makefiles in advance, and perhaps even generate the .o files, and save only the
remaining work (which w/ .o files would be trivial) for the install phase.
[ ... ]
>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?)
No, I am not opposed to the move at all. I just don't have any control over it, not being
the author of any of the code in question. And I am not arguing for something as much as I
am defending people who in my judgment have been unfairly slandered.
[ ... ]
>
> > > 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.
That is not absurd, that is the fact. The company has to comply, not the subordinate. Now
a company, being an inanimate entity, can only act through agents; the subordinate is such
an agent. The company complies by having its agent perform the task. That does not make
the agent liable if the terms of the contract aren't followed; only the company is. (And
that's a good thing, b/c otherwise if you screw up on fulfilling a customer's contract you
would get sued personally).
> 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?
Well, that is a very interesting question. One way you could look at it is that the tech
was installing the license as the agent of the user, and clicked the license acceptance as
the user's agent. But that is unlikely to hold up the court. Suppose the license had a
provision in it that says, "You will pay a usage fee of $5/hr for each hour you use the
software". Now the user, unaware of this clause, uses the program for 2000 hours. Do you
think the *user* now owes the $10,000 to the software author? I think not.
Another way to look at it is that the tech agrees to the license as agent for the company,
so the company is the licensee; and as licensee the company lets its agent, the user, use
it. In that case the company, which presumably is aware of the $5/hr usage fee, would owe
the $10,000. Make more sense?
> 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?
We were talking before about "inferring" rights. Well, a corporation obviously can not use
software, since it is only a legal entity. So the court's would try to make sense out of it
and would permit the corporation to exercise those rights through an agent. Most
sophisticated licenses skip this inference step and specify how many users can use the
corporation's license (e.g., an NT server license).
> 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?
[ ... ]
> 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.
This is all covered by "agency law", look it up in a book if you are interested, it's quite
standard and, at least to the extent of your questions, non-controversial.
> > > > 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.
Right, and it is possible under the GPL to put an ad in the paper saying "this software
includes YYYY which was written by XXXX" w/out explicit consent, but not under the BSD.
[ ... ]
> 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"?
I don't think anyone on the KDE side is saying licensing is not a big deal; I think they
believe they are complying with relevant licenses.
Now why don't people make the change you suggest? Well, I can't speak for anyone, but I
presume it is the following reasons.
(1) In various places, there is GPL'd code in KDE code. Nobody knows exactly where it
is; could be a line here, a line there.
(2) Even if all the lines of GPL'd code could be identified, in many cases it will not
be clear who to ask for permission; an e-mail address may be invalid. As long as not
everyone that's an author agrees, the license can't be changed (I actually don't think it
would be a material change, though you seem to think it would be, but not even an immaterial
change is allowed w/out the author's consent).
By the way, the code is not limited to core KDE developers and code taken from
pre-KDE projects. It would also involve every single patch submitted by users (including
yours truly). Those people submitted patches when the code was under the GPL, so by
inference their code is under that license as well.
(3) Some KDE developers just won't do it, I won't get into reasons why but AFAIK they
don't believe they are violating the GPL. Nobody can force them to.
(3) So presumably there are some projects where it is known for certain that nobody
submitted a tiny patch (knowing all the while that it would be linked to Qt) and the authors
are willing to change the license. If the license is changed on those, an implication
arises that there was a need to do it, which throws into deeper question the status of the
other files (I can hear the arguments already -- "But they changed the license on
this-and-that project, that must mean they know it was wrong").
[ ... ]
> > > 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".
I'm sorry if I offended you or anyone, that was not my intent. Everyone is hypocritical
from time to time; I admit I am. But when someone points out my hypocrisy I will fix it.
To respect a difference of opinion does not mean you don't think the other person is wrong.
A concrete example being religion. I may respect your different religion, but yet think it
is wrong (in fact many religions are exclusive that way). As it is in this case: I respect
your right to hold your opinion, I would not want to punish you for it and I do not think
you are a bad person b/c you hold it (i.e., I respect it), but I still think it is 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.
Again, sorry if I flamed anyone. My goal was only to respond to the rather provocative
flames which were being spread on these lists about KDE and its developers.
[ ... ]
> 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.
Finding a packager is not a problem; they already exist. The problems, as I see them, are
outlined above.
> 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.
I'm obviously giving your concerns a lot of attention. The change you are requesting is not
as easy to make as you seem to think. And on top of that neither I nor AFAIK the KDE
developers think the GPL is being violated
> 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).
AFAIK, whenever a *real* objection has been raised, it has been dealt with appropriately.
Kgv and Kfloppy are no secret, and nobody has complained. I would guess that, even though
KDE developers might think they could distribute those apps if the authors objected (b/c
permitted by the GPL), they would not.
> Further, don't be surprised when we slight you, recommend your
> competitors, and refuse to include you in our distributions.
I'm way past being surprised.
[ ... ]
> 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.
Well, if you really mean that, I put it to you that it would be a lot easier (given the
problems I noted above about changing the KDE license) for Debian to distribute KDE-2.x as
is than it would be for KDE to get all the consents you request. So if respect is a two-way
street, why should not the side with the much easier task of showing respect be the one to
do it? Perhaps b/c Debian developers do not respect KDE developers' views?
> > 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?
Like I said, given the complications noted, it is likely that many KDE packages would be
lost. AFAIK a not-insignificant number of KDE programs have patches from authors who KDE
developers could not locate if they had to. That is, if those patches could even be
identified.
> > > 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.
Right, but making the change could easily raise new legal problems -- suddenly two months
later someone who submitted a patch in KDE beta 0.89 says, hey, you can't do that. And the
KDE gets flamed for changing someone's license w/out permission, etc.
[ ... ]
> > 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.
Under my reading neither license is a problem.
> 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.
I have claimed that.
[ ... ]
Ciao,
Andreas
Reply to: