Slashdot Mirror
BitKeeper Love Triangle: McVoy, Linus and Tridge
erktrek writes "NewsForge has given a brief interview to the parties involved in the (inevitable?) BitKeeper debacle." Here is some of our previous coverage.
← Back to Stories (view on slashdot.org)
Any chance we could get a 1-2 line summary of what the "debacle" is exactly? The summary above is practically just a link... it doesnt' really help anyone understand w/o a reading of several materials.
stuff |
Reverse engineering is particularly warrented for the purposes of interoperability, and this seems to have been the motivation of Andrew "Tridge" Tridgell. He wasn't reverse engineering BitKeeper to "steal" McVoy's ideas, he was doing it so that he could gain access to the Linux kernel without using non-free tools. McVoy's position is one that you might expect from Microsoft on Samba, but not from someone that claims to support the ideals of free software.
Bottom line? I'm with Tridge on this one, McVoy is wrong, what he wants and seems to expect is effectively patent-level protection of his ideas.
http://www.channelregister.co.uk/2005/04/06/torval ds_bitkeeper/
So whether you take the view that Bitkeeper isn't compatible with the principles of the Linux project, or vice versa, is moot. It's simply a wonder it took so long for things to come to a head.
CC.
TaijiQuan (Huang, 5 loosenings)
Linus said
Larry has a very clear moral standpoint: "You can compete with me, but you can't do so by riding on my coat-tails. Solve the problems on your own, and compete _honestly_. Don't compete by looking at my solution."
And that is what the BK license boils down to. It says: "Get off my coat-tails, you free-loader". And I can't really argue against that.
That's bollocks. Reverse-engineering is not riding on the coat-tails of anyone. It ensures that the product is 100% compatible.
If Linus truly believed that, he'd have worked to drop Tridge and keep BitKeeper. However, I'm quite disappointed in Linus implicating Tridge as the evil in this situation.
Larry has a very clear moral standpoint: "You can compete with me, but you can't do so by riding on my coat-tails. Solve the problems on your own, and compete _honestly_. Don't compete by looking at my solution."
Hmm.. and where does that end? Is it dishonest to not re-invent the wheel for your new automobile? This is a tricky area because outright copying of someone elses work without their permission is not right, but figuring out how someone else has solved a problem is kind of the way progress works.
Starsucks
He's probably either:
a) getting sued and his lawyers have advised him not to release too many details
b) worried about getting sued and his lawyers have advised him not to release too many details
Why wait until some undefined "later" point to explain one's self, if one has nothing to hide?
for legal reasons
Please lets get this straight - there is nothing immoral about reverse engineering, particularly in the interests of interoperability as seems to be the case here.
Its sad to see people put celebrity before principal, if this were Microsoft making these arguments against Samba, rather than Linus' friend making them against this Tridge guy, there would be no question as to which side most slashdotters would come down on.
The principal doesn't change just because the people in question claim to be friends of free software.
Better yet, since Larry is since against reverse engineering of his work, I hope he only uses IBM PC's, as all others stem from the original reverse engineering of the IBM BIOS.
Remember kids, it's all fun and games until someone commits wholesale galactic genocide.
Wow, I had better call my lawyer next time I decide to surf the web!
I am not a zealot, so I do not think it was a sin to temporarily use non-free software, especially when there were a lot of circumstances at the time leading to this at the time - we didn't want a Linux fork or Linus having a nervous breakdown, or so on. You have to look at things like a war - there is an objective, there is strategy and there is tactics. Bitkeeper was a necessary tactical retreat, but now that Linux is moving beyond Bitkeeper, we can see it fit in with the overall good objective and strategy behind Linux. The thing people like me worried about was the fortitude of the Linus core team as they began using Bitkeeper - is this a tactical retreat, or are they going over to the dark side? With recent events, we can see they did the right thing.
I think people should have sympathy with the situation at the time that led to Bitkeeper. It's alright for Richard Stallman to be pure and a zealot - that's his job. But it was a tactical necessity. On the other side of the coin are the little worms who whine how some developer floating around out there tried to reverse engineer Bitkeeper and offended the tender sensibilities of Bitmover and Larry McVoy, and how Linus doesn't crawl in subjugation before Bitmover and by implication other short-term corporate concerns. I don't think these people really understand even corporate America, never mind industrial or information production in general. Corporate America doesn't respect little worms that crawl around and do whatever are ordered, they just get used up until they're of no use any more and are then thrown away. And who ever said Linux was for corporate America anyway? I always thought of Linux as by engineers, for engineers. Which is not the same things as by engineers, for corporate America. That's what most of us do for our day jobs.
Why wait until some undefined "later" point to explain one's self, if one has nothing to hide?
That's a good question. We should immediately execute anybody who insists on talking to a lawyer when arrested. After all, why wait until some undefined "later" point to explain one's self, if one has nothing to hide?
Secession is the right of all sentient beings.
What exactly do you want him to say? He's never agreed to the BitKeeper license, and he's not bound by it. How could his defense possibly be any stronger?
What is this, some kind of astroturfing effort by McVoy to try to make us think that "everyone" feels like Tridge's defense is weak? What, exactly, is deficient in his statement?
Secession is the right of all sentient beings.
What happens if Tridge's client sucks?
:)
Someone looks at the source and makes it better.
What happens if it corrupts older files?
That sounds like a problem that can only occur if the server doesn't enforce proper ACLs. Older files cannot be corrupted by "updates" or "checkouts" unless there's an architectural problem with the server.
A source control system should enforce immutability of older revisions. Only administrators should have any delete powers at all to clean up, and the idea of modification of committed revisions should be right out! I expect the server to enforce this.
If word gets out that that damn BitKeeper source control system has corrupted 6 months worth of work, that's bad publicity.
And it's their own fault for that bad publicity. They should have written code that properly enforced immutability of older stuff.
Of course, if that data cannot be recovered from backups, then it's Linus's fault.
INSIGHTFUL?! I've seen some amazing moderator goofs, but this one takes the cake!
No, this is not insightful, this is called trolling. It's akin to, "have you stopped beating your wife?"
However -- to answer his question -- if you have nothing to hide, you keep you lips sealed if:
I don't think many of NewsForge's readers are going to be anti-reverse engineering. Like Sanity says, McVoy appears to want patent-level protection of his work. He doesn't have patent-level protection of his work, whether that's because he doesn't hold patents or because Tridge lives somewhere safe.
I don't think McVoy is exactly a villain here either. He just needs to quit acting like he got taken advantage of. He was doing a service and now it's not worth it to him so he's stopped. Larry McVoy, quit your bitching for your business' sake. However well founded you think it is, it only makes you sound like an asshole.
There are no trails. There are no trees out here.
What I've got from this so far is this:
1. BitKeeper is a technically good program
2. Larry McVoy is an arrogant a******.
3. I have absolutely no problem with Tridge
Sure, Larry might not like people cloning his program. Well, tough. A clone is what is needed for interoperability. Sure, the Samba team could probably have built their own networking protocol, probably even a better one, but that wasn't the point!
Or he finds the idea of getting involved in a "he said, she said" public mud flinging fest to be personally distasteful. It may be hard to believe here on Slashdot, but there really are people who feel that way.
He made the relevant points, that he did not use Bitkeeper at all in developing his tool and was never subject to the Bitkeeper license.
KFG
There's nothing wrong with Tridge writing a program that can read Bitkeeper'd files any more than there is Open Office writing programs that can read Microsoft Word files. Interoperability is good. Linus is being silly if he's blaming Tridge for anything here.
Bitkeeper traces it's roots to Sun's Teamware, which was not written by Larry McVoy, to Sun's NSE-lite which was partially written by McVoy, to Sun's NSE which McVoy had absolutely nothing to do with except being an unhappy customer, to Eric Scmidt's PhD dissertation which Larry had nothing to do with, to Apollo's DSEE which Larry had nothing to do with, to SCCS which Larry had nothing to do with. Bitkeeper is largely an amalgamation of 3 previously existing ideas, the Teamware/NSE distributed development model, changesets, and the CVS pserver. It's a little hypocritical for Larry to complain about other people riding on his coat tails when Bitkeeper is, like most successful products, a really good implementation of a bunch of ideas that were invented by a lot of other people over a lot of time.
Chris DiBona
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
I've been trying to make sense of Larry McVoy's actions here and the only sane conclusion I can come to is that he is one of the ultimate advocates of Open Source. He is willing to go as far as destroying his own company to make a point on the benefits of Open Source!
Right now, he is saying this to potential BitMover clients: "If you use BitKeeper, then I will control your development process. I am free to change how you work at just a whim." Can you imagine even ONE company that would accept terms like this? I can't.
Therefore, his actions now will have the result of destroying his company. That means that he is either incredibly stupid or has some other plan so clever that nobody (or almost nobody) sees it. I think it's the latter.
He's said many times that he is a big advocate of Open Source. Now, he is showing an object lesson on how horrible proprietary software can be. "Look at how much I can screw you over," he is telling us. "I wouldn't be able to do this if BitKeeper was Open Source."
Very clever! By sacrificing his company, he gets his point across much more strongly than mere words could ever do. Bravo McVoy!
I have also seen no reason to suggest that Tridge cannot be trusted when he claims that he didn't use BitKeeper, and since Tridge is the free software developer in this debate, I am more inclined towards sympathy with him than towards a guy that thinks reverse engineering for interoperability is immoral.
Read the article - Tridge reverse engineered BitKeeper without once using BitKeeper or it's source code. By doing this, he was not bound to the BitKeeper license.
/. hypocracy this time.
Seeing as Tridge is the main SAMBA dev, I think he has lots of experience doing reverse engineering work on closed systems with zero access to the source.
Sorry, not
Soko
"Depression is merely anger without enthusiasm." - Anonymous
While McVoy may be overstating things a bit, I get this sort of vibe from some F/OSS people, most notably RMS, who adovcated outlawing proprietary source code in the GNU Manifesto.
I run SuSE 9.2 at home, and I use Firefox and OpenOffice on Windows at work. I also provide the "freedom" angle for every tool we consider using or purchasing. We use GCC instead of commercial compilers so that we never have to renew a license or pass around a dongle. We use a libre and gratis source code management tool. Our lab machines and test stations run linux.
Even in hardware, I try to inject freedom: we are buying a Bitscope instead of a competitor's product because their gratis (but not libre, duly noted) software runs on Windows or Linux, while the slightly-more-capable competitor only runs on Windows. Additionally, the Bitscope interface is documented well enough that we will be writing one for an automated hardware validation test, something that would be much more difficult if we had to reverse-engineer the protocol.
I found myself explaining this philosophy to our FNG (f-ing new guy) recently, when he asked why we didn't buy tool X from vendor Y: "we want to control our tools, rather than have our tools control us."
Contrast this to our JTAG/ICE which used to support Motorola and IBM PowerPC chips until the company was bought a few times and wound up in the Motorola family of companies. We had to upgrade the firmware and software to support a new Mot chip, and with that we lost the support for the IBM PPC chips.
F/OSS is great, but we will not make inroads if we have an attitude like that attributed to Tridge; we cannot [openly] "look down" on those who are stuck in the land of proprietary software, or we come across as self-righteous zealots, and we all know how well that sort of attitude is taken these days.
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
Not to mention samba sharing files and printers, or email clients interoperating with exchange, or Linux having the ability to read FAT32 and NTFS partitions.
I think "Tridge" is being scapegoated because Larry McVoy is Linus' buddy, so he doesn't want to lay the blame on him.
The purpose of copyrights is to advance science and useful arts, not to reward authors.
If rewarding authors for that purpose is required, then they will be rewarded.
Copyrights on binaries however, reward authors while stifling the progress of science and useful arts.
It encourages people to create secretly-operating software that helps them get revenue but does not inspire new works, does not enter the public domain and does not help anyone else in the long run.
It is rediculous that binaries are copyrightable and the law that allows it is actually quite new (from the late 70's) and should be reverted.
I find it appauling that people actually buy it that reverse engineering here is immoral.
It seems to be everyone's knee-jerk reaction that McVoy is against all reverse-engineering in general.
But if he's okay with competition, reverse engineering is always a part of competition and he should be fine with it.
After RTFA, what I get is, if you reverse engineer BK, learn how it works, and implement something that's not plugged into BK's network, and compete with McVoy, he's fine with it. The "riding on his coat-tails" is when you reimplement his solution using BK's network, and compete with BK directly.
Before you jump into conclusion the network is open so everyone can use it, consider this: you are not just reading information from BK's network, but also changing the information, and possibly corrupting the network data. You can say it's a flaw.
So it comes to this: should reverse-engineering, on the third party's property, that could cause harm to the third party be allowed?
I'm not sure letting an implementation that potentially render the whole network useless should be protected as valid reverse-engineering.
A sig is redundant.
The problem is two-fold
1. The only way to access revision history was through the non-OSS client
2. If the non-free client is revoked, developers are left with no way to export their own revision history
Tridgedell was not writing a Free client, exactly. He was writing a migration tool.
McVoy's position is equivelant to espousing vendor lock-in as a legitimate strategy, and if Tridgedell's description of his actions is effectively accurate, McVoy is just using this as an excuse.
McVoy should take his license if he wants, and then encourage Tridgedell to finish his export client so developers w/o a commercial license don't lose their revision histories.
In fact, it is clearly stated that he is uncomfortable with the situation simply because it is costing more money to support a free BK than the extra revenue such support is apparenty encouraging.
--
God! I sound like a NYT article, i mean editorial!
There is something really wrong with a tool if some user tweaking a ChangeSet file causes damage that costs $35000 and needs a custom release to fix!
Just because it CAN be done, doesn't mean it should!
Since people keep saying the same things, I'll keep responding with the same too:
It's a bit silly to say 'I told you so" - especially since I didn't actually say it. I thought the arguments made by Linus had some logic behind it too (the technical-merit-before-anything-else approach). Often I thought both sides (Stallman and Linus) had some valuable viewpoint on it, and it was difficult to say who actually was right on the matter.
It seems now, after all, it was R.Stallman all along. Yes, Linus has a good point in chosing for technical superior alternatives...BUT, in the end, as is clearly shown now, you can't just devide the political/ideological/proprietary issue from the mere technical one. When push comes to shove, an alternative that isn't really free, isn't really an alternative. You are always dependend on the goodwill of whomever owns the product- even when buying it, I may add.
So, it would seem the viewpoint of Linus, in this instance, is the weaker one, because now he doesn't have a 'tecnological superior' product anymore, and what is he going to do? Go for another proprietary product, because it's technologically better? And have the same thing happen to him again? I don't think so. I think he learned his lesson, and he will go for the really free alternatives that R.Stallman suggested, which, albeit not as good, at least allow you to continue with it as you see fit.
Stallman can be a nag sometimes because of his gnu/linux diatribe, but in this instance, he was right.
--- "To pee or not to pee, that is the question." ---
Case 1: CherryOS violates the license to some open source software by taking it, adding some slight functionality, and renaming it, claiming it's 100% original code.
Case 2: Tridge reverse-engineers the bitkeeper protocol / binary format, intending to release an open-source version.
Case 1: Violates source code license, used to do something illegal, taking open software and making it closed.
Case 2: Adheres to all laws and licenses, takes something closed and makes it open.
Tridge didn't use proprietary code, and he wasn't reverse engineering an open-source project. (What open-source project did you think he was reverse-engineering? Linux? Why would you need to reverse-engineer an open source project anyhow, rather than reading the source and chatting with the original developers?)
Let's look at reverse engineering for a minute. First of all, even the DMCA has a clause that protects reverse engineering for the purposes of interoperability. That's right, one of the most draconian media laws we've ever seen protects the right to figure out what something does so that you can interface to it. This is precisely what Tridge was attempting to do.
For the user, Free Software is about not being locked into a proprietary solution. BK is apparently the antithesis of this - they would very much like to lock you into BK. This is made abundantly clear when McVoy says "If we sat back and did nothing about Tridge then we are implicitly condoning reverse engineering."
For me, that tells me everything I need to know about bitmover. Reverse engineering is a necessary and even protected activity. If you want to lock people into your solution, you just don't get it.
What McVoy is saying, and what you are apparently agreeing with, is that it's reasonable that BK should be such a house of cards that it is possible to knock it over in such a way that you can't put it back again. McVoy tells us how unreliable and unmaintainable BitKeeper is in the following bit:
Why on earth is there no way to fix them by hand? Why, in fact, can I not just turn back the clock to a point where the system was not corrupted? Are they really passing information around without sanity checking? I'm sure a lot of people are saying "I can tell this asshole isn't a programmer" as they read this, but does something like this really give you a warm fuzzy feeling, knowing that if your BK DB is somehow corrupted, you're going to need a custom release of the BK software?
Was going to provide? If bitmover had seen interoperability as a goal from the beginning (the very least I will accept out of proprietary software that is part of a core business process) then it would have been provided already, Tridge would never have had reason to write tools that interfaced to BitKeeper via its internal protocols (Assuming that is what is happening, which all of this strongly implies - I don't know just what was written obviously) and this whole thing never would have happened. Instead, what happened here is that bitmover decided that they didn't want what they saw as competition, and wants to be able to lock their customers into their product, preventing them from retrieving the entirety of the data - data which belongs to them.
Tridge's efforts were entirely prudent. Functionality was needed and was not present, and he sought to add it. Bitmover was apparently not very interested in providing it; otherwise why write anything? Tridge's efforts may not have been helpful - I'll wait to see some code (or not) before I pass judgement there. However, I am inclined to say that they were helpful, in that I do not believe that the Linux development process should involve proprietary tools when there are free tools that will do the job. If Linux needs functionality not currently present in Free software, IMO the proper course to follow
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
That's bollocks. Reverse-engineering is not riding on the coat-tails of anyone. It ensures that the product is 100% compatible.
It's not just bollocks, it's rank hypocrisy coming from Linus Torvalds, who would be a completely unknown, minor software developer in Finland if he hadn't ridden -- dry-humped, actually -- on the coattails of Unix. The same goes for his last employer, whose business is built on a reverse-engineering of x86 microcode.
Ordinarily, I'm quite fond of Linus, but in this case, he's being a ridiculous ass.
The whole idea behind free software, IMHO, is that by encouraging reverse-engineering, among other forms of transparency, it ensures that software development is accelerated because you can't rest on your laurels. Your good ideas become the community's (and your competitors') good ideas, and you have to keep coming up with new good ideas to stay ahead.
This is the reverse of the closed source world where having had good ideas once entitles you to maintain a monopoly to the detriment of the consumer.
Proud member of the Weirdo-American community.
Basically you would like to know all about his motivations. Who the f*ck cares? The entire problem is a hissy fit about somebody reverse-engineering a protocol and Tridge isn't the hissy.
But to answer for him anyway:
Why did he do it? Because he wanted to.
Is OSDL paying for it? Ask OSDL.
Why he kept going when OSDL promised he'd stop? He's not OSDL.
Was it worth it? Ask McVoy.
Why was reverse-engineering the only way? Because of the BitKeeper license.
Will he keep going with the project? If Linux falls back to BitKeeper.
Seriously this is just pissed-off.com 101. Reverse-engineering a protocol is not wrong, immoral or impolite. It does not require justification. Purposely keeping a protocol closed however, does.
Linus says it himself:
"...we did get three very productive years out of it, and we not only learnt how SCMs can work, we also taught a lot of people what to expect of a _good_ SCM, so anybody who claims that it was a waste of time to go with BK obviously doesn't have his head screwed on right. BK did good."
There seems to be the idea that now that they've got to move off BitKeeper that it's the end of the world. It isn't. What if they hadn't used BitKeeper - kernel development would not have progressed at nearly the rate that it has and they'd still be in the same position they are in now, but with less work done on the kernel. They'd still have had to work out some alternative SCM, they might just have had to do it sooner.
I really don't see what the big deal is. Linus hasn't lost anything by using BitKeeper - you say that he was "dependent on the goodwill of [BitMover]", but dependent for what? we still have the Linux source - the only thing he was dependent on them for was the productivity that no open source product was capable of offering. So all he's done is gain, and lost nothing.
The sky hasn't fallen.
You presume that Linus is correct in saying that BK is the best SCM. It was the best for the way he wanted to work, but that's no surprise since lm wrote it that way. Why did he do that and yet not make it open source? Because he wanted to make money off Linus's use of BK. Yes, he's coat-tail riding.
-russ
Don't piss off The Angry Economist
If MS were to add this sort of clause to the EULA would it mean I can't reverse engineer the MS-Word .doc format because the receptionist at my day job uses Word?
According to the article Andrew Tridgell may have worked for ODSL, but he didn't use BK. I'm not sure how you can be bound by the licence of software you're not using.
Cogito, ergo sig.
Opportunity knocks. Karma hunts you down.