Novell Makes Linux Driver Project a Reality

apokryphos writes "Novell have relaunched the Linux Driver Project by dedicating well-known kernel developer Greg KH to work on the project full-time. Greg KH writes: 'My employer, Novell, has modified my position to now allow me to work full time on this project. Namely getting more new Linux kernel drivers written, for free, for any company that so desires. And to help manage all of the developers and project managers who want to help out...They really care about helping make Linux support as many devices as possible, with fully open-source drivers.'"

Comments

Cool

[PhrostyMcByte]

I'm not sure how much just one developer can do, but props to Novell nonetheless.

Re:Cool

[deek]

I'm not sure how much just one developer can do, but props to Novell nonetheless.

Never fear, because he's not doing all the coding himself. According to the link in the article, he's had over 100 volunteers to help him out. If he's good at managing them, then 100 talented coders could certainly make a large impact!

Re:Cool

[Enderandrew]

Stop trolling, and educate yourself.

http://www.novell.com/linux/microsoft/faq.html

"Under the patent agreement, both companies will make up-front payments in exchange for a release from any potential liability for use of each others patented intellectual property, with a net balancing payment from Microsoft to Novell reflecting the larger applicable volume of Microsoft's product shipments. Novell will also make running royalty payments based on a percentage of its revenues from open source products."

Novell is paying for being liable for using Microsoft patents, and will also make running royalty payments. If no one violated these patents, then why pay for protection?

It sets a legal precedent that apparently you weren't aware of. Google can help you out with that. So stop the personal attacks and shouting, and please read up on the issue.

Re:Cool

[tomhudson]

This was a cross-licensing deal that had NOTHING to do with any patents in linux. Read the bottom - its about Mono (which has nothing to do with linux) and virtualization technologies:

Q. By making it easy to run Windows virtualized on Linux, isn't Novell undercutting its own Mono project, which shares a similar goal?

Mono provides developers a way to run applications designed using Microsoft .NET technologies to run on Linux and other platforms. Its main focus is the Linux desktop, where Mono has been leveraged to build a series of new services, including search, music playback, and more. Virtualization focuses on maximizing the value of server hardware by running multiple operating systems. It is used for server consolidation, workload balancing and other corporate needs. So while both approaches are designed to give customers flexibility in their IT systems, their focuses are quite different.

Q. What does the patent agreement cover with regard to Mono and OpenOffice?

Under the patent agreement, customers will receive coverage for Mono, Samba, and OpenOffice.org as well as .NET and Windows Server. All of these technologies will be improved upon during the five years of the agreement and there are some limits on the coverage that would be provided for future technologies added to these offerings. The collaboration framework we have put in place allows us to work on complex subjects such as this where intellectual property and innovation are important parts of the conversation.

Now lets see ... is MONO part of the linux kernel? Nope. Is Samba part of the linux kernel? Nope. Is OpenOffice part of the linux kernel? Nope. Is .NET part of the linux kernel? Nope. Is Windows Server part of the linux kernel? Nope. And those last two are what Microsoft is paying Novell for (which is why the net flow of money is from Microsoft to Novell, and not vice verse. Microsoft uses a LOT of Novell's IP).

So, there is not a SINGLE part of the agreement that has anything to do with linux, and most of it is money from Microsoft for Novell IP in Windows Server and .NET.

Not a single Microsoft patent in linux, and the agreement doesn't say otherwise. The only one saying so is Balmer, and the "useful fools" who believe what he says; show ONE Microsoft patent in linux. Microsoft has had a year to do it. They can't. Neither can you; the deal was not for "patent coverage for linux."

Re:Success Stories?

[Anonymous Coward]

Just curious, but where is the list touting the manufacturers that stepped forward and provided documentation (and consequently which new hardware is supported). Be nice to see what progress this campaign has made and is continuing to make.

Here's one:
http://arstechnica.com/journals/linux.ars/2007/09/21/amdati-release-register-specifications-novell-follows-with-alpha-driver

Re:Still not the Right(TM) way

[Eivind Eklund]

Having worked both directly with hardware developers (as an embedded systems developer) and with kernel development, this is not quite that clear to me. In some cases, the hardware knowledge side is the most important; in others, the kernel side. Mostly, the kernel side of things is harder to learn than the hardware side, though, so the kernel development skills is the important side. Also, kernel developers often have more experience with working with different kinds of hardware, so they will know how to trick around the particular piece.

And, importantly: For a LOT of the hardware on the market, what's important is the chipset used, not wiring around it. And the "hardware manufacturer" has often only done the wiring.

Eivind.

not the case

[free space]

If that is indeed what worries the original poster then he can res assured, from the project's FAQ:

Q: How are you going to write a GPL driver by signing an NDA? Is it going to require a binary blob or some other way of obfuscating the code?

A: No, not at all. I have written many drivers after signing NDAs with companies. They are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, nothing will be obfuscated at all.

Re:not the case

[mystran]

Having written one or two drivers for a completely irrelevant toy operating system of mine (making me just marginally less incompetent to comment on this thread), it is very helpful to have datasheets that actually describes the operation of a given device, instead of just something like a list of it's registers and their meaning. Even descriptions of sequences of commands required are not always helpful without understanding the internal workings of the device. The resulting code ofcourse has to take all relevant device details into account, but the code itself is typically not sufficient to figure out anything beyond what the original code has at least attempted to take into consideration, if even that (ofcourse any sample code is invaluable when trying to decipher datasheets but that's another issue).

So based on what little I understand about the whole subject, I'd say letting somebody develop a driver under NDA and just releasing the driver source instead of all the documentation is likely to keep a LOT more details about the device essentially secret, even if the code itself was pretty decently commented with remarks about the particular implementation (assuming ofcourse that said internal documetation isn't duplicated in the comments).

Ofcourse that DOES have the effect that anybody willing to improve the driver functionaly in regards to the device would need the same documents under NDA (or reverse-engineer the relevant details, which might be easier with a working driver to tweak), but at least a source driver let's the kernel developers deal with things like driver API changes internally. Say, you want to change the protocol by which drivers reserve IO resources because you've found a new, totally fair way to do that. Now, with binary drivers you can either break the drivers or implement workaround wrappers. Source drivers, you can simply change the driver code yourself without having a clue what the driver actually does. :)