[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: KDE not in Debian?


OK, looks like at least one more round . . . .

Jeff Licquia wrote:

> [whoops - wrong lists for last message - fixed - sorry]
> On Fri, Jan 28, 2000 at 03:00:40AM -0500, Andreas Pour wrote:
> > Jeff Licquia wrote:
> >
> > > True.  However, the BSD license allows relicensing (sort of), as long
> > > as its terms are respected.  So, technically, those BSD files are
> > > GPLed when distributed with the GPLed project, as the GPL requires.
> > > BSD (at least the new one) doesn't enforce any restrictions beyond the
> > > GPL, so you're OK with this one.
> >
> > Errh, I keep hearing this misconception that BSD code can be relicensed as GPL
> > code, but can not figure out where it comes from.  How can you re-license BSD
> > *source code* as GPL code?
> The same way you can re-license it as proprietary code.  See below.
> > The author of BSD code has told me (and everyone else for that matter) that I can
> > redistribute it w/out following the requirements of the GPL (all I have to comply
> > with is the far fewer conditions placed in the BSD license).  Now you want to tell
> > me that, by virtue of someone adding a line of GPL code to it, that the whole kit
> > and kaboodle has been converted to GPL and I can no longer do what the author of
> > the BSD code told me I can do (namely, redistribute it without complying with the
> > GPL)?  Well, if you try to do that, I can remove that line of code and say forget
> > you, I will distribute the code in compliance with BSD but in violation of the
> > GPL.  And what is your remedy for this act of mine?  Can you stop me from doing
> > it?  No, obviously not.
> You are mostly correct.
> 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.  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.  Now, if you
truly mean what you said below -- namely

    Debian doesn't have millions of IPO dollars to finance a legal fight.
    And our actions can affect our distributors as well.  Therefore, we
    have to be careful.

-- then this uncertainty should stop Debian from distributing mixed BSD/GPL code as
well.  Or do you have a legal opinion or reasoned legal analysis from reputable law
firms that tell you that you are permitted by law in all legal jurisdictions where
Debian distributes mixed BSD/GPL code to so re-license the BSD code?

Anyway, my case is a lot easier to make with the X license, which I mentioned in one of
my other mails to this list and I repeat below, as that does explicitly state what
license you may redistribute under, and it ain't the GPL.  And clearly Debian
distributes X code linked with GPL code.

> 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?  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.

> 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.  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?  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.  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?  Ahh, but you may
say that is only a technical violation.  But, to quote you from below in this e-mail,

    How great does it have to be?  "She's only a little pregnant."

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.

> 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?

> > What does that mean?  That the GPL does not apply to the
> > "modified work as a whole" -- i.e. to the BSD code.  That is, the BSD code is not
> > under the GPL.  This is so obvious, I find it hard to believe people keep
> > spreading this interpretation of yours as if it were true.
> No - the work *as a whole* is under the GPL.  You can distribute the
> BSD pieces separately under the BSD license, but you can only
> distribute the whole under the GPL.

OK, I was thinking the BSD license is incompatible with the GPL license ((the part in
Section 6 which says "you may not impose any further restrictions on the recipients'
exercise of the rights granted herein") b/c of the copyright notice requirement and the
advertising restriction.  Now, if you distribute the "whole" to me, you cannot have it
both licensed under the GPL and the BSD, since the BSD would require me to do something
the GPL forbids.  Thus, I have to choose a license, I guess, and then when I
redistribute it to a third party, the code is no longer under two licenses, right?

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 .
. .

> 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.

> > > > But, for the sake of argument, I am distributing Qt
> > > > as part of the whole. So I have to make the distribution "as a whole" be
> > > > under the GPL. I have done so.
> > >
> > > Not Qt!  Qt is still under the QPL, not the GPL, and there is no way
> > > to "mesh" the requirements of the QPL and the GPL coherently.
> >
> > Well, your BSD code is still under the BSD, regardless of the sophistic
> > interpretation you offered above, and so there is no way to "mesh" the
> > requirements of the BSD and the GPL coherently.  Meaning that under your
> > interpretation you cannot combine BSD and GPL code (or X and GPL code, for that
> > matter).
> Such nice words - "sophistic".  Is this an example of the fool, who
> "knows not, and knows not that he knows not"?
> Per BSD, I have preserved all copyright notices, so I can distribute;
> this requirement is also explicitly mentioned in the GPL.  Since the
> whole is licensed under the GPL, I can assume that I've met the
> requirements of the GPL.
> Where's the problem?

I think I've raised numerous problems and uncertainties.  Certainly enough to worry
someone w/out millions of dollars of IPO funds ;-).

> > > > Section 3 allows me to distribute
> > > > binaries of kgv, if I follow sections 1 and 2.
> > >
> > > Since you aren't following section 2, you can't distribute binaries.
> > >
> > > > I am making available the
> > > > complete source code for kgv as well as Qt.
> > >
> > > Irrelevant - you still haven't followed section 2.
> >
> > There was a long debate about this a year ago on this list.  Section 2 does not
> > require all the code to be "licensed under the GPL" -- it only requires it "to be
> > licensed as a whole at no charge to all third parties under the terms of this
> > License".  Well, 2 questions come to mind when reading that language:  (1) what
> > does the phrase "under the terms of this License" mean? and (2) what does that
> > phrase modify?
> 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)".  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'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
    or is derived from the Program or any part thereof, to be licensed as a whole under
    License, and you must ensure that each part of the whole contains a statement
    that such part is licensed under this License.

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.

>  - whose permissions (the GPL's permissions) for other licensees
>  - extend to the entire whole (the Program plus the separate
> component)
>  - and thus to each and every part (the Program, and the separate
> component, each on its own) regardless of who wrote it.
> It is therefore clear that the whole work must be licensed under the
> GPL, according to this clause, or you cannot distribute the parts as a
> whole.

Not clear to me; I think it's clearer the other way, actually.

> I do not see how your other interpretations can be extracted from the
> plain English in the license.  As I mentioned above, the license
> explicitly states that the GPL must extend to the whole and to every
> part independently.

Right, but which part of the GPL?  All of it -- as in 'licensed under' -- or just the
applicable terms -- Sections 1 and 2(b)?  And, rhetoric aside, the GPL is decidedly not
in plain English.

> Bill Gates: "It depends on what you mean by 'is'."  Have we stooped to
> such a level?

Rhetoric is nice in politics and debating class, I guess.

> > The second question is similar.  What does the phrase "under the terms of this
> > License" modify?  The first option is for the phrase to modify "to be licensed as
> > a whole", so the sentence would read "to be licensed as a whole . . . under the
> > terms of this License", and the language "at no charge to all third parties" would
> > be excess verbiage (I say excess verbiage b/c Section 6 already provides that a
> > third party can redistribute GPL'd code at no charge).
> 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, 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.

> >  The second option is for
> > the phrase to modify "at no charge to all third parties", so in effect you only
> > have to comply  with the no-charge provisions of the GPL.
> That phrase appears two paragraphs back.  The phrase:
> "...the distribution of the whole must be on the terms of this
> License..."
> is clear, concise, and complete,

You forgot crisp, clean, comprehensible and categorical.  But that doesn't make it so.

> especially given the definition of
> "the whole" given in the opening sentences of the paragraph.  It is a
> great stretch of the language to construe the subject of that
> statement to be two paragraphs previous.

Huh?  I'm not following you. Sorry.

> 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.

> > You will note that Section 6 is the section that ensures that
> > third parties can freely redistribute unmodified code distributed pursuant to
> > Section 1, and so if the added code were also licensed under the GPL those
> > provisions would also apply to the added code, ensuring it can be freely
> > distributed.  In other words, Sections 1 and 6 ensure that any GPL'd code can be
> > freely redistributed by third parties.  Thus, if Section 2(b) required that the
> > added code be licensed under the GPL, there would be absolutely no need for the
> > "at no charge to third parties" language -- that language would add no new
> > requirement, it would be there for no reason since it does nothing.  Now, a pretty
> > standard rule of contract interpretation is that a court will try hard to give
> > meaning to all words in a contract.  Since the first option makes the words "at no
> > charge to all third parties" meaningless, and the second option does not, the
> > second option is the preferred interpretation.
> Section 6 merely guarantees that the terms of the GPL are transferred
> along with the software itself.  Section 2 guarantees that you can
> transfer the software; section 6 guarantees that anyone receiving the
> software from you can also transfer the software.

Yes, but the "no charge to third parties" stuff relates to the rights of the recipient,
not to your rights to distribute.

> Thus, section 6 has
> a quite definite meaning apart from any fanciful redefinition of
> English grammar.

"I'm a mirror and you are glue . .." ahh, never mind ;-).

> > There of course is a third reason to favor this reading of the GPL.  As has been
> > mentioned numerous times, GPL code has often been, and continues to be,
> > mixed/linked with BSD code and X code.  BSD or X code also complies with the two
> > requirements I mentioned above apply to added code -- free redistribution and
> > source availability.  However, neither BSD code nor X code complies with other
> > provisions of the GPL.
> Such as?  BSD/X is not more restrictive than the GPL; all of their
> restrictions are also in the GPL.  When you distribute under the GPL,
> you are not violating any of the BSD license's restrictions.

I think we've debated this ad nauseum above w/r/t the BSD license, but the X license is
more straightforward.  It explicitly states you must redistribute under the X 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".  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).

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.

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.

> > Hence, established practice over an extended period
> > confirms that mine is the proper reading of Section 2(b).  Of course you may
> > object that you can convert BSD or X code to GPL, but I have to disagree -- you
> > cannot change the license of someone else's code.
> Why not?

[ example snipped ]

OK, we've gone through the redistribution already and this is adding nothing new.  Now,
do the exercise with the XFree license, and then perhaps we will have something new to
discuss.  The XFree license raises even greater hurdles to your position than does the
BSD license.

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.  So how can you say it's GPL'd?  Well,
you can say, it's easy enough to do, all you have to do is change the license, its
ministerial.  Well, the same can be said about KDE -- someone can create a script that
compiles the KDE code on a machine during installation, a quite ministerial affair, and
I would presume that you at least agree that a user can compile KDE code w/out
violating the GPL?

[ ... ]

> > More to the point with Qt, it is not "incorporated" into the combined work -- the
> > Qt license does not permit that.  It is just "linked" in the *binary* version.
> > There is no mixing of source code (like in my example above where all 10 gv files
> > licensed under the BSD went unmodified by your GPL code -- in the kgv case the GPL
> > code is unmodified by the Qt code).
> 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

    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.

> 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.

> 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.

> > > Thus, your "work based on the Program"
> > > (expressly mentioned in section 6) incorporates code with restrictions
> > > beyond the GPL - namely, certain restrictions in the QPL.
> >
> > Regardless of how you interpret Section 2(b), it is a fact that Qt code is not
> > mixed with KDE code.  Qt, as a library, can be "considered [an] independent and
> > separate work[] in [itself]", and in fact Qt source code is distributed separately
> > from the KDE source code, so pursuant to the last paragraph of Section 2 whatever
> > provisions of the GPL you think Section 2(b) makes applicable to the Qt code, the
> > last part of Section 2 excuses from those provisions.  The KDE source code is not
> > derivative of the Qt source code.
> 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.

> This falls under the exception for system
> libraries.  Whether source or binaries were provided would make no
> difference at all.

Actually, under your reading it does.  If no binaries are distributed, there is no
obligation to distribute source code to Qt, even though you may choose to do so (and
the Qt license may require you to do so).  It seems to me quite plausible that, under
your reading of the GPL, you can distribute a Qt .so and KDE source, and let users
compile the two together.

> > Although a KDE binary is derivative of both KDE and Qt code, AFAIK KDE does not
> > distribute the Qt code as part of a whole with KDE code but only puts source code
> > on its servers (of course the various distributions do combine the two, but AFAIK
> > KDE does not).  So if no distributor distributed KDE and Qt code together --
> > instead forcing people to download KDE and Qt code separately from the KDE and Qt
> > ftp sites and compile it themselves -- even under your reading of the GPL there is
> > no problem.
> 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

[ ... ]

> > So I guess you would agree, then, that if a distributor only distributed (a) the
> > Qt library, (b) KDE applications that are under the Artistic license or under the
> > LGPL, and (c) KDE applications that are under the GPL but have only code developed
> > by the KDE developers for use with Qt, then it is OK even for the distributor to
> > distribute Qt and those KDE applications?  And if there are a few KDE applications
> > that fall outside those boundaries, then it would be OK for those to be
> > distributed separately to the user even in binary form, so long as they were
> > dynamically linked to the Qt libraries distributed by the distributor?

> The QPLed Qt library plus KDE components under the Artistic or LGPL
> licenses are not a problem.  Neither are KDE components licensed under
> the GPL but containing an exception clause in their license (something
> like "as an exception to the GPL, you may link this code to the Qt
> library distributed by Troll Tech...")
> 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"?

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

> > Another way of looking at it is to say, Debian could distribute *all* of KDE and
> > Qt as source code, and let its users compile it on their machines (Debian could
> > even use a fancy script that automates this).  This is true because when KDE and
> > Qt are still in source code form, the last paragraph of Section 2(b) applies:  Qt
> > is a separate work and is excused from compliance with Section 2(b).  And the user
> > compiling Qt and KDE does not violate the GPL even under your reading (provided
> > the user does not distribute the binaries).
> 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.

> > Under your reading, it would not be possible only for the handful of KDE apps that
> > incorporate third party GPL code, since it is obvious that the KDE developers
> > agree that users may compile and link with Qt.
> "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.

> > And in any event Debian could
> > distribute the source code to Qt and KDE together with a script for compiling
> > everything (the user is not restricted from compiling b/c Section 2(b) only
> > applies to distribution and publication, and the user does not distribute or
> > publish).
> "Together" - there's that system library clause again.

That's section 3 again, which does not apply if you only distribute source code.

> > So at most your problem with KDE is only the current mode of distribution -- under
> > your reading the install should take a few hours longer while the KDE code is
> > being compiled, and then everything woudl be OK.  That's pretty pedantic, in my
> > book.
> "Pedantic"?
> Debian doesn't have millions of IPO dollars to finance a legal fight.
> And our actions can affect our distributors as well.  Therefore, we
> have to be careful.

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".

> > > Except that (for example) the GPL does not restrict your right to make
> > > modifications that you keep for your own private use only, while the
> > > QPL requires you to release anything you do based on Qt Free Edition
> > > to Troll Tech upon request.
> >
> > This is debatable as well.  The issue here is whether an internal corporate
> > distribution is a "distribution" for purposes of the GPL.  I have argued elsewhere
> > that I think it is, and I won't repeat those arguments here.
> 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.

> Beyond that, at what point did I bring up a corporation?  What if I,
> as a private citizen, make some modifications on my own computer, and
> don't give them to anybody?

Oh, in that case, even under the QPL you don't have to give a copy to the original
author.  Look at Section 6 a bit closer, you will see what I mean.

> > 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.

> 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.

> > 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

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.  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.

> > 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.

> > > This is an added restriction beyond the GPL, which clearly violates
> > > section 6.
> >
> > Well, not that great of one.
> How great does it have to be?  "She's only a little pregnant."
> > 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).

> > Under the GPL, if you distribute the binary, you cannot
> > prevent the recipient from distributing it (or the source code you have to supply
> > with the binary) to third parties.  So in any event the original author can get it
> > (i.e., it is out of your control).  The only difference is, now the original
> > author can ask you for it, but given the Internet, that really is not a big
> > imposition.  The far greater imposition would be if the original author could
> > force you to reveal it after distributing to third parties if otherwise (under the
> > GPL) you could prevent third parties from revealing it, but that is not the case.
> This isn't a case of "small" impostions or "kinda" legalities.  The
> licenses conflict; my friend,

OK, then will you admit that the BSD license, w/ its copyright notice and advertisement
restriction requirements, conflicts with the GPL?

> in the case above, does not have the
> right to respect my wishes by refusing to give Troll a copy.  That is
> a restriction that does not appear in the GPL, which violates the GPL.

[ ... ]

> > AFAIK, and as I read the GPL as it is written (not as I necessarily want
> > it to be), what KDE people have done complies with not only the language of the
> > GPL, but also with the way everyone -- including AFAIK RMS -- have historically
> > treated, and to this day continue to treat, it (in relation to BSD code and X code
> > linking, and possibly with static Motif linking and in other areas that a more
> > thorough look into the past would reveal).
> Your perceptions of this issue are largely irrelevant.

In some cosmic scheme, I suppose we are all irrelevant . . .

> It is an
> uncontested fact that a large plurality (if not a majority) of the
> community, including some of its leaders and founders, had a different
> perception of the facts.

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.

> Had this been addressed early on to
> everyone's satisfaction, this could have been a minor blip in KDE's
> history.

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 :-).

> Instead, it has been a defining struggle from the project's
> earliest days until now, with nothing good having come from it
> (except, possibly, for the open-sourcing of Qt).  There are a lot of
> people who are antagonistic about the KDE project largely because of
> inattention to these matters.

On the other hand, far more people love and use KDE.

> 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?  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.
And in case you are implying I speak on behalf of KDE, I don't, I speak only for

> 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?

> > <offtopic>
> > The KDE project is composed of extremely talented, hard-working, creative,
> > responsive, devoted and selfless people who contribute an enormous amount of
> > quality GPL'd code to the open source community.  In fact, the KDE project is one
> > of the biggest Open Source projects, comparable in scope to the Linux kernel,
> > apache and GNU software.  Their enormous contributions are enjoyed and relied upon
> > by millions of people, and with the pending release of KDE 2.0, the Open Source
> > community will gain an even greater set of applications, including konqueror, a
> > fantastic browser/file manager/viewer/etc., and koffice, a sophisticated and
> > ground-breaking office suite.
> All of this is true (I assume, not having seen some of it).
> > Whether you agree with some KDE developers'
> > interpretation of the GPL or not (I am not implying any of them agrees with my
> > interpretation, though I do believe that none of them believes that he is
> > violating the GPL), I believe they do not deserve the harsh words that have been
> > levelled against them on these lists and in other forums.
> If you want to be a partner, be a partner.  Address our concerns, and
> we will work with you on yours.

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.  There is a difference
between respecting differences of opinion (which I do), and bowing to a vocal minority
which I believe to be wrong.  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).

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) -- first b/c I think it is already permitted, and
second, even if it were not, it is quite obvious the KDE authors not only permit it but
in fact encourage it (in law, there is an equitable concept of "estoppel", which
basically means in one of its incarnations that if you encourage someone to do
something not inherently wrong, you cannot then later complain that they did it -- and
it is not inherently wrong if by adding a sentence to a contract it would be OK).

[ ... ]

> > It also seems to me that if the KDE detractors spent 1/10th the effort creating a
> > GPL/LGPL version of the Qt API -- as the WINE project is doing with the Win32 API
> > and as the Lesstif project is doing with the Motif API -- as they do arguing about
> > the GPL and QPL, there would be no need for this mudslinging at all.
> 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.  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.  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?

> Which, we have heard, you are trying to do.  Good for you.  But be
> aware: there will be many eyes on the licensing for KDE 2.0.  This
> community is famous for requiring deeds instead of words.
> > I suggest that you save your energy for the real fights, when someone really
> > violates the GPL by incorporating GPL code into a binary-only distribution.  This
> > is happening more and more.  You are fighting a bitter battle against people that
> > are doing marvelous things for the open source community.
> > </offtopic>
> 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".

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

> 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.

> > > Troll would not like it very much if I took Qt Free, made some trivial
> > > modifications to it, and released it under the GPL.  (Otherwise, they
> > > would have done it, right?)  So why is it that we are not allowed to
> > > be angry because people take our GPLed code, make a few trivial
> > > changes, and release it under some other, more restrictive license?
> >
> > For the same reason, I guess, that we are not angry if people take my BSD code,
> > make a few trivial changes, and release it under some other, more restrictive
> > license (like the GPL).
> 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.

> > And yes, the GPL is more restrictive than the BSD.  Both
> > if your point of view as author is that you don't want to force people to comply
> > with the GPL, which many authors choose not to do even today, and if your view as
> > a recipient is that you want to make a binary-only distribution, which many
> > recipient want to do.
> 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?


speaking as a layman

Reply to: