login
Search
"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."
practical vs best
It is best that all details of devices are disclosed and I remember the bad old days (1970s) when it was usually pretty easy to get details needed. At some point most outfits started to hide this information claiming it is secret for whatever reason. Unfortunately, today this is a very common case. Personally I would like to avoid all devices where information is not disclosed and encourage the use of devices from manufacturers who are more helpful. Unfortunately there is often an evil tradeoff to be made. I still use NVidia cards - they are only just tolerated because they really are very good and there is no comparable hardware with an open approach. A lot of people really just want their hardware to work and couldn't care less about software freedom (ignorance is bliss, isn't it?) and it is this majority which is being catered to by such NDA->driver development agreements.
Having done a lot of driver development on different systems over the years, I can say that it takes some special talent to be able to correctly interpret the documentation for chips - I have never encountered documentation that does not have faults which force you to do experiments to clarify things. Often these are very subtle and easy for most people (even experienced driver developers) to miss - so I'd really prefer that any driver developer can look at the specs and play around. The NDA scheme makes this implicit assumption that the developer will get the core of the driver perfect and that any other problems will be between getting the data between the driver and another layer of code. I definitely do not want to encourage this silly idea that it's OK to keep everything secret because kernel developers have now agreed to it, but there is a dangerous area between attempting to support more products and thus gain a larger user base and losing the war on open device specifications. Personally, I can't imagine how the code can be made maintainable and publicly available while being fully compliant with an NDA. I'm waiting for these drivers to appear so I can have a look myself at some maintenance issues - but not knowing what is in the NDAs, I can't really evaluate the compliance situation.
Maybe
Maybe Theo is right.
Lets hear about what Richard Stallman says?
I think he is right in this
I think he is right in this case.
Some reasons for signing NDAs might be acceptable for a short time (for marketing purposes), but other than that signing NDAs is very contrary to the free software spirit.
Remember it all started with a printer driver and when someone who had the necessary information to fix it basically told rms, "sorry I can't share that. I promised someone not to share it".
NDAs for technical information are basically just that; a promise not to share what can be shared at near zero cost. It is a detrimental and anti-social practice, and developers should not easily accept them.
I do not run any BSD systems myself, but I can sometimes understand Theo's emotional tone when he tries to explain that if we don't hang together we will hang apart. I feel all Free Software operating systems have a moral obligation to stand up for eachother, and the ones who have the most momentum should not use that to gain an unfair advantage of the others.
The main problem with NDA'd
The main problem with NDA'd code is it's practically unmaintainable, you cannot document or comment the code and say "what this code is doing is ..." for some obscure quirk of the device.
Probably the same, RMS
Probably the same, RMS presented Theo de Raadt the 2004 FSF award citing amongst other things his commitment to free software. Around that time Theo de Raadt was trying to obtain free distribution of many wireless firmwares without restriction.