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.