This article is more than 1 year old
The Larry and Linus Show: personalities vs principles?
Kernel row rumbles on
Letters Last week Linus Torvalds ditched the source code tool he's been using to maintain updates to the Linux kernel tree for the last three years. That's a fact so unremarkable few news organizations would think it merited a story.
But it's no ordinary decision: for it pits friendship against principle, the core of any great drama.
And Reg readers don't need much of an invitation to be very perceptive drama critics. Here's how you see it.
Not one correspondent begrudged Larry McVoy, who took the Bitkeeper tool under a proprietary license last week, the right to make money from closed source software. Not one doubted that his Bitkeeper software is good. Very few correspondents seem to be laboring under the mistaken impression that Samba developer Andrew Tridgell was in the wrong either legally - by "breaking" a Bitkeeper license he didn't agree to - or morally.
Let's unpick this tangled web.
I think Linus is letting his friendship get in the way of his thinking.
Come on, how can you make a replacement without referring to the original? You make a consistent UI? Need to look at the original. Make it read the files? You need the files created by the original. Need to operate on the network (as in a replacement *client*)? Need to sniff the network the client is on.
Since this last one is what happened, if that is not moral reverse engineering according to Linus or Larry, how can the information be gleaned "morally"? Or do they mean a *competing* product is fine, but not a *replacement*?
I hope that both Larry and Linus remove OO.o and SAMBA from their networks, since these were reverse engineered products riding on the coattails of others.
If Larry didn't want a bad client to corrupt the system and cause $35,000 damage, maybe he should fix the server so that the server is more robust. What if there was a corruption on the network, or someone killed the client halfway through (both possibly causing corruption). If he didn't want reverse engineering because it could kill the server, maybe he ought to open up the API to the public.
No, I think he just got all the free fixes he wanted and the support of the free licenses were now more than the benefit he saw from it (this is from quotes he made earlier on this issue).
What's wrong with Linus? Maybe he doesn't want to admit RMS/Bruce/etc were right and he wrong. Maybe he just wants to protect his friend, even if that means attacking other friends.
Several of you want to make the point that Linux isn't a reverse engineered Unix™ -
It seems to me this could be the first of many serious splits in OSS development, not least that the personalities have become more important than the software.
But having said that I don't get what Linus is saying here; a lot of OSS is anything but innovative, it might be well written, solid stuff, but it isn't exactly new. Linus never had to start from scratch in figuring out an operating system, Linux's origins are found from Unix. OpenOffice and Mozilla are both clear derrivatives of once commercial products. Even Samba is just a Unix clone of a Windows client. I'm not saying they reverse engineered anything but neither are they entirely original - in fact some OSS versions of commercial products are utter shit (compare the Gimp to Photoshop or Scribus to Quark or PageMaker).
I just get the feeling Linux is going to back himself into a corner -- frankly he should never have used a free version of a commercial product in the first place, if people so involved with OSS and/or the GPL won't eat their own dog food, who will?
The fact that Linus is having to abandon use of BitKeeper due to the proprietary licensing of it and the decision of its proprietary owner to change the licensing terms, after having become somewhat dependent upon it, demonstrates the downside of proprietary software more than anything you or I could say about this.
Perhaps Linus feels he has a favour to return to Larry, in the sense of the gratis use of BitKeeper to date (and perhaps not wanting to be sued by Larry: check the BitKeeper terms which prevent any user of the previously free product working on anything similar), however, this is probably far outweighed by the marketing and testing benefits Larry has obtained through Linus's BitKeeper use.
So there are likely to be entirely rational and understandable diplomatic reasons for Linus not wanting to slag Larry off right now.
Best regards, Richard Kay
As far as I can see from reading the original source material, Linus Torvalds is being pragmatic and practical here and trying not to offend unnecessarily; Larry McVoy is defending his product, possibly to excess (reverse-engineering for compatibility IS a legitimate activity, after all), and Andrew Tridgell is keeping very quiet while being somewhat maligned by the NewsForge article.
I grant you, it's a bit odd how faint Linus' praise of Tridge is, but I don't see any real philosophical conflict between Linus' words and deeds. He's never made any bones about his willingness to use the proprietary BitKeeper product or his reasons for doing so; it does things no Open Source product yet does, and he needed that.
Andrew Tridgell, while he's being very low-profile here, appears simply to have been building a tool that can interoperate with BitKeeper repositories; no bad thing in itself. As concerns all the interpersonal conflict, I don't know enough to understand the situation fully, and likely never will. McVoy, on the other hand, does seem a bit ethically-conflicted here; he's gained a lot from the Linux community's use of BitKeeper (not least a number of corporate sales and intensive development feedback), yet he seems to claim it was all a giveaway with no benefit to him.
His insistence that a competing Open Source product is OK also seems at odds with his dislike of reverse-engineering. (As one Slashdotter put it, in the absence of adequate documentation to interoperate with BK repositories, reverse-engineering is the only way left to achieve interoperability).
His characterization of folks reverse-engineering BK as freeloaders seems rather disingenuous in light of that fact.
Now then. Many of you pounced on the comparison that Linux itself was "reverse engineered". David Chisnall drew out some of the subtleties.
I agree with your point about Samba and OpenOffice. Both of these reverse engineered file formats and protocols. The situation is not quite the same as for BitKeeper, since reverse engineering the format can also give clues as to the algorithms used for implementation (for example, efficiently performing merges) - something that a lot of R&D money will have been spent on. Linux, however, implements fully public APIs, and can be created with no access at all to any existing implementation of these APIs. Linus himself has gone on record several times as saying that he has not used Solaris (for example), or other UNIX implementations. In most jurisdictions, reverse engineering must be performed in a clean-room context. The people performing the reverse engineering may create documentation on the file formats and APIs, and the re-implementation must be performed by a team which has no direct contact (other than the documentation) with the first team. This is how, for example, the original IBM PC BIOS was reverse engineered.
Someone who is an employee of a high-profile licensee of the software in question clearly does not fulfill this requirement.
But we must be careful here.
Suppose you had to explain to the man in the street, who neither knows nor cares about such things, the following.
Firstly, try and explain why crafting an open source, compatible version of software that works with HP-UX® and UnixWare®, is good for the world. Then try and explain why creating an open source, compatible version of software that works with Microsoft® Office™ Word&trade documents is good for the world. Now, try explaining why creating an open source, compatible version of software that works with Bitkeeper is bad for the world.
The fact that, say, POSIX is documented, or Word's OLE binary stream isn't documented, is an implementation detail, and both are quirks of history. Neither fact alters the moral rights or wrongs of crafting an open source, compatible version of a chosen piece of software. And viewed in terms of moral rights Andrew Tridgell is the only party in this dispute who is being entirely consistent. ®