Slashdot Mirror
SCO SCO SCO!
Still more links on SCO's assorted allegations of copyright infringement. They say they're going to sue Novell. Software analysts refuse to be part of the hoax - also some good quotes from Linus here. SCO and UNIX: a Comedy of Errors. Salon has a story on SCO too, but sadly it's not available to read freely. And Wired has an old story which I think sums up the SCO claims pretty well.
Would the team at SCO really keep pushing a lie, even though they know that by doing so they will face unspeakable countersuits after the trial(s)? I think that SCO is cleverly hiding an ace-in-the-hole, and it's going to hurt Linux and IBM badly. This is unprecedented: no company would ever commit suicide so blatantly and openly. I fear the worst is yet to come.
HAHA, yea right. Had ya going there, didn't I? SCOX stocks plummet some more.......
PS: fist post fools
SCO apparently seems to be suing everyone and anyone that stands in their way. So lets recap:
SCO sues IBM
SCO threatens sue Linus
SCO threatens to sue Novell
The whole unix world is in some kind of uproar now thanks to this crappy company over IP thats so old that it should have lost most of it's value anyways. Theoretically, the concepts and whatnot in the unix world can also be in Cisco and everywhere else.
What really blows my mind is that they don't own any of it, they are a sub licensee of Novell. Maybe Novell can revoke the contract with SCO and then they can no longer sue because they no longer can enforce the copyrights? I don't know, IANAL.
sri
"If Linux had all of the capabilities of AIX, where we could put the AIX code at runtime on top of Linux, then we would.
"Right now the Linux kernel does not support all the capabilities of AIX. We've been working on AIX for 20 years. Linux is still young. We're helping Linux kernel up to that level. We understand where the kernel is. We have a lot of people working now as part of the kernel team. At the end of the day, the customer makes the choice, whether we write for AIX or for Linux.
"We're willing to open source any part of AIX that the Linux community considers valuable. We have open-sourced the journal filesystem, print driver for the Omniprint. AIX is 1.5 million lines of code. If we dump that on the open source community then are people going to understand it? You're better off taking bits and pieces and the expertise that we bring along with it. We have made a conscious decision to keep contributing."
On the surface, those comments seem fairly damning, but let's think outside the box for a moment, something Bruce Perens is used to doing. "IBM is smart enough not to open source other people's intellectual property," he says. "Maybe the comment about being willing to open source any part of AIX that the Linux community considers valuable simply means that there is no portion of AIX that would be considered valuable by the Linux community."
2) You'll show me the secret code in question IFF I sign an NDA.
3) The code for Linux is freely available.
What's in the secret code that I can't see by looking the kernel source?
Are they the super secret comment statements that surround the code?
Is the secret code surrounded by super-double-secret code ?
What's next? I have to sign and NDA and wear a tin foil hat so Linus can't suck the super-double-secret code directly from my head and add it to the source?
Sounds like someone was sniffing glue and listening to the M$ FUD about the GPL over at SCO...
=tkk
Bill Gates - Creationist?!?
Even Slashdot posting could be next.
Pretty much the best write-up of this farce so far.
Help fight continental drift.
However, it seems to me that the incentives are totally analogous. Programmers in the open source world code (mainly) to help others, or show off their skills (for prestige or a better job). If they are caught cheating then they obviously are not helping, and plus they lose a lot prestige.
Similarly, the people who manage open source projects clearly want their project to be successful and popular. If they accept infringing contributions then they jeopardise this, so they have an incentive not to. There may not be a direct economic incentive, but that doesn't mean the incentive isn't just as strong. The only conundrum is the familiar one that, in the free software world, people do things for reasons other than money.
I am a lawyer--specifically an IP litigator.
Any litigator knows that you don't want to go to trial--you want to force a settlement. If you hae a halfway decent case, you'll show your evidence up front, so the other side sees that it's going to lose. On the other hand, if you have no case, then you try to keep everything under your hat and stretch out the legal proceedings until the other side pays just to make you go away.
Which of these sounds like SCO? I think that they have squat and I think that SCO and their lawyers know it.
BTW, if SCO doesn't produce evidence, IBM can file a motion to compel discovery and demand to get it. If they still stonewall, IBM can move for dismissal and get the whole case thrown out.
Several years ago I made a strong push to move my career from SCO to Linux. One of the main motivations for this was that I was so fed up with SCO, SCO support, SCO licenses (and policy daemons), and most of all SCO crashes. It was so bad - SCO eventually made the entire OS mirror a bunch of soft links to the real files, and changed their FSCK program so as not to do a real fsck on bootup. (which made things worse) They litterally had programs to undo the damage of their crashes like "fixmog".
I also got sick of people insisting that SCO was commercial quality UNIX while blowing off Linux, while I knew darn well that Linux was more trustworthy and stable, and the only way to get decent productivity out of a SCO box was to install tons of free software on it that was often better then the software you licensed out the nose for from SCO - they even licensed TCP/IP for chrisake. Anyhow, sometimes I still do SCO work, because I'm one of the few that know how to nowdays - but none the less I am so thankfull that this next generation will never need to deal with them. And I am so thankfull that many of the businesses that toiled under SCO now have the freedom to be productive with their computers.
I am also thankfull that people no longer need to suffer under their lies, lies about quality, lies about stability, lies about being for the enterprise, and most of all lies that they were better than free software. They are so full of it. At home I tell my 4yr old daughter no-no, and in the enterprise I tell business men sco-no.
Goodbye and good-riddance SCO, I should have known you'd sue IBM. You maximized damage and harm to the computing industry for years, it only makes sense you'd do it on your death bed too. Goodbye and good riddance.
I've been outraged, puzzled, and amused by the on-going SCO saga. While I think SCO is unlikely to succeed in their current "endeavor," I am increasingly concerned about open source legal vulnerabilities which I think SCO is exposing, and which I think the open source community should address more vigorously.
Consider the following scenario:
Imagine that the Linux kernel developers are having trouble designing a driver for some new hardware device: a winmodem, a video card, a hard drive or whatever. The manufacturer, ACME INC, has released a Windows-only (binary) driver, but doesn't appear willing to cooperate with the development of an open source driver. Furthermore, ACME's minimal published specs for the device seem to be wrong in significant ways.
The Linux driver is buggy and giving users trouble. A volunteer - Mr. Smith - presents himself to the Linux kernel mailing list. He says he has the device in question and he would like to try to help with improvements to the Linux code. Taking the existing driver code as a start, he makes a series of important contributions over a few weeks that resolve the difficulties. His changes are incorporated into the kernel source and released as part of kernel 2.6.30.
A few weeks after the release of 2.6.30, Linus Torvalds and Alan Cox receive an angry letter from ACME Inc. ACME claim that large portions of ACME's original (proprietary) driver code have been incorporated into the Linux driver code. Furthermore, they are incensed that the kernel developers accepted contributions from Mr. Smith, who, it turns out, is an ex-employee of ACME, dismissed for serious financial improprieties. ACME is convinced that Mr. Smith has stolen their code and released it under the gpl in order to harm ACME's competitive position in the market. (ACME says that a careful reading of the Linux driver code clearly reveals that Mr. Smith made use of ACME's trade secrets.)
The company decides to sue Linus Torvalds and the kernel developers. The suit does not allege that the kernel developers knowingly tried to harm ACME Inc. Rather, the claim is that the kernel developers didn't exercise "due diligence" in vetting Mr. Smith and his contributions. In effect, ACME says that someone in a position of responsibility should have asked Mr. Smith where he worked previously, and an effort should have been made to contact Mr. Smith's previous employer. Furthermore, the kernel developers should have asked ACME to review the Linux driver code before it was released.
During a news conference, ACME's CEO says:
"Every computer company in American does a at least some background checking before they hire someone to work on an important project. Where did the employee get their education? Where were they employed previously? Did they have any significant problems at their previous place of employment? In the Linux world such questions are rarely asked or followed-up on, even though Linux advocates claim that millions of people rely on the Linux operating system. In failing to ask such questions of Mr. Smith, the Linux kernel developers made themselves legally liable for the harm that resulted when he exploited the open source development process for nefarious ends."
My question is: Is this a plausible scenario? What safeguards are in place to prevent such a scenario from coming true? Are these safeguards adequate?
Ok so we've got our hypothetical 5000 lines of offending code. Now lets count the number of lines in every .c file in linux-2.4.20.tar.bz2 ...
TMPFILE=`mktemp /tmp/$0.XXXXXXX`
for i in $(for i in $(for i in $(find ./|grep "\.c"|grep -v Documentation);do cat $i|wc -l;done);do echo $i;done);do echo -n $i+>>${TMPFILE};done;echo "0">>${TMPFILE};echo quit>>${TMPFILE};bc -q ${TMPFILE};rm ${TMPFILE}
Which gives us 3332935 (including comments but hey we're lazy).
And this seems reasonable give that according to this link which shows ~1.8 million for a 2.2 kernel so yeah hey what's another 1.5 million between friends? (think of all the new hardware support)
Ok so we've got our probably bogus number of ~3.3 million lines of code. Remember N? Come on you can do the next step its fun!
5000 / 3332935 == 0.0015% and lets be super generous and assume comments make up 40% of our line count...
5000 / 1999761 == 0.0025%
I wonder what the statistical liklihood of having similiar blocks of code of some signifigant size that happen to be the same (excluding format and variable differences). I mean there's only so many ways one can _intelligently_ code a given function
Given those kind of percentages I doubt a judge or jury could be convinced of any copyright infringement of any signifigance. It'd be kind like trying to sue a competing encyclopedia company for swiping that one entry in the "P" volume on "Petards" ("hoisting", "petard", look it up) from you and demanding millions of dollars in compensation for this plagerism (ok so this analogy sucks but I had petards on my mind so...)
-- schubert