First sign this NDA(svhacks.wordpress.com)
svhacks.wordpress.com
First sign this NDA
http://svhacks.wordpress.com/2012/07/17/first-sign-this-nda-2/
5 comments
Anyone signing an NDA without knowing what it is the NDA covers is needlessly incurring legal liabilities. I would never sign an NDA unless I knew what it was covering AND it was properly scoped (most NDAs tend to be too broad).
Even then, there has to be a really good reason for doing so - everything you agree to is something you have to keep track of and make sure you don't accidentally break at some point in the future.
Even then, there has to be a really good reason for doing so - everything you agree to is something you have to keep track of and make sure you don't accidentally break at some point in the future.
While I can see some validity in some of the points I can't really say that an NDA is a completely useless tool. I have never dealt with one before so I might not be the ideal candidate to talk about them. Nevertheless I think that if the NDA is reasonable and restricted to the matter at hand, in this case it seems to be some kind of consulting for a new startup, then is OK to use one. After all, wanting to protect a cool new idea is perfectly reasonable and understandable, specially in a highly competitive field.
For me, it's gotten to the point where NDAs just scream "junior! junior!" about the people asking me to sign them.
Two words important to technical types: Working code.
For "pure" tech ideas -- where the product primarily consists of software with unique functionality -- these two things are equivalent, and staying in "stealth mode" and protecting yourself with NDA's until you're ready for release is important, because it's easier for an adversary to develop an equivalent product than it is to develop equivalent relationships.
For more "businesslike" tech ideas -- where network effects, marketing, positioning, or inter-business relationships are most important -- the business-side execution is more important than the software details.
Of course, your mileage may vary, and most real companies require both technical and business competence to be successful.
The more time you've spent on your code, the harder it is for your competitors to replicate it. As a very rough rule of thumb, the time it takes to build a meaningful competitive advantage is probably approximately equal to the time it takes to get a working prototype, so you can stay at least one major release ahead of your competitors, but this can vary a lot.