| |||||||||||||
|
| |||||||||||||
Device drivers and non-disclosure agreementsDevice drivers and non-disclosure agreementsPosted Oct 9, 2006 23:02 UTC (Mon) by nix (subscriber, #2304)In reply to: Device drivers and non-disclosure agreements by cventers Parent article: Device drivers and non-disclosure agreements
Indeed. Jim Gettys makes the cogent point that there is no alternative to
I'm not sure what Theo would prefer: surely not that the OLPC project die
(Log in to post comments)
Device drivers and non-disclosure agreements Posted Oct 9, 2006 23:35 UTC (Mon) by drag (subscriber, #31333) [Link] 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:
Device drivers and non-disclosure agreements Posted Oct 9, 2006 23:44 UTC (Mon) by drag (subscriber, #31333) [Link] If your curious the reverse engineered bcm43xx specs can be found at:http://bcm-specs.sipsolutions.net/
Reverse engineering takes longer than a product cycle Posted Oct 10, 2006 0:43 UTC (Tue) by gdt (subscriber, #6284) [Link] Reverse engineering simply doesn't work. I own a Dell Latitude D600 with a Broadcom wireless MiniPCI card. The machine has reached the end of its extended warrranty, so is for essentially obsolete for use by enterprises. The wireless card still does not have a native Linux driver which will authenticate against an enterprise wireless network. As fine as the technical work reverse engineering the Broadcom chip is, the fact that it needed to be reverse engineered at all is a systemic failure. Compounding this, the Broadcom 802.11a/b/g card is on the edge of being superceeded by a 802.11n card. And no, I won't be buying machinery with Broadcom parts again.
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". Thatmeans 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.
Reasons partially out of $COMPANY's control. Posted Oct 10, 2006 0:20 UTC (Tue) by shapr (subscriber, #9077) [Link] "Reasons partially out of $COMPANY's control." - All the hardware vendors say this. Nvidia is the first one that comes to mind, but I'm tired of hearing it. I don't want to pay money to any hardware vendor to get a device that I don't control. This is like DRM, "We'll sell this to you as long as we can choose how you use it."Recently I've been hacking on the driver sources for my Nokia 770. One serious problem is that the Bluetooth firmware has bug(s) where rfcomm keyboards cause the chip to die in such a way that only a reboot fixes the problem. This problem has been known for months, and some of the smartest and most productive coders I know have been having this problem. If they had the firmware source, it would already be fixed. But they won't get the source, and at some point the bluetooth chip vendor might get off their ass and fix it. But the has no motivation to fix it, they don't get more money for drivers. Users have a motivation to fix it because it affects them directly. Obvious conclusion? Get the users to write the drivers. Similarly, I want to do cool and nifty tricks with the cx3110x 802.11 chip in the 770, but it also has a binary firmware blob that gets in the way. When will someone start making hardware and hiring {Linux,BSD,etc} device driver authors to write, release and maintain the drivers? I would cheerfully pay $5000+USD for my next system if it came with all the source for everything in the system. Is there such an option? I'm not picky about the arch...
Reasons partially out of $COMPANY's control. Posted Oct 10, 2006 0:28 UTC (Tue) by cventers (subscriber, #31465) [Link] I, too, would pay a premium for a truly and fully open system to which allsource was available.
But I wish to simultaneously observe that this discussion we are now
So I do think Theo is fighting the good fight. He may just be barking up
Reasons partially out of $COMPANY's control. Posted Oct 10, 2006 7:15 UTC (Tue) by nix (subscriber, #2304) [Link] I concur, for what it's worth. It's a very silly first-strike target,PR-wise.
Reasons partially out of $COMPANY's control. Posted Oct 20, 2006 3:22 UTC (Fri) by Nimbleno (guest, #41230) [Link] First strike? Theo and the OpenBSD folks have been fighting this battle for years. And they've had some good sucesses, such as with many wireless drivers. This is hardly a first strike.
Reasons partially out of $COMPANY's control. Posted Oct 25, 2006 23:03 UTC (Wed) by nix (subscriber, #2304) [Link] True.
It's a very badly-chosen fiftieth-strike target, for that matter. `Hey,
Theo de Raadt, unsung comedic genius?
There are fully open systems Posted Oct 10, 2006 2:33 UTC (Tue) by wookey (subscriber, #5501) [Link] Depends what you mean by system, but this board comes with everything, including CPLD/FPGA code, jtag programming code, bootloader, drivers, kernel, rootfs, schematics, gerbers. http://balloonboard.org/Of course, whilst you can run Debian on it, it is pretty feeble in comparison to a modern x86 machine, so is not a great desktop-replacement, but it is an example showing that fully open systems can and do exist.
Reasons partially out of $COMPANY's control. Posted Oct 10, 2006 4:36 UTC (Tue) by danm628 (subscriber, #5995) [Link] The companies may not be able to release the documentation even if they they want to.
I worked at a startup (since bought by Intel which is where I now work though on a totally different product -- just making full disclosure here). We developed a wireless product which unfortunately never shipped. But even if we had released it there were limits on what we could have publicly documented. Obviously we had the right to document the portions of the chip that we designed. But we purchased licenses for a couple of large RTL blocks and licensed a couple of large hunks of C code from other companies. These companies exist solely to sell licenses to the RTL modules and code they develop which means they have no desire to publish their code under any of the open source licenses.
Our product would have been "open", we planned to document the PC side API's to the firmware completely. You could have written a driver for Linux (in fact we did for internal use) or OpenBSD. But we could *NEVER* release the source code to the firmware or even document the internal registers that the firmware used. In a single register there could be IP from multiple companies and we can only publish our companies IP. So we couldn't have written documentation that would have allowed outside developers to write code unless they were under the same NDAs that we were under.
And all of this ignores regulatory issues. The FCC really doesn't like software controlled radios to be documented. You have to get approval to sell you chip. Our solution was to put the FCC stuff into our firmware. This made our driver (Windows, Linux, etc.) was very thin.
Many chips are like the one we designed. A small amount of IP designed by the company, the "key" feature of the product. A lot of off the shelf modules that may or may not have publicly available documentation. The company can try to select modules with public documentation but they may not exist. So you have to license what is available, whether or not it has public documentation. The company can try to develop all of the modules itself so it can release the documentation but that takes more money and takes more time. Both of which are in short supply on any project.
I'm not sure what the solution is. Theo does have a point; he usually does. Without public documentation of hardware we can't have a fully open OS. But getting fully open hardware requires changes to how chip IP vendors work, which will take time to achieve.
Reasons partially out of $COMPANY's control. Posted Oct 10, 2006 6:25 UTC (Tue) by bignose (subscriber, #40) [Link] > The companies may not be able to release the documentation even if they they want to.
Their choices are what led them to be in possession of hardware which they are not allowed to describe.
> Obviously we had the right to document the portions of the chip that we designed. But we purchased licenses for a couple of large RTL blocks and licensed a couple of large hunks of C code from other companies. These companies exist solely to sell licenses to the RTL modules and code they develop which means they have no desire to publish their code under any of the open source licenses.
This just begs the question one further level. If companies find themselves in a position to obtain part of their hardware design from another party, we need to let them know -- with noise, and real repercussions when they ignore us -- that if they don't get it under conditions that allow them to describe it fully, they are *choosing* to lock themselves out.
> But getting fully open hardware requires changes to how chip IP vendors work, which will take time to achieve.
So, by encouraging vendors when they *can* release the documentation on their hardware, and -- more importantly -- making it plain that we *don't* accept hardware without this documentation, we enlist the hardware manufacturers in pressuring *their* suppliers.
Reasons partially out of $COMPANY's control. Posted Oct 10, 2006 6:34 UTC (Tue) by cventers (subscriber, #31465) [Link] Yes. I believe this to be our challenge and goal in getting the free specsand drivers that we need. All manufacturer statements of "but it can't be free" must be met with "It must, for we are the consumer that pays your salary and rent."
I _do_ think that this is already a functional and working strategy.
But I want to caution at the same time that while we must always be firm
Reasons partially out of $COMPANY's control. Posted Oct 10, 2006 8:22 UTC (Tue) by shapr (subscriber, #9077) [Link] How about a startup that writes this sort of free/oss RTL so that companies can release everything about their drivers? Maybe this would be better as a bounty?
If this existed, companies could sell their chips without drivers and users would have to deal with FCC discovered misuse themselves maybe?
How does the GNU USRP get sold? What does the FCC think about it?
Anyway, hardware specs and open firmware is of value to me, so I'd pay a startup to do it.
The earlier post that mentioned the balloon board is the sort of thing I'd like to have, but with desktop sized power. Maybe the Movidis x16 with totally open drivers?
Reasons partially out of $COMPANY's control. Posted Oct 10, 2006 18:18 UTC (Tue) by flewellyn (subscriber, #5047) [Link] These companies exist solely to sell licenses to the RTL modules and code they develop which means they have no desire to publish their code under any of the open source licenses. That's as it may be, but there are now projects like OpenCores that are working on developing free IP blocks for hardware development. The project may not have existed at the time your old startup was working on this card, of course. But now that it does, I would think it'd be in the interest of many manufacturers, as well as the community at large, to start using that resource.
|
|
||||||||||||