The changes that Red Hat has made in the way it releases kernel source for RHEL
6 have stirred up some controversy. There is a certain tension between the needs of an enterprise
distribution and the interests of the free software projects on which it is
the changes that Red Hat has made do not seem very popular, there has also
been a fair amount of speculation that the move somehow violates the GPL,
which is a rather serious charge. But there is good reason to believe that
Red Hat is not crossing into GPL-violation territory, though it may well be
sitting close to that line.
First, the obvious: Red Hat has a top-notch legal team, with a lot of GPL
experience, so it's a little hard to believe that those lawyers, at least,
haven't examined Red Hat's position and believe it is defensible in the
unlikely event of a lawsuit. While Red Hat has a legal team, LWN seems to
be lacking in the legal budget department, so nothing in this article should
be considered legal advice of any sort (I am not a lawyer, nor do I play
The arguments being made
about GPL compliance seem to fall into two categories. The first is that
what is effectively a tarball of the kernel source does not qualify as the
"preferred form of the work for making modifications to it"
(as is specified in the GPL). While the second is that making the
individual patches to
the kernel source available to customers, but not allowing those customers
to redistribute the patches to others, puts a "further
GPL-covered code (which the patches clearly are). While neither complaint is
completely without merit, both would seem to fall short of GPL violations.
While there can certainly be arguments about what "preferred
form" means for source code distributions, Red Hat's actions here
don't seem very close to the line. The basic idea is that the code be
released in digital form, along with any build scripts, so that downstream
developers can reproduce the GPL-covered binary that is being shipped. It
is partly meant to prevent recalcitrant vendors from releasing the source on
paper—or stamped into clay tablets in cuneiform. One could argue
that those methods do provide the source code, but it certainly isn't in a
form preferred by anyone—nor does it adhere to the "medium
customarily used for software interchange" requirement.
Obfuscated source code, where all the variables and function names get
turned into unintelligible gibberish, or the source is deliberately split
up in ways that are harder to work with, are a bit more of a gray
area—but not much. Those kinds of actions should be seen as clear
attempts to circumvent the GPL requirements. But that's not at all what
Red Hat is doing.
The tarball that Red Hat is releasing may not be the preferred form for the
Red Hat kernel developers to use, but that is not part of the requirement.
Tarball releases of GPL code are a longstanding tradition in the free
software world. Many projects
still do it that way and the FSF itself has made releases that way in the
past. While it is nice to get some visibility into the version control
system of a project, it certainly isn't required for GPL compliance. No
one complained that Red Hat didn't provide access to its Git repositories
back when it was still providing the broken-out patches, for example. A
the preferred form for Red Hat developers to use, but there are lots of
reasons that the company might want to keep its repositories to
itself—something that is obviously within its rights.
There is an oft-ignored GPL clause about modifications to consider here as
well: "You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change."
Red Hat may well be technically violating that clause, but it is hardly
alone in that as it is pretty much completely ignored by everyone, without
any real consequences. But this GPL requirement is of little interest to most.
What everyone really wants is the reason
that the change was made (along with which changes to other files go along with
it), and the GPL is silent on any requirement to provide
that level of detail.
For the RHEL kernel source, what Red Hat is providing is well within the
GPL boundaries. It is also well within community norms. The community
gets kernel tarballs from lots of companies (often those in the embedded
Linux world), sometimes after a bit of a
struggle, and is happy to get them. Red Hat shouldn't be treated any
differently than those companies are with respect to the distribution of
Tarballs may be
something of a barrier to easier collaboration, debugging, and so on, but
distributing them doesn't rise to anything near a GPL violation. The other
complaint, on the other hand, is a bit less clear cut.
Trading GPL rights for support
While it isn't anything particularly new, some aspects of the RHEL support
model are raising eyebrows in light of the changes to the kernel source
distribution. In particular, the broken-out patches that used to come with
the kernel source RPMs are evidently being made available to Red Hat
customers, but only if they don't distribute them further on pain of losing
support going forward. This sounds
like a restriction on the GPL rights of the recipients of the
patches—and it is—but that restriction is enforced via an
agreement between Red Hat and its customers.
This is part of Red Hat's business model that Bradley Kuhn calls
the "'if you like copyleft, your money is no good here' business
model" (scroll down a ways to get to that part of his post). It is,
he says, GPL-compliant "merely because the GPL is silent on whether
or not you must keep someone as your customer". He also says that
Red Hat was the first to make use of that particular business model, but he
may be forgetting about Sveasoft.
The history is fading into link rot a bit at this point, so it is possible
that Red Hat
was the first to get there. But Sveasoft's subscription model, which
essentially required subscribers to give up their distribution right on
GPL-covered code provided by Sveasoft, was roundly criticized in the early
2000s. In 2004,
though, Sveasoft announced
that the FSF had reviewed and, somewhat surprisingly, at least at the time,
approved that arrangement. Essentially, the support (or subscription)
agreement is a contract between two entities and those parties can agree to
pretty much anything they want. The GPL cannot protect one from agreeing
from certain behavior.
In the distant past, there were also complaints that Red Hat will terminate
contract for users that run their own kernel, rather than what is supplied
with RHEL. While that is another restriction on exercising GPL rights, it
is one that is rather easier to understand. Trying to support any random
kernel that a customer wants to run is likely to be a quick way to drive
Red Hat's kernel engineers mad. Complete termination of support may be an
excessive reaction—and is probably rarely if ever used—but
certainly not supporting those systems running other kernels is not
The inability to redistribute the kernel patches is clearly seen by some as
the most egregious "violation" of the GPL rights of its customers. In
some, possibly many, cases those patches are not even owned by Red Hat, but
were instead submitted by others to the upstream kernel and then integrated
or backported into the RHEL 6 kernel. But the results of that effort
are being distributed in source form. If Red Hat's customers are
willing to trade their GPL rights for support, there is little anyone else can
do but complain.
On the other hand, a sufficiently motivated group could probably
reverse-engineer the patches from the RHEL 6 kernel source. It would be a
tedious and error-prone process, but Red Hat has said that
all of the RHEL 6 features have been submitted upstream, so it should be doable.
Anyone with a RHEL support contract would want to think long and hard
before participating in such a project, however. Whether there is
sufficient value in doing so remains to be seen.
to post comments)