BitKeeper Love Triangle: McVoy, Linus and Tridge 850
erktrek writes "NewsForge has given a brief interview to the parties involved in the (inevitable?) BitKeeper debacle." Here is some of our previous coverage.
Factorials were someone's attempt to make math LOOK exciting.
Uh, a summary? (Score:3, Insightful)
My opinion hasn't changed (Score:5, Insightful)
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.
Paraphrase ... (Score:4, Insightful)
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.
What the... (Score:3, Insightful)
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.
Riding of Coat-tails. (Score:5, Insightful)
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.
Re:weak answer from Tridge (Score:5, Insightful)
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
Re:weak answer from Tridge (Score:5, Insightful)
for legal reasons
Re:weak answer from Tridge (Score:5, Insightful)
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.
Re:My opinion hasn't changed (Score:5, Insightful)
Re:Riding of Coat-tails. (Score:1, Insightful)
But they figured it out in the first place, and they deserve some credit for that. That's the way the patent system works.
Re:My opinion hasn't changed (Score:1, Insightful)
Tridge is wrong on this one...
If you're using the BitKeeper server, you should be agreeing to their terms of use. I think the author of bitkeeper was a bit miffed that he was completly bypassing the terms of usabe by writing his own client. You're very specifically using their client which is designed to work with their server.
In this case, they're 100% right. What happens if Tridge's client sucks? What happens if it corrupts older files? The Linux kernel, in case you hadn't heard, is a bit of a high profile project. If word gets out that that damn BitKeeper source control system has corrupted 6 months worth of work, that's bad publicity. And who would know if it was really the official client or Tridge's client?
Bottom line, Tridge's a bit of a dick for not playing nice. Let people protect their reputations, and don't screw with their abilities to feed their family.
Re:Interesting (Score:5, Insightful)
Re:When Is Reverse Engineering Wrong? (Score:5, Insightful)
Re:My opinion hasn't changed (Score:5, Insightful)
I say McVoy was trying to tie his proprietary product to the linux kernel development. Can't fault him, really, he's acting as a suit. The geeks that let him do that: shame. The ones that called his shenanigans: kudos.
It doesn't matter if it's the best tool for the job. What matters is that the tool is not entirely within your control. It's like the chinese buying aircrafts from the americans, and the americans building a remote shutoff switch in the target aquisition radar. (bad analogy, I know... Sowwy.)
What? (Score:5, Insightful)
Wow, I had better call my lawyer next time I decide to surf the web!
Good for its time, now it's time to move on (Score:5, Insightful)
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.
Bottom Line (Score:3, Insightful)
Copyrights are not a "reasonable" position anymore (and please don't go off about how the GPL is a copyright license without reading it first either) Because the "right" to micro-controll and manipulate how every last person uses information in the information age is no longer, workable tenable, or acceptable any more.
Re:weak answer from Tridge (Score:5, Insightful)
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?
No Reverse-Engineering Allowed (Score:1, Insightful)
Re:I really think Tridge needs..... (Score:5, Insightful)
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?
Server Should Enforce Immutability (Score:4, Insightful)
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.
Re:weak answer from Tridge (Score:4, Insightful)
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:
Really? (Score:5, Insightful)
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.
Definitely disagree with McVoy (Score:3, Insightful)
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!
I get the impression... (Score:3, Insightful)
The BK guy claims that he would be ok with a OSS clone, so long as it was not reverse enginerred from BK. Who knows? We may never really know now.
Linus, who is in a position to know (and I consider trustworthy), doesn't seem convinced that Tridge wasn't just trying to torpedo BK from the get-go. (based on his statements here and in the eariler article)Re:My opinion hasn't changed (Score:5, Insightful)
He hasn't even clicked through one. He wasn't useing the BK client, and was thus compleatly unbound by what BitMover thought and in the right to do what he was doing.
The day he installs the BK client and clicks through it's liscence, you'll be 101% right, until then I'm with tridge on this one.
Re:Bottom Line (Score:3, Insightful)
If you don't like the license ... don't use it.
That's such bullshit. First off, the guy who was reverse engineering wasn't party to the license. And second off, that logic is like the saying "if you don't like slavery - don't own slaves".
PS: I'm not liberal, I'm more like libertarian, and copyrights are not a property right - they are a bullshit regulation on how people use information.
Freedom to have you post duped? (Score:3, Insightful)
Nice catch.
Especially ironic given the title of the post, and the copyright issues the gpl uses as its core.
Re:weak answer from Tridge (Score:5, Insightful)
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
Re:You git! (Score:5, Insightful)
Re:Freedom Matters (Score:1, Insightful)
And in many situations, that is true. And in most situations, it's not important.
The different between FOSS and proprietary is this: for the former, I don't have to switch. For the latter, I do.
If Commodore Amiga's operating system had been Free Software, the chances are I'd still be using it today. It would, by now, have a community of developers built around it who would have kept it up to date, ported it to commodity hardware, etc.
So, to be honest, this kind of argument doesn't impress me. Why, exactly, do I need to switch from sendmail? I don't. I can't envisage needing to any time in the next decade, can you?
Why did I need to switch from AmigaOS? 'cos it was set in stone. There'd never likely be an update, and even if there was one, I'd be unlikely to obtain it, and it's unlikely it'd ever move forward very far.
Re:My opinion hasn't changed (Score:2, Insightful)
Software patents are tricky because they are so easy to work around to get a similar effect. They can't GPL it, because they put too much effort into their code for their competitors to get it all for free. In short, trade secrets are all the software industry has for protecting ideas in these cases.
The best compromise, IMO, is to use open standards for the repository, with an explicit clause in their license that any time the repository is broken by another program, BitKeeper is not liable to provide any help.
Re:What the... (Score:3, Insightful)
Confused (Score:2, Insightful)
PearPC accuses CherryOS of stealing its open source code and using it in their proprietary project. There is some proof of this.
Bitkeeper accuses Tridge of using their propriety code to reverse-engineer an open-source project. To best of my knowledge, only circumstantial evidence as yet supports this.
So when open source take advantage of closed source, it's a Good Thing (tm), but when closed sources takes advantage of open source, it's a Bad Thing (tm). Did I get that right?
Re:My opinion hasn't changed (Score:5, Insightful)
Reverse-engineering is perfectly legal (when done correctly) and is employed by proprietary folks regularly. How do you think the PC-clone market got started?
Bitkeeper is hardly 100% original (Score:5, Insightful)
Re:Confused (Score:2, Insightful)
Re:I really think Tridge needs..... (Score:1, Insightful)
If he's never agreed, he hasn't been allowed to use it.
Reverse engineering (Score:2, Insightful)
Re:weak answer from Tridge (Score:5, Insightful)
Chris DiBona
Re:I really think Tridge needs..... (Score:3, Insightful)
The fact that it doesn't explain his apparently antisocial behavior. Both Linus and BK dude sound as though they were working together and attempting to find an equitable solution, including a natively supported SCM-independent export format. Tridge sounds like he was given an opportunity to negotiate and come up with a solution everyone could be happy with, and he sent them all a fuck you instead.
Of course, I don't know if that's the case, because he didn't bother to defend himself. See?
I have every right to insult yo momma right now. If I did, though, it would be completely reasonable to expect me to explain why -- and saying that there's no law saying I can't isn't exactly a great explanation.
McVoy: Ultimate Open Source Advocate? (Score:5, Insightful)
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!
Re:Zealotry? (Score:5, Insightful)
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.
Re:My opinion hasn't changed (Score:4, Insightful)
IMO, it seems a little hypocritical that he's starting the name-calling only after the reverse-engineering isn't benefitting himself.
Re:My opinion hasn't changed (Score:3, Insightful)
I'm not going to make a judgement as to whether or not the approach was sound because I still don't see how someone is supposed to make money off software that's supposed to be given away. He squeezed the kernel PR as much as he was able to, so good for him. Torvalds got a good tool that enabled him to manage development for a while. It was a win-win situation, at least for a while.
Unfortunately the zealots will point to this and gargle the "U S33!!1!! THE SOFTWAREZ iT W^S NOT TEH FREE!!!!1!! HAHAHAH!!!!" and send McVoy and his company down the same creek as SCO, Microsoft and anyone else they think is evil.
I think McVoy's approach was flawed, but I don't think he was trying to screw anyone. It was a good experiment on what does not work with open source though.
Re:Confused (Score:5, Insightful)
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
Balancing freedom and zealotry (Score:5, Insightful)
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 [bitscope.com] 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
Re:You git! (Score:5, Insightful)
I think "Tridge" is being scapegoated because Larry McVoy is Linus' buddy, so he doesn't want to lay the blame on him.
Re:What? (Score:5, Insightful)
Given his success at SAMBA, it's a reasonable bet that
he can do it
he's ethical
The obvious question is, how much better will we all be when a good merging application is as free as the fundamental theorem of calculus?
Re:weak answer from Tridge (Score:2, Insightful)
I hope not.. Or we wouldn't have any frigging drivers!
Re:Zealotry? (Score:3, Insightful)
There is nothing unmoral, unethical, or unfriendly about reverse engineering. Otherwise have fun buying only PC's from IBM and cars from Ford (or whoever [about.com]) for the rest of your life, since anything else would be against your sense of 'ethics'.
Re:When Is Reverse Engineering Wrong? (Score:1, Insightful)
Please, do tell which _law_ Tridge isn't abiding the spirit of?
Is it the "thou-shall-not-reverse-engineer-Larry McVoy's-baby" law for your stupid pseudo religion? Cuz, from where I sit, you are pulling _laws_ out of your ass...
Copyrights on binaries (Score:4, Insightful)
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.
Re:Good for its time, now it's time to move on (Score:5, Insightful)
And let us not forget that one of Richard Stallman's most important efforts, porting of gcc to the x86, was not done in a vacume. It required a commercial version of UNIX for the x86, and the commercial version of ATT's C compiler and Assembler. All quite legally done, too.
RMS and the rest of the world moved on from that as well, and the results are the Linux world we have today.
Should all reverse-engineering be allowed? (Score:5, Insightful)
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.
Re:When Is Reverse Engineering Wrong? (Score:3, Insightful)
it's nearly stealing OSS code (Score:3, Insightful)
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!
Re:weak answer from Tridge (Score:1, Insightful)
I don't think anyone other than you has claimed that OSDL paid him to 'copy' Bit Mover's work. Every other account has them paying him for a completely unrelated matter.
Re:What? (Score:1, Insightful)
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.
Free/Open software is good, but dont shove its moral superiority on the face of people who are not convinced of it. People have a right to make their choices as regards open or proprietary source code. And when you deal with them respect their views on the issue even if yours are radically different. And if you dont want to play by the rules, do not deal with them at all.
The problem with McVoys stand is that he should be dealing with this on a personal level with Tridge rather than making it a blanket move on the whole of the open source community and on the OSDL.
Re:BitKeeper sees two problems (Score:5, Insightful)
Re:What? (Score:5, Insightful)
Re:Really? (Score:3, Insightful)
Hardly. I think the wrong here isn't the reverse engineering, even if that's what got McVoy's panties in a twist.
I think the wrong is accepting BitKeeper's generosity and then continuing to do things that attack the revenue model that keeps BitKeeper in business. The right thing to do would have been to let BitKeeper know that Linus, et al, were thankful for BitKeeper's help, but they switching over to a new, GPLed system. Then if BitKeeper were pricks about the switch, sure, reverse-engineering would have been fine.
This is pretty basic don't-bite-the-hand-that-feeds-you stuff, and I'm sad that it came to this. It doesn't look like the open-source community gained much, and aside from losing kernel productivity, we also have planted a big warning flag to any business that might want to give free licences to open-source projects.
and thus, R.Stallman was right all along... (Score:4, Insightful)
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.
You sure are confused (Score:5, Insightful)
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?)
Zealot? (Score:2, Insightful)
So it's about control (Score:3, Insightful)
In other words: this, like most of the disagreements over DRM, trademarks, domain-squatting, copyright, and even software licensing, isn't really about freedom. It's not really about cost, or about 'stealing' someone's work. It's about control.
If Larry's client is the only one that can connect to the BK servers, then he has full control over the system as a whole. If other clients can connect as well, then he loses that control.
Now, whether you think that control is a Good Thing(tm) or not is another matter. I haven't been following the story, and I don't know the details, so I have no firm opinion.
Try looking at it from Larry's point of view. AIUI, at present, if there's a problem with BK, then he's responsible. It's down to him to fix software, get new clients out there, fix corruption in the DBs, &c &c. And where that's down to mistakes in his own code, then that seems fair enough -- especially when people have paid him money for the privilege.
But if other clients can connect, then that opens up whole areas of problems for which he could not be responsible. How could it be fair to expect him to invest time and money in sorting out problems caused by third-party code? Especially when he'd be incapable of fixing said code, or even from preventing it being used?
OTOH, I can also see the users' point of view, where huge amounts of data, time and effort are invested in a system with no guaranteed future, no way to fix mistakes or make improvements themselves. That's not a good long-term investment. But was this a good response to the situation?
Maybe the Right Thing to do would be to ignore the BK protocols (regardless of whether it's okay to reverse-engineer them, or to connect to a such a closed system). The moral high ground would be to ensure some way of getting all the information out of BK DBs (which I gather McVoy was going to provide), and then write a free tool, servers and clients, to do the same job -- with its own, separate protocols. But it looks like it's too late for that now...
My own ill-informed opinion, FWIW, is that while Tridge's efforts were probably legal (and rightly so), they weren't helpful or prudent.
Re:My opinion hasn't changed (Score:4, Insightful)
I'm not familiar with BitKeeper, but I use to do pre/post sales technical work on one of the big (at the time) SCM tools, and I see nothing in Bitkeepers description that looks terribly original.
That is not to criticise it, the real value in SCM tools is doing their job well, being well integrated into the programmer work environment, and keeping out of the way except where they add value, not being innovative computer science.
It is possible Bitkeeper have devised mysterious complex mathematical enhancements on the theory of changesets - but I doubt it, and even if they have I doubt that is what adds much of the value perceived in BK.
Indeed many "old time" developers use to complain bitterly when we were selling SCM that the modern tools often lacked integration features the older tools had.
Although this was largely market driven, trying to appeal to as big a market as possible, where as many of the earlier tools targetted a much smaller toolset (Cobol on IBM Mainframes for example), not least because there were less tools around then, and interoperability and portability were more talked about than actually implemented before the late 1980's.
Re:Really? (Score:1, Insightful)
Tridge knew this would happen..... (Score:2, Insightful)
Re:My opinion hasn't changed (Score:5, Insightful)
I'm not sure you know what reverse engineering means. Linux does not need to, and never needed to, reverse engineer Unix or any operating system. Linux is an independent implementation of freely published POSIX specs. The way it works internally is entirely a new invention. Similarly, many Linux programs are designed to emulate the same core functionality as other programs (some of them non-free), but can do so without reverse engineering because the protocols and file formats are freely available, and the implementation can simply be reinvented from scratch.
There are only three areas where reverse engineering happens in Linux development: writing tools (like OpenOffice) that open proprietary file formats, writing emulators like Wine that implement the Windows API, and writing device drivers for devices that don't have full specs. However, I don't think that those account for the majority of the focus of Linux, and it's certainly not hard to make use of Linux without ever running across any of these three areas. (For example, there are lots of device drivers that did not make require any reverse engineering.)
Reverse engineering has a very particular meaning. Writing something similar to something else is not reverse engineering.
Re:My opinion hasn't changed (Score:3, Insightful)
Re:The OSS Religion Clashes With Reality (Score:3, Insightful)
In a word, "Yes". Just don't copy the source code, or people might get a bit irritated.
Re:Riding of Coat-tails. (Score:3, Insightful)
Everything we do is based on things we learned from others. If you didn't ride the coat tails of those who invented calculus and higher math, or those who invented the wheel (as is often stated), where would you be today?
It is perhaps dishonest to take someone else's product, make your own identical version and then sell it as your own idea, but that's not what's happening either. AFAICT, major car manufacturers do it all the time -- "hey, people like a longer wheel base from company x, lets make a longer wheel base car for our own customers".
Larry has my sympathies when it comes to trying to make a living off being smart at algorithms vs. having made a physical product to sell, but by virtue of how ideas allow societies to evolve, they must remain basically available for all to use.
Re:reverse engineering wasn't called "evil" (Score:1, Insightful)
How is reverse engineering BK right when the company he worked for said it wouldn't in a legal agreement?
In many countries, reverse-engineering is a statutory right that cannot be signed away. In these countries, that clause would have no standing.
I find it amusing that people are calling reverse-engineering immoral and unethical when many countries have deemed it even more important than the right to free speech (which you can easily sign away with NDAs).
Re:So it's about control (Score:5, Insightful)
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
Re:Should all reverse-engineering be allowed? (Score:3, Insightful)
Decent FOSS source-control system (Score:3, Insightful)
Yeah, I know things like CVS and Subversion exist, and in particular CVS is often cited as being a "mature" and "capable" version control system. But in my experience they're awfully difficult and complicated to set up and maintain, particularly CVS. Setting up and maintaining a source control system shouldn't be a full-time job in addition to the code you're actually trying to develop. It should be amazingly simple to set up and use, with almost zero learning curve and very little distraction from actually working on your software.
For instance, I know several people on various SourceForge projects who basically gave up trying to work with SourceForge CVS because it's so damn complicated to get set up and working. Even when CVS hosting is offered for FREE people choose not to use it because it's such a pain in the ass. That right there should tell you something.
Re:so when is something reverse engineered... (Score:3, Insightful)
This is NOT reverse engineering, because you disassembled the original product into source, and looked at said source, you are no longer "clean".
Reverse engineering implies that you only use a binary implementation of a product and build a product that works like it, based solely on inputs and outputs from the binary product.
Re:My opinion hasn't changed (Score:3, Insightful)
An old version, by definition, is an old version. Clients shouldn't (and probably aren't) able to say "delete this file on the server". They should not, without proper access, be allowed to delete a revision either, but if they do, you should be able to get it from backups.
If the internal database can be corrupted by something the server does to itself, there is something fundamentally wrong with the system. We call it a bug. McVoy is blaming Tridge for exposing weaknesses (again, bugs, places where the program is written incorrectly and does not do what it is supposed to do, what the programmer meant it to do, what was specified for it to do, or anything else that was intended) in bitkeeper. Guess what? Reliability through obscurity is about as sane as security through obscurity. People WILL use the system in ways you did not intend. If the system breaks when they do that, then you were thinking completely wrongheadedly when you designed it, or maybe you just made a boo-boo. Either way, it's your fault, not the other guy's.
Re:What? (Score:4, Insightful)
I find it difficult to believe that you know more about clean-room development of software compatible with proprietary software than does tridge at Samba.org. :-)
Re:Definitely disagree with McVoy (Score:3, Insightful)
Ah, yes, the "well, there are clients available for X platform, so why do you need to reverse engineer it?" argument.
Here's a hint: you don't need a reason to reverse engineer something. None. It's been explicitly protected many times in court proceedings. It's explicitly protected in copyright code when it comes to semiconductor chip design.
Look it up - for semiconductor designs, it's explicitly protected for one person to crack open a chip, write down the way the chip works, and for another person to reimplement the way the chip works based on the first person's documentation. They don't need a reason. They're explicitly allowed to do it.
If someone implements the chip without the first person's documentation, then it's even more explicitly okay - which is actually what Tridge did. No access to source code or workings whatsoever - just figuring it out from network traffic. Of course, maybe you'd like to say that someone can say "You may not use this product if your ethernet traffic may be captured" in which case, no one can use BitKeeper.
Sure, his solution would have been OSS, but that wasn't the drive behind it.
How do you know? How do you know his goal wasn't to make a BeOS client? But again, as I said above, you don't need a point to reverse engineer.
This client would sink their business.
I doubt it - and if that's true, then they're resting on their laurels far too much, because you're saying "they won't be able to compete with a reverse-engineered client." If that's true, that's competition for you. No one would've wanted to give IBM a free pass simply because it couldn't compete with Compaq's PCs.
Essentially, you're talking about granting them a monopoly. A monopoly on BitKeeper clients. If their business model relies on having a monopoly on BitKeeper clients, then they deserve to be sunk.
It's worse than that (Score:5, Insightful)
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.
Re:My opinion hasn't changed (Score:5, Insightful)
McVoy is trying to lock people - his customers, for chrissakes - into BitKeeper by preventing them from getting data out of the BK repository in any way of which they do not approve. He is claiming two things; that reverse engineering is wrong, and that tridge's client may somehow break BK. To the first point, he is wrong; not only is it a legally-protected activity (at least in the U.S.) but it is a fundamental engineering method that has been guiding engineering as long as there's been engineering, and then some. To the second point, he is again wrong; clients do not break servers. Servers break servers, when they do something stupid in response to a client request. A client request that would result in database corruption should be denied. There should be nothing you can do, for example, in a SQL query, that will stop the RDBMS from working. A SCMS is supposed to maintain old revisions and let you work on new revisions, and handle merging code, right? Where in there does it say that the client should be able to corrupt the database? This is what McVoy is saying is a risk with a third party client. In other words, BK is not designed with reliability in mind. Do you trust BK? Do you think McVoy is making reasonable statements? McVoy IS down the same creek as Microsoft. Vendor lock-in, trying to prevent people from developing interoperating tools, and placing blame for failure of their systems on other companies. That sounds quite a bit like Microsoft to me. If they ever get a monopoly, we'll see how they do on the fair trade practices, but in the meantime they're Microsoftian enough for me to avoid them like the plague that they apparently are. It may be a fantastic product when you don't want to do anything it doesn't provide for, but frankly I think that's a bullshit way to purchase (or, as we do today, license) software and not at all good for the long haul.
Re:Definitely disagree with McVoy (Score:3, Insightful)
I have nothing against Larry releasing a free version, but doing that still doesn't give him any right to profit. I certainly have nothing against him having retired it, but retiring licenses to people vaguely associated with people doing reverse engineering is plain stupid.
Re:I really think Tridge needs..... (Score:4, Insightful)
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.
Re:My opinion hasn't changed (Score:3, Insightful)
You even read what you're saying? Don't compete by looking at my solution.
Not the source, not decompiled code, not hex dumps, not even formal documentation. Looking at the product. That's enough to get the license revoked for everyone you work with. Larry McVoy wants total control, and it's plain that he cannot be trusted.
Re:weak answer from Tridge (Score:2, Insightful)
Linus Torvalds doesn't seem to agree. Or does that not count now that he's betrayed the purer faith?
Re:Really? (Score:3, Insightful)
Tridge did not (a) accept BitKeeper's generosity nor (b) "attack". He was working on building a tool that would compete with free BitKeeper. I hope you don't think that anyone else did anything wrong.
What exactly do you think should have gone differently here?
But using BitKeeper has been *good* (Score:5, Insightful)
"...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.
Re:Tridge knew this would happen..... (Score:4, Insightful)
-russ
and thus, R.Stallman was right after all (2 etc) (Score:3, Insightful)
"If you follow some of the links from the article, it talks about productivity doubling since using BitKeeper."
There is, ofcourse, always the matter that there might be a relation noted, but therefor not a causality. Is there really a heightened production? Is it due to Bitkeeper? Is it *all* due to Bitkeeper?
Those are reasonable questions, and I think, even the neutral Linus could be biased a bit in this regard, because after all, he has made and kept to this decision for 3 years, contrary to much critique.
"Even if there is a cost now moving to something else, it may still work out better in terms of productivity to have used BitKeeper for the three years. Also the use of BitKeeper in Linux seems to encouraged a lot of work on open source alternatives, so they may well be better now than they would have been had BitKeeper not been chosen."
The cost will not be minute, I assure you. Yes, it *might* have been worthwile, but I have problems with this 'might' because it is largely based on speculation. If it really is all that much beneficial, he (Linus) would obviuosly chose another technological superior, yet proprietary system. I doubt that he will, however. Well, we'll see.
"So from the practical, rather than ideological, point of view, even with dropping it now it may still have been the best choice."
See above.
"When you are provided a powerful tool for no cost under the condition that you don't fund the creation of a competing tool based on that technology you are not at the whim of someone's goodwill."
Ermm...yes, you are. I don't follow you: you just describe a situation where, at least in that instance, you are at the whim, and you claim it's indicative that you aren't? Unless you equal 'whim' with totally unreasonable demands, this makes no sense. however, being depended on the goodwill of someone does not infer being unreasonable: they can have very good reasons (even economical ones are good too, in a sense); but still it remains a fact you are at their mercy.
"When they approached OSDL and said you have a employee doing this (reverse engineering our technology), please have them stop and OSDL says it's not our problem."
See above. Besides, reverse engeneering isn't illegal per sé, so they were right to say it's not there problem.
"Its not like they all of the sudden started says hey OSDL/Linus you now need to start paying for this since you like it. They said we are giving you free access to our tool but you have staff that are now striking at our revenue line, which happens to be how we fund this tool you like. Please have them stop and we will continue to provide this tool."
That's very amicable (or not) of them, but it still means one is not free to use the tool; thus, one is dependend on their goodwill.
"When you still thumb your nose at the company who has employees to support and revenue to generate you are only putting them under the gun."
See above.
"So based on this evidence you can see this isn't a RS versus Linus issue versus a OSDL taking responsibility issue. If OSDL came back to the table and said Ok, mea culpa, we will make this right then the problem wouldn't be there."
Yes, it would, since it would still be clear that they are not really free. If they can say 'do not do this" they can say "do not do that" neither. Whether it is reasonable from their perspective or not doesn't enter the picture: it still makes it clear that they can't use the tool totally free.
"Make Sense?"
Not really, when you look at it strictly from the viewpoint of whether or not they are delivered to the goodwill of the owners of Bitkeeper. This shows they aren't, whether Bitkeepers owners were reasonable in their demands or not.
"RMS was not necessarily right. In TFA Linus is quoted as saying "three years of using BitKeeper has made some profound impr
Re:Definitely disagree with McVoy (Score:3, Insightful)
The license didn't just prohibit reverse engineering for any reasonable definition of the term, it prohibited licencees from working on any other source code management system for some time into the future. What this means is, not only are the people who won't touch nVidia drivers morally unable to use BK, but most people who value their freedom and want to keep their options open can't morally use it. Not only that, it makes using BT a big liability, because how do you define SCM system? And there were tons of people whose employers won't let them enter into such a contract, and with good reason. The "free" BK license drastically increased the demand for a BK "clone," which was absolutely needed for interoperability with the unnecesarily large number of people who couldn't agree to the license.
The idea with the free version was that you could use it if you made your servers open to the public, but if you wanted them private, you'd have to pay. This is a great business model, and perfectly capable of being supported using nothing but copyright, and not even particularly restrictive licenses. It would even have been possible to make the source code visible (though not "open source," as you couldn't necessarily use the results of your modificiations). But instead McVoy got scared, and made the license far too restrictive, thus increasing the demand for a clone. When work inevitably began on this, he took his ball and went home.
Also, saying Tridell is "license cracking" implies that he was a party to the license, which we have no evidence of. And 'If you do this, it'll sink our business; We gotta eat' is not a valid argument.
Re:You git! (Score:4, Insightful)
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.
Re:McVoy: Ultimate Open Source Advocate? (Score:3, Insightful)
Re:So it's about control (Score:3, Insightful)
But they have no reason to believe that. A bug in their own client could apparently cause corruption. Then it would be their own fault. It would make more sense to build a server which could not be damaged by anything the client can send it than to depend on the client. Especially if other people can gain access to this service. Imagine someone finding a flaw like this in BK, connecting to the repository, and breaking your code... Irrecoverably.
I'm not sure it was so unwise. If Tridge's goal was to get access to all of the information in the repository, and he doesn't care if the kernel sources are managed with BK, this is a win for Tridge because the next system will certainly be more open. If Tridge's goal was to separate Linux and BitKeeper (not unthinkable) then it's a win. In fact in general I am not sure what Tridge might have lost by doing this; his boss probably knew what he was doing. But of course, this is pure speculation, and we will have to wait to find out how much of this is true. Certainly I would be quite annoyed if he suffered as a result of doing something both legal and necessary.
Can't have your cake... (Score:4, Insightful)
Re:My opinion hasn't changed (Score:3, Insightful)
Based on Larry's past (e.g. lmbench!) and present behavior, that would be extremely unwise. In this instance, IMO, Linus is being a profound fool.
I don't blame Tridge for insisting on a method that doesn't continue to put everyone at the mercy of Larry's whims. Frankly, he's done Linus a favor, at least in the long-term.
Re:Really? (Score:2, Insightful)
Propreitary overlords? Linus picked the tool, and could have unpicked it at any time. Other people do kernel development without using it at all. If Tridgell has a beef with somebody, it should be with Linus.
Now if Tridge just wanted to improve the state of kernel development, he did a pretty poor job of it. And if he didn't care about the kernel and just wanted to reverse engineer BitKeeper, then perhaps he could have picked somewhere other than OSDL to do it.
Or if his goal was really to improve the state of open-source SCM, then maybe he could have buckled down and started his own project. Or he could have done work to add BitKeeper features to SVN. Starting on an open-source BitKeeper tool seems weird to me, and continuing after Linus asked him to stop seems especially weird. I look forward to hearing his explanation.
Aside from finding that situation unacceptable on the face of it, I imagine Tridge also worried that Larry would continue to tighten the noose over time. From what I've heard from other people who have actually had to deal with him, it's not an unfounded concern.
I grant that McVoy's a bit of a loon. On the other hand, he's also struggled to build a business competing against larger, better-funded companies, which would certainly make him a little defensive. I'm not sure which is the cause of him flipping out, but I imagine it's a bit of both.
But either way, if Tridge felt that Linus was making a bad decision, the right thing to do was argue with Linus. Or even better, to spend the time to produce something that's both as good as BitKeeper and also free (libre), so that Linus was compelled to switch by the quality of his work. But forcing Linus off of his chosen SCM system and providing no decent alternative was either amazingly jerky or a huge miscalculation. I hope it's the latter.
And really, if we in the open-source community are going to build exact clones of other people's products rather than building new, innovative stuff, then I'd rather see us go after large, sinister companies that work against open source, rather than small ones that spend time and money helping Linus out.
Re:I really think Tridge needs..... (Score:3, Insightful)
-------------------
Since Tridge isn't talking about it at the moment, I'll try to provide some insight.
"Why he thought it was important to start reverse-engineering BitKeeper, rather than any of the many more widely-used proprietary products out there"
-- Because the Linux kernel source isn't stored in those other proprietary products.
"Whether and why he's doing it on OSDL's nickel"
-- He did it on his own time, as has been stated numerous times.
"Why he kept going when, at least according to McVoy, OSDL promised he'd stop while they negotiated"
-- Who said he promised to stop? And why should he?
"Whether screwing up Linux kernel development was worth whatever it is he thinks he's achieved"
-- Sorry, it was BitKeeper that screwsd up kernel development by creating this mess. Which anybody with a clue could see coming years ago.
"Why reverse-engineering the BitKeeper project was the only way to achieve his goals"
-- Because there is no other way to get all the revision data out of BitKeeper repositories, and into free/open source repositories.
"Whether he'll keep going with the project now that the kernel won't be in BitKeeper format anymore."
-- He surely will, until every last bit of open source code has been released from locked-in BitKeeper repositories.
If you have any more questions, could you please phrase them in a less accusatory style.
Re:My opinion hasn't changed (Score:2, Insightful)
Duh! Obviously you are at fault for inviting your noisy, messy friends. You made a poor choice, realized the unintended consequenses, and deal with it by making due without use of said conference room. Similarly Linus made a choice, realized the unintended/unexpected/unwanted consequenses, and now must make do. It's not the end of the world (no matter whose side one subjectively chooses to be on).
Also (to address your main point), why should Tridge be obligated to respect Linus' decisions/wishes regarding BK any more or less than Linus is obligated to respect Tridge's decision to choose another (perfectly legal and ethical) option?
Re:My opinion hasn't changed (Score:2, Insightful)
That's OK. We're allowed to have differing opinions. I don't feel it is unethical for one to stand by one's principles. Sometimes when you stand up for your principles you offend others (including possibly your friends). If someone is really your friend they will respect that fact that you stood by your principles, even if they are offended.
The *ONLY* person wrong here is Tridge
I disagree. IMO no one is 'wrong here'. I don't fault Linus for choosing BK, and I wouldn't fault him for being upset with Tridge. I also don't fault McVoy for terminating the license, as he is perfectly within his rights to do so (although I find his reasoning suspect, as is my prerogative). Where we seem to differ is that I also don't fault Tridge for standing by his principles. A great man once said, "The universe is not required to be in perfect harmony with human ambition."
So I ask again, why is it that Tridge ought to be bound by Linus' decisions and principles any more or less than Linus be bound by Tridge's?
Re:You are talking like a marketing droid.... (Score:3, Insightful)
I work in the information industry. I don't want to be working on Microsoft platforms 10 years from now because linux consistently stumbled, got a reputation for amateurish behavior and not being able to release quickly enough to satisfy customers, and lose the confidence of the industry.
You, on the other hand, mouth platitudes like an poser loser. "Hackers don't meet deadlines, they don't program for money, its purely for the knowlege and pleasure."
Yeah, I can see why your more comfortable with slowing things down, espousing F/OSS theory, getting rid of those damn capitalists. Accomplishing doesn't mean jack to losers like you. Worse, you think you're entitled to tell producers how they should do their job. (Man, I hate that Ayn Rand...)
Go become a HURD fanboy. They wouldn't be caught dead using BK. They're the ultimate in hacking. There's way more computer science theory in microkernel, multithreaded programming than an outdated monolithic kernel design like Linux. Leave Linux to the soulless masses...