Developing Mixed-Source Commercial Products - OSS Risks and Mitigation
- 1. © Jim Markwith 2015. All Rights Reserved. 1 Developing Mixed-Source Commercial Products: Open Source Software Risks and Mitigation By: Jim Markwith, Esq.
- 2. © Jim Markwith 2015. All Rights Reserved. 2 Biographical Information Title: Developing Mixed-Source Commercial Products: Open Source Software Risks and Mitigation Author: Jim Markwith, Esq., Managing Partner, Symons Markwith LLP, Seattle, WA. Phone: +1-206-714-6003 E-Mail: Jimmarkwith@gmail.com Jim Markwith is the Co-founder and Managing Partner of Symons Markwith LLP’s Seattle office. His clients represent a range of industries and offerings, including healthcare IT, computer software, data analytics, standards development organizations (SDOs), and other emerging technologies and services. He specializes in technology and intellectual property transactions, establishing end-to-end contracting processes, supporting healthcare IT and cloud-based product development, HIPAA and privacy compliance, open source software use and compliance, and M&A. Prior to private practice he served as Senior Vice President and Chief IP Counsel for Allscripts Healthcare, and held senior in-house legal positions with Microsoft, GE Healthcare IT and Adobe Systems. He is an Adjunct Professor at the Law School Graduate Program in Intellectual Property (LLM) at the University of Washington. Prior to his legal career Jim was a U.S. Navy Pilot. Education: J.D., Santa Clara University School of Law; B.S.B.A., Finance, California State University at Long Beach. Bar Admissions: California; Washington State; District of Columbia.
- 3. © Jim Markwith 2015. All Rights Reserved. 3 Introduction This paper provides an overview of open source software (“OSS”) from a legal and developer’s perspective, discusses risks associated with non-compliant use of OSS, including use in the Cloud, and provides recommendations to mitigate risks. Using Third-party Software during Development During the product development life cycle, developers must decide what functionality they will develop in-house, and what they will buy or license from third parties. That buy v. build decision should take into account not only the cost of the third-party code, but other important considerations as well, including the code quality, security vulnerabilities, and intellectual property related risks, associated with the particular third-party code. Open Source Software Defined From a software developer’s perspective, OSS should be viewed simply as a subset of third-party software. This view is helpful because most developers know that they should not use third-party software without permission, which is typically in the form of a license. As with proprietary software1, the license associated with the particular OSS must be reviewed in order to understand the rights and conditions that may apply to the use of that particular code. 1 “Proprietarysoftware” is software that is subject to licenses that typically restrict the licensee’s right tocopy, redistribute, or modify the software, and normally do not grant access to the software’s source code. These restrictions help to protect the developer’s investment in the software by preventingthird parties from expropriating the software’s economic value without the developer’s authorization. See also: http://en.wikipedia.org/wiki/Proprietary_software