FindLaw columnist Eric Sinrod writes regularly in this section on legal developments surrounding technology and the internet.
These days, major software systems make the world go around. Software is used to assist every day mundane functions. Software also is the backbone behind mission critical systems that ensure the health and safety of our society. But does that mean that software always is procured and supplied without controversy and disputes? Absolutely not.
Unfortunately, fights and litigation between major software providers and recipients is all too common. Why does this happen? There are a variety of reasons, and there are ways to avoid such problems on the front-end of software relationships, if due care is taken.
One problem that can occur on the software provider side is that of over-promising. There are instances when providers desperately want to get into a particular software niche or they mightily want to land a specific engagement. In this context, they may over-hype their expertise, prior experience and ability to deliver under the given software scope. Indeed, they may even start to believe their own over-hyping. While that may land the engagement on the front-end, once problems emerge, the software buyer will complain about unfulfilled promises. In fact, the buyer may even argue that the provider engaged in deception and fraud.
On the procuring side, at times software buyers are not sufficiently specific in terms of their precise needs, they keep making change requests to the scope of the software project along the way, and they may not provide sufficient information and assistance to the software provider to enable the provider to do its best on the project.
And, perhaps not surprisingly, there can be a number of disputes and issues that arise from contractual documentation. Software buyers may find that they are limited by contractual terms as far as their potential remedies in the event they encounter software problems. When that happens, they may need to prove fraud to get out from under the contractual limitations. Software providers, on the other hand, may find that contractual representations they make in terms of software capabilities may come back to bite them if those representations are not achieved.
While both sides may be well motivated when a major software project is coming together at the outset, they should not jump into bed together in haste before truly vetting out relevant details relating to the project. Both sides should be careful and frank in terms of what they want and what they can do realistically as part of the project. And then the contractual documentation should be worked out to truly capture the accurate nature of the envisioned relationship on the software project. Plainly, appropriate technical and legal support should be brought to bear in properly formulating the relationship. It is not a good idea to be penny-wise and pound-foolish when crystallizing the parameters of a major software project.
- Google Voice Now Available to All: What It Means for Your Firm (FindLaw's Technologist Blog)
- Software License Considerations (FindLaw)
- Is it Time to Upgrade to Microsoft Office 2010? (FindLaw's Technologist Blog)
Eric Sinrod is a partner in the San Francisco office of Duane Morris LLP (http://www.duanemorris.com) where he focuses on litigation matters of various types, including information technology and intellectual property disputes. His Web site is http://www.sinrodlaw.com and he can be reached at firstname.lastname@example.org. To receive a weekly email link to Mr. Sinrod's columns, please send an email to him with Subscribe in the Subject line. This column is prepared and published for informational purposes only and should not be construed as legal advice. The views expressed in this column are those of the author and do not necessarily reflect the views of the author's law firm or its individual partners.