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)
I wouldn't excatly call it love.
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 |
Does the name 'git' strike anyone else as an odd name for a (kind-of) SCM system?
Or is this Linus making a not-so-subtle pot-shot at Larry McVoy?
"Linux leader Linus Torvalds has begun looking for a new electronic home for his project's source code after a conflict involving the current management system, BitKeeper"
Linky
"With sufficient thrust, pigs fly just fine." -- RFC 1925
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.
Wow, that is definitely one video I definitely wouldn't want to look for a torrent of.
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.
...to make a better statement.
This kind of thing looks bad to the entire community and makes corporations question their liability if it's found their products in use have been copied. OSS doesn't need this kind of anchor around it's neck.
I hope this addressed openly and completely in the near future.
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
Curiouser and curiouser.
And, incidentally, since Larry is so offended by Tridge's reverse engineering, I take it that he's taken the moral stand, and backed up his strong principles by making sure that none of BitMover's employees use Samba, either at work or in their spare time.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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.
It seems that Larry McVoy has a fine line between a replacement and reverse-engineering (in this case compatibility?).
From the article (Torvald's statement):
" What Larry is _not_ fine with, is somebody writing a free replacement by just reverse-engineering what _he_ did."
I always am sympathetic to reverse engineering efforts, because frankly interoperability is ultimately a good thing. I am not sure what sort of principle we can follow if reverse-engineering is bad in this case. Where is the line? Is it a property line?
You've put together the friggin' _kernel_. This is a lot more complicated than creating a version control system. Just take Monotone (which I like as it is), and make a BitKeeper killer out of it. Have Tridgell do it with a few other gurus. Yeah, it's probably gonna take half a year, but the benefit to the open source community will be immense.
Thanks for stripping out the formatting. I despise paragraph breaks, and now, I don't have to read them!
He was most likely asked or forced to sign some form of Non-disclosure agreement. This is even more likely if lawyers were or are involved (in which we'd have no way of knowing if all involved parties keep silent).
Regards,
Steve
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.
When you think of copyrights like a right (and please don't go off on how it's pro business), then it is only a matter of time till you believe that your right is the right to controll how others use or learn from information that originated from you via coercive means.
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.
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.
They didn't drop BitKeeper. BitMover dropped the free version BitKeeper and refused to license the paid version to any employees of OSDL.
Being Linus works for OSDL, that pretty much means BitKeeper has to go or Linux has to leave OSDL. It is the same case for Andrew Morton. I think Linux prefers to drop Bitkeeper.
So nice of you to copy this comment from an earlier story, verbatim, without crediting the original author.
Auto-reply to ACs: "Truly, you have a dizzying intellect."
Larry McVoy sees two problems with Andrew Tridgell's reverse-engineered, free tool. One is "condoning reverse engineering". The other is, in his words:
Once again, Linus shows he more of a practical guy than a political ideologue. He recognized the cost to BitMover and suggested the rational solution for them. I think Linus' role in this is being underreported--he appears to have been on McVoy's side all through this.
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!
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)Free Mac Mini Yeah, it's
Amazing. The exact same post was made by Concern, here. And then Squiggleslash replies with the exact same reply that Redswinglinestapler replies with here.
Are you guys just all the same people, or what?
Moderators: this is redundant, and overrated.
Secession is the right of all sentient beings.
Wow.
Nice catch.
Especially ironic given the title of the post, and the copyright issues the gpl uses as its core.
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
On the other hand, I see plenty that is ugly about BitMover trying to impose the terms of their license on a guy who apparently didn't even use their software to build a free replacement for it.
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?
Free MacMini
He hardly "Came along", if I remember right he wrote most of rsync and was the initial author of (and is still a major developer of) Samba. Devising and reverse engineering protocols is what he does.
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.
Hey, it's the easy way to summarise! It can also be automated. Summariser v2.0 also stripes out spaces and punctuation to reduce article size even further! Coming soon from a /dev/urandom near you!
the layman's guide to computer science
Not quite. They agreed to donate free license for the paid version of BitKeeper to a number of Linux developer, but they refused to provide them for anyone at OSDL. Linus would still have been free to pay for a license, but he decided not to on the grounds that it would increase the barrier for entry for new kernel developers (and some existing ones).
I am TheRaven on Soylent News
"Then this 'Tridge' guy comes along, and is *so* opposed to BK that he is determined to fight against it using tactics that are legal, but not especially moral, ethical, or friendly."
Yes. And why can't he? What's immoral or unethical about trying to interoperate with a program which performs a task very well, is popular and has restrictions attached to its usage that someone sees as making the program inaccessible to themselves, completely within the bounds of the law?
"Then, while a temporary cease-fire is arranged so that the matter can be discussed and resolved maturely, he violates this truce."
The "ceasefire" was temporary while the situation was being resolved. (BTW: Where was the "war" and/or who was threatening it? It was more an investigation into the situation). Obviously, there *wasn't* any sort of resolution and people have squarely placed the blame on Tridge.
How? He (I assume) agreed not to reverse engineer the program as part of his work. You can't stop him, or guilt him into stopping, from performing a perfectly legitimate activity in his own personal time.
"So now that so much happiness and productivity has been ruined, are the license zealots happy? I hope so."
Lost happiness is questionable, lost productivity is probably undeniable. However, how much more productive could someone be with an OS or otherwise free version of this same tool, with all of the custom additions they require?
Linus himself has always said that he'd love to be able to use some OS equivalent of BitKeeper but that one did not exist. Tridge was obviously taking steps towards creating something along those lines, or at the very least building a helpful tool to improve BK's usage.
The problem is not licensing choice, or zealotry. The problem stems from people's perception that somehow emulating a good tool is blasphemous, immoral, illegal and generally bad. Of course, having an OS equivalent of BK will not be in BK's own interest because they would probably see some dip in sales, hence the clash of personalities that we've seen in this case.
However, people always knew that this point was going to turn up and that there would be controversy. Somehow, McVoy is being depicted as some sort of spurned hero and, in a way, that may be correct. He's got a good tool that is well-crafted, no doubt, but at all points it was obvious that the more popular it got, the more people would emulate its functionality.
McVoy isn't a hero. He's a good programmers. Tridge isn't some sort of villain. He's legally emulating functionality that he can't enjoy under his own terms any other way.
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.
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.
Once I waive the cloud of zealot spray away from my face a bit, I still have the same question: How is reverse engineering BK right when the company he worked for said it wouldn't in a legal agreement? Isn't this what happned? moral or immoral doesn't count. BK had a standard clause (look at any software licence and you'll probabaly see it) that said you can use our product as long as you don't use the product against us. OSDL agreed (through Linus I believe) that they wouldn't reverse engineer. They said so in a legal agreement (licence). There is someone under thier pay reverse engineering it.
Argue on the right and wrong of such an agreement in the first place. Argue on the details of how far the agreement reaches. The first is about something in the past. The second is about somethign going on now. But, They are really different arguments. And to claim no problems exists seems kinda funny to me since the licence doesn't just go away because you don't like it.
AB HOC POSSUM VIDERE DOMUM TUUM
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.
I hope not.. Or we wouldn't have any frigging drivers!
What are the limitations with the various obvious candidates ? Is support for merging binaries the killer feature ?
What made BitKeeper so special in the first place ? Shouldn't a really good SCM server system have a standardized, controlled interface that can allow simple, third-party clients, anyway ? If Tridge had limited his client to doing check-outs, and had avoided modifying the source tree with it, would the BitKeeper folks have been OK with _that_ amount of reverse engineering ? And who works with the leaders in open-source software while being so against reverse engineering ?? That seems odd.
But ignore that last set of questions. Really, I just want everyone in this thread to tell me what the really, really good open source SCM system I'm not using is. Unless it's Subversion, in which case I want you all to tell me what to look out for.
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.
I really don't get how a single ChangeSet file could wreak havoc to all those repositories out there.
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) for the rest of your life, since anything else would be against your sense of 'ethics'.
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.
Context is everything. I posted this article (written at the time of Linus' adoption of bitkeeper) from Linux World in the last BK thread. Casts the current events in an interesting (and not McVoy-friendly) light.
grammar-lesson free since 1999. (rescinded - 2005)
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.
Lets get this straight. Permission and/or a license agreement and/or source code are not not needed to reverse engineer software or anything else. And its still perfectly legal, moral, etc.
Not in the case of reverse engineering; reverse engineering is a vital part of competition in a free market.
Actually, it is the controls put in place by Microsoft (no-compete licenses with OEM's + punishment for those who disobey) that skew the market and merit sanctions against Microsoft. Microsoft's size and market share only enable the problem (their bad behaviour); its not the problem itself. In a truely free market, the market dictates how the vendors behave, not visa-versa.
Unfortunately for your arguement and for the BK folks, you can't preclude people from doing things in a license if those people aren't actually party to the license. Tridge stole nothing from BK by reverse engineering it.
No, it doesn't. It sets conditions for anyone who copies, distributes or creates derivative works of software. You can completely repudiate the GPL and continue to use GPL-licensed software (except for copying, distributing, and deriving).
You're thinking of an End User License Agreement (EULA). EULAs take away users' rights. The GPL is not an EULA. The GPL gives you rights you would not have had without a license.
(prostituting anonymously)
Go, AT!
How Samba was written
---------------------
Andrew Tridgell
August 2003
Method 1:
---------
First off, there are a number of publicly available documents on the
CIFS/SMB protocol. The documents are incomplete and in places rather
inaccurate, but they are a very useful starting point. Perhaps the
most useful document is "draft-leach-cifs-v1-spec-02.txt" from 1997
which is a protocol specification released by SNIA and authored
primarily by Microsoft (with significant input from many other people,
including myself). This document has expired as an IETF draft, and
Microsoft has dropped their attempts to get CIFS accepted as an IETF
standard, but the document is still available if you look hard enough
with an internet search engine.
There are numerous other public specifications for various pieces of
the protocol available. I maintain a collection of the ones I know
about in http://samba.org/ftp/samba/specs/
Method 2:
---------
I call this method the "French Cafe technique". Imagine you wanted to
learn French, and there were no books, courses etc available to teach
you. You might decide to learn by flying to France and sitting in a
French Cafe and just listening to the conversations around you. You
take copious notes on what the customers say to the waiter and what
food arrives. That way you eventually learn the words for "bread",
"coffee" etc.
We use the same technique to learn about protocol additions that
Microsoft makes. We use a network sniffer to listen in on
conversations between Microsoft clients and servers and over time we
learn the "words" for "file size", "datestamp" as we observe what is
sent for each query.
Now one problem with the "French Cafe" technique is that you can only
learn words that the customers use. What if you want to learn other
words? Say for example you want to learn to swear in French? You would
try ordering something at the cafe, then stepping on the waiters toe
or poking him in the eye when he gives you your order. As you are
being kicked out you take copious notes on the words he uses.
The equivalent of "swear words" in a network protocol are "error
packets". When implementing Samba we need to know how to respond to
error conditions. To work this out we write a program that
deliberately accesses a file that doesn't exist, or uses a buffer that
is too small or accesses a file we don't own. Then we watch what error
code is returned for each condition, and take notes.
Method 3:
--------
Method 3 is a greatly expanded variant of the "swear words" technique
I have already mentioned. It involves writing something called a
"protocol scanner". A protocol scanner is a program that tries all
possible "words" in some section of a protocol and uses the response
to automatically deduce new information about the protocol. It is like
the French Cafe technique but with a very patient waiter.
For example, some section of the protocol might contain a 16 bit
"command word" that tells the server what operation to perform. There
are 64 thousand possible command words, so we try all of them and note
which ones give an error code other than "not implemented". Then we
need to work out how much supplementary data each command word needs,
so the program tries 1 byte of blank data, then 2 bytes then 3 bytes
etc until the server changes its response in some way. When the
response changes then you know (with a fairly high level of confidence
at least) that you are using the right quantity of data. You then try
using non-blank data, putting in a filename or a directory name or a
username until the server changes its response again. After a large
number of tries the program eventually finds a combination of data
that gives no error code at all - the server
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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!
"(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. ;)"
I just have one thing to say: About fucking time.
I'm on an out of date 2.6 kernel right now because every 2.6 kernel I've used has replaced one set of show-stopping bugs with another. I'd rather just stick with the show-stoppers that I've worked around (in this case, I use a Promise IDE card because the kernel doesn't support an SATA hard drive and a CD drive on the same chipset) than get a whole new set of show-stoppers that I may not be able compensate for.
I rarely criticize things I don't care about.
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?)
And in fact I have a lot of respect for Linus for dropping BK now right on the spot, when the problems it created were becoming too big -- after he had been unimpressed by 3 years of anti-BK flaming...
Indeed. I've been staying out of this as I know too much about what really happened to comment publicly.
But one thing I will say is that tridge has done *nothing* wrong in this matter.
As for his short reply to the question, unfortunately this is for reasons outside his control.
Jeremy Allison,
Samba Team.
If I disasemble your code to find out how you did something and then make my own version that is probably a clear case of reverse engineering.
If I use your product for a period of time and keep notes of all it's features (and bugs!) and then create a work alike based on my notes is that also reverse engineering?
Samba was clearly reverse engineered, and it HAD to be done that way because M$ dosen't publish any details on the workings of their net protocols necessary to build a work alike. Does M$ gain anything from Samba? Perhaps they don't lose some sales of Office and Windows OS because by having Samba available a customer can choose to keep their windows desktop sytems and applications while using Unix for their inferstructure.
I cannot fault BK for having an anti-reverse engineering clause in their eula for the 'free' version of the product. As long as someone had purchased the 'enterprise' version I would think some form of functional reverse engineering (not necessarly disassembly and copy) would be fair game.
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.
Ceterum censeo subscriptionem esse delendam.
"I developed the tool in a completely ethical and legal manner." Whether it was the right thing to do or not in light of the situation, and despite the warnings, for him it was "ethical" to go ahead with it despite full knowledge of the consequences. Tridge's ethical conscience 1 Rest of the Linux community 0
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:
I'm sorry, but there is no way to write "a tool that is interoperable with BitKeeper" without using BitKeeper. How in the world did he test his tool? How does he know it's interoperable? Well, the only way is to actually try it. Which means his comment "I did not use BitKeeper at all" is a completely lie.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
In a word, "Yes". Just don't copy the source code, or people might get a bit irritated.
That is all.
If only there were a decent FOSS source-control system out there, the end of free BitKeeper wouldn't be an issue.
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.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Lesson #1:
From what I can tell, BitMover got involved with the Linux kernel for very little or no money. Expecting a return from giving your product away for free and expecting return in the form of corporate profit is a huge mistake when it appears the business model is product (not support/integration service) oriented.
Lesson #2:
Every good idea gets reversed engineered. Take it as a compliment that your software is being reversed engineered. In this article and judging by some of the comments, it's not viewd as complimentary and it might land the parties in court. (I won't get started with the problems with American IP)
Personal Opinion and Off-Topic:
(Here's where I get modded down) Reverse engineering should be valued as an accomplishment in American culture. A reverse-engineered product is typically lower in cost and innovates because more consumers can afford it.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
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.
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.
Since this is much in line with the answers I already gave to other posts like yours, let me repeat those:
"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
--- "To pee or not to pee, that is the question." ---
Well once again we see the wisdom of RMS's position that you try for 100% non-proprietary software.
Time and again, he has been proven correct, and others (like me) who are willing to compromise or cut corners proven wrong.
MP3 -> ogg-vorbis
KDE/QT -> Gnome
BitKeeper -> ???
Others I prob don't know about.
The article cites Torvalds summarizing McVoy's position:
Compatibility is honest competition and it requires understanding protocols to work as a drop-in replacement. There is nothing so original about BitKeeper that it would pass the criteria of this statement. But the next statement from Torvalds underscores a theme on why we should not place Torvalds in the position of "posterboy" for a long-term movement:
Well, I can, and Torvalds ought to be able to. In science and art (and perhaps those categories draw an artificial difference which is much more blurry in reality) everyone rides someone's coat-tail. Again, the work done by the speaker would not pass the test suggested by these statements. The Linux kernel does a lot of things that are not original. One of the major reasons it was able to become a practical kernel is because of its design--HURD developers talk of the difficulty of debugging a multithreaded kernel replacement which slows down their development progress. A monolithic kernel, it has been said, is easier to debug and faster to add new features to. The GNU/Linux operating system benefits from Samba and OpenOffice.org which are built on reverse engineering Microsoft's underdocumented and changing protocols and file formats.
This is part of why I believe Linus Torvalds is about to make the same mistake twice, choosing a non-free program for Linux kernel maintenance because he values popularity and short-term technical gains like more than software freedom.
Digital Citizen
While the agreement was made between Linus and McVoy, Tridge positioned Linus in the middle of the shit.
I think that everyone just needs to take a moment and look at what actually happened here.
Bitkeeper created a truly exceptional source management software. Linus had a problem with what he was currently using, and was in search of a new tool. Bitkeeper provides Linus with a free version which allows him to use the tool, thus providing two things: (1) an exceptional source management tool for Linux, (2) unbelievable publicity for Bitkeeper by having perhaps the most famous developer in the world using and advocating his product.
Fast foward 3 years. Bitkeeper has established itself as a solid company on its own right, and spends a considerable amount of money maintaining the relationship with Linus. An open source developer starts developing an open source version of the Bitkeeper product, which is essentially happening because the product is being given away for free. Essentially, what is happening here is that McVoy is spending money to provide a free version that is actively being used to create an open source competitor to his product.
As much of an open source fan as I am, I have to see McVoy's stance on this. Why should he spend money to indirectly support the creation of a competitor to his product? Because he's got a good heart and knows that it is good in the long run? He's also not stupid, and realizes that the open source version will get along just fine w/o his indirect funding.
Now let's find a villian, shall we?
Option 1: Linus. Linus has done no wrong. He used the best tool at his disposal. It wasn't open source, but it was a small amount of evil for a greater amount of good (linux kernel moved along quite well with bitkeeper). Now he's looking for another solution. Villian? I don't think so. Opportunistic? Definitely.
Option 2: McVoy. McVoy provided Bitkeeper free of charge for 3 years and kept up development on the free version. Changed his mind when Tridge wouldn't quit developing the open source version which essentially reverse engineered the work he had done and created a valid competitor. Made the proper business decision, lost his best marketing tool. Villian? Don't think so. Opportunisitic? Definitely.
Option 3: Tridge. Didn't like using the proprietary software, and decided to reverse engineer what had already been created. This caused McVoy to have problems with the business relationship. Result is that Linus has to find a new SCM solution, but also that new energy will be thrown into SCM in an open source way. Villian? Not at all. Opportunistic? Definitely.
My conclusion? There is no villian here. The entire relationship was doomed to fail eventually. Everyone got something out of it while it lasted. Linus got great source code management. McVoy got _amazing_ advertising. Tridge got to create an open source version of one of the best SCM systems out there. Who is the winner? Probably everyone. Who is the loser? I can't think of one right now.
Opportunity knocks. Karma hunts you down.
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PT O2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r =5&f=G&l=50&co1=AND&d=ptxt&s1='Sun+Microsystems'.A SNM.&s2=skinner.INZZ.&OS=AN/%22Sun+Microsystems%22 +AND+IN/skinner&RS=AN/%22Sun+Microsystems%22+AND+I N/skinner
I believe Larry thinks he should be listed as co-inventor (and he probably should), but that isn't what the patent says. I don't really care for the purposes of this dicussion, but just wanted to verify that my memory isn't completely gone. Note that there was a fair amount of prior art leading up to this.
Unpicking it requires an export tool, and frankly, like Tridge, I wouldn't personally want to rely wholly on Larry's good graces for one as Linus seemed willing to do.
So, is Larry providing one now? Tridge's was just a proof-of-concept.
(Admittedly that's kind of moot as it sounds like Linus did extract his own BK repository already. But what if he hadn't?)
This was on his own time, not when he was billing OSDL contract hours (he's a contractor, not an employee).
Larry did that, not Tridge.
Frankly, the more I read about the situation, the more this sounds like one of those situations where a controlling and jealous husband beats his wife because he doesn't like what some of her friends are doing. Then some people take the side of the husband and blame the friends for everything.
They insist how good he was was to her, and that he wasn't really TOO controlling, really. He PROVIDED for her. Where would she have been without him? Is it too much to ask if she and her friends could just show gratitude and respect his wishes?
DNA just wants to be free...
I'm speaking like someone who wants linux to be the preferred choice to do computing. I want to help my mother and family use linux PCs, not XP. (Because XP is "easier", runs the programs they want to run, works on all hardware...) That won't happen if Linux doesn't become the widespread choice of platform for business.
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...
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon