To Zoborov

Posted Oct 1, 2007 18:37 UTC (Mon) by filker0 (guest, #31278) [Link]

You're talking as if projects that eschew NDAs were somehow vaporware or the dead-end pursuit of naïve idealists; I've cited OpenBSD, a burgeoning project if ever there was one.

As far as ad hominem reasoning, I'm not sure what you're getting at. Your position seems to be that anything short of the ideal world (where the HW manufacturers all provide all the technical information for all the devices they make free of any NDA or other restrictions) is unacceptable, and that any project that submits to an NDA is neither useful nor valid in the FOSS world. You criticise those people who are willing to compromise and sign an NDA with the understanding that the resulting driver will be FOSS, without NDA restrictions. In the current environment, you won't see that. Maybe in the future, as open standards and open software become the normal way that these companies do business, but they're not there yet.

The reason that I asked about whether you've ever written a driver is that anyone who has written a non-trivial device driver, and gotten it to work well, has the skill set to determine what each register access (read/write) is doing within a driver based on the desired effect and how the device reacts. I've worked with quite a few parts where the docs from the supplier told me where the registers were and what the bits in the registers were called, but almost nothing else (in some cases, the published register information was just plain wrong). Having a working driver as a reference was the best documentation that I could get. If you've written a driver and still feel that having a working driver is just as bad as having no driver at all (or a binary blob), then you've got a completely different philosophy than I do.

I suppose what would be best for all of FOSS is an Open Documentation Project, where a team of literate engineers sign NDAs, work with the Open Source driver folks, and produce unencumbered device programming level (registers and theory of operation) documentation that is released under the Creative Commons license or some such. A nice idea, but there are fewer people who can do this than who can write the drivers, and it's harder than writing the drivers because testing it is almost impossible. I have been a technical writer (and editor) in the past, but I'm not sure how many other experienced engineers have that background.

My biggest gripe with what you've been posting in this thread is that you seem to be completely unwilling to contemplate that GKH is anything but a sell-out who doesn't care about FOSS, and that the results of the Linux Driver Project are going to be anything but bad for FOSS. The fact that he's got nothing to do with BSD (and says so) does not mean he's hostile to it, just that he's not involved with it. I don't know his personal feelings about BSD, but I saw nothing in the FAQ from which you quoted as being hostile. If there were a more congenial relationship between the BSD and Linux communities, he'd probably have more to say. I'm not involved in that conflict, but I've seen signs of it for many years.

You criticise. You quote alot. You don't seem to draw from personal experience. I've been involved FOSS since before GNU. Things were much more open back before chips more complicated than, say, a M68000 CPU. Today, ancillary chips (such as 3D graphics chips) are far more involved than anything that was available in the early days. For a while, a lot of communications chips were being built to work with Windows and nothing else. I don't know if Microsoft actively made deals with the chip makers, but it sure seemed like it. I think that this is still the case with the graphics chip sets. Microsoft gives the chip makers advance DirectX internals information and the chips get designed to work best with the interfaces expected by DirectX. Non-windows drivers, then, become more difficult, as X doesn't have the Windows GDI (which is a good thing). The generic programming interfaces may be a complete mess. No cogent programming information exists beyond the VHDL, which is very proprietary. Hence the NDAs. I've even had to sign NDAs for high capacity NOR flash programming info in advance of release of the parts even though the only significant differences between it (2+GiBit) and the previous (<=1GiBit) were the ID codes and erase timings.

In any case, you seem convinced that the project cannot do the FOSS community any good, and are intent on criticising GKH and those who work with him for undertaking it. I am not trying to stop you so much as I'm defending an endevour that I see as being good for FOSS. My "politics" are those of moderation; I don't see this NDAs as a moral evil, and I believe that trade Secrets are better than Software Patents. Your position, and world view, are very different.

I'm a reformer, you appear to be a crusaider. As such, I'll be one of the first up against the wall when the revolution comes. I've had a long and productive life, so I suppose that's not too big a loss.

Posted Oct 2, 2007 0:36 UTC (Tue) by jejb (subscriber, #6654) [Link]

Perhaps if you looked at the structure of the actual set of NDA's that this is based on you'd have some better arguments? They're published by the Linux Foundation, who found a set of lawyers to help craft them. The general programme is here:

http://www.linux-foundation.org/en/NDA_program

The actual legal docs are at the bottom of the page. The relevant sections to this current thread are:

Section 2A "no Open Source Product shall contain any of the Contributor's confidential information except to the extent required in order to effect the purposes". This somewhat opaque legalese means that any information in the confidential doc that's needed to actually program the device may be incorporated into the resulting driver or otherwise published. i.e. register definitions, APIs, the lot can move directly into the public domain via documentation within the actual written driver.

Section 2B is a patent licence for any and all patents the contributing company happens to hold in the technology needed to drive the device.

Section 7 limits the absolute term of confidentiality to five years.

This seems to be about as transparent as it can be and true to the principles of Open Source: all information needed actually to program the device can become public domain. Any other embellishments in the docs that usually cause lawyers to insist on redacting them before they're released (like slanderous aspersions on the competition or misguided marketing plans) can remain confidential.