On 2/14/07, Nick ! <[EMAIL PROTECTED]> wrote:
On 2/14/07, Steven <[EMAIL PROTECTED]> wrote:
> The problems would be similar if one signed a NDA, and then released
> code with a BSD license. GPL, however, _requires_ that the code be
> shared, and so I imagine it will be more problematic. Seriously,
> how do you resolve the dilemma ethically?
We haven't actually seen what will happen in this situation (unless we
have, before my time, but I don't see anyone linking examples). Maybe
instead of paranoia we should give the benefit of the doubt. From the
FAQ:
We have seen this happen in the past. A couple of examples have
already been given, such as when one particular BSD project went under
NDA with one particular storage adapter manufacturer and came out with
crap drivers for the community. This has also been an item of HUGE
debate over the last couple of years in this project's community.
Search archives and Undeadly for specifics. I'm providing a couple of
resources in this posting.
"[NDAs] are usually signed either to keep information about the
device private until it is
announced at a specific date, or to just keep the actual
specification documents from
being released to the public directly. All code created by this
NDA program is to be
released under the GPL for inclusion in the main kernel tree,
Read: the _created code_ is to be released. Not the _docs_ and
_specifications_ that led to the code.
What do you think helps keep driver code maintainable and improved as
time goes on? Code itself, or documentation and specifications?
nothing will be obfuscated
at all."
This statement is wrong and just plain idiotic. Something is
obfuscated; the original specifications from which working,
maintainable drivers can be written. The code itself *is* obfuscation.
This is the reason our community doesn't petition hardware
manufacturers to give us driver source code; it's nearly useless.
He might *actually* be telling the truth. Maybe not all NDAs are
conspiracies against us, but are just marketers trying to keep things
quiet, and beyond that the companies don't care. That code might
actually be readable!
Don't make excuses for the project guy (as well intentioned as he may
be), and certainly don't make excuses for the hardware vendors who
screw their customer base. The code will be readable to some degree,
without a doubt, but it will *not* accurately provide implementation
documentation so that a working, maintainable driver can be authored
by other open source projects. Driver code can be filled with magic
numbers, meaningless constants, and inadequate commenting that results
in a working implementation for the Linux kernel source tree but
insufficient information for reverse engineering that crap for any
other implementation.
In short, it's next to useless.
Also, please educate me: couldn't a BSD driver be created by using the
cleanroom approach? One person reads the GPL code, writes specs,
another implements them? Or is this covered when people say "reverse
engineer"?
That *has* been the approach in many cases. And it sucks.
http://www.openbsd.org/papers/opencon06-docs/index.html
http://kerneltrap.org/node/6550
http://kerneltrap.org/node/7184
http://kerneltrap.org/node/6497
DS
