decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
The Economist Article: Looking at Open Source at a Tilt
Friday, March 17 2006 @ 12:33 PM EST

You probably saw the article on Open Source in the Economist, "Open, but not as usual".

If you did, you read it and probably sighed. The premise of the article is that the very openness of the Open Source method is its worst vulnerability, particularly as attempts are made to extend the method beyond software, and as the title implies, that Open Source is changing to become more like proprietary. It is also another attack on Wikipedia. My, there's been a lot of anti-Open Source mileage out of that. I have news for you. Wikipedia is not an Open Source project. It's a cousin, maybe. But it's an entirely different kettle of fish, as I'll explain.

This is the part in the article that got me sighing:

The open-source method has vulnerabilities that must be overcome if it is to live up to its promise. For example, it lacks ways of ensuring quality and it is still working out better ways to handle intellectual property.

But the biggest worry is that the great benefit of the open-source approach is also its great undoing. Its advantage is that anyone can contribute; the drawback is that sometimes just about anyone does. This leaves projects open to abuse, either by well-meaning dilettantes or intentional disrupters. Constant self-policing is required to ensure its quality.

First of all, Open Source, for example the Linux kernel, has never been anything but controlled by Linus. At the bottom, anyone can contribute, true. But there is a definite sieve-like process as the code moves up through various lieutenants until it finally gets to Andrew Morton and Linus. Anyone can comment on the code, offer fixes, or something better. But the thing is, Linus has always been there at the top, with total veto power. It has never been a free-for-all.

You know that. I know that. So why doesn't the Economist? Instead, the article goes on to assert that the Wikipedia method leads to chaos and so Open Source needs to tighten up, and more, that it now realizes it and is. What poppycock.

And of course, there is the obligatory reference to SCO, and the usual misinformation:

The question of accountability is a vital one, not just for quality but also for intellectual-property concerns. Patents are deadly to open source since they block new techniques from spreading freely. But more troubling is copyright: if the code comes from many authors, who really owns it? This issue took centre stage in 2003, when a company called SCO sued users of Linux, including IBM and DaimlerChrysler, saying that portions of the code infringed its copyrights. The lines of programming code upon which SCO based its claims had changed owners through acquisitions over time; at some point they were added into Linux.

Heh heh. Not exactly. IBM wasn't sued for using Linux. It was sued for contributing code to Linux. SCO mainly is suing IBM by means of a theory of contract, as best as anyone can make out, a ladder theory by which somehow the contract can be interpreted in a novel way so that any code IBM writes, if it ever touches UNIX SystemV, or if it is kind of similar to methods and concepts in Unix, can then be controlled by SCO, even if there is no SystemV code or derivative code in it. Nice work if you can get it. Here's SCO's Second Amended Complaint if you want to try to figure it out yourself.

And by the way, when code is written by many authors, they all own the part they individually wrote. Is that hard to grasp? No need to travel to Delphi to get that puzzle solved. Each author holds the copyright to his own piece of code. That's the Linux kernel setup. Think of it like a collection of short stories. Each author holds copyright in his story, and the editor might hold a copyright in the collected work. In other projects, say under the GNU umbrella, the Free Software Foundation might hold the copyright. In other projects, a foundation set up around a specific project might.

SCO certainly tried to assert copyright claims, although at one point it swore up and down it hadn't, but the judge in the case was not impressed with their evidence. Their copyright claims had to do with continuing to distribute AIX after SCO allegedly terminated their license. Look at the Complaint, and you'll see that in the Fifth Cause of Action. I know. That doesn't match what SCO said in the funny papers. But read the court filings for yourself, and you'll see. Copyright is more of a problem only because they don't have any Unix patents to sue over.

Copyright is a problem *for* SCO, however, because Novell has asserted in a blazing Answer with Counterclaims that Novell owns the copyrights, not SCO. Should that get established, SCO is ...well, pretty much a dead duck.

And DaimlerChrysler wasn't sued for copyright infringement. There was only one cause of action, breach of contract. AutoZone was, but when push came to shove, it turned out it was really about them switching from Unix to Linux, and SCO asserting they used SCO's shared libraries to make the switch, something AutoZone denied. The judge in that case said that SCO's claims against AutoZone would be completely undermined if Novell wins.

If you wish to check my accuracy, and by all means do, here's SCO's complaint against DaimlerChrysler, which the Economist forgot to mention SCO lost in all significant parts in 2004. It was an embarrassing rout. The last little bit might get resurrected someday, but if it is, here's what the Order dismissing the complaint without prejudice on stipulation says will happen:

IT IS FURTHER ORDERED that, in the event Plaintiff The SCO Group, Inc. refiles its claim for breach of contract for Defendant DaimlerChrysler Corporation's alleged failure to respond to the request for certification in a timely manner, Plaintiff shall pay Defendant's costs and reasonable attorneys' fees incurred in the instant action in defending against that claim only, from and after the entry of this Court's August 9, 2004 Order Granting in Part and Denying in Part Defendant DaimlerChrysler Corporation's Motion for Summary Disposition, as a condition precedent to pursuing any such refiled action.

SCO tried to appeal the August order, but it was dismissed. Nobody is quaking in their boots over DaimlerChrysler. It stands for the proposition that you can sue anybody over any foolishness you please, as long as you don't mind having good men everywhere burst out laughing at you. DaimlerChrysler hadn't used Unix for almost a decade, something SCO apparently didn't bother to check before litigating.

And here's the complaint against AutoZone, which is moribund, to be resurrected only after IBM is decided and only worth resurrecting if Novell loses too, neither of which anyone I know and respect is expecting. You can read this transcript of a court hearing in the case to learn about the real issue, the libraries. If you wish to read all the documents in the case, just go to our Legal Docs page and help yourself. Here's the DaimlerChrysler collection. And here's Autozone. And here's IBM. And here's Novell.

I'm pointing out all the mistakes in the Economist article, not to be mean, but just to say that if Wikipedia had made as many errors, there would be anguished cries of inaccuracy and calls for reform of the Wikipedia process. When the mainstream media makes huges errors of fact, nobody even remarks on it. Except for Groklaw. It's our calling, you might say. I've been writing Groklaw now daily since May of 2003, carefully and laboriously chronicling and correcting all the mainstream media's mistakes in their reporting on the SCO litigation, and I haven't run out of material yet, have I? What does that tell you about accuracy in journalism done the old-fashioned way?

Actually, I can tell you a little story about the Economist article, because the reporter on this story contacted me in January and interviewed me in preparing this article. So you can't say he made mistakes because he didn't know about Groklaw or had no idea where to turn for raw material on SCO. You can't even say that no one told him before his article was published that he was making mistakes in his overall concept. Here's the rest of the story.

In January, I got an email from the Economist, asking to interview me:

I'd be keen to chat with you briefly about the issue of how benefits of open-source entail inherent vulnerabilities that need to be addressed (eg, Wikipedia and accountability/accuracy). I read your piece in the O'Reilly book "Open Sources 2.0" and thought it might be good to chat briefly.

I noticed that he was laboring under some wrong ideas, and looking at the finished article, I notice that he never wavered from his theory, so I don't know why I even bothered to do the interview. But I requested that he send me questions by email, which I'd gladly answer. Here are two of his questions pertinent to this article and the answers I sent back:

* When you realized you needed to establish some controls to remedy the threat of well-meaning poor-performers or intentional disrupters, where did you go to find models for what to do? If it was the open source software community's practices, please explain the parallels regarding how they police their contributors with respect to how you do....

PJ: I analyzed it somewhat like this: what will work without violating principles we share? Many readers suggested an official comment policy, so we wrote one together. That made it easier to implement, because we all agreed, as we learned from experience. I rarely have to do anything, because others immediately spot disruption attempts.

But I also was influenced by a paper I'd read, whose name I forget, that compared the effectiveness of the Linux development process as a pyramid, with Linus at the top. He's at the top because it's his project and because others respect his skill and ability.

The paper pointed out that at the bottom of the pyramid, there are no barriers to entry, however. Anyone can contribute code and ideas. But then there is a filtration process, whereby everyone evaluates the code/idea in public, and then lieutenants implement or not, so that Linus sees the discussion, but the code sent to him isn't sent by just anyone in the world. There is a merit test first.

I decided I'd do it that way too. It helps me, because time is always at short supply, and it helps me because over time, you learn who is trustworthy and effective and willing and you can rely on their judgment. But one person has to be willing to be the bad guy and say NO when it's necessary, and the vision is that person's responsibility to move forward by making tactical decisions.

And in a project that involves a specialty, you can't have a democratic process where it's one man, one vote. The Linux development process doesn't work that way, because some people are better at coding than others, and some are more interested in the project sticking to what it set out to do. Others come along with ideas to extend the project to suit their ideas, or what their business wants, and sometimes they're fine ideas, but they don't work to push the project where it's trying to go.

It requires folks in decision-making roles who get that and are willing to lop off ideas that lead to dead ends. Also, in a legal project, you are more constrained, by the law, for one thing, and because not everyone understands the law equally.

* If you were to make any recommendation to Wikipedia with respect to overcoming the controversy it faced in terms of inaccurate information, what would it be?

I view the Wikipedia story somewhat differently. In my view, the false report, which was intended as a joke in the first place, not a malicious act, was fixed, the victim received an apology, the joker lost his job, and the whole world learned that it was not true information. Could a defamation lawsuit get you more than that? Well, money maybe, but if your concern is your reputation, the Wikipedia event was a template in fixing things right.

In contrast, I was, in my opinion, defamed by several articles in the professional media. I believe it's all part of SCO's strategy (and friends') to destroy Groklaw's and my reputation, so folks won't believe what we publish. In one case, a journalists' professional group sent a letter to Forbes pointing out factual flaws in their article. The letter was not responded to in any way that I ever heard about, no correction was ever published, no apology was forthcoming, and no one was disciplined.

So I ask, which is worse? The way Wikipedia handled an injustice? Or the way the mainstream press does? One's only relief with the latter is to bring a lawsuit against the mainstream press, if they don't fix it themselves, yet the bottom line with Wikipedia is: if you see a mistake about yourself, you really can just fix it yourself.

Obviously, I made no dent in his theory of the article, that Wikipedia is flawed because anyone can work on it and that Wikipedia is an example of problems in Open Source. My view is that Wikipedia isn't an example of Open Source precisely because there is no Linus at the top. Here's a very clear and accurate description of how the Linux kernel is developed, from a 2004 article in InfoWorld by Paul Venezia:

Decisions on what features and patches are incorporated into the official kernel are generally preceded by much debate among kernel developers, but are ultimately made by the kernel maintainer, a central authority who shoulders the brunt of day-to-day maintenance, as well as the responsibility for official kernel releases. Given the size and scope of the kernel, neither the maintainers nor Linus Torvalds himself can fully know and understand every portion of the kernel. To alleviate this, several unofficial kernel subsystem maintainers are entrusted to keep a watchful eye on their chosen sections of the code and to contribute validated patch sets to the maintainer for inclusion in the next release.

New releases of the stable kernel are vetted through a release candidate process, during which kernel patches are tested by the community. In addition to release candidate kernels, patches for stable and unstable kernels are distributed by a select few core developers, such as Alan Cox and Andrew Morton. These patches usually contain experimental code that hasnít been officially introduced into the source by Torvalds, as well as bug fixes or hardware support likely to be incorporated into the next release.

While the kernel maintainers are responsible for the kernel under their care, Linus Torvalds still runs the show.

So, as you can see, the title of the Economist article should have been "Open, as Always." Nothing about the role Linus plays in running the show has changed. And Wikipedia isn't run like that at all. For what Wikipedia is, though, it certainly works at least as accurately as the mainstream press, as the Economist article, I think, amply evidences. So what do we do with the mainstream press? Just keep trying to educate them, I guess. And when we read what they write, I think it's wise to reserve judgment on any conclusions we see. It might be true. Then again, it might be completely wrong information, as the SCO info in the Economist was and is. Funny thing. He could have just asked me, and I could have shown him the legal documents. So I think there is no excuse.

This isn't an attack on anyone, by the way. I am sure he is as nice a guy as you can find. The problem is the process. There is a shocking lack of accuracy in the media. I'm not at all kidding. Wikipedia has its issues too, I've no doubt. But that is the point. It has no greater issues than mainstream articles, in my experience. And you don't have to write articles like this one either, to try to straighten out the facts. Just go to Wikipedia and input accurate information, with proof of its accuracy.

If you would like to learn about Open Source, here's Wikipedia's article. Read it and then compare it to the Economist article. I think then you'll have to agree that Wikipedia's is far more accurate. And it isn't pushing someone's quirky point of view, held despite overwhelming evidence to the contrary.

If I wrote an article pointing out this many mistakes in a Wikipedia article, it would set off an orgy of antiWikipedia articles, I'm sure, all of which would use the errors as "proof" that the system doesn't work. Well, folks, what is good for the goose is good for the gander. Neither system is without flaws, peculiar to its own methodology. Errors crop into anything humans write, no matter how many or how few are involved, because we are humans. Experts make mistakes too. And sometimes folks put a little spin on the ball, consciously or unconsciously. That's why Groklaw always provides urls to proofs, so you can check for yourself and make sure of the facts with your own eyes. If I make a mistake, I want you to find it, and the more of you there are looking, the more likely it is you will find the correct information so errors can be corrected. If truth is the goal, that's the only way to think.


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )