As the Atheros driver issue continues to simmer on the OpenBSD -misc mailing list and the Linux Kernel mailing list, with debate continuing over when the license of source code can be altered or added to, Eben Moglen made a statement for the Software Freedom Law Center. He began by defending their own actions, "it might be useful to recall the first stage of this process, when OpenBSD developers were accused of misappropriating Atheros code, and SFLC investigated and proved that no such misappropriation had occurred? Wild accusations about our motives are even more silly than they are false." He went on to acknowledge, "we understand that attribution issues are critically important to free software developers; we are accustomed to the strong feelings that are involved in such situations. In the fifteen years I have spent giving free legal help to developers throughout the community, attribution disputes have been, always, the most emotionally charged." He added that the SFLC would be making no further statements until their work on this matter was complete, noting:

"Also, and again for the last time, let me state that SFLC's instructions from its clients are to establish all the facts concerning the development of the current relevant code (which means the painstaking reconstruction of several independent and overlapping lines of development, including forensic reconstruction through line-by-line code reviews where version control system information is not available), as well as to resolve all outstanding legal issues, and to make policy recommendations, if possible, that would result in all projects, under both GPL and ISC, having full access to all code on their preferred terms, on an *ongoing* basis, with full respect for everyone's legal rights. We continue to believe those policy goals are achievable in this situation. The required work has been made more arduous because some people have chosen not to cooperate in good faith. But we will complete the work as soon as we can, and we will, as Mr Garvik says, follow the community's practice of complete publication, so everyone can see all the evidence."

"In the patch you really remove _a_lot_ of stuff," commented Roman Zippel in his reaction to Ingo Molnar's latest updates to the Completely Fair Scheduler. Roman has been consistently critical of Ingo's efforts, asking questions and criticizing Ingo's feedback. He continued, "you also removed a lot of things I tried to get you to explain them to me. On the one hand I could be happy that these things are gone, as they were the major road block to splitting up my own patch. On the other hand it still leaves me somewhat unsatisfied, as I still don't know what that stuff was good for."

Ingo replied to Roman's technical concerns, and pointed out that he'd been traveling for the recent kernel summit, adding, "I bent backwards trying to somehow get you to cooperate with us (and I still haven't given up on that!) - instead of you disparaging CFS and me frequently :-(". Willy Tarreau took a more critical stance, calling into question Roman's motives. He noted that he had been impressed by Roman's original review of the scheduler, but disappointed as the discussion seemed to degenerate, "it's the way you're trying to prove Ingo is a bastard and that you're a victim. But if we just re-read a few pick-ups of your mails since Aug 1st, its getting pretty obvious that you completely made up this situation." Kyle Moffett added, "I get the impression that Ingo re-implemented some ideas that you had because you refused to do so in a way that was acceptable for the upstream kernel. How exactly is this a bad thing?"

Ingo Molnar reviewed Roman Zippel's Really Fair Scheduler code, suggesting that much of the work was similar to that which was being done by Peter Zijlstra, "all in one, we don't disagree, this is an incremental improvement we are thinking about for 2.6.24. We do disagree with this being positioned as something fundamentally different though - it's just the same thing mathematically, expressed without a "/weight" divisor, resulting in no change in scheduling behavior. (except for a small shift of CPU utilization for a synthetic corner-case)"

Roman was not impressed with Ingo's review, asking, "did you even try to understand what I wrote?" He continued, "while Peter's patches are interesting, they are only a small step to what I'm trying to achieve." Regarding performance and code-quality concerns with his patch he added, "I explicitly said that my patch is only a prototype, so I haven't done any cleanups and tuning in this direction yet, so making any conclusions based on code size comparisons is quite ridiculous at this point. The whole point of this patch was to demonstrate the algorithmic changes, not to demonstrate a final and perfectly tuned scheduler."

Discussion continues regarding the choice to merge the CFS scheduler into the upcoming 2.6.23 kernel. A recent thread looked at the possibility of having merged the plugsched code to allow for both the CFS and SD schedulers to coexist in the mainline kernel at the same time, thereby avoiding the recent flamewars. Linus Torvalds pointed to the ManagementStyle documentation and acknowledged that while it's better to avoid flamefests when possible, "at the same time, I don't like playing politics with technology. The kernel is a technical project, and I make technical decisions. So I absolutely detest adding code for 'political' reasons."

As to the technical reason why he wasn't interested in making the CPU scheduler pluggable, Linus explained, "this is one approach, but it's actually one that I personally think is often the worst possible choice. Why? Because it ends up meaning that you never get the cross-pollination from different approaches (they stay separate 'modes'), and it's also usually really bad for users in that it forces the user to make some particular choice that the user is usually not even aware of." He went on to note, "I personally think that it's much better to find a setup that works 'well enough' for people, without having modal behaviour. People complain and gripe now, but what people seem to be missing is that it's a journey, not an end-of-the-line destination. We haven't had a single release kernel with the new scheduler yet". He added, "this, btw, has nothing to do with schedulers per se. We have had these exact same issues in the memory management too - which is a lot more complex than scheduling".

"People who think SD was 'perfect' were simply ignoring reality," Linus Torvalds began in a succinct explanation as to why he chose the CFS scheduler written by Ingo Molnar instead of the SD scheduler written by Con Kolivas. He continued, "sadly, that seemed to include Con too, which was one of the main reasons that I never [entertained] the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them." He went on to stress the importance of working toward a solution that is good for everyone, "that was where the SD patches fell down. They didn't have a maintainer that I could trust to actually care about any other issues than his own." He then offered some praise to Ingo, "as a long-term maintainer, trust me, I know what matters. And a person who can actually be bothered to follow up on problem reports is a *hell* of a lot more important than one who just argues with reporters." Linus went on to note a comparison between the two schedulers:

"I realize that this comes as a shock to some of the SD people, but I'm told that there was a university group that did some double-blind testing of the different schedulers - old, SD and CFS - and that everybody agreed that both SD and CFS were better than the old, but that there was no significant difference between SD and CFS."

A lengthy debate that began with a suggestion to dual license the Linux kernel under the GPLv2 and the GPLv3 [story] continues on the Linux Kernel Mailing List. Throughout the ongoing thread Linux creator Linus Torvalds has spoken out on the GPLv2, the upcoming GPLv3, the BSD license, Tivo, the Free Software Foundation, and much more. During the discussion, he was asked we he chose the GPLv2 over the BSD license when he's obviously not a big fan of the FSF. Linus explained:

"Because I think the GPLv2 is a great license. And I don't like the FSF's radical world-view, but I am able to separate the license (the GPLv2) from the author and source of the license (rms and the FSF). Why do people always confuse the two? The GPLv2 stands on its own. The fact that I disagree with the FSF on how to act has _zero_ relevance for my choice of license.

"[...] But for a project I actually care about, I would never choose the BSD license. The license doesn't encode my fundamental beliefs of 'fairness'. I think the BSD license encourages a 'everybody for himself' mentality, and doesn't encourage people to work together, and to merge."

"I was impressed in the sense that it was a hell of a lot better than the disaster that were the earlier drafts," Linus Torvalds explained in reply to a comment suggesting that he was impressed with the final draft of the GPLv3. He went on to add, "I still think GPLv2 is simply the better license." The discussion began with a suggestion that the Linux kernel be dual-licensed GPLv2 and GPLv3. Linus noted, "I consider dual-licensing unlikely (and technically quite hard), but at least _possible_ in theory. I have yet to see any actual *reasons* for licensing under the GPLv3, though. All I've heard are shrill voices about 'tivoization' (which I expressly think is ok) and panicked worries about Novell-MS (which seems way overblown, and quite frankly, the argument seems to not so much be about the Novell deal, as about an excuse to push the GPLv3)." In a followup email, Linus added:

"Btw, if Sun really _is_ going to release OpenSolaris under GPLv3, that _may_ be a good reason. I don't think the GPLv3 is as good a license as v2, but on the other hand, I'm pragmatic, and if we can avoid having two kernels with two different licenses and the friction that causes, I at least see the _reason_ for GPLv3. As it is, I don't really see a reason at all."

What started as the review of a bug report grew into an interesting debate as Linus Torvalds slammed the current suspend and resume [story] design in the Linux Kernel, "why the HELL cannot you realize that kernel threads are different? The right thing to do is AND HAS ALWAYS BEEN, to stop and start user threads only around the whole thing. Don't touch those kernel threads. Stop freezing them." Later in the discussion, Linus noted that he had no interest in Suspend to Disk (STD), and was only interested in a working Suspend to Ram (STR) implementation. He noted that complexity introduced by STD was infecting the STR logic, and that the two should be completely separated, "what irritates me is that STR really shouldn't have _had_ that bug at all. The only reason STR had the same bug as STD was exactly the fact that the two features are too closely inter-twined in the kernel. That irritates me hugely. We had a bug we should never had had! We had a bug because people are sharing code that shouldn't be shared! We had a bug because of code that makes no sense in the first place!" Linus noted that he doesn't use laptops much, but still likes STR on his desktop, "STR means they are quiet and don't waste energy when I don't use them, but they're instantly available when I care." He then went on to point to design flaws in the freezer:

"I actually don't think that processes should be frozen really at all. I agree that filesystems have to be frozen (and I think that checkpointing of the filesystem or block device is 'too clever'), but I just don't think that has anything to do with freezing processes. So I'd actually much prefer to freeze at the VFS (and socket layers, etc), and make sure that anybody who tries to write or do something else that we cannot do until resuming, will just be blocked (or perhaps just buffered)!"

Greg Kroah-Hartman's announcement for free Linux driver development [story] included the necesssary legal framework to honor NDAs when creating GPL'd drivers. This allowance was discussed on the OpenBSD -misc mailing list. In a public exchange with Greg KH, Stephan Rickauer said, "now these companies have a great excuse to keep specs locked up tight under NDA, while pretending to be 'open.' The OpenBSD project has made clear more than once how this will hurt Free Software in the long run. Signing NDA's ensures that Linux gets a working driver, sure, but the internals are indistinguishable from magic. It is a source code version of a blob." OpenBSD founder Theo de Raadt [interview] called the free driver effort a farce, "you are trying to make sure that maintainers of code -- ie. any random joe who wants to improve the code in the future -- has LESS ACCESS to docs later on because someone signed an NDA to write it in the first place. You are making a very big mistake."

Greg pointed the discussion to his FAQ in which the final question asks about the BSD operating systems and the answer states, "what about them? They are free to do whatever they wish, I have no input into their development at all, sorry." Greg further clarified, "well, as my goal is to have a GPL driver for everything, I don't see how this can hurt :) Now others can have different goals, and that's great and fine. I'm not saying you can't work on something if you wish to do so."

Hans Reiser [interview] sent an email to the lkml titled, "I request inclusion of reiser4 in the mainline kernel". He provided a list of objections raised earlier, noting that all had been addressed. Among the listed issues, Reiser4 now works with 4k stacks. "There have been no bug reports concerning the new code," Hans added.

The request was followed with some suggestions by Christoph Hellwig, including general comments about the coding style. This was one of many issues that led to debate in which Hans commented, "most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code. So yes, it is different." Alan Cox [interview] replied that while the kernel coding style isn't his own style, he tries to follow it when working on the kernel, "one big reason we jump up and down so much about the coding style is that its the one thing that ensures someone else can maintain and fix code that the author has abandoned, doesn't have time to fix or that needs access to specific hardware the authors may not have." Much of the rest of the thread was less friendly, leaving the question of merging Reiser4 into the mainline kernel still up in the air.

In the debate following Andrew Morton [interview] posting his plans for 2.6.13 [story], the existence of a plugin layer in Reiser4 was discussed. Jeff Garzik put it blunty, "the plugin stuff is crap. This is not a filesystem but a filesystem new layer. IMO considered in that light, it duplicates functionality elsewhere." Andrew Morton went on to explain, "I think the concern here is that this is implemented at the wrong level. In Linux, a filesystem is some dumb thing which implements address_space_operations, filesystem_operations, etc."

Hans Reiser noted, "please remember that this is per file, per item, per node, per attribute, per disk format, per bitmap, per super block, etc., abstracting, not per filesystem abstracting." He explained a couple advantages to plugins being that it makes it much easier for developers to change the disk format, and allows for easy code reuse. He added, "the use of plugins forced all the programmers to think about reusability at every layer of design. V3 of reiserfs is way too hard to work on and modify. If you ask one of the team to code something for V3 instead of V4, they quietly groan at the thought. It is just so much easier to do in V4."

Andrew Morton replied, "advanced features such as those which you describe are implemented on top of the filesystem, not within it. reiser4 turns it all upside down. Now, some of the features which you envision are not amenable to above-the-fs implementations. But some will be, and that's where we should implement those." The lengthy discussion continued, an interesting read for Reiser4 supporters and detractors alike.

Three years after Linux creator Linus Torvalds began using BitKeeper to manage the Linux kernel source tree, debates have continued to spring up on the Linux kernel mailing list [story]. A BitKeeper press release from nearly a year ago claims that the move has resulted in doubling the pace of Linux kernel development, a claim examined in a later two part interview on NewsForge from last May, including comments from Linus and Larry McVoy [interview]. In spite of this significant boost in productivity, there remains a group who vehemently oppose Linus' choice to use BitKeeper.

In a recent thread, Larry noted that the version of BitKeeper in use by Linux kernel developers uses an unsigned short to count changesets, and that in about 100 days the number of changesets in the Linux kernel source tree will grow too large to fit in this variable. A new version of BK will soon be released to allow developers to continue to work even after this 64 thousand changeset boundary is reached. While explaining this, Larry also noted that there was a plan to update the BK license to provide a more precise definition of what is and what is not allowed. Specifically, as is, the license requires that you agree to not work on another SCM product if you use or have used the free BK product. Larry explains, "we've had some people who have indicated that they believed that if they used BK they were agreeing that they would never work on another SCM system. We can see how it is possible that people would interpret the license that way but that wasn't our intent. What we would like to do is change the language to say that if you use BK you are agreeing that you won't work on another SCM for 1 year after you stop using BK. But after that you would be able to hack on anything that you wanted."

Larry went on to note that the reason for this clause is to prevent people from using the free BK product, then to stop using it to work on a competing product, then to go back and use the free BK product again gathering more ideas, then to stop using it to further work on the competing product, and so on. For anyone unwilling to use BK due to its licensing, there are numerous alternative methods for obtaining up-to-date snapshots of the Linux kernel, and Linus continues to accept plain text patch files from non-BK users.

A recent disagreement on the linux-usb-devel mailing list ultimately led to the removal of the Philips webcam driver known as 'pwc'. The driver contains two modules, an open source module that has long been part of the mainline Linux kernel, and a closed source module which ships separately. Craig Rogers explained on the lkml that the closed source module ships in object format and "provides decompression services for proprietary codecs that are used for higher-resolution modes in some Web cameras based on this chip family." A hook in the open-source module allows the compression module to register with the kernel.

The actual disagreement was from the removal of this hook which was only used by the closed source module. Greg KH explained, "see
Linus's comments about 'if a change is needed to be made to the kernel in order to get a closed source module to work, that module must be made opensource' or something close to that." In response, the pwc maintainer requested that his GPL'd code be removed from the kernel, explaining why here in his own words. Greg KH offers his own explanation here.

Separate from the above debate around the removal of the hook, following the request for the driver's removal by its author it was pointed out that the driver is GPL'd, so the source code should legally be able to stay in the kernel regarldess of its author's requests. Linux creator Linus Torvalds replied, "yes and no. From a legal standpoint you're right. However, we should also be polite. If he's the sole author, and he asks for it, I think it's reasonable to honor his wishes. Of course if some new maintainer shows up and decides to infer how the device worked by looking at the original open-source code, that's also clearly fine. I don't want people to play lawyer. Honoring peoples rights to the code they write is more important than just the law."

A recent posting to the lkml suggested that the udev project has unfairly hijacked the devfs project, leading into yet another lengthy discussion comparing udev to devfs, and questioning why the latter has been deprecated. Linux devfs was written by Richard Gooch and merged into the 2.3.46 kernel in February of 2000. Since that time, Richard has stopped maintaining it, though a number of issues remain. During the 2.5 release cycle others such as Andrey Borzenkov have contributed fixes, though problems evidently remain with the actual design.

As early as 2001, Greg Kroah-Hartman began developing udev, working to implement the same functionality as devfs, but in userspace. Currently at version 010 [story], though not complete, udev is quite functional. For a good understanding of how it works, refer to this pdf from Greg's 2003 OLS talk. During the recent lkml discussion, 2.6 maintainer Andrew Morton acknowledged that though it has "architectural/cleanliness issues [...] devfs shall remain in 2.6 and shall continue to be supported." He went on to explain:

"Nor would I recommend that devfs be removed early from 2.7.x. We should wait until the proposed udev/sysfs solutions have matured in 2.6 and have proven themselves in the field. Only then will we be in a position to confirm that devfs can be removed without causing some people unacceptable levels of grief. There is no rush."