NYSIA Legal Forum Summary – Live Blogging
Guest: Mark Grossman – Attorney and “TechLaw” Columnist
The industry should be embarrased – contracts are horrible, not so much one-sided as incompetently drawn, fail to address basic questions. VERY often, the contract delivered is not the deal the parties wanted to do. Most business litigation is honest business people, honestly disagreeing about their items that are unclear.
You have to be on the same page – legal review helps you – lack of attention to details will bite you later – it is a safety net. But sometimes people agree to agree later.
Sellers are in the best position to put out the first draft for a deal. Good form documents are helpful for you to close and seal a deal.
Assumption: assume that no one at the table will be involved after the parties sign, the doc stands on its own, and its well written and could be understood by people not familiar with the details. Who do you write for- the judge, the (high school and college educated) jury, who? – Work with assumption that everyone who negotiated will not be there but have the same skill set – and they could read the document and understand it.
Mark now shows 6 basic questions for a software dev contract – responsibilities, procedures for feedback, corrections and changes; procedures for final acceptance; price and when it’s paid; who owns the copyright and ip rights; remedies for delay or failure.
Who’s responsible for: text, graphics, look and feel, layout. Is it defined?
Licensing – who licences 3rd party software? Who does due dilligence on underlying licenses now?
What’s the procedure for change orders? – must create procedures for collaboration
Changes require approval of both parties, needs to deal with timelines, mechanisms for adjusting price, do not get sloppy with procedure – creates litigation.
Procedure for final acceptance – including functions, speed, and response time. Have to think about failed tests – procedures, time for fixing, etc. What happens if parties never agree it works.
What’s the price for the work when it is paid? – flat fees – more work up front to clearly delinate the scope.
Is it based on time? What’s hourly rate? Time to completion? Require regular updates on time to date.
When is payment due? Dates vs milestones.
Who owns the copyrights and other IP rights in a website?
buyer – “I paid for it – how come I don’t own it?” vs developer – “losing rights to my own programming library.”
Work made for hire – unless agreement says the buyer owns it, the seller owns it.
If doing outsourced work, even if venue for law is New York, always check with foreign lawyer.
Remedies for delay or failure – careful balance needed. If customer doesn’t provide what’s needed on time, like logos, graphics, etc. developer can’t deliver on time.
Whose law should apply? NY can be a compromise state.
Magic language- time is of the essence – – Courts don’t like to enforce time limits, but putting this in can make court put higher priority on timeline. (Shouldn’t be acceptable to a seller).
Where and how to battle – Lawsuit, arbitration, attorney fees to the victor?
Norms on limitation of liability – no matter what we do and how bad it is, we owe you little, and you owe us first born.
Limits on liability – from seller – it’s a price issue, its an industry standard, we’ve never done it any other way, we can’t be possibly responsibile for all the harm our software would do if it failed. You have to have backups in place.
Buyer’s perspective – full amount of contract or more, exclude 3rd party property damage and bodily injury, exclude liability for infringement of IP, exclude NDA liability, reciprocal.
In general, great presentation, very informative, I learned a lot.