Actually, slashdot blew a perfect opportunity to post a dupe that wasn't a dupe (for once). "SCO says they'll sue an end user tomorrow" was a headline yesterday and could have been an equally valid headline today.:)
In any case, I'd explain how you can set your preferences so you don't have to waste your time on SCOldera stories if you don't find them interesting, but since you're "ObviousGuy", I don't have to point out something so obvious to you, do I?:p;)
...they'd have to affirm the GPL! Don't hold your breath waiting for that to happen. Especially since it would contradict their court filings in Utah, and possibly open them up to charges of perjury.
Has SCO actually claimed in court has the GPL is invalid?
Yes, in their response to IBM's counterclaims, SCOG states that the GPL is "unenforcable", "void and/or voidable" and "unconstitutional". Those statements are all on file with the Utah court at this time.
SCO has filed a statement with the court (in response to IBM's counterclaims) saying that the GPL is (among other things) "unenforcable", "void and/or voidable", and "unconstitional". This could be read as prima facie evidence that they do not accept the terms of the GPL, which is a requirement for distributing any GPL'd software.
If they'd confined themselves to press releases questioning the legality of the GPL, then I think you might have a point. But they've basically stated in open court that they do not accept the GPL at all, therefore they're in violation of section 5 of the GPL with respect to any and all GPL'd programs. (Thanks to the smart folks at Groklaw for pointing this out.)
The GPL is a copyright licence, not a patent licence.
Yes it is. Now, assume that I knew that in the first place, and read my post again. Note, in particular, the emphasis I placed on the word "effectively".
The proposal is also to drop support for the non-free section. What, exactly, this entails is not completely clear to me (and I'm a Debian developer), but at the least, I think it means no guarantees of security updates or even bug fixes.
Also, the non-free repository is currently mentioned by the Debian Social Contract, which is part of the Debian Constitution, so it has to be there. This proposal removes it from the Social Contract, clearly opening the door for the repository to be removed entirely in the future. (Which may be just as well if there are no security updates.)
It is an add-on currently. And there are two proposals: the first is to drop support for the existing non-free add-on section; the second is to "affirm" that it will continue to be supported. Obviously these are somewhat at cross-purposes.:)
Many (possibly most) of the programs in the "non-free" repository actually meet the FSF's definition of "semi-free" software. Basically, this is non-commercial-but-otherwise-free software, i.e., it comes with the rights to use, copy, modify, and redistribute, but not the right to sell. I don't think this sort of software should be part of the system (and indeed, the non-free repository is not part of Debian), but aside from that, I don't find it objectionable.
What I'd really like is to replace "non-free" with "semi-free", and only allow semi-free software in - but nobody has proposed that. Oh well.
True but irrelevent. Patents cover methods, not specific code. If I have a patent, and I give permission for anyone to use the methods of that patent in any GPL'd code, then I have effectively licensed the patent under the GPL. And everyone has those (GPL) rights, so there's no unequal rights, so the GPL doesn't self-cancel, but I still have the right to sue someone who uses my patent in non-GPL'd code. Even in BSD or ASL 2.0 licensed code.
Except that's not true. The first point 2 (to look for yourself) is a good one; I did just that, and came to the opposite conclusion from the second point 2. The two licenses are NOT compatible.
The flaw in the the Apache Foundation's rebuttal is when they say, "the GPL says that you cannot redistribute software that is covered by a patent wherein the patent is not licensed free for everyone". But that's not true. The GPL only says that the patent has to be licensed under the terms of the GPL! Thus, IBM could still sue, say, SCO, for using IBM's patented methods that are currently in Linux - but only if they use those methods in a non-GPL'd product, because IBM licensed the patents for any GPL use (otherwise Linus would have rejected the patented-encumbered code).
The BSD license allows sublicensing. It does not allow relicensing. While not directly relevent to the current debate, this is an important distinction, and it grates on my ear to hear people talking about relicensing the code.
Code released under the GPL may be included in projects with thse liceances:
GPL
Nope. Or to be more precise, that's only partially true. The project as a whole must be considered to be under the GPL if portions are GPL'd, but portions that are not GPL'd, but are merely under a compatible license, are still under that compatible license. Thus (practical actual working real-world example here), I have a project that is BSD'd except for one module (an EMACS connector) that is GPL'd. Thus, the whole thing is distributed under the terms of the GPL, but the module is completely separate, and if you delete it, what you are left with is a BSD'd project. If the GPL prevented this, I would have to distribute the module separately, which would be stupid and pointless, but it doesn't, so I don't.
After considering the possibilities, I think the Apache folks are wrong, and their license IS still GPL-incompatible.
The flaw in their rebuttal is when they say: "In other words, the GPL says that you cannot redistribute software that is covered by a patent wherein the patent is not licensed free for everyone." But that's not true. The requirement is that the patent be licensed for use UNDER THE GPL! Thus, for example, IBM has licensed some of their patents for use under the GPL so that Linus would accept their code, but they (IBM) still reserve the right to sue, say, the SCO Group for using their patented methods in SCO Unixware.
Actually, the rebuttal seems to be based on section 7 of the GPL, in particular: "if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."
Which is a much more interesting argument, it's actually changed me from certainty that the ASL2 is incompatible to reserving judgement until I have more time to analyze and consider.
Now, in addition to all the other dangers of scientific research, you want to add the possibility of torture? You inhuman bastard! Oh well, at least you're not asking them to read any of Crichton's dreck. Movies are a medium where Crichton's levels of ignorance, stupidity and scientific illiteracy are the norm, which helps numb the pain somewhat....:)
X Windows *does* have issues; I think we can all agree on that.
You think wrong. I think some implementations of X have issues, but I think the extremely extensible X protocol is just fine.
Linus was just one guy when he started work on Linux. Other people then joined in, and made Linux what it is today.
But Linus wrote his system to follow existing standards, which was a large part of the key to its success. I'd be much more impressed if you said "XFree86 sucks, so we're going to write a new version of X from scratch". That would be a project more like Linux. That would also seem to me to be a whole lot more likely to result in something useful in a reasonable about of time (like, while I'm still alive). Fortunately, the freedesktop project exists to do useful work while you guys run around trying to reinvent the wheel.
Sure, it'll be gratifying if we become popular, but that's not what we've set out to do -- write good code.
Well, I can't fault you there. As long as you don't mind that I'm not going to be holding my breath waiting for your project to succeed.
I do think you should maybe tone down the "this is going to be the successor to X" rhetoric. I think "this is inspired by X" might be a more realistic assessment.
The XFree86 license change was (and is) a big deal because of thousands of GPL'd programs that currently link with xlibs that would have to be removed from distributions which want to use newer versions of XFree86.
Now, by slashdot editor "logic", the fact that one license change is an issue, that means all license changes (or non changes) are issues that deserve long, confusing, misleading discussion. Hence a story on the non-issue of the Apache license.
From the analysis I've seen in Debian lists, the new license wouldn't really be a problem if it just applied to the Xserver. The problem comes with the X client libraries (xlib and friends) that have to be linked with GPL (and other, the GPL is not the only problem here) programs.
Now, when it comes to the users, most of the new features they want have to do with hardware support, which is an Xserver feature. So it's possible that, as an interim solution, systems could be shipped with the new, ugly-licensed Xserver, but with older-but-sanely-licensed xlibs. This would seem to address everyone's issues fairly well.
I've always felt it was a bit of a mistake to have the client-side and server-side of XFree86 tied together anyway. They are pretty much independent, and I think it might make the most sense for XFree86 to abandon the client side, and just focus on making Xservers, while Freedesktop could ignore the server side (at least for now) and focus on the client libraries. Would make both parties jobs easier.
As far as I can tell, BitTorrent has no problem serving directory hierarchies.
Entire hierarchies, no, but you can't pick-and-choose files from a hierarchy; the download is all-or-nothing. Which makes it less-than-useful for systems like apt-get, where each user is going to want a different subset of the available new files (and may even have a different definition of "new files", depending on how often they update).
Doesn't Valve currently distribute updates by FTP? And would that mean that it would also be ironic if you had used FTP to download UT2004 (instead of Torrent)?
Since the only notable difference between FTP and Bittorrent is that downloaders share their bandwidth, and in particular, since it's easy to identify and trace people using the system (much like FTP), I expect that he probably though only idiots would use BT for illegal distribution. And frankly, I think he's right.:)
My understanding (which is admittedly shallow) is that the main benefit of Eiffel over most other compiled (or not) OO languages is the added maintainability provided by its "Design by Contract" features. (Not to mention the enhanced readability gained by not being based on C.) Unfortunately, "maintainability" is a bit of a difficult feature to show off in a programming contest. Although it's a pretty important feature in the Real World(tm).
it's pretty much a given that SCO's own rendering of this code as GPL was inadvertent will be brought up as grounds for why the GPL should be considered legally invalid.
You obviously didn't read the article (reasonable, given that it was slashdotted into oblivion), but it addresses the "inadvertent" angle in great depth. It contains public statements and press releases from Caldera bragging about the work they were doing to help provide common APIs/ABIs between Linux and Unix, and proudly proclaiming their use of the GPL for their contributions.
Slashdot Mirror
Actually, slashdot blew a perfect opportunity to post a dupe that wasn't a dupe (for once). "SCO says they'll sue an end user tomorrow" was a headline yesterday and could have been an equally valid headline today. :)
:p ;)
In any case, I'd explain how you can set your preferences so you don't have to waste your time on SCOldera stories if you don't find them interesting, but since you're "ObviousGuy", I don't have to point out something so obvious to you, do I?
...they'd have to affirm the GPL! Don't hold your breath waiting for that to happen. Especially since it would contradict their court filings in Utah, and possibly open them up to charges of perjury.
SCOG is truly between a rock and a hard place.
Has SCO actually claimed in court has the GPL is invalid?
Yes, in their response to IBM's counterclaims, SCOG states that the GPL is "unenforcable", "void and/or voidable" and "unconstitutional". Those statements are all on file with the Utah court at this time.
SCO has filed a statement with the court (in response to IBM's counterclaims) saying that the GPL is (among other things) "unenforcable", "void and/or voidable", and "unconstitional". This could be read as prima facie evidence that they do not accept the terms of the GPL, which is a requirement for distributing any GPL'd software.
If they'd confined themselves to press releases questioning the legality of the GPL, then I think you might have a point. But they've basically stated in open court that they do not accept the GPL at all, therefore they're in violation of section 5 of the GPL with respect to any and all GPL'd programs. (Thanks to the smart folks at Groklaw for pointing this out.)
The GPL is a copyright licence, not a patent licence.
Yes it is. Now, assume that I knew that in the first place, and read my post again. Note, in particular, the emphasis I placed on the word "effectively".
Keywords for further research: linux, RCU.
That makes a lot more sense.
But if your public key isn't in the Debian keyring, this information will not be very useful to you.
The proposal is also to drop support for the non-free section. What, exactly, this entails is not completely clear to me (and I'm a Debian developer), but at the least, I think it means no guarantees of security updates or even bug fixes.
Also, the non-free repository is currently mentioned by the Debian Social Contract, which is part of the Debian Constitution, so it has to be there. This proposal removes it from the Social Contract, clearly opening the door for the repository to be removed entirely in the future. (Which may be just as well if there are no security updates.)
It is an add-on currently. And there are two proposals: the first is to drop support for the existing non-free add-on section; the second is to "affirm" that it will continue to be supported. Obviously these are somewhat at cross-purposes. :)
Many (possibly most) of the programs in the "non-free" repository actually meet the FSF's definition of "semi-free" software. Basically, this is non-commercial-but-otherwise-free software, i.e., it comes with the rights to use, copy, modify, and redistribute, but not the right to sell. I don't think this sort of software should be part of the system (and indeed, the non-free repository is not part of Debian), but aside from that, I don't find it objectionable.
What I'd really like is to replace "non-free" with "semi-free", and only allow semi-free software in - but nobody has proposed that. Oh well.
True but irrelevent. Patents cover methods, not specific code. If I have a patent, and I give permission for anyone to use the methods of that patent in any GPL'd code, then I have effectively licensed the patent under the GPL. And everyone has those (GPL) rights, so there's no unequal rights, so the GPL doesn't self-cancel, but I still have the right to sue someone who uses my patent in non-GPL'd code. Even in BSD or ASL 2.0 licensed code.
Except that's not true. The first point 2 (to look for yourself) is a good one; I did just that, and came to the opposite conclusion from the second point 2. The two licenses are NOT compatible.
The flaw in the the Apache Foundation's rebuttal is when they say, "the GPL says that you cannot redistribute software that is covered by a patent wherein the patent is not licensed free for everyone". But that's not true. The GPL only says that the patent has to be licensed under the terms of the GPL! Thus, IBM could still sue, say, SCO, for using IBM's patented methods that are currently in Linux - but only if they use those methods in a non-GPL'd product, because IBM licensed the patents for any GPL use (otherwise Linus would have rejected the patented-encumbered code).
The BSD license allows sublicensing. It does not allow relicensing. While not directly relevent to the current debate, this is an important distinction, and it grates on my ear to hear people talking about relicensing the code.
Code released under the GPL may be included in projects with thse liceances:
GPL
Nope. Or to be more precise, that's only partially true. The project as a whole must be considered to be under the GPL if portions are GPL'd, but portions that are not GPL'd, but are merely under a compatible license, are still under that compatible license. Thus (practical actual working real-world example here), I have a project that is BSD'd except for one module (an EMACS connector) that is GPL'd. Thus, the whole thing is distributed under the terms of the GPL, but the module is completely separate, and if you delete it, what you are left with is a BSD'd project. If the GPL prevented this, I would have to distribute the module separately, which would be stupid and pointless, but it doesn't, so I don't.
After considering the possibilities, I think the Apache folks are wrong, and their license IS still GPL-incompatible.
The flaw in their rebuttal is when they say: "In other words, the GPL says that you cannot redistribute software that is covered by a patent wherein the patent is not licensed free for everyone." But that's not true. The requirement is that the patent be licensed for use UNDER THE GPL! Thus, for example, IBM has licensed some of their patents for use under the GPL so that Linus would accept their code, but they (IBM) still reserve the right to sue, say, the SCO Group for using their patented methods in SCO Unixware.
Actually, the rebuttal seems to be based on section 7 of the GPL, in particular: "if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."
Which is a much more interesting argument, it's actually changed me from certainty that the ASL2 is incompatible to reserving judgement until I have more time to analyze and consider.
Now, in addition to all the other dangers of scientific research, you want to add the possibility of torture? You inhuman bastard! Oh well, at least you're not asking them to read any of Crichton's dreck. Movies are a medium where Crichton's levels of ignorance, stupidity and scientific illiteracy are the norm, which helps numb the pain somewhat.... :)
X Windows *does* have issues; I think we can all agree on that.
You think wrong. I think some implementations of X have issues, but I think the extremely extensible X protocol is just fine.
Linus was just one guy when he started work on Linux. Other people then joined in, and made Linux what it is today.
But Linus wrote his system to follow existing standards, which was a large part of the key to its success. I'd be much more impressed if you said "XFree86 sucks, so we're going to write a new version of X from scratch". That would be a project more like Linux. That would also seem to me to be a whole lot more likely to result in something useful in a reasonable about of time (like, while I'm still alive). Fortunately, the freedesktop project exists to do useful work while you guys run around trying to reinvent the wheel.
Sure, it'll be gratifying if we become popular, but that's not what we've set out to do -- write good code.
Well, I can't fault you there. As long as you don't mind that I'm not going to be holding my breath waiting for your project to succeed.
I do think you should maybe tone down the "this is going to be the successor to X" rhetoric. I think "this is inspired by X" might be a more realistic assessment.
The XFree86 license change was (and is) a big deal because of thousands of GPL'd programs that currently link with xlibs that would have to be removed from distributions which want to use newer versions of XFree86.
Now, by slashdot editor "logic", the fact that one license change is an issue, that means all license changes (or non changes) are issues that deserve long, confusing, misleading discussion. Hence a story on the non-issue of the Apache license.
From the analysis I've seen in Debian lists, the new license wouldn't really be a problem if it just applied to the Xserver. The problem comes with the X client libraries (xlib and friends) that have to be linked with GPL (and other, the GPL is not the only problem here) programs.
Now, when it comes to the users, most of the new features they want have to do with hardware support, which is an Xserver feature. So it's possible that, as an interim solution, systems could be shipped with the new, ugly-licensed Xserver, but with older-but-sanely-licensed xlibs. This would seem to address everyone's issues fairly well.
I've always felt it was a bit of a mistake to have the client-side and server-side of XFree86 tied together anyway. They are pretty much independent, and I think it might make the most sense for XFree86 to abandon the client side, and just focus on making Xservers, while Freedesktop could ignore the server side (at least for now) and focus on the client libraries. Would make both parties jobs easier.
As far as I can tell, BitTorrent has no problem serving directory hierarchies.
Entire hierarchies, no, but you can't pick-and-choose files from a hierarchy; the download is all-or-nothing. Which makes it less-than-useful for systems like apt-get, where each user is going to want a different subset of the available new files (and may even have a different definition of "new files", depending on how often they update).
Doesn't Valve currently distribute updates by FTP? And would that mean that it would also be ironic if you had used FTP to download UT2004 (instead of Torrent)?
Since the only notable difference between FTP and Bittorrent is that downloaders share their bandwidth, and in particular, since it's easy to identify and trace people using the system (much like FTP), I expect that he probably though only idiots would use BT for illegal distribution. And frankly, I think he's right. :)
My understanding (which is admittedly shallow) is that the main benefit of Eiffel over most other compiled (or not) OO languages is the added maintainability provided by its "Design by Contract" features. (Not to mention the enhanced readability gained by not being based on C.) Unfortunately, "maintainability" is a bit of a difficult feature to show off in a programming contest. Although it's a pretty important feature in the Real World(tm).
it's pretty much a given that SCO's own rendering of this code as GPL was inadvertent will be brought up as grounds for why the GPL should be considered legally invalid.
You obviously didn't read the article (reasonable, given that it was slashdotted into oblivion), but it addresses the "inadvertent" angle in great depth. It contains public statements and press releases from Caldera bragging about the work they were doing to help provide common APIs/ABIs between Linux and Unix, and proudly proclaiming their use of the GPL for their contributions.