I am not a kernel programmer, but couldn't someone code a driver from this project, and make it documented enough that the BSD's could make a driver from the GPL work?

Well, he used the same words that I used about this, and I say more, so what? Drivers with a lot of structs with a lot of hexa numbers. Hey, but it is GPL'd! Well, a GPL'd code that is useless to anyone without the documentation. The Linux guys are so wrong about this at all. Where is true freedom? I would really like to know Linus about this. He doesn't care? Putting code in the Kernel that just one or two people can understand?

Well, since he has been wrong once, maybe the BSD folks have a point.

As much as I agree - in principle - with the concerns raised (I'm not convinced that Greg's "strategy of small steps" is not a better idea than the BSD fundamentalism, but I'm not convinced that the short-term convenience of a working GPL'ed driver is worth the long-term problems that come with "officially" [insofar as that Greg is a core Linux kernel hacker] sanctioning NDAs, either), but I've got to say that all the BSD developers participating in this thread - Rickauer, Peereboom and de Raadt - come across as (I'm sorry for being blunt) total idiots.

Way to go, guys. Greg was right to killfile Rickauer (I would've done the same thing to all of them myself); you really need to get it into your heads that if you want to convince someone of your position, it's not a good idea to insult and flame them.

I really like OpenBSD, but I can see why the BSDs in general and OpenBSD in particular are - ultimately - niche projects that failed to ever attract a larger userbase beyond the hackerish types (which, I might add, is a pity - but it's the fault of people like de Raadt etc., so they really have noone but themselves to blame).

Ah well. More power to Greg - even though NDAs are bad, and even though I think he's doing the wrong thing here, I'm glad someone's sticking it to those asshats.

I think before we try to have a debate on this, we should take down some of these strawmen.

First of all, Linus is not going to let anything into the kernel that is literally obfuscated. So any NDA'ed device drivers will presumably be correctly formatted, and with some minimum level of structure and comments.

Second of all, nobody said anything about allowing patented or trademarked code here. Marco Peereboom injected that into this debate, along with some kind of completely OT discussion about Java.

Stephan A. Rickauer seems to be laboring under the delusion that hardware companies care about being seen as "open," and want to use this driver collaboration program as a way to get a PR bonus. In reality, most hardware companies care little about what the open source community thinks of them. It doesn't sell widgets. Their main customers are usually OEMs or kids who want to play Quake {$n+1}. OEMs are locked into contracts that force them to put Windows on every machine, and serious gamers need to use Windows because it's where all the games are.

I'm not sure how I feel about this whole issue, honestly. I agree that NDA'ed drivers are much less desirable than ones obtained from open specs or reverse engineering. They are probably just a step above running Windows drivers under emulation, like ndiswrapper does.

However, a lot of people seem to have the mistaken impression that if we keep holding out for open specs, the hardware companies will eventually break down and say "oh, you guys were right, we *have* to open up our hardware!" I'm sorry to say this, but it doesn't work like that. Hardware companies make their decisions based on financial considerations. They want to minimize risk. Even opening up the specification for obsolete, 5-year-old hardware can potentially open them up to patent infringement suits. In contrast, giving the specs to one person who is under an NDA is a much more controlled risk.

The choice is not, as Theo de Raadt seems to believe, between "forcing the companies to open up their specs" and accepting an NDA'ed driver. There is no "force" here-- no way that Linus or anyone can compel them to open up their specs. It's their own decision, legally speaking. The choice is between a closed-source binary driver (like the ones NVidia keeps pumping out), and an in-tree NDA'ed driver, which might be a little bit less informative than it could be, but which should still be a good starting point for reverse engineering and exploration.

I'm sorry to hear that there is such a big disagreement between the Linux and BSD camps on this issue. I think it's good for Linux to have competition and I hope that BSD is able to keep up on the driver front, whether by reverse engineering or otherwise.

It would be nice if companies would hand over docs without an NDA.. that is certainly preferable for everyone.. but some of them just won't, and getting them to hand over docs under and NDA with the ok for someone to write a free driver (be it GPL or BSD) - that's something and it shouldn't be ignored.

Now, if companies start doing this and drivers start showing up as GPL, but without the documentation, you guys can go ask the companies for the docs yourself (with or without NDA) and make your own driver using the GPL driver as a reference implementation.. or you can reverse engineer the GPL driver, it's certainly a hell of a lot easier than trying to reverse engineer a binary driver isn't it?

I'm sure Greg and his merry band will be pressing for docs without NDA, but in the event that an NDA is the only way forward, it's certainly better than no driver at all.

Finally, just let me say, docs are not the be all of driver development. Great to have them, but docs can be wrong and you won't have any idea until you implement them. At least a driver, you can test. So unless you intend to start asking hardware companies for their VHDL, you're better off having a working source code driver to confirm the docs (if you can get em) are accurate.

First time I read about this "free drivers & NDA's", I started thinking "How are they going to do this? How can they make this happen and avoid 'being tainted' afterwards?" Only way I can think of is for one person (or persons) to sign the NDA's and convey the "driver writing information" to other person(s) - this way drivers are fully GPL and as open as possible, for all to use, reverse engineer etc. That's just my 0.2 € on a matter of implementing this.

On the matter of strong words exchanged, it is understandable that people feel strongly about certain things (otherwise they, nor their words, wouldn't be here) but calling someone idiot, stupid or derogating other side in an argument is, in my experience, best way to make them not listen to you.

And BTW, I completely agree with QuantumG - it is far better that the closes binary blob; anything is better then nothing .

i'd say that the guy, who codes the driver, based on NDA-locked documents, should also document his code properly. But he can't because he is bound to the NDA, and hence cannot explain why he is doing certain things in his code.

this will make it harder for people who come after the NDA-bound developer, who want to extend or fix the driver: they still will be bound to do reverse engineering, reverting back to the initial situation: no docs available.

i don't think developing drivers based on NDAs is the way to go. imho, only the full and unlimited disclosure of the hardware provides the basis for good and maintainable drivers

...And understating.

Marco Peereboom:

Exactly, Copyrights + GPL. What a fantastic combination! You
get inherent patent protection because no one can use your code and copyrights take care of the rest.

This isn't true: anyone can use your code, if they obey the terms of the GPL (which says that you must licence your patents to producers of derivative works). That it can't be close-sourced is a win for the "GPL hippies"; far from being beaten, they win.

However, this too is unreasonable:

Greg KH:

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.

But for you to try to tell me that I shouldn't work to achive my goal, as it somehow conflicts with your goals, is pretty rude, don't you think?

The purpose of the GPL is to maximise freedom in a utilitarian sense. That is, the freedom to the community, rather than the next developer. For specs not to be released obviously harms the community interests. Possibly they gain more than they lose by having a GPLed driver available (which is, on balance my judgement), but it's not cut and dried.

Goals clash inherently, but political activism is open to us all; discouraging, or even obstructing NDA-based development is legitimate by the same logic that drives developers to use the GPL in the first place to disrupt closed-source derviatives and hence create an incentive to produce open-source derivatives.

I find it somewhat humourous that each side here has their arguments backwards. In the GPL corner, we have "What right have you to tell me what to do?", and in the BSD corner "It's important to limit what contracts you can accept, so as to maximise overall freedom". Ho hum.

I can understand the NDA argument, but this portion of the email is pretty unedifying:

"What a fantastic combination! You get inherent patent protection because no one can use your code and copyrights take care of the rest."

Err, except that putting X out under even GPLv2 will implicitly grant the relevant patents to anything that's actually implemented in X. When the license explicitly reads something like 'You have the right to use this code and modify it and distribute it', it pretty much estops Sun from using patents to prevent you from doing what they've just affirmitavely said you can do.

"Now Sun gets to shut up the open source world; hey we "gave" you (some) of our code now didn't we? And they get to pretend to be open source friendly to boot! The GPL hippies are beat at their own game :-)"

Errr, what's your frigging problem here? As far as I know, Sun haven't obfuscated the Java code, so this isn't that NDA thing.

How is 'pretending to be open source friendly' by putting out your flagship product under the GPL any different from actually being open source friendly by putting out your flagship product under the GPL? Are you moaning because it makes financial sense for them? If so, good! This isn't a zero sum game, and we're not here to demand altruism. I'm as anticapitalist as the next man, but if it's profitable for Sun to turn Java into free software, it suits me just fine.

Or is this just a crybaby whine because they didn't put Java out under YOUR favourite license? Awww izzy wizzy wazzums den. There's you, there's your computer. Feel free to write your own sodding BSD Java.

I always wondered why Linux users got the reputation for zealotry when BSD weenies are just as prone to shrill, pointless bitching.

Yet another religious argument between licensing purists. Personally, I prefer open-source software, but more than anything I just want software to work. A pure-minded piece of software that doesn't run on my hardware is useless to me. I think in general Linux strikes a good balance between practicality and ideology.

I love it when *BSD folks rant and rave about the perils of having more GPL-licensed drivers out there when their own drivers can be used for whatever purposes by anyone without any code ever having to be contributed back. And yes, Theo is still immature--film at 11!

Can't understand the fuzz some very idealistic people are making.
This is simply an attempt to get more reliable drivers into linux and will work out or not.

If it works out, Linux get more drivers, it's not an consequence that BSD-licensed driver development is being hurt.

If it doesn't work out, nothing is lost but time.

It is highy hyphothetical to state that this offer will cause damage simply because it allows companies not to release their specs to the public.

Making things short - I am wondering, did anybody in the Linux kernel world ask the question "what are GNU licences for" and "what is freedom"?

Greg, Linus and other guys simply, selfishly, sold the whole community.
Yes, _they_ will have *their*, trusted code in *their* kernel. What a pity that nobody else will be able to actually reuse it, because nobody will really know what actually this code makes with the hardware and how to modify it.

Thus, this "GPL'd" software will be nothing different than a binary blob.

Making free drivers, and promoting NDA's in linux kernel, Greg, are two completely different things. I do understand that linux kernel badly needs the help of vendors. But do you need it that badly to actually sell the reason of making FLOSS? Not only freedom, but actual openness as well?

Yeay for the free software and myopia of some hackers.

...though certainly not the worst one. This is what this sort of code looks like:

http://lkml.org/lkml/2006/11/3/149

What exact inputs trigger the issue? Why only CD burning? 0x1fff must explain it, don't look behind the curtain!

While this is vendor-supplied code, if a developer under NDA succumbs to pressure from the vendor to obfuscate or not document, there is no recourse. Hint: The developer is often a contractor who would like to get paid.

Your votes please!
OSS_needs_hardware_documentation_without_NDA

There is a legal couterpart for anyone selling products in france (and I think europe): Providing all needed technical information about a product bought there if a customer requires it!

The real problem is the lack of class-action => You will probably win, but after years of individual battle that will cost a lot, just to get specs that become obsolete ine the meantime. I think this is the reason why no-one uses this possibility.

But maybe the FSF could handle this and kick nvidia/ati/connexant and others asses so hard some day... that they would publish their specs...

I'd guess that Linus isn't overly concerned. I doubt he has the capacity to check that every patch he receives is backed by documentation. I don't think he likes nda's but I also don't think he has the power to combat them like tdr does.