Printer Friendly

Acquiring all you need to maintain your software.

In my filing cabinet at home, I have a drawer devoted to all the things I get when I buy an appliance or power tool. These include owners manuals, instruction manuals, maintenance manuals, attachments, and spare parts. While I don't always need these things when I first buy the item, I often need them in the future to learn more about how the item works, repair it myself, or find out how to get it serviced by a dealer. That's when I'm glad I kept all the ancillary items. Making sure I have what I need up front helps make the item maintainable down the road.


Maintainability is also important if you acquire software for the government. Whether procuring software by itself or as part of a system, you should determine the need for maintenance of the software, determine who might maintain it (the software developer, government personnel, or a third party), and make sure you get whatever is required to perform that maintenance, which includes not only error corrections but also enhancements and adaptation to different hardware. Don't forget to think beyond just the first few years when the developer of the software may still be under contract to maintain it. The software may be in use for 30 years or more.

Besides considering what documentation you might need (requirements documents, design documents, programmer manuals, user manuals, etc.), you'll also want to evaluate the need for source code and data rights. Just like the license agreements that come with software for your personal computer, data rights specify what you can and can't do with the software: make and use copies, run it on multiple computers, modify it, and allow other government agencies or third-party vendors access to it.

Software Data Rights: A Thorny Issue

Unfortunately, determining the need for software data rights is not as simple as merely specifying the maximum (also referred to as "unlimited") data rights in the contract. Recent intellectual property laws preclude the government from asking for anything beyond minimal ("restricted") data rights unless there is justification. Several reasons to specify more than restricted rights would be the possibility for the government to do software maintenance in-house or to compete it among vendors. Inadequate data rights may make in-house or third party software maintenance extremely costly (if these data rights must be purchased after contract award) or even impossible. The need for software maintenance without adequate data rights usually requires a non-competitive contract with the organization that developed the software.

Many people are surprised--even shocked--when they hear that the government doesn't automatically own software that is produced on a government contract, even if the government paid for 100 percent of its development. Copyright laws say that an individual contractor or contracting company owns the computer software, computer software documentation, or technical data the individual or the company creates. The government typically receives only standard license rights to use the software, software documentation, or technical data in certain limited ways and only if the proper data rights clauses are in the contract.

Standard rights may or may not meet your needs. It's the responsibility of the contracting officer to put the proper data rights clauses in your contract, but it's your responsibility to provide the contracting officer with a complete assessment of your work effort. This assessment, called a "Data Rights Requirements Analysis," should include a determination of your contemplated present uses of the software or other deliverables as well as an assessment of any future uses by you or others. The DRRA should be conducted prior to contract award, taking into consideration such factors as multiple-site or shared-use requirements, and whether the government's software maintenance philosophy will require the rights to modify or have third parties modify the software. If the DRRA determines that the standard data rights clauses are not sufficient to meet your needs and the future needs of the federal government, additional rights may be obtained through negotiations with the contractor, usually at an additional cost. These negotiations will be conducted for you by the contracting officer.

The DRRA should address the following:

* Is this a new or existing procurement?

* Do you have the proper rights in existing software or other deliverables that permit the government to modify, in any way, that existing software for this new contracting effort?

* What type of procurement or assistance vehicle is/will be involved (cooperative research and development agreement, Federal Acquisition Regulation contract, other transaction agreement, technology investment agreement, etc.)?

* What clauses already exist regarding data rights?

* How much, if at all, might requiring more than restricted/limited rights diminish competition or increase procurement cost?

* Will one of the standard Defense Federal Acquisition Regulation Supplement (DFARS) levels of data rights ("unlimited," "government purpose," "limited," or "restricted") be acceptable, or do the data rights need to be specifically tailored and negotiated for this procurement?

* Do the number of anticipated changes to the software and the required response time for those changes warrant the possible additional cost or fewer bidders on the procurement?

* What is the likelihood that the government will perform the software maintenance in-house?

* What is the likelihood that the software maintenance will be competed and awarded to a third party?

* Might there be any situations that would require licensing outside the federal government (e.g., foreign military or commercial sales)?

* Do you require the rights to modify the deliverables now or in the future? Modifications include updates, corrections, and enhancements.

* Do you need to maintain configuration control over the deliverables? If so, the government may obtain ownership of all or a part of the deliverables.

After the DRRA has been conducted, the contracting officer will determine if the standard DFARS data rights clauses provide the necessary rights for you and the government to accomplish the stated objectives. If additional rights are required, the contracting officer will enter into negotiations with the contractor to try to acquire such rights.

To close, here are five important things to keep in mind when planning to acquire software:

* The data rights issue is very complex and requires expert guidance from both a patent attorney and contracting officer to determine the best strategy.

* Inadequate data rights typically result in paying large sums of money to acquire the required rights or having only one option for software maintenance--sole-source procurement to the creator of the software.

* Without the proper data rights, you will not be able to legally use your deliverables the way you want.

* Don't forget to consider the maintenance that may be required over the useful life of the software, sometimes 30 years or more.

* Make sure you get everything you will need to recreate the software product--not just the source code.

When you buy a new tool or appliance, it's easy to get caught up with its features and how well it works--and neglect to think about future maintenance. Don't throw away the opportunity to acquire what it takes to maintain the item later on. Similarly, when contracting for software, get and save what you'll need to maintain it over its lifetime.

Kaniss is the chief engineer of the Software Engineering Division of the Naval Air Systems Command. He holds a master's degree from Villanova University in computer science.

The author welcomes comments and questions and can be contacted at
COPYRIGHT 2005 Defense Acquisition University Press
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2005, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:data rights requirements analysis
Author:Kaniss, Al
Publication:Defense AT & L
Geographic Code:1USA
Date:Mar 1, 2005
Previous Article:A risky fable.
Next Article:Using military standards in acquisition programs.

Related Articles
Prospecting for prospective payment software.
HIPAA Privacy Rules Challenge Long-Term Care Providers. (Computer Quarterly Update).
Teleservices plus: multichannel, outsourced Customer Relationship Management (CRM). (Outsourcing).
A road map to HIPAA compliance.
Planning and implementing an ERP system.
Addressing power and thermal challenges in the datacenter.
Survey finds only 18% of providers ready for HIPAA.

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters