Certain subjects return to these pages over and over again; one of those,
certainly, is the BitKeeper
management system. Despite concerns about its proprietary nature,
BitKeeper has become the tool of choice for many Linux kernel developers.
Those who are concerned about BitKeeper use for kernel development found
new flame fuel in a previously unnoticed clause in the BitKeeper license
, version 1.38, which
Notwithstanding any other terms in this License, this License is
not available to You if You and/or your employer develop, produce,
sell, and/or resell a product which contains substantially similar
capabilities of the BitKeeper Software, or, in the reasonable
opinion of BitMover, competes with the BitKeeper Software.
The purpose of this clause is to say "you can use BitKeeper free of charge,
but only if you are not using it to develop a competitor to BitKeeper." It
is arguably a reasonable licensing clause; regardless of what one thinks of
BitKeeper or proprietary software in general, BitMover can not be expected
to willingly provide its tools for the purpose of creating new
And BitMover does fear this competition. Many years of effort went into
the development of BitKeeper and the associated business; the creation of a
suitably capable free replacement could wipe out that investment in a short
time. BitMover founder Larry McVoy believes that the free software
community is not capable of creating from scratch a source management
system of BitKeeper's quality and with BitKeeper's innovations. He does,
however, think it could produce a clone that, while inferior, is good
enough to cost BitMover a lot of business. Coming up with ideas in the
first place is expensive; copying them is far easier. BitMover wants the
space to earn something from its (expensive) efforts to create BitKeeper;
it also wants to be able to develop the product into a far more capable
tool, a task requiring, they think, about four years. They have stated
their intention to fight back with every weapon at their disposal -
including copyright and patents - against anybody who threatens their
ability to carry out that plan.
Is all this a problem for free software and the Linux kernel? It could be,
but probably not on the scale that some people fear. The immediate concern
with the clause quoted above is that a number of free software developers
and companies do deal with other source management systems. In the case of
developers, the situation is fairly clear: if you work on a free source
management system, BitKeeper is not available to you. To emphasize the
point, Larry McVoy publicly told Ben
Collins, a kernel FireWire driver developer (and Subversion hacker) that he could
not use BitKeeper:
And you made it clear that you'd be delighted if Subversion was
made good enough to replace BK and you were working towards that
goal. I can't imagine a better example of someone who we
absolutely do not want to support and do not want using BK. I am
explicitly stating that it is our view that your use of BK is
violation of our license.
Ben's kernel work will not be affected, since he was not using BitKeeper
for that project. Other kernel developers could eventually run afoul of
this rule as well, however. For example, the ReiserFS team has no end of
ambitious plans for its filesystem; some of them, such as version
management, begin to push into BitKeeper's turf. Larry told us that, in
his opinion, it was "very likely" that ReiserFS would eventually cross the
line and become a BitKeeper competitor; at that point its developers would
be unable to use BitKeeper.
That is about as far as it goes, however. The license, says Larry, went
too far by excluding anybody whose employer works on source management
systems. The next "debugging" release of the license will tighten that
term so that it only affects developers working directly on source
management, and, perhaps, those very close to them. Thus, for example, Red
Hat developers will not lose their access to BitKeeper just because Red Hat
puts some patches into CVS. It is also BitMover's position the Linux
kernel developers as a whole will not lose
their BitKeeper access even if Linus merges a version of ReiserFS which
costs the ReiserFS team its access.
In evaluating the whole BitKeeper controversy, it is worth remembering a
few things. One is that BitMover could have avoided all this pain simply
by never giving gratis access to its product. Other vendors of commercial
source management systems do not make their products available for
free-of-charge use, and they are not routinely flamed the way BitMover is.
BitMover, instead, has chosen to make its product freely available to
groups developing free software. Kernel development has benefitted from
this gift in a number of ways:
- The capabilities of BitKeeper are much appreciated by developers who
choose to use it. BitKeeper really does make a lot of things easier,
especially in a distributed, multi-developer environment.
- Linus is merging patches at a tremendous rate, and appears to be far
less stressed than before. Patches still get dropped, but on a much
smaller scale. The process, by all appearances, is working more
smoothly than it has in a long time.
- Anybody who is interested can see the state of Linus's development
tree in near real time. There is no longer any need to wait for
prepatches or full releases. Thanks to BitKeeper, a new development
kernel is released many times a day. As an added bonus, Linus is now
able to post automatic changelogs as well, eliminating the need to
read through each release to see what patches were included.
It is also worth pointing out that nobody has been forced to use
BitKeeper. Many top-tier kernel developers have chosen not to use it, and
they have not had to change their ways of working. Getting repositories
and patches into and out of BitKeeper is easy by design; BitKeeper has a
stated "no lockin" policy. It is not even
necessary to use BitKeeper to keep track of Linus; several sites (like this
one) provide frequent access to the updates in his tree.
In other words, the adoption of BitKeeper has brought good things to
anybody who uses the Linux kernel. This has happened free of charge, with
no visible costs of any significance. Except, perhaps, for the time lost
in flame wars. Access to BitKeeper is a gift that its creator was under no
obligation to make. It is unfortunate that some members of the community
expend so much effort criticising those who have made that gift. It is
hard to see how the free software community would be better off if
BitKeeper were withdrawn.
All this is not to say that there is no reason for vigilance and concern.
The denial of access to some developers is a discriminatory action, to say
the least. If Larry McVoy (or his board of directors) wakes up hung over
one morning and decides to
end free access to BitKeeper, the show is over. Larry is uninclined to do
that - he has maintained free access despite the constant flames because he
wants to support the kernel project. But Larry could have an unfortunate
encounter with a bus (though, as Linus has pointed out, buses are rare in
California), or BitMover could be acquired by another company; in either
case, the new management could make changes to the license. The BitKeeper
binary does not come with source; it could be doing no end of evil things
and it would be difficult for people to know. Currently, BitKeeper makes
it easy to extract all data and metadata from a repository; moving an
entire repository into a different
source management system is an easy task. Linus also uses the BitKeeper
interfaces to export patches and tarballs in the same way he always has.
Future versions of BitKeeper, however,
could quietly shift over to a closed format that is harder to escape
And so on. These are issues that come up with any proprietary package, and
they are certainly no worse than the issues raised by that other
proprietary source management platform which is even more heavily used in
the free software community: SourceForge. In the end, people who use
software should always look at the license, and not use a particular
package if the license is not to their taste. In the case of BitKeeper,
those who chose not to use it are no worse off than they were before, and
an easy path is open should a quick evacuation to another source management
system be required. BitKeeper is worth watching; one never knows where a
company might decide to go tomorrow. But the situation at the moment is
not that bad.
Comments (28 posted)
As of this writing, there are almost 1800 subscribers to LWN.net; we have
also sold a small number of (small) corporate subscriptions. This level of
support is almost sufficient for two full-time staff at minimal salaries - a
huge step in the right direction, but still not enough to keep LWN going in
its current form. While we hope and expect that the number of subscribers
will continue to grow, we will have to take steps to live within our
available means for the near future. It is fully our intent to deliver on
the full term of the one-year subscriptions that many of you have bought;
to do that we will have to be careful now.
So there will be some changes to LWN. We're working on the details now,
and will post another update soon. But it looks like LWN is
here to stay, and that is good news. Let it never be said that the free
software community is unwilling to support the services it finds valuable.
A few other notes:
- We have tracked down and solved the problem that was causing cookie
problems with a number of browsers - especially Internet Explorer. If
you have experienced trouble in the past, please try again; things
should work better.
- There have been some complaints that our initial subscription screens
are not as informative as they could be. We'll be reworking the
subscription information soon to address those concerns. Various
other glitches in the subscription system (i.e. changing between
monthly and fixed-term subscriptions) will also be fixed soon.
- We have, finally, managed to extract the last of the donation money
(from last July!) from our previous credit card processor. Happily,
our new processor seems to be far more, um, together, and has not yet
given us any trouble.
- Occasionally somebody asks what happened to our old donation screen.
That screen has been taken down for a couple of reasons. One is to
keep our new credit card processor happy - donations seem to be a
hot-button issue for those people. The other is that we are trying to
transition into a real business, which offers direct value for the
money received. For people who would like to send more money our way,
we'll work out a new way to take it - no need to worry.
- For those of you who are unwilling or unable to buy a subscription,
we have set up a new mailing list that sends out a daily notification
whenever a subscription article becomes freely available. To receive
these notifications, you can sign up via the "My Account" screen for
- We're a little behind on some of our subscription-oriented mail. Once
the Weekly Edition is out, we hope to get caught up again.
As always, thank you all for supporting LWN.net.
Comments (13 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: The sendmail trojan; new vulnerabilities in apache, evolution.
- Kernel: Watching Linus; LinuxKernelConf; Unexporting <tt>sys_call_table</tt>.
- Distributions: Red Hat Trademarks; Lots of reviews
- Development: PostgreSQL 7.2.3, CUPS v1.1.16, Apache 1.3.27, Quixote 0.5.1,
Procps 2.0.10, GStreamer Pipeline Editor 0.2, WaveSurfer 1.4.5,
Rosegarden-4-0, KDE 3.1beta2, FLTK 1.1.0, KVim 6.1.141, Python 2.2.2b1.
- Commerce: TowerGroup: Linux gaining in financial firms; W3C board votes for royalty-free patent policy
- Press: Geeks and Hackers, patenting the Web, Evesham sells Lindows PC,
WindowsRefund.net, ExxonMobil Travel Guide using Linux, Linus interview.
- Announcements: Swedish Cluster Conference CFP, Australian educationaLinux 2003 CFP,
Perl Journal struggles.
- Letters: BitKeeper license; Apache and Red Hat; Copyright and consumer's rights