Re: KDE not in Debian?

[Jeff Licquia <jeff@luci.org>]

[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's why people can make
proprietary versions of BSD-licensed code.

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.

This is no different than, say, Microsoft's Winsock library, or BSDI.
It's just that far fewer additional restrictions are being placed.

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

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.

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

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

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

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.

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

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

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

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

> 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.  Thus, section 6 has
a quite definite meaning apart from any fanciful redefinition of
English grammar.

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

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

> Not to be repetitive, but here is a more detailed example of why you cannot
> convert BSD or X code to GPL code. 

More gyrations.  OK, let's...

> Let's say I write a program, let's call it gv,
> which displays ghostscript code.  I put this in ten separate source code files,
> and license each file under BSD (the same reasoning applies to X
code). 

Good so far.  "gv" is a BSD-licensed program.

> You then
> come along and want to add a GTK front-end for it, call it ggv, and write some GPL
> code which does the front-end stuff but leaves my ten files
untouched. 

Got it.  Ten files under the BSD, plus a few under the GPL.

> You then
> want to distribute the whole thing under the GPL, b/c under your reading if you
> did not do so you could not distribute a binary of your ggv
program. 

Exactly.

> Well, how
> can you do that? 

The BSD license reads:

"Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
3. Neither the name of the University nor the names of its contributors
   may be used to endorse or promote products derived from this software
   without specific prior written permission."

When I give you a copy of "gv" under the GPL, what conditions have I
violated?  I have, per condition 1, preserved the copyright notice,
the conditions, and the disclaimer, all of which are allowed (or even
required) under the GPL.  The same with condition 2.  For condition 3, 
I have not made any statements that the University endorses my
software, and the GPL does not require me to.

> Let's say you distribute that combined set of files to Joe (Joe
> is a third party). You claim that he can distribute the gv code, which I wrote,
> only in compliance with the GPL? 

No.  But he can distribute my code only in compliance with the GPL,
which means that the whole thing must be in compliance with the GPL as 
well.  If Joe removes my code, he can distribute the result and
"violate" the GPL, and I don't care.

The key is, again, that the GPL's terms do not violate the BSD
license's terms.

> So, structure, logic, and established practice all support my reading of Section
> 2(b).

No, no, and no.  Three strikes, and you're out.

> I may not have convinced you, but at least you must agree that this is a
> reasonable and fair interpretation.  And thus, it would be incumbent upon you not
> to call people that have this interpretation of the GPL, or similar ones,
> criminals, outlaws, bandits or other libelous words.

Please don't tell me what to do.  I do not, in fact agree that your
interpretation is reasonable and fair, and it is not incumbent on me
to say anything at all about anyone.

(Aren't we fond of accusing people of things!)

> > > And finally, section 6
> > > requires me to sublicense kgv under the GPL to anyone I give it to. I
> > > have not changed the license, so I am not in violation. However, sec6
> > > also says I can't add any restrictions to the gv code. I contend that I
> > > have not done so. There are no further restrictions on ANY of gv's code
> > > or on any of its code that I have modified.
> >
> > Yes, there are.  You have incorporated Qt into the work (based on your
> > own admission above).
> 
> 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?

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.

Can KDE source code be a separate product from Qt code?  It's an
interesting question.

> > 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.  This falls under the exception for system
libraries.  Whether source or binaries were provided would make no
difference at all.

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

> > "Linking" is an OS-specific action, so it must be looked at in the
> > context of the OS in question.
> >
> > Motif is a component on every Solaris system.  Therefore, you don't
> > have to distribute Motif source code, binaries, dynamic libraries, or
> > whatever with your GPLed Motif program, since they are provided with
> > every Solaris system.
> 
> Not necessarily true.  The "unless that component itself accompanies the
> executable" would mean that *statically linked* Motif applications would not fall
> under this exception.  So this would hold only if none of these GPL/Motif programs
> was statically linked (perhaps none were, I don't know either way).

I agree.

On Solaris, it wasn't usually a big problem, as dynamic linking is
preferable, and everyone is guaranteed a dynamic Motif library.  But
Debian has in the past pulled (or threatened to pull) static Motif
binaries out of Debian for licensing reasons.

As I mentioned before, Lesstif has made this particular issue moot.

> > Thus, you can link a GPLed program to Motif on
> > Solaris, since Solaris users wanting to use your binary can use it
> > without having to download Motif, and people wanting to recompile it
> > can link with the Solaris-provided Motif libraries.
> 
> 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?

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

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

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

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

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

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?

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

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.

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

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

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

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

> Errh, just for clarification, I was not calling anyone a moronic idiot :-).

Right.

> > This controversy was created by people in one of two situations:
> >
> >  - muddle-headed thinkers, who would yell like crazy about sloppy code
> > yet see no reason to apply any effort to legal coherence, or
> 
> Hmm, I don't consider myself muddle-headed either ;-).

Good for you! :-)

> >  - people with an agenda, who don't like what the GPL stands for, and
> > who contort themselves into pretzels to squeeze out of a relatively
> > clear legal document they've agreed to once but no longer agree with.
> 
> I happen to like the what the GPL stands for, although unlike you I think the
> draftsmanship is rather unclear.  The only reason I have given my interpretation
> of the GPL is b/c some people were calling my friends at KDE criminals and
> immoral. 

Name calling is not good - from either side.  The facts must be left
to stand.  At the very least, the principle of "innocent until proven
guilty" proves that you are not criminals.  Moral questions are
another matter, and are debatable; on that score, ignorance is a
better defense, so you might want to take back that part about not
being muddle-headed. :-)

> 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.  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.  Had this been addressed early on to
everyone's satisfaction, this could have been a minor blip in KDE's
history.  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.

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.  Are you surprised when you
meet resistance from these people when you expect to partner with them 
to provide great applications for your project?

> <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 do not agree with the desktop flamage that has been spewed.
However, I believe it to be the result of a fundamental arrogance that 
I saw at the beginning of the KDE project, right after it was first
announced.  These licensing issues were discussed then, and in much
less of a confrontational way, but they were brushed aside as
"unimportant".  The attitude was "we'll write our code our way, and you 
can't stop us".  And here we are, many years later, and the project is 
still weighed down with the fallout from this first slight.

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

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

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

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

> Andreas
> speaking as a layperson

IANAL, as well.