Selling a new license to the kernel developers was always going to be an
uphill battle. They are a large and strong-minded crowd, occasionally
suspicious of the Free Software Foundation and its attitude toward Linux,
and happy with the licensing that they have now. Given the immense
practical difficulties involved in changing licenses, there would have to
be a strong incentive to get the developers to even try.
The odds of a license change fell even further earlier this year, when
Linus Torvalds made his opposition to the anti-DRM provisions of the GPLv3
draft known. For some time, it appeared that Linus was alone in that
position, however; few other developers had made public statements on the
license. Even Linus wondered about it:
The reason the poll and the whitepaper got started was that I've
obviously not been all that happy with the GPLv3, and while I was
pretty sure I was not alone in that opinion, I also realize that
_everybody_ thinks that they are right, and that they are supported
by all other right-thinking people. That's just how people work. We
all think we're better than average.
So while I personally thought it was pretty clear that the GPLv2
was the better license for the kernel, I didn't want to just depend
on my own personal opinion, but I wanted to feel that I had
actually made my best to ask people.
So he put together a quick discussion list involving the top 30 or so
kernel developers (see the message quoted above for the the exact selection
criteria) and held an informal poll. The results were as clear as it
gets: none of the developers polled was positive about the license, and
most were strongly negative. Among this crowd of most active kernel
developers, nobody is prepared to say that moving to GPLv3 would be a good
thing for the kernel project to do.
A subset of these developers put their names onto a separate position statement.
Some of the positions taken in that statement are quite strong (see
Russell's take), to the point that not all were willing
to support it. It also appears that, while the anti-DRM provisions are
almost unanimously opposed, a number of developers are sympathetic to the
patent-related terms in GPLv3.
The anti-DRM clauses are, indeed, at the heart of the problem. The GPLv3 draft
requires that, if somebody ships you a device which runs GPLv3-licensed
code, they must also provide you with everything required to rebuild and
reinstall that code - including encryption keys if the hardware requires
them. Those who support this language see it as a fundamental guarantee of the
freedom that comes with free software - the freedom to replace that
software if need be. In particular, these people want to be able to
replace software which implements unpleasant DRM schemes or other
In the discussions that have followed, it is hard to find kernel developers
who support locking up content and abridging fair-use rights with DRM
schemes - though some do see situations where locking down a system's
software makes sense. But they see the language in the GPLv3 draft as
restricting the possible uses of their software, and they don't like it.
The cure seems worse than the disease.
The core question behind this whole debate, perhaps, is this: what,
exactly, do we want to accomplish with our licenses? Just as there is
disagreement over what kinds of problems can be solved by passing laws,
there is no consensus on which problems can be addressed with license
terms. One can argue that oppressive DRM is a societal or legal problem,
and that it should be addressed at those levels through a reaffirmation of
what fair-use rights should really be rather than by adopting a license which
tries to keep specific software from being used to implement DRM. A
license can be a hefty hammer, but not every problem is a nail.
Regardless of the reasoning, the fact is that the GPLv3 draft is currently
in a difficult spot. There appears to be no way it will be adopted for the kernel in
its current form; there has also been quite a bit of speculation that a
number of other important projects will either resist the new license or,
possibly, fork into GPLv2 and GPLv3 versions. GPL-licensed libraries are
of particular concern. The prospect of having to carry around two
versions of the C library - one for each version of the GPL - is not
particularly appealing. This is the scenario that some of the kernel
developers warn about in their position statement; anybody who dismisses it
should have a good reason for believing that it will not come about.
There are a lot of good things in the GPLv3 draft. The updating of the
language for worldwide applicability is something we will almost certainly
want, sooner or later. The software patent provisions have the potential
to deter patent attacks against free software users - an important
protection in the absence of a real fix for the patent problem. The "this
code is not a technical protection measure" clause may offer similar
protection from some attacks based on DMCA-like laws. All of this, and
more, is worth having - but only if the new license can find acceptance
from those who have so wholeheartedly adopted GPLv2. The Free Software
Foundation is going to have to make a difficult decision over the next few
months: it can keep the controversial terms and risk the consequences, or
increase the chances of a successful GPLv3 by dropping terms that, in its
opinion, are of fundamental importance.
[Other things to see: the FSF's
response to the position statement and Linus Torvalds's Ode to GPLv2. There is also the announcement of the first
discussion draft of the GNU Free Documentation License, version 2,
which almost appears to have gotten lost in the noise.]
Comments (74 posted)
Back in January, 2005, LWN ran an
article about Debian and Mozilla's trademarks
. In particular, the Mozilla
places strict requirements on where names like
"Firefox" can be used, some of these requirements do not mix well with the
Debian Free Software Guidelines. Recent events now warrant a new look at
Any distribution of Mozilla software which diverges from the
official tarballs must use a different name unless specific approval has
been obtained from Mozilla. Debian's version does indeed
differ in a number of ways. The project could seek approval from Mozilla
to call its version of the browser "Firefox," but that approval does not
help others who may wish to redistribute the software after receiving it
from Debian. Also, the Debian Firefox build omits the official logos,
since they carry a non-free license; that is another change which runs
afoul of the trademark rules.
In the 2005 discussion, the Debian Project had seemingly come to a
resolution with the Mozilla Foundation, as represented by Gervase Markham,
where Debian would be trusted to make reasonable changes and the omission
of the logos was condoned. All seemed well, and Debian has been shipping
Firefox under this understanding for over a year.
In February of this year, however, Mike Connor from Mozilla Corporation
bug report with the Debian project. This bug, marked "serious," stated
that shipping a browser called "Firefox" was a trademark violation:
Firefox (the name) is equally protected and controlled by the same
trademark policy and legal requirements as the Firefox logo.
You're free to use any other name for the browser bits, but calling
the browser Firefox requires the same approvals as are required for
using the logo and other artwork.
Under the previous understanding, the Mozilla Foundation had seemingly
concluded that it could trust Debian to be judicious in its patches to
Firefox. The Mozilla Corporation, instead, is taking a harder line:
To my knowledge, each patchset that deviates from what we ship
should be run by whoever is doing licensing approvals (this is in
progress with various distributions already). Its hard, if not
impossible, to define a set of guidelines that is crystal clear and
doesn't need human oversight. Novell and Red Hat already do this.
The conversation then lapsed until September 18, when Mr. Connor
restarted it. His position has not softened:
In that light, you should consider this, as I previously said,
notice that your usage of the trademark is not permitted in this
way, and we are expecting a resolution. If your choice is to cease
usage of the trademark rather than bend the DFSG a little, that is
your decision to make.
Anybody familiar with the Debian Project will know that asking it to "bend
the DFSG a little" tends not to go over very well.
Mozilla's immediate complaint is about the omission of the official logo, a
change which had seemingly been approved
back in 2005. But Mr. Connor is also taking issue with a number of the
other patches shipped by Debian, and has repeatedly said that every patch
that the distribution applies must be approved by the Mozilla Corporation
ahead of time.
So what happened to the previous understanding? It appears that the shift
to the Mozilla Corporation has brought a new approach to trademark policies
- and new people into the trademark enforcement role. Meanwhile, the
understanding that the Debian Project thought it had was never really
codified onto a piece of paper with the requisite signatures - and, as a
result, it is easy for the Mozilla Corporation to change. A cardinal rule
for dealing with corporations is to always assume that the people you are
dealing with will soon be replaced by others with a much more hostile attitude;
that would appear to be what has happened here. With regard to the logo:
Fair enough, [Gervase Markham] did make that statement. At the
time, we obviously weren't taking that part seriously. We are now,
and we're saying its not ok.
The Debian developers have no intention of going against Mozilla's wishes.
Eric Dorland, one of the Debian Firefox maintainers, did ask for some time,
If this isn't possible, could we at least get a stay of execution?
Etch is going into deep freeze in less than a month. Would it be
possible to resolve this after the release?
The response was not particularly sympathetic:
I would think it makes much more sense to resolve this before you
put another long-lived release into the wild, unless your aim is to
delay compliance. Ignoring the logo issue entirely, I have grave
concerns around the nature and quality of some of the changes the
patchset contains, and I would like to see the changes as a set of
specific patches before I could make any recommendation as to
whether we should continue to allow use of the trademark. If we
were forced to revoke your permission to use the trademark, freeze
state would not matter, you would be required to change all
affected packages as soon as possible. Its not a nice thing to do,
but we would do it if necessary, and we have done so before.
Eric also asked for clarification on the patch review policy, wondering if
it applied even to security updates. The answer was clear:
Yes, if you are shipping a browser called Firefox, we should be
signing off on every deviation from what we ship. Yes, its time
consuming, and yes, I can find more entertaining ways to spend my
time, but its a necessary evil.
As for your straw man about security bugs, what security bugs would
you be fixing with your own patches? If there are security bugs,
they should be fixed upstream, not in your own tree.
Many people do not consider security to be a "straw man," however. Debian
stable currently includes Firefox 1.0.4, which is no longer supported by
the Mozilla developers. So Debian must backport its own security fixes,
and may not want to wait for the Mozilla bureaucracy to review those fixes
before putting them out. The Mozilla response here is that users should
simply be force-upgraded to a supported version; that is, indeed, what a
number of distributors do, but people are not always happy about it. There
are not many other projects which force upgrades in this manner.
The end result of all this, as expressed by Steve Langasek:
Given your subsequent comments indicating that the Mozilla
Foundation reserves the right to revoke trademark grants for
released versions of Debian, I don't see that we have any choice
but to discontinue our use of the marks.
Eric Dorland has stated that he will be changing the name of the browser
soon. Previously, this scenario has been described as the "Iceweasel"
approach - but Eric has not said what name he will be using. He has asked
if Debian sarge can continue to ship "firefox," or whether the name will
have to be changed in the stable distribution; that question has not yet
Debian is not the only project to express some frustration with Mozilla;
consider this message sent to the Fedora
advisory board in August on why Firefox security updates tend to be
slow in coming:
Also you have to take into account that firefox.org doesn't care
about Linux. They produce "updates" that are first Windows
precompiled binaries. Their Linux stuff is still in CVS, not even
tarball released yet, so we have to try and take a CVS snapshot or
troll through CVS logs to find the right patch. They also don't
seem to care about vendorsec, or if they do its a token notice and
nonsensical embargo dates. The last one I noticed was set to be
released in the middle of a global holiday (Easter).
See also this message from last
June on problems the Ubuntu developers have had in keeping Firefox
secure in their distribution.
The Mozilla project has, mainly via the Firefox browser, changed the way
people work with the web. It has brought millions of people into the
community of free software users and ended the destructive domination of a
single, proprietary browser. Firefox is good stuff, and we are far richer
for its existence.
One cannot help wondering, however, if the Mozilla Corporation, now one year old,
isn't losing touch with the free software community it is ostensibly part of.
Releasing software under a free license means losing control over what
happens to it, but Mozilla appears to be having a hard time letting go.
The result makes life harder for Linux distributors, and for Linux users as
Nobody really wants to fork Firefox. The Mozilla Corporation, however,
would appear to be requiring distributors to do exactly that, whether they
want to or not. No distributor has any interest in shipping Iceweasel, but
it appears that a number of us will be using it anyway - or, perhaps,
looking harder at some of the other free browsers out there.
Comments (82 posted)
The 13th annual International Linux System Technology Conference, also
known as Linux Kongress, took place September 5 - 8 in Nürnberg,
Germany. As a technical Linux event Linux
Kongress is smaller in scale than the Ottawa Linux Symposium and
linux.conf.au. Still the conference sessions and tutorials included a
number of quality talks from familiar members of the Linux and open
source communities such as Heinz Mauelshagen, Lars Mueller, Theodore
Ts'o, Volker Lendecke, Alan Robertson, and Daniel Phillips.
A few of the talks stood out. One such talk was Felix von
Leitner's presentation titled "Benchmarking, round 2: I/O
Performance", in which he tested file system performance on
Linux, Windows, OpenSolaris, NetBSD, FreeBSD, and OpenBSD in order
to better understand the scalability of different operating systems and
IP stack throughput. Based on von Leitner's benchmarking methodology Linux
has the fastest file system - reiser4.
The testing theme continued with Poornima
Bangalore, whose presentation was on the topic of "Best Practices
in Linux Kernel Testing." Her talk detailed many of the key
differences between traditional and open source testing. She pointed out
that mainline kernel testing is more challenging than testing many other
open source projects because of the rapid development and the different
sub trees in the kernel: the stable kernels are released every 6 weeks or so,
release candidate (-rc) kernels are available every week, and experimental
(-mm) kernels are available every few days. Poornima shared best practices
regarding kernel configuration, hardware configuration, test automation,
test coverage, and first failure data capture.
Heinz Mauelshagen gave a talk on
device-mapper architecture features and the related target feature
set. In the talk "Linux as a Hypervisor," Jeff Dike discussed the
evolution of the hypervisor support in the Linux kernel and how
capabilities such as ptrace, AIO and O_DIRECT make a difference to
virtual machines. He also talked about the implications of FUSE
(filesystems in userspace) and the manageability benefits of exporting a
UML filesystem to the host. Lars Marowsky-Bree's presentation on
Heartbeat 2 and Xen
explored Heartbeat's ability to manage Xen
guests. He expanded on Heartbeat's architecture and its integration with
Xen to enable resource reallocation, globally ordered recovery actions,
and data center automation policies using the Cluster Resource
Mattias Rechenburg's presentation on
"Using Enterprise Data
Centers with OpenQRM" showcased the state of
OpenQRM an open source project to achieve high-availability,
scalability, and deployment, service and server virtualization on a
variety of operation system. In spite of OpenQRM's pluggable architecture,
the audience focused on the fact that it depends on a binary module
which requires support from Qlusters. The general sentiment from the
audience was they were not interested if they couldn't get support from
Red Hat, IBM, Hewlett-Packard etc.
In "Real-Time Approaches to Linux,"
Ted Ts'o shared his perspective on enterprise real-time computing and
how it differs from so-called traditional real-time computing.
He emphasized the changing
requirements in enterprise software and how high throughput is not
enough because customers increasingly also require latency guarantees,
especially in particular military applications and trading
systems. It was interesting to hear about the benefits and tradeoffs of
different approaches to enterprise real-time including RTAI and Ingo
that guidelines outlined by his colleague Paul McKenney can be used to
evaluate the different approaches to enterprise real-time. This includes
quality of service, the amount of code inspection required when a new
feature is added, the API provided to applications, the relative
complexity, fault isolation, and supported hardware and software
Although IBM presently has only one customer that plans to
deploy enterprise real-time computing, the ability to support large
TCP/IP, commercially available middleware, and databases makes it an
area to watch in the future. Ted also elaborated on the features of
IBM's real-time JVM/SDK (aka IBM Websphere Real-Time v1.0) such as RTSJ
(Real-time specification for Java), the Metronome real-time garbage
collector, and AOT (Ahead of Time Compilation). The talk emphasized that
there are many new applications for real-time operating systems, and in
particular enterprise real-time Linux.
Maddog provided the final keynote on having fun
with open source in his own inimitable way.
Comments (1 posted)
Page editor: Jonathan Corbet
Next page: Security>>