National Academies Press: OpenBook

Technology Contracting for Transit Projects (2017)

Chapter: 2 Technology agreements, types of software, methods of project delivery and related issues

« Previous: 1 Introduction
Page 4
Suggested Citation:"2 Technology agreements, types of software, methods of project delivery and related issues." National Academies of Sciences, Engineering, and Medicine. 2017. Technology Contracting for Transit Projects. Washington, DC: The National Academies Press. doi: 10.17226/24869.
×
Page 4
Page 5
Suggested Citation:"2 Technology agreements, types of software, methods of project delivery and related issues." National Academies of Sciences, Engineering, and Medicine. 2017. Technology Contracting for Transit Projects. Washington, DC: The National Academies Press. doi: 10.17226/24869.
×
Page 5
Page 6
Suggested Citation:"2 Technology agreements, types of software, methods of project delivery and related issues." National Academies of Sciences, Engineering, and Medicine. 2017. Technology Contracting for Transit Projects. Washington, DC: The National Academies Press. doi: 10.17226/24869.
×
Page 6
Page 7
Suggested Citation:"2 Technology agreements, types of software, methods of project delivery and related issues." National Academies of Sciences, Engineering, and Medicine. 2017. Technology Contracting for Transit Projects. Washington, DC: The National Academies Press. doi: 10.17226/24869.
×
Page 7

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).

Next: 3 State Statutes Applicable to Technology Contracting »
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!