Leading items

Ubuntu, security response, and community contributions

A recent interview with Mark Shuttleworth is raising a few eyebrows. The Austrian news site derStandard sat down with Ubuntu founder and Canonical CEO Shuttleworth at GUADEC in Istanbul asking about many aspects of Ubuntu, desktops, and Linux in general. His answers to questions about synchronizing releases with other major distributions included some controversial claims.

Last May, Shuttleworth suggested that the major enterprise distributions (Red Hat, SUSE, Debian, and Ubuntu) should coordinate their release cycles to foster better stabilization of Linux components. None of the other distributions have expressed much in the way of interest in that plan—at least publicly—though Shuttleworth says there have been some interesting discussions behind the scenes. In answer to a question about the belief that Ubuntu has much more to gain than either Red Hat or Novell, Shuttleworth said:

Below is a table that summarizes the response time for a few vulnerable packages over the last several months. It shows when the vulnerability was first announced along with the first update from each of four major distributions. Note that some distributions fixed the vulnerability at different times for different versions, so the date below is the first; other distribution versions may have waited longer for an update.

Package	Announced	Ubuntu	Red Hat	SUSE	Debian
kernel	1 May	3 June	7 May	20 June	1 May
kernel	6 May	3 June	7 May	20 June	12 May
samba	28 May	17 June	28 May	4 June	30 May
xorg-server	11 June	13 June	11 June	13 June	11 June
Firefox 1.5 and 2.0	1 July	2 July	2 July	11 July	11 July
bind9	8 July	8 July	9 July	11 July	8 July

There doesn't appear to be any clear "winner", though Red Hat seems to beat Ubuntu in most cases—at least on this set of vulnerabilities. It would be much easier to do this kind of comparison if Ubuntu followed Red Hat's lead and published regular assessments of its security performance.

It is rather easy to make sweeping statements, referring to unnamed "independent studies", while it is much harder to actually gather the information and present it. Red Hat's transparency on its security performance is something that all distributions should strive for—especially those who would tout their security response. But the security issue is just a part of a fairly pervasive perception that Ubuntu and Canonical are not contributing very much back to the community.

That is the underlying concern that Shuttleworth is addressing. He continues:

While supporting more hardware is an excellent goal, doing it by merging unsupported drivers into the kernel is not the recommended path. As Red Hat kernel hacker Dave Jones puts it:

Canonical, unlike the other major enterprise distribution vendors, is not known for its kernel contributions. It is a much smaller organization than Red Hat or Novell, so its support organization is rather small as well. Trying to support lots of hardware is a difficult task. Doing it with out-of-tree and binary-only drivers makes it that much harder.

Historically there has also been friction between Ubuntu and its upstream distribution, Debian, at least partially because of a perception that it does not contribute back. It is against this backdrop that Shuttleworth is speaking. The fact that he feels that he needs to defend Ubuntu speaks volumes.

Some of the complaints might be written off to jealousy over the popularity of Ubuntu, but there is a fair amount of truth to them as well. Canonical and the Ubuntu community have done some fairly amazing things in a short period of time, but they did it by leveraging lots of work by Debian and others. It is important to be a contributing member of the larger Linux ecosystem, so Ubuntu and Canonical need to work to remove this perception of the distribution—regardless of its merits. Talk alone won't do that, action is required.

Comments (53 posted)

Fedora and distributed source packages

Fedora's new version of RPM, announced on July 9, has hit the Rawhide repositories; after inspiring some initial cries of pain, it would appear to settling in well. It is good to see activity on Red Hat's version of RPM after a long period where nothing much was happening. In the process of bringing this new code to Rawhide, the RPM developers have also inspired some interesting side discussions on topics like whether such a major change should have gone through the official "features" process first. But the most extended (and arguably most interesting) discussion came from an unexpected direction.

Doug Ledford is known in kernel development circles, but, being an RHEL engineer, he has not been seen much in the Fedora camp. He joined the RPM discussion with a feature request of his own: he would like a set of tags which would facilitate the location of a package's source code in a distributed version control system (DVCS). So these tags would indicate which DVCS is in use (git, mercurial, etc.), where the repository is to be found, the tag corresponding to the source code for a specific version of a package, etc. And, Doug let it be known, it would be nice if he could have those tags soon; tomorrow would be nice, but before the Fedora 10 release in particular.

Once this information exists for a package, interesting things can be done. For example, source RPM packages could become much smaller; rather than containing a tarball and a set of distributor-applied patches, it could just hold the DVCS information. An "installation" of that package would then just go to the source repository and check out the sources from there. If the source repository is managed carefully, it could help the cooperation between Fedora and the upstream projects; patches could be pushed and pulled between repositories with ease. This kind of mechanism could also make it easier for the Fedora project to distribute "spins" created by outsiders by reducing the resources required to make the associated source code available. See this lengthy pitch from Doug for more discussion of the advantages of the distributed source package approach.

Of course, there are some obstacles too. Not all projects are using a DVCS, so integration with those projects would be more difficult. Quite a few projects have material in their repositories which, for legal reasons, cannot be distributed by Fedora. Finding a way to excise that material without breaking the connections between repositories could be challenging. The tarballs distributed by many upstream projects - which are the starting place for Fedora packages now - often contain changes which are not reflected in their source repositories. Those changes can include the removal of non-distributable material, or simply generating the configure file.

These challenges are real, and some of them will take a fair amount of work to resolve. But it seems clear that things eventually need to go in this direction. Tighter integration between projects and distributors can only help the whole free software ecosystem work in a more efficient manner. Tarballs reflect a form of frozen state which is entirely divorced from the code's history - and from its future. Or, as Doug put it:

A source package format that can maintain its connections wherever it goes can only make the whole system work better. So it is good that the Fedora folks (including those beyond Doug who have been thinking about this issue for a while now) are working on this problem.

There was, however, an interesting omission from the discussion; as far as your editor can tell, nobody ever mentioned the work being done by the vcs-pkg project, which is aimed toward this goal:

This group is mostly Debian-based, but its members are making a concerted effort to create solutions which are independent of any given distribution (or DVCS). It can only make sense for Fedora to work with this project - or at least have a look at what vcs-pkg is doing and come up with a good excuse why a different solution has to be invented for Fedora.

The integration of distributed version control and packaging can only reach its full potential if, among other things, it facilitates cooperation between distributors and their upstream providers, their users, and, importantly, other distributors. If each distributor brews up its own solution (again), they'll have a hard time sharing their work with each other. Few upstream projects will have the patience to integrate with several disparate distributor systems, so that integration will be much less likely to happen. All of this can be avoided, though, if the distributors decide now to work toward some common standards for the use of distributed version control in packaging.

Comments (21 posted)

What Red Hat and Firestar agreed to

On July 15, Red Hat and Firestar released the terms of the settlement [PDF] of their patent suit. When we last looked at this settlement, those terms were not available. Now we can examine exactly what was agreed to and assess the degree of protection that Red Hat actually negotiated for the wider community. It may be tempting to say that recent events have reduced the relevance of this settlement, but that would be a mistake; what Red Hat has done here still matters.

Those recent events, of course, are dominated by Sun's announcement that it had successfully challenged the Firestar patent; the US Patent and Trade Office (PTO) has officially rejected all of Firestar's claims. As your editor (along with numerous others) has said, this should not have been a particularly hard thing to do; the weakness of this particular patent was evident after even a cursory reading. So one might well wonder why Red Hat chose to pay the troll in this particular case.

And, incidentally, Red Hat did pay. Naturally enough, the specific payment terms have been removed from the agreement, but a payment was a part of the deal.

It is nice that Sun took a less compromising approach to this case, even though it was not named as a defendant. But Sun's success has not rendered this settlement moot, for a few reasons. To begin with, Firestar now has two months to fight the PTO decision and reinstate its patent. That looks like a difficult task, but, with the PTO, one never really knows. Second, the settlement does not cover just that one patent; it covers just about any patent that Firestar owns or will acquire in the next five years - though some of that coverage goes away in 2013. And, perhaps most importantly, Red Hat clearly sees this settlement as a template for the resolution of other patent suits which are certain to come in the future.

The settlement itself reads somewhat like a Pascal program; one must start toward the bottom and read it in reverse. Following that analogy, the main program can be found in section 5.2:

So, these patents have been licensed for any practical purpose to anybody who happens to be a Red Hat Community Member, as long as they are working with Red Hat Licensed Software. Well, almost any purpose; there is a small catch, as will be seen shortly. First, though, it is time to read the declarations toward the top of the settlement to see what those terms really mean. Who, exactly, is a Red Hat Community Member?

This definition is clearly quite comprehensive; anybody who makes use of the software is considered to be a Red Hat Community Member. Your editor is pondering offering for sale a line of "Proud Red Hat Community Member" T-Shirts at the next Debconf or OpenBSD hackfest. This is a club that we all get to join.

The other key term, though, is "Red Hat Licensed Product," because only such products are covered by the settlement. The definition of this product is simple:

Now, perhaps, we have moved away from Pascal programming and are stuck with the unenviable task of making sense of a convoluted Java class hierarchy. One of the subclasses, the definition of "Red Hat Product," is crucial:

So essentially, a Red Hat Product is anything developed or shipped by Red Hat under one of its trade names. So anything in Red Hat Enterprise Linux qualifies. The important thing that Red Hat didn't see fit to specify in its early PR is that anything in Fedora - also being software distributed under a Red Hat Brand - qualifies too. Since Fedora packages rather more software than RHEL does, that broadens the coverage of this agreement considerably.

Also important is the "any predecessor version" clause. Coverage under this agreement does not apply to just the specific, possibly patched version of a program shipped by Red Hat; anything which came before in that package's upstream is also part of the deal. And, incidentally, this coverage does not go away if Red Hat stops shipping a package; just one shipped version will do. The Red Hat Brand has become the magic touch which confers protection against Firestar patents onto any software it touches.

Thus far, we have coverage for Red Hat's packages and their predecessors upstream. What happens, though, if the upstream project continues to develop the software beyond the version shipped by Red Hat? That's where the "Red Hat Derivative Product" category comes in:

So the combination of "any predecessor version" and the definition of a Derivative Product means that the entire project is covered, from its first version through anything it will do in the future - though, once again, there's a catch. But, before we get to that, there is the third subclass: "Red Hat Combination Product." It refers to a grouping of something which is one of the two product types described above and something unrelated - an aggregation. The apparent intent is to cover situations like dynamic linking: an application which links to a covered library will, itself, be covered.

These definitions, too, appear to be quite broad. Just about anything which has been shipped by Red Hat, or which has even shared the same disk drive as something shipped by Red Hat qualifies. But, as has been mentioned before, there is one catch in the form of an excluded class of software:

(There is similar language for Combination Products as well). What this section is saying is that, if a derived product contains infringing code, that infringing code must have been part of the covered Red Hat product as well. In other words, outsiders cannot bless their particular patent infringement by grabbing enough code from some other project to create a derived product. One can see why this restriction was seen to be necessary; without it, any software (free or proprietary) could have easily been brought under the coverage umbrella. Instead, one must first convince Red Hat to distribute that software at least once.

Plenty of other legalese can be found in the agreement, of course; interested readers are encourage to read the whole thing. But the core of it is what's described above. Notably absent (unless it has been redacted from the payment section, which seems unlikely) is any discussion of what happens if the patent is held to be invalid. So, even if Sun is ultimately successful in its challenge (as seems likely), Red Hat will not be getting its money back under the terms of this agreement.

Red Hat's initial press release claimed that this settlement demonstrated the company's commitment to standing up for the community in the face of patent trolls, and stated that it would discourage any future such cases. At this point it seems fairly evident that Sun has made a better show of standing up for the community and discouraging future cases. What Red Hat has done, though, is to show us how future patent problems could be resolved in the absence of obvious prior art. If one must pay the troll, one would do well to come out with an agreement like this one and, at least, keep the troll away from the rest of the community. Whether patent holders who actually have a legal leg to stand on will be willing to agree to such a settlement remains to be seen; the nature of the game is such that, unfortunately, we are likely to get an answer to that question sooner or later.

Comments (16 posted)

Page editor: Jonathan Corbet
Next page: Security>>