NDAs and FOSS

Jon

Paw Prints: Writings of the maddog

Feb 27, 2010 GMT
Jon maddog Hall

I recently had to sign a "Non-Disclosure Agreement" (NDA) for the first time in a long while, and I thought I would write about how an NDA might or might not fit in with Free and Open Source Software.

One of the main ideas of FOSS is to share information, and we encourage both programmers and vendors to share as much information as possible.

Sometimes a vendor shares some information with developers, and the vendor's words "we think we are going to do this" becomes misconstrued as "we are going to do this". Then people get upset when (perhaps a year later) the "promise" never materializes.

Information like product lines that never get produced, shipping dates that are not realized, features that never appear, and other issues of the same ilk. If a customer of the vendor starts building their own business cases around these plans, and the vendor's plans do not materialize, then the customer might be out a lot of money. Framing this information with an NDA focuses the concept that "this is a goal, not a promise".

Likewise plans to retire functionality. The vendor might be thinking about retiring a certain piece of functionality, and wants to get customer feedback about that issue. This retirement could be contingent on new functionality being developed to replace it, or could simply be a retirement of functionality that the vendor thinks is completely unused.

Many years ago Digital Equipment Corporation was thinking about "retiring" an entire addressing mode of the VAX computer system. The VAX had a fairly complex instruction set, and by eliminating a rather obscure and questionable addressing mode, a lot of complexity and silicon on the microprocessor chip could be eliminated. Digital quietly went out to all the commercial compiler writers and asked if any of their compilers generated this addressing mode, and they also looked at all the FOSS compilers of the day. No compilers they could find generated this addressing mode.

They were just about to give the go-ahead for the CPU designers to leave out the addressing mode, when I reminded them that assembly language could be used with the VAX and there was no guarantee that assembly language programmers would not use this addressing mode. Further investigation did show that some assembly language programs used the addressing mode, and Digital backed off its plans to eliminate that addressing mode.

Here it could be argued that the best thing for Digital to eventually do is to announce their intentions far and wide to allow their customers to advise them in what to do, but the initial "Non-Disclosure" research allowed them to find the answer without panicking all of their customers.

Another reason for NDAs, of course, has to do with marketing and the marketplace. Many manufacturers do not want their competitors to know what they are going to do before they announce their products. Therefore they ask people working with them to keep certain information confidential until they can make their official announcement. This may or may not affect the FOSS that runs in conjuncture with their products.

A new controller of some type may have an NDA assigned to the source code for the driver, but the expiration date of that NDA may coincide with or be tied to the release of the new hardware.

An interesting NDA I heard about was one that had to do with the documentation of a hardware vendor regarding the programming interfaces of the hardware. The vendor did not want to release the documentation unless FOSS programmers signed an NDA, but the vendor was perfectly willing to have their device driver shipped in source code form with comments in the code telling what the driver was doing and how the hardware worked. The software engineers felt it would be better to also freely publish the hardware specifications, but the vendor was emphatic that this should not be done.

It turns out that the vendor's specification document was riddled with the vendor's engineers' statements about future products, ideas for products that had already been rejected, and even comments about their competitors and customers that were not very complimentary. The CEO of the vendor company was embarrassed about the documentation, and did not want it to get back to their customers. A promise to help "clean up" the documentation got a welcome agreement to terminate the NDA at an appropriate time in the future.

Another time I was dealing with a standards organization, that was working on a specification for a new standard. They required an NDA to see the specification, and people in the FOSS space would not sign it. Therefore we were locked out of knowing what was happening with the specification, and being able to have input and vote on it. A visit to the offices of the standards group and signing a short-term NDA allowed me to find out that they were using an "industry membership" method of raising money to help finance the standards work, and as soon as the first version of the standard was complete (in a few weeks), this NDA would not be needed. This knowledge and an invitation to an early "Linuxworld" event in San Francisco convinced the management of the standards group to hasten this a bit faster and a copy of the initial specification was on its way.

In each of these cases, an NDA which specifically detailed the information that was "confidential" would send a signal to the people involved not to depend on that information until it was announced formally.

Often companies that ask you to sign an NDA are simply passing along a requirement from one or more of their partners, vendors or customers.

While some people will argue that no NDA is "good", there are some NDAs that are better than others.

A "good" NDA will be very specific about what pieces of information should be kept confidential and what pieces do not. Typically "any thing generally known by the public" through announcements, newspapers or other publications, word-of-mount, etc. is not "confidential" and falls outside the scope of the NDA. Anything that is generally announced by the vendor after you sign the NDA means that specific information is no longer considered to be "confidential".

Most NDAs will have an attachment that will list the specific areas that should be considered "confidential", and will also state that "confidential" information must be marked as "confidential", or stated as "confidential" in conversations or telephone calls, to indicate to the signer of the NDA which specific material is "confidential".

A good NDA will have a termination date where the information will be considered outside the confidentiality of the NDA, and sometimes there are two dates: One that states when the confidentiality ends and one which states when confidential materials have to be returned.

I would suggest that if you have to sign an NDA, that it be as specific and short-termed as possible.

Some FOSS developers will refuse to sign an NDA. Of course that is their prerogative, There are some NDAs that I have refused to sign, since they were so broad of scope or long in time that they did not make sense. Normally when this was pointed out, the NDA was changed to be more sensible.

There are some NDAs that make writing FOSS for a piece of hardware or doing business with a particular vendor impossible, and those are ones that you also have to avoid.

Finally, if you do decide to sign an NDA, unless you have experience in reading and understanding the terminology and their ramifications in your legal system, you might find a lawyer who will go over it with you and watch out for your interests, and the interests of the FOSS community.

Carpe Diem!

Comments

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News