Page 232 - Automated Fingerprint Identification Systems (AFIS)

CONTRACTUAL ISSUES REGARDING THE PURCHASE OF AN AFIS 217

ment’s interest in the AFIS and (depending on the nature of the AFIS) the
impact such termination would have on the health, welfare, and safety of the
citizenry.
A related concept is whether it is permissible for the vendor to incorporate
hardstop or other coding that permits the vendor to “turn off” or disable the
software under specified conditions. Such a clause is extremely disruptive and
can constitute a major breach of security. In general, the vendor will have
numerous other ways to protect its intellectual property rights, due in part to
its maintenance responsibilities requiring constant contact with the System, and
such severe remedies are not warranted. Again, legal counsel can provide assis-
tance in this issue.
The software license also clarifies whether the government can transfer the
license and the permissible circumstances for the transfer. The government
needs to consider if it might need the ability to transfer or co-locate the soft-
ware on a consolidated data system.
When seeking the pricing for the software license, if a test bed system will
be acquired, the vendor should provide different pricing for this license.
Arguably, since the test bed system is not a production system and serves to
benefit the operations of the System, there should be favorable pricing for such
licenses.
• Verifying Functionality: At the RFP stage, the means for verifying the function-
ality of the software will be stated in very general terms, if at all. Language may
indicate that there will be acceptance testing and that such acceptance testing
is subject to the mutual agreement of the parties. It may even broadly outline
time frames for the development of acceptance test procedures and plans.
Rarely does the RFP detail the process, the expectations, or the consequences
of not passing the acceptance test; such language is reserved for the contract
negotiation stage. Given the critical importance of acceptance testing from both
the government’s perspective (to ensure that it obtains the System it needs)
and the vendor’s perspective (since successful completion of acceptance testing
usually triggers payments and commences the software maintenance period
and associated fees), acceptance testing issues should be considered early in
the process. The government should ensure that anything relied on during the
evaluation is part of the acceptance test. For example, suppose that during the
RFP process or the contract negotiation process, the vendor provides product
literature with various representations. If that product literature or the repre-
sentations are not part of the contractual requirements, arguably they should
not be part of the acceptance testing and are not a requirement of the soft-
ware. While there are different ways to address this issue, it is something to be
aware of and incorporate into the planning process.