Jesse Barnes posted a summary of recent efforts to improve the Linux kernel's support for graphics, "in collaboration with the [framebuffer] guys, we've been working on enhancing the kernel's graphics subsystem in an attempt to bring some sanity to the Linux graphics world and avoid the situation we have now where several kernel and userspace drivers compete for control of graphics devices." He then explained, "there are several reasons to pull modesetting and proper multihead support into the kernel: suspend/resume, debugging (e.g. panic), non-X uses, and more reliable VT switch," going on to offer detail on each of these listed reasons. Jesse followed these explanations with an overview of the current status of the code:

"The current codebase is still incomplete in many ways: locking needs to be (re-)added around our various list manipulation paths, we need better initial configuration logic, only the Intel driver has any support (and it's still missing suspend/resume and accelerated FB functions), we need to check modes against monitor limitations (which come from EDID or the user), CVT and GTF based mode generation still isn't used by the DRM modesetting code, and much more. I'm hoping that by posting this now, we can get some ideas about what requirements other people have for graphics on Linux so we can prioritize our work."

The following editorial was contributed by Ciarán O'Riordan of FSFE. Working for FSFE since April 2005, Ciarán has been raising public awareness and participating in public discussion on GPLv3 since the launch in January 2006 and contributes heavily to FSFE's GPLv3 project.

Discussion draft 3 of GPLv3 is due in early November, approximately. Before that is finalised, I'd like to review the debate over DRM and the Linux kernel developers. Discussion draft 3 may be the final discussion draft, so I'd like to encourage discussion of this issue so that people can make comments now (via gplv3.fsf.org) which can be taken into account for draft 3.

GNU GPL version 2 is a great licence. It's an amazing licence when we remember that Richard Stallman wrote it pretty much on his own with some legal counsel. This year, the community's input is solicited and four teams comprising 130 people have been formed to research each issue raised by the community. With fifteen years of hindsight, and will brains from around the World, I think we can write an even better licence.

The decision for whether the Linux kernel will relicense to GPLv3 can really be made when the official GPLv3 is published in early 2007. Relicensing Linux will not be simple, due to it's hundreds or thousands of copyright holders, but it can be done if there is a will. (I previously wrote about how this works in "Can the Linux Kernel Relicense?") Right now is the time for debating what the licence can do, should do, and what options it should leave open. In this article, I'll focus on DRM.

Linux creator Linus Torvalds posted an email titled, "An Ode to GPLv2" examining why he feels the GPLv2 is such a great license as an alternative way to look at the GPLv3 debate [story]. "This post is kind of another way to look at the whole GPLv3 issues," Linus explains, "not caring so much about why the GPLv3 is worse, but a much more positive 'Why the GPLv2 is _better_'." Following a lengthy preamble to explain his stance, Linus includes a comment originally posted to a Groklaw article titled GPL Upheld in Germany Against D-Link.

His Groklaw comment is in reply to a number of concerns including that the GPLv2 doesn't get specific, doesn't provide patent protection, and ignores DRM. "That's why the GPLv2 is so great," Linus replies, "exactly because it doesn't bother or talk about anything else than the very generic issue of 'tit-for-tat'." Linus explains that when he replaced his original license with the GPLv2 [story], he did it because he was looking for something that was fair. "And that's what the GPLv2 is. It's 'fair'. It asks everybody - regardless of circumstance - for the same thing. It asks for the effort that was put into improving the software to be given back to the common good. You can use the end result any way you want (and if you want to use it for 'bad' things, be my guest), but we ask the same exact thing of everybody - give your modifications back."

James Bottomley posted an article to the lkml titled, "The Dangers and Problems with GPLv3" authored by ten of the most active Linux kernel developers. The paper begins by examining the GPLv2's role in the success of the Linux kernel, then goes on to point out some potential flaws in the upcoming GPLv3. Specific issues are raised with the DRM clauses in the license, "while we find the use of DRM by media companies in their attempts to reach into user owned devices to control content deeply disturbing, our belief in the essential freedoms of section 3 forbids us from ever accepting any licence which contains end use restrictions", the additional restrictions clause, "the additional restrictions section in the current draft makes GPLv3 a pick and choose soup of possible restrictions which is going to be a nightmare for our distributions to sort out legally and get right", and the patents provisions, "as drafted, this currently looks like it would potentially jeopardise the entire patent portfolio of a company simply by the act of placing a GPLv3 licensed programme on their website." The document concludes, "the three key objections noted in section 5 are individually and collectively sufficient reason for us to reject the current licence proposal. However, we also note that the current draft with each of the unacceptable provisions stripped out completely represents at best marginal value over the tested and proven GPLv2."

The resulting discussion included a number of clarifications from Linux creator Linus Torvalds. When it was suggested that he should have specifically retained the right to modify the licensing of the entire kernel he pointed out that things work better as they are with nobody firmly in charge, "remember: the perfect is the enemy of the good. Asking for things that are perfect 'in theory' usually just results in things that are horrible 'in practice'. So not having anybody in charge could _in_theory_ cause problems. But _in_practice_ it's a hell of a lot better than somebody that people need to worry about." He also stressed that the Linux kernel is not a Free Software Foundation project, "I personally have always been very clear about this: Linux is 'Open Source'. It was never a FSF project, and it was always about giving source code back and keeping it open, not about anything else." He further clarified, "the whole 'Open Source' renaming was done largely _exactly_ because people wanted to distance themselves from the FSF. The fact that the FSF and it's followers refused to accept the name 'Open Source', and continued to call Linux 'Free Software' is not _our_ fault."