|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching ten thousand messages in a given week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown. Our regular monthly column keeps you abreast of the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly online digest, the Kernel Traffic newsletter for over five years now. Even reading Kernel Traffic alone can be a time consuming task. Linux Magazine now provides you with the quintessence of Linux Kernel activities, straight from the horse's mouth. |
Linus Torvalds has said that he does not intend to license any of his own kernel contributions under anything but version 2. However, that doesn't stop anyone else from submitting their own code under whatever license they please, so long as it is also licensed under the GPL version 2, or (as with BSD code) can be relicensed under GPL version 2.
Even if Linus were willing, it would be difficult to change the kernel license. Anyone who contributes code to the kernel retains their own copyright and simply grants a license to use the code in the kernel. Unless the license itself defines conditions under which it could be changed, no one but the copyright holder has permission to change the license. So, to convert the kernel from GPL version 2 to GPL version 3 would theoretically require tracking down all the thousands of developers who have contributed and asking them to relicense their code under the GPL version 3. Then all of those thousands of people would have to unanimously consent to that request.
An alternative would be to insist that all new contributions be dual licensed under version 2 and version 3; eventually (in dream-land), code covered only by version 2 would be replaced, and version 3 would cover the whole kernel.
The argument that GPLed code is usually licensed under version 2, "or (at your option) any later version," does not apply, because the kernel doesn't use that wording when it identifies its license. Version 2 of the license is specified explicitly, because Linus didn't trust Richard Stallman to produce an acceptable GPL version 3. And although the GPL states that the copyright holder may not impose additional restrictions, avoiding the "any later version" wording does not actually introduce restrictions, because that text is not part of the license. It is just the text suggested for use in licensing something under the GPL.
So, it would take an incredible series of circumstances for the Linux kernel to change licenses, or even to upgrade to a newer version of the same license.
The 2.4 kernel has been out for over 5 years, and development has really slowed. But a lot of people still use version 2.4 of the Linux kernel, especially in light of the abandonment of the previous even/odd development cycle. For many users, the 2.4 tree is the only one they trust - it's the only one that has undergone a strong stablization effort.
The counter argument is that distributions do their own stablization work, and that the w.x.y.z series also takes care of stablization; but these efforts are all restricted essentially to uptime. The 2.6 codebase itself is not stable but changes constantly, and this may be what makes some people nervous about going to the 2.6 tree.
Recently Willy Tarreau posted about a dozen choice 2.4 patches, mainly driver support, security enhancements, and memory optimizations. There was a lot of interest immediately, and a request for additional feature support, as well as pointers to other 2.4 patches that might be collected and made available in a centralized place.
While it's difficult to imagine any of these patches making it into the official tree at this late date, it's possible that this new, unofficial branch of 2.4 development may become more serious and develop a larger following while 2.6 continues its wild throes.
Adrian Bunk has submitted a patch to no longer list the Forcedeth driver as "experimental" during kernel configuration. It's apparently become quite stable, as several users affirmed in response to the patch. Another part of the patch caused the one-line driver description to no longer mention that the code had been reverse-engineered from NVIDIA's binary-only counterpart. Adrian felt that the user only needed to know what the driver did, not how it was developed. But Lee Revell pointed out that the information was still useful, if only to let users know which Linux-unfriendly vendors to boycott. However, Arthur Othieno pointed out that the fact of reverse engineering could be preserved in the driver's help text, rather than displayed directly on the configuration description; and Alistair John Strachan mentioned that not all of NVIDIA was hostile to open source - at least two NVIDIA employees contributed to the free driver, he said.
For quite some time, the kernel has been restricting the third-party code that can link into it and use its symbols (variables and functions). These symbols are necessary for third-party drivers to interact with the deeper kernel. But many parts of the kernel will only export their symbols to code that has set a licensing variable to indicate that it is licensed under the GPL.
This is actually quite a clever little device, and it has inspired some interesting attempts at circumvention, such as adding weird characters to the licensing variable that satisfied the kernel but didn't actually indicate that any code was GPLed. These loopholes were all fixed as they came up, but one has to marvel at the audacity of companies, just straightforwardly releasing binary-only drivers that tweak the licensing variable in just the right way.
Ultimately, those attempts were few and far between, but the question now becomes, what about proprietary third-party software produced by the more Linux-friendly companies? Recently Sven Schmidt of AVM complained that Greg Kroah-Hartman recently altered the USB subsystem's requirements for the licensing variable, making it impossible to run non-GPLed USB drivers with an unpatched kernel. Sven said that AVM had been very good about providing Linux support, and offering their customers the choice of Microsoft or Linux drivers; but that now, they would have to drop Linux support for all of their USB devices.
There were several responses to this. The traditional one, voiced by Valdis Kletnieks, was that AVM should just release their drivers under the GPL, so they would have no further trouble linking into the kernel. But a more technical reply came from Greg himself, who said that, in fact, the recent advent of usbfs and libusb made it possible to write USB drivers in user-space without sacrificing speed. AVM could distribute all the closed-source user-space drivers it wanted without worrying about kernel symbol accessibility.
This might have settled the issue, but as with all things kernel, there's always just a little more going on. For instance (though AVM was not the one to point this out), the kernel FAQ has stated for years that no more symbols would be made GPL-only, and that developers of proprietary modules could feel comfortable releasing those drivers. Greg's response to this was that the FAQ entry was 8 years old and should be updated to reflect the truth.
Sven also pointed out that even if user-space drivers were possible, they would not ensure the reliability of time-critical applications the way kernel-space could. Also, switching to user-space would require a huge development effort. And finally, of course, AVM wanted to protect its "intellectual property."
The git revision control system continues to be developed at a tremendous pace. For starters, Linus Torvalds and others have been giving some thought to subproject support, where one portion of a git repository could be checked out independently of the rest. Linus actually looks at this from a somewhat reversed standpoint. The value of subproject support, he feels, is that for projects that have a lot of subprojects, the feature allows regular users to check out the whole repository without having to type many different commands to get each subproject. So, git may end up supporting subprojects in one form or another.
The X.org project is beginning to migrate at least part of its codebase over to git, starting with the X server core. Keith Packard is leading this effort and plans to migrate all the X.org modules he's responsible for. Other modules will choose their own revision control; and dead code may never migrate at all.
The issue of whether to lock files for editing is under consideration. This would involve giving an `edit' command on a file to be edited, so git would know precisely which files had been altered. BitKeeper behaved this way, and the speed gain is considerable. Linus is reluctant to go in this direction, because git under Linux is already incredibly fast, due in large part to the Linux kernel's very speedy lstat() file statting function. Unfortunately, under operating systems with less well designed filesystem behavior, this speed benefit is lost.
In an interesting irony, git may begin to support shallow cloning, where users could clone only the most recent history of a given repository. Junio C. Hamano, the git maintainer, has proposed this more CVS-like feature as a way to protect developers from the sheer size of a project. Even a small project, over time, could grow a tremendous history, so large that it could be difficult to hold on a contributor's home system. Shallow cloning would allow the developer to choose how much history is actually relevant to their particular contribution.
Aneesh Kumar has been working on gitview, another git repository browser, to go along with qgit, gitk, and others. Eric Wong has written git-svn, a tool to allow developers on a single project to use either git or Subversion, at their discretion. He did this mainly so he could use git himself on projects that were otherwise held in Subversion repositories. Junio has created a contrib area of the source tree for interesting and experimental tools. The most recent addition is an emacs interface to git, from Alexandre Julliard.