Making sense of the One Laptop Per Child proprietary software row (Jem Report)
I have never signed an NDA for generally useful technical information, and I don't want to start now. On the other hand, I can see how, since it eliminates a greater wrong, it can be justified in this case. It is an unfortunate example, but it could also eliminate the problem."
Posted Oct 10, 2006 15:05 UTC (Tue)
by elicriffield (guest, #33738)
[Link] (19 responses)
How can you write free (as in rights not price like the artical talks about) software based on infomation you had to sign an NDA to get?
What good is the source if noone else gets to knows the specs anyway?
Eli
Posted Oct 10, 2006 15:26 UTC (Tue)
by i3839 (guest, #31386)
[Link] (3 responses)
Not all NDAs are the same, and signing one without getting permission to release the driver is just stupid and hopefully never happens, as the whole point is to be able to get a driver. Companies which don't want that won't give the NDA option in the first place. NDAs can also have a limited duration after which all information may be disclosed. If that's something like one or two years then that isn't that bad.
Of course the driver written under NDA must be complete and of reasonable quality, or else it isn't worth much.
Posted Oct 10, 2006 15:37 UTC (Tue)
by gnb (subscriber, #5132)
[Link] (2 responses)
Posted Oct 11, 2006 5:14 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
Posted Oct 11, 2006 8:51 UTC (Wed)
by gnb (subscriber, #5132)
[Link]
Posted Oct 10, 2006 15:27 UTC (Tue)
by nix (subscriber, #2304)
[Link] (13 responses)
Posted Oct 10, 2006 16:10 UTC (Tue)
by ca9mbu (guest, #11098)
[Link] (12 responses)
Posted Oct 10, 2006 16:22 UTC (Tue)
by arjan (subscriber, #36785)
[Link] (2 responses)
you make it sound "easy" to have a good driver documentation that you can just release. Reality is different often....
Posted Oct 10, 2006 18:09 UTC (Tue)
by ca9mbu (guest, #11098)
[Link] (1 responses)
Posted Oct 11, 2006 9:51 UTC (Wed)
by broonie (subscriber, #7078)
[Link]
You can also find that a vendor with NDAs with other people or with secret information of its own
Posted Oct 10, 2006 16:28 UTC (Tue)
by smoogen (subscriber, #97)
[Link]
Posted Oct 10, 2006 23:27 UTC (Tue)
by arafel (subscriber, #18557)
[Link] (7 responses)
(I know people that do this, albeit not on purpose. ;-)
Posted Oct 11, 2006 0:21 UTC (Wed)
by dberkholz (guest, #23346)
[Link] (6 responses)
Posted Oct 11, 2006 7:17 UTC (Wed)
by k8to (guest, #15413)
[Link] (5 responses)
Of course deliberate obfuscation occurs, and that is sad.
Posted Oct 11, 2006 13:12 UTC (Wed)
by nix (subscriber, #2304)
[Link] (4 responses)
Posted Oct 11, 2006 14:08 UTC (Wed)
by jg (guest, #17537)
[Link] (3 responses)
He should enter the obfuscated C contest.
Posted Oct 11, 2006 15:59 UTC (Wed)
by dberkholz (guest, #23346)
[Link] (2 responses)
XFree86 3.3.3 (18 November 1998)
Posted Oct 11, 2006 21:44 UTC (Wed)
by dberkholz (guest, #23346)
[Link] (1 responses)
Posted Oct 16, 2006 22:16 UTC (Mon)
by roelofs (guest, #2599)
[Link]
And for even more amusement, do a diff against the previous version for any of the files in question. ;-)
Greg
Posted Oct 11, 2006 6:04 UTC (Wed)
by jd (guest, #26381)
[Link]
This is usually tolerated by companies, as it (a) keeps their intellectual property safe, (b) adds extra customers for the hardware - where the money is anyway, and (c) doesn't expose their code to any meaningful peer-review.
This is also usually tolerated by Open Source developers, as the clean-room implementation is (a) unburdened, (b) semantically identical to the original (although not syntactically identical), (c) much more likely to be correct and feature-complete than if a hostile company picks and chooses what to put in a published specification. (I shouldn't need to name names here.)
Although not often mentioned as a feature, clean-rooming can lead to cleaner code, as there's less risk of cruft or architectural defects caused by the inevitable failures of communication between hardware and software divisions of a corporation. For this reason alone, ancient and crufty code is almost always better re-engineered by clean-rooming it than attempting to fix.
Posted Oct 10, 2006 19:07 UTC (Tue)
by sbergman27 (guest, #10767)
[Link] (1 responses)
Posted Oct 10, 2006 21:14 UTC (Tue)
by i3839 (guest, #31386)
[Link]
"OLPC-contracted developers have signed a non-disclosure agreement (NDA) to access Marvell's hardware documentation in order to create a free software replacement for it."Making sense of the One Laptop Per Child proprietary software row (Jem Report)
Wouldn't distributing the source code alone break your NDA.
Good source code makes it clear what's happening all the time and has comments documenting the more obscure things. It is also structured, with a function doing this, and another doing that. So if the driver is written well it's better than the specs, as it doesn't only tell what can be done, but also shows how. See also the previous article, "Device drivers and non-disclosure agreements", good comments there. What's more important than the specs is the ability to communicate constructively with the hardware engineers.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
>as it doesn't only tell what can be done, but also shows howMaking sense of the One Laptop Per Child proprietary software row (Jem Report)
With the added advantage that what the driver says can be done probably
works in real life, which may or may not be true of the spec., depending
how conscientious the vendor is about documenting errata. Of course,
a spec. that provides a decent explanation of the programming model is
nice and well worth having. But the value of a well-commented driver that
has been shown to work should not be underestimated.
I would imagine that if it's illegal for a person to violate NDA by talking to somebody on IRC chat about how a peice of hardware works then I realy doubt that that same person is going to be able to put a large amount of comments or be especially descriptive with the code either.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
Sure, they can't just drop the whole of the NDA'd document into a Making sense of the One Laptop Per Child proprietary software row (Jem Report)
comment block and say "well, it's code now", but the result can typically
contain meaningful enough names, and enough relevant comments to
understand what is going on See for example the driver that this article
is about (there's a URL further down among the comments). It's more work
to make sense of than a document, but it is likely to match reality more
closely.
Your argument that there is no sense requiring an NDA and allowing the
development of an open source driver from which equivalent information
can be extracted is perfectly logical, but that doesn't seem to stop
companies.
Whether it's a violation of the NDA depends on the NDA's terms. Pretty much invariably it is true that the NDA in question was only asked for at all on the basis that a free driver would result, so there is no violation.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
So, what value does the NDA have then, if folks are going to obviously be able to understand how the hardware operates by looking at the source code? Surely it would have been quicker, easier and therefore cheaper to just release the docs and not have to pay lawyers to draw up and sign the NDAs?Making sense of the One Laptop Per Child proprietary software row (Jem Report)
often the so called "specification" contains a lot of things not relevant to driver writers. It's easier and cheaper to just put those under NDA than to pay a docwriter to completely overhaul a 100 page document... in addition it's sometimes not even entirely clear what info exactly is needed for the driver.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
Sorry, arjan, I didn't mean to come across as thinking it's "easy" at all. It's hard enough for me to write proper documentation for the code I write. I can't imagine what it is like to have to document hardware, never having been involved in that field. My question obviously shows that lack of experience, I guess. It just seemed ironic that the documentation is only being released under NDA, but being used for software that was obviously going to be made public, hence the information it contained would be disclosed, albeit in a slightly different format.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
Sometimes you end up with things like implementation details of the chips that the vendors don't Making sense of the One Laptop Per Child proprietary software row (Jem Report)
want too public mixed in with the documentation on how to program the chip, especially if the
manual isn't really intended to become public but the need has come along over time.
will have some sort of process in place for auditing released manuals to ensure that they don't
have that sort of information leak even if it's not likely. Releasing under an NDA may allow that
process to be streamlined.
From what I can tell.. the contract that Marvell has with whoever wrote the embedded code OS for them does not allow them to release it unless under NDA. So the lawyers have to get into this.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
It's perfectly feasible - and pretty easy - to write a driver which doesn't give away enough about the hardware to allow someone else to properly modify it.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
Not on purpose? Take a look at the nv driver for nvidia video cards. It was deliberately obfuscated.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
The statement suggested that he knows people who achieve this via accident or incompetence. That such achievements occur is not contradicted by the fact that deliberate obfuscation also occurs.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
Deliberate obfuscation occurs even in cases where no NDA is involved: see the vcg graphing tool, for instance (de-obfuscated a few years ago).Making sense of the One Laptop Per Child proprietary software row (Jem Report)
There are some claims, which I judge are more likely correct than not in the case of the NVidia driver, that the author of that driver literally programs that way.Making sense of the One Laptop Per Child proprietary software row (Jem Report)
I'm willing to believe that ... but how about looking back in the XFree86 history at when the driver wasn't obfuscated, and at this CHANGELOG entry:Making sense of the One Laptop Per Child proprietary software row (Jem Report)
1244. Obfuscate the NVIDIA sources by NVIDIA's request.
And if you want to see obfuscation at it's finest, take a look at the actual code.
Making sense of the One Laptop Per Child proprietary software row (Jem Report)
And if you want to see obfuscation at it's finest, take a look at the actual code.
Making sense of the One Laptop Per Child proprietary software row (Jem Report)
Typically, I believe people do a "clean-room" version in circumstances like this. In other words, person A signs the NDA for the source code and writes a formal specification of what it does. No code, no exposure of code, just a specification. Person B, who has neither signed the NDA nor seen the source code, then writes a driver based on the specification.
Depends.
As per Jim Gettys' blog, the driver in question, still in development but already functional, is here:Making sense of the One Laptop Per Child proprietary software row (Jem Report)
The only remaining proprietary software is the firmware running on the embedded wireless card's cpu, and this will be replaced by free software in time.Making sense of the One Laptop Per Child proprietary software row (Jem Report)