Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Open source software 101: Compliance and risk management


Published on

This presentation by Sam Ip, an associate in Osler’s Technology Group, details key considerations for emerging and high growth companies regarding OSS.

Published in: Law
  • Be the first to comment

Open source software 101: Compliance and risk management

  1. 1. Osler, Hoskin & Harcourt LLP Sam Ip Technology Business Group Open Source Software 101 for Start-ups
  2. 2. 2 OPEN SOURCE SOFTWARE TRENDS AND DEFINITIONS Why does Open Source Matter? • Almost Every Company Today Uses Open Source • 80%+ of companies (tech + non-tech) run on open source software; • Very few companies build software entirely from scratch. • Yet, the vast majority of companies are not in compliance with open source licenses • 55% of companies have no formal procedure or policy; • Less than 40% even know what open source they are using. • Consequences are not trivial • Could be required to give away proprietary source code** • Could be required to give away patent rights • Could result in loss of rights to use open source software
  3. 3. 3 Agenda Osler’s Open Source License Identification Tool Practical Tips to Mitigate Such Risks Risks – Sample Acquisition Scenario Open Source Software Primer
  4. 4. Open Source Primer
  5. 5. 5 OPEN SOURCE PRIMER What is Open Source Software? Open Source Software is software where the source code is made available under an open source license. Examples? Firefox, Android, Mozilla….in fact, most of the Internet is built on open source software. Source: Open Source Initiative, “The Open Source Definition”,
  6. 6. 6 Open Source Software is about a movement… OPEN SOURCE SOFTWARE PRIMER …and the ethos that software should be “free”.
  7. 7. 7 OPEN SOURCE SOFTWARE PRIMER Many licenses are written by programmers, and they have a sense of humor… Beerware License. You can use the software as long as you buy the guy a beer if you see him at a bar. “As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp”
  8. 8. 8 OPEN SOURCE SOFTWARE PRIMER Other licenses are a little wacky… Death and Repudiation License. You can only use software if you are dead. “This software may not be used directly by any living being…any living being using (or attempting to use) this software will be punished to the fullest extent of the law. For your protection, corpses will not be punished. “ ….. So how would you use it?
  9. 9. 9 OPEN SOURCE SOFTWARE PRIMER ….. But the license provides an “out”: “We respectfully request that you submit your uses (revisions, uses, distributions, uses, etc.) to your children, who may vicariously perform these uses on your behalf. If you use this software and you are found to be not dead, you will be punished to the fullest extent of the law.”
  10. 10. 10 OPEN SOURCE SOFTWARE PRIMER But in many cases, many open source developers felt the best way to make software “free”, is to make the licenses the least restrictive as possible. • We call these licenses “permissive” licenses. • Permissive licenses have very little restrictions and obligations, letting you effectively do whatever you want at no cost (e.g., copy it, distribute it, sell it, build your own products on top of it, etc.) • E.g., MIT License: ◦ “Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions…”
  11. 11. 11 OPEN SOURCE SOFTWARE PRIMER In other cases, some open source developers felt the best way to make software “free” is to include a “viral” element to ensure software always remains “free” and infects other software to make other software “free” too. • We call these licenses “viral” or “copyleft” licenses • Characteristics (Problems) with Copyleft Licenses? ◦ (1) If you distribute the “copyleft” software, often you must disclose source code. ◦ (2) If you build software that is based on the “copyleft” software, often you must also disclose your proprietary source code. • E.g., General Public License (GPL), Affero General Public License (AGPL)
  12. 12. 12 RISKS OF USING OPEN SOURCE SOFTWARE Top Licenses Mapped on a Spectrum Permissive Strong Copyleft /Viral BSD Apache MPL/Eclipse LGPL GPL Affero MIT
  13. 13. Risks In The Context of a Typical Scenario - Due Diligence Conducted by Strategic Acquirer.
  14. 14. 14 RISKS OF USING OPEN SOURCE SOFTWARE You are a technology company being evaluated for acquisition by a strategic acquirer…. Facts ◦ As is often the case, your solution is comprised of: • (1) distributed software • (2) web/cloud-based platform • (3) mobile application ◦ You use the following open source licenses: Apache, General Public License (GPL), and the Affero General Public License (AGPL)
  15. 15. 15 RISKS OF USING OPEN SOURCE SOFTWARE What is a Strategic Acquirer Concerned with? 1. Are you (target) in compliance with Open Source Licenses? ◦ Risk Implications: Loss of rights to use the OSS Software; monetary damages; reputational risks; expensive to remediate? 2. Will you (target) be required to give away your source code, particularly their proprietary source code? ◦ Risk Implications: Dilution of value. 3. Will we expose our proprietary source code and patents when we integrate with your (target’s) products? ◦ Risk Implications: Infect acquirer’s Source Code? Or require us to grant unintended licenses to our patents? 4. What does Target’s have open source practices look like?
  16. 16. 16 RISKS OF USING OPEN SOURCE SOFTWARE Step 1: Ask Target Company for Inventory of Open Source Materials, with a focus on copyleft licenses. Permissive Weak Copyleft Strong Copyleft BSD Apache MPL/Eclipse LGPL GPL Affero MIT
  17. 17. 17 RISKS OF USING OPEN SOURCE SOFTWARE Step 2: Evaluate the open source in distributed software. ◦ General Rule: The majority of source code disclosure requirements in open source licenses are triggered on distribution. No distribution; no source code disclosure, no “viral” effects. • For example: If there is GPL code (an example of copyleft) in distributed software, there is the risk that you will need to give away your proprietary code if you combined it with the GPL code (e.g., through linking). • This dilutes the value of your IP and potentially limits the ability of the acquirer to integrate with its own products without a potentially expensive remediation effort.
  18. 18. 18 RISKS OF USING OPEN SOURCE SOFTWARE Step 3: Evaluate open source in cloud-based platforms ◦ General Rule: For cloud-based platforms, you are at risk of source code disclosure if you have used copyleft licenses: (1) in web-pages; or (2) written specifically for cloud-platforms. • For example, if GPL code (an example of copyleft license) is used in client-side JavaScript, the act of someone loading your webpage is a “distribution”, and will trigger source code disclosure obligations. • As another example, if AGPL code (an example of copyleft license written specifically for cloud-platforms) is used in server-side code, someone accessing your website will trigger source code disclosure obligations • Again, this dilutes value of your IP and creates risk for acquirer.
  19. 19. 19 RISKS OF USING OPEN SOURCE SOFTWARE Step 4: Evaluate open source in Mobile Applications ◦ General Rule: For Mobile Applications, copyleft licenses intended for libraries (e.g., source code modules or building blocks) are often incompatible with popular application stores (e.g., Apple AppStore), and you will be in violation of the license. • For example: if you use LGPL code (example of copyleft license designed for libraries) to build a mobile application deployed on AppStore, you are likely in violation of the LGPL license. This is because AppStore often requires software to be signed (i.e., unchangeable), whereas LGPL requires the ability for someone to change the open source code and put it back together again. • The acquirer would need to remediate this violation to be in compliance, and can be expensive.
  20. 20. 20 RISKS OF USING OPEN SOURCE SOFTWARE Step 5: Evaluate Patent, Security and Operational Risks ◦ Does the Target have a large IP portfolio, and do any of these open source licenses grant rights to them? • E.g., Licenses such as Apache contain patent licenses that may be unintended. ◦ Do any of the open source software create any security issues? • E.g., Open-SSL (heartbleed) ◦ How is the Target’s open source practices? • E.g., How reliable is the Target’s practices for managing open source usage? Do they have an open source policy? Do they comply with it?
  21. 21. Summary of Practical Strategies to Mitigate Risks of Using OSS
  22. 22. 22 PRACTICAL TIPS OF MANAGING USE OF OPEN SOURCE SOFTWARE Create and Maintain Inventory of Open Source Usage ◦ Take stock of your open source software used. ◦ Not all Use Cases present equal risks; divide into 3 buckets and focus on the high-risk categories: 1) Back-end Office Tools (Low Risk) 2) In Products that are Not Distributed to Customers (Low Risk) 3) In Products that are Distributed to Customers (Potentially High Risk Depending On License)
  23. 23. 23 RISKS OF USING OPEN SOURCE SOFTWARE Cautious Use of Copyleft Licenses in Distributed Software ◦ Undisciplined use and distribution of copyleft licenses can result in the requirement to disclose source code, including your valuable proprietary code. • Note: Popular copyleft licenses include: General Public License (GPL), Affero General Public License (AGPL), Lesser General Public License (LGPL), Eclipse Public License and Mozilla Public License ◦ If there is no “distribution”, it is unlikely you will need to disclose source code. ◦ If there is a “distribution”, you should ensure your proprietary code is sufficiently isolated from the copyleft code so that it is not “infected”. (e.g., avoid linking code together). This way, the only code you need to disclose is limited to the open source code.
  24. 24. 24 RISKS OF USING OPEN SOURCE SOFTWARE Watch Out for Often Over-Looked Scenarios • Use of Copyleft Licenses in the Cloud That Require Source Code Disclosure. ◦ E.g., General Public License (GPL) in client-side Javascript; Affero General Public License (GPL) in server-side code. • Use of Copyleft Licenses for Mobile Apps on the App Store That You Cannot Comply With. ◦ E.g., Lesser General Public License (GPL) and the Apple App Store
  25. 25. 25 HOW TO MITIGATE RISKS OF USING OPEN SOURCE SOFTWARE Governance Strategy and Policy 1) Open Source Policy. A good open source policy includes: ◦ Internal Usage ◦ Release and Distribution ◦ License Compliance ◦ Open Source Request and Evaluation ◦ Support and Maintenance ◦ Community Participation 2) OSS Governance. A team of legal, business, and technical professionals should be established to govern the use of open source software. 3) Regular On-going Audit. Periodic software audits should be performed (e.g., Black Duck Software.) 4) Training.
  26. 26. Osler’s Open Source Software License Identification Tool
  27. 27. 27 OPEN SOURCE SOFTWARE TRENDS AND DEFINITIONS Osler Open Source License Identification Tool • Purpose of Tool: Provide a cost-free way to help technology companies and companies that develop software manage open source risks. Also helps VCs, PE and strategic purchasers perform preliminary OSS due diligence on companies. • What the Tool Does: Identifies in the top 15-20 licenses in your source code. Unless you know what open source software you are using, you will not be able manage your use! • What the Tool Does Not do: Not intended to be a replacement for third party source code audit service providers (e.g., Black Duck Software or Flexera). • Cost: Free
  28. 28. Thank You