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.
4 government and state and local agencies, including the federal governmentâs rights in patents for inven- tions and discoveries that are federally funded. Also discussed are the Federal Transit Administrationâs (FTAâs) rights in experimental, developmental, or research work that the FTA funds. Part XII analyzes whether a government transit agencyâs data are subject to a Freedom of Informa- tion Act (FOIA) or equivalent state open records law, and if so, whether a transit agency may require a requester to sign an end-user agreement before disclosing data to a requester. Parts XIII and XIV discuss, respectively, procure- ment laws that some states have enacted, as well as FTA policies, that permit transit agencies to negotiate the terms of a technology procurement with contrac- tors, designers, developers, licensors, and vendors to obtain the best price or value for technology and best practices for transit agencies to consider adopting. A survey of transit agencies for the report obtained information on their technology projects and copies of their agreements. Of fifty-two transit agencies responding to the survey, forty-three agen- cies reported that within the past five years they had been involved in the design, development, and/ or procurement of technology that their agency regards as particularly significant because of a proj- ectâs cost, scope, complexity, and/or objectives.2 Nine agencies said that they had not had any projects of significance in the past five years.3 The agenciesâ responses to the survey are discussed throughout the report and summarized in Appendix C. Appendix A is a list of the transit agencies that responded to the survey. Appendix B is a copy of the survey. Appendix C is a summary of the transit agen- ciesâ responses to the survey, including a description of the technology projects that the agencies designed, developed, and/or procured in the past five years. Appendix D is a checklist of clauses for technology agreements. Appendix E is a sample escrow agree- ment. Appendix F is a sample nondisclosure and confidentiality agreement. Appendix G is a compen- dium of technology agreements and other documents that transit agencies furnished for the report. II. TECHNOLOGY AGREEMENTS, TYPES OF SOFTWARE, METHODS OF PROJECT DELIVERY, AND RELATED ISSUES A. Comparison of Technology Contracting to Other Public Contracting Other government contracts, particularly public construction contracts, have influenced technology contracting. In general, because the same rules and methods of procurement apply, government acquisi- tions of technology are similar to the procurement of other types of goods and services.4 In fact, â[t]he complexity of a construction contract is matched if not exceeded by the complexityâ of an information technology (IT) contract.5 One difference, however, is that construction contracts usually are based on technical specifications rather than on performance- based specifications,6 whereas technology contract- ing may involve a mix of performance-based, functional, and/or technical specifications.7 B. Licenses and Other Forms of Agreements As discussed in parts IX, X, and XI, trade secrets, copyright, and patent laws combine to protect an ownerâs IP rights in technology, including software and related systems, rights that may be conveyed by licenses and assignments.8 A license is a contract whereby a licensor grants permission to a licensee to use IP on an exclusive or nonexclusive basis for the term of the license for the use or uses stated in the license. A license enables a licensor to maintain title to its property, whereas an assignment âequates to a sale.â9 A license is more flexible than an assignment or a sale because a licensor is able to âcontrol the permitted locations, duration of use, number of users, and even the permitted uses of the software.â10 Licenses may grant certain IP rights or may grant âall the IP rights necessaryâ¦to create and market a product that complies with a technical standard of specification.â11 The type of technology service or 4 Katherine M. John, Information Technology Procure- ment in the United States and Canada: Reflecting on the Past with an Eye towards the Future, 48 Procurement Law. 4, 9 (2012â2013). 5 William W. Warren, Jr. & Kara P. Scarboro, Standard Terms and Conditions in Commonwealth Contracts, Sym- posium Issue: Pennsylvania State and Local Government Contracting--Practitionerâs Guide to Current Issues, 85 PA Bar assn. QuarterLy 141, 143 (2014), hereinafter referred to as âWarren & Scarboro.â 6 Id. 7 Id. 8 Ward Classen, A Practical Guide to Software Licens- ing for Licensees and Licensors 19 (ABA 2d ed. 2007), hereinafter referred to as âClassen 2d ed.â See also, Stephen J. Davidson, Avoiding Pitfalls and Allocating Risk in Major Software Development and Acquisition Con- tracts, 14 comPuter Lawyer 12 (May 1997). 9 Classen 2d ed., supra note 8, at 11, 19. 10 Michael L. Rustad, The Exportability of Principles of Software: Lost in Translation?, 2 Hastings sci. & tecH. L. J. 25, 31 (2009). 11 World Intellectual Property Organization, IP Assets Management Series, Successful Technology Licensing, at 5â6 (2015), (last accessed Feb. 24, 2017) http://www.wipo. int/edocs/pubdocs/en/licensing/903/wipo_pub_903.pdf. 2 See Appendix C, transit agenciesâ responses to ques- tion 2. 3 See id.
5 system being acquired and the nature of an agree- ment affect the terms and conditions of a contract.12 Although part V and Appendix D provide a checklist of clauses to consider when drafting a technology agreement, two important provisions of a license are the license-grant clause, which describes specifically a licenseeâs rights to use the licensed technology, and the royalties clause, which describes the payments that are due by a licensee to a licensor.13 C. Types of Software Used by Transit Agencies 1. Commercial Off-the-Shelf Software As for the types of technology that transit agencies may procure, one type of software is commercial off-the-shelf (COTS) software. COTS is ââa standardized package or platform regularly used for the deployment of specific applicationsâ that âincludes proprietary products that have already been developed and/or are owned by the Contractor or by third parties.ââ14 Twenty-seven transit agencies responding to the survey said that for some or all of their projects they specified the use of off-the-shelf software.15 2. Open Source Software Open source software, a âmajor factor in the computer industry and in informational technology in general,â16 may be âembedded in commercial soft- ware products and devicesâ¦.â17 Although Linux may be the best known open source program, there are many other programs available for open source licensing, including from âmainstream software companies,â such as IBM, that have released their own version of open source products.18 Twelve tran- sit agencies said that they had specified open source software for some technology projects.19 Open source software is not a technology but âan increasingly popular licensing and distribution method,â20 i.e., a computer program that is available under an open source license.21 Developers of open-source software distribute source code with the software under a generally applicable license. The license provides conditional permission to use copyright- protected material. [T]he licenseâ¦require[s], as a condition of use, that recipients redistributing the software also redis- tribute the source code. More importantly, if the recipients modify the source code, they must make the modifications available to others if they redistribute the software. Finally, recipients who redistribute (with or without modifications) must impose the same terms on their licensees.22 Open source licensing is not about licensing source code but involves the licensing of âbinary computer programs when the source code is avail- able.â23 Although source code is âthe key to main- taining and improving any software program,â24 most users of open source-licensed products do not use the source code but âsimply run and use the binary versions of the program.â25 Although open source software is protected by the copyright laws, âthe source code for such software is widely avail- able and developers are free to fix bugs, add new modules, and otherwise reviseâ the software.26 (In contrast, under the proprietary model for owning and licensing software, a vendor has sole control of the source code.27) Some licensors may license proprietary source code when âthe ability to modify and customize the source code is important to the licensee.â28 In such instances, licensees have a contractual obligation âto keep the source code secret and to distribute only binary derivatives of the source code.â29 Although there are advantages and disadvantages to using open source software, one disadvantage is that â[m]ost open source products come without 12 Classen 2d ed., supra note 8, at 1 13 Joel W. Mohrman, Capitalizing on Intellectual Prop- erty: An Introduction to Licensing, 38 tHe Brief 36, 42â44 (2009). 14 Lockheed Martin Transportation Security Solutions v. MTA Capital Construction Company, Case No. 09, Civ. 4077 & 09, Civ. 4077, 2014 U.S. Dist. LEXIS 131395, at *1, 12 (S.D.N.Y. Sept. 16, 2014) (citation omitted). 15 See Appendix C, transit agenciesâ responses to ques- tion 5(a). Twelve agencies said that they had not specified the use of off-the-shelf software. Id. Three agencies did not respond to the question. Id. 16 Gene K. Landy & Amy J. Mastrobattista, The IT/ Digital Legal Companion: A Comprehensive Business Guide to Software, IT, Internet, Media and IP Law 238 (2008), hereinafter referred to as âLandy & Mastrobattista.â 17 Id. 18 Id. 19 See Appendix C, transit agenciesâ responses to question 5(b). Twenty-five agencies reported that they had not. Id. 20 Landy & Mastrobattista, supra note 16, at 239. 21 Id. 22 Greg R. Vetter, The Collaborative Integrity of Open- Source Software, 2004 utaH L. rev. 563, 570â71 (2004), hereinafter referred to as âVetter.â The writer explains further that â[i]n essence, under this approach, open- source programmers govern how the âworkâ (the software) will be viewed by future users and developers. It must be viewable at least as source code.â Id. at 571. 23 Landy & Mastrobattista, supra note 16, at 239. 24 Id. 25 Id. 26 David W. Tollen, The Tech Contracts Handbook: Soft- ware Licenses and Technology Services Agreements for Lawyers and Businesspeople 179 (ABA 2010), hereinafter referred to as âTollen.â 27 Landy & Mastrobattista, supra note 16, at 240. 28 Id. 29 Id.
6 intellectual property indemnification.â30 There is a risk with open source software that licensees will be left without a remedy if there is a claim for infringe- ment of a copyright or patent.31 A claim could arise because a licensee likely does not know the âprove- nanceâ of any software that it obtains and cannot be certain that a contributor had the right under the copyright or patent laws to make a contribution.32 As one writer cautions, it is important to know open source products and licenses before incorporating open source software in a project.33 It may be noted that, because the intention is that open source soft- ware will be shared rather than kept secret, trade secret laws, discussed in part IX, do not apply to open source software.34 In responding to the survey, the Central Florida Regional Transportation Authority (LYNX) reported that the scope of one of its projects was that the system would use open source software and âaggregate exist- ing technologies as much as possible.â35 The Tri-County Metropolitan Transportation District of Oregon (TriMet) also has specified open source software. One article states that TriMet increasingly has used open source software and off-the-shelf products.36 3. Custom-Built or Customized Software and/ or Systems Transit agencies may acquire custom-built or customized software or systems for their use. Twenty-three agencies reported that they had speci- fied custom-built or customized software for a tech- nology project.37 Some transit agencies may be avoiding the use of customized software. Vermontâs public transit agen- cies used custom software for a rider intake and management system for demand response services;38 however, when ridership increased and the custom software failed to meet the agenciesâ needs, the agencies changed to RouteMatch to meet transit industry standards.39 In a case involving the Metro- politan Transportation Authority (MTA) in New York, there was testimony that the MTA generally does not prefer customized applications because support and maintenance always become an issue with proprietary software.40 4. Systems Using Multiple Types of Software Technology projects may specify the use of more than one type of software. As noted, the Central Florida Regional Transportation Authority (LYNX) said that one of its projects was designed to use open source software and aggregate existing technolo- gies.41 The Greater Cleveland Regional Transit Authority reported that it used off-the-shelf soft- ware for six of its seven projects (e.g., phone system replacement, DriveCam, transit police radio replace- ment, enterprise report writer, and mobile ticket- ing), used both off-the-shelf and custom or customized software for its operator bid dispatch project, and used custom or customized software for its public announcement system.42 D. DesignâBuild Procurement Some state statutes encourage the use of designâ build contracting, including for technology procure- ments.43 Under the traditional designâbidâbuild method of procurement âthe public-sector sponsor retains the design risk; the design and construction work is procured sequentially; and the public sector retains responsibility for operating and maintaining 30 Id. at 243. 31 Id. at 254. 32 Id. at 253. 33 Id. at 256 (emphasis in original). 34 Vetter, supra note 22, at 588. 35 See Appendix C, Central Florida Regional Transporta- tion Authorityâs (LYNX) response to question 5(b). 36 Andy Opsahl, Open Source Software Helps an Oregon Transportation Department for GIS, Website Development, government tecHnoLogy magazine (March 15, 2011), http:// www.govtech.com/e-government/Open-Source-Software- Oregon-Transportation.html (last accessed Feb. 24, 2017). 37 See Appendix C, transit agenciesâ responses to question 5(c). Eighteen agencies said that they had not. Id. Two agencies did not respond to the question. Id. 38 Vermontâs Urban and Rural Transit Agencies to Use RouteMatch Softwareâs Intelligent Transportation Systems (ITS) Platform, routematcH (Sept. 9, 2015), hereinafter referred to as âReuters,â (last accessed March 13, 2017) http://www.marketwired.com/press-release/vermonts- urban-rural-transit-agencies-use-routematch-softwares- intelligent-transportation-2054052.htm. 39 Id. RouteMatch Software âbrings innovative passen- ger transportation technologies that help more than 600 public transit agencies transform rider experiences and manage operational costs. â¦[Its] technologies span⦠scheduling, computer aided dispatching (CAD), routing, analytics, automated vehicle location, and reporting on the âback officeâ to user friendly automated fare collection, mobile apps for âwhereâs my bus?â information, and other multi-modal trip planning tools on the ârider side.ââ RouteMatch, (last accessed Feb. 24, 2017), http://www. routematch.com/. 40 Lockheed Martin Transportation Security Solutions v. MTA Capital Construction Company, Case No. 09 Civ. 4077 & 09 Civ. 6083 (PGG), 2014 U.S. Dist. LEXIS 131395, at *1, 13 (S.D.N.Y. 2014). 41 See Appendix C, Central Florida Regional Transporta- tion Authorityâs (LYNX) response to question 5(a). 42 See Appendix C, Greater Cleveland Regional Transit Authorityâs response to question 5(b). 43 See, e.g., caL. PuB. contract code § 22162(a) (2016) and N.C. gen. stat. § 143-129.8(a) (2016) (stating that because of the âcomplex and innovative nature of informa- tion technologyâ a contract with âa single point of responsi- bilityâ may be used in addition to or instead of other proce- dures available under North Carolina law).
7 the infrastructure.â44 Twenty-three agencies reported using a traditional designâbidâbuild contract for their technology project.45 However, a transit agency may want to use an alternative method of contracting, such as designâ build, to transfer the responsibility from the transit agency to the contractor for the design of any soft- ware and related systems for a project. Nine transit agencies responding to the survey said that they had used designâbuild or another form of project delivery for their technology projects.46 It has been argued that technology contracting is âanalogousâ to designâbuild construction because for many or most IT projects âa single entity devel- ops the business requirements with the â¦agency and then implements the projectâ¦.â47 In designâbuild contracting, âthe design and construction procure- ments are combined into one fixed-fee contract with a âsingle point of contactâ that is responsible for both design and construction.â48 The designâbuild method is said to encourage design creativity, involve the contractor earlier in the process, and shorten the time for project delivery.49 One article states that in 2005 the Metropolitan Atlanta Rapid Transit Authority (MARTA) used designâbuild contracting to acquire technology for its closed-circuit television (CCTV) surveillance system.50 MARTA reportedly saved money because it was able âto take advantage of the technological advancements that occurred between the initial proposal submission and the commencement of the projectâs design phase.â51 E. Maintenance and Support and Service Level Agreements Thirty-six transit agencies stated that they had a maintenance and support agreement for technology projects.52 Twenty-six transit agencies said that they had a service level agreement for technology projects.53 Several agencies provided details on their mainte- nance and support and/or service level agreements.54 F. Acquisition of Technology Through Non- Technology Contracts Transit agencies may acquire technology, and thus need updates, maintenance, and support, through what are essentially non-technology contracts for construction projects or the purchase or lease of âadvanced technologyâ vehicles. For exam- ple, the Department of Energyâs Advanced Vehicle Testing Activity (AVTA) reportedly has begun a full evaluation of the New York City Transitâs new fleet of 125 Orion VII diesel hybrid electric buses featur- ing BAE Systemâs HybriDrive⢠propulsion system that reduces toxic emissions and increases fuel economy.55 Other transit systems are considering alternative vehicle technology.56 G. Escrow Agreements After the commencement of a technology project, a developer may be unable (or unwilling) to support its software, cease to do business, or be purchased by another entity.57 Consequently, transit agencies may want to require a contractor, designer, developer, licensor, or vendor (developer hereafter) of software to sign an escrow agreement. When there is an 44 Edward Fishman, major LegaL issues for HigHway PuBLic-Private PartnersHiPs, Legal Research Digest No. 51, National Cooperative Highway Research Program, Trans- portation Research Board of the National Academies of Science, Engineering and Medicine, Washington, D.C., 2009, p. 5, http://onlinepubs.trb.org/onlinepubs/nchrp/ nchrp_lrd_51.pdf (last accessed Feb. 24, 2017). 45 See Appendix C, transit agenciesâ responses to ques- tion 6(a). Fifteen agencies said that they had not used design-build, and four did not respond to the question. Id. 46 See Appendix C, transit agenciesâ responses to ques- tion 6(b). Twenty-four agencies said that they had not. Id. 47 Warren & Scarboro, supra note 5, at 143. 48 Id. 49 Jason H. Peterson, Note: The Big Dig Disaster: Was Design-Build the Answer?, 40 suffoLk u. L. rev. 909, 916 (2007). 50 Robert M. Bertuca, Design-Build Approach Delivers Enhanced Security for Atlantaâs Mass Transit System, Decreased Risk for Metropolitan Atlanta Rapid Transit Authority, Design-Build Dateline, 1 (2007), (last accessed Feb. 24, 2017) http://www.mcdean.com/services/security/ Sep2007_Bertuca_web.pdf. 51 Id. at 2. 52 See Appendix C, transit agenciesâ responses to ques- tion 7(a). Three transit agencies said that they did not. Id. Three agencies did not respond to the question. Id. 53 See Appendix C, transit agenciesâ responses to ques- tion 7(b). Eleven agencies said that they did not. Id. Five agencies did not respond to the question. Id. 54 See Appendix C, transit agenciesâ responses to ques- tion 7. 55 Leslie Eudy, U.S. dePât of energy, Advanced Technol- ogy Vehicles [AVTA] in Service, âMTA New York City Transitâ (March 2003), http://www.nrel.gov/docs/fy03osti/ 33397.pdf (last accessed Feb. 24, 2017). AVTA âbridge[s] the gap between R&D of advanced vehicle technologies and commercial availability.â Id. 56 See Downtown/Riverfront Streetcar Project, Vehicle Technology Survey Technical Memorandum, (2013), http:// www.riverfrontstreetcar.com/wp-content/uploads/ 2014/03/DT-Riverfront-Streetcar-Vehicle-Tech-Survey- Memo-Dec-2013.pdf (last accessed Feb. 24, 2017). 57 virginia information tecHnoLogies agency, Guidance on Source Code Escrow and Escrow Agreements (undated), 1, hereinafter referred to as âVITA,â https://www.vita.virginia. gov/uploadedfiles/VITA_Main_Public/SCM/Templates/ guidance%20on%20source%20code%20escrow.pdf (last accessed Feb. 24, 2017).