To NDA or not to NDA?

Question

Assuming a small off-hours development project that may or may not have market value but which the project owner does not want to open source (or at least not at the moment). What is the proper way to formally state this intention to potential collaborators? Is a non-disclosure agreement over board? I know many people are weary of signing NDA's because they are somewhat ambiguous contracts that have the potential to open up lawsuits. Are there other less legally ensnaring ways to say "don't publish or disclose this code"?

Answer 1

Yes, you should have potential collaborators sign an NDA - there's really no harm in that, and it's better to be safe early on than sorry later.

That said, you should make sure your NDA is specific to your project, and the collaborator's participation in that project. In other words, don't craft an NDA that tries to prevent the collaborator from ever doing anything with any idea he or she may have.

Collaborators should not see an NDA as too heavyweight or heavy-handed. You should be able to find nicely worded NDAs to use as templates; look in books about starting your own business.

Of course, an NDA is worthless unless you would actually intend to follow up legally if you suspect someone of making off with your code. But at least having something signed is good.

Disclaimer: I am not a lawyer, and you should probably seek real legal advice.

Answer 2

Assuming that programming is your day job, I would very carefully check your employment contract with your principal employer prior to signing an NDA. The thinking here is that many employee programming contracts have a number of clauses that could cause you problems. Those I've seen include;

• Employer automatically holds to any code developed by the programmer for the duration of the employment. This includes out of hours moonlighting.

• Employee is not allowed enter into any competitive activity for the duration of the employment, and sometimes for a period afterwards. Competitive in this instance is at the discretion of the employer.

• Employee is not allowed disclose any code, technique or similar to any third party for the duration of employment. Technique in this instance is at the discretion of the employer, and may include any programming activity.

These terms may seem draconion, but not only do they exist, they're pretty common.

Answer 3

Keep the NDA focused and it shouldn't be a problem.

I had one company send me an NDA that essentially said that they would own every new feature that I built into a long-established product that might remotely be related to our (common) industry. They were hoping to buy our product but wanted to suggest a feature that they wanted to "own." A feature! Oh, and the NDA stated that they'd still own everything that we added to the software even if they didn't buy anything.

Obviously, we laughed at the sheer audacity of the request and did no further business with them.

Answer 4

The copyright status of the source code should be more than sufficient to accomplish that. Nobody is allowed to create a copy of someone else's copyrighted work unless licenced to do so. If the owner wants to keep control, all he needs legally is to make sure he ends up holding copyright on the produced work.

In the comments and another answer folks have mentioned "work for hire" as the best way to accomplish this. However, it is not the only way, and may not even be the best way.

For example, it would be quite simple to just have everyone add the project leader's name to the copyright as a matter of course. Then no distribution or license change can be made without his say-so. This is how Linux work is typically done. The drawback here is that said change has to be agreed to by all people named in the file's copyright.

If the project leader wants total control, the thing to do would probably be to require copyright assignment. This is what contributors to Gnu projects typically have to do. (You don't think Gnu makes people sign NDA's do you? Hating NDA's is what started Gnu). The Gnu folks have copyright assignment templates avilable that you can probably use nearly verbatim.

Stephan pointed out in the comments that a lot of people really don't like to sign NDAs. You may well lose contributers over it.

Answer 5

A lot of people will tell you to cover your ass and get an NDA signed. That's good advice. But so is this:

The more you share your ideas with others, the more (and better) feedback you'll get.

After being an entrepreneur for long enough, I came to the realization at some point that I get a lot more done when I talk about it and share it with other people than I do when I guard it jealously.

And after being a marketer long enough I also realized: noone gives a shit about your little idea. Yeah, it might be brilliant, but that doesn't mean someone's going to sneak off with it like a thief in the night. Besides -- they'd have to play catch-up just to get to the level of thought and effort you've put in already. And they don't count as long as they're playing catch-up. But if your idea is good... get ready to contend with people who are playing catch-up for a great many years.

Answer 6

It depends are you worried about the actual code or about the ideas the code will implement? If it is just about the code itself then I agree a copyright should be enough.

If you want to prevent taking the idea or the process the software will implement, then a copyright may not be enough and a NDA is called for.

As others have stated, make sure the NDA is fair and not draconian in its terms.

Answer 7

You may be confusing different concepts here. Keeping a code closed-source, which can be communicated easily by e-mail to other collaborators and confirmed by copyright tags in every file, is much less restrictive versus prohibiting anyone to use (or even discuss or mention) all or parts of your idea - which is what a NDA is about.

I believe that there are many more ideas in the world than will be actually developed into a usable service; furthermore, that there is significantly more "inventing" effort required to produce such a useful, revolutionary service than to generate the original idea. Bouncing ideas off friends and acquaintances is an early, easy way to see their viability. Trying to prepend those ideas with an NDA makes this informal process cumbersome and bureaucratic.

If you do decide on a NDA, make it as restricted in scope and time as possible, otherwise people who would like to work with you but are working in the same field wouldn't be able to sign it because it would impact their current/future business as well.

Answer 8

I use a mutual NDA for all collaborative efforts and discussions. Professionals and serious amateurs have no problem with this, as it shows two-way respect.

Answer 9

The Rands in Response weblog recently had a post that covers this topic. See it here it's about FrieNDA. But it might be a little less then you want.

Answer 10

Does anyone has a template available or a web link where its available?