Linux Weekly News, BitKeeper Feature

Linux Weekly News
Contact us

Not quite Open Source
Larry McVoy is out to change the way cooperative software development is done, and he may just pull it off. But he also seeks to make a living from his work, and his way of achieving that goal has put him in conflict with the Open Source Definition. His novel way of extracting revenue from proprietary software developers may well fund the creation of a great new free software tool, but it also has shown that "Open Source" is not everything.
Some background is in order. Larry has built up an impressive résumé over the years, with stints at places like SCO, Sun, SGI, and Cobalt. Much of that time has been spent hacking on one kernel or another, and, at Sun, putting together configuration management tools. So when he set out to create a new free tool to address some of the problems that have come up in the Linux kernel development process, he had a lot of experience to bring to the task.
The result, a system called BitKeeper, is now nearing readiness. BitKeeper provides all of the features of systems like SCCS or CVS, and a lot more. BitKeeper was designed from the beginning to work with multiple source repositories, and to facilitate moving patches from one repository to another. Included are some nice graphical tools for managing and merging patches. To learn more, see the BitKeeper web pages.
Larry's stated goal is to have every free software project using BitKeeper within a few years. He may just get there. The multiple repository scheme is designed to work well with large, globally-distributed development teams. The patch management allows for the handling of changes, and for filtering these changes on their way up to the "master" repository. In the Linux kernel case, this means that Linus can benefit from much greater peer review of patches before he has to see them. With some luck, the result should be a reduction in the number of "Linus does not scale" burnouts that have occasionally halted kernel work in the past.
As part of Larry's approach to world domination, he intends that BitKeeper be freely available for any free software development team that wants it. That includes source availability, ability to distribute modified versions, etc. But Larry also wants commercial software companies to use his system, and he would like for them to pay for the privilege. After all, he estimates that about four person-years of effort have gone into the development of the system; it would never have happened without some expectation of a return on that investment. And it's his way of getting them to pay that has put him in conflict with the Open Source Initiative.
To understand the problem, it's necessary to understand two features of BitKeeper and its license. BitKeeper includes a logging feature. Once multiple repositories are in use, BitKeeper will log all changes to a central server; these logs will be made available via a web page. Thus anybody can go to the web site and see what's happening with any development project out there which is using BitKeeper.
BitKeeper's license allows for modifications, but under one restriction: all modified versions must pass a regression test. Other free systems (i.e. perl) have regression tests in their licenses, but a modified version which is unable to pass the test simply loses the right to use the original name. Versions of BitKeeper which fail the test may not be used at all. And yes, the regression test checks to be sure that the logging feature has not been removed or disabled. If you turn off the logging, you violate the license.
The reasoning behind this move is the following: Larry believes that free software projects want their work to be in the open anyway, and will not be bothered by the logging. Since the logging only kicks in when multiple repositories are used, individuals using BitKeeper to manage their diaries will not be affected. Proprietary vendors, instead, are not likely to be happy with having their change log messages broadcast to the world. For them, this restriction will probably make the system unusable.
At this point Larry shows up with a deal: the commercial version of BitKeeper doesn't do public central logging - you can direct the logging to an internal server. Pay the price, and you can use the system with your privacy intact.
There are a number of other features to the BitKeeper license. Subsections of the code - generally library modules that could be useful elsewhere - will be available under the GPL. If the logging servers go away, or if work on the system stops for two years, the whole thing goes GPL.
But that is not good enough for the "Open Source" designation, because the regression test requirement breaks the rules. Larry discussed the issue at length with the OSI folks, and was not able to get them to bend on the issue. He has since given up. BitKeeper is not Open Source.
The interesting thing is that, on a list for kernel hackers who intend to use the system, nobody really cares all that much. Even members of the OSI board have posted there, saying that the license is a good one, and that the lack of the "Open Source" designation should not be a problem. BitKeeper is free enough for that crowd, and they tend to be pretty fussy on these things.
So we have a situation where a license widely regarded as "free enough" does not qualify for [what is supposed to be] the free software community's mark of recognition. We may be seeing the future here: more "commercially crippled" licenses may well appear as more developers try to make a go at making a living from free software. When a lot of "free enough" software is no longer "Open Source," what becomes of the certification mark? Will people care about it any more?
Maybe the OSI should consider adopting a multi-tier designation. The top tier could be reserved for fully free code - perhaps with an even more restrictive set of criteria than what they have now. Lower levels could then be used to recognize software which is "free enough," but which does have some restrictions. Doing so could help the community distinguish between the incredible number of software licenses which are coming out, and could also help to preserve the relevance of the Open Source certification mark.