Device drivers and non-disclosure agreements [LWN.net]

Device drivers and non-disclosure agreements

Posted Oct 9, 2006 23:35 UTC (Mon) by drag (subscriber, #31333)
In reply to: Device drivers and non-disclosure agreements by nix
Parent article: Device drivers and non-disclosure agreements

Why not sign a NDA with Marvell in order to develop the documentation needed for software development?!

I've seen this with the reverse engineered documentation for the Broadcom BCM43xx devices. Of course that was all reverse engineered from Linux binary-only drivers, but I think the end result would be the same.

The results of the drivers being developed based on that are actually very nice. The results are superior to say that of the Ralink drivers who work to improve on code released by ralink. (they can't work on SMP machines, it's not 64bit safe, it's not usefull for non-x86 platforms, etc etc. (The rt2x00 is working on the devicescape branch and drivers fro those devices which will be superior.. but nothing realy usefull has materialized yet)).

So if there is no documentation then get the NDA to develop documentation!! I am sure that since it's OS agnostic you should be able to get developers from OpenBSD, FreeBSD, and maybe even Apple to praticipate.

That way I figure then it's a win-win. Your doing the NDA to get more knowledge out there and make the hardware usefull for a wider audiance.

Of course then this doesn't help for hardware support for people who wish to keep everything secret... But that suites me. If a manufacturer wasn't to obscure how to use their own hardware then I don't want it, as long as a alternative is aviable.

(and not even speaking about internal hardware.. just the software interfaces)

The way I figure:
Open hardware specs + open code > Open hardware specs > Open code > closed code > no support.

(Log in to post comments)

Reverse engineering takes longer than a product cycle

Posted Oct 10, 2006 0:58 UTC (Tue) by drag (subscriber, #31333) [Link]

That's not quite what I ment.

I ment that if you have to sign a NDA because of non-existant documentation then sign it so that you develop documentation for other people to use with the hardware.

The BCM43xx documentation was just a example of what is possible for this sort of thing.. Athough that was from reverse engineering Linux drivers and not done under NDA.

In other words.. If it's true that the OLPC have to sign the NDA to work with the Marvell engineers because there is no documentation and they have to get help from the engineers then they should be making the nessicary documentation for other people, like the OpenBSD developers, to use.

If they can't do that then the lack of documentation is just a BS excuse and Marvell has no intention on having their hardware open. (and again, not completely open. Just documentation on what is needed to program software to run on them)

I wasn't saying that people should avoid NDAs completely and work on reverse engineering stuff.

Oh, and the bcm43xx drivers are working fine for me. They were included in the 2.6.17 kernel branch by default although you have to get the firmware seperately. The ralink drivers don't work because I am using a non-x86 machine, although I still very much suggest buying Ralink products instead of the Broadcom stuff. When the devicescape stack gets finalised then those drivers are going to be very very good and full featured. There is just some bugs standing in their way..

Reverse engineering takes longer than a product cycle

Posted Oct 10, 2006 11:10 UTC (Tue) by arafel (subscriber, #18557) [Link]

I think you'll find most NDAs forbid you from signing them in order to develop documentation to allow people to circumvent the NDA. The lawyers aren't *that* stupid.

Reverse engineering takes longer than a product cycle

Posted Oct 10, 2006 11:20 UTC (Tue) by drag (subscriber, #31333) [Link]

""I think you'll find most NDAs forbid you from signing them in order to develop documentation to allow people to circumvent the NDA. The lawyers aren't *that* stupid.""

YES. Now you are starting to see my point.

Theo says that Linux devs are screwing up by falling for NDA traps and it's not helping anybody other then themselves. Linux developers say they are doing it because it allows them to work with engineers because documentation is non-existant. The company can't release something that is non-existant.

I say, then if it is true then they can produce the documentation themselves so that other developers can use it to improve and develop their own drivers. However if the NDA forbids stuff like that.. Then the Linux developers are full of shit and are just saying that so they don't look bad. Corporations like that wouldn't release the documentation anyways even if it existed.

I don't have a problem with them replying something like: "Tough shit Theo. The ONLY way we are going to get good drivers in a reasonable time span is by signing NDAs. Next time make a more popular OS so you too can sign NDAs otherwise shut up and go back to reverse engineering with help from the Linux drivers code and bitching about the lack of quality in said code.".

If that is the truth then that is the truth. What can anybody do about it?

Reverse engineering takes longer than a product cycle

Posted Oct 10, 2006 23:26 UTC (Tue) by lambda (subscriber, #40735) [Link]

I think you don't understand what NDA stands for. It stands for "Non-Disclosure Agreement". That
means that you can't talk about what you were working on. Writing documentation, and releasing it
as open documentation, would surely violate most NDAs. And the Linux developers certainly could
be telling the truth when they say there are no docs, but their NDA doesn't let them write docs. In
many cases, there may be closed firmwares, or the files they use for designing their hardware, that
they give the Linux developers access to. NDAs are usually quite broad, to make sure someone
doesn't find a way around, and so they can give you just the code to their closed firmware
while still not even allowing you to write documentation for interfacing with said firmware.

Reverse engineering takes longer than a product cycle

Posted Oct 11, 2006 2:19 UTC (Wed) by bronson (subscriber, #4806) [Link]

It's perfectly possible to sign an NDA to write documentation. In fact, it's happened in the past. Typically the NDA will include a stipulation that any materials produced must be authorized by the company before they can be distributed.

For example, let's say you enter into an agreement with Motorola. They can give you their Verilog code, and ASIC floorplan, or any other highly proprietary information that might be relevant. You would then write the documentation being careful to avoid writing about anything that would be proprietary. Once both you and Motorola are are satisfied with what you've produced, your work can be distributed publicly.

But, if you're under NDA anyway, why not just write code and some extremely well-commented header files? I've written a few drivers in my day and I found that even crappy reference drivers tend to be more useful that the most perfect English documentation. (Bad documentation: S3. Good documentation: Philips. But S3's part was much easier to bring up because they included code)

Reverse engineering takes longer than a product cycle

Posted Oct 11, 2006 8:54 UTC (Wed) by drag (subscriber, #31333) [Link]

Yep.

NDA is a contract and contracts differ.

I would expect that if it's true that the problem is that there is simply a lack of documentation then that can easily be overcome. Either through self documenting code or other things.

I figure a company may just need help or lack resources and a Linux developer or two can then work with them in a consulting role as a sort of ambassador to figure out the best way to get their hardware open enough to allow other developers write code for it.. but not to violate any prior patent or copyright agreements with other companies and not to risk revealing hardware design more then nessicary. If a Linux developer was to follow that role then it would probably be nessicary for them to know more about the company and the hardware design then is nessicary or desirable and a NDA were the company gets to review documentation and code before release would be appropriate and safe for everybody involved.

It would be a insurance policy to protect not only the ass of the hardware company in question, but also make sure that no third party 'IP' (horrid word) makes it's way into the Linux kernel or other people's software were it could cause legal troubles down the road.

However if the company isn't going to allow you to open up the hardware then the likelihood is that the real reason that there is no documentation or reveiling code or whatever the hell people want is because _they_had_no_intention_in_releasing_anything_at_all_ and why waste resources on something like that? They'll force developers to obsicate the code and thus it will be unmaintable by anybody that hasn't signed the NDA. In that case it's not realy any that much better then closed source. Free software, Open Source software just doesn't work under those conditions. This is what Theo was bitching about.

You'd just end up with something like the 'NV' driver were it's unmaintanable and pretty buggy and just encourages people to use close source drivers.

Reverse engineering takes longer than a product cycle

Posted Nov 14, 2009 17:49 UTC (Sat) by vleo (guest, #32027) [Link]

Although lawyers are not that stupid, signers of said NDAs should not be stupid and passive as well - for one I was always adding to the NDA being signed for the purpose of getting access to the documentation for a device - "It is though fully understood by the Parties that nothing in this Agreement shall be used to prevent <our side> from developing and releasing the source code and software design documentation for Linux Kernel device driver module for the devices, covered by this Agreement, under the terms of GNU General Public License, v2, see Appendix G) made integral part of this Agreement"

And if THEY refuse to sign it like that - so be it. Look for another chip vendor. There are enough chips designed to find one that meets your requirements, in both technological and legal areas.