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.

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.

Related Resources:

  • 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 ejsinrod@duanemorris.com.  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.

You Don’t Have To Solve This on Your Own – Get a Lawyer’s Help

Civil Rights

Block on Trump’s Asylum Ban Upheld by Supreme Court

Criminal

Judges Can Release Secret Grand Jury Records

Politicians Can’t Block Voters on Facebook, Court Rules