Since you're a veteran of the AT&T vs. BSD legal battles, could you draw some parallels between that battle and...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
SCO's suits? In the 1990s, the IT people at AT&T, which was USL [Unix System Labs] by that time, had not been around when their software's code was being developed and integrated during the 1980s. The AT&T people who had brought the code in had deleted the Berkeley (BSD) copyrights. So those folks in the 1990s started comparing their code base with the Berkeley code base, and they found lots of the same code in the Berkeley code base and the USL/AT&T code. They didn't realize it hadn't originated at AT&T. That is what caused the whole thing to start in the first place.
After they brought this out, they found out what had been going on and started backpedaling. Out came all of these questions about what code belonged to Berkeley and what belonged to AT&T.
You have the parallel situation where the accuser, AT&T or SCO, sort of drags his feet and finally brings out a file or two to state his case. Also, it's the same situation in that there is just so much code that has come from so many different places over many years, and the attributions have gotten lost. What happens then when attorneys are brought into this situation?
The intellectual property lawyers are used to looking at code that didn't have an open source base at some point in time. So, the code they know well has a very strong lineage, and pretty much anything that is there, was written at the company and documented, including contracts that turn over rights from one company to another company. So, in these proprietary software cases, all attorneys needed to do was to compare their clients' code with the alleged infringing code. If an attorney finds anything that matches, he's made his case.
In the AT&T and SCO cases, I think that the lawyers made a lot of those same mistakes of assuming that if code matched, someone was trespassing on their client's intellectual property. What lessons were learned from the BSD situation, and what lessons weren't learned but should have been?
What you really need is a well-documented trail of ownership. At BSD, we learned from that legal battle that absolutely everything had to be maintained under a source code control system. You have to document with every line of code, who put it in and where that person got it from. That person has to have a signed release from the originator saying that it is OK to use the code.
The thing that saved our bacon in the long term with the AT&T/USL suit was that we now have a documented trail. Since that time, BSD has been fanatical about maintaining that trail. There's a record for every single change that is in BSD today saying who put it in, where it came from, why they put it in. Isn't Linux documented in this way?
Up until fairly recently, Linus [Linus Torvalds, the creator of the Linux kernel] didn't believe in source code control systems. My understanding is that he felt that the source code on his machine was the master source --he knew where everything came from -- and you didn't need to use source code control because he had centralized control.
We can argue whether that is good or bad, but there isn't a well-documented ownership trail with Linux. So, they have opened themselves up to a swamp of "he said-she said" about where code came from. Now they have started documenting, but they will have to dig themselves out of the swamp in the meantime. It was and is a hard lesson for everyone involved.
SCO's battle has been a battle by press release. If you look back at the BSD and AT&T/USL situation, they really stuck to the courts. If anything, they shied away from publicity. Anytime something would leak out about it, they would be grumpy with us and say, 'this is something that we want to sort out, and then we will make a public statement.' I think that is a much mature way of handling the situation.
In the end, I think SCO will look foolish. Since AT&T/USL didn't make a big deal about it, they didn't look foolish.
Of course, in the short run, SCO's approach has been helpful in turning around the stock price; that is, until recent developments with BayStar [Capital]. Also, some companies using Linux are paying SCO for licenses. These are different times, and battle-by-press-release seems to be a popular business strategy. Do you believe that SCO's overreaching objective is to get legal sanctions placed on business' usage of GPL and open source software?
Despite all of their pounding around that topic, I really think that is a secondary goal for them. I think they really want to collect license fees on Linux first. They might want to knock out the GPL as far as Linux is concerned in order to collect license fees. I don't think SCO cares about open source software like Apache.
Maybe some of SCO's funding people may care about getting rid of the GPL. If Microsoft is involved, they might care; but even Microsoft is beginning to include open source software as part of their software ecology. Look at the stuff Microsoft is doing with spam now, working with America Online, EarthLink and Sendmail because they're not going to make headway against spam unless the open source and the proprietary software worlds work together. In your opinion, can the GPL stand up in court, and why or why not?
I think it will stand up because it stands on the simple premises of copyright laws that are well established. Copyright law says that the owner of the copyright gets to decide how their thing is used. If the owner of the copyright says you can use this in any way you want to, except that you have to follow these rules, that is the same as a copyright owner saying you have to pay me royalties.
Read part 2 of this interview tomorrow.
FEEDBACK: Does Linux need better documentation?
Send your feedback to the SearchEnterpriseLinux.com news team.