By Jonathan Corbet
January 10, 2012
Recently, certain corners of the net have carried the claim that Barnes
& Noble is refusing to release the source for the kernel shipped in its
"Nook Tablet" book reader device. That, of course, would be a violation of the
kernel's licensing. GPL violations are far from unheard of in the mobile
electronics market, but B&N is a company with a high-enough profile to attract
special attention. A look at what is going on suggests that there is less
to the story than meets the eye - but it still merits a look.
The big fuss was made on the XDA
developers forum, where many Android-related conversations are hosted.
There, Adam Outler claimed:
It would seem that Barnes and Noble is betraying the most sacred of
things in the open-source world, The General Public
License(GPL). As open source programmers we all use the GPL
daily. The GPL is what keeps Open-Source work like the Linux kernel
free, modifiable and re-distributable. I tried to compile the
sources provided by Barnes and Noble, but they are incomplete. They
will not compile.. I'm not the only one, others have tried and
failed as well.
He also claims that B&N has been deleting requests for the source from
its own forum sites.
In truth, B&N has made the kernel source for its Nook
devices available - though some prodding from Matthew Garrett was required
to get that to happen. One can find it by scrolling down on the
Nook "terms of service" page. Matthew believes that source
distribution to be complete - or something very close to it. His
position is that B&N appears to be living up to its obligations under
the GPL at this time.
Some XDA developers still disagree with this assessment for one simple
reason: it is not actually possible to build a replacement kernel for the
Nook (specifically, the "Nook Tablet" variant) using the source provided.
Like many consumer electronics devices,
the Nook Tablet is locked down and will refuse to boot a kernel that lacks a
signature that it recognizes. What the XDA developers want is a signing
key that will allow them to build kernels that are actually bootable on the
device. Without that key, they say, the kernel sources are incomplete and
useless.
It is certainly a reasonable thing for them to want; hackable
devices are, after all, far more interesting and valuable than the
locked-down variety.
There is a difference, though, between wanting something and claiming that
somebody is obligated to provide it to you. Whether B&N is obligated
to provide that key is far from clear. The relevant GPLv2 language is
this:
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus
any associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
Many developers have, over the years, claimed that a signing key qualifies
as one of the "scripts" referred to in §3 of the GPL. Even if the
license does not explicitly say that it must be possible to build and
install an executable that the hardware will actually deign to boot, that
requirement is arguably within the intent of the license.
Version 3 of the GPL added language to make this expectation explicit; in
most cases, it is not possible to use GPLv3-licensed code in a device if
that code cannot be updated by the user. But the Linux kernel is not
covered by GPLv3, and, more to the point, the discussion around GPLv3 made
it clear that a significant portion of the kernel development community
does not wish to limit the use of their code in this way. The "kernel developers' position on GPLv3" document
posted in 2006 was explicit on that point. Linus Torvalds
made his position clear on the issue well
before the GPLv3 process even started:
But since the signature is pointless unless you _use_ it for
something, and since the decision how to use the signature is
clearly outside of the scope of the kernel itself (and thus not a
"derived work" or anything like that), I have to convince myself
that not only is it clearly ok to act on the knowledge of whether
the kernel is signed or not, it's also outside of the scope of what
the GPL talks about, and thus irrelevant to the license.
Of course, the actual meaning of the language in the GPL is not determined
by Linus or any specific group of kernel developers. That, in the end, can
only be definitively done in a court, and, even then, clarity can be hard
to come by. So it is conceivable that, someday, some developer could
pursue a case against a company like B&N and prevail, forcing either
the release of the signing key or the removal of the product from the
market. Such an outcome, needless to say, would cause a number of
manufacturers to reevaluate their use of Linux in their products.
That outcome seems unlikely, though, for one simple reason: Linus and a
number of other high-profile developers have, through their statements and
rejection of GPLv3, made it clear that they see locked-down systems as a
permissible use of the kernel and in full compliance with its license.
Such signals carry a lot of weight in arguments before a judge, who will be
reluctant to rule that a vendor cannot do what the developers of the kernel
explicitly said was allowed. Anybody seeking such a ruling will be
fighting an uphill battle from the outset.
Saying that the license allows certain behavior is not a statement that
such behavior is a good thing. But that is the nature of free software: it
is not truly free if it cannot be used to do something the author disagrees
with. Once code is released under a free license, it can be used for any
number of distasteful things, including running criminal organ-harvesting
rings, controlling land mines, tracking people the government doesn't like,
or sending "join my social network" email. It can also be used to
implement unpleasant DRM schemes on a locked-down ebook reader. That is
simply part of the loss of control that comes with making software free.
In some parts of the market, it has become clear that an open platform is a
competitive advantage; see HTC's policy of not locking down the boot
loaders on its handsets, for example. Barnes & Noble is engaged in a
difficult fight against companies like Amazon; as Charlie Stross so
clearly stated last year, an insistence on using DRM is just making
that fight harder. The push for DRM seemingly comes mainly from the
publishers, but pushback from retailers like B&N could force some
change there. So one could easily argue that B&N should stop
locking down its readers, not because of licensing problems, but because it
makes more commercial sense not to.
(
Log in to post comments)