Torvalds knifes Tridgell
Kernel source row turns nasty
Linux founder Linus Torvalds has followed up his weekend condemnation of reverse engineering with an astonishing personal attack on the integrity of one of the most respected figures in the open source community, rsync author and Samba co-lead Andrew Tridgell.
Torvalds accuses Tridgell of playing dirty tricks with his proprietary source code tool of choice, Bitkeeper and destabilizing the product. These are serious accusations to make.
Torvalds uses the pay-for proprietary software to manage the Linux source code (obliging other kernel developers to follow suit), but last week its owner, Bitkeeper CEO Larry McVoy, yanked the license, pushing Torvalds to look for an alternative. He's now going to write his own. For this inconvenience, he blames Tridgell.
Tridgell, we've learned, was attempting to gain knowledge of the Bitkeeper protocols on the wire, so he could allow the Linux kernel developers to retrieve their source code metadata from the dark dungeons of Larry McVoy's back garden (ie, Bitkeeper). This metadata is one piece of information that Bitkeeper regards as proprietary - to itself - so, if you're not a paid-up Bitkeeper licensee, you never get to see it. But kernel developers like to have this information, and Tridgell was trying to open up the possibility for a third-party client to work with Bitkeeper.
Torvalds strongly disputes this characterization of Bitkeeper, but McVoy has made his position clear: no Bitkeeper license, no metadata.
"You need to understand that this is all you get, we're not going to extend this so you can do anything but track the most recent sources accurately. No diffs. No getting anything but the most recent version. No revision history," he wrote in a post to the kernel mailing list on December 14, 2003.
When a developer pointed out: "All existing methods of getting information out of a bk repository either involve running bk yourself, or getting incomplete information," McVoy was adamant: "sorry, we're not in the business of helping you develop a competing product," he replied.
Many online services (such as AIM, Yahoo, and in its day, Napster) happily allowed third-party clients on to their networks. Our banks private networks even engage in such promiscuity... with each other!
So Tridgell's process of enquiry seems neither unreasonable, nor unprecedented.
Morality in software: now you see it, now you don't
In a post on the Real World Technologies discussion board appropriately titled "Hypocrisy the worst of human traits", Torvalds takes advantage of Tridgell's vow of silence on the matter. For the first third of his response, Torvalds gently tries to persuade us that ethics doesn't belong in the software business, taking a strictly utilitarian view. Or, as he puts it,
"So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative." he writes.
This is an odd statement for the leader of Linux to make. Openness and interoperability are values that many Linux supporters view as moral imperatives. It's even odder then, for Torvalds to devote the remainder of his reply to blasting Andrew Tridgell for being morally inadequate. And he lays into him with quite some fury.
Tridgell "screwed people over", claims Torvalds, portraying him as a hooligan who had no purpose other than willful destruction.
"'[Tridgell] ... tore down something new (and impressive) because he could."
Much as hooligans do.
"He didn't write a 'better SCM [source code management tool] than BK [Bitkeeper]'. He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about."
But this outburst doesn't add up for several of reasons.
Firstly, Tridgell legitimately wanted to get at data valuable to the Linux kernel developers: this motive cannot be described as selfish. Linus already had access to this having been given a Bitkeeper license by McVoy, but developers who declined the Bitkeeper license of course didn't. So at core, it raises issues of privilege and accountability: the Linux kernel developers need their metadata so they can do their work, they want to be able to that work using tools they choose; and it helps them keep an eye on what Linus is doing.
This is exactly what Tridgell had been doing on his Samba project. Microsoft's protocols are now "documented" - and you can even buy a license for them - but they're usefulness is dubious, because Microsoft obfuscates its protocols on the wire. So you need to deploy a Tridgell to make sense of these signals, if you're going to interoperate, and it's an essential principle of open source to allow such exploration.
Secondly, we know that Tridgell wasn't trying to scupper McVoy's services based model. He wasn't trying to build a server and no one in the Torvalds/McVoy camp has made such an accusation. At most, Tridgell is accused of wanting to create a client, or tools for a client, that isn't under McVoy's control. Anyone but McVoy would consider this is a win for open source.
What, we wonder, makes writing one open source access tool to a proprietary product (such as Samba) good, and writing another open source access tool to a proprietary product (such as Bitkeeper) bad? We're not alone in asking.
"Why would doing this (wanting to know the protocols and data) cause problems?," asks a baffled Jeremy Allison in reply. "That's the issue you're not addressing with your post. Why does doing this with BK cause problems, and doing it with SMB does not ?""
"I *know* tridge didn't want to tear down BK, as I'm sure you do also. You have to ask yourself where the blame for that outcome really lies."
With key participants outside the Torvalds/McVoy camp declining to participate and Tridgell staying tight-lipped, it's hard to piece together the sequence of events that led up to this mugging. But we'll keep trying. ®
Sponsored: Benefits from the lessons learned in HPC