Part 2 Of Nouveau Saga: The Microcode
Only a few hours have passed since that second news article, but more messages surrounding the Nouveau status have been sent on the kernel mailing list and dri-devel. Maarten Maathuis who has worked on the Nouveau project responded saying that Nouveau isn't in the kernel yet (as far as he knows) because the project is unsure over the legal status of some microcode.
You assume that Red Hat has full control over the project, which i don't think is the case. The reason it isn't in staging yet (as far as i know) is because of some questions over the copyright of some (essential) microcode. Either the question needs to be answered, or it has to be reverse engineered to the point that it's possible to generate it.
Like most graphics drivers, the Nouveau driver is reliant upon loading in some microcode/firmware for it to work. In the case of Nouveau they load up this big batch of microcode for the GPU initialization, but the problem is they are unsure of what this microcode even does or what is its legal status is with regards to copyright and redistribution. This microcode can be obtained when using REnouveau to (cleanly) reverse-engineer NVIDIA's display drivers using memory mapped I/O register traces, with the steps to fetching the ctx_voodoo being documented on their Wiki. Without ctx_voodoo, the Nouveau driver cannot function. Legal situations can be messy, especially when there is no support from NVIDIA for this project, but they stand neutral on the matter of Nouveau. NVIDIA's Andy Ritger had said the following when we had interviewed him at Phoronix, "The guys working on nouveau have done a really incredible job so far. However, our policy remains the same: we won't try to hinder their efforts, but we have no plans to help them."
In response to this "excuse" of microcode uncertainty, Linus replied:
I think people are just making up excuses, as evidenced by the fact that you're quoting a different excuse than I've heard before.
The fact is, if there are license questions, then Fedora had better not be distributing the code either. And they clearly are.
And don't tell me about "full control". There's absolutely full control over it being included or not.
When I brought this up at the kernel summit, there were various other random excuses. I think one of them was that it wasn't part of an official Fedora release (which is sure as hell not true at least as of Fedora 12).
I've heard the "but it's hard to merge" excuse too - which I also know is bullshit, because I can look at the git tree Fedora apparently uses, and it merges without any conflicts what-so-ever.
The most common excuse is the "oh, but it might change" crap. But that's not even a very good excuse to start with, and it's what staging is for anyway.
Somebody even made the crazy comment that "but Fedora isn't a real distribution, so it doesn't need to follow the rules everybody agreed to several _years_ ago wrt merging stuff to mainline".
I _think_ that last one was meant as a joke. But it's damn hard to tell, because the ones that are apparently sincere are equally crazy. People just seem to make up total crap to make excuses for something that everybody knows is wrong.
Linus
This microcode issue is also why Nouveau support had not shipped with FreeBSD 8.0 in its kernel, as was shared in the thread by the FreeBSD X/Mesa maintainer, Robert Noland. Alan Cox has called upon Linus to just merge the code seeing as he is the maintainer of the Linux kernel master branch.
Just minutes ago, however, David Airlie who is the DRM maintainer and a Red Hat developer that is involved with the Nouveau project, has provided his response. Due to this troubled microcode, Red Hat cannot provide a "Signed-off" copy of Nouveau for inclusion into the Linux kernel due to this legal uncertainty. As David went on to mention, if the Nouveau driver supported the kernel's firmware loader interface, this ctx_voodoo microcode could be separated from the driver so that this potentially troublesome work would not land in the kernel but could be redistributed separately, it may help in this situation. However, no one has done this firmware loading work yet.
This microcode issue for the Nouveau project could certainly be a legal problem, but as of last check, no one has actually approached the Linux Foundation, Free Software Foundation, or Software Freedom Law Center for any assistance in determining the legality of the ctx_voodoo microcode or for obtaining permission from NVIDIA to use this blob. One of these foundations should be more than willing to help, after all better free software graphics drivers have been a priority for the FSF and the Linux Foundation is currently working on 3D patent issues for OpenGL 3.x support in free software.
As far as we know, NVIDIA has also not approached Red Hat regarding problems with them shipping this microcode in their Fedora releases. Nouveau continues to be available in Fedora. Canonical is also planning on shipping Nouveau support in its kernel for Ubuntu 10.04. If NVIDIA did pursue Red Hat, Canonical, or even the lone Nouveau developers over their use of this microcode they obtained through clean-room reverse engineering, it would generate an immense amount of negative publicity for this major, publicly-traded company as being an attack against free software and Linux. This should not be an issue.
29 Comments
