News from the SCO front [LWN.net]

The SCO Group, a little while back, filed a motion asking for a delay in the trial of its suit against IBM. According to SCO, IBM's foot-dragging had slowed things to the point that SCO could not get its act together in time. IBM has now responded; the full filing can be read in PDF format. It is not particularly surprising that IBM opposes this delay.

In fact, IBM has taken this filing as an opportunity to stiffen its language against SCO in general:

Since this suit began in March, 2003, SCO has publicly touted its evidence of IBM's alleged misconduct, but has resisted disclosing the supposed evidence to IBM. In fact, SCO's Chief Executive Darl McBride commented in an interview that SCO was 'fine to go to court just on what we have before discovery.' ... In contrast to its public assertions, SCO's conduct during discovery reflects a remarkable pattern of delay and obfuscation.

It's not clear when the judge will rule on this motion.

A hearing will be held on June 9 on SCO's suit against DaimlerChrysler, with a focus on Daimler's motion for a summary dismissal of the case. As reported in Groklaw, this case appears to have drawn a no-nonsense judge who will try to see things through to a resolution in relatively short order.

The Free Software Foundation received a subpoena from SCO last year; they have now posted the subpoena on their site with some related discussion. It will surprise few to see that the subpoena is impossibly broad; the FSF has no intention of fulfilling it in its entirety. Being the FSF, they cannot stop with just the subpoena, however:

In addition to answering and/or disputing the subpoena, we must also educate the community about why it is that Linux was attacked and GNU was not. For more than a decade, FSF has urged projects to build a process whereby the legal assembly of the software is as sound as the software development itself. Many Free Software developers saw the copyright assignment process used for most GNU components as a nuisance, but we arduously designed and redesigned the process to remove the onerousness. Now the SCO fiasco has shown the community the resilience and complete certainty that a good legal assembly process can create.

The FSF is right to emphasize the importance of ensuring that stolen code is not merged into free software projects; there is no doubt that more care is called for in that regard. Claiming that the FSF's copyright assignment policies headed off a legal attack from the SCO Group seems a little strong, however. It seems just as likely that SCO was repelled by the FSF's small bank balance. IBM, too, has strong rules covering its code contributions; armies of lawyers are involved. Those rules did not keep SCO from suing IBM, however.

Expect some fun around June 2, when SCO will announce its second quarter results. One can only assume that said results will not be of a kind that will revive the company's stock price, which fell below its one-year low this last week. It will be interesting to see what the company comes up with as a way of distracting attention from these matters.

(Log in to post comments)

Clarification

Posted May 20, 2004 16:48 UTC (Thu) by Ross (subscriber, #4065) [Link]

"The FSF is right to emphasize the importance of ensuring that stolen code
is not merged into free software projects..."

I don't see the FSF doing any such thing. I'm sure they do take steps to
avoid this, including an copyright waiver from employers, plus the copyright
assignments with relatively detailed scopes. But that is at best implying
they ensure "stolen code" (sounds like a SCO catchphrase) is screened out.

There's really nothing any project, whether run by a company or individual,
open or closed, can do to make sure this doesn't happen unless you have
watchers for each programmer. At some point it has to come down to trust.

Clarification

Posted May 20, 2004 18:56 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

The FSF goes further. They require indemnification. That means that if you sign the forms to contribute code to the FSF, and you know it's someone else's code, you pay any damages that the FSF might have to pay, at least until you're bankrupt. That's a legal protection Linus does not have.

FSF and stolen code

Posted May 22, 2004 18:58 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

The GNU Project's (FSF) process makes it a whole lot less likely that GNU Bash contains stolen code than that the Linux kernel does, but I agree it doesn't eliminate the problem completely. There's still the problem of the contributor who deliberately or mistakenly claims he owns the rights to contributed code when he really doesn't.

In that case, the GNU indemnification requirement is barely meaningful. It doesn't protect a user of Bash. Under copyright law, a user of Bash can be liable for royalties to the actual copyright owner of the code. That could be, for example, the guy from whom that contributor copied it, or the guy for whom he wrote it for hire.