Submitted by “Yes, that’s right, the Linux kernel community is offering all companies free Linux driver development. No longer do you have to suffer through all of the different examples in the Linux Device Driver Kit, or pick through the thousands of example drivers in the Linux kernel source tree trying to determine which one is the closest to what you need to do. All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while. A few sample devices might be good to have so that debugging doesn’t have to be done by email, but if necessary, that can be done.”
“I will also be available at FreedomHEC 2007 held adjacent to WinHEC, if anyone wants to bring devices and work face-to-face.”
To all of you video/wireless/whatever vendors with your proprietary, standards-non-compliant gear, I must say: go to HEC!
NDA is mentioned. I think we have a revolution here growing. BSD / Haiku/ AROS/ Syllable have a fighting chance if NDA does not accompany products. Windows are doomed.
Three massive cheers for the kernel developer community! This is great news and excellent thinking.
That’s a few less excuses for the device manufacturers.
If the hardware suppliers want driver on linux for free they should have released the spec of their hardware long time ago …
I think the important part here is that the Linux kernel community is providing options in a language that the hardware vendors can understand. They aren’t making demands, they are making an offer that’s hard to turn down.
They’ve effectively turned the issue on it’s head. “We will supply kernel engineers to build your driver at no direct cost to you if you merely cooperate.” Not “cooperate or we won’t be able to make a driver.”
Other than a formal statement expressing the kernel community’s willingness to develop (open source) drivers with NDA specifications (which has been a prevailing sentiment for some time), there is nothing effectively new here. The kernel community has always been willing to develop drivers and maintain them in-tree with the rest of the kernel. But now they’ve restated their intentions in clear and direct language.
When put this way, it seems like an offer you can’t refuse. For any hardware vendor that doesn’t have a Linux driver, excuses have become nearly impossible to imagine. This statement makes the issue of Linux driver support (and continued maintenance thereof) an issue of dollars and cents. When the lawyers say to the CEO that they’d better avoid open source drivers to stay on the safe side of intellectual property law (because it’s 100x easier for a lawyer to say no than yes), the CEO will look at the bottom line. Well, it won’t cost us anything, so I say the heck with it, tell the bearded folks the specs are on the way.
On the other hand, I don’t believe nVidia/ATi is the target audience of this offer. These vendors have the resources to continue to wrestle with providing binary drivers for a moving target, and they might be fine with continuing this development model.
They also need to face up to the fact that the community has the resources to reverse engineer heavily demanded drivers within a reasonable time frame, even without their cooperation. The Nouveau project is projecting a stable 3D nVidia driver before the end of the year, and the early progress suggests it might be even earlier (and with possible performance advantages over the proprietary driver). If they don’t cooperate, we’ll eventually go over their heads and make it happen anyway.
Does *not* get any better than this, that announcement makes the Vista launch puny by comparison on the richter scale of computing scene impact and effect.
This is the interesting part:
From the Announcement: If your company is worried about NDA issues surrounding your device’s specifications, we have arranged a program with OSDL/TLF’s Tech Board to provide the legal framework where a company can interact with a member of the kernel community in order to properly assure that all needed NDA requirements are fulfilled.
Companies could have given out specs before, but often they didn’t for legal reasons, this seems to be addressed now. Any manufacturer not jumping in on this is not interested in making money, simple as that.
I hope you’re right. I first thought when reading the announcement that there was nothing new about it except a great PR movement. But you might be right that this legal framework for NDA requirements might be what was missing before.
However, I have a question. If a manufacturer don’t want to give out its specs, even if the kernel guy who writes the driver doesn’t give them out, the open source driver will be there for anyone to look it. I don’t know much about drivers and hardware, but I thought that reading a driver’s source code was as good as reading the specs, if not better, to know how something works. Or am I wrong and the driver reveals nothing important about the device?
If a manufacturer don’t want to give out its specs, even if the kernel guy who writes the driver doesn’t give them out, the open source driver will be there for anyone to look
The spec might not be available as a separate document but be part of vendor internal documentation describing other details of the device.
A developer under NDA could be given access to the whole documentation and only the information necessary for interfacing with the device will end up in the driver code.
The spec might not be available as a separate document but be part of vendor internal documentation describing other details of the device.
Exactly, and it’s easier to just give the developer access to those documents, rather than having someone write a spec. Or have him go through the internal documentation, removing the parts the company don’t want public. It’s both a costly process for the company. And it’s likely the person(s) responsible will err on the caseous side and remove too much, making the spec lacking.
Using a NDA makes more sense not only from a busness and economical point of view, but also from an engineering viepoint.
Edited 2007-01-30 19:26
What documents? I agree with you in principle, but in practice these hardware vendors have to be so quick to market that there isn’t usually ANY natural language documentation.
As Linus has said many times, the source code is the only valid documentation. Any print documentation is inherently out-of-date and/or inaccurate–at least in the commodity space.
That’s why many hardware vendors will choose the part of the offer where they supply an engineer’s email address. “Well, I don’t know how that register works, but I do know that we set it to 0xFFFFFFFF in our Windows driver.”
Edited 2007-01-30 22:03
What documents? I agree with you in principle, but in practice these hardware vendors have to be so quick to market that there isn’t usually ANY natural language documentation.
The programmers in the company that wrote the Windows driver almost certainly had some kind of documentation – it’s unlikely they wanted a hardware engineer on the phone with those guys practically 24/7. It may be incomplete or outdated, but it would at least be a good starting point.
A developer under NDA could be given access to the whole documentation and only the information necessary for interfacing with the device will end up in the driver code.
IANAL, but I suspect that the NDA situation will still have to be handled via a clean-room type of scenario. A developer under NDA (likely working under the OSDL/Linux Foundation) may be given access to engineering information necessary to create the driver, but will probably have to create a non-infringing spec that the kernel devs will use for coding against.
There’s too big a liability for kernel devs coding under NDA’s since there’s an inherent risk of tainted code inadvertently getting into the kernel, and it could ultimately handicap the kernel devs on potential future code contributions they could make. It’s bad enough that MS is making ambiguous claims about MS-owned “ip” in the linux kernel, it would be very dangerous for commercial companies to have a legally valid paper trail backing up similar accusations. Even companies like IBM and HP keep their OSS and proprietary developers separate to prevent the risk of code taint in either direction.
Letting an independent party under a binding NDA have access to the necessary information in order to produce a vendor-approved design spec for the non-NDA’d kernel devs provides necessary legal protection for the devs and the kernel in general. This is also important for the vendors because it not only allows them to maintain control over the degree of information publically released, but can help ensure they themselves remain in compliance with licensing agreements, since in many cases vendors cross-license technology from other companies and are obligated to prevent it’s public disclosure.
I know things like that may not fly as well with the free-software side that would want full disclosure on every aspect of the hardware, which I agree would be ideal, but I think it’s a reasonable compromise that respects the legal concerns vendors may have. Of course, that whole process is not much different than what they do now with reverse-engineering, but at least it should cut down the development time considerably, particularly if they have access to back-channels at the vendor for troubleshooting support.
But like I said, IANAL and maybe they’ve worked things out differently.
On a side note, I also think that, to a certain extent at least, it may help the business case for vendors that may otherwise be willing to support linux but unable to invest in any resources to do so. It’s very difficult to build business cases for resource allocation when you have absolutely no form of metrics or potential market to even ballpark an ROI, that’s just business reality. And there are already precedents for vendors that have basically out-sourced linux support to community developers, unable to justify the business case internally with the beancounters.
Personally I think this is a good thing, though I’m taking a cautious wait-and-see attitude before becoming overly optimistic. They’ve eliminated a barrier for entry that may or may not have existed for many vendors, we just need to see if those vendors will step up now.
Just my 2c…
Luis: I don’t know much about drivers and hardware, but I thought that reading a driver’s source code was as good as reading the specs, if not better, to know how something works. Or am I wrong and the driver reveals nothing important about the device?
I’m certainly not an expert on driver development, so if somebody has more information, please share.
That being said, imagine the device as a black box, an encapsulated object that offers a documented interface — “the specs.” If you know UML think of a class diagram. That’s all you need to operate the device but you don’t know anything about what’s happening inside. That’s basically it.
Yes, that makes sense and you’re probably right. But then it’s even more difficult to understand that manufacturers don’t open source their own drivers. I always thought it was because those drivers would reveal the secrets inside the device.
But knowing how the usually act it might be for many other reasons. Go figure.
Then it will be our duty to buy hardware from those manufacturers who decided to collaborate with the kernel hackers.
Definitely a sweet way of voting with your wallet!
This is great for the hardware vendors. Now you have two groups (windows and linux) who will buy your hardware instead of just the one. More groups = more sales.
Is this similar to what Theo and the gang from OpenBSD has been doing? I know they have requested hardware specs from a lot of vendors.
“Is this similar to what Theo and the gang from OpenBSD has been doing? I know they have requested hardware specs from a lot of vendors.”
The OpenBSD people have specifically requested fully open documentation which is not encumbered by NDA. They don’t accept NDAs, binary blobs, obfuscated code full of magic numbers or any other shit like that…
I’m a bit worried by the willingness of Linux developers to go along with NDAs. This probably results in code where we have lines like “#define MAGICNUMBER1 0xblahblahblah” without any explanation what magicnumber “0xblahblahblah” is and what it does. This results in open write-only code which is practically unmaintainable. And if we give signal that this type of thing is OK then eventually most vendors will start requiring NDAs.
I think it would be much better if Linux (and FreeBSD) developers joined the OpenBSD projects quest for truly open documentation. That is the only way to have some guarantee that we have maintainable and good quality code which allows us to further develop free systems and fix problems in them.
Of course open documentation would be the way to go, but the fact is it will take a LONG time to get there, esp. since the device manufacturers don’t have much to gain.
Even if the code resulting from NDAs *is* in effect “write only”, this may be appropriate considering the devices themselves have a sort of “one-off” nature. Given today’s proprietary hardware market, where device makers change the internals of their designs all the time to cut costs, and different “versions” of the same product often use a wide range of different chipsets, I’d say that rapid, usable driver development is more important than “maintainability”.
Once the dialogue with the hardware makers has been established, then perhaps the push for open platforms can begin. But right now, all the manufacturers would see are higher costs. Meanwhile, most end-users can’t see the value proposition in *not* buying whatever cheap commodity hardware is on sale at Fry’s today. It’s the chicken and egg problem: open hardware doesn’t exist because Linux has too small of an installed base. But Linux can’t increase its installed base if it requires open hardware.
Now is our chance to make inroads into the mainstream sector in real ways. The question is: Do we want to wait around forever for the open-source utopia to coalesce, or do we want to leverage the opportunities that are presented to us right now?
I think this is a good idea.
BUT!
What about existing code from existing specs that’s already in the kernel?
I’m talking about security. I know I’m going on a specific track here, but from what I’ve heard/read most of the security issues surrounding the kernel itself are from poorly written modules and drivers that are inserted and not kept up. OSS modules, AFAIK.
Now, don’t get me wrong I’m all for bringing in new code, new drivers and expanding our operational base among more and more devices and obscure devices….
But I think it’s a valid question.
In the meantime of waiting for more specs to come in, why don’t they upkeep and close holes of existing code? The sourcecode and/or specs may not be forthcoming anymore to make the driver itself, but the holes can certainly be closed.
Can’t they?
Edited 2007-01-30 18:47
Does anyone have detailed information on how NDAs are handled? I don’t understand how this is going to work if a hardware company’s stance on NDAs is “no driver source code may be revealed”. Note that this may be due to reasons out of the company’s control, so there is little point in argueing how “lazy” or “uncooperative” the company is (e.g. agreements with other hardware vendors over parts of a device).
Take a read on OLPC XO example on your question:
http://www.olpcnews.com/software/operating_system/a_blizzard_of_olp…
Surprisingly for some people and for a rare moment, it was Microsoft (yes, themselves) and HP that allowed Open Source SD implementation.
This is excellent news. Perhaps this will drive a greater level of hardware support from hardware vendors. I don’t think this is a “killer move” but it’s certainly a great opportunity for companies to embrace Linux.
I didn’t have much respect for Greg K-H before this due to the snafu with binary-only kernel modules (and his inane poem). He seemed to be a Linux triumphalist (Oh, look at how much better our kernel is than NT! Everyone sucks but us!) more concerned with politics than with technical excellence (let’s break proprietary modules just for the hell of it by removing symbols for no technical reasons!).
This free driver development initiative, on the other hand, is the most positive thing he could have done to promote his conception of Linux driver development. Rather than making threats, these devs are finally extending an olive branch to IHVs. I really hope some people take them up on this offer.
A thought just came to mind, though. Who owns the copyright on the driver code once it is done? Can an IHV take the kernel code thus produced and dual-license it in BSD or make a private branch to port to Windows or OS X? I’m interested in the response to this.
Having one programmer write the driver against an NDA flies in the face of Open Source. This helps NOBODY!. Say the driver developer got run over by a bus, now who the hell can support his code if there are no docs. I’d much rather have a company maintain binary drivers and if the lead developer at the company goes away, they will hire someone else to take his place.
Just a quick note to let everyone one know that I managed to grab a short interview with Greg about this for tonights (9:30pm AEDST (UTC+1100) episode of Open Source On The Air.
Details can be found here: http://www.localfoss.org/OSOTA/Promotion/31-01-2007
Awesome! Any chance you’ll be making a podcast available?
Edited 2007-01-31 15:30
Why yes
http://www.localfoss.org/OSOTA/Episode_14 <– Thats our latest episode.
What do the actual hardware vendors have to say?
I know Realtek has a good relationship with open source, as do a handful of other vendors, but what about the likes of Marvell, Nvidia, Broadcom, ATI, Matrox, Cirrus Logic, Texas Instruments, etc.?
Wireless and graphics are the two major areas of the system where open source could use the most help, especially if the community wants to see the likes of Linux finally become acceptable as a complete desktop solution for Mom and Pop Joe Blow next door.
This goes without saying that unless there is an application base available that the majority of people can accept and use, it’s not going anywhere, but hardware support in the two areas I mentioned helps more than some might believe.
I can’t use my laptop with any distro out of the box because the wireless chipset isn’t readily supported by a kernel-level driver. NDISWrapper has to be used and I still need the firmware used in the Windows driver for it. For Mom and Pop Joe Blow, that’s a big pain just to talk with a router.
Hardware driver had really been a hurdle to Linux, this move is brilliant! Good job, keep up. By the way I am also using ndiswraper. Hopefully in future I don’t have to
Edited 2007-01-31 22:28
//Hardware driver had really been a hurdle to Linux//
Are you sure about that?
Hardware support on Linux is better than Vista.
http://www.desktoplinux.com/articles/AT9325931427.html
“I found that MEPIS actually has better hardware support for this PC than Vista.
Now, that may change as Microsoft puts dollars into hardware vendors’ hands to support Vista. But, for now, if you’re going to upgrade your operating system on an existing PC, Linux gives you the better shot of everything working correctly.
On the other hand, if you’re planning on viewing or listening to DRM-protected media of any sort, Linux is clearly going to give you better hardware support. By incorporating DRM into the operating system, Microsoft is going to make it very difficult for everyone from PC DVR (digital video recorder) users to just a guy who wants to play a DRM-crippled CD to be certain that everything will work properly.
“