Back on February 23 I learned from Linus that Tridge was reverse-engineering BK so that he could pull stuff out of BK trees without agreeing to the BK license. As you might expect, we were less than thrilled and began having talks with Linus, Tridge, and Stuart Cohen, the CEO of OSDL. These talks didn't go anywhere. Tridge believes strongly enough in free software that he thinks anyone using non-free software is living in sin.Torvalds' take on the situationLinus worked very hard to get Tridge to stop. He and I spent a significant amount of time on this issue and Linus understands my position very well He summarized it nicely:
Larry is perfectly fine with somebody writing a free replacement. He's told me so, and I believe him, because I actually do believe that he has a strong moral back-bone.What Larry is _not_ fine with, is somebody writing a free replacement by just reverse-engineering what _he_ did.
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.
This position seemed to be lost on Tridge.
Concurrently we were working with OSDL's management. In this area I pulled in calmer heads than mine and our VP of sales got involved. He negotiates all of our enterprise level agreements, (his strength is finding common ground) so you can imagine he's a pretty reasonable guy. He was unsuccessful in getting anywhere with OSDL's CEO. Stuart's position was that this was not their problem and this is the sort of activity you expect in the open source world. We did get a verbal promise from OSDL that Tridge had discontinued his work and would not begin again as long as we were trying to work things out. We believed we had an uneasy truce, but it ends up Tridge was still working.
We ended up in a no-win situation. OSDL didn't appear to care and we couldn't trust what we were being told. With that we were fairly confident that Tridge was going to release his code. That was a problem for us for two reasons:
a) Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it.
If Tridge's tool is out there we are now supporting our code and his code. We couldn't do that.
b) IP loss. If we sat back and did nothing about Tridge then we are implicitly condoning reverse engineering.
Internally, we were looking at ways to best handle this. One option was to have two versions of BK, one that we gave away and another that was commercial only. This had been our course for some time and it wasn't working out. The difficulty with that solution is we couldn't just stop all work on the free version because of future compatibility issues. Trying to maintain compatibility between a free product and commercial version was grinding our development to a halt. Everyone was losing. In order for this to work we had to continuing throwing resources at the problem. We're already up to about $500K/year for the free version and continuing to ratchet that up wouldn't be prudent.
At that point we started looking at what it would be like to discontinue the free BK. Linus strongly encouraged us to do this once he came to the conclusion that the costs of the free version to BitMover outweighed the benefits to BitMover.
OSDL's management was kept informed of what we were thinking and again they seemed rather apathetic about it. Their position was that it was BitMover's problem and we needed to figure out how to fix it. That is until we set the wheels in motion to discontinue the free product. They did make motions very recently that we should work together on this, but it was too little too late.
We finalized our discussions with Linus last weekend and he began the process of migrating off of BK. Linus is a very ethical guy. His feeling was that we were getting a bad deal and he didn't want to be part of that. So off he went. We spent the next couple of days scrambling to figure out how we were going to handle this, announcements, migrations, programs moving forward, etc. We're still working on the details moving forward with some of these issues, but our hope is to make this as smooth as could be expected for this sort of transition.
After reading McVoy's response (he cc:ed Torvalds on the email he sent to us so that he would not misquote or take out of context anything he quoted from their correspondence), we asked Torvalds three questions.
NewsForge: What will you use to replace BitKeeper?
Torvalds: I don't even know yet. I'm playing around with my own scripts and tools right now, and talking to various open-source source code management (SCM) people. In fact, I'm trying to get as many people as are interested in the problem to just explore the options.
NewsForge: How will this impact your workload short or long term?
Torvalds: Short-term we'll merge patches. Right now the -mm tree should work like usual, so people can go on developing. On the other hand, especially people that used BK will just slow down, take a breather, and look around at the alternatives.
And some people will just continue to use BK. It didn't go away, and it's still the best SCM out there, it just got harder to merge with me (and some of the people I work with). So you export BK changes by patches instead, but some people largely worked like that _anyway_ before (i.e. they used BK for its merge capabilities).
So we'll definitely have a slowdown in the short run, but it's not likely to be a huge deal. The biggest worry is developer frustration about the uncertainty, so I'm certainly trying to get to a decision, but on the other hand I don't want to hurry it _too_ much either.
(Ironically, many users and distributions are likely to actually not mind slightly slower development for a while. One of the most common worries for users is just the fact that 2.6.x has continued to be developed at a very high rate thanks to just how smoothly it's been working, so I bet some people are both upset and gratified by this all. ;)
In the long run, we'll just have to see. I think in the _medium_ run the problem is going to be just having to live with less capable tools, and having to possibly teach old developers (me included) new tricks.
And I don't mean the various syntactic differences between different SCMs, I mean new ways of working and adapting to new constraints (and likely new freedoms too -- BK had its own set of constraints simply due to the model of development that _it_ imposed -- every SCM tool to some degree has a "world view," and it takes time to get comfortable with that world view...
NewsForge: Was this split inevitable, or could it have been avoided?
Torvalds: I think everybody saw the split as inevitable _eventually_. I don't think anybody believes that the open-source SCMs wouldn't grow up, and when they would, there would have been obvious reasons to switch over eventually.
But I think it could have been a lot less painful if it happened a year or two down the road, and that's my only real regret. That said, 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.
Tridge offers his side
There is no doubt Tridge is being cast as the villain in this piece. Here's what he had to tell us when we asked him for his side of the tale:
I expect that in the future I will be able to give a more detailed response, but for now I can only tell you the following:- In late February I wrote a tool that is interoperable with BitKeeper. The aim was to provide export to other source code management tools and provide a useful tool to the community.
- I did not use BitKeeper at all in writing this tool and thus was never subject to the BitKeeper license. I developed the tool in a completely ethical and legal manner.
At the end
In spite of the end of the relationship, McVoy and Torvalds seem to have lost no respect for each other's integrity or professionalism. Torvalds still admires BitKeeper, and still feels it to be the best tool for the job. Whether this outcome was inevitable or not, it's a little bit sad to see this marriage of proprietary and free software come to an unhappy end. Not to mention a little unsettling, due to the uncertain handling of patches in the future.
Note: Comments are owned by the poster. We are not responsible for their content.
"... that reverse engineering is evil, and is stealing. And Linus agrees."
Ok<nobr> <wbr></nobr>... let's start then, with the Q-Cam driver, from there to the various printers, scanners, IDE, WinModems<nobr> <wbr></nobr>....
What Larry needs to admit is that he really wished he'd patented his code, because that is what he's asking here, he's asking someone to respect his exclusive right to his invention or anything similar enough to his invention so as to circumvent his license. That's what a patent does<nobr> <wbr></nobr>... only Larry isn't man enough to say so. Instead he wines foul play, and Linus isn't man enough to say "tough titties, Larry, you should have patented it if you feel this way".
Tridge says he didn't have the code, so he didn't pilfer anything, he just worked backwards from the solution, the exact same way most of the Linux kernel device drivers were distilled from those hardware vendors unwilling to share specs. If Larry thinks Tridge stole the code, that's different, that's plagerism and that's being crooked if Tridge holds it out as his own, and Linus, in light of the lessons learned from SCO, should understand what all that means.
btw, whatever happened to SCO?
Anyway, back on topic: Larry won't use the P-word because he knows the free-software/opensource people will bolt for the door. Linus won't use the P-word because he and Larry are reasonably close friends. And Tridge won't say anything because he's (a) not a famous media-darling geek and (b) he's being bravely "unamerican" the way all the very best and most famous Americans have always been.
Now, if he had been writing a tool to import code into BK, or if he had been disassembling the actual BK binaries, then perhaps he should have had his shorts run up a flagpole, but at this point, I don't see where the problem is.
Reverse Engineering in this case will involve the two systems talking to each other, so Tridge must have used BK in some form in order to at least debug his code.
**Or is McVoy really claiming that Free BitKeeper changesets are the intellectual property of BitMover?
To change the topic slightly: McVoy ought to look into a legal concept called "slander of title". It occurs when you deliberately harm the value of a property by making false statements about its title, such as driving people away from a copyrighted work with a false claim that its authorship is derived. Also, the fact that McVoy intentionally threatened Tridge's employment with this claim might constitute extortion. If I were BitMover, right now I'd be on my knees praying that Tridge doesn't have the money and indignation for a RICO lawsuit.
<TT>> So I wrote some very preliminary scripts (on top of BK itself) to extract
> the data, to show that BK could generate a SCM-neutral file format (a very
> stupid one and horribly useless for anything but interoperability, but
> still...). I was hoping that that would convince Tridge that trying to
> muck around with the internal BK file format was not worth it, and avert
> the BK trainwreck.
> Larry was ok with the idea to make my export format actually be natively
> supported by BK (ie the same way you have "bk export -tpatch"), but Tridge
> wanted to instead get at the native data and be difficult about it.</TT>
so I'm going to guess that Tridge was working with a native BK repository. Not analyzing the wire protocol, but the native on-disk format. Such analysis would probably lead to a pretty good idea of the important BK data structures, which is a good lead into the algorithms.
1. Tridge says he didn't use BK at all in the development of his software. If that is true, then McVoy and BitMover are being unfair (with the caveat that the free use of BK was a gift in the first place, and that no can complain if the gift is withdrawn for any reason, even a whim).
BK is a 10 man company and they work hard to develop products for Linux.
I can take open source software and have code jockeys in India modify it for me and the original developer loses out on any possible chance that I may come back to him for Widget frosting.
They suck big time!
Sure that's objective statement. But it does bring up the point that while I'm sure Bitkeeper is good, and seems to have been customized to suit Linus, it certainly is not the only source control game in town by any means, it's actually a pretty competitive field.
People told Linus a long time ago that going with proprietary software for something as important as source control was a bad idea. He is not infallible, you know. I believe he got this decision wrong.
Slightly more surprising is the range of reactions to the news. Some people seem to think that Tridge did something wrong. Perhaps they will stop using OpenOffice and go back to using MS Office? (OO.o reverse-engineered<nobr> <wbr></nobr>.doc and<nobr> <wbr></nobr>.xls files). Or stop using cheap printers, which work under Linux solely because somebody deciphered their data protocols without permission? In view of their limited capacity for logical thought, I think that trying to explain to them the difference between reverse engineering and what Tridge did is a waste of time.
You are kidding, right?
Yes they were, in fact they were more than enough. IBM published the entire source code of the BIOS in the manual for the original IBM PC.
IIRC, the reverse-engineering accomplished by Phoenix involved 2 teams, who were not allowed to talk to each other. Team 1 read the BIOS code, and wrote a specification of what it did, in purely functional terms - i.e. what a BIOS had to do, to be compatible, including key addresses like 40h. Team 2 took the spec, and wrote a BIOS. The result was a BIOS that did not violate IBM's copyright, yet was fully compatible.
I think Linus is handling it in the best possible manner given the unfortunate circumstances.
I wonder why everybody talks about Linus as if the guy was some sort of "open-source-god". Linus is just an apolitical free-software developer.
Please, Joe: stop trying to hide the political issues behind free-software by using this "apolitical open-source image" of Linus.
Bottom line in this situation is this; Linux can no longer use BK (it doesn't matter why). Time to move on. Is Tridge right or wrong? Is McVoy right or wrong? Who gives a fsck! I can tell you this, though. It's a damn good thing that Linus is the person he is. If he were more like any of the GPL zealots or RMS'like then Linux would have died at birth. If Andy Tanenbaum had been RMS then Linux would have never even been conceived.
This is all immaterial now, though. It's done so we need to move on. To spend time and energy flaming all over the place is counterproductive and will only hurt Linux and open source. Get over it and get back to work.
The message I'm getting is
Posted by: Anonymous Coward on April 11, 2005 08:56 PMInteresting.
#