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
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
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,
Well we have a better security track record than Red Hat, we do that by
focusing very hard on security, making sure the updates are available as
fast as possible on Ubuntu, independent studies have generally ranked
Ubuntu number one.
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
||1 May ||3 June ||7 May ||20 June||1
||6 May ||3 June ||7 May ||20 June||12
||28 May ||17 June ||28 May ||4 June||30
||11 June ||13 June ||11 June ||13 June||11
|Firefox 1.5 and
||1 July ||2 July ||2 July ||11 July||11
||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:
So what I'm trying to say here, that the notion that Canonical wouldn't
contribute anything in such a situation and it would be a one way flow is
something I disagree with. Look for example at the fact that Ubuntu has
usually better hardware support, if we all were on the same kernel the
others could take the drivers we put in there and have hardware support
that is just as good as Ubuntu.
While supporting more hardware is an excellent goal, doing it by merging
unsupported drivers into the kernel is not the recommended path. As Red
kernel hacker Dave Jones puts it:
Does no-one else see the hypocrisy in this statement ? Here's how it reads
to me... "It would be great if everyone just shipped the Ubuntu kernel and
debugged the random crap we merge that we don't have the resources to do
If only there were some kind of process of getting drivers merged upstream
to kernel.org. Perhaps then we COULD be on the same kernel. Oh wait, there
is a process. Ubuntu just chooses to ignore 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
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'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
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:
It's all about the repo. A tarball is something you hand off to
poor saps that haven't joined the 21st century, all the while
snickering at their inability to get with the times. It is nothing
more than a middle man step that interferes with efficiency of
operation and that should be cut out of the loop.
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:
Our goal is to integrate version control with distro package
maintenance. We want to recognise all involved in the process, from
upstream, the package maintainers of the various distributions,
their security and release teams, and power users, who aren't
afraid to fix their own bugs, and give maximum flexibility to
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)
On July 15, Red Hat and Firestar released
the terms of the settlement [PDF]
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
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:
Licensor grants and promises to grant to Red Hat Community Members
a perpetual, fully paid-up, royalty-free, irrevocable worldwide
license of the Licensed Patents to engage in any and all activities
related to Red Hat licensed Products, including without limitation
to make, have made, use, have used, sell, have sold, offer for
sale, have offered for sale, provide or have provided, distribute
or have distributed, import or have imported and Red Hat Licensed
Product and services related to any Red Hat Licensed Product.
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
toward the top of the settlement to see what those terms really mean. Who,
exactly, is a Red Hat Community Member?
...any Entity that is a licensee or licensor of, contributes to,
develops, authors, provides, distributes, receives, makes, uses,
sells, offers for sale, or imports, in whole or in part, directly
or indirectly, any Red Hat Licensed Product, including without
limitation any upstream contributor to, or downstream user or
distributor of, a Red Hat Licensed Product.
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:
"Red Hat Licensed Product" means any Red Hat Product, Red Hat
Derivative Product, or Red Hat Combination Product.
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:
...(a) any product, process, service, or code developed by,
licensed by, authored by, distributed under a Red Hat Brand by,
made by, sold under a Red Hat Brand by, offered for sale under a
Red Hat Brand by, sponsored by, or maintained by Red Hat, (b) any
predecessor version of any of the foregoing, including without
limitation any upstream predecessor version any of the foregoing...
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
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:
"Red Hat Derivative Product" means any product, process, service,
or code that is a direct or indirect Derivative of at least one Red
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
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
a Red Hat Derivative Product that infringes the particular Licensed
Patent at issue without use of or reference to any portion or
functionality in or from a Red Hat Product on which the Red Hat
Derivative Product is based.
(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
Comments (16 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Trust and mirrors; New vulnerabilities in apache, drupal, firefox, java,...
- Kernel: 2.6.27: what's coming; Block layer: integrity checking and extended partitions; Handling kernel security problems.
- Distributions: Gentoo: New release, "new" leadership; BLAG 90000 Released; Mandriva Linux 2009 Alpha 2 released; Intrepid Alpha 2 released; package management vulnerabilities; Ubuntu quality assurance
- Development: Control model railroads with JMRI, database replication wiht Postgres-R, new versions of BusyBox, FCKeditor.Java, YaBB, Ardour, Sonic Visualiser, Vamp plugin SDK, Mnemosyne, Urwid, Wine, Qsynth, Rubber Band, Firefox, OpenSwing, Common Lisp Reasoner, Python NetAddr lib, GIT.
- Press: The current state of Gentoo, debunking Myths About KDE 4, looking at Xandros' purchase of Linspire, Brian Proffitt interview, plans for GNOME 3.0, Motorola's Linux smartphone, OO.o 3.0 review, Ubuntu photo applications, Joe Barr dies.
- Announcements: Support the Django Software Foundation, In Memory of Uwe Thiem, ODBMS.ORG releases new reports, Pizzigati Prize applications, mod_perl Users Survey, ClubHack cfp, Linux-Kongress cfp, Django coding sprints, Akademy and GUADEC on Gran Canaria, EuroSciPy slides, LWE openSUSE Day.