The author of the article seems to be a bit biased towards GTK. He fails to mention though that GTK is often used in conjunction with Glib, Gnome, GDK, Bonobo, and Gnome-VFS/Ghttp. As a complete group, these are difficult to use and poorly documented in far too many places.
QT is well documented, consistent and stable but the licensing terms are a bit vicious if you want to do any commercial development. I'd use QT exclusively if it was LGPL, but I can't afford to shell out $3000 for a Win32 and Linux license.
wxWindows has some flaws when it comes to stability and features, but it includes all of the core functionality in one package, it's well documented, the license is very generous, and the API is simple to use for complex tasks. As nice as a well written GTK app looks, I'd much rather write or debug a wxGTK app since the learning curve is so much easier to overcome.
Take a look at Galeon if you don't believe me. After years of working with GTK, those developers still can't figure out why bonobo popup windows don't respond properly when GTK pops a window. The documentation is bad and the libraries are too complex. Hopefully this will change in the future. I'd love to see GTK and Gnome become the defacto standards, but as-is they're too complex.
It definitely is not unless they were using unpatched sources in all three systems. The Gentoo sources applies bunches of patches to the stock kernel which would affect compile time.
RTFA. "The same 2.4.21 source was copied to all machines and compiled using the same options. However, it should be noted that the Debian system used gcc 3.3.1 whilst the Mandrake and Gentoo installations used gcc 3.3.2"
Agreed. I do not understand what Bill is trying to say when he says "The way the GPL works, if you license any Linux, you have to license all Linux". Is he refering to the so called "viral nature fud" of Linux?
I wonder if the top brass at Microsoft understand their own EULA's? It doesn't take a law degree to understand the GPL. It does take a law degree to fully understand what you're agreeing to when you apply a Windows service pack.
Of course, the assertion that OSS has stolen code from Microsoft is about as stupid as they come. If it's so easy to steal their IP "crown jewels", they have a real problem with internal security. All the lawsuits I've read about so far point to Microsoft stealing code from others.
It seems to me that the FSF, or Linus, or any major Linux vendor is now free to sue SCO, for either libel or barratry or whatever laws govern deceptive harrassment of your competitor's customers, at the least. In fact, I'm shocked they haven't already.
I would expect that most of the folks with enough of a financial interest in this and the funds to see a lawsuit through are waiting for SCO to stop waffling and present their licensing plan. I don't buy the idea that SCO has been working out the details all this time. They're stalling...once they start demanding money instead of just talking about demanding money the lawsuits against SCO will start coming in.
What do you think the odds are that six months from now SCO is STILL working on their licensing plan AND distributing the Linux kernel via their own ftp server?
The only thing that shows up being even close between the Linux kernel and the versions of Unix with source available is what seems to be a derivative of malloc and mfree in ate_utils.c
ate_utils is/was part of the NUMA code for IA64. It has been removed from the latest development and prepatch kernels (it's obsolete, from what I've read.)
There are some less interesting similarities between the signal handling code, but that's hardly remarkable. How many ways can you write a switch statement?
The key thing to remember though is that SCO doesn't actually claim they wrote the code. They claim to own rights in code that IBM wrote. I would bet that it's safe to assume that a detailed inspection of AIX and Linux 2.4.21 will reveal similarities. The question is, does IBM have the right to relicense code they created?
What does overture have that is worth $1.63 billion to Yahoo?
Advertisers and listings. Yahoo is making the majority of it's money off pay-per-click advertising. It's only natural that they would try to consolidate and eliminate the middle-man. I'd expect this will drive Kanoodle and FindWhat through the roof and raise some serious concerns at Google. In the short term, this is probably a good thing for anyone who buys traffic from the search engines. Overture were dicks about minimum bids and what sort of pages you could link to... In the long run though, this is yet another sign that the pay-per-click pipe will be squeezed to the point of being useless. Personally, I expect to see the search engines start going after affiliate programs next. That will indeed be a sad day for anyone who makes their living as an internet middle-man.
Re:for those turned off by the elitist Debian comm
on
Introduction to Debian
·
· Score: 3, Informative
There is plenty of good community support available for Debian. The only time I've ever seen anyone suggest "RTFM" is when someone posts nonsence questions to the developers mailing lists without bothering to check the various developers manuals. I don't think it's unreasonable to expect DEVELOPERS to RTFM. Users are a whole different subject.
My biggest complaint w/ debian is the slow release cycle.
That's the very thing I like most about Debian. There are enough distros pushing for 6 month release cycles regardless of the reliability of the underlying software. Debian seems to take the opposite stand, sticking with old versions until the newer versions work properly. Personally, I'd rather have a reliable KDE 2.2 than a buggy KDE 3.x-beta1. I make my living using this software. I don't want to spend time tracking down obscure kdelibs bugs. I have a development system tracking Debian Unstable for that.
I was shown a little of the copied code. Admittedly, I can't tell you what I saw, but I did form the opinion that it was not in the kernel proper. In all probability, the code is more important to Silicon Graphics' Altix servers than to average x86 Linux users.
Ugh.. Altix is Itanium (AKA ia64.) This sounds very much like the code I pointed out yesterday. (ate_utils.c in Linux -vs- malloc.c in versions of Unix up to at least System3)
A couple of things people have pointed out about why the example I found should be legit:
(1) It's in BSD... No, I'm no expert on BSD history but from what I've read the settlement happened between BSD 4.3 and 4.4. Anything prior to 4.4 probably doesn't count since the whole reason BSD won is that they had rewritten all of the code. BSD3 contains pretty much an exact copy of malloc.c from Sys3, but the version in 4.2 looks newer than the version SGI used. I'd assume it's even more different in BSD 4.3 and 4.4.
(2) The code is common knowledge. This same form of malloc has been around longer than the C language. This sounds good, but it's hard to believe the code was written independently. The comments, structure, and variable names seem a bit too much to be coincidence.
(3) Caldera released the code for all versions of Unix prior to and including Sys3 under a BSD-style license. This is definitely the best argument, but SGI didn't include a "(c)Caldera 2001" in the file. The dates in SGI's copyright statment in that file are also out of line with the date of the Caldera offer, and it's easy to show that ate_utils.c was around prior to 23 Jan 2002. (Check the 2.4.17 ia64 port on Kernel.org)
The real question is why would SGI use versions of malloc and free that trace their lineage all the way back to 1973 Bell Labs when there are untainted, free, and better written versions of these functions available.
After going even further back, this code appears at least as early as Unix Release 5 with a Copyright of 1973 by Bell Telephone Inc. The comments appear later, but the code is basicly the same. I assume it was in BSD at some point, but why does the Linux version claim that Silicon Graphics owns the copyright?
I downloaded a copy of the OpenBSD 2.7 kernel and I don't see it. I realize there are a variety of possible explanations and I'm not a kernel developer so I don't really understand the context of this code or its history, but on the surface it certainly doesn't look good.
That's what I though as well. If it's BSD code why is it stuffed into the ia64 section. I'll hold off on any snap judgement, but my confidence in the validity of IBM's position has dropped down a few notches.
If you strip the whitespace before hashing it does turn up a few interesing things.
Comparing the code from the PDP kernel in sys3.tar.gz and the Linux 2.4.21 kernel there is a good match between the mfree function in usr/src/uts/pdp11/os/malloc.c around line 69, and the atefree function in arch/ia64/sn/io/ate_utils.c around line 187. It certainly looks like the version in SYS3 was used to create the version in 2.4.21. Take a look at the comments in these files, they're almost identical.
The copyright on the Linux version attributes this file to Silicon Graphics. Anyone want to grep for the same comments in a BSD kernel or provide a history of this file?
But there's nothing wrong at all with what RedHat's doing: they give you the binary, and they give you the source. Then they offer a separate deal, in which they'll support the software they gave you in exchange for money.
I didn't mention RedHat, but if you take a look at the licensing terms you'll see that their support contract wraps around the GPL software by claiming that if you accept any support contract you give up the right to freely use, and copy the software on any machines you want. In fact, their terms claim that you can't use the software at all without a support contract, but that's patently false so it's not even worth worrying about.
Debian, Gentoo, Slack, etc offer community based support which does not require any seperate agreement. They also don't make claims that their trademarks must be removed if you install any non-distro specific software on your machine. Check out RedHat's trademark guidelines page for even more fun. If you compile a custom kernel on your RedHat machine you have to remove all the RedHat logo's and trademarks even if the changes are only for personal use.
Anyway, I don't think RedHat is any worse than...say...Mandrake or Lindows in wrapping GPL software with additional restrictions. I just hate to see companies trying to make money this way. Sooner or later the restrictions will go a bit too far and we'll see the house of cards come tumbling down. Some enterprising developer will decide to start suing everyone that's wrapping their GPL work with additional terms. The GPL does not allow for placing additional terms on end users. Any support contract, download agreement, EULA, trademark restrictions which restrict the rights listed in the GPL clearly cannot apply to GPL software. I'd hate to see that proven in a court of law since it will only serve as a nasty example for GPL+Business doubters.
You do all understand that while the GPL doesn't permit tying by license, distros have now moved to using threats of invalidating support contracts to achieve the market leverage they need to exclude competitors, yes?
Although I agree with Reiser's statement that tying support contracts to a GPL product is/should be illegal, some of his other statements about the GPL have been questionable.
RMS responded to a question about some of Reiser's statements about the GPL v3 indicating that Reiser was incorrect about GPL3 including ad-removal restrictions.
The entire thread is an interesting read about the GFDL, GPL, and possible crossover between the two. Take a look at the author index for some other interesting tidbits.
Since you don't have to register with for a copyright any more aren't we all "copyright holders"? So if this logic prevails I have the right to destroy your computer because you read this comment and your browser made a local copy in the process? What comes after this? I get to chop off your hands?
* IBM will act in its own interests, of course, and not in the interests of the Linux community; what should we expect from them?
The fact that SCO has thrown the future of AIX into doubt along with the future of Linux means that IBM can't simply pack up and walk away. They have to see this resolved, one way or another. Personally I'm betting that IBM will buy SCO or a license that makes these allegations go away. I'd bet that they're waiting for the circus to die down so that SCO's stock will deflate to a more realistic value.
Not at all. They're validating many of the arguments in favor of free software. SCO can't stop Linux. SCO is still distributing Linux code on their own servers. The *MAY* be able to stop the sale of commercial derivatives of AT&T's commercial Unix, which just goes to show that you and I can no longer afford to gamble on the continued goodwill of commercial vendors. The licensing terms IBM had with AT&T are straightforward in stating that IBM owns the rights to its own derivative works, but now that SCO has become a lawsuit factory they claim otherwise. If AIX had been based on BSD there would be no issues at all.
Compared to SCO, the FSF is overly business friendly. The worst the FSF has done to glaringly obvious GPL violators pales in comparison to the kind of BS SCO is doing. I'm sure this will do wonders for SCO's IP sales. I can see folks lining up around the block to create new derivative works based on this IP.
At the very worst, you'd see Debian/RedHat/Mandrake/etc move to a BSD kernel. Debian already has a somewhat working port of the GNU userspace to BSD kernel. (Not related to the current lawsuit) How long would it take if all the vendors came together to work on it?
So no function names to remember, and who can remember some not very specific interesting variable name?
In the translation I read there was no mention of function names being removed, only dates and filenames. Surely someone going through all the effort to view the code can be expected to remember a few function names or the exact wording of the comments. Picking the exact lines out of the source should be trivial.
It's not like someone expecting you to remember an obscure function you wrote 3 years ago. This person was looking at small bits of code that are at the center of a major lawsuit. I find the lack of even one single identifiable line to be a good indication that this story is a fake.
Which of the functions is he talking about? Given that he knew the area of the kernel he was looking at, why didn't he take a glimpse at the kernel source and point out the function name or line numbers?
I'm not saying this is proof that the story is BS. I'm just saying that the lack of any single concrete piece of code makes me doubt the story. I mean, wasn't the whole point to give juicy details that would be verbotten under the NDA?
I can't trust my own governement to tell me the truth...why should I assume this person is doing so?
No doubt. Cite a damn file name and line numbers. Without it, this looks like a scam to get traffic.
What use are vague references to jokes in comments? Tell the line numbers so that we can know for certain whether or not the code being shown comes from a questionable source.
If this story is true and someone did see SCO's code without a NDA then they're wasting the chance they've been given to cite some concrete examples of what SCO is claiming.
Since the author elected to provide the same sort of wish-wash "proof" that SCO is handing out to the public, it's hard to imagine this isn't a scam.
I think it's arguable that the enthusiasm is for Unix on the cheaper intel platform. Other Unix/Intel variants exist.
I'd say the enthusiasm is for a cheaper Unix. Sun doesn't seem to be offering that. If anyone really gains marketshare from the current litigation it's bound to be the *BSDs.
I think the key point in the quote though is that it seems to completely discount Free Beer and Free Speech as motivating factors. Solaris may appeal to businesses that are currently running AIX, but personally I'm not about to replace my Linux web servers with a proprietary Unix unless every free alternative disappears.
Forgot this one with the nice quote from a Sun exec:
Why do we think enthusiasm for Linux exists in the first place? The enthusiasm isn't about Linux, it's about access to Intel and the ability to run Unix on what seems to be a cheaper platform.
Ok, I see two issues here. First, you can get all of the SRPMS (i.e., all of the source to build your own) from http://ftp.redhat.com/pub/redhat/linux/enterprise/ 2.1AS/en/os/i386/SRPMS/ [redhat.com], which I located by going to the download directory for 9, going up a few directories, and selecting enterprise instead of 9. Not intuitive, but the source is technically available, as per the GPL.
I think it's even worse than that when you add it all together. RedHat's trademark policies claim that any modification for purely internal use still requires you to remove all the RedHat trademarks.
"If you are an individual or business (including all subsidiaries of such business) and you only intend to use Red Hat® Linux® personally or, in the case of a business, internally, in the original form delivered by Red Hat (or its authorized distributors) or with modifications provided by Red Hat, you have permission to apply Red Hat's trademarks to all such internal copies."
So.. If I take a SRPM and compile it, it's certainly not in the original form delivered by RedHat.
What really worries me isn't that RHAS is a rip-off or that RedHat's trademark licensing terms are ass-backwards. I worry that other companies will accept this as a valid business model for GPL software. I don't want GPL software I write to be suject to this sort of sublicensing. If I wanted that, I'd use the BSD license.
Slashdot Mirror
The author of the article seems to be a bit biased towards GTK. He fails to mention though that GTK is often used in conjunction with Glib, Gnome, GDK, Bonobo, and Gnome-VFS/Ghttp. As a complete group, these are difficult to use and poorly documented in far too many places.
QT is well documented, consistent and stable but the licensing terms are a bit vicious if you want to do any commercial development. I'd use QT exclusively if it was LGPL, but I can't afford to shell out $3000 for a Win32 and Linux license.
wxWindows has some flaws when it comes to stability and features, but it includes all of the core functionality in one package, it's well documented, the license is very generous, and the API is simple to use for complex tasks. As nice as a well written GTK app looks, I'd much rather write or debug a wxGTK app since the learning curve is so much easier to overcome.
Take a look at Galeon if you don't believe me. After years of working with GTK, those developers still can't figure out why bonobo popup windows don't respond properly when GTK pops a window. The documentation is bad and the libraries are too complex. Hopefully this will change in the future. I'd love to see GTK and Gnome become the defacto standards, but as-is they're too complex.
It definitely is not unless they were using unpatched sources in all three systems. The Gentoo sources applies bunches of patches to the stock kernel which would affect compile time.
RTFA. "The same 2.4.21 source was copied to all machines and compiled using the same options. However, it should be noted that the Debian system used gcc 3.3.1 whilst the Mandrake and Gentoo installations used gcc 3.3.2"
Agreed. I do not understand what Bill is trying to say when he says "The way the GPL works, if you license any Linux, you have to license all Linux". Is he refering to the so called "viral nature fud" of Linux?
I wonder if the top brass at Microsoft understand their own EULA's? It doesn't take a law degree to understand the GPL. It does take a law degree to fully understand what you're agreeing to when you apply a Windows service pack.
Of course, the assertion that OSS has stolen code from Microsoft is about as stupid as they come. If it's so easy to steal their IP "crown jewels", they have a real problem with internal security. All the lawsuits I've read about so far point to Microsoft stealing code from others.
It seems to me that the FSF, or Linus, or any major Linux vendor is now free to sue SCO, for either libel or barratry or whatever laws govern deceptive harrassment of your competitor's customers, at the least. In fact, I'm shocked they haven't already.
I would expect that most of the folks with enough of a financial interest in this and the funds to see a lawsuit through are waiting for SCO to stop waffling and present their licensing plan. I don't buy the idea that SCO has been working out the details all this time. They're stalling...once they start demanding money instead of just talking about demanding money the lawsuits against SCO will start coming in.
What do you think the odds are that six months from now SCO is STILL working on their licensing plan AND distributing the Linux kernel via their own ftp server?
The only thing that shows up being even close between the Linux kernel and the versions of Unix with source available is what seems to be a derivative of malloc and mfree in ate_utils.c
ate_utils is/was part of the NUMA code for IA64. It has been removed from the latest development and prepatch kernels (it's obsolete, from what I've read.)
There are some less interesting similarities between the signal handling code, but that's hardly remarkable. How many ways can you write a switch statement?
The key thing to remember though is that SCO doesn't actually claim they wrote the code. They claim to own rights in code that IBM wrote. I would bet that it's safe to assume that a detailed inspection of AIX and Linux 2.4.21 will reveal similarities. The question is, does IBM have the right to relicense code they created?
What does overture have that is worth $1.63 billion to Yahoo?
Advertisers and listings. Yahoo is making the majority of it's money off pay-per-click advertising. It's only natural that they would try to consolidate and eliminate the middle-man. I'd expect this will drive Kanoodle and FindWhat through the roof and raise some serious concerns at Google. In the short term, this is probably a good thing for anyone who buys traffic from the search engines. Overture were dicks about minimum bids and what sort of pages you could link to... In the long run though, this is yet another sign that the pay-per-click pipe will be squeezed to the point of being useless. Personally, I expect to see the search engines start going after affiliate programs next. That will indeed be a sad day for anyone who makes their living as an internet middle-man.
Try Debian Help or Debian Community or even one of the mailing lists. And, of course, you can usually get instant answers by asking on irc.debian.org.
There is plenty of good community support available for Debian. The only time I've ever seen anyone suggest "RTFM" is when someone posts nonsence questions to the developers mailing lists without bothering to check the various developers manuals. I don't think it's unreasonable to expect DEVELOPERS to RTFM. Users are a whole different subject.
My biggest complaint w/ debian is the slow release cycle.
That's the very thing I like most about Debian. There are enough distros pushing for 6 month release cycles regardless of the reliability of the underlying software. Debian seems to take the opposite stand, sticking with old versions until the newer versions work properly. Personally, I'd rather have a reliable KDE 2.2 than a buggy KDE 3.x-beta1. I make my living using this software. I don't want to spend time tracking down obscure kdelibs bugs. I have a development system tracking Debian Unstable for that.
I was shown a little of the copied code. Admittedly, I can't tell you what I saw, but I did form the opinion that it was not in the kernel proper. In all probability, the code is more important to Silicon Graphics' Altix servers than to average x86 Linux users.
Ugh.. Altix is Itanium (AKA ia64.) This sounds very much like the code I pointed out yesterday. (ate_utils.c in Linux -vs- malloc.c in versions of Unix up to at least System3)
A couple of things people have pointed out about why the example I found should be legit:
(1) It's in BSD... No, I'm no expert on BSD history but from what I've read the settlement happened between BSD 4.3 and 4.4. Anything prior to 4.4 probably doesn't count since the whole reason BSD won is that they had rewritten all of the code. BSD3 contains pretty much an exact copy of malloc.c from Sys3, but the version in 4.2 looks newer than the version SGI used. I'd assume it's even more different in BSD 4.3 and 4.4.
(2) The code is common knowledge. This same form of malloc has been around longer than the C language. This sounds good, but it's hard to believe the code was written independently. The comments, structure, and variable names seem a bit too much to be coincidence.
(3) Caldera released the code for all versions of Unix prior to and including Sys3 under a BSD-style license. This is definitely the best argument, but SGI didn't include a "(c)Caldera 2001" in the file. The dates in SGI's copyright statment in that file are also out of line with the date of the Caldera offer, and it's easy to show that ate_utils.c was around prior to 23 Jan 2002. (Check the 2.4.17 ia64 port on Kernel.org)
The real question is why would SGI use versions of malloc and free that trace their lineage all the way back to 1973 Bell Labs when there are untainted, free, and better written versions of these functions available.
After going even further back, this code appears at least as early as Unix Release 5 with a Copyright of 1973 by Bell Telephone Inc. The comments appear later, but the code is basicly the same. I assume it was in BSD at some point, but why does the Linux version claim that Silicon Graphics owns the copyright?
I downloaded a copy of the OpenBSD 2.7 kernel and I don't see it. I realize there are a variety of possible explanations and I'm not a kernel developer so I don't really understand the context of this code or its history, but on the surface it certainly doesn't look good.
That's what I though as well. If it's BSD code why is it stuffed into the ia64 section. I'll hold off on any snap judgement, but my confidence in the validity of IBM's position has dropped down a few notches.
If you strip the whitespace before hashing it does turn up a few interesing things.
Comparing the code from the PDP kernel in sys3.tar.gz and the Linux 2.4.21 kernel there is a good match between the mfree function in usr/src/uts/pdp11/os/malloc.c around line 69, and the atefree function in arch/ia64/sn/io/ate_utils.c around line 187. It certainly looks like the version in SYS3 was used to create the version in 2.4.21. Take a look at the comments in these files, they're almost identical.
The copyright on the Linux version attributes this file to Silicon Graphics. Anyone want to grep for the same comments in a BSD kernel or provide a history of this file?
But there's nothing wrong at all with what RedHat's doing: they give you the binary, and they give you the source. Then they offer a separate deal, in which they'll support the software they gave you in exchange for money.
I didn't mention RedHat, but if you take a look at the licensing terms you'll see that their support contract wraps around the GPL software by claiming that if you accept any support contract you give up the right to freely use, and copy the software on any machines you want. In fact, their terms claim that you can't use the software at all without a support contract, but that's patently false so it's not even worth worrying about.
Debian, Gentoo, Slack, etc offer community based support which does not require any seperate agreement. They also don't make claims that their trademarks must be removed if you install any non-distro specific software on your machine. Check out RedHat's trademark guidelines page for even more fun. If you compile a custom kernel on your RedHat machine you have to remove all the RedHat logo's and trademarks even if the changes are only for personal use.
Anyway, I don't think RedHat is any worse than...say...Mandrake or Lindows in wrapping GPL software with additional restrictions. I just hate to see companies trying to make money this way. Sooner or later the restrictions will go a bit too far and we'll see the house of cards come tumbling down. Some enterprising developer will decide to start suing everyone that's wrapping their GPL work with additional terms. The GPL does not allow for placing additional terms on end users. Any support contract, download agreement, EULA, trademark restrictions which restrict the rights listed in the GPL clearly cannot apply to GPL software. I'd hate to see that proven in a court of law since it will only serve as a nasty example for GPL+Business doubters.
You do all understand that while the GPL doesn't permit tying by license, distros have now moved to using threats of invalidating support contracts to achieve the market leverage they need to exclude competitors, yes?
Although I agree with Reiser's statement that tying support contracts to a GPL product is/should be illegal, some of his other statements about the GPL have been questionable.
RMS responded to a question about some of Reiser's statements about the GPL v3 indicating that Reiser was incorrect about GPL3 including ad-removal restrictions.
The entire thread is an interesting read about the GFDL, GPL, and possible crossover between the two. Take a look at the author index for some other interesting tidbits.
Since you don't have to register with for a copyright any more aren't we all "copyright holders"? So if this logic prevails I have the right to destroy your computer because you read this comment and your browser made a local copy in the process? What comes after this? I get to chop off your hands?
* IBM will act in its own interests, of course, and not in the interests of the Linux community; what should we expect from them?
The fact that SCO has thrown the future of AIX into doubt along with the future of Linux means that IBM can't simply pack up and walk away. They have to see this resolved, one way or another. Personally I'm betting that IBM will buy SCO or a license that makes these allegations go away. I'd bet that they're waiting for the circus to die down so that SCO's stock will deflate to a more realistic value.
SCO are going to destroy *nix.
Not at all. They're validating many of the arguments in favor of free software. SCO can't stop Linux. SCO is still distributing Linux code on their own servers. The *MAY* be able to stop the sale of commercial derivatives of AT&T's commercial Unix, which just goes to show that you and I can no longer afford to gamble on the continued goodwill of commercial vendors. The licensing terms IBM had with AT&T are straightforward in stating that IBM owns the rights to its own derivative works, but now that SCO has become a lawsuit factory they claim otherwise. If AIX had been based on BSD there would be no issues at all.
Compared to SCO, the FSF is overly business friendly. The worst the FSF has done to glaringly obvious GPL violators pales in comparison to the kind of BS SCO is doing. I'm sure this will do wonders for SCO's IP sales. I can see folks lining up around the block to create new derivative works based on this IP.
At the very worst, you'd see Debian/RedHat/Mandrake/etc move to a BSD kernel. Debian already has a somewhat working port of the GNU userspace to BSD kernel. (Not related to the current lawsuit) How long would it take if all the vendors came together to work on it?
So no function names to remember, and who can remember some not very specific interesting variable name?
In the translation I read there was no mention of function names being removed, only dates and filenames. Surely someone going through all the effort to view the code can be expected to remember a few function names or the exact wording of the comments. Picking the exact lines out of the source should be trivial.
It's not like someone expecting you to remember an obscure function you wrote 3 years ago. This person was looking at small bits of code that are at the center of a major lawsuit. I find the lack of even one single identifiable line to be a good indication that this story is a fake.
$ wc -l sched.c
1460 sched.c
Which of the functions is he talking about? Given that he knew the area of the kernel he was looking at, why didn't he take a glimpse at the kernel source and point out the function name or line numbers?
I'm not saying this is proof that the story is BS. I'm just saying that the lack of any single concrete piece of code makes me doubt the story. I mean, wasn't the whole point to give juicy details that would be verbotten under the NDA?
I can't trust my own governement to tell me the truth...why should I assume this person is doing so?
No doubt. Cite a damn file name and line numbers. Without it, this looks like a scam to get traffic.
What use are vague references to jokes in comments? Tell the line numbers so that we can know for certain whether or not the code being shown comes from a questionable source.
If this story is true and someone did see SCO's code without a NDA then they're wasting the chance they've been given to cite some concrete examples of what SCO is claiming.
Since the author elected to provide the same sort of wish-wash "proof" that SCO is handing out to the public, it's hard to imagine this isn't a scam.
I think it's arguable that the enthusiasm is for Unix on the cheaper intel platform. Other Unix/Intel variants exist.
I'd say the enthusiasm is for a cheaper Unix. Sun doesn't seem to be offering that. If anyone really gains marketshare from the current litigation it's bound to be the *BSDs.
I think the key point in the quote though is that it seems to completely discount Free Beer and Free Speech as motivating factors. Solaris may appeal to businesses that are currently running AIX, but personally I'm not about to replace my Linux web servers with a proprietary Unix unless every free alternative disappears.
Forgot this one with the nice quote from a Sun exec:
Why do we think enthusiasm for Linux exists in the first place? The enthusiasm isn't about Linux, it's about access to Intel and the ability to run Unix on what seems to be a cheaper platform.
There are quite a few reports that SUN is hoping to make some headway with AIX customers due to the ongoing litigation between SCO and IBM.
Ok, I see two issues here. First, you can get all of the SRPMS (i.e., all of the source to build your own) from http://ftp.redhat.com/pub/redhat/linux/enterprise/ 2.1AS/en/os/i386/SRPMS/ [redhat.com], which I located by going to the download directory for 9, going up a few directories, and selecting enterprise instead of 9. Not intuitive, but the source is technically available, as per the GPL.
I think it's even worse than that when you add it all together. RedHat's trademark policies claim that any modification for purely internal use still requires you to remove all the RedHat trademarks.
"If you are an individual or business (including all subsidiaries of such business) and you only intend to use Red Hat® Linux® personally or, in the case of a business, internally, in the original form delivered by Red Hat (or its authorized distributors) or with modifications provided by Red Hat, you have permission to apply Red Hat's trademarks to all such internal copies."
So.. If I take a SRPM and compile it, it's certainly not in the original form delivered by RedHat.
What really worries me isn't that RHAS is a rip-off or that RedHat's trademark licensing terms are ass-backwards. I worry that other companies will accept this as a valid business model for GPL software. I don't want GPL software I write to be suject to this sort of sublicensing. If I wanted that, I'd use the BSD license.