So many times it's been said and yet people still don't grasp the big picture.
If the work being done here didn't impact anyone other than the GPL

driver writing Linux crew, it would be one thing.
When the message sent to commercial hardware manufacturers is "we

don't want your specifications to be open, we just want to work under

NDA so we can produce a single driver" by one open source guy, the

message is received by said vendor is different. What it tells them is

that not releasing open documentation and specifications is the norm,

they don't have to disclose anything to the open source community

outside of NDA, and that helping produce a GPL driver is good enough.

The next step is them thinking that they can just produce said driver

themselves. And then that they can just release a blob.
In other words, it undermines the (better) efforts of a project like

OpenBSD who try to get fully open docs and specs so that OpenBSD can

have a functioning driver, FreeBSD can have one, NetBSD can have one,

Linux can have one... etc.
Instead we end up with a GPL driver that has to be reverse engineered

and we end up with the same problems we already have.
It's not enough to be "good enough". If the damn community can't get

this by now, it's going to continue to be an uphill battle.
DS

Since when is the GPL a close source license?
# Han

GPL isn't, but a NDA would require that the documentation, or

specifications used to write the driver not be shared.  So despite

assurances, how could they _not_ obfuscate details in the code if

they're to abide by the terms of the NDA?  At the same time, how can

they obfuscate the code if it's written in terms of the GPL?
It seems a little lame to write code under a license like the GPL if

you have to sign a NDA to do so.  I mean, what takes precedence, and

who decides?  Does the Linux Driver Development team lack courage to

demand open documentation for their drivers so that they can release

them properly under the terms of the GPL, or are they actually that

deluded that they think that this can work?
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?
Thankfully, there are people like Theo, and the OpenBSD developers,

who see this problem more clearly than most.  Keep up the good work,

and fighting the good fight.
In the meantime, I'm going to work on an e-mail to send to Greg

Kroah-Hartman expressing my concerns regarding the Linux Driver

Development team's recent decision.
--

W. Steven Schneider  <steven_schneider@telus.net>

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:

    "[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,

nothing will be obfuscated

    at all."

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!

--then again it might not. We'll see.
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"?
-Nick

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
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
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
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.
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

And what, you get a new chunk of code that replicates misinterpretations

of the hardware specs?
An  often  quoted  open  source  adage "Many eyes make all bugs shallow"

fails  when  the  number of eyes being permitted to look at the hardware

documentation is restricted.
--

rodd@polylogics.com     "The avalanche has already started, it is too

Rod Dorman              late for the pebbles to vote." - Ambassador Kosh

Programming documentation is restricted also because the hardware is

full of bugs and like Theo said there is no errata for a lot of

hardware.

On the other hand, some vendors go as far as releasing even the schematics and

gerbers for their hardware:
http://wiki.emqbit.com/free-ecb-at91
CL<

Hello!
That's exactly what was meant by "reverse engineer". Then, by reading

the GPL code w/o hardware docs, you see only *that* the GPL driver is

doing thisorthat, but not *why* exactly it's doing thisorthat at a

specific point.
And if thisorthat (e.g. peeking and poking around magical I/O addresses,

using magical values/bit masks) doesn't work as it should, you don't

know exactly in what way it deviates from the hardware spec, as you

don't have access to it.
I.e. difficult debugging, troubleshooting, maintenance.
And the point of Theo & co is that it'd be much easier with open

documentation.
And you could identify points where things are done in an unnecessarily

twisted/dirty/... way using the docs and eliminate them, even if you
Kind regards,
Hannah.

As an optimist, I tend to agree with you.  He hasn't really started something

new - he's really just making it public knowledge with an open letter to

hardware makers how FOSS drivers get made.  A lot of shops must avoid the

FOSS world because they don't want to take on another platform for support,

no knowing that the community will.
Realistically, while a company may require an NDA while they want to keep

things secret, I expect having an unobfuscated driver out there will negate

any need to enforce it longer than necessitated by marketing departments.  I

also expect that any drivers written in this manner will be discluded from

the mainline linux kernel tree unless they are absolutely clearly written to

a degree that the top deciders in Linux will accept it regardless of NDAs.  
Manufacturers who continue to be troublesome will see their drivers go away or

require more work at least for users. If I can choose between two SCSI cards

in Linux where one is supported by generic kernels, but the other requires

either binary blobs or firmware loaders, or patching my own kernel with their

code, I'll pick the easy one hands down.  I think manufacturers will see 
I imagine that's the best case scenario here, but that certainly does make

things harder and everyone's a little more likely to lose something in

translation.  It's one of those situations where it *can* work, but no one

wants to do it that way.  It's not as bad as reverse engineering without a

working model, but it is still reverse engineering because you're building

your own specifications based on something that isn't the specifications.
--

Regards,

Neil Schelly

Senior Systems Administrator
W: 978-667-5115 x213

M: 508-410-4776
OASIS Open http://www.oasis-open.org

"Advancing E-Business Standards Since 1993"

No, the best case scenario is that the good intentions of the Linux

driver project would be focused on getting vendors to provide open

documentation from which any OSS project, including Linux, can produce

good drivers. People say it can't happen, but the OpenBSD project has

shown on more than a few occasions that it can and does work.
The only difference here is one project has a pair of big brass balls

hanging between their legs and the other doesn't.
DS

My statement wasn't an opinion, so please don't say I'm wrong.  His question

was about how this project could lead to drivers for BSD.  And it ~could~ be

that cleanroom implementations of the driver code developed for GPL projects

get reliable enough under BSD here.  That is the best case scenario here -

that drivers are written well enough that reliable specs can be drawn up from

them and be useful.
I didn't in my email suggest I thought this was the best way to make drivers.

I just answered the question he asked about creating BSD drivers based on

GPL'd drivers without the original specs.  Please don't correct my statements

out of context.
--

Regards,

Neil Schelly

Senior Systems Administrator
W: 978-667-5115 x213

M: 508-410-4776
OASIS Open http://www.oasis-open.org

"Advancing E-Business Standards Since 1993"

Who said it was?
If you mean what I said about the same problems we already have, I

mean that we don't have specifications and documentation from which a

reliable driver can be written. Problems with magic numbers and

unclear implementation details have been pointed out in the past.

Reverse engineering can only take you so far, no?
DS

Oh right, the Greg KH stuff. I think he should not take half the

deal. They should refuse to sign NDA, just like RMS insists.
Even if the driver was BSD licensed it wouldn't help you since a

linux driver is incompatible with a BSD driver.
This is not a BSD v GPL issue at all. This is about some stupid

developer accepting a deal when he should fight on.
Hardware specifications must be available to all people. Anything

else is immoral.
# Han

You still don't get it. The problem is lack of available documentation.
CK
--

GDB has a 'break' feature; why doesn't it have 'fix' too?