I think everyone can see from the Slashdot blurb what the criticism is: Freenet has taken a long time and still isn't ready for the masses. Ian writes a very insightful analysis of the situation, talking about how innovation takes time, and how the project is still in development, and is still in that pre-release wacky stage when stuff breaks at times.
So I check the comments, and what is everyone raving about?
"Waah - it's hard to install!"
"It's never going to take off! The version I downloaded three months ago doesn't have animated icons!"
Idiots.
People, we sit here in angst about how Open Source isn't very innovative, that all we do all day is copy the work other people have done. Well, here's something no one else has managed to pull off: a decentralized P2P network with privacy and anonymity built in. So now we're trying to kill it off with criticism because it's taking longer to write than the IRC client your roommate wrote in a night of caffeine-induced frenzy.
Here's a news flash for you: Creating something new takes time. It's not as easy to do as copy other people's good ideas. So the fact that, say, GNOME, or Linux, or whatever was done in less time is irrelevant: for a fair comparison, you should factor in the 15+ years of tweaking to the GUI done by Apple and Microsoft into the GNOME timetable, or the 30+ years of development on Unix into Linux's. For a more pertinent example of how good Freenet is doing, go compare Freenet to Unix circa 1971, or the Apple Lisa, or Windows 1.1.
So, if you're the type to download something, play with it, then slam it because it doesn't work, let me give you some advice:
Stay away from Freenet. Far away. Go play with Napster or Gnutella. Come back and play when the Freenet 1.0 announcement comes across Freshmeat.
NetZero and their ilk aren't forcing you to use their service; if you want, you can always get AOL, some other dialup ISP, cable, DSL, etc.
All of these grant you a service in exchange for payment. For most of these services, the payment is in dollars. For NetZero & Co., the payment is in advertising you are forced to see when you use the service.
Sounds fair to me. In fact, for people who can't afford "regular" Net access, a business throwaway Pentium and NetZero sounds like an ideal way to get wired.
This is in contrast to spammers like Harris, who send you stuff without you asking for it and can't be made to stop even when you ask.
I lived in Champaign during that period, and worked half a block from Spyglass (the company that licensed Mosaic from UIUC). IMO, UIUC lost Mosaic out of pure stupidity, not because of corporate avarice.
As has been proven in the market, their static intellectual property in Mosaic was worthless without the talent to drive it; the people were the critical factor, not the existing code base. NCSA should have created something like the W3C back then and given the Mosaic team the incentive to stick around, perhaps by being a bit more friendly to "Mosaic Communications" (Netscape's original name) and less anal about defending what they saw as their property. Had they done this, the W3C would likely be based at UIUC, and the university would have lots of corporate grants for Internet research, the cream of the crop among both students and faculty, higher academic rankings, etc..., all of which translate into more dollars for them.
Instead, they pissed off Andressen & Co., who ended up mostly reimplementing Mosaic from scratch (which was relatively easy for them - after all, they had practice) and moving on. Meanwhile, Mosaic - the precious property they defended - withered when no one proved worthy of the task of keeping it up to date (including Spyglass, who tried to play the licensing game instead of coming out with a superior browser immediately to kill Netscape in infancy). So, once Navigator came out, Mosaic was doomed - as was NCSA's (and UIUC's) leadership role on the Internet, and Spyglass's future (the shop I used to work next to was closed years ago in financial crisis).
It figures that UIUC would mislearn the lessons from this and try to hold even more tightly on to its IP. Isn't it funny that NCSA's leadership role on the Web has been taken over by MIT with the W3C, considering MIT's much more relaxed attitude towards IP?
You write up specs for a "meta-package" format, and EPM will build various packages for you. It supports RPM,.deb, Solaris packages, IRIX packages, and HP-UX packages, as well as a "tarball" format that installs with a setup program (user-supplied, or you can use theirs).
It's GPL, and it's packaged for Debian (for woody, not for potato, unfortunately, although the woody package works on potato).
And, of course, in a world without IP protections, it's impossible to add restrictions to code you distribute. If you distribute some code with source, and I distribute changed code in binary form, someone else can reverse-engineer your code, write equivalent source, and distribute that.
Heck, that can be done even if the initial author doesn't distribute source.
So, essentially, the net effect of abolishing intellectual property would be that everything would have an implicit GPL license attached to it. I don't think the FSF would have a problem with that.
We already tried security through obscurity; it roughly translates as "trust the vendors to do the right thing". I'm sure no one is surprised to find that it doesn't work.
The first full-disclosure lists were founded by sysadmins who were frustrated at the lack of response by vendors, as a "self-help" resource. Some of them even started out as "partial disclosure" lists, thinking that vendors would wise up and fix their bugs. Did it work? Nope.
Heck, even in this day and age, vendors are still stupid. Every so often, a bug gets posted to BugTraq without an exploit, and the vendor gets all pissed, calls the submitter a liar, and threatens a slander lawsuit. The only way to shut them up? Publish the exploit.
That's when people like Ranum get all pissed because the poor submitter defended his honor after being slammed in a public forum. Well, cry me a river.
The current situation isn't ideal by any means; I think exploits shouldn't be posted except in cases of flagrant irresponsibility or hostility, just as one example. But let's not pretend that it's irresponsible, or even immoral. It's the lesser of two evils.
If Marcus Ranum wants us to stop publicizing cracks, then he had damn well better be ready to deliver a guarantee that vendor response will be better in an age of secrecy. Can I sue him if a vendor sits on a report and doesn't fix it for six months, and a cracker uses it to trash my system?
Until that happens, get used to full disclosure. It isn't going away as long as the USA has a First Amendment.
Re:But Mattel _asks_ if you want it!
on
Mattel Spyware
·
· Score: 2
Actually, Debian does have such a package. It's called "popularity-contest", and it uploads your installed packages list to Debian for statistical purposes.
The differences between this and Mattel should be obvious:
- You have to explicitly install popularity-contest, so you are guaranteed to know what you're doing; none of the default install profiles include it. Mattel had to be threatened with legal action before they gave the option to not install it.
- Popularity-contest's purpose is clearly stated and fully documented; Mattel was scared to even let you know it existed.
Well, I don't want to detract any more from the otherwise good stuff in the interview than I already have. Dave, if you want to, E-mail me, and we can discuss our differences. If not, fine; and good luck with Konquerer.
I will say a few things:
I don't particularly like the situation with the licensing, either. But I can't do anything about it. KDE has chosen to give an internally inconsistent license to its users; it must accept the resulting confusion and missed opportunity that results.
We ridicule programmers who dismiss usability; indeed, KDE is about bucking that trend. Usability implies that a project listens to its users and assists them. If there is a usability issue with your license, why must it be consistently ignored? If incomplete bug fixes are not to be accepted in code, why should they be accepted in licensing?
Licensing matters. One would think that the recent incidents with the CyberPatrol crack, DeCSS, UCITA, Napster, and MP3.com would cause people to realize this.
- The GPL prohibits you from placing any greater restrictions on software you distribute.
- The QPL places such restrictions (you must give Troll a copy).
- Therefore, the licenses are incompatible.
No one is suggesting that Qt isn't free. What we're saying is that your license is logically inconsistent, and that therefore it's impossible to know what license you really want.
Essentially, you don't distribute KDE under the GPL. You *say* you do, but really you don't, because distributing KDE binaries would be illegal if so, and you haven't seemed to mind so far.
What Debian wants here is a statement of *what* your license really is.
This refers to "contrib". The idea is that popular non-free software could be given a "helper package" that would do the meat of the installing for you (untar, copy binaries, etc.), as well as allow the user to manage non-free software through apt/dpkg as much as possible.
KDE and Qt are not distributed as a whole. And Qt is not a work based on KDE (the Program). Just prior to your quote, it states "this License, and its terms, do not apply to those sections when you distribute them as separate works" The only parts of KDE which actually include QPLd files as part of the package are licensed under the LGPL instead of the GPL.
Which, as I said, gives you your two choices: source, or unusable binaries.:-)
The problem is that you are creating "a work based on the Program". The "Program", here, is KDE. By compiling it, you create a "work based on the Program" - namely, the combination of KDE and Qt. And this is more than a mere aggregation, because if you remove Qt, KDE stops working.
In this sense, Qt becomes "a part" of KDE when it's compiled, in that KDE won't work without it.
I have been much nicer and far politer here than most (not all) Debian developers have ever been to me.
Fair enough. Not that I've *ever* been snide or sarcastic before.:-)
This is a major illustration of one of RMS's points: that the GPL is not anti-commercial, just anti-proprietary. The QPL's stated intent is to be anti-commercial.
They are free to be motivated in this way, and to make such demands; this does not make it any less incompatible.
That may be their intent. Unfortunately, it happens too often that the letter does not match the intent; that's the source of too much lawyering these days.
It's debian-legal, in fact, that keeps pushing us not to include KDE, so I fail to see how the issue could have been "cleared up" there. I suppose you're free to re-introduce the issue if you think this is really what's happening (though my thoughts are that it will simply ignite another flame war and accomplish nothing).
At any rate, your analysis fails. Section 3 starts out:
"3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following..."
So Sections 1 and 2 apply to any distribution you make under Section 3. And, of course, Section 2 (in the part you forgot to quote) states:
"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."
Now, this argument would work for source-only distribution; it's perfectly legal to distribute source. But binaries, when distributed, are linked to Qt, thus forming a "work based on the Program" (namely, a complete working binary distribution of KDE) - either by physical static linking (copies of Qt code embedded in each executable) or through binaries that will not function without a copy of Qt, and incorporate Qt into themselves at run time.
To make this perfectly clear, you could likely do one of the following:
- Distribute KDE source.
- Distribute KDE binaries, dynamically linked to Qt but not accompanying Qt. In other words, a broken implementation of KDE that will do nothing.
Finally, if I may: Let's dispense with the hostility. Don't you think we have enough slamming on other people's views, without such volatile language? The old saw applies here well: If you don't like Debian, don't use it.
I'm not sure how the KDE post is relevant. I didn't think that XFree86's licensing was an issue.
I'm also not sure what Lineo's IPO filing has to do with anything. As I mentioned somewhere else, companies with legal departments (like Lineo) may consider things to be acceptable risks that others (like Debian) may not.
There's nothing magical about the GPL. It's simply a nice template license that expresses a certain set of goals well. If those aren't your goals for your software, don't use the GPL; you'd do better with something like the LGPL.
It's fairly obvious that the KDE project's goals don't totally mesh with the GPL; otherwise, they wouldn't be using Qt at all. So, my question is: Why did they pick the GPL when they didn't agree with it?
"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
This is part of a larger paragraph that requires, among other things, that source must be distributed, and that the compilation must itself be licensed under the GPL. This is where the restriction comes from that the license for components cannot be more restrictive than the GPL; otherwise, you couldn't license the compilation (your code plus the other code needed) under the GPL.
It's not legal to write GPLed apps for Motif and distribute them with Motif. It is legal, however, to distribute GPLed Motif apps separately.
"You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements:... If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one."
The GPL does not force you to distribute; it only forces you to distribute source when you do distribute. The QPL, on the other hand, does force you to distribute in this one special case: when Troll asks, you must give them a copy. This is an "additional restriction", and therefore is incompatible with the GPL.
(The "when distributed" clause is not enough of an "out" here. If I give a copy of my cool new GPLed program to my friend, and the two of us don't want to give a copy to Troll, we don't have to - unless, of course, the program is linked to Qt.)
Technically, it is already legal to distribute the source of KDE to anyone you want, QPL or no QPL. You just aren't allowed to link it to Qt (or are you?)
The other reason why this doesn't work:
Imagine that Microsoft modified the EULA on the Windows SDK to state:
"You may, additionally, link any of these libraries to code covered by the GNU General Public License. Doing so does not grant you any special rights to the source code of the Microsoft products licensed herein."
Now the SDK is explicitly allowed to link to, say, gettext - at least from MS's perspective. Does that make it legal for MS to incorporate gettext into Visual C++? Of course not! This is because the GPL is being violated here.
The QPL situation is a less extreme example of the same thing.
One way that proprietary UNIX vendors get around this is by including the GNU utilities on a separate "unofficial" or "unsupported" CD. MS could do that.
Licenses exist for a reason: to tell the world how the author of some software wants it to be distributed.
In the case of KDE, they have (so far) not managed to make a coherent statement about how they want KDE distributed. This is because they use the GPL, but link to Qt, which is not GPL-compatible.
Now, many people have taken the risk of "assuming" a few extra clauses in KDE's license. Most likely, that's safe, and for commercial distros with legal departments, that may be an acceptable risk.
Debian, however, is a legal fiction, with no assets. If we assume a risk like this, we are in reality causing our distributors to assume that risk, since in all likelihood they would be the ones sued. We don't feel it proper to put our distributors at risk; therefore, we don't incorporate software that doesn't have a clear license. KDE falls into that category.
The problem is that KDE hasn't made a coherent statement about their wishes that we can respect. Once they do (by incorporating a clause like the one in the offer, or switching to Artistic, or whatever), KDE will be incorporated into Debian as quickly as we can get it uploaded.
Slashdot Mirror
I think everyone can see from the Slashdot blurb what the criticism is: Freenet has taken a long time and still isn't ready for the masses. Ian writes a very insightful analysis of the situation, talking about how innovation takes time, and how the project is still in development, and is still in that pre-release wacky stage when stuff breaks at times.
So I check the comments, and what is everyone raving about?
"Waah - it's hard to install!"
"It's never going to take off! The version I downloaded three months ago doesn't have animated icons!"
Idiots.
People, we sit here in angst about how Open Source isn't very innovative, that all we do all day is copy the work other people have done. Well, here's something no one else has managed to pull off: a decentralized P2P network with privacy and anonymity built in. So now we're trying to kill it off with criticism because it's taking longer to write than the IRC client your roommate wrote in a night of caffeine-induced frenzy.
Here's a news flash for you: Creating something new takes time. It's not as easy to do as copy other people's good ideas. So the fact that, say, GNOME, or Linux, or whatever was done in less time is irrelevant: for a fair comparison, you should factor in the 15+ years of tweaking to the GUI done by Apple and Microsoft into the GNOME timetable, or the 30+ years of development on Unix into Linux's. For a more pertinent example of how good Freenet is doing, go compare Freenet to Unix circa 1971, or the Apple Lisa, or Windows 1.1.
So, if you're the type to download something, play with it, then slam it because it doesn't work, let me give you some advice:
Stay away from Freenet. Far away. Go play with Napster or Gnutella. Come back and play when the Freenet 1.0 announcement comes across Freshmeat.
And, for the love of Mike, shut up.
NetZero and their ilk aren't forcing you to use their service; if you want, you can always get AOL, some other dialup ISP, cable, DSL, etc.
All of these grant you a service in exchange for payment. For most of these services, the payment is in dollars. For NetZero & Co., the payment is in advertising you are forced to see when you use the service.
Sounds fair to me. In fact, for people who can't afford "regular" Net access, a business throwaway Pentium and NetZero sounds like an ideal way to get wired.
This is in contrast to spammers like Harris, who send you stuff without you asking for it and can't be made to stop even when you ask.
I lived in Champaign during that period, and worked half a block from Spyglass (the company that licensed Mosaic from UIUC). IMO, UIUC lost Mosaic out of pure stupidity, not because of corporate avarice.
As has been proven in the market, their static intellectual property in Mosaic was worthless without the talent to drive it; the people were the critical factor, not the existing code base. NCSA should have created something like the W3C back then and given the Mosaic team the incentive to stick around, perhaps by being a bit more friendly to "Mosaic Communications" (Netscape's original name) and less anal about defending what they saw as their property. Had they done this, the W3C would likely be based at UIUC, and the university would have lots of corporate grants for Internet research, the cream of the crop among both students and faculty, higher academic rankings, etc..., all of which translate into more dollars for them.
Instead, they pissed off Andressen & Co., who ended up mostly reimplementing Mosaic from scratch (which was relatively easy for them - after all, they had practice) and moving on. Meanwhile, Mosaic - the precious property they defended - withered when no one proved worthy of the task of keeping it up to date (including Spyglass, who tried to play the licensing game instead of coming out with a superior browser immediately to kill Netscape in infancy). So, once Navigator came out, Mosaic was doomed - as was NCSA's (and UIUC's) leadership role on the Internet, and Spyglass's future (the shop I used to work next to was closed years ago in financial crisis).
It figures that UIUC would mislearn the lessons from this and try to hold even more tightly on to its IP. Isn't it funny that NCSA's leadership role on the Web has been taken over by MIT with the W3C, considering MIT's much more relaxed attitude towards IP?
You write up specs for a "meta-package" format, and EPM will build various packages for you. It supports RPM, .deb, Solaris packages, IRIX packages, and HP-UX packages, as well as a "tarball" format that installs with a setup program (user-supplied, or you can use theirs).
It's GPL, and it's packaged for Debian (for woody, not for potato, unfortunately, although the woody package works on potato).
By opening a socket to port 25, perhaps? Or by providing a /usr/sbin/sendmail that's option-compatible (as, I believe, most of the MTAs do)?
And, of course, in a world without IP protections, it's impossible to add restrictions to code you distribute. If you distribute some code with source, and I distribute changed code in binary form, someone else can reverse-engineer your code, write equivalent source, and distribute that.
Heck, that can be done even if the initial author doesn't distribute source.
So, essentially, the net effect of abolishing intellectual property would be that everything would have an implicit GPL license attached to it. I don't think the FSF would have a problem with that.
We already tried security through obscurity; it roughly translates as "trust the vendors to do the right thing". I'm sure no one is surprised to find that it doesn't work.
The first full-disclosure lists were founded by sysadmins who were frustrated at the lack of response by vendors, as a "self-help" resource. Some of them even started out as "partial disclosure" lists, thinking that vendors would wise up and fix their bugs. Did it work? Nope.
Heck, even in this day and age, vendors are still stupid. Every so often, a bug gets posted to BugTraq without an exploit, and the vendor gets all pissed, calls the submitter a liar, and threatens a slander lawsuit. The only way to shut them up? Publish the exploit.
That's when people like Ranum get all pissed because the poor submitter defended his honor after being slammed in a public forum. Well, cry me a river.
The current situation isn't ideal by any means; I think exploits shouldn't be posted except in cases of flagrant irresponsibility or hostility, just as one example. But let's not pretend that it's irresponsible, or even immoral. It's the lesser of two evils.
If Marcus Ranum wants us to stop publicizing cracks, then he had damn well better be ready to deliver a guarantee that vendor response will be better in an age of secrecy. Can I sue him if a vendor sits on a report and doesn't fix it for six months, and a cracker uses it to trash my system?
Until that happens, get used to full disclosure. It isn't going away as long as the USA has a First Amendment.
Actually, Debian does have such a package. It's called "popularity-contest", and it uploads your installed packages list to Debian for statistical purposes.
The differences between this and Mattel should be obvious:
- You have to explicitly install popularity-contest, so you are guaranteed to know what you're doing; none of the default install profiles include it. Mattel had to be threatened with legal action before they gave the option to not install it.
- Popularity-contest's purpose is clearly stated and fully documented; Mattel was scared to even let you know it existed.
Well, I don't want to detract any more from the otherwise good stuff in the interview than I already have. Dave, if you want to, E-mail me, and we can discuss our differences. If not, fine; and good luck with Konquerer.
I will say a few things:
I'll shut up now.
OK, let's go over this one more time:
- The GPL prohibits you from placing any greater restrictions on software you distribute.
- The QPL places such restrictions (you must give Troll a copy).
- Therefore, the licenses are incompatible.
No one is suggesting that Qt isn't free. What we're saying is that your license is logically inconsistent, and that therefore it's impossible to know what license you really want.
Essentially, you don't distribute KDE under the GPL. You *say* you do, but really you don't, because distributing KDE binaries would be illegal if so, and you haven't seemed to mind so far.
What Debian wants here is a statement of *what* your license really is.
This refers to "contrib". The idea is that popular non-free software could be given a "helper package" that would do the meat of the installing for you (untar, copy binaries, etc.), as well as allow the user to manage non-free software through apt/dpkg as much as possible.
KDE and Qt are not distributed as a whole. And Qt is not a work based on KDE (the Program). Just prior to your quote, it states "this License, and its terms, do not apply to those sections when you distribute them as separate works" The only parts of KDE which actually include QPLd files as part of the package are licensed under the LGPL instead of the GPL.
Which, as I said, gives you your two choices: source, or unusable binaries. :-)
The problem is that you are creating "a work based on the Program". The "Program", here, is KDE. By compiling it, you create a "work based on the Program" - namely, the combination of KDE and Qt. And this is more than a mere aggregation, because if you remove Qt, KDE stops working.
In this sense, Qt becomes "a part" of KDE when it's compiled, in that KDE won't work without it.
I have been much nicer and far politer here than most (not all) Debian developers have ever been to me.
Fair enough. Not that I've *ever* been snide or sarcastic before. :-)
This is a major illustration of one of RMS's points: that the GPL is not anti-commercial, just anti-proprietary. The QPL's stated intent is to be anti-commercial.
They are free to be motivated in this way, and to make such demands; this does not make it any less incompatible.
That may be their intent. Unfortunately, it happens too often that the letter does not match the intent; that's the source of too much lawyering these days.
It's debian-legal, in fact, that keeps pushing us not to include KDE, so I fail to see how the issue could have been "cleared up" there. I suppose you're free to re-introduce the issue if you think this is really what's happening (though my thoughts are that it will simply ignite another flame war and accomplish nothing).
At any rate, your analysis fails. Section 3 starts out:
"3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following..."
So Sections 1 and 2 apply to any distribution you make under Section 3. And, of course, Section 2 (in the part you forgot to quote) states:
"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."
Now, this argument would work for source-only distribution; it's perfectly legal to distribute source. But binaries, when distributed, are linked to Qt, thus forming a "work based on the Program" (namely, a complete working binary distribution of KDE) - either by physical static linking (copies of Qt code embedded in each executable) or through binaries that will not function without a copy of Qt, and incorporate Qt into themselves at run time.
To make this perfectly clear, you could likely do one of the following:
- Distribute KDE source.
- Distribute KDE binaries, dynamically linked to Qt but not accompanying Qt. In other words, a broken implementation of KDE that will do nothing.
Finally, if I may: Let's dispense with the hostility. Don't you think we have enough slamming on other people's views, without such volatile language? The old saw applies here well: If you don't like Debian, don't use it.
Ah, my bad. Thanks for the clarification.
I'm not sure how the KDE post is relevant. I didn't think that XFree86's licensing was an issue.
I'm also not sure what Lineo's IPO filing has to do with anything. As I mentioned somewhere else, companies with legal departments (like Lineo) may consider things to be acceptable risks that others (like Debian) may not.
There's nothing magical about the GPL. It's simply a nice template license that expresses a certain set of goals well. If those aren't your goals for your software, don't use the GPL; you'd do better with something like the LGPL.
It's fairly obvious that the KDE project's goals don't totally mesh with the GPL; otherwise, they wouldn't be using Qt at all. So, my question is: Why did they pick the GPL when they didn't agree with it?
Here is the rule: (from the GPL, section 3)
"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
This is part of a larger paragraph that requires, among other things, that source must be distributed, and that the compilation must itself be licensed under the GPL. This is where the restriction comes from that the license for components cannot be more restrictive than the GPL; otherwise, you couldn't license the compilation (your code plus the other code needed) under the GPL.
It's not legal to write GPLed apps for Motif and distribute them with Motif. It is legal, however, to distribute GPLed Motif apps separately.
...specifically paragraph 6, clause c. Note specifically that this applies to programs that link to "the Software".
Clause 6 of the QPL, especially part c:
... If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one."
"You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements:
The GPL does not force you to distribute; it only forces you to distribute source when you do distribute. The QPL, on the other hand, does force you to distribute in this one special case: when Troll asks, you must give them a copy. This is an "additional restriction", and therefore is incompatible with the GPL.
(The "when distributed" clause is not enough of an "out" here. If I give a copy of my cool new GPLed program to my friend, and the two of us don't want to give a copy to Troll, we don't have to - unless, of course, the program is linked to Qt.)
Technically, it is already legal to distribute the source of KDE to anyone you want, QPL or no QPL. You just aren't allowed to link it to Qt (or are you?)
The other reason why this doesn't work:
Imagine that Microsoft modified the EULA on the Windows SDK to state:
"You may, additionally, link any of these libraries to code covered by the GNU General Public License. Doing so does not grant you any special rights to the source code of the Microsoft products licensed herein."
Now the SDK is explicitly allowed to link to, say, gettext - at least from MS's perspective. Does that make it legal for MS to incorporate gettext into Visual C++? Of course not! This is because the GPL is being violated here.
The QPL situation is a less extreme example of the same thing.
Not as a part of the OS, no.
One way that proprietary UNIX vendors get around this is by including the GNU utilities on a separate "unofficial" or "unsupported" CD. MS could do that.
Sorry; my bad. I must have gotten my timelines mixed up.
If Harmony existed, then there would be no licensing problems at all, and KDE would be in main right now.
Licenses exist for a reason: to tell the world how the author of some software wants it to be distributed.
In the case of KDE, they have (so far) not managed to make a coherent statement about how they want KDE distributed. This is because they use the GPL, but link to Qt, which is not GPL-compatible.
Now, many people have taken the risk of "assuming" a few extra clauses in KDE's license. Most likely, that's safe, and for commercial distros with legal departments, that may be an acceptable risk.
Debian, however, is a legal fiction, with no assets. If we assume a risk like this, we are in reality causing our distributors to assume that risk, since in all likelihood they would be the ones sued. We don't feel it proper to put our distributors at risk; therefore, we don't incorporate software that doesn't have a clear license. KDE falls into that category.
The problem is that KDE hasn't made a coherent statement about their wishes that we can respect. Once they do (by incorporating a clause like the one in the offer, or switching to Artistic, or whatever), KDE will be incorporated into Debian as quickly as we can get it uploaded.