The kernel and BitKeeper part ways

Back in early 1999, your editor got a call from Larry McVoy. He was worried that Linus Torvalds was on the verge of burning out as the kernel project grew. The problems in those days were quite evident; Linus, it was being said, did not scale. But, according to Larry, a complete burnout was not inevitable. If Linus could be given the right tools, many of his problems (and the frustrations of other kernel developers) could be solved, and the system would run smoothly again. The right tool, according to Larry, was a thing called BitKeeper; if some sort of agreement could be made on licensing, Larry (along with his company, BitMover) was willing to make BitKeeper available for kernel development. In fact, Larry wanted to see BitKeeper used for all free software development; see this article from the March 25, 1999 LWN Weekly Edition for a view of how things looked at that time.

Three years later, the situation did not look any better. The 2.4 kernel had taken almost a full year to stabilize after 2.4.0 came out. 2.5 had begun, but the process was looking rocky at best. Patches were being dropped, developers were complaining, and Linus was getting tired. After convincing himself that the tool had reached a point where it could do what he needed, Linus decided to give BitKeeper a try. There was no looking back.

Some of the development process issues could have been addressed by adopting any source code management system. But BitKeeper brought more than that; it established a model where there is no central repository. Instead, each developer could maintain one or more fully independent trees. When the time came, patches of interest could be "pulled" from one tree to another while retaining the full revision history. Rather than send patches in countless email messages - often multiple times - developers could simply request a pull from their BitKeeper trees. Meanwhile, the current development trees could be pulled automatically into the -mm kernel, allowing patches to be tested by a wider audience prior to merging into the mainline. BitKeeper enabled a work method and patch flow which naturally supported the kernel's development model.

Once the developers and the tools got up to speed, kernel development took off like never before. The rate at which patches were merged skyrocketed, the developers were happy, and the whole system ran smoothly. The public version of Linus's BitKeeper repository (and the repositories of many other developers) made the development process more transparent than ever. Anybody could look to see the up-to-the-minute state of the kernel and how it got there. Larry was right: with the right tools, Linus really could scale.

The only problem was that BitKeeper is proprietary software. Instead, it came (in binary-only form) with a license which allowed free use, but which imposed some significant restrictions. The free version of BitKeeper could only be used with open source projects; users could be required to make their repositories available on demand. The free version posted all changelog information on openlogging.org, and disabling the logging was not allowed. Users were required to upgrade to new versions, which could come with different licenses. And users were not only prohibited from reverse engineering the software, but they were prohibited from working on any sort of source code management system at all.

Larry wanted to have his cake and eat it too. He truly wanted to support the development of free software - as long as that software didn't threaten his own particular business niche. Supporting the kernel development cost real money - and supporting the business which created BitKeeper cost even more. Whenever BitMover felt that its business model was threatened, it responded; often the BitKeeper licensing terms were changed in response to perceived threats - to the point that the BitKeeper license became known in some circles as the "don't piss off Larry license."

Well, somebody pissed off Larry one time too many. The final straw, it seems, was a certain high-profile developer who refused to stop reverse engineering work while simultaneously doing some work for OSDL. BitMover is now withdrawing support for the free version of BitKeeper, and Linus has ceased to use it. BitKeeper is no longer the source code management system for the kernel. Proprietary software can be good stuff, but it always carries this threat: you never really know if it will be there for you tomorrow or not. BitMover has decided that it can no longer afford to make BitKeeper available for the free software community.

BitMover has issued a press release on this change:

The open source client, incidentally, enables the extraction of the current version from a repository, but does little else. The PR also states that "Our relationship with the Open Source community has been evolving and many of the key developers have already migrated to the commercial version of BitKeeper." Linus has, however, made it clear that he is not one of those "key developers":

What happens next is far from clear. The kernel developers will not go back to the previous way of doing things - no source code management system at all. Even the developers who can continue to use BitKeeper are unlikely to continue doing so if Linus is unable to pull their patches. So a replacement will have to be found. It is not clear that any of the free alternatives is up to the task of handling a project as large as the kernel. One of them may end up growing up in a hurry in order to take the load. Thanks partly to the example and motivation provided by BitKeeper, the free alternatives do look far more viable than they did three years ago, when Linus first started using BitKeeper.

Larry has made it clear that he blames the free software community for this turn of events:

If BitKeeper users were violating the license under which they received the software, they have indeed done something wrong. Every time we release code under a free license, we do so with the expectation that the terms of that license will be respected. To treat somebody else's license with less respect is hypocritical; if the license terms are not acceptable, do not use the software. That said, one could note a couple of other things. The notion that developers of proprietary software do not engage in reverse engineering - that it's "an open source community problem" - is debatable at best. And how, exactly, might the community be expected to do this sort of "policing"?

The ironic result of all this is likely to be the accelerated development of exactly what Larry claims to most fear: a free source code management system that, while it lacks much of what makes BitKeeper great, is "good enough" for a large portion of the user base. As the BitKeeper developers found out, hosting the kernel project is an effective way to shake out scalability and usability problems. Whichever system ends up hosting the kernel can be expected to go through a period of rapid improvement.

BitMover did, in fact, get a few benefits from hosting the kernel, even if, in the company's view, the benefits do not come close to equaling the associated costs. BitKeeper is a more scalable and robust system as a result of the use it saw in that role. There were also substantial PR benefits; see, for example, this 2004 press release with nice quotes from David Miller and Linus Torvalds. There can be no doubt that working with the kernel has brought a great deal of visibility to BitKeeper, and that must have resulted in some new business. The cynical among us might conclude (and some already have concluded) that BitMover simply decided that it had obtained most of the benefits it was going to get from hosting the kernel and decided to move on.

Whether or not that is the case, it cannot be doubted that Linux, too, has benefited strongly from its association with BitKeeper. We would not have a 2.6 kernel with anything near its level of capability, scalability, and robustness without the role played by BitKeeper. One could easily argue that the free source code management systems would not be as good as they are had BitKeeper not come along. BitKeeper was a gift to the community that was well worth accepting; now that it is gone, the best thing to do is to say "thanks" (with sincerity!) and figure out what comes next.

Index entries for this article
Kernel	BitKeeper

---

to post comments

The kernel and BitKeeper part ways

Posted Apr 7, 2005 4:08 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

Interestingly Linus is not saying that he won't use bitkeeper, just that he is exploring the alturnatives.

I have no doubt that if he found that there was nothing else out there that he considered acceptable somebody would be willing to pay for a commercial bitkeeper license for him (if not some company, I'm sure that a fund setup for such a use would fill _very_ quickly).

Linus has said before that he's not willing to hald his work hostage to idealism (either in his tools or in other things, he is very practical) so it's a good thing that he's reviewing his options.

from what little I know I suspect that the options are not viable at this time, we'll see if a crash programming effort can get any of them useable fast enough (and if it does happen, everyone benifits), but don't assume that if they don't work out that Linus won't go back to useing bitkeeper for a while longer.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 4:37 UTC (Thu) by lilo (guest, #661) [Link]

On the other hand, the alternatives to BitKeeper continue to be developed. If one of them can do the job, it will certainly simplify life and remove some arguments and noise.

The kernel and BitKeeper part ways

Posted Apr 10, 2005 18:28 UTC (Sun) by smurf (subscriber, #17840) [Link]

Larry McVoy says that OSDL violates the BK license. Legally, the options you have in that case is to either fix your violation or cease using the licensed product. OSDL won't fire a contractor for what they do in their spare time (and rightly so, IMHO) (assuming I have my facts straight).

Therefore, presumably, OSDL and hence Linus can't use Bitkeeper any more.

NB: There option of "continue to use the product and wait whether the other party sues you" isn't applicable here; Bitmover can remotely turn off your BK when it asks for a lease. Besides, AFAIK the 65535-changeset bug is still not fixed in the free version.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 5:06 UTC (Thu) by JoeBuck (guest, #2330) [Link]

Oh, please. If Larry hadn't gotten the Linux kernel developers, or some other high-profile project, to use his product he would not have a company. Growing a business is tough, and he chose an excellent strategy to do it. There was no charity involved, though he might have felt that way sometimes.

Of course Linux benefitted; after all, Larry basically designed the thing according to Linus's specifications (as well as his own very good ideas). But in the early days, Larry needed Linus; now he doesn't need Linus anymore, so ta ta.

Of course any good ideas in BitKeeper that aren't patented will be cloned. And no, that isn't a social problem, and no, it isn't unique to open source; proprietary competitors will also seek the best ideas that they can use.

And there's a lesson: if you depend on a proprietary tool, you'd better have a contract in place that guarantees that the tool is around as long as you need it, or else have a contingency plan for dealing with your pain when your supplier withdraws the tool from the market.

Mutual benefit, painful parting, false martyrdom

Posted Apr 7, 2005 5:22 UTC (Thu) by jasone (subscriber, #2423) [Link] (2 responses)

The Linux community benefitted greatly from the change in process that was a result of using BitKeeper. BitKeeper even did a particularly good job of meeting the Linux kernel developers' needs (barring refusal by some to use it).

BitMover benefitted greatly from the testing and user feedback, as well as the PR value of having their product used by Linux kernel developers.

While it lasted, this arrangement had some very positive aspects. Now it's over, and the transition is likely to be painful. It's a disruption to kernel development, and it's very definitely generating some ill will toward BitMover. However, some of the benefits are going to survive. The kernel developers know now that there is a better way of doing things, and BitKeeper is a more solid product than it otherwise would have been.

Over all, everything above sits fine with me. What doesn't sit well is Larry McVoy's repeated attempts to cast himself as a martyr. BitMover benefitted significantly, and his attempts to quantify the value of the exchange as one-sided in purely monetary terms are in my opinion disingenuous interpretations of statistics.

Larry convinced Linus to move beyond tarballs. He had a tangible positive impact on the Linux development process. However, he'd do better from my perspective to simply consider this as a mutually beneficial arrangement that is over. He's not a martyr, no matter how much he feels like one.

Jason Evans

Mutual benefit, painful parting, false martyrdom

Posted Apr 7, 2005 7:31 UTC (Thu) by jwb (guest, #15467) [Link]

I would tend to agree with everything you wrote, and go further. Any measure of an exchange between a commercial entity and free software development communities which has money as its main focus is plainly fatuous. The free/open software phenomenon is predicated on the idea that the release of the software maximizes the benefit to everybody, or at least a very large group of people. Anyone who contributes does so because they expect to reap that benefit.

Then for anyone to come along, like McVoy, and make themselves a martyr by saying that the Linux community has taken their vast charity stabbed them in the back is ridiculous. McVoy is a rational actor and he made his decision that he was going to contribute BitKeeper and he would reap the benefit of good publicity and, more indirectly, a better Linux kernel. Think how ridiculous it would be if someone like (choosing randomly) Vixie was to come along and pull the plug on kernel.org, because someone at OSDL was starting up a competing internetworking business, and cry about how he tried to be charitable but look what those two-faced Linux people went and did? That would be absurd, and the present situation is equally absurd.

I'm really a disinterested observer on this topic, since I'm not involved in kernel development, or SCM development. But you can't ignore the shamelessness on display here. I always perceived that the clause in the BK license was intended as an escape for BitMover, and that, given the nature of hackers and hacking, its invocation was inevitable. Now that McVoy has used his escape, and presumably has got what he wanted from his contribution, he shouldn't be acting like the last three years were a unidirectional act of charity.

Mutual benefit, painful parting, false martyrdom

Posted Apr 7, 2005 18:16 UTC (Thu) by coolian (guest, #14818) [Link]

I couldn't agree more.

I own my own company and the PR that this generated has been doubly
fortunate for Larry. It's a genius move in the vein of Microsoft
licensing DOS to IBM.

He got the PR coming *and* going. The martyr part is laughable though,
since nobody really believes it, and it's so...*wink wink*

The kernel and BitKeeper part ways

Posted Apr 7, 2005 5:58 UTC (Thu) by allesfresser (guest, #216) [Link] (23 responses)

Um, excuse me, but I simply refuse to allow good people to be called "bad apples" because they refuse to use closed-source software. People who really do not get it at all, such as Mr. McVoy, would qualify for that label in my mind. This whole soap opera surrounding the BK license (as embodied in its colorful colloquial name mentioned in the LWN story) strikes me as a telling contrast to the stability of the GPL and the consistency and true openness of the FSF.

Personally, I wouldn't be surprised if suddenly we get some patent claims popping up trying to land-grab the whole concept of a source code control system... time will tell...

The kernel and BitKeeper part ways

Posted Apr 7, 2005 6:33 UTC (Thu) by massimiliano (subscriber, #3048) [Link] (22 responses)

Um, excuse me, but I simply refuse to allow good people to be called "bad apples" because they refuse to use closed-source software.

Well, IANLMcV, but IMHO he called "bad apples" those who instead of refusing to use the software, decided to break the license.

Now, I know "bad apple" sounds like name calling, but how would you define a community member that breaks a license?

The history of the BitKeeper "free" license is impressive: from almost OSI approved (source code provided, you must just keep the logging feature), to closed binary, to "don't work against us"... every change was the answer to somebody that didn't respect the previous license version.

So I really think that if nobody had broken the license[s], we would not be at this point now. And the whole community could still benefit from a "mostly free" BitKeeper (remember, the 1st license was almost OSI approved, you really had all the code!).

The kernel and BitKeeper part ways

Posted Apr 7, 2005 7:09 UTC (Thu) by khim (subscriber, #9252) [Link] (17 responses)

Well, IANLMcV, but IMHO he called "bad apples" those who instead of refusing to use the software, decided to break the license.

Clarification: they decided to ignore illegal and thus meaningless clause in license (this exact part is uneforceable in a lot of countries - and by good reason).

The kernel and BitKeeper part ways

Posted Apr 7, 2005 8:12 UTC (Thu) by Xman (guest, #10620) [Link] (15 responses)

Clarification: they decided to ignore illegal and thus meaningless clause in license (this exact part is uneforceable in a lot of countries - and by good reason).

Take a look at the license, if that clause is illegal then you throw out the baby with the bathwater: you don't have a license for the software.

In general the "it's unenforceable in a lot of countries" angle is silly. First, the relevant bit is what is enforceable in the relevant jurisdiction. Secondly, how would you feel about someone violating the GPL on the same principle?

The kernel and BitKeeper part ways

Posted Apr 7, 2005 10:41 UTC (Thu) by kleptog (guest, #1183) [Link] (8 responses)

Actually, a lot of contracts state something like: "if a particular clause is illegal where you are, then it doesn't apply to you". Precisely because of the baby/bathwater effect.

Say you sell a product somewhere in the world and the law changes there to make one of your clauses invalid. Without a clause such as the one above, your *entire* licence has been cancelled and is no longer binding. Most people would prefer to have some form of binding licence that does whatever is legal, than no licence at all.

I mean, would Microsft prefer to have their entire EULA killed because the reverse engineering clause was ruled invalid. No way, they'd like any and all the other clauses enforced to the fullest extent.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 20:15 UTC (Thu) by Xman (guest, #10620) [Link] (7 responses)

Yes, a lot of contracts do state something like that. Some jurisdictions make it impossible to impose a no reverse engineering clause. That's really nice to know, but we're talking about a specific situation here.

I fully support a developer who chooses not to accept the BitKeeper license and therefore doesn't use the software, and frankly I suspect Larry would too. It's another matter entirely to accept the license in bad faith as demonstrated in this case. In pretty much any jurisdiction that would qualify as fraud.

There are ways to fight for freedom that don't involve that kind of behavior, and we ought to encourage them and discourage bad practices.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 21:47 UTC (Thu) by ksmathers (guest, #2353) [Link] (1 responses)

The developer in question didn't accept the BK license or use BK as far as I know. The license violation, as far as it went, was directed at OSDL for employing a developer who, on the side, worked on a source control system. OSDL refused to get rid of the developer, so Larry terminated the license to OSDL.

Should OSDL have complied? Essentially Larry was dictating who OSDL could and could not employ, not on the basis of work actually paid for by OSDL, but on work done on the side. Larry argued that it was a violation of the license, and he has the right to control his own software, so I suppose it was. Still, I think it would cripple OSDL if due to license restrictions they could not employ relevant developers.

The kernel and BitKeeper part ways

Posted Apr 19, 2005 4:31 UTC (Tue) by beoba (guest, #16942) [Link]

"..and he has the right to control his own software.."

His software was not being modified.

If I view the HTML source to this site, am I hurting the HTTP server that sent it?

The kernel and BitKeeper part ways

Posted Apr 8, 2005 10:38 UTC (Fri) by daniel (guest, #3181) [Link] (4 responses)

"I fully support a developer who chooses not to accept the BitKeeper license and therefore doesn't use the software, and frankly I suspect Larry would too. It's another matter entirely to accept the license in bad faith as demonstrated in this case. In pretty much any jurisdiction that would qualify as fraud."

Don't be ridiculous. You are trying to call reverse engineering a) immoral and b) illegal. When you know perfectly well that it is neither, when done for the purpose of interoperability. Which is the case here.

There is a reason why reverse engineering is legal: it helps keep people from gaming the system.

The kernel and BitKeeper part ways

Posted Apr 8, 2005 21:22 UTC (Fri) by Xman (guest, #10620) [Link] (1 responses)

You are trying to call reverse engineering a) immoral and b) illegal.

Please try not to put words into my mouth. You got this from a quote which didn't mention reverse engineering. Indeed, the implication of what I was saying (and which I've stated more explicitly in other comments on this thread) was that I had no problem with a developer reverse engineering BitKeeper if they didn't accept the license.

I did suggest that accepting a license in bad faith is fraud, and I guess that's where you got the immoral and illegal from. I'm guessing you are throwing in with those who feel anti-reverse engineering license clauses shouldn't be valid, which is how that got in to it. Check the case history. You'll find that reverse engineering is not legal when it involved the breach of an implicit or explicit agreement between the parties involved or if improper means such as deceit are used to obtain the secret. The legal debate is about whether EULA's should be enforceable (UCITA clarifies that they are, but it still needs to be tested more in court), but if you like the GPL, you don't want to go down that path.

Now, if the developer in question accepted the license in bad faith and lied when explicitly asked to comply with the license, then that very strongly qualifies as illegal, and I'd be okay with throwing in immoral. If they didn't, then they aren't the "bad apple" Larry is suggesting they are. If you think it is legal and moral, then it follows that someone who accepted the GPL in bad faith, and lied when explicitly asked to comply with the GPL is also acting legally and morally. I for one, can't abide by that, and I'd be shocked if I was alone on that.

The kernel and BitKeeper part ways

Posted Apr 14, 2005 11:49 UTC (Thu) by forthy (guest, #1525) [Link]

I did suggest that accepting a license in bad faith is fraud, and I guess that's where you got the immoral and illegal from.

On the other hand, making a license which contains stuff that's not enforcible, is also immoral and illegal. That's why contracts that contain such stuff are not enforcible, and any good contract contains a clause that makes the contract valid even though (removing the "bad apples" in the contract).

Further note that when you get a legal copy of a software without contract/license, you still can legally use, reverse engineer, patch, and resell that software (given that you don't keep a copy - that's basic copyright stuff). If you obtain the software from the copyright holder, it is a "legal copy". That's why any EULA or other license absolutely should contain the phrase that no matter what rubbish there's written in it, the valid clauses still stay valid, because otherwise, the customer has a much better position.

In the end, I'm very happy that this BitKeeper stuff happend as it did. I didn't understand why Linus didn't use any source management at all for a long time (even though in the beginning, CVS would have been completely sufficient), and any free tool he had used long enough would have scaled into what he needs now. Now, we've just 10 years lost (for the first 5 years of Linux), and have to play fast catch-up. The result will probably be two or three free distributed source repository systems which are all capable to do more than we ordinary users ever want. And no one ever again will depend important free software work on a non-free software.

Note: I usually tell people about contract clauses I'm going to ignore (if there's a general "ignore the rubbish" clause), or that signing the contract is a waste of time (when there's not). In the latter case, my response to such a contract will be rather rude.

The kernel and BitKeeper part ways

Posted Apr 9, 2005 9:37 UTC (Sat) by daniel (guest, #3181) [Link]

if the developer in question accepted the license in bad faith and lied when explicitly asked to comply with the license, then that very strongly qualifies as illegal, and I'd be okay with throwing in immoral. If they didn't, then they aren't the "bad apple" Larry is suggesting they are. If you think it is legal and moral, then it follows that someone who accepted the GPL in bad faith, and lied when explicitly asked to comply with the GPL is also acting legally and morally. I for one, can't abide by that, and I'd be shocked if I was alone on that.

Your screed is peppered with big fat ifs that turn it into meaningless speculation and innuendo.

The kernel and BitKeeper part ways

Posted Apr 17, 2005 13:58 UTC (Sun) by Ross (guest, #4065) [Link]

But was the license actually accepted by this individual or is this just
one of the "you can't work for a company which has SCM products" and "you
can't employ people who work on SCM products" parts of the license?

It's hard to hold third parties to terms in an agreement made without them,
and employment is a very tricky area. You can't just fire people because of
a EULA.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 10:43 UTC (Thu) by rjw (guest, #10415) [Link] (5 responses)

If you have received software legally, you do not need a licence to use it, including reverse engineering. There is no requirement to accept an EULA. Please learn what copyright law is.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 12:43 UTC (Thu) by xanni (subscriber, #361) [Link]

Unfortunately this is no longer the case in Australia. After signing the so-called "Free Trade Agreement" with the USA, courts in Australia now interpret copying into RAM as "fixing in a tangible medium", which means that loading a program or data into memory is subject to copyright law and must be authorised by the copyright holder.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 15:27 UTC (Thu) by massimiliano (subscriber, #3048) [Link]

OK, but my main point was that the first license was almost OSI approved. It didn't even mention reverse engineering, you had all the source code! You were only required to make it pass all regression tests after modifocations, including sending the changelog to the public server.

It has been when somebody abused of this license that we took the slippery slope that in the end brought us here...

The kernel and BitKeeper part ways

Posted Apr 7, 2005 20:04 UTC (Thu) by Xman (guest, #10620) [Link] (2 responses)

Keep in mind open source software is frequently licensed through EULA's as well. The "legal" way that this particular person received BitKeeper, was through a EULA which included some restrictions on the use of the product. If the EULA is illegal, then this particular person had no legal means to obtain BitKeeper, which means they violated BitMover's copyrights in order to get the software. This is the same principle which protects the GPL.

licenses, contracts, and copyrights

Posted Apr 7, 2005 21:45 UTC (Thu) by giraffedata (guest, #1954) [Link] (1 responses)

I'd like to clarify some of the legal issues that have been misstated in this thread.

First, there are two entirely separate issues here: licensing under copyright law and contracts. You can't "break" a license, but you can break a contract. A license is never "binding" on a licensee, but a contract is binding on both parties.

You need a license from the copyright owner to copy something. You don't need to execute a contract with him. You don't need a license to use a copy the copyright owner gave you.

I'll take Xman's word for it that the mystery developer who spoiled it all got his copy from BitMover under a EULA (which is a contract) and assume that in the contract he promised not to reverse engineer. So copyright law and licenses have nothing to do with the controversy.

As for severability, if there's a law making the reverse engineering clause unenforceable, that law could easily also nullify any severability or backup clause, so we just don't know. Example: California has a law that says a loan contract of a certain type that states an interest rate of >10% is enforced as if it says 0%. The rest of the contract still applies. But if there's a clause that says if the interest rate is found illegal, then the loan must be repaid immediately, that clause gets wiped out by the same law. When people write laws to forbid people from agreeing to certain things, they don't mess around.

licenses, contracts, and copyrights

Posted Apr 8, 2005 0:18 UTC (Fri) by hppnq (guest, #14462) [Link]

Thanks, giraffedata! Some people should have this tattooed on their foreheads.

Reversed, of course.

The kernel and BitKeeper part ways

Posted Apr 13, 2005 8:24 UTC (Wed) by njhurst (guest, #6022) [Link]

As far as I can see, Tridge hasn't touched bitkeeper, so even the tenuous shrinkthrough licence laws don't apply. I don't understand why people keep missing this: Tridge never accepted the bk licence, so nothing in it has any relevance to him. The only issue is whether he should have reverse engineered something that was gifted to the community, knowing LM's propensity for dummy spitting. Considering the usefulness of samba, I think Tridge made a reasonable choice.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 8:08 UTC (Thu) by ronaldcole (guest, #1462) [Link]

> how would you define a community member that breaks a license?

Oh, I don't know... defendant?

The kernel and BitKeeper part ways

Posted Apr 7, 2005 9:34 UTC (Thu) by dan_b (guest, #22105) [Link]

every change was the answer to somebody that didn't respect the previous license version

And has the GPL changed to become more restrictive every time someone didn't respect the previous version? I think it's up to version 2 now, so if so I guess that means only one person has ever violated its terms.

Regardless of who was "at fault" for the licence changes, this does highlight the desirability of using software with licences that don't change. Whether it's fair or not, I would choose to avoid relying on software if my ability to use it can be withdrawn because of the action of some third party unrelated either to me or to the vendor.

"If one of you doesn't own up, you're all staying behind after class". Is that a good situation to be placed in?

Almost is not enough

Posted Apr 7, 2005 19:00 UTC (Thu) by GreyWizard (guest, #1026) [Link]

The difference between almost free and free is an important one, and the community is much better off without an almost free BitKeeper. The kernel development team will soon be providing feedback, patches and attention to one of the completely free source control systems, which will benefit everyone -- even people BitMover views as a competitive threat. We'll never know what would have happened had Torvalds chosen one of these technically inferior projects in the first place, but I find it hard to believe that a thousand or so sharp minds and ample funding from OSDL member organizations would have been unable to produce a kernel of similar quality to the one we have today. Either the kernel hackers would have worked around the limitations of the chosen tool, improved the tool or written their own from scratch -- there are examples of each approach in response to other problems in this process.

Assuming that the free BitKeeper product is being withdrawn because someone violated the terms of the license (and that isn't entirely clear) BitMover is within its rights to do this and it even seems like the best business decision they could make under the circumstances. Still, many people who have respected the license are now losing something they have come to depend on due to the actions of "bad apples" they cannot control. This is the return on their investment in a "mostly free" tool.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 22:36 UTC (Thu) by mbp (subscriber, #2737) [Link]

The question is whether any did actually accept the licence and then break it. From what has been written to date that doesn't seem to be true.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 6:17 UTC (Thu) by daniel (guest, #3181) [Link]

"We would not have a 2.6 kernel with anything near its level of capability, scalability, and robustness without the role played by BitKeeper."

Jon, I think that had more to do with Andrew Morton's steady hand and boundless energy.

Regards,

Daniel

The kernel and BitKeeper part ways

Posted Apr 7, 2005 6:33 UTC (Thu) by ekj (guest, #1524) [Link] (3 responses)

Larry just does not get it. And for once I think our editor is being overly nice to him.

A person working on developing a good, scalable, capable SCM is not in any way a "Bad apple". Even if he does so by reverse engineering a closed product the license disallowing, or attempting to disallow reverse engineering is the "bad apple". Indeed in many jurisdictions such a clause in a license is void.

Also, BitKeeper was very likely the best choise at the time, probably still is. But there's a second effect: choosing BitKeeper over one of the free tools has helped BitKeeper develop faster and that other free tool develop slower. Like you say: hosting the kernel is a wonderful way of shaking out bugs and scalability issues.

So, in other words, choosing some other free (as in speech) tool back then likely would've made the kernel-development somewhat slower, atleast initially, but on the other hand would've ensured that that tool improved quicker. It's not clear that this is such a clear win.

Furthermore -- on several points the critics have just been prooved rigth: Choosing a closed tool *does* give a single comercial entity the rigth to pull the rug out from under us at their discretion. One of the benefits of free software is precisely *not* to be in a situation where that can happen.

I think the whole thing is good, overall. Not because BitKeeper has helped us so much, but because it has showed a lot of people (including Linus) that sometimes free matters. I *very* much doubt that Linus would even consider a hypotetical new closed SCM with the same licence BitKeeper had when he once choose that.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 9:47 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (2 responses)

There might be another way forward.

Several companies have a lot to lose if kernel development is harmed (Redhat, Novell and IBM spring first to mind). At least two of those could offer to buy Bitkeeper with their petty cash, and re-open it, or at least revert back to an acceptably non-open state.

And if Bitkeeper is going to become totally closed ... nasty thought, but I wonder what IBM has got in their patent arsenal? Carrot *and* stick?

Just say ``no'' to patent wars

Posted Apr 7, 2005 17:47 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link]

[...] I wonder what IBM has got in their patent arsenal? Carrot *and* stick?

If software patents are evil, which I fervently believe, they are a means which no ends can justify.

(Of course, these ends (opening Bitkeeper) don't deserve any means.)

The kernel and BitKeeper part ways

Posted Apr 14, 2005 8:05 UTC (Thu) by xoddam (subscriber, #2322) [Link]

What, reward lm with a Porsche after leaving with his ball? Better to
invest the money in developing an already-free tool, or a whole class of
them.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 9:45 UTC (Thu) by hppnq (guest, #14462) [Link]

Excellent as always, Jon. Counting myself among the more cynical readers (I'd like to think of it as "not extremely naive" ;-) I must say I stand in awe of the way you consistently present the most complete, reasonable and intelligent observations in front of a hot-headed crowd.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 10:04 UTC (Thu) by wookey (guest, #5501) [Link] (2 responses)

Well, an interesting development. Who was the individual who refused to stop reverse engineering, I wonder?

I always refused to use BK because I didn't like the license (especially the 'no work on competing products' - that was the point at which I decided I was never going to use it). I have been involved in a couple of projects where there were strong network incentives to use BK (e.g. Openembedded), and I even do a bit of kernel hacking occaisionally. I was never very happy about the way this non-free software was becoming embedded in community development. I'm glad to see that period is over (well, hopefully), and I hope lessons are learned.

So I shall sit back and feel slightly smug and pure today :-) I didn't violate anyone's licenses and can claim to have been 'right all along', albeit somewhat incovenienced along the way.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 14:18 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

The version of events I've heard from the rumour mill is as follows:

1. Andrew Tridgell (of Samba fame) starts reverse engineering BK in his spare time.
2. BitMover asks OSDL to tell him to stop, as they believe it infringes their licence.
3. OSDL tell him to stop, making it clear that any work done on OSDL time is going to cost him his job; he continues working on it in his spare time.
4. BitMover tells OSDL that he's still hacking on it, and demand that he's told to stop.
5. OSDL turn round and say that he's not doing it on work time, so they can't do more to stop him.
6. BitMover tell OSDL to fire him or they'll withdraw the licence. OSDL refuse.
7. The licence is withdrawn.

Of course, this is all rumour, and backed up with as much evidence as you'd expect from rumour.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 16:02 UTC (Thu) by daniel (guest, #3181) [Link]

If true, would it mean that Andrew can now go full time on his reverse engineering work, for the purpose of, say, importing the BitKeeper graph into Bazzzr-ng?

The kernel and BitKeeper part ways

Posted Apr 7, 2005 14:07 UTC (Thu) by ballombe (subscriber, #9523) [Link] (1 responses)

> The open source client, incidentally, enables the extraction of the current version from a repository

Where is that "open source" bitkeeper client ? The 'No whine license' is not a open source license. If Bitmover was serious about it, they would have used a standard opensource license like BSD or GPL.

The 1999 link is very interesting. It show there is a pattern of difference between advertised licensing and the final license.

> If BitKeeper users were violating the license under which they received the software,

Copyright law does not allow licenses to forbid reverse engineering, so there was no license violation in the first place.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 18:27 UTC (Thu) by vmole (guest, #111) [Link]

1. Larry said in the LKML that the "no-whine" license was joke, and that the real license was BSD, or even public domain. I don't know if there was ever an updated tarball with a BSD license in it, though.

2. Licenses most certainly are allowed to forbid reverse engineering. What you're thinking of is that making a copy for the purpose of reverse engineering is not a violation of copyright law, which is true. See http://www.chillingeffects.org/reverse/ for an explanation and more links.

More info on OSS/FS SCM tools

Posted Apr 7, 2005 14:20 UTC (Thu) by dwheeler (guest, #1216) [Link] (2 responses)

See Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) Systems for some comments on the available OSS/FS SCM tools.

Don't forget ArX

Posted Apr 7, 2005 22:55 UTC (Thu) by kevinbsmith (guest, #4778) [Link]

That page is a great resource. Thanks for creating and maintaining it.

I'm glad to see that ArX is mentioned briefly, but I'm still slightly puzzled about why ArX gets so little attention. It solves many of the same GNU arch problems as Bazaar-NG, but is much more mature.

I'm not in a position to judge whether or not ArX is capable of handling the kernel tree at this point. But it may be at least as close as monotone or darcs.

http://www.nongnu.org/arx/

[Disclaimers: I have played around with ArX some but have not yet had a chance to use it heavily. Based on quite a bit of research and experimentation, I like ArX better than the alternatives. So I am helping the ArX project by maintaining the web page shown above, and doing a little evangelizing.]

More info on OSS/FS SCM tools

Posted Apr 9, 2005 1:33 UTC (Sat) by mongre26 (guest, #4224) [Link]

Good review, but unless you are a time traveler your revision date is a bit off. :)

"by David A. Wheeler
April 10, 2004; lightly revised April 10, 2005"

My clock says Apr 8 2005. Well maybe Sat Apr 9 GMT 2005 but still not the 10th.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 14:27 UTC (Thu) by TwoTimeGrime (guest, #11688) [Link] (16 responses)

What I don't understand is why were people were reverse engineering the BK protocol in the first place. Linus already said he would consider another tool if it would do what BK would do. No version control system appeared with the features he needed. Instead of reverse engineering the protocol why not create a replacement? Detailed feature lists for BK are ont he bitmover site. Even the entire user's guide is online for anyone to read. There's all you need for your functional spec right there.

What saddens me most is the demonstration that certain people are not going to respect the licenses of others. How can you ignore their license and expect people to sprect *your* license when you release software?

The kernel and BitKeeper part ways

Posted Apr 7, 2005 16:06 UTC (Thu) by daniel (guest, #3181) [Link] (14 responses)

"What I don't understand is why were people were reverse engineering the BK protocol in the first place. Linus already said he would consider another tool if it would do what BK would do. No version control system appeared with the features he needed. Instead of reverse engineering the protocol why not create a replacement?"

Simple. There are three years of revision history locked up in BitKeeper repositories. That information is ours, we want it back. (In a less charitable mood I'd insert "told ya so" at this point.)

Regards,

Daniel

The kernel and BitKeeper part ways

Posted Apr 7, 2005 17:42 UTC (Thu) by jee (guest, #202) [Link] (3 responses)

But with the BKCVS gateway, that history is available, isn't it? As in, all the information the users put in there, including comments and so on.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 17:59 UTC (Thu) by jonabbey (guest, #2736) [Link] (1 responses)

Including file renames and moves?

The kernel and BitKeeper part ways

Posted Apr 7, 2005 20:24 UTC (Thu) by lm (guest, #6402) [Link]

Yes, it includes file renames, go look at the data.

The kernel and BitKeeper part ways

Posted Apr 8, 2005 16:45 UTC (Fri) by daniel (guest, #3181) [Link]

"But with the BKCVS gateway, that history is available, isn't it?"

So if you have set up a BitKeeper repository for yourself (complete with "open logging") then how do you set up a BKCVS gateway from it? Oh you can't?

Regards,

Daniel

The kernel and BitKeeper part ways

Posted Apr 7, 2005 21:21 UTC (Thu) by TwoTimeGrime (guest, #11688) [Link]

> Simple. There are three years of revision history locked up in BitKeeper
> repositories.

It's not locked up. It's been in CVS all along.

The kernel and BitKeeper part ways

Posted Apr 8, 2005 16:36 UTC (Fri) by bronson (guest, #4806) [Link] (7 responses)

So the ends justify the means? Careful, Daniel... If you're right, then the GPL is toast. So it's a good thing you're wrong. (and quite hypocritical it would appear...)

The kernel and BitKeeper part ways

Posted Apr 8, 2005 17:07 UTC (Fri) by daniel (guest, #3181) [Link] (6 responses)

"So the ends justify the means? Careful, Daniel... If you're right, then the GPL is toast."

Don't be disingenuous. There is nothing wrong with the "means" here. Reverse engineering is perfectly legal.

"So it's a good thing you're wrong."

According to you.

"(and quite hypocritical it would appear...)"

I resent that.

The kernel and BitKeeper part ways

Posted Apr 8, 2005 23:26 UTC (Fri) by bronson (guest, #4806) [Link] (5 responses)

Oh, I thought you were explaining why breaking bk's license agreement is justified. Typically, if a clause in a contract is illegal, the entire contract is void and must be renegotiated. I haven't read BK's license (who can keep up with the changes?) so don't know if they included language to change this. The point is, if you agree to a license, it's a bad idea to turn right around and knowingly break parts of it.

If you're ONLY justifying reverse engineering then that's OK and I take back the hypocritical stab. :)

The kernel and BitKeeper part ways

Posted Apr 9, 2005 9:29 UTC (Sat) by daniel (guest, #3181) [Link] (4 responses)

The point is, if you agree to a license, it's a bad idea to turn right around and knowingly break parts of it.

How do you know whoever it was agreed to the license?

The kernel and BitKeeper part ways

Posted Apr 10, 2005 2:09 UTC (Sun) by bronson (guest, #4806) [Link] (3 responses)

Because that's the only legal way to have a copy of the software.

I suppose it's possible that you could sniff the wire while a properly licensed copy did transactions over it but that's starting to get real shaky...

The kernel and BitKeeper part ways

Posted Apr 10, 2005 2:40 UTC (Sun) by daniel (guest, #3181) [Link] (2 responses)

Because that's the only legal way to have a copy of the software. I suppose it's possible that you could sniff the wire while a properly licensed copy did transactions over it but that's starting to get real shaky...

How do you know that the engineer did not just connect to a BitKeeper repository and try to make it talk by pure trial and error?

The kernel and BitKeeper part ways

Posted Apr 13, 2005 8:38 UTC (Wed) by njhurst (guest, #6022) [Link] (1 responses)

Particularly if that someone has a history of reverse engineering things from the outside (samba, tivo etc). I spent a little time working with tridge a long time ago and he's neither vindictive/zealotous nor is he naive when it comes to licences. I have no trouble believing him capable of doing what he did without touching the client, and I don't imagine him willingly using bitkeeper with the knowledge of the licence.

The kernel and BitKeeper part ways

Posted Apr 17, 2005 17:57 UTC (Sun) by alext (guest, #7589) [Link]

More recent reports show he (Tridge) didn't use BK in his reverse engineering and did not accept the license (no need as he wasn't installing or using BK) and the reports go on to point out that he is doing exactly what he did for Samba (for which he is celebrated like a hero).

The kernel and BitKeeper part ways

Posted Apr 10, 2005 19:54 UTC (Sun) by smurf (subscriber, #17840) [Link]

Reading the repository is simple, it's a souped-up SCCS format. Reading that isn't something the Bitkeeper people are able to notice in the first place, plus it's comparatively simple, and so is getting out the metadata. You don't need to generate test files for that, just look at any files in the Linux kernel tree.

What the reverse-engineering job obviously was about (at least from my remote-viewing crystal ball PoV) is to figure out the protocol used to pull changes form one repository into another. *That* shows up on openlogging.org, especially when you do it 100 times in a row to figure out which changes trigger which protocol events (a classic reverse engineering technique certain people should be *very* familiar with, if the rumor is to be believed).

The kernel and BitKeeper part ways

Posted Apr 7, 2005 22:26 UTC (Thu) by giraffedata (guest, #1954) [Link]

How can you ignore their license and expect people to respect *your* license when you release software?

I can at least answer the philosophical question. It's the same way a person can be against murder but for the death penalty. Or rely on a zoning law preventing his neighbor from operating a rendering plant while ignoring a law telling him in what positions he may have sex.

The reverse engineer simply determined that the reverse engineering promise that was extracted from him was immoral and the promisee didn't deserve performance. But his own license conditions are pure, so he has every right to expect them to be respected.

The kernel and BitKeeper part ways

Posted Apr 7, 2005 16:08 UTC (Thu) by parimi (guest, #5773) [Link]

Thanks, Jon for such a detailed article on BitKeeper. I never knew the exact purpose of BitKeeper, but you cleared up the facts!

Free version of Bitkeeper?

Posted Apr 15, 2005 20:25 UTC (Fri) by anton (subscriber, #25547) [Link]

There is no free version of Bitkeeper in the free software sense.
Larry McVoy is apparently focused on money, and that's why he calls the pay-with-freedom version of Bitkeeper "free", but LWN should not follow this usage.

The kernel and BitKeeper part ways

Posted Apr 16, 2005 21:17 UTC (Sat) by wolfrider (guest, #3105) [Link]

Thanks for this article; it's one of the most sympathetic to LM/BK that I've seen so far.

Some people just don't understand what it's like to try and run a business while trying simultaneously to help "the community."

I'd like to take this opportunity to publically thank Larry and his company for their efforts, and wish them well in the future.

Wolfrider