Yep, that would be exactly right, as far as I know:). KDE is ok for linking to Qt under the system component exception then, and that clause only states that you may not distribute them together (the non-GPL-compatible component and the GPL software that uses the component). Anyone else may ship it for debian (commercial unix vendors traditionally distribute these things as addons that have to be separately ordered or downloaded to make it clear that they do not accompany the OS, so debian could likely do that too).
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.
--snip--
Unless that component itself accompanies the executable. If you distribute Qt as a system component it most certainly accompanies the executable if you distribute KDE together with it.
This isnt as much an issue with Qt as it is with truly proprietary libraries. It was more to illustrate why the GPL is the way it is; Qt and KDE is mostly just an unfortunate causualty of carelessness regarding licenses.
Qt could, theoretically, be forked and development could continue with patches or an entirely free version (I dont remember the exact legal setup of that).
GTK, if they changed (unlikely, many authors and no single copyright holder there), could be forked with no problem and a free branch continue, like with all lgpl libraries.
A truly proprietary toolkit couldnt be forked, and it is mostly those the GPL is worded to prevent linking with.
The GPL allows you to link your software with restrictive libraries if they are system components, _BUT_ then you may _NOT_ distribute that software with the system.
You can consider Qt a system library however much you wish. That makes it legal to distribute KDE. But, it also makes it explicitly illegal to distribute KDE together with the OS.
Except, of course, that in most large corporations obtaining purchasing orders will waste you several months of development time while the red tape runs.
No, no, no, no and no. You may NOT distribute anything qualifying under system component exception _with_ the system. Sure, ship Qt as a system library, but then it is a VIOLATION to ship KDE together with it.
Just like Solaris cannot legally include any GPL software.
The GPL would work fine for that. As long as you retain sole ownership of the code, you can sell copies to proprietary vendors with whatever license you like. Just dont ever include other peoples code unless you obtain the copyright for it.
If you are licensing your software under the QPL on the other hand, no GPL application will be able to link against it.
But it doesnt MATTER if Qt is a system component or not! If it qualifies under the exception, KDE may NOT (I repeat, NOT NOT NOT) be distributed together with the OS!
Again, YOU MAY NOT distribute code that qualifies under system component exception together with the system!
The other distribution vendors are still violating the GPL license, whereever they place Qt.
The purpose of the GPL is to _keep_ free software free. Imagine you have a free desktop environment that depends on a semi-free toolkit. Imagine the toolkit vendor decides to go completely proprietary and charge $1000 per copy of the toolkit.
How 'free' is that free desktop environment really? Both in beer and the freedom from proprietary control?
5) In which case they may not distribute KDE with Debian. Read the GPL again, you may _not_ ship software that is 'ok' under system library exception _with_ the system.
6) Umm... or, hey, why not pretend that blue is green? I have yet to see a solid 'interpretation' that would make this problem go away. The 'I want this to mean that wether it does or not so Im gonna argue until I faint' interpretation style doesnt count.
7) I cant really see how Debian gains from not including KDE (except from the purely legal standpoint).
Yes, KDE using the GPL was a serious mistake. It should be corrected. KDE using other peoples GPL code was an even huger mistake, which made it very difficult to correct the first mistake.
It is a whole other kettle of fish. KDE does include GPL code not written by the KDE team, which is why they cannot just change the license and be done with the whole issue.
Re:My favorite quote...
on
Napster Wars
·
· Score: 1
Oh, I'd like to see some more;
* % of non Napsterers who pretty much figure: This Sucks and I'm not buying this crap even if I can afford to buy 50 times the number of CD's I could when there was anything worth buying.
Id be that category at least. And I dont think I've seen anything I liked from a big label in years. Maybe, just maaaaybe, their sales decline because they dont sell anything worth buying anymore?
Since the quality of media in general and the stuff that the big four promotes in particular is about, well, zero, big loss.
The general idea of the unnatural creation of the intellectual property concept was that consumers would get more high quality works. That has, it seems, failed to a point where I, at least, start thinking that at least a 10 or 20 year moratorium on the entire concept of intellectual property might not be a bad idea to bludgeon it into the heads of those in control that the concept is _not_ there for their sake and if they abuse the IP laws they can lose it all.
True. Heck, we have a couple of SCO boxes standing around. They're on the 'Hey, new guy, here's your first project, upgrade these things and then you're responsible for them until the next suck.. err new employee comes along' list.
Of course, we'd like to get rid of them but the applications running on them run only on SCO or NT, and, well, both sorta stink, but one of those certainly stinks more.
1) No. (No license that Im sure of offhand, altho you may be breaking some of Microsofts licenses which require you to only run Word on a Microsoft OS, or something similar, if you try to run it under Wine.)
2) Yes (if you distribute the CD). For GPL software that is linked agaist non GPL compliant libraries such as Qt under the system component exception clause, you may not distribute the software together with the OS.
3) Probably not, altho such a license wouldnt be unthinkable.
I dont really care about the ad banners themselves; I rarely watch them. I _do_ care that the junk stays stealing cpu cycles from my computer as long as the pages stay up because they're full of icky animations. And I do _definitely_ care when the freaking banners include java crap and stuff that makes my browser barf or get redirected or other shit because the damn banners arent compatible with java script turned off or just plain broken. That lands a banner site in junkbusting land faster than it can spew another piece of junk over my connection.
Regarding section 3; Qt is a part of the program covered by the GPL. You cannot use the program without having Qt.
The GPL does make the OS component exception, BUT you may NOT then distribute the GPL program WITH the OS. Thus, Debian cannot distribute both Qt _and_ KDE as part of the OS.
Qt is part of the Program as a whole. Qt is not relicensed under the GPL, neither is Qt restricted by the GPL license (go ahead and distribute Qt all you want acording to the QPL), but the Program as a whole, including Qt must be distributable under the TERMS of the GPL. As long as the QPL contains terms that are not compatible with the GPL, you end up with an aggregate of both licenses that is not distributable.
Either way the real point is, why do people argue this? Personally, I must say it offends me deeply that some _argue_ these points instead of accepting what both the writer of the license and many free software developers say were the intent and is the actual wording of the license? Why not obtain permission when needed and discard code where permission will not be forthcoming? I have read the GPL back and forth and upside down and come to the same conclusion every time. You cannot legally distribute KDE with an operating system as long as some code remains under unchanged GPL or the QPL is not amended.
Further, if I was not asked permission (in which case I would likely grant it) and found a KDE port of one of my programs, this very attitude makes sure that I _would_ take legal action.
There is. Harmony. Of course, Troll Tech have said that they are likely to sue if such a project completes, and interest from coders seems to be lacking (those that code for KDE seem to wish to ignore the issue or write exception clauses to GPL software if they hold the copyright, those that are aware of the issue use other toolkits instead).
So you'll have to find a core of dedicated people who wish to use a LGPL Qt, arent afraid to be sued by Troll Tech and for some reason dont want to use the other available toolkits.
That is irrelevant. If you hold the rights to the code you can change the GPL to allow an exception. The GPL means to prevent those that DO wish to combine GPL code (that they do not hold copyright to) with proprietary code.
Lets put it the other way around. A company that makes device D needs a program. They do not want to pay for the development so they simply take your program X, modify it a bit to link it to their libraries, and sell it. The modified code is useless without their proprietary libraries, so they have essentially locked up your program code into depending on their proprietary libraries.
If you write a program and GPL you _have_ to make the exception that is needed here. If, as is the case of some of the KDE code, _you_ didnt write some of the code to the GPL program, you cannot change the license. And so the problem remains.
If the maker of a device will not use the GPL you need to explicitly allow linking against their library. You should do that if you need the library to make your GPL program work.
But dont come and say that I should allow _my_ GPL code to be linked against someones proprietary library, because I actually read the licenses I place my code under and choose one that accomplishes what I want. And, with my GPL code, I dont want it used to further sales of proprietary libraries.
This isnt restricting GNU programmers, this is protecting GPL programs against proprietary misuse. If you find it restrictive, read your licenses before you use them.
Exactly right. You cannot link GPL code to closed libraries. The Program as a WHOLE, including libraries it depends on, MUST be able to fulfill all terms of the GPL to be distributed. Dynamically linked libraries are considered part of the program. You cannot create a bunch of proprietary libraries and then snarf GPL code to provide a framework around them; for example, selling a proprietary data format encoder/decoder for a GPL soundplayer or something.
EXCEPT for the operating system exception clause. If, and only if, a library can be (very strictly, think libc, not widget lib x from Bobbys Linux Distro) considered a part of the operating system, then you may link to it without it having to be license compatible with the GPL.
That way, you can write GPL programs for Windows or commercial unixes, but you cannot abuse GPL code and just separate it from a proprietary program/library by isolating either entity with dynamic linking.
Basic checking would be to run an rpm verify if you're using an rpm based system. Better would be if you'd run a tripwire session in the beginning and you had correct checksums stored elsewhere.
Otherwise, scan the logs, run a find through your system for any suid files and check if they are what they're supposed to be, check all.history files on the system (heh, some guy who hacked a user account on one of my machines many years ago missed cleaning that one). Run COPS or similar tools. Check all security related config files.
Any of which can show you that you have been compromized, none of which will prove you havent.
All of which will take far far longer than reinstalling.
Slashdot Mirror
Yep, that would be exactly right, as far as I know :). KDE is ok for linking to Qt under the system component exception then, and that clause only states that you may not distribute them together (the non-GPL-compatible component and the GPL software that uses the component). Anyone else may ship it for debian (commercial unix vendors traditionally distribute these things as addons that have to be separately ordered or downloaded to make it clear that they do not accompany the OS, so debian could likely do that too).
Read the license again:
--snip--
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.
--snip--
Unless that component itself accompanies the executable. If you distribute Qt as a system component it most certainly accompanies the executable if you distribute KDE together with it.
Hehe, oops. Must have more coffee.:)
This isnt as much an issue with Qt as it is with truly proprietary libraries. It was more to illustrate why the GPL is the way it is; Qt and KDE is mostly just an unfortunate causualty of carelessness regarding licenses.
Qt could, theoretically, be forked and development could continue with patches or an entirely free version (I dont remember the exact legal setup of that).
GTK, if they changed (unlikely, many authors and no single copyright holder there), could be forked with no problem and a free branch continue, like with all lgpl libraries.
A truly proprietary toolkit couldnt be forked, and it is mostly those the GPL is worded to prevent linking with.
The GPL allows you to link your software with restrictive libraries if they are system components, _BUT_ then you may _NOT_ distribute that software with the system.
You can consider Qt a system library however much you wish. That makes it legal to distribute KDE. But, it also makes it explicitly illegal to distribute KDE together with the OS.
Except, of course, that in most large corporations obtaining purchasing orders will waste you several months of development time while the red tape runs.
No, no, no, no and no. You may NOT distribute anything qualifying under system component exception _with_ the system. Sure, ship Qt as a system library, but then it is a VIOLATION to ship KDE together with it.
Just like Solaris cannot legally include any GPL software.
The GPL would work fine for that. As long as you retain sole ownership of the code, you can sell copies to proprietary vendors with whatever license you like. Just dont ever include other peoples code unless you obtain the copyright for it.
If you are licensing your software under the QPL on the other hand, no GPL application will be able to link against it.
But it doesnt MATTER if Qt is a system component or not! If it qualifies under the exception, KDE may NOT (I repeat, NOT NOT NOT) be distributed together with the OS!
Again, YOU MAY NOT distribute code that qualifies under system component exception together with the system!
The other distribution vendors are still violating the GPL license, whereever they place Qt.
The purpose of the GPL is to _keep_ free software free. Imagine you have a free desktop environment that depends on a semi-free toolkit. Imagine the toolkit vendor decides to go completely proprietary and charge $1000 per copy of the toolkit.
How 'free' is that free desktop environment really? Both in beer and the freedom from proprietary control?
Yay, and we get MicroSoft Kerberos which is really appropriated free kerberos code with added incompatibility? Sounds grrrreat. Or not.
RMS was, to put it your way, so fucking tired of people taking free code and making it proprietary. Which is what the GPL prevents.
5) In which case they may not distribute KDE with Debian. Read the GPL again, you may _not_ ship software that is 'ok' under system library exception _with_ the system.
6) Umm... or, hey, why not pretend that blue is green? I have yet to see a solid 'interpretation' that would make this problem go away. The 'I want this to mean that wether it does or not so Im gonna argue until I faint' interpretation style doesnt count.
7) I cant really see how Debian gains from not including KDE (except from the purely legal standpoint).
Yes, KDE using the GPL was a serious mistake. It should be corrected. KDE using other peoples GPL code was an even huger mistake, which made it very difficult to correct the first mistake.
It is a whole other kettle of fish. KDE does include GPL code not written by the KDE team, which is why they cannot just change the license and be done with the whole issue.
Oh, I'd like to see some more;
* % of non Napsterers who pretty much figure: This Sucks and I'm not buying this crap even if I can afford to buy 50 times the number of CD's I could when there was anything worth buying.
Id be that category at least. And I dont think I've seen anything I liked from a big label in years. Maybe, just maaaaybe, their sales decline because they dont sell anything worth buying anymore?
Since the quality of media in general and the stuff that the big four promotes in particular is about, well, zero, big loss.
The general idea of the unnatural creation of the intellectual property concept was that consumers would get more high quality works. That has, it seems, failed to a point where I, at least, start thinking that at least a 10 or 20 year moratorium on the entire concept of intellectual property might not be a bad idea to bludgeon it into the heads of those in control that the concept is _not_ there for their sake and if they abuse the IP laws they can lose it all.
True. Heck, we have a couple of SCO boxes standing around. They're on the 'Hey, new guy, here's your first project, upgrade these things and then you're responsible for them until the next suck.. err new employee comes along' list.
Of course, we'd like to get rid of them but the applications running on them run only on SCO or NT, and, well, both sorta stink, but one of those certainly stinks more.
Actually, it _was_ IBM. But they got a solid spanking in the corporate behind by the trustbuster team...
1) No. (No license that Im sure of offhand, altho you may be breaking some of Microsofts licenses which require you to only run Word on a Microsoft OS, or something similar, if you try to run it under Wine.)
2) Yes (if you distribute the CD). For GPL software that is linked agaist non GPL compliant libraries such as Qt under the system component exception clause, you may not distribute the software together with the OS.
3) Probably not, altho such a license wouldnt be unthinkable.
I dont really care about the ad banners themselves; I rarely watch them. I _do_ care that the junk stays stealing cpu cycles from my computer as long as the pages stay up because they're full of icky animations. And I do _definitely_ care when the freaking banners include java crap and stuff that makes my browser barf or get redirected or other shit because the damn banners arent compatible with java script turned off or just plain broken. That lands a banner site in junkbusting land faster than it can spew another piece of junk over my connection.
Regarding section 3; Qt is a part of the program covered by the GPL. You cannot use the program without having Qt.
The GPL does make the OS component exception, BUT you may NOT then distribute the GPL program WITH the OS. Thus, Debian cannot distribute both Qt _and_ KDE as part of the OS.
Qt is part of the Program as a whole. Qt is not relicensed under the GPL, neither is Qt restricted by the GPL license (go ahead and distribute Qt all you want acording to the QPL), but the Program as a whole, including Qt must be distributable under the TERMS of the GPL. As long as the QPL contains terms that are not compatible with the GPL, you end up with an aggregate of both licenses that is not distributable.
Either way the real point is, why do people argue this? Personally, I must say it offends me deeply that some _argue_ these points instead of accepting what both the writer of the license and many free software developers say were the intent and is the actual wording of the license? Why not obtain permission when needed and discard code where permission will not be forthcoming? I have read the GPL back and forth and upside down and come to the same conclusion every time. You cannot legally distribute KDE with an operating system as long as some code remains under unchanged GPL or the QPL is not amended.
Further, if I was not asked permission (in which case I would likely grant it) and found a KDE port of one of my programs, this very attitude makes sure that I _would_ take legal action.
There is. Harmony. Of course, Troll Tech have said that they are likely to sue if such a project completes, and interest from coders seems to be lacking (those that code for KDE seem to wish to ignore the issue or write exception clauses to GPL software if they hold the copyright, those that are aware of the issue use other toolkits instead).
So you'll have to find a core of dedicated people who wish to use a LGPL Qt, arent afraid to be sued by Troll Tech and for some reason dont want to use the other available toolkits.
That is irrelevant. If you hold the rights to the code you can change the GPL to allow an exception. The GPL means to prevent those that DO wish to combine GPL code (that they do not hold copyright to) with proprietary code.
Lets put it the other way around. A company that makes device D needs a program. They do not want to pay for the development so they simply take your program X, modify it a bit to link it to their libraries, and sell it. The modified code is useless without their proprietary libraries, so they have essentially locked up your program code into depending on their proprietary libraries.
If you write a program and GPL you _have_ to make the exception that is needed here. If, as is the case of some of the KDE code, _you_ didnt write some of the code to the GPL program, you cannot change the license. And so the problem remains.
If the maker of a device will not use the GPL you need to explicitly allow linking against their library. You should do that if you need the library to make your GPL program work.
But dont come and say that I should allow _my_ GPL code to be linked against someones proprietary library, because I actually read the licenses I place my code under and choose one that accomplishes what I want. And, with my GPL code, I dont want it used to further sales of proprietary libraries.
This isnt restricting GNU programmers, this is protecting GPL programs against proprietary misuse. If you find it restrictive, read your licenses before you use them.
Exactly right. You cannot link GPL code to closed libraries. The Program as a WHOLE, including libraries it depends on, MUST be able to fulfill all terms of the GPL to be distributed. Dynamically linked libraries are considered part of the program. You cannot create a bunch of proprietary libraries and then snarf GPL code to provide a framework around them; for example, selling a proprietary data format encoder/decoder for a GPL soundplayer or something.
EXCEPT for the operating system exception clause. If, and only if, a library can be (very strictly, think libc, not widget lib x from Bobbys Linux Distro) considered a part of the operating system, then you may link to it without it having to be license compatible with the GPL.
That way, you can write GPL programs for Windows or commercial unixes, but you cannot abuse GPL code and just separate it from a proprietary program/library by isolating either entity with dynamic linking.
Basic checking would be to run an rpm verify if you're using an rpm based system. Better would be if you'd run a tripwire session in the beginning and you had correct checksums stored elsewhere.
.history files on the system (heh, some guy who hacked a user account on one of my machines many years ago missed cleaning that one). Run COPS or similar tools. Check all security related config files.
Otherwise, scan the logs, run a find through your system for any suid files and check if they are what they're supposed to be, check all
Any of which can show you that you have been compromized, none of which will prove you havent.
All of which will take far far longer than reinstalling.