Subject line says it all. It's all they can be expected to do. If they have trouble doing it then they have trouble. But right now they're denying there's a problem, much less trying to fix it.
Perhaps once what they did could have been unintentional. However the fact is that they have taken not a single step to correct this after THREE YEARS in some cases. If this were Microsoft and not Joe Linux Hacker, you'd expect it resolved in THREE DAYS.
Date: Sun, 18 Jun 2000 02:43:44 -0700 From: Waldo Bastian <bastian@kde.org> Subject: Your posting on www.slashdot.org. To: knghtbrd@debian.org
On www.slashdot.org you posted: > What is the problem is that KDE has committed Copyright infringement.
Dear Sir,
According to one of our laywers statements like the one above can be considered libel. I kindly ask you to cease making such definitive public statements.
Kind regards, Waldo Bastian -- Make way, KDE/Linux is coming to a desktop near you!
It's only libel if it's false and I know it to be false. However, I've proven it to be true right here.
In other words, Mr. Bastian, fuck off. I will not be silenced by legal threats from a meta-organization that doesn't even exist as a legal entity.
A glaringly obvious example of KDE's blatant GPL violations comes in the form of kghostscript. They didn't write it, and it is GPL'd. Now since it takes a minimum of one license conflict to bring down the whole house of cards that is KDE's license to distribute kghostscript, let's stop after the first one (for the sake of brevity..)
Section 3 of the QPL reads:
3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications:
Modifications must be seperate, ie patches or CVS or something, from the source code itself.. That's a restriction the GPL doesn't have, to be sure. Now let's look at the GPL itself, shall we?
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:
All we have to do is satisfy sections 1 and 2 and make source available under the provisions in section 3. But let's have a look at section 2(b):
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Here's the classic dilemma. Binaries are okay as long as the whole thing is under the GPL's terms. The GPL does provide an exceoption for system libraries, but that exception doesn't apply if the system libraries are being distributed at the same time as kghostscript, so it does not apply to Qt.
You could argue that Qt is not part of the binary because it is dynamically linked. But Qt's headers and macros are linked in at compile time. And even then, a court would have to view dynamic linking the same as static linking if it were being used as a mechanism to thwart the license of the GPL'd application. Another point from the GPL:
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.
Any other agreement includes the terms of the QPL. Because we cannot satisfy both the QPL and GPL, we cannot distribute the program at all. And not only can we not, but KDE can not as well. Neither can Red Hat or SuSE or Mandrake for that matter. To do otherwise is a violation of Copyright law, whether or not you're likely to face a lawsuit (or even criminal charges under the DMCA!)
You don't get it do you? Under Copyright law, I can be hit with big fines if I commit Copyright infringement. Under the DMCA, I can do time for it too.
Faced with these risks, should I willfully violate Copyright licenses? Not likely! Debian agrees. You want Debian to break the law?
If someone else else wants to do that, that's fine. It doesn't change the incompatibility between the multiple licenses in KDE's code. Until they're sure they can satisfy the software's licenses, I doubt Debian will touch KDE.
This should probably be 5, Informative IMO because it's dead on. As I've said about as many times as I spent working on this (which means I no longer have any idea other than "a lot"), it's NOT a matter of KDE being non-free or Qt being non-free. KDE is GPL'd and Qt's QPL satisfies our Free Software Guidelines (which are the origin of the Open Source Definition), so Qt v2 IS free software.
The whole crux of the problem lies in KDE's use of code under the GPL which they did not write and have not right to change the license of. If you write some code and put it under a given license, I don't have the right to change your code's license to suit my needs. KDE has done precisely this in spirit. In legality, they are simply committing Copyright infringement. So is Red Hat and any other distribution distributing KDE. What's interesting is the number of messages from Red Hat employees my editorial has garnered trying to explain how market pressures forced them to include KDE even though they knew the final licenses weren't compatible. They agreed to do this back when Troll Tech was actively talking with me and it looked like the license would be GPL compatible when finished.
Market dynamics are apparently more important than legal and moral reprocussions of Copyright infringement. KDE better hope they don't touch my code.
flash /UL Probably more than that even. This isn't about free vs proprietary software. It's a license conflict forcing us into the unfortunate position of being denied legal right to distribute most of KDE at all. What's left really isn't worth distributing on its own because it'll just cause version conflicts for people who want the rest of KDE.
It's not a question of free software vs. proprietary software as is typical of most issues surrounding the GPL. KDE v2 is GPL and Qt v2 is under a free license.
What is the problem is that KDE has committed Copyright infringement. And they know and admit it, but not publicly. Legally what they're doing is the same as software piracy. Morally? That's for each of us to decide on our own.
You mean like those parsed by GNUStep tools? Window Maker also uses them (though it's C, not ObjC) and provides libproplist for other programs to do the same.
GNUStep provides a series of tools for checking and working on these proplist files, which somewhat resemble configuration for perl scripts IMO. Anyway, it's a good format that seems to be what everyone drooling about XML was after, and it's got a longer history. It's worth looking at if you happen to like the way wmaker's configs are stored.
The engine is GPL'd, but we still need to come up with our own GPL'd game data. In order to make this possible, John was nice enough to release the Quake1 tools and QuakeC code under the GPL. This means all we need are graphics, sounds, models, maps, etc. Email or ICQ me (67962016) if you're interested, I'll get you in touch with people planning to do exactly that.
The project is probably a bigger undertaking than QuakeForge itself, and really needs more talented people so it can really take off.
What it seems to me you are saying is that if the custom UI functions are to be there, the defaults should be as much like the host environment as possible. For win32, something that looks like netscape4 is probably appropriate. For Linux, something like GTK (and nextstep and motif and qt and... well you get the idea), for BeOS something that looks like Be...
This isn't necessarily a bad idea. It's not easy to implement, but if possible I agree the host environment should be a major consideration when chosing installation defaults.
I've managed to crack mine. It's a little tough to get out of the sleeve byt if you realize there's not data around that round section you quickly get over the fear of a fingerprint at the round edges interfering with the reading.
I want a replacement or two, that's for sure! I've had my ass saved more than once by that thing.
John, have you looked at QuakeWorld Forever yet? They have an encryption-based solution which is far more effective than any obfuscated code ever could be. And they're not walking on the GPL to do it.
The QWF people even offered to help Slade implement their techniques if it would guarantee GPL compliance. Their offer was declined. I made a similar offer. Also declined.
I don't have much sympathy for the guy anymore. He's where he is because this is where he's decided to be. He's also stated that he intends to fight you in court if necessary on this, going so far as to say he may sue you for slander.
The QuakeWorld Forever project is using encryption to protect the game while still maintaining compliance with the GPL. Their model currently allows one key, but they're not finished yet. It will allow public key cryptography before they're done, just as you suggest here. I don't know if they've considered key trust levels yet though.
That's not quite true... Once someone does prove they have a copy of the binaries he does have to give them access to the source on request for 3 years, whether he continues to distribute binaries or not. I can prove I have them---so where's my source?
The answer to that question is that QuakeLives refuses to give me the source---even now. Go get 'em John!
You're not aware I take it that just about every attempt to do something meaningful with the quake source but two or more persons is somehow involved with or connected the QSG if not QuakeForge or both? QSG is the standards body, they're "Linus". QuakeForge is shaping up to be the QSG reference implementation.
The problem is that quake was not designed to assume the client couldn't be trusted, only that the server had to be. The solution is to stop trusting the clients. Any open sourced game developed with open source in mind is going to be written with client untrustability in mind. Quake wasn't, which means everyone will have to update to the latest versions of the cleint and server as soon as we fix the cheating bugs. It's unfortunate, but it's not the end of the world.
Most people aren't cheating. Most people being accused of cheating aren't cheating. Most people complaining about cheating are just sore losers.
It's possible to cheat in quake. It always was. Now that there's source it's relatively easy to do if you grok some C. We'll fix it though, like we would any other bug. So far movement looks like the simplest cheat, but it's also got the simplest solution: let the server calculate movement rather than the client. We're all a lot better off in that case anyway because then nobody can cheat regarding movement. (server side cheats are of course always possible but that's because you have to trust the server...)
It's been discussed that autoaiming aids could be doable, QuakeForge is talking about fixes for that too. And there's also the whole idea of someone faking packets to screw up a player (either to their client claiming to be from the server or the server claiming to be their client..) There are simple fixes for these things too and we'll fix them. There are doubtless other cheats to be found, but we'll fix those too. This isn't exactly a big deal.
Yesterday someone came onto the QuakeForge irc development channel and pointed out the first quake cheat we've seen yet. The movement multiplier. Change it and you can move as fast as you want independant of the server's limits. It's surely not going to be the last such cheat.
QuakeForge is already discussing this problem and is planning to fix it WITHOUT requiring a closed source solution because we believe any closed source solution could at best be considered a stopgap measure. We will be coordinating our efforts to fix the problem with the Quake Standards Group. Any ways we discover in which cheating is possible will be fixed as soon as we discover the nature of the problem and the best course of action to correct it.
In the meantime we'd like to ask everyone to consider that at least half of the reports of people cheating are probably false alarms anyway. There are real problems in how the client and server trust eachother at the moment which are bound to lead to some problems now that it's possible to modify the clients, but they're certainly not fatal to quake as a game or the quake development projects such as QuakeForge.
I expect we will start seeing a rise in BBSes again because it's becoming possible to set them up again. Most people today have access to fast enough connections that allowing a few users to log on to a BBS over the internet is no longer impractical. The BBSes can probably never be quite what they were (what use is ZModem today? Message bases are probably going to be stored in NNTP format, etc) but there are too many people who miss them for them not to start reappearing.
I have to get about as close as advertised to my screen as it is because of my vision. I have to stop now and then but I don't get headaches often at about 6-8 inches.
As for reading through a magnifying glass, I use an 8x and I can read through it 5-10 minutes without headaches. No more.
Some companies would argue that point, and the WIPO will support their arguments by legalizing such monstrosities. However, that has not gone into effect yet and until it does, it is my layman's understanding that you are absolutely correct in your belief that they cannont retroactively relicense their software.
HOWEVER, this does not prevent them from granting blanket permission to anyone to use UC Berkeley-Copyrighted code under the old license (this does not include things such as Apache for example but would affect things such as ash, the BSD/bin/sh) under the new one.
AFAIK, the FreeBSD project at least is already using a 3-clause BSD license for new code, but they could not previously grant use of the original BSD code under those terms---not that it really matters to them from a legal standpoint, but the advertising clause IS somewhat inconvenient and ineffectual IMO. Where this change REALLY benefits anyone (and the reason Richard Stallman was pushing for it) is in terms of GPL compatibility. The new BSD license is compatible with the GPL. This means libreadline linked bash, among other things.
I think Red Hat still understands the spirit. Of course they have to put profits first, so they have to include free-to-use-but-non-free software on the CDs because they have to make a profit.
Two big examples... Netscape and pine. Netscape doesn't even have source code (Mozilla is a very different animal) and pine doesn't allow one of the essentials of free software--the right to distribute modified versions. (In the case of pine some changes have been made and sooner or later if someone else doesn't I'll write to UW and ask them to make it say what the mean and maybe Debian might be able to distribute it too---possibly even in main)
Slashdot Mirror
Read my profile, it'll tell you what I do.
Subject line says it all. It's all they can be expected to do. If they have trouble doing it then they have trouble. But right now they're denying there's a problem, much less trying to fix it.
Perhaps once what they did could have been unintentional. However the fact is that they have taken not a single step to correct this after THREE YEARS in some cases. If this were Microsoft and not Joe Linux Hacker, you'd expect it resolved in THREE DAYS.
It's only libel if it's false and I know it to be false. However, I've proven it to be true right here.
In other words, Mr. Bastian, fuck off. I will not be silenced by legal threats from a meta-organization that doesn't even exist as a legal entity.
Section 3 of the QPL reads:
Modifications must be seperate, ie patches or CVS or something, from the source code itself.. That's a restriction the GPL doesn't have, to be sure. Now let's look at the GPL itself, shall we?
All we have to do is satisfy sections 1 and 2 and make source available under the provisions in section 3. But let's have a look at section 2(b):Here's the classic dilemma. Binaries are okay as long as the whole thing is under the GPL's terms. The GPL does provide an exceoption for system libraries, but that exception doesn't apply if the system libraries are being distributed at the same time as kghostscript, so it does not apply to Qt.
You could argue that Qt is not part of the binary because it is dynamically linked. But Qt's headers and macros are linked in at compile time. And even then, a court would have to view dynamic linking the same as static linking if it were being used as a mechanism to thwart the license of the GPL'd application. Another point from the GPL:
Any other agreement includes the terms of the QPL. Because we cannot satisfy both the QPL and GPL, we cannot distribute the program at all. And not only can we not, but KDE can not as well. Neither can Red Hat or SuSE or Mandrake for that matter. To do otherwise is a violation of Copyright law, whether or not you're likely to face a lawsuit (or even criminal charges under the DMCA!)
I did my homework, believe me.
Faced with these risks, should I willfully violate Copyright licenses? Not likely! Debian agrees. You want Debian to break the law?
This should probably be 5, Informative IMO because it's dead on. As I've said about as many times as I spent working on this (which means I no longer have any idea other than "a lot"), it's NOT a matter of KDE being non-free or Qt being non-free. KDE is GPL'd and Qt's QPL satisfies our Free Software Guidelines (which are the origin of the Open Source Definition), so Qt v2 IS free software.
The whole crux of the problem lies in KDE's use of code under the GPL which they did not write and have not right to change the license of. If you write some code and put it under a given license, I don't have the right to change your code's license to suit my needs. KDE has done precisely this in spirit. In legality, they are simply committing Copyright infringement. So is Red Hat and any other distribution distributing KDE. What's interesting is the number of messages from Red Hat employees my editorial has garnered trying to explain how market pressures forced them to include KDE even though they knew the final licenses weren't compatible. They agreed to do this back when Troll Tech was actively talking with me and it looked like the license would be GPL compatible when finished.
Market dynamics are apparently more important than legal and moral reprocussions of Copyright infringement. KDE better hope they don't touch my code.
What is the problem is that KDE has committed Copyright infringement. And they know and admit it, but not publicly. Legally what they're doing is the same as software piracy. Morally? That's for each of us to decide on our own.
GNUStep provides a series of tools for checking and working on these proplist files, which somewhat resemble configuration for perl scripts IMO. Anyway, it's a good format that seems to be what everyone drooling about XML was after, and it's got a longer history. It's worth looking at if you happen to like the way wmaker's configs are stored.
The project is probably a bigger undertaking than QuakeForge itself, and really needs more talented people so it can really take off.
This isn't necessarily a bad idea. It's not easy to implement, but if possible I agree the host environment should be a major consideration when chosing installation defaults.
I want a replacement or two, that's for sure! I've had my ass saved more than once by that thing.
The QWF people even offered to help Slade implement their techniques if it would guarantee GPL compliance. Their offer was declined. I made a similar offer. Also declined.
I don't have much sympathy for the guy anymore. He's where he is because this is where he's decided to be. He's also stated that he intends to fight you in court if necessary on this, going so far as to say he may sue you for slander.
The QuakeWorld Forever project is using encryption to protect the game while still maintaining compliance with the GPL. Their model currently allows one key, but they're not finished yet. It will allow public key cryptography before they're done, just as you suggest here. I don't know if they've considered key trust levels yet though.
QuakeLives has far more PR people than programmers. FAR more. We're talking something close to a 4:1 ratio here.
The answer to that question is that QuakeLives refuses to give me the source---even now. Go get 'em John!
You're not aware I take it that just about every attempt to do something meaningful with the quake source but two or more persons is somehow involved with or connected the QSG if not QuakeForge or both? QSG is the standards body, they're "Linus". QuakeForge is shaping up to be the QSG reference implementation.
The problem is that quake was not designed to assume the client couldn't be trusted, only that the server had to be. The solution is to stop trusting the clients. Any open sourced game developed with open source in mind is going to be written with client untrustability in mind. Quake wasn't, which means everyone will have to update to the latest versions of the cleint and server as soon as we fix the cheating bugs. It's unfortunate, but it's not the end of the world.
It's possible to cheat in quake. It always was. Now that there's source it's relatively easy to do if you grok some C. We'll fix it though, like we would any other bug. So far movement looks like the simplest cheat, but it's also got the simplest solution: let the server calculate movement rather than the client. We're all a lot better off in that case anyway because then nobody can cheat regarding movement. (server side cheats are of course always possible but that's because you have to trust the server...)
It's been discussed that autoaiming aids could be doable, QuakeForge is talking about fixes for that too. And there's also the whole idea of someone faking packets to screw up a player (either to their client claiming to be from the server or the server claiming to be their client..) There are simple fixes for these things too and we'll fix them. There are doubtless other cheats to be found, but we'll fix those too. This isn't exactly a big deal.
QuakeForge is already discussing this problem and is planning to fix it WITHOUT requiring a closed source solution because we believe any closed source solution could at best be considered a stopgap measure. We will be coordinating our efforts to fix the problem with the Quake Standards Group. Any ways we discover in which cheating is possible will be fixed as soon as we discover the nature of the problem and the best course of action to correct it.
In the meantime we'd like to ask everyone to consider that at least half of the reports of people cheating are probably false alarms anyway. There are real problems in how the client and server trust eachother at the moment which are bound to lead to some problems now that it's possible to modify the clients, but they're certainly not fatal to quake as a game or the quake development projects such as QuakeForge.
I expect we will start seeing a rise in BBSes again because it's becoming possible to set them up again. Most people today have access to fast enough connections that allowing a few users to log on to a BBS over the internet is no longer impractical. The BBSes can probably never be quite what they were (what use is ZModem today? Message bases are probably going to be stored in NNTP format, etc) but there are too many people who miss them for them not to start reappearing.
As for reading through a magnifying glass, I use an 8x and I can read through it 5-10 minutes without headaches. No more.
HOWEVER, this does not prevent them from granting blanket permission to anyone to use UC Berkeley-Copyrighted code under the old license (this does not include things such as Apache for example but would affect things such as ash, the BSD /bin/sh) under the new one.
AFAIK, the FreeBSD project at least is already using a 3-clause BSD license for new code, but they could not previously grant use of the original BSD code under those terms---not that it really matters to them from a legal standpoint, but the advertising clause IS somewhat inconvenient and ineffectual IMO. Where this change REALLY benefits anyone (and the reason Richard Stallman was pushing for it) is in terms of GPL compatibility. The new BSD license is compatible with the GPL. This means libreadline linked bash, among other things.
Two big examples... Netscape and pine. Netscape doesn't even have source code (Mozilla is a very different animal) and pine doesn't allow one of the essentials of free software--the right to distribute modified versions. (In the case of pine some changes have been made and sooner or later if someone else doesn't I'll write to UW and ask them to make it say what the mean and maybe Debian might be able to distribute it too---possibly even in main)
Of course mutt is still more nifty than pine. =D