Leading items
A pair of acquisitions
While much of the commercial world was watching the initial public offering of VMWare stock, a competitor was carefully pushing forward a different strategy. On August 15, Citrix announced its acquisition of XenSource, the company formed to commercialize the Xen hypervisor. At $500 million, it is a pricey purchase - Citrix guesses that XenSource will bring in $50 million in revenue in 2008, but at a cost of $60-70 million. So profits from XenSource, in the near term, will be virtualized as well; perhaps the plan is to make it up in volume.Those who fear that money cannot be made with free software might take comfort in a half-billion dollar acquisition of a free software company. Of course, XenSource is far from a pure free software operation. The kernel-level code is GPL-licensed, as is required; much of that code has recently, after a long delay, found its way into the mainline kernel. But the upper layers - the code for the management of virtualized systems - is highly proprietary. It is offered in a three-tier scheme, with the more expensive products un-crippling larger numbers of features. These products are where the revenue comes from.
This acquisition is somewhat indicative of what is happening in the virtualization market. The low-level functionality is free, and is getting steadily more capable. But the tools for the administration of virtualized systems - a task of daunting complexity for sites running large numbers of virtual guests - are generally proprietary. It is the offerings at this level which give XenSource its value despite the fact that Xen's kernel-level support is increasingly surrounded by capable and arguably better-designed alternatives. For all practical purposes, the XenSource acquisition is just the purchase of yet another proprietary software company, Xen's free software origins notwithstanding.
Perhaps more interesting is the acquisition of the ClamAV project by Sourcefire, the company behind the Snort intrusion detection system. ClamAV, a virus scanner, is a true free software project which, previously, had lacked a commercial component. Details have not been disclosed, but one assumes that the owners of ClamAV did not make out quite as well as the holders of XenSource stock. They did get jobs out of the deal, though; they will now continue their ClamAV work as Sourcefire employees.
Who the owners are is, in this case, an interesting question. Projects led by developers with commercial ambitions typically require copyright assignments for any outside contributions. With ownership of 100% of the code base, selling a project (or taking it proprietary) is a relatively straightforward operation. ClamAV, however, is not one of those projects, and all contributors retained their copyrights. So Sourcefire does not own the entire ClamAV code base (or the equally important virus signature database). What it has acquired is the copyrights held by the primary contributors - a large part of the project, but not the whole thing.
This ownership structure could be a bit of a challenge for Sourcefire going forward; part of the plan for making money from this deal involves making a commercially-licensed version of ClamAV available for vendors who wish to integrate ClamAV into their products without being bound by the GPL. To make this offering possible, Sourcefire will be digging through the code and the source code management system to weed out any code which it cannot relicense. If the developers involved have an accurate idea of how much code is involved, if they are thorough in eradicating it, and if they do not anger any outside contributors to the point that they wish to create trouble, this scheme could go well. If a misstep is made somewhere, the possibility of legal action and other unpleasant consequences is very real.
For now, the stated plan is to continue to keep the entire code base and signature database available under the GPL. Sourcefire's Mike Guiterman says that the ClamAV user community has nothing to worry about:
It has been pointed out, though, that there is a bit more to Sourcefire's track record than stated above. Snort releases may happen "in lock step," but anybody who has not bought a Snort rules subscription must wait 30 days for rule updates. Like Snort, ClamAV uses a frequently-updated set of rules which are compared against incoming traffic to detect threats. So it would seem that the ClamAV signature database would be very much amenable to the same commercial treatment; that is, after all, how a number of other anti-virus companies do business.
For now, though, all of the indications are that Sourcefire will not be creating a subscription service around ClamAV signature updates. Quite possibly the company feels that one reason for ClamAV's success is the presence of a wider community which can contribute those updates; putting signature updates behind a subscription gate would almost certainly cause community contributions to dry up. Rather than risk damaging the project it just bought, Sourcefire may have decided to seek revenue in other directions - for now, at least.
With sufficient care, Sourcefire should be able to keep the ClamAV community together - and, perhaps, help it to grow further. Acquisition of a free software project is almost certain to bring change, but that change need not be bad. As we head steadily toward World Domination, we may well see more of these deals. One can only hope that the companies carrying out these acquisitions understand well that, in the absence of the wider community, all they can acquire is a lump of code. Preserving the value of a project acquisition requires preserving the community that goes with it. As long as this important fact is kept in mind, acquisitions can be ultimately beneficial to the affected projects and free software as a whole.
Large projects and decentralized development
Development using Git, with its decentralized model, is gaining proponents for projects beyond its Linux kernel heritage. Some recent threads on the kde-core-devel mailing list have been discussing how Git might be used by some developers without disrupting the Subversion (svn) infrastructure that is used by KDE. That conversation has broadened to consider how a large project like KDE might reorganize to take advantage of Git's strengths. It does not look like KDE is really considering a switch – they converted from CVS a little over two years ago – but the discussion is useful to anyone thinking about using Git.
There are really two separate discussions taking place, the first concerns using Git without disrupting svn, while the second covers the larger issues of how to structure and use Git for a larger project. The two are intertwined as the "best practice" for a KDE-sized project is to convert incrementally. Smaller sub-projects, a particular KDE application for example, would use Git while still committing the changes back to the svn repository. Trying to do a wholesale conversion of a project the size of KDE, with many developers, testers, translators and users – not to mention millions of lines of code – would be something approaching impossible.
For tracking an svn repository, while using Git locally, the git-svn tool is indispensable. It uses any of the svn protocols to check out a repository, optionally including branches and tags, and installing them as a Git repository. A developer then uses Git commands locally, using git-svn again when ready to update from or push changes to the svn repository. It is not a perfect fit, complaints about losing history in the conversion have been heard, but it does provide Git users a way to interact with svn.
The decentralized nature of the Git development model is always a stumbling block for projects that are used to the single, central, repository model of svn and other revision control systems. Adam Treat invited a rather well-known expert on Git, with some small experience in applying it to large projects, to comment on some of the questions he and others had. Linus Torvalds, who is also a KDE user, responded, at length, with some very useful insights.
Breaking the project into sub-projects is the first step:
Using the git-submodule command, a project can be broken up into many pieces, each with their own Git repository. Those separate repositories can then be stitched together into a "superproject" that understands how to handle a collection of repositories. If a change affects multiple modules, it can still be handled in an atomic way:
See? It's totally atomic. Anybody that updates from the supermodule will get one supermodule commit, when that in turn fetches all the submodule changes, you never have any inconsistent state.
Users of a development tree have differing needs, which Git supports by not requiring a central repository that all users must interact with. Torvalds believes that the development organization, not the tool, should determine which repositories are central:
But that should not be a *technical* distinction, it should be a *social* one, if you see what I mean. The reason? Quite often, certain groups would know that there is a primary archive, but for various reasons would want to ignore that knowledge.
For Linux, his kernel Git tree is the center, but for a variety of other users, the "stable" tree or distribution kernel trees for example, their repositories are the source. Those repositories can and do update from time to time from the main tree, but they control when and the users of those trees don't have to care.
On the subject of mapping the current KDE practices to Git, Torvalds is, characteristically, not shy about expressing his opinion:
Centralized _works_. It's just *inferior*.
There is a clash of development models going on and Torvalds is pushing the kernel's model. His reasons are good, though they may not convince everyone, which is why Git tries hard to avoid forcing any particular style. As he did with open source development, Torvalds is trying to lead by example, while not forcing anyone to change.
Reading the full threads including the entire posting by Torvalds will be very interesting to those who follow source code management issues. This culture clash, centralized and somewhat bureaucratic versus decentralized and freewheeling will come up again and again over the next few years. Torvalds seems to think the Git model will work most everywhere and his track record for making smart choices is good. It will be interesting to watch.
Microsoft's licenses: excerpts from a conversation
Microsoft recently submitted two licenses to the Open Source Initiative to be considered for approval as being truly open source. There have been a few themes which have come out of the subsequent discussion. One is that the licenses are generally seen as being compliant with the Open Source Definition, though their incompatibility with other licenses bothers a few people. Not everybody agrees that the Microsoft Permissive License (MS-PL) is truly "permissive," and some have asked for a name change. There have been some grumblings that the licenses offer no additional value in a time when the OSI is actively trying to reduce license proliferation.But, as can be seen below, the heated part of the conversation was about a different topic: can and should the OSI judge a license based on its origin? Without further ado...
a) Stop using the market confusing term Shared Source
b) Not place these licenses and the other, clearly non-free , non-osd licenses in the same place thus muddying the market further.
c) Continue its path of spreading misinformation about the nature of open source software, especially that licensed under the GPL?
d) Stop threatening with patents and oem pricing manipulation schemes to deter the use of open source software?
If not, why should the OSI approve of your efforts? That of a company who has called those who use the licenses that OSI purports to defend a communist or a cancer? Why should we see this seeking of approval as anything but yet another attack in the guise of friendliness?
Except I wouldn't, really, because then the OSI would lose every shred of credibility and quickly become irrelevant - just like it would if it failed to carefully consider the licenses submitted by Microsoft, or to approve them if they were found to adhere to the OSD.
That said, I personally would be in favor of approving the Microsoft licenses. I think it is overall a benefit to the community to acknowledge that code under these licenses is open source.
I think not. Not if he wants to have any chickens. A fox in a chicken suit is still a fox and is still planning to eat his chickens. So only a stupid farmer would reason that a fox in a chicken suit, even one made from real chicken feathers, should now be allowed to reside in his chicken coop with his tasty chickens. Farmers are supposed to consider what foxes are known to do to chickens and what a fox's motives and likely purpose might be in putting on a chicken suit and sweetly pawing on the door to the henhouse.
There's really nothing new, here. However, if OSI were to surrender the integrity of its certification program, that would be something new, and particularly bad. Which is easily a sufficient reason for that not to occur.
The actual decision must wait for the recommendation from the OSI license approval committee and the vote of the board of directors.
Page editor: Jonathan Corbet
Next page:
Security>>