LWN.net Weekly Edition for September 28, 2006
Much ado over licenses
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:
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 Rusty 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 user-hostile behavior.
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.]
The return of Iceweasel
Back in January, 2005, LWN ran an article about Debian and Mozilla's trademarks. In particular, the Mozilla trademark policy 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 the issue.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 posted a bug report with the Debian project. This bug, marked "serious," stated that shipping a browser called "Firefox" was a trademark violation:
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:
The conversation then lapsed until September 18, when Mr. Connor restarted it. His position has not softened:
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:
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, however:
The response was not particularly sympathetic:
Eric also asked for clarification on the patch review policy, wondering if it applied even to security updates. The answer was clear:
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:
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 been answered.
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:
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 well.
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.
Highlights from Linux Kongress
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 Manager (CRM).
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 Molnar's CONFIG_PREEMPT_RT.
Ted suggested 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 configurations.
Although IBM presently has only one customer that plans to deploy enterprise real-time computing, the ability to support large SMP systems, 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.
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Searching for insecurity; New vulnerabilities in openssh, tikiwiki, and webmin.
- Kernel: The 2.6.19 process begins; Driver core API changes; Read-copy-update for realtime.
- Distributions: Debian + Dunc-Tank.org = dissent; new releases: BLAG50002, Cross-LFS 1.0.0, FreeBSD 6.2-BETA1, Mandriva Linux 2007 (soon); new distributions: Linux XP, WENDYX
- Development: XCB: the X Protocol C Binding, new versions of Berkeley DB, LAT, rsplib, CUPS, Zope, eSpeak, XMMS2, LyX, Electric, Gnucap, Rosegarden, Maxima, OProfile, Linux binutils.
- Press: Bluetooth on Linux, Linus on GPLv3, aKademy 2006, LTSP meeting, Linux adoption in India, European patent debate continues, Stallman interview, OO.o OXT plug-ins, cluster management systems, IBM's Linux Migration Guide, GNOME 2.16 review, Scalix messaging server.
- Announcements: D-Link loses GPL case, OLPC update, E. Raymond Joins Freespire, iSER protocol for InfiniBand, Novell gets delisting notice, draft of GNU FDL-v2, open RFID reader, Akademy Awards, Projects of Social Benefit award, OO.o template award, FOSS.IN cfp, PyCon 2007 cfp, Desktop Architects Meeting, FSFE Fellows meeting, Boston GNOME summit, Family Guide To Digital Freedom.