I agree with your analysis, in that using the GPL doesn't really give a great measure of "freedom" to any who choose to use the GPLed code. In reality, it imposes extreme limitations on the developers, much as a proprietary license does. For the end user, there really is no difference, IMO.
The original developer loses nothing, of course, unless he/she foolishly assigns the copyright to the FSF, in which case the code becomes even LESS free, because then it is owned by a third party, and is only available under very strict licensing. Doing so simply helps the FSF grow its suite of free software that is only available under the GPL. I suppose it's a noble goal, but the fact is it is just another company with strict licensing rules, although they include the benefit of being open source.
On the other hand, the BSD license doesn't guarantee much of anything for the developers, and it's sad in a way that it's so easy to use the code w/o giving anything to the coders. And I suppose that's where the GPL comes in; if you feel that your free contributions should only be available to those who are willing to make more free contributions, you should use it.
There is no question that the BSD license is more "free" than the GPL. But there is the issue of whether the GPL perpetuates more (a greater amount of) "free" code overall than does BSD. I think the GPL is quite useful in that sense.
-Dan
You should read one of a host of other articles
on
More E-Voting SNAFUs
·
· Score: 2, Insightful
Because I have seen a great deal of studies that "prove" he won, that "prove" he lost, and that say it is impossible to determine without the courts releasing the information needed to know the exact count.
There are too many ways to estimate this, and none are 100% accurate. But what *is* 100% certain is that Bush prevented the count from being made more accurate than the original. Now, why would he do that? Because he *already* won the first count! It doesn't matter whether the recount would have gone in his favor--he chose *not* to count more accurately specifically because doing so would have reduced his chance of winning.
It's not really that suprising that he wanted to win. But it is disgusting that he cared less about the votes than he did about winning.
> With the Linux solution you have the ability to > add support for new hardware yourself if the > vendor chooses not to.
This is really pretty ironic. I mean, whenever new hardware comes out, the first thing that is done is to write drivers for every windows OS under the sun (except 3.x and lower, perhaps).
On the other hand, sometimes drivers *never* get written for *nix. That situation has improved vastly in the last few years, but is still the case--new hardware often doesn't have drivers for the "free" OSes.
To suggest that it's very likely that a driver would be available for *nix (at least x86) when it isn't for windows, is laughable. You're inventing a non-scenario. Although occaisonally one may find hardware that isn't supported on older windows OSes, it happens far more on even recent version of *nix, and frequently on older versions (especially with proprietary drivers). A FreeBSD driver I'm using (Highpoint) isn't available for any version before 4.1 (or any Linux before 7.0).
The idea of writing your own driver for new hardware is ludicrous. Sure it's possible, but rather than do that, most people would just buy hardware that did have a driver available (I just did that the other day for a FreeBSD system).
Your argument misses one crucial point, as well: there is no reason one can't write drivers for windows. Frankly, I wouldn't want to do either, for hardware that I didn't build myself, but if it's so important to use the new hardware that you'd write a Linux driver, a windows one should be possible as well.
I do agree with you on other points, however, and I dislike MSes forced upgrades. But to act as if Linux's hardware support is somehow an advantage is a little disingenous. It may be easier to write a Linux device driver by using existing open-source ones, I admit. But new hardware is always going to be a pain on old OSes, and that's not Microsoft's fault.
It can't emulate win32 x86 on a non-x86 platform. To work on Mac, it would need a hardware emulation layer, to translate x86 assembly into Gx assembly.
The extra layer, wherein an executable's calls are "translated" into *nix calls, is most certainly emulation. It allows an executable to run as if it were in one environment, even though it is not.
All an emulator is, is a translator. It's simply a question of how much is translated. If you want to say, "WINE is a really efficient emulator, because it doesn't have to translate every single assembly instruction," you'd be right. But it is STILL an emulator, because it still emulates having the win32 api.
Do win32 executables run on *nix systems? No, *nix systems don't know how to interpret them. By virtue of the WINE emulator, however, the part that *nix doesn't know how to run is translated into something that it does know how to run, while the part that is consistent between win32 and *nix can simply be passed through.
If WINE were not an emulator, you wouldn't have to run the win32 exes in WINE, you could just run them in the shell.
All that said, does the fact that WINE is really an emulator make it bad? No, of course not, especially since it is an extremely efficient one. Of course it's not a pure hardware emulator, so many ideas of inefficiency associated with emulators don't apply. But when you get right down to it, it's allowing binaries designed for one system to run on another, and even if it's more efficient than running on the original platform, that still makes it an emulator.
Think for just a minute about how SCO claims IBM breached the contract. Remember, they took SCO's code and put it into Linux? Well, whether they actually did or not, or whether the code in question really "belongs" to SCO (under "derived work") is in debate. But Linus, as the person in charge of changes to the kernel, would be in a unique position to comment on whether IBM actually did this.
As for calling Stallman, it's clearly to deal with the counter-claims re: the GPL, which IBM brought to the table. Certainly Stallman is worth questioning if the GPL is being challenged or used as a point of attack.
Singles are not anywhere near as popular as regular CDs as you only get a few songs and the price isn't that much lower. You only buy singles when a group only has one good new song, and even then it's kind of grudging to pay $5-$10 for a single song.
In addition, these two numbers shouldn't even be compared. Single digital tracks are far cheaper than single CDs, and have less content as well (most singles have more than one song).
Even when more digital tracks are sold than ALL CDs put together, it still doesn't mean anything, because those people are buying 10-15 songs vs. one song. To actually beat CD sales, digital downloads must be ~10 times greater than individual CDs sold.
...is the biggest fallacy I have ever heard of, especially for people who make extensive use of them. You end up forwarding legions of ports for all the services that must be exposed to the internet, all from one ip address. This means hackers have ONE ip address that effectively has hundreds of services running on it, instead of many different computers with one or two services, which takes much longer to scan.
It is true that public ip addresses might expose all the *nix computers running sshd, and all the windows computers running smb, but that's what a firewall is for! And one has to have a firewall equivalent (i.e., a machine that all packets must route through) anyway if he's using NAT. Most NAT boxes are firewalls, too.
The only downside to public ip addresses is that it isn't strictly necessary to have a packet filtering solution to get up and running. But only a fool would set up a corporate network w/o some sort of protection.
In short, it is actually less work to configure a simple firewall which blocks everything to public ips than it is to configure a simple NAT solution which blocks everything to private ips. And once you start forwarding ports, it's actually the NAT that's less secure, because of the single point of entry. Let's not forget as well that people often "DMZ" one of their internal machines, exposing an entire machine to the outside, which again is far worse than a public, firewalled ip.
Again, public ips w/o a firewall is an even more insecure situation, but public ips aren't less secure per se. They're less secure in the hands of a fool.
As already pointed out, the start menu can go anywhere you like, not just the bottom.
However, I think there may have been a design principle at work when placing the menu on the bottom. Perhaps the reason is exactly what you have considered a problem: all the apps have their menus on the top.
When clicking on menus, it's always agravating to miss and click something else. The more menus and buttons that are close together, the more likely you are to click something you didn't intend. By placing the windows buttons/menus at the bottom, MS solves this problem: application menus are on top, and windows menus are on the bottom. There's no chance for confusion, and it's less likely the wrong button will be pressed.
Yes, all the applications have their menus on the top. But should the desktop have its menu on the top as well? A desktop toolbar is a very different thing (in terms of use) than an application toolbar. It's a weak argument to suggest that windows is poorly designed simply because the desktop toolbar isn't in the same place as the application toolbars.
If you could cite a study demonstrating that this design makes Windows less efficient, I'd be interested to hear about that. But otherwise, your comment doesn't hold much water.
Personally, I find it very annoying to have the toolbar on top, because I have to take care when clicking on the windowpane not to press some button on the quicklinks or something. But if you like it up there, it can always be moved...
And I'd be happy to get patches from them, especially since they'd be open-source, and reviewable. If they were helpful, of course they would be accepted under the GPL.
If you look at early white papers from Microsoft, it becomes obvious that some very intelligent people worked there at one time. Surely some of them are still there, as well as fresh talent. Many people I know "sold out" to Microsoft in college, but were actually experienced Linux hackers.
Software bloat (happens to everyone), company overhead (impossible to avoid in a company the size of MS), and economical agendas driving poor design decisions have all made MS' codebase an unsightly beast, I'm sure. But to think they are incapable of creating working, useable, and even secure code is preposterous. Some of the most talented programmers in the world work for MS.
However, I'm fairly sure that very little help will be given to GNU/Linux from MS, whether by the company as a whole, or specific employees. MS would consider it a waste of time, and dangerously helpful to a competitor. The only reason I could see them doing this is to convince a court they weren't "anti-competetive." Judging by the overly-lenient rulings as of late, however, I doubt they need to do so.
I disagree. It's highly unlikely that a judge would dismiss this outright, unless some other defendant didn't show up.
In a case against SCO, perhaps you're right. But we're talking about a case against Linux end users. The question is whether the fact that SCO distributed said code under the GPL (having NOT placed it there in the first place) indemnifies the end users. I'm saying I don't think it does. Is there a case against SCO for distributing Linux under the GPL, knowing it shouldn't have been? Perhaps. Does it protect users of other distributions? Doubtful.
Is SCO aware of the requirements of the GPL? I assume so.
Is SCO aware of "their" code in the kernel? Clearly.
IS SCO DISTRIBUTING IT?
Yes.
AS SCO IS CONTINUTING TO DISTRIBUTE "THEIR" CODE, THEY ARE AGREEING TO THE GPL.
They are agreeing to the GPL for the code that they added after having received the GPLed code. I don't think it is cut and dry that they agree to it for their code that they didn't add. There are more questions which, although you may not consider them relevant, I bet a judge would:
4) Did SCO put the code there, and does SCO bear the responsibility for the violation that said code being there causes?
5) Does agreeing to the GPL mean you implictly accept that all past violations of the GPL are agreeable to you?
The question is whether SCO's actions really constitute them releasing their Unixware code under the GPL. Unfortunately, on this point the GPL doesn't really help, because it doesn't describe what happens when Party A takes party B's code, inserts it into GPLed code, and Party B rereleases said code under the GPL. Obviously, when Party A introduced the proprietary code, the GPL was not followed, meaning the resulting code was available only under an illegal license. But, did the rerelease by Party B suddenly validate the GPL license again? Or were all derivations, including Party B's, invalidated by Party A's actions?
I'm inclined to think the only way to fix it is to go back prior to Party A's actions and build from that point. Everything else was distributed under an illegal license, and the buyers are subject to lawsuit, as are distributors. Is SCO as guilty as everyone else? Absolutely! Does this protect everyone else from SCO's wrath? I don't think it does.
What "other distributions" are doing is irrelevant - "other distributions" are not claiming that they have proprietary code, and "other distribitons" are not suing to stop one another from distributing the kernel.
You couldn't be more wrong. If SCO's allegations are correct, other distributions are definitely vulnerable. They have distributed SCO's code illegally! SCO, on the other hand, will have distributed GPLed code illegally (of course, so will have every other distro).
Bullshit. You're trying to tell me that something can not be replaced? AT ALL ?!?!?! What have you been smoking?
Nope, I'm saying SCO will claim this. They will argue that the kernel has been tainted so badly that even if the code were removed, it would just be replaced by practically identical code, since their code would be known publically. Of course the code could be replaced, but that doesn't make it feasible. Remember, this is in the context of "mitigating losses." Just because SCO didn't tell everyone which code was illegal doesn't mean they didn't try to mitigate losses.
In reality, the code doesn't need to be replaced--it simply adds functionality that wasn't there in 2.2. The question is whether identical functionality would be possible w/o SCO's code. The answer is probably 'yes' but SCO will argue that it never would have been written that way if their code hadn't been there in the first place. In other words, the new kernel has been crafted around SCO's code, and therefore any replacement will by necessity resemble SCO's code, which they would consider anothe
So far, I have seen a few arguments as to why SCO could not possible get away with this. For the sake of argument, let's assume SCO is telling the truth about the copyrighted code. Their claim, while dubious, is probably not entirely without merit.
1. SCO released a GPL distro of Linux which necessarily GPLs any source code of their own which was included.
Why it doesn't matter:
SCO themselves did not insert the code. They simply redistributed a source package which already contained their code before it came into their possession. A judge is probably going to look at this claim and dismiss it outright. Let me illustrate with an example
If I work for Microsoft, steal some code, create a free Unix driver for WinFS, and distribute it, this creates a copyright violation for the users. If MS provided this to Solaris users (even with mods) on their website afterwards, it is very doubtful that a judge would suddenly declare the stolen code in the public domain. The fact that MS participated in the public code license doesn't suddenly indemnify all the users of the proprietary code of a copyright violation.
At this point, MS would almost certainly be able to sue users of the code, as well as me for releasing the code. I can hear some of you crying out, "But SCO went one further! They kept distributing the code even after they 'discovered' the violation." This is true; in fact they are still distributing the code, although this may be accidental. I'm sure you can find the SRPM link somewhere around here. Let me explain why this doesn't matter:
SCO is going to claim that they were not the ones to insert their proprietary code into Linux, IBM was. Therefore, it isn't their responsibility to take it out. In fact, they allege that they still are not aware of the extent of the violation. It's not as if SCO received a clean GPLed version of Linux, added their proprietary code, rereleased it under the GPL, and now expect payment for their code. What they have done is participate in a "good faith" way in the GPL license, adding code and releasing it under the GPL. If the code they received wasn't GPL, however, it isn't legally their fault, but the fault of the individuals who added it originally. SCO doesn't immediately give up their rights to their code just because they added GPLed code to a non-GPL product.
SCO doesn't bear responsibility for the code getting into Linux. Therefore, releasing Linux under the GPL doesn't GPL any unauthorized code simply because SCO is the owner. I would say a judge would probably consider the GPL violation to have occurred when IBM inserted the code, not at SCO. SCO can probably keep releasing Linux under the GPL without giving up the rights to their code, because the violation occurs before them in the distribution stream.
If it is a GPL violation for SCO to release their distro (which is doubtful), then they will have to deal with that. But, if it is, it is also a violation for every single other Linux distro. Therefore, even if this particular claim is correct, it damns all distros along with SCO's. It would mean ANY distributer such as RH, Suse, etc., could be sued at any time by any of the copyright holders of the Linux source code. Surely, this isn't the victory the Linux community is seeking. It makes more sense to leave the violation where it allegedly occured: namely, at IBM. Everyone else (including SCO) can then begin releasing a legal version of Linux as soon as possible.
In essence, SCO is not GPLing their code by rereleasing it under the GPL. They are only GPLing it when they primarily release it under the GPL. I sincerely doubt a judge would set the precedent of allowing unauthorized code to be GPLed by the owner simply for redistributing it.
SCO may be found in GPL violation for knowingly redistributing GPL code which shouldn't have been. Most likely,
Slashdot Mirror
I agree with your analysis, in that using the GPL doesn't really give a great measure of "freedom" to any who choose to use the GPLed code. In reality, it imposes extreme limitations on the developers, much as a proprietary license does. For the end user, there really is no difference, IMO.
The original developer loses nothing, of course, unless he/she foolishly assigns the copyright to the FSF, in which case the code becomes even LESS free, because then it is owned by a third party, and is only available under very strict licensing. Doing so simply helps the FSF grow its suite of free software that is only available under the GPL. I suppose it's a noble goal, but the fact is it is just another company with strict licensing rules, although they include the benefit of being open source.
On the other hand, the BSD license doesn't guarantee much of anything for the developers, and it's sad in a way that it's so easy to use the code w/o giving anything to the coders. And I suppose that's where the GPL comes in; if you feel that your free contributions should only be available to those who are willing to make more free contributions, you should use it.
There is no question that the BSD license is more "free" than the GPL. But there is the issue of whether the GPL perpetuates more (a greater amount of) "free" code overall than does BSD. I think the GPL is quite useful in that sense.
-Dan
Because I have seen a great deal of studies that "prove" he won, that "prove" he lost, and that say it is impossible to determine without the courts releasing the information needed to know the exact count.
There are too many ways to estimate this, and none are 100% accurate. But what *is* 100% certain is that Bush prevented the count from being made more accurate than the original. Now, why would he do that? Because he *already* won the first count! It doesn't matter whether the recount would have gone in his favor--he chose *not* to count more accurately specifically because doing so would have reduced his chance of winning.
It's not really that suprising that he wanted to win. But it is disgusting that he cared less about the votes than he did about winning.
-Dan
> With the Linux solution you have the ability to
> add support for new hardware yourself if the
> vendor chooses not to.
This is really pretty ironic. I mean, whenever new hardware comes out, the first thing that is done is to write drivers for every windows OS under the sun (except 3.x and lower, perhaps).
On the other hand, sometimes drivers *never* get written for *nix. That situation has improved vastly in the last few years, but is still the case--new hardware often doesn't have drivers for the "free" OSes.
To suggest that it's very likely that a driver would be available for *nix (at least x86) when it isn't for windows, is laughable. You're inventing a non-scenario. Although occaisonally one may find hardware that isn't supported on older windows OSes, it happens far more on even recent version of *nix, and frequently on older versions (especially with proprietary drivers). A FreeBSD driver I'm using (Highpoint) isn't available for any version before 4.1 (or any Linux before 7.0).
The idea of writing your own driver for new hardware is ludicrous. Sure it's possible, but rather than do that, most people would just buy hardware that did have a driver available (I just did that the other day for a FreeBSD system).
Your argument misses one crucial point, as well: there is no reason one can't write drivers for windows. Frankly, I wouldn't want to do either, for hardware that I didn't build myself, but if it's so important to use the new hardware that you'd write a Linux driver, a windows one should be possible as well.
I do agree with you on other points, however, and I dislike MSes forced upgrades. But to act as if Linux's hardware support is somehow an advantage is a little disingenous. It may be easier to write a Linux device driver by using existing open-source ones, I admit. But new hardware is always going to be a pain on old OSes, and that's not Microsoft's fault.
-Dan
It can't emulate win32 x86 on a non-x86 platform. To work on Mac, it would need a hardware emulation layer, to translate x86 assembly into Gx assembly.
-Dan
The extra layer, wherein an executable's calls are "translated" into *nix calls, is most certainly emulation. It allows an executable to run as if it were in one environment, even though it is not.
All an emulator is, is a translator. It's simply a question of how much is translated. If you want to say, "WINE is a really efficient emulator, because it doesn't have to translate every single assembly instruction," you'd be right. But it is STILL an emulator, because it still emulates having the win32 api.
Do win32 executables run on *nix systems? No, *nix systems don't know how to interpret them. By virtue of the WINE emulator, however, the part that *nix doesn't know how to run is translated into something that it does know how to run, while the part that is consistent between win32 and *nix can simply be passed through.
If WINE were not an emulator, you wouldn't have to run the win32 exes in WINE, you could just run them in the shell.
All that said, does the fact that WINE is really an emulator make it bad? No, of course not, especially since it is an extremely efficient one. Of course it's not a pure hardware emulator, so many ideas of inefficiency associated with emulators don't apply. But when you get right down to it, it's allowing binaries designed for one system to run on another, and even if it's more efficient than running on the original platform, that still makes it an emulator.
-Dan
Think for just a minute about how SCO claims IBM breached the contract. Remember, they took SCO's code and put it into Linux? Well, whether they actually did or not, or whether the code in question really "belongs" to SCO (under "derived work") is in debate. But Linus, as the person in charge of changes to the kernel, would be in a unique position to comment on whether IBM actually did this.
As for calling Stallman, it's clearly to deal with the counter-claims re: the GPL, which IBM brought to the table. Certainly Stallman is worth questioning if the GPL is being challenged or used as a point of attack.
-Dan
Singles are not anywhere near as popular as regular CDs as you only get a few songs and the price isn't that much lower. You only buy singles when a group only has one good new song, and even then it's kind of grudging to pay $5-$10 for a single song.
In addition, these two numbers shouldn't even be compared. Single digital tracks are far cheaper than single CDs, and have less content as well (most singles have more than one song).
Even when more digital tracks are sold than ALL CDs put together, it still doesn't mean anything, because those people are buying 10-15 songs vs. one song. To actually beat CD sales, digital downloads must be ~10 times greater than individual CDs sold.
-Dan
...is the biggest fallacy I have ever heard of, especially for people who make extensive use of them. You end up forwarding legions of ports for all the services that must be exposed to the internet, all from one ip address. This means hackers have ONE ip address that effectively has hundreds of services running on it, instead of many different computers with one or two services, which takes much longer to scan.
It is true that public ip addresses might expose all the *nix computers running sshd, and all the windows computers running smb, but that's what a firewall is for! And one has to have a firewall equivalent (i.e., a machine that all packets must route through) anyway if he's using NAT. Most NAT boxes are firewalls, too.
The only downside to public ip addresses is that it isn't strictly necessary to have a packet filtering solution to get up and running. But only a fool would set up a corporate network w/o some sort of protection.
In short, it is actually less work to configure a simple firewall which blocks everything to public ips than it is to configure a simple NAT solution which blocks everything to private ips. And once you start forwarding ports, it's actually the NAT that's less secure, because of the single point of entry. Let's not forget as well that people often "DMZ" one of their internal machines, exposing an entire machine to the outside, which again is far worse than a public, firewalled ip.
Again, public ips w/o a firewall is an even more insecure situation, but public ips aren't less secure per se. They're less secure in the hands of a fool.
-Dan
Don't know if this was posted yet:
http://www.onlamp.com/pub/wlg/3880
-Dan
As already pointed out, the start menu can go anywhere you like, not just the bottom.
However, I think there may have been a design principle at work when placing the menu on the bottom. Perhaps the reason is exactly what you have considered a problem: all the apps have their menus on the top.
When clicking on menus, it's always agravating to miss and click something else. The more menus and buttons that are close together, the more likely you are to click something you didn't intend. By placing the windows buttons/menus at the bottom, MS solves this problem: application menus are on top, and windows menus are on the bottom. There's no chance for confusion, and it's less likely the wrong button will be pressed.
Yes, all the applications have their menus on the top. But should the desktop have its menu on the top as well? A desktop toolbar is a very different thing (in terms of use) than an application toolbar. It's a weak argument to suggest that windows is poorly designed simply because the desktop toolbar isn't in the same place as the application toolbars.
If you could cite a study demonstrating that this design makes Windows less efficient, I'd be interested to hear about that. But otherwise, your comment doesn't hold much water.
Personally, I find it very annoying to have the toolbar on top, because I have to take care when clicking on the windowpane not to press some button on the quicklinks or something. But if you like it up there, it can always be moved...
-Dan
And I'd be happy to get patches from them, especially since they'd be open-source, and reviewable. If they were helpful, of course they would be accepted under the GPL.
If you look at early white papers from Microsoft, it becomes obvious that some very intelligent people worked there at one time. Surely some of them are still there, as well as fresh talent. Many people I know "sold out" to Microsoft in college, but were actually experienced Linux hackers.
Software bloat (happens to everyone), company overhead (impossible to avoid in a company the size of MS), and economical agendas driving poor design decisions have all made MS' codebase an unsightly beast, I'm sure. But to think they are incapable of creating working, useable, and even secure code is preposterous. Some of the most talented programmers in the world work for MS.
However, I'm fairly sure that very little help will be given to GNU/Linux from MS, whether by the company as a whole, or specific employees. MS would consider it a waste of time, and dangerously helpful to a competitor. The only reason I could see them doing this is to convince a court they weren't "anti-competetive." Judging by the overly-lenient rulings as of late, however, I doubt they need to do so.
-Dan
I disagree. It's highly unlikely that a judge would dismiss this outright, unless some other defendant didn't show up.
In a case against SCO, perhaps you're right. But we're talking about a case against Linux end users. The question is whether the fact that SCO distributed said code under the GPL (having NOT placed it there in the first place) indemnifies the end users. I'm saying I don't think it does. Is there a case against SCO for distributing Linux under the GPL, knowing it shouldn't have been? Perhaps. Does it protect users of other distributions? Doubtful.
Is SCO aware of the requirements of the GPL?
I assume so.
Is SCO aware of "their" code in the kernel?
Clearly.
IS SCO DISTRIBUTING IT?
Yes.
AS SCO IS CONTINUTING TO DISTRIBUTE "THEIR" CODE, THEY ARE AGREEING TO THE GPL.
They are agreeing to the GPL for the code that they added after having received the GPLed code. I don't think it is cut and dry that they agree to it for their code that they didn't add. There are more questions which, although you may not consider them relevant, I bet a judge would:
4) Did SCO put the code there, and does SCO bear the responsibility for the violation that said code being there causes?
5) Does agreeing to the GPL mean you implictly accept that all past violations of the GPL are agreeable to you?
The question is whether SCO's actions really constitute them releasing their Unixware code under the GPL. Unfortunately, on this point the GPL doesn't really help, because it doesn't describe what happens when Party A takes party B's code, inserts it into GPLed code, and Party B rereleases said code under the GPL. Obviously, when Party A introduced the proprietary code, the GPL was not followed, meaning the resulting code was available only under an illegal license. But, did the rerelease by Party B suddenly validate the GPL license again? Or were all derivations, including Party B's, invalidated by Party A's actions?
I'm inclined to think the only way to fix it is to go back prior to Party A's actions and build from that point. Everything else was distributed under an illegal license, and the buyers are subject to lawsuit, as are distributors. Is SCO as guilty as everyone else? Absolutely! Does this protect everyone else from SCO's wrath? I don't think it does.
What "other distributions" are doing is irrelevant - "other distributions" are not claiming that they have proprietary code, and "other distribitons" are not suing to stop one another from distributing the kernel.
You couldn't be more wrong. If SCO's allegations are correct, other distributions are definitely vulnerable. They have distributed SCO's code illegally! SCO, on the other hand, will have distributed GPLed code illegally (of course, so will have every other distro).
Bullshit. You're trying to tell me that something can not be replaced? AT ALL ?!?!?! What have you been smoking?
Nope, I'm saying SCO will claim this. They will argue that the kernel has been tainted so badly that even if the code were removed, it would just be replaced by practically identical code, since their code would be known publically. Of course the code could be replaced, but that doesn't make it feasible. Remember, this is in the context of "mitigating losses." Just because SCO didn't tell everyone which code was illegal doesn't mean they didn't try to mitigate losses.
In reality, the code doesn't need to be replaced--it simply adds functionality that wasn't there in 2.2. The question is whether identical functionality would be possible w/o SCO's code. The answer is probably 'yes' but SCO will argue that it never would have been written that way if their code hadn't been there in the first place. In other words, the new kernel has been crafted around SCO's code, and therefore any replacement will by necessity resemble SCO's code, which they would consider anothe
...but I'd like to be proven wrong. IANAL.
So far, I have seen a few arguments as to why SCO could not possible get away with this. For the sake of argument, let's assume SCO is telling the truth about the copyrighted code. Their claim, while dubious, is probably not entirely without merit.
1. SCO released a GPL distro of Linux which necessarily GPLs any source code of their own which was included.
Why it doesn't matter:
SCO themselves did not insert the code. They simply redistributed a source package which already contained their code before it came into their possession. A judge is probably going to look at this claim and dismiss it outright. Let me illustrate with an example
If I work for Microsoft, steal some code, create a free Unix driver for WinFS, and distribute it, this creates a copyright violation for the users. If MS provided this to Solaris users (even with mods) on their website afterwards, it is very doubtful that a judge would suddenly declare the stolen code in the public domain. The fact that MS participated in the public code license doesn't suddenly indemnify all the users of the proprietary code of a copyright violation.
At this point, MS would almost certainly be able to sue users of the code, as well as me for releasing the code. I can hear some of you crying out, "But SCO went one further! They kept distributing the code even after they 'discovered' the violation." This is true; in fact they are still distributing the code, although this may be accidental. I'm sure you can find the SRPM link somewhere around here. Let me explain why this doesn't matter:
SCO is going to claim that they were not the ones to insert their proprietary code into Linux, IBM was. Therefore, it isn't their responsibility to take it out. In fact, they allege that they still are not aware of the extent of the violation. It's not as if SCO received a clean GPLed version of Linux, added their proprietary code, rereleased it under the GPL, and now expect payment for their code. What they have done is participate in a "good faith" way in the GPL license, adding code and releasing it under the GPL. If the code they received wasn't GPL, however, it isn't legally their fault, but the fault of the individuals who added it originally. SCO doesn't immediately give up their rights to their code just because they added GPLed code to a non-GPL product.
SCO doesn't bear responsibility for the code getting into Linux. Therefore, releasing Linux under the GPL doesn't GPL any unauthorized code simply because SCO is the owner. I would say a judge would probably consider the GPL violation to have occurred when IBM inserted the code, not at SCO. SCO can probably keep releasing Linux under the GPL without giving up the rights to their code, because the violation occurs before them in the distribution stream.
If it is a GPL violation for SCO to release their distro (which is doubtful), then they will have to deal with that. But, if it is, it is also a violation for every single other Linux distro. Therefore, even if this particular claim is correct, it damns all distros along with SCO's. It would mean ANY distributer such as RH, Suse, etc., could be sued at any time by any of the copyright holders of the Linux source code. Surely, this isn't the victory the Linux community is seeking. It makes more sense to leave the violation where it allegedly occured: namely, at IBM. Everyone else (including SCO) can then begin releasing a legal version of Linux as soon as possible.
In essence, SCO is not GPLing their code by rereleasing it under the GPL. They are only GPLing it when they primarily release it under the GPL. I sincerely doubt a judge would set the precedent of allowing unauthorized code to be GPLed by the owner simply for redistributing it.
SCO may be found in GPL violation for knowingly redistributing GPL code which shouldn't have been. Most likely,