It is certainly true that the GPL does not require linked code to be GPLed. However, it does require that code linked to GPLed code (subject to the "system library" exemption) impose no more restrictions than the GPL itself does. Thus, the GPL is compatible with a number of licenses, including (I believe) the new BSD, X, Apache, and Artistic licenses.
The QPL is not compatible with the GPL because it imposes additional restrictions on distribution: Troll Tech can demand that you give them a copy, with source, and you have no choice but to comply.
If the KDE project included third-party GPLed software in KDE without permission, is that the fault of the third parties? Or of Debian? As I remember, this was the major complaint from the GIMP people; the KIMP people seemed to feel it was their right to violate the GPL on the GIMP by linking it to Qt, and they didn't even bother to discuss it with the GIMP people. The archives even contain some discussion about making the GIMP toolkit-independent and adding the license exception; I think this petered out after KDE showed their utter disregard for the rights of the GIMP team.
As for what KDE needs to do to "appease" Debian, the clause in the offer is what Debian has repeatedly asked for from KDE since the adoption of the QPL. This has not changed, ever. Official Debian developers have even developed packages, and the whole team stands ready to incorporate KDE the moment the license is changed - again, as we have been since the QPL was adopted.
As I have said before, so I say again: licenses are important. It's stupid to make your stated wishes on your software incoherent, and it's rude (not to mention illegal) to ignore other people's stated wishes on their software out of convenience. Other people may be able to accept the risk that results from such stupidity and rudeness; Debian is not in a position to do so. But isn't it better to just stop being stupid and rude?
In that case, you chose the wrong license for your software. You'd likely be happier with the LGPL, or some other license. Or, if you really like the GPL otherwise, you could include an exemption like the one proposed here.
The license is your statement of what you allow other people to do with your software. If the GPL doesn't respect your wishes, don't use it.
The GPL includes an exemption for code that is considered to be "system libraries", but adds a clause that the "system libraries" and the executable itself cannot be distributed together.
So, to use your example, it is perfectly legal to write GPLed Windows programs, or to port a GPLed program to Windows (GNU Emacs has been ported; do you think RMS would stand for this if it weren't?). But, it wouldn't be legal for Microsoft to distribute those programs as a part of Windows.
Debian already has this. It's called "contrib". This is what allows, for example, LyX to be distributed, even though it links with the non-free Xforms. (apologies if this is inaccurate; it was true at one time).
The problem with KDE is that the licenses are logically inconsistent. Debian's position is that there is no coherent license for the distribution of KDE at all. This is as opposed to the LyX issue above; the LyX people added a suitable exemption from the GPL.
Once the exemption is included, then KDE could ship in main, since KDE itself is DFSG-compliant and Qt is also DFSG-compliant. This would make KDE just as much a part of Debian as GNOME.
Back when KDE was developed, GTK didn't even exist. The KDE team was asked about the license problems; their response was basically "we think Qt is great software, go take your lawyers and go home".
This is a good object lesson in how attention to detail is important. The problem here is that the KDE authors' stated wishes are logically incoherent. Had they picked something like the X or Artistic licenses back then, or added the exception clause, many of the problems we've had since would've been avoided.
This is mostly correct, as I understand it; any third-party GPL code would have to include the exception as well.
As an aside, if the KDE app were de-KDEized (say, by rewriting it for GNOME), the GPL-with-exception code would be license-compatible with other straight-GPL code. The sole problem is linking with Qt.
The basic idea (as I understand it) is that the QPL requires that any software developed that links to Qt Free must be given to Troll Tech, with source, upon their request. This is an "additional restriction" to the terms of the GPL (the GPL doesn't require you to distribute to anyone, only to distribute source whenever you do distribute), which is prohibited by the GPL.
It does make it kind of disingenuous, though, to talk big about "protecting the small inventor" while at the same time requiring you to hire a big-time lawyer just to get anything done.
So let's not pretend that the patent system is about its original purpose (encouraging innovation) or about "helping the little guy" (as Dickenson would have us believe). Let's just admit that patents exist to help rich guys get richer at the expense of poor bright people, and be done with it.
If these people are worried about the reliability of sendmail, then Exchange is going to be about the worst move they make.
OTOH, it sounds like the "single mail message lost" thing is more of an excuse than anything else. Sendmail can be a pain to manage.
I've just implemented a mail solution for escorting mail safely from the Internet to an internal Exchange Server using Postfix and LDAP. It's actually quite easy; everything works well, and can be administered from a Windows box with a GUI. (Admittedly, the GUI is a bit clunky, but it's still usable until better alternatives become available.) Users can have Internet ability granted or revoked, groups can be set up, and mail can be forwarded. The system even does virus checking on inbound E-mail!
In short: you don't have to sacrifice the reliability of Linux/*BSD in order to get ease of maintenance.
The free software movement has always had rifts like this. Look at Emacs vs. XEmacs, or the controversy over NET2 when Alan Cox took over networking from Fred van Kampen, or the sound driver situation of a few years ago, or the political stuff in Debian when Bruce Perens quit.
Happily, it all works out in the end. The Emacs and XEmacs people still do their own things, but they at least try to maintain compatibility. Linux networking generally rocks now, and keeps getting better (as opposed to the 1.0 days when the BSD folks kept beating up Linux for crappy networking). Sound support is improving. Debian is still rolling, and Bruce even comes back around on occasion to help out.
Whatever the money does, I think there will always be a core group that values free software, not to mention the many people who have learned the quality lesson (the only way you can guarantee quality results is to have source). Even if Red Hat, VA, LinuxCare, etc. tank, we'll just go back to the gool ol' days before Jesse Berst knew how to spell Linux, and we had to hack our own device drivers.
You certainly could do that on your own. You'd probably need some form of wrapper script for gcc that would add the necessary options for compiling on your system. You'll also want to add deb-src lines to your/etc/apt/sources.list (see the man page for sources.list for details). Then, a simple:
apt-get -b source dpkg -i
OTOH, I wouldn't think you'd gain much. Most systems today are I/O-bound, not CPU-bound. You might see some benefits from, say, an optimized libc or an optimized kernel, since those components touch everything on the system, as well as any tasks you run that are indeed CPU-bound.
I doubt Debian would do it, though. -m486 is about the best you can do if you want code that runs on everything from the 386 to the Athlon. And we've got enough work to do with the architectures we do support.
As I understand it, the problem isn't just a binary-only driver. It's a brand-new binary-only driver subsystem, that may (or may not - guess which is more likely) cooperate well with other DRI-based stuff, may or may not hamper upgrades to XFree86 4.1, etc.
At least, that's the assumption. We don't know. All we know is that NVidia isn't using DRI to write their binary-only driver, which makes us wonder how the heck they're going to write the driver at all, and whether they'll provide source for any of it.
Of course, no one is suggesting that NVidia is not free to do as they wish, assuming they honor the licenses on the code they use/link to. What is being suggested is that it's bad for someone like NVidia to force their users to go to an all-proprietary solution.
I think Frank said the following would be acceptable from NVidia:
And I would wager he wouldn't have a problem with:
- open-source "different" driver subsystem with closed driver
What NVidia is doing, however, is:
- closed "different" driver subsystem with closed driver
(as far as we know at this point)
As you point out, this causes problems. NVidia cards won't play nice with other vendor's stuff in, for example, dual-head systems. Furthermore, NVidia users may not be able to take advantage of advances in XFree86 until NVidia gets around to porting their driver subsystem to the new stuff.
If other binary-only drivers are any guide, the driver and subsystem will be a piece of crap. Even if the new subsystem is really a good advancement, all the advantages will be overshadowed by the poor implementation (which we won't be able to improve in any way).
Also, and most importantly, any proprietary driver subsystem partially closes the entire system. If it comes to the place where you have to pay NVidia, sign an NDA, or whatever in order to write video drivers for Linux, then how can we claim that Linux is "open" or "free"? And, as Frank pointed out, if we wanted proprietary stunts like this, we'd just stick with Microsoft, who is a lot bigger and has a lot better proprietary support than Linux.
In the MS world, no one seriously suggests implementing a different/new way of doing graphics outside of GDI, DirectX, or OpenGL; the one company that has (3Dfx) eventually abandoned this plan. The reason is simple: no one wants to worry about whether their game or whatever is compatible with your particular video card's preferred graphics API, so the standards are a big win for consumers. Why should it be any different for Linux?
For example, you mention that the NT network doesn't require any administration at all, but you then mention the MCSEs you employ. Aren't they admins?
I'm an NT admin by day, and I can tell you that NT definitely requires administration, and lots of it. I would suspect that the MCSEs you hire are doing more than what you think they are in keeping the NT network humming. And if you hire more than about two MCSEs, you're probably paying more for NT administration than you are for Solaris administration.
There was a study done (sorry - don't have a cite, though it may be findable on the Web) that suggested that Unix admins are more cost-effective than MCSEs, even given their higher compensation. There were many reasons cited - fewer admins needed, greater efficiency, less downtime (planned or not).
That said, I'd have to say that your technical staff is clueless in at least one respect. Anyone who alienates the non-techies in their job is just asking for the axe to be taken to their projects and ideas. Perhaps you should talk to their managers or whoever and educate them on the importance on at least being polite and attempting to explain things. It's not always easy for techies to "dumb down" when explaining things to non-techies (witness your MCSEs), but an honest attempt should be made, at least.
(I've done Linux advocacy in every job I've held since '93, with great success in every case. I've saved my employers money and provided more efficient and reliable service by doing this. This couldn't have happened if I had copped an attitude with all the "suits" I associated with. Most of them may not understand "mbuf kernel modes for async I/O" (ROFL!), but most get the picture with comments like "the NT solution will cost $25,000 and the Linux solution will cost $3500.")
Like the other guy said, E-mail me if you have more questions.
The system library exception in the GPL should cover these cases, as long as the libraries in question are distributed separately from the project itself.
This means no DLL games like the big boys like to play. Personally, I think that's a good idea; as a sysadmin, DLL games are my biggest headache.
Most of this system could be implemented trivially on any Unix. (The copy-on-write stuff, if it exists, might require a kernel module, depending on the implementation's needs.) Take the output of 'find / -type f -print' (adjusted to taste) and pipe to a Perl script which hashes md5sums and file sizes to filenames, then takes matches and creates (sym)links accordingly. If you're really into this idea of a "central store", copy the files to somewhere under/var/spool first.
The main reason this hasn't been written is that most real sysadmins recognize the pitfalls you describe. So, there's no demand for this "feature".
Microsoft Research has done it again! New, from the people who brought you the Office Paperclip: Auto-Backup-Destruction!
That argument would hold water if you consider, say, corporate Web access, or cybercafes, or access terminals at big conferences.
However, most libraries around are government agencies, not private entities. This makes the problem a bit more difficult.
Government-mandated or government-sponsored censorware, you see, ends up becoming a case of your government telling you what you can and cannot see - in other words, a restriction on free speech. For lots of very good reasons, this is illegal.
(Note: It isn't "proposed" to be illegal, or "might" be illegal, it IS illegal. Right now. Making it legal would require nullifying part of the Constitution, too, something that's not easily done.)
Do you want your government telling you what you can and cannot read in the library? Would you be pissed if your (print) book on, say, Mars exploration were banned from the library because the subject contained the letters "s", "e", and "x" in a row? I would.
Slashdot Mirror
The GPL does not require that all software linked to it be GPLed. It merely requires it to be no more restrictive than the GPL.
As has been said numerous times, the QPL is more restrictive than the GPL. Therefore, it is not compatible.
The X and GPL licenses are compatible, while the QPL and GPL are not.
It is certainly true that the GPL does not require linked code to be GPLed. However, it does require that code linked to GPLed code (subject to the "system library" exemption) impose no more restrictions than the GPL itself does. Thus, the GPL is compatible with a number of licenses, including (I believe) the new BSD, X, Apache, and Artistic licenses.
The QPL is not compatible with the GPL because it imposes additional restrictions on distribution: Troll Tech can demand that you give them a copy, with source, and you have no choice but to comply.
If the KDE project included third-party GPLed software in KDE without permission, is that the fault of the third parties? Or of Debian? As I remember, this was the major complaint from the GIMP people; the KIMP people seemed to feel it was their right to violate the GPL on the GIMP by linking it to Qt, and they didn't even bother to discuss it with the GIMP people. The archives even contain some discussion about making the GIMP toolkit-independent and adding the license exception; I think this petered out after KDE showed their utter disregard for the rights of the GIMP team.
As for what KDE needs to do to "appease" Debian, the clause in the offer is what Debian has repeatedly asked for from KDE since the adoption of the QPL. This has not changed, ever. Official Debian developers have even developed packages, and the whole team stands ready to incorporate KDE the moment the license is changed - again, as we have been since the QPL was adopted.
As I have said before, so I say again: licenses are important. It's stupid to make your stated wishes on your software incoherent, and it's rude (not to mention illegal) to ignore other people's stated wishes on their software out of convenience. Other people may be able to accept the risk that results from such stupidity and rudeness; Debian is not in a position to do so. But isn't it better to just stop being stupid and rude?
In that case, you chose the wrong license for your software. You'd likely be happier with the LGPL, or some other license. Or, if you really like the GPL otherwise, you could include an exemption like the one proposed here.
The license is your statement of what you allow other people to do with your software. If the GPL doesn't respect your wishes, don't use it.
The system library exemption doesn't apply if the components are distributed together.
So, it may be legal to make "KDE for Debian", but Debian can't distribute it.
That's a matter of opinion. I don't know what Debian's position on that is, since Qt is now in main (on potato, anyway).
However, it doesn't help in this case, since we still can't distribute KDE in main along with Qt.
http://www.internatif.org/bortzmeyer/debian/apt-so urces/
The GPL includes an exemption for code that is considered to be "system libraries", but adds a clause that the "system libraries" and the executable itself cannot be distributed together.
So, to use your example, it is perfectly legal to write GPLed Windows programs, or to port a GPLed program to Windows (GNU Emacs has been ported; do you think RMS would stand for this if it weren't?). But, it wouldn't be legal for Microsoft to distribute those programs as a part of Windows.
Debian already has this. It's called "contrib". This is what allows, for example, LyX to be distributed, even though it links with the non-free Xforms. (apologies if this is inaccurate; it was true at one time).
The problem with KDE is that the licenses are logically inconsistent. Debian's position is that there is no coherent license for the distribution of KDE at all. This is as opposed to the LyX issue above; the LyX people added a suitable exemption from the GPL.
Once the exemption is included, then KDE could ship in main, since KDE itself is DFSG-compliant and Qt is also DFSG-compliant. This would make KDE just as much a part of Debian as GNOME.
Back when KDE was developed, GTK didn't even exist. The KDE team was asked about the license problems; their response was basically "we think Qt is great software, go take your lawyers and go home".
This is a good object lesson in how attention to detail is important. The problem here is that the KDE authors' stated wishes are logically incoherent. Had they picked something like the X or Artistic licenses back then, or added the exception clause, many of the problems we've had since would've been avoided.
This is mostly correct, as I understand it; any third-party GPL code would have to include the exception as well.
As an aside, if the KDE app were de-KDEized (say, by rewriting it for GNOME), the GPL-with-exception code would be license-compatible with other straight-GPL code. The sole problem is linking with Qt.
Last I had heard, this was not the case. KDE had stated that this is a goal for KDE 2.0.
I could be wrong, though; I confess to not having kept up with it very well.
No; that's what the letter is asking for.
:-)
FWIW, Debian has been asking for the same thing for quite a while now. SPI doesn't have $3k to give to KDE for it, though.
The basic idea (as I understand it) is that the QPL requires that any software developed that links to Qt Free must be given to Troll Tech, with source, upon their request. This is an "additional restriction" to the terms of the GPL (the GPL doesn't require you to distribute to anyone, only to distribute source whenever you do distribute), which is prohibited by the GPL.
Disclaimer: I'm a Debian developer.
It does make it kind of disingenuous, though, to talk big about "protecting the small inventor" while at the same time requiring you to hire a big-time lawyer just to get anything done.
So let's not pretend that the patent system is about its original purpose (encouraging innovation) or about "helping the little guy" (as Dickenson would have us believe). Let's just admit that patents exist to help rich guys get richer at the expense of poor bright people, and be done with it.
If these people are worried about the reliability of sendmail, then Exchange is going to be about the worst move they make.
OTOH, it sounds like the "single mail message lost" thing is more of an excuse than anything else. Sendmail can be a pain to manage.
I've just implemented a mail solution for escorting mail safely from the Internet to an internal Exchange Server using Postfix and LDAP. It's actually quite easy; everything works well, and can be administered from a Windows box with a GUI. (Admittedly, the GUI is a bit clunky, but it's still usable until better alternatives become available.) Users can have Internet ability granted or revoked, groups can be set up, and mail can be forwarded. The system even does virus checking on inbound E-mail!
In short: you don't have to sacrifice the reliability of Linux/*BSD in order to get ease of maintenance.
Perhaps, perhaps not.
The free software movement has always had rifts like this. Look at Emacs vs. XEmacs, or the controversy over NET2 when Alan Cox took over networking from Fred van Kampen, or the sound driver situation of a few years ago, or the political stuff in Debian when Bruce Perens quit.
Happily, it all works out in the end. The Emacs and XEmacs people still do their own things, but they at least try to maintain compatibility. Linux networking generally rocks now, and keeps getting better (as opposed to the 1.0 days when the BSD folks kept beating up Linux for crappy networking). Sound support is improving. Debian is still rolling, and Bruce even comes back around on occasion to help out.
Whatever the money does, I think there will always be a core group that values free software, not to mention the many people who have learned the quality lesson (the only way you can guarantee quality results is to have source). Even if Red Hat, VA, LinuxCare, etc. tank, we'll just go back to the gool ol' days before Jesse Berst knew how to spell Linux, and we had to hack our own device drivers.
You certainly could do that on your own. You'd probably need some form of wrapper script for gcc that would add the necessary options for compiling on your system. You'll also want to add deb-src lines to your /etc/apt/sources.list (see the man page for sources.list for details). Then, a simple:
apt-get -b source
dpkg -i
OTOH, I wouldn't think you'd gain much. Most systems today are I/O-bound, not CPU-bound. You might see some benefits from, say, an optimized libc or an optimized kernel, since those components touch everything on the system, as well as any tasks you run that are indeed CPU-bound.
I doubt Debian would do it, though. -m486 is about the best you can do if you want code that runs on everything from the 386 to the Athlon. And we've got enough work to do with the architectures we do support.
His body is, uh, missing.
:-)
As I understand it, the problem isn't just a binary-only driver. It's a brand-new binary-only driver subsystem, that may (or may not - guess which is more likely) cooperate well with other DRI-based stuff, may or may not hamper upgrades to XFree86 4.1, etc.
At least, that's the assumption. We don't know. All we know is that NVidia isn't using DRI to write their binary-only driver, which makes us wonder how the heck they're going to write the driver at all, and whether they'll provide source for any of it.
Of course, no one is suggesting that NVidia is not free to do as they wish, assuming they honor the licenses on the code they use/link to. What is being suggested is that it's bad for someone like NVidia to force their users to go to an all-proprietary solution.
I think Frank said the following would be acceptable from NVidia:
- open-source DRI driver (obviously)
- closed DRI driver
- open-source "different" driver subsystem
And I would wager he wouldn't have a problem with:
- open-source "different" driver subsystem with closed driver
What NVidia is doing, however, is:
- closed "different" driver subsystem with closed driver
(as far as we know at this point)
As you point out, this causes problems. NVidia cards won't play nice with other vendor's stuff in, for example, dual-head systems. Furthermore, NVidia users may not be able to take advantage of advances in XFree86 until NVidia gets around to porting their driver subsystem to the new stuff.
If other binary-only drivers are any guide, the driver and subsystem will be a piece of crap. Even if the new subsystem is really a good advancement, all the advantages will be overshadowed by the poor implementation (which we won't be able to improve in any way).
Also, and most importantly, any proprietary driver subsystem partially closes the entire system. If it comes to the place where you have to pay NVidia, sign an NDA, or whatever in order to write video drivers for Linux, then how can we claim that Linux is "open" or "free"? And, as Frank pointed out, if we wanted proprietary stunts like this, we'd just stick with Microsoft, who is a lot bigger and has a lot better proprietary support than Linux.
In the MS world, no one seriously suggests implementing a different/new way of doing graphics outside of GDI, DirectX, or OpenGL; the one company that has (3Dfx) eventually abandoned this plan. The reason is simple: no one wants to worry about whether their game or whatever is compatible with your particular video card's preferred graphics API, so the standards are a big win for consumers. Why should it be any different for Linux?
For example, you mention that the NT network doesn't require any administration at all, but you then mention the MCSEs you employ. Aren't they admins?
I'm an NT admin by day, and I can tell you that NT definitely requires administration, and lots of it. I would suspect that the MCSEs you hire are doing more than what you think they are in keeping the NT network humming. And if you hire more than about two MCSEs, you're probably paying more for NT administration than you are for Solaris administration.
There was a study done (sorry - don't have a cite, though it may be findable on the Web) that suggested that Unix admins are more cost-effective than MCSEs, even given their higher compensation. There were many reasons cited - fewer admins needed, greater efficiency, less downtime (planned or not).
That said, I'd have to say that your technical staff is clueless in at least one respect. Anyone who alienates the non-techies in their job is just asking for the axe to be taken to their projects and ideas. Perhaps you should talk to their managers or whoever and educate them on the importance on at least being polite and attempting to explain things. It's not always easy for techies to "dumb down" when explaining things to non-techies (witness your MCSEs), but an honest attempt should be made, at least.
(I've done Linux advocacy in every job I've held since '93, with great success in every case. I've saved my employers money and provided more efficient and reliable service by doing this. This couldn't have happened if I had copped an attitude with all the "suits" I associated with. Most of them may not understand "mbuf kernel modes for async I/O" (ROFL!), but most get the picture with comments like "the NT solution will cost $25,000 and the Linux solution will cost $3500.")
Like the other guy said, E-mail me if you have more questions.
The system library exception in the GPL should cover these cases, as long as the libraries in question are distributed separately from the project itself.
This means no DLL games like the big boys like to play. Personally, I think that's a good idea; as a sysadmin, DLL games are my biggest headache.
Most of this system could be implemented trivially on any Unix. (The copy-on-write stuff, if it exists, might require a kernel module, depending on the implementation's needs.) Take the output of 'find / -type f -print' (adjusted to taste) and pipe to a Perl script which hashes md5sums and file sizes to filenames, then takes matches and creates (sym)links accordingly. If you're really into this idea of a "central store", copy the files to somewhere under /var/spool first.
The main reason this hasn't been written is that most real sysadmins recognize the pitfalls you describe. So, there's no demand for this "feature".
Microsoft Research has done it again! New, from the people who brought you the Office Paperclip: Auto-Backup-Destruction!
That argument would hold water if you consider, say, corporate Web access, or cybercafes, or access terminals at big conferences.
However, most libraries around are government agencies, not private entities. This makes the problem a bit more difficult.
Government-mandated or government-sponsored censorware, you see, ends up becoming a case of your government telling you what you can and cannot see - in other words, a restriction on free speech. For lots of very good reasons, this is illegal.
(Note: It isn't "proposed" to be illegal, or "might" be illegal, it IS illegal. Right now. Making it legal would require nullifying part of the Constitution, too, something that's not easily done.)
Do you want your government telling you what you can and cannot read in the library? Would you be pissed if your (print) book on, say, Mars exploration were banned from the library because the subject contained the letters "s", "e", and "x" in a row? I would.