National Academies Press: OpenBook

Technology Contracting for Transit Projects (2017)

Chapter: 5 Drafting Technology Agreements

« Previous: 4 Applicability of State Contract and Tort Law and Article 2, Uniform Commercial Code, to Technology Agreements
Page 17
Suggested Citation:"5 Drafting Technology Agreements." National Academies of Sciences, Engineering, and Medicine. 2017. Technology Contracting for Transit Projects. Washington, DC: The National Academies Press. doi: 10.17226/24869.
×
Page 17
Page 18
Suggested Citation:"5 Drafting Technology Agreements." National Academies of Sciences, Engineering, and Medicine. 2017. Technology Contracting for Transit Projects. Washington, DC: The National Academies Press. doi: 10.17226/24869.
×
Page 18
Page 19
Suggested Citation:"5 Drafting Technology Agreements." National Academies of Sciences, Engineering, and Medicine. 2017. Technology Contracting for Transit Projects. Washington, DC: The National Academies Press. doi: 10.17226/24869.
×
Page 19

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

17 It should be noted that “UCITA’s definitions of ‘information’ and ‘informational rights’ include content traditionally governed by copyright law and other intellectual property regimes as well as content, notably factual compilations, [that are] explicitly excluded from copyright protection under current law.”207 UCITA “covers much, but not all, of the same subject matter as copyright, as well as subject matter specifically denied copyright protection.”208 UCITA allows contractual protection of public domain information, notably compilations of facts, and allows providers to control all uses of information. UCITA offers compilers the opportunity to “legislate” protection of their products through mass market licenses whose terms are so pervasive as to establish rights “good against the world.”209 However, the Copyright Act210 may preempt state laws, including UCITA, that attempt to protect non-copyrightable data. UCITA recognizes the possibility of preemption, inas much as the Act states that “[a] provision of this [Act] which is preempted by federal law is unenforceable to the extent of the preemption.”211 Finally, although only two states have adopted UCITA, a transit agency should be aware of UCITA’s default rules on choice of law and of the forum appli- cable to an agreement subject to UCITA. V. DRAFTING TECHNOLOGY AGREEMENTS A. Issues and Clauses to Consider When Drafting Technology Agreements Transit attorneys will want to be aware of issues affecting the drafting of technology contracts.212 Accordingly, this part of the report and a checklist in Appendix D identifies issues and clauses for transit agencies to consider when drafting technol- ogy agreements; discusses the development of performance-based, functional, and technical speci- fications for technology agreements; and empha- sizes the importance of interoperability and the interfacing of new technology with a transit agency’s legacy and/or proprietary technology. Footnote 213 includes additional sources on technology contract- ing and checklists of recommended clauses.213 Twenty transit agencies that responded to the survey said that in their experience, there are clauses that are important to include in technology contracts.214 Among the provisions that are impor- tant are clauses that clearly state a transit agency’s expectations on customization, functional require- ments, and delivery timeframe;215 rights of owner- ship, particularly when licensed software generate data; and changes to an agreement.216 MARTA stated that it is “useful to clearly delin- eate the ownership of (and/or royalty free licenses to use) the work product/IP rights in the subject tech- nology” and to have audit rights that allow an agency “to review prior and root software versions” to ensure that the agency is receiving the correct software.217 Also, depending on the purpose of the technology, MARTA stated that it is important to have specific indemnification provisions for a transit agency’s protection.218 Other agencies reported that technology agreements should include clauses permitting termination for convenience, “proof of concept requirements,”219 no-fault termination of an 207 Id. at 327. The author notes that UCITA § 102(35) defines “information” as all “data, text, images, sounds, mask works, or computer programs, including collections and compilations of them” and that § 102(38) defines informational rights as explicitly including all rights cre- ated under current intellectual property laws. Id. N 38. 208 Id. at 334. 209 Id. at 337 (footnote omitted) (emphasis supplied). 210 Pub. L. No. 94-553, 90 Stat. 2541 (1976). 211 UCITA, § 105(a). 212 See, e.g., APTA Report, supra note 1, at 1 (noting provisions to consider). 213 Benesch Law, Tech Procurement eBook Updated, http://www.beneschlaw.com/files/uploads/Documents/ TechProcurement_eBook%20updated%20April%209%20 2015.pdf (last accessed Feb. 24, 2017) (identifying the types of IT contracts as licenses, development agreements, master services agreements, outsourcing agreements, sys- tems implementation agreements, professional services and consulting agreements, support and maintenance agreements, cloud computing agreements, Internet and eCommerce agreements, and combinations of the above) (quotation marks omitted); Simon Cooper, Bespoke vs Off- the-shelf Software (Mar. 2015), http://www.hero-solutions. co.uk/articles/bespokevsofftheshelf.asp (last accessed Feb. 24, 2017) (discussing the pros and cons of bespoke or cus- tom-built software and off-the-shelf software); Joel W. Mohrman, Capitalizing on Intellectual Property: An Intro- duction to Licensing 42, tHe Brief, ABA Winter 2009; Computer Economics, “How to Evaluate IT Procurement Contracts” (Nov. 2008) (providing a checklist for reviewing technology contracts); and Carla Michler, The Procurement Decision - Open or Closed Source Software, 10 deakin L. rev. 261, at 263–64 (2005). 214 See Appendix C, transit agencies’ responses to ques- tion 10. However, twenty agencies said that there were not; two agencies did not respond to the question. Id. 215 See Appendix C, Capital Metropolitan Transporta- tion Authority’s response to question 10. 216 See Appendix C, Maryland Transit Administra- tion’s response to question 10. 217 See Appendix C, Metropolitan Atlanta Rapid Tran- sit Authority’s response to question 10. 218 See id. 219 See Appendix C, Golden Empire Transit District’s response to question 10.

18 agreement,220 and an agency’s right to retain data from programs and any derivative work.221 Like- wise, when relevant, a contract should state whether a vendor is entitled to retain and market a transit agency’s data after contract termination. Appendix D is a detailed checklist of clauses to consider with citations to specific provisions of technol- ogy agreements provided by transit agencies respond- ing to the survey. Part VII of this report discusses in more detail clauses on limitation on liability, indemni- fication, and representations and warranties. B. Types of Specifications Properly considered and drafted specifications are critical to the procurement of technology; however, specifications reportedly are given insuffi- cient attention.222 One source argues that more guidance is needed to improve “the terms and condi- tions and risk management for these procurements,” because “[t]echnology procurements have inherent differences from other procurements….”223 Although the types of specifications appear to overlap, commentators have distinguished functional and other specifications from technical specifications. The term functional specifications “describe[s] software from the user’s point of view,” whereas the term technical specifications concerns issues such as “system architecture and programming languages.”224 The term functional specifications also refers to the specific objectives the client or developer wishes to achieve through the development of the Product. Func- tional Specifications may include, but are not limited to, screen layout, security requirements, record keeping or reporting process capabilities, and any other functional objective agreed upon by the contracting parties.225 Functional specifications “are a general descrip- tion of how one sees or operates the system. They usually include a system overview, a high-level description of the system functionality, a description of the architecture, the description of interfaces with other systems, and a description of the ‘look and feel’ of the system.”226 The term technical specifications includes “the size, number, speed and memory capabilities of the hardware, the response time, the interfaces with other products, and the compatibility with desig- nated hardware or operating system software.”227 Technical specifications detail how coders will imple- ment a system and describe the hardware and soft- ware that will operate a system, as well as provide a technical description of a system’s functionality.228 In responding to the survey, seventeen transit agencies stated that they had used performance- based specifications in lieu of or in combination with other specifications.229 C. Transit Agencies’ Use of Staff, Contractors, or Consultants to Develop Specifications Transit agencies responding to the survey stated that their technology department or other agency employees developed the specifications for their projects230 or that the agency’s staff developed the specifications in conjunction with an engineering firm, contractor, consultant, or vendor.231 Some agen- cies reported that they used an independent contrac- tor or consultant or relied on a request for proposal (RFP).232 The Capital Metropolitan Transportation Authority stated that in some cases, it relied on internal stakeholders and on consultants for its Computer-Aided Dispatch (CAD)/Automatic Vehicle Location (AVL) project. The Milwaukee County Transit System (MCTS) stated that for its real-time and AVL specifications MCTS developed an internal committee and all the work was done internally. For both the fare system and MVSS projects, MCTS conducted an RFP process for qualified consultants and with both RFP’s IBI Consultants was the successful applicant. MCTS worked closely with IBI to develop each technical specification.233 D. Transit Agencies’ Use of Requests for Information or Proposals or a Separate Contract to Develop Specifications If a transit agency is uncertain about the desired technical specifications, a request for information 220 See Appendix C, Greater Peoria Mass Transit Dis- trict’s response to question 10. 221 See Appendix C, responses of Fort Worth Transporta- tion Authority and Utah Transit Authority to question 10. 222 Tollen, supra note 26, at 55–56. 223 APTA Report, supra note 1, at 1. 224 Tollen, supra note 26, at 55. 225 Mark L. Gordon, Key Issues in Contracting for the Development of Joint and Derived Products, 11 comPuter L. J. 1, 18 (1991–92), hereinafter referred to as “Gordon.” 226 Thomas M. Laudise & Leonard T. Nuara, How to Contract for a Successful E-Commerce Development Proj- ect: Beating the Odds, 58 Bus. Law. 299, 311 (2002–03), hereinafter referred to as “Laudise & Nuara.” 227 Gordon, supra note 225, at 18. 228 Laudise & Nuara, supra note 226, at 311. 229 See Appendix C, transit agencies’ responses to ques- tion 12. Twenty-three agencies reported that they had not. Id. Two agencies did not respond to the question. Id. 230 See Appendix C, transit agencies’ responses to ques- tion 11(a). 231 See id. 232 See Appendix C, responses of Golden Empire Transit District, Maryland Transit Administration, and Stark Area Regional Transit Authority (SARTA) to question 11(b). 233 See Appendix C, Milwaukee County Transit System’s response to question 11(a).

19 (RFI) and/or an RFP may be used to obtain informa- tion or guidance from interested licensors or vendors.234 In New York, an RFI may be sent to potential bidders to “elicit responses that would enable the agency to write specifications to provide the agency with the best solution.”235 An RFP may be used to explain the requirements for the software or services that an agency wants to acquire.236 In New York, a request for comment may be used “to solicit input from all potential bidders about a solici- tation’s structure and language to assess its impact on potential bidders.… An agency may submit a Draft RFP to all potential bidders for remarks/ comments prior to issuance.”237 Twenty-eight transit agencies responding to the survey stated that they used various methods to obtain information for the preparation of specifica- tions.238 The agencies said that they used contrac- tors or consultants,239 “expos” and trade exhibits,240 RFIs,241 site visits and/or RFIs from other transit agencies,242 vendors,243 and other forms of research, including the Internet.244 Another approach is to have the writing of speci- fications as a deliverable.245 Thirteen transit agen- cies reported that they had issued a separate contract for the preparation of specifications for their technology acquisitions.246 E. Interfacing With Legacy and/or Proprietary Technology Standards are developing at such a rapid pace that technology systems must be more intercon- nected to exchange or transfer data;247 however, when procuring technology, a transit agency may have a legacy and/or proprietary system with which new software and/or hardware must interface prop- erly. In addition to having proper specifications, an agency will want a contractor, designer, developer, licensor, or vendor to warrant that a new system will be able to interface with the agency’s legacy and/or proprietary technology. Recent articles have discussed the integration of legacy systems with new ones. Genesee & Wyoming kept “an aging train control system in Illinois while linking to a modern, computerized dispatching center in Vermont.”248 Although the existing system entered in service in April 1966, RailWorks Signals & Communications succeeded in interfacing the old equipment with a new centralized dispatch system.249 Another article describes a successful project for WMATA in which the “[s]ystems supporting finance, budgeting, materials management, and mainte- nance management were…replaced and integrated simultaneously.”250 The integration of the systems involved “four major COTS packages…including requirements validation, design, testing, implemen- tation, and deployment of systems….”251 One objec- tive was to “minimize customization” and “leverage built-in industry best practices.”252 234 See State of Texas Contract Management Guide, at 37–38 (Sept. 2015), http://comptroller.texas.gov/procurement/ pub/contractguide/contract-mgmt-guide-v1.14.pdf (last accessed Feb. 24, 2017) (summarizing the differences between invitations to bid, request for information, request for offer, request for proposals, and request for qualifica- tions); Tom McEwen, Randall Guynes, Julie Wartell, & Steve Pendleton, Institute for Law and Justice, Information Technology Acquisition (Final Report), at 45–56 (2002), http://www.ncjrs.gov/pdffiles1/nij/grants/204026.pdf (last accessed Feb. 24, 2017); Del. Code Ann. tit. 29, §§ 6924(b)– (c) (2016); Ariz. Rev. Stat. Ann. §§ 41-2532, 41-2533, and 41-2534(A)–(B) (2016); Colo. Rev. Stat. §§ 24-103-201 and 24-103-203(1)–(2) (2016); 30 ILCS 500/2010(a), 30 ILCS 500/15(a)–(b), and 30 ILCS 500/20-16 (2016). 235 New York State Procurement Guidelines, at 16 (May 2014), hereinafter referred to as “N.Y. Procurement Guide- lines,” http://www.ogs.ny.gov/bu/pc/Docs/Guidelines.pdf (last accessed Feb. 24, 2017). 236 Classen 2d ed., supra note 8, at 5. 237 N.Y. Procurement Guidelines, supra note 235, at 16. 238 See Appendix C, transit agencies’ responses to ques- tion 11(b). Nine agencies reported that they had not; five agencies did not respond to the question. Id. 239 See Appendix C, Mass Transportation Authority’s response to question 11(b). 240 See Appendix C, Brockton Area Transit Authority’s response to question 11(b). 241 See Appendix C, transit agencies’ responses to ques- tion 11(b). 242 See id. 243 See Appendix C, responses of Fort Worth Transpor- tation Authority and Maryland Transit Administration to question 11(b). 244 See Appendix C, responses of Brockton Area Transit Authority, Capital Metropolitan Transportation Author- ity, Cobb County Department of Transportation, and Greater Peoria Mass Transit District to question 11(b). 245 Tollen, supra note 26, at 59. 246 See Appendix C, transit agencies’ responses to question 11(c). Twenty-seven agencies reported that they had not issued a separate contract to develop technical specifications. Id. Two agencies did not respond to the question. Id. 247 APTA Report, supra note 1, at 1. 248 Old and New Tech Combine for G&W Line (Rail- Works Today), July 2016, at 1, http://railworks.com/sites/ default/files/railworks-today/RailWorks-Today-July- 2016-I.pdf (last accessed Feb. 24, 2017). 249 Id. (Internal quotation marks omitted.) 250 Booz Allen Hamilton, Modernizing WMATA Systems: A Transformation Success Alignment of Business and Tech- nology through a Life Cycle Approach (undated), at 1, https:// www.boozallen.com/content/dam/boozallen/media/file/ Modernizing_WMATA_Systems_TLC.pdf <page not found> (last accessed Feb. 24, 2017). 251 Id. at 2. 252 Id.

Next: 6 Technology Contracting and Cloud Computing »
Technology Contracting for Transit Projects Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's Transit Cooperative Research Program (TCRP) Legal Research Digest 51: Technology Contracting for Transit Projects examines issues that transit attorneys should be aware of when drafting technology contracts. It addresses how provisions differ depending on the nature of the contract, the type of technology being procured, and whether the system is controlled internally or externally by the agency. Specific focus is given to cloud computing as an alternative delivery mode, and indemnification. This digest also discusses federal, state, and local industry standards regarding liability and warranties, and the contract language that should be used to protect against data breaches, including inadvertent release of personal information.

Available online are report Appendices A-F and Appendix G.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!