FLIGHT Amsterdam Presentation - Don’t Let Open Source Software Kill Your Deal
0 likes452 views
The document discusses the impact of open source software on mergers and acquisitions (M&A), highlighting the associated risks such as licensing, compliance, security, and remediation. It outlines the importance of conducting thorough due diligence to identify third-party software and mitigate risks throughout the transaction process. Key recommendations include establishing an open source policy, conducting code scans, and preparing documentation to ensure smooth transactions and avoid potential legal issues.
![37
Company has not accessed,
used, distributed, hosted or
modified any third party software
in such a manner as to:
• Require disclosure or distribution of any
Company product/technology in source code
form
• Require the licensing of any Company
product/technology for the purpose of making
derivative works/modifications
• Grant the right to decompile, reverse engineer or
otherwise derive the source of any Company
product/technology
• Require distribution of any Company
product/technology at no charge or with limited
usage restrictions
• Limit in any manner the ability to charge fees or
seek compensation in respect of any Company
product/technology
• Place any limitation on the right of the Company
to use, host or distribute any Company
product/technology
Company:
• Has no plans to do any of the
foregoing
• Is in compliance [in all material
respects] with the licenses
• Has not been subjected to an
audit, nor received any notice of
intent to conduct any such audit
• Has no payment obligations,
except as scheduled
• Company has remedied all
security vulnerabilities
Definitive Agreement: Substantive Reps](https://image.slidesharecdn.com/gtc-flightamsterdam2018may15v-180621175609/85/FLIGHT-Amsterdam-Presentation-Don-t-Let-Open-Source-Software-Kill-Your-Deal-37-320.jpg)
FLIGHT Amsterdam Presentation - Don’t Let Open Source Software Kill Your Deal
- 1. 1 1 Don’t Let Open Source Software Kill Your Deal: Recent Trends Impacting M&A and Other Transactions
- 2. 2 • Background – Casting the Net • Motivation – Why Should You Care About Open Source? • Transactions – Impact Of Open Source On Your Transactions • Takeaways Overview
- 3. 3 Background Casting the Net • Business Models • The Inadvertent Software Company • Software+ • Types of Transactions
- 4. 4 • Applies to all sorts of business models • Traditional distributed • Hosting • SaaS • PaaS • IaaS • Internal use • In support of professional services Background: Business Models
- 5. 5 Background: Open Source Software is Everywhere EVERYONE Automotive Retail Healthcare SoftwareInfrastructure Banking & Financial Services Internet of Things Mobile & Home
- 6. 6 Agriculture Banks and Financial Services Automotive - Parts Design/Custom Products - 3D printing - DNA sequences Hardware - Medical Devices - Lab and Diagnostics Equipment - POS terminal/bar code reader Content Provider - Media Companies - Publishing Companies - Universities Consumer Products - TVs - Appliances - Internet of Things - Wearables - Toys - Greeting Cards - Locks Mobile Apps; SaaS Platforms; Code on the Devices Distributing and/or Hosting Code Background: The Inadvertent Software Company
- 7. 7 • More than just open source software • Typically any third party in-licensed software • Commercial, freeware and open source • In any form: Object code, binary code, source code, firmware, microcode, drivers, libraries, routines and subroutines • Extends to: APIs, SDKs, protocols, specifications and interface definitions • Not just embedded, but also for development and internal use • Covers inbound SaaS offerings • Sometimes applies to: • Hardware • Data • Inbound content Really any in-licensed software/service (or more) for developing, maintaining, supporting and offering your products and services Background: Software+
- 8. 8 • Applies to all sorts of transactions • Mergers & acquisitions • Divestitures • Financings, including VC/PE investments • Loans • IPOs • Customer/license agreements • Reps and warranties insurance Background: Transactions
- 9. 9 Motivation Why Should You Care About Open Source? • Licensing and Compliance Risk • Security Risk • Business and Operational Risk • Remediation Risk • Recent Enforcement and Litigation
- 10. 10 Motivation: Licensing and Compliance Risk • Breach of licenses; automatic termination since no materiality/cure period • Copyright infringement • ‘Viral’ infection of proprietary code • Automatic grant of licenses to certain of your patents • Defensive patent termination rights • Use beyond scope of license • Transfer/assignment/change-of-control issues • Under licensing; not enough seats/licenses • Combinations of components under incompatible licenses • Notice and attribution non-compliance • Failure to comply with licenses for “fourth party” components
- 11. 11 • Avoid unknowingly using third party software with known security vulnerabilities • Traditional static and dynamic security analysis find few OSS vulnerabilities • No support; self-serve; pull vs. push model • Risk profile changes over time • Any vulnerabilities associated with the components? • Which components? BOM • What are the vulnerabilities? Cross-check databases • Any patches available? Motivation: Security Risk
- 12. 12 • Securing your code from attacks is hard • Securing code you don’t know you are using is harder • You will have vulnerabilities; this is unavoidable • Important to have a policy in place • To routinely check for known vulnerabilities • To perform patches in a planned fashion (no ad-hoc fixes that lead to more problems) • To make sure updates can be enforced / can happen in the field • To properly license your products and shift risk Motivation: Security Risk (continued)
- 13. 13 • Bad practices can: • Break the law • State/local law • e.g. Massachusetts 201 CMR 17 (used to sue Equifax) • GDPR • Article 32 • Result in reputational damage • Cause courts to later find that your security practices were not reasonable • Cause you to be unable to contract with the government • DFARS 204.73 required for DoD contracts since 12/31/2017 • NIST 800-171 compliance likely required for government contractors • Lead to civil liability • 50-state class action suit against Equifax Motivation: Security Risk (continued)
- 14. 14 • Good practices require (at a minimum): • Establishing an open source policy (NIST 800-53, CM-10) • Creating a list of open source software (NIST 800-53, CM-8 and NIST 800-171, 3.4.1) • Following a process for regularly testing security (GDPR, 32) • Recordkeeping of breaches and actions taken (GDPR, 30) • You cannot fix the vulnerabilities in components you do not know you are using! Motivation: Security Risk (continued)
- 15. 15 • Dependence on code from: • Competitor/hostile party • Orphaned/dead project • Think ahead to integration and running the business or things can become very difficult • Changing the offering model • Standardizing on certain components • May be expensive or impossible to collect the key information later Motivation: Business and Operational Risk
- 16. 16 Code Remediation • Removing, rewriting or replacing code • Costs: Engineering, time Legal Remediation • Amending/terminating agreements, seeking clarifications, seeking waivers of past liability, re-licensing components and obtaining new licenses • Often hard to remedy past non-compliance • Costs: Legal, time, fees to licensors Risk Mitigation/Allocation • Additional representations and warranties • Remediation-focused closing conditions and best efforts covenants • Specific indemnities • Additional escrows Motivation: Remediation Risk
- 17. 17 Continuent v. Tekelec • Alleged GPL violations, copyright infringement; sued for “all profits” • Remediation appears to have been trivial • Oracle bought Tekelec prior to suit • Settled in 2014 for undisclosed amount XimpleWare v. Versata • Alleged GPL violations, copyright infringement; sued for $150m • Remediation was trivial (patch released in 2 weeks) • Trilogy bought Versata prior to suit • Settled in 2015 for undisclosed amount CoKinetic v. Panasonic • Business dispute leads to GPL-related claims by licensee • CoKinetic demanded source code first • Damage demands in excess of $300m • Settled in 2018 for undisclosed amount Artifex v. Hancom • Alleged GPL violations, copyright infringement; request for permanent injunctive relief • Hancom used GPL version of Artifex code; could have used commercial license • Settled in 2017 for undisclosed amount Motivation: Recent Enforcement and Litigation • Shifting landscape • No longer brought for ideological reasons • Financial demands (versus demands to release open source); shift from compliance enforcement to revenue generation/protection • Monetizing GPL • Copyright trolls/profiteers (e.g. Patrick McHardy and iptables/netfilter) • Dual-licensing model (e.g. iTextPDF) • Some recent cases:
- 18. 18 Transactions Impact Of Open Source On Your Transactions • Due Diligence Process • What Should You Be Doing (And When) • Pre-LOI/Before the Next Transaction • LOI/Transaction Kick-Off • Diligence Requests • Definitive Agreement – Reps and Warranties – Covenants and closing conditions – Indemnification and escrow • Post-signing/closing
- 19. 19 Due Diligence Process: Overview • Identify • Aim to identify all of the third party software (both commercial and open source) and hardware embedded in or used in the development, maintenance, support and offering of products, along with the applicable licenses and usage facts • Analyze • Understand incompatibilities between the described or proposed use of a given third party component and the license terms for that component • Analyze license terms which may be incompatible with current or proposed business practices • Plan / Remediate / Mitigate / Allocate • Create a remediation plan to address identified issues • Code remediation, legal remediation, notice and attribution • Risk allocation through contract terms • Additional representations and warranties • Remediation-focused closing conditions and best efforts covenants • Specific indemnities • Additional escrows DEVELOP A GAME PLAN TO IDENTIFY, QUANTIFY, MITIGATE AND ALLOCATE THIRD PARTY SOFTWARE- RELATED RISKS
- 20. 20 What Should You Be Doing (And When)?
- 21. 21 Pre-LOI/Before the Next Transaction • Timing is… everything! • Preparation matters • Poor practices can be felt… • In your pocket (financial) • In your work (business) • In your transactions (terms / risk allocation) • Buyers who know what to look for can find problems • Sellers who know what’s in their code can reduce rep burden
- 22. 22 Pre-LOI/Before the Next Transaction (Buyer) • Gain institutional knowledge (know what to look for!) • Get the right people involved • Line up your team and advisors and develop a game plan • Have agreements in place with vendors (e.g. Black Duck) • Develop a policy / substantive plan • Know what will and will not be approved ahead of time • Prioritization plan • By product • By category of component • By license or usage type • Compile / update documents • Diligence requests • Reps and warranties
- 23. 23 Pre-LOI/Before the Next Transaction (Seller) • Get your house in order • Avoid the “no time for this crap” trap • Perform due diligence on your code • Identify, Analyze, Plan/Remediate • The cleaner your code, the cleaner your reps • Remedy all known security vulnerabilities • Third party software policy • Implement (and be able to show that you follow) • Software bill of materials • Using self-disclosure and code scans • Notice and attribution files • Prepare for diligence • Consider industry practices • Know your likely buyer/investor • Address any known issues; remediation and explanations
- 24. 24 LOI/Transaction Kick-Off • Both sides should work to set expectations early • Avoid surprises • Surprises cause conflict
- 25. 25 LOI/Transaction Kick-Off (Buyer) • Code scan • Let Seller know you plan to perform a code scan • Reference in LOI, if possible • Eliminates surprise, also allows to kick off the code scan process as soon as possible • Kick-off call • Conduct kick-off call to learn about products and policies • Prioritization • Decide which product(s) and version(s) should be scanned; prioritization • Self-disclosure • Require simultaneous self-disclosure • Personnel • Push for Seller to disclose correct personnel
- 26. 26 LOI/Transaction Kick-Off (Seller) • Feel out the Buyer • Try to get a feel for what you are about to face • Scope and depth of diligence • Involve and prepare your internal team • High-level tech person (CTO or the like) to drive the process internally • Development resource (knows the code) to answer questions • Line up legal to help in interpreting license provisions • Have the materials prepared earlier available • Consider providing code scan results (if recent) Avoid having to correct responses!
- 27. 27 Due Diligence Requests: Sample
- 28. 28 Materials needed for Identify phase Due Diligence Requests • Possible excuses • Small development team • Approval by single technical resource • Separate security review • Informal policy Third Party Software Policy • Is it written? • Date implemented? • What is the approval process? • How is it documented? • Addresses security vulnerabilities? • Ongoing compliance?
- 29. 29 Due Diligence Requests (continued) • This is where the pre-LOI preparation really pays off • Nuanced approach to whittle down requests • Use pre-prepared materials • But mind the reps! • Negotiate • De-prioritize development tools • Narrow the scope of usage collection • Try to avoid some license collection List of third party software • Cast a wide net: embedded/production, development tools, infrastructure • Consider prioritizing embedded/production • Include requests for any APIs and/or data • Collect usage information • Collect complete copies of licenses • Collect description of known security vulnerabilities
- 30. 30 Due Diligence Requests (continued) Notice and attribution compliance • Make sure anything you provide is up-to-date • Possible excuses • Nothing is distributed • Industry practice Open source contributions • Describe process and oversight (if any) • Explain reasoning (if any) • Possible excuses • Cannot police what employees do on their own time Notice and attribution compliance • Request copy of notice and attribution files Open source contributions • Request copies of open source contribution policy/guidelines • Any open-source products/projects? • Other code contributions?
- 31. 31 Due Diligence Requests Provide responses quickly, but accurately! Note how long it takes to obtain responses! If all else fails…
- 32. 32 Definitive Agreement: Scheduling Reps
- 33. 33 Identify All In-Licensed Software Components • Incorporated, embedded or integrated • Used to offer any Company product/technology • Sold with any Company product/technology • Otherwise distributed by Company • Used or held for use by Company, including use for development, maintenance, support and testing • Scope matches that of diligence requests • No duplication of effort • No wasted time Definitive Agreement: Scheduling Reps
- 34. 34 Information for Each Component: • Relevant version(s) • Applicable license agreement • How incorporated, embedded or integrated • How used internally • How distributed or bundled; distinguish source and binary • Whether linked • How modified • How hosted; allow others to host • Relevant Company products/technologies • Payment obligations • Audit rights Definitive Agreement: Scheduling Reps • Match rep to diligence • Reliance on disclosures • True, correct, and complete • Hard to argue against repping to diligence disclosures • Materiality threshold • Match rep to concessions won • Possible carve-outs: • Low-cost commercial off-the- shelf software • Fourth party code • Non-development software
- 35. 35 List of Contracts Pursuant to Which: • Company has agreed to create or maintain interoperability or compatibility with any third party software/technology • Company has the right to access any software as a service, platform as a service, infrastructure as a service, cloud service or similar service • Company has the right to access, link to or otherwise use data or content Definitive Agreement: Scheduling Reps • Additional scheduling reps • APIs/interfaces • Use of services/SaaS • Data/content
- 36. 36 Definitive Agreement: Substantive Reps
- 37. 37 Company has not accessed, used, distributed, hosted or modified any third party software in such a manner as to: • Require disclosure or distribution of any Company product/technology in source code form • Require the licensing of any Company product/technology for the purpose of making derivative works/modifications • Grant the right to decompile, reverse engineer or otherwise derive the source of any Company product/technology • Require distribution of any Company product/technology at no charge or with limited usage restrictions • Limit in any manner the ability to charge fees or seek compensation in respect of any Company product/technology • Place any limitation on the right of the Company to use, host or distribute any Company product/technology Company: • Has no plans to do any of the foregoing • Is in compliance [in all material respects] with the licenses • Has not been subjected to an audit, nor received any notice of intent to conduct any such audit • Has no payment obligations, except as scheduled • Company has remedied all security vulnerabilities Definitive Agreement: Substantive Reps
- 38. 38 Definitive Agreement: Substantive Reps • Standard reps; making sure no viral use • Buyer should not take on Seller’s risk • Current enforcement actions • Financial risk • Cannot avoid the bulk of these • Can try to shift risk on some items • Notice and attribution • Hosting • Fourth party components • Do the prep, so you know what you need • And if all else fails…
- 39. 39 Definitive Agreement: When All Else Fails…
- 40. 40 Definitive Agreement: Covenants and Closing Conditions • Types: • Commercially reasonable or best efforts covenant • Actual closing condition • Typically focused on: • Code remediation (clean code on day 1 / security issues fixed) • Legal remediation • Ongoing ability to perform code scans and continue diligence
- 41. 41 Definitive Agreement: Covenants and Closing Conditions • Remediate any non-compliant use • Remediate security issues • Clean code on day 1 • Argue for closing conditions • Especially for high-risk items • Clean code = less remediation • Excessive/specific requests • Industry practice • Try to avoid closing conditions
- 42. 42 Definitive Agreement: Indemnification and Escrow • Specific indemnities • Errors/omissions and breaches/non-compliance with in-licensed software related reps; security vulnerabilities • General or in respect of certain agreements, licensors and components • For simultaneous sign/close, include costs of remediation • Often included in IP indemnity and pushes amount higher • Trade-offs with rep and warranty insurance • Additional escrows • Set aside for specific issues and to back-stop specific indemnities • Costs of remediation in simultaneous sign/close can significantly drive up escrow amounts • Often included in general transaction escrow and pushes amount higher
- 43. 43 Definitive Agreement: Indemnification and Escrow • General third party software indemnities • Especially where seller does not know what’s in the code • Cover gray areas • “Dollar one” coverage for riskier items and remediation • Clean shop = fewer indemnities • Try to lower risk with narrowly-tailored indemnities • Split costs for remediation • Buyer has skin in the game
- 44. 44 After the Agreement: Post-Signing • Continue to prod Seller on remediation • Avoid push to close over incomplete remediation • Prepare any needed consent/notice letters • Finish any de-prioritized review • Prepare notice and attribution files (from results of diligence) • Require any new components to go through review process Work does not stop with a signature! • Complete remediation (both compliance and security) tasks so as not to delay closing • Communicate any issues as they arise • Track consents/notices sent and responses received • Identify any new components to go through review process
- 45. 45 • But don’t make the mistake of thinking you are done • Continue practices developed during the process, expand to cover all of buyer’s own code • Put together new approval teams for third party software • Continue to follow approval processes • Keep notice and attribution files up to date • All sides of business should work together to be prepared for the next event • Celebrate! and / or After the Agreement: Post-Closing
- 46. 46 The Takeaways
- 47. 47 Overall Impacts on All Sides of the Transaction Macro Impacts: • Delay • Signing • Closing • Price Uncertainty • Due to expected cost of remediation • Due to estimate of past non-compliance • Plus a premium for the unknown • Deal certainty • Due to conditions • Dependence on third parties • Kill the deal • Upset the build vs. buy decision Diligence/Scheduling Impacts: • Inability to provide basic materials requested in diligence and for schedules • List of in-licensed software with license and usage for each item • Open source policy • Surprises discovered during diligence • Inability to cleanly make reps Overall: • Adds frustration • Increases costs: • Additional diligence • Protracted negotiations • Being prepared makes transaction proceed smoothly • Lower the risk for everyone APPLIES TO ALL IN-LICENSED SOFTWARE, ANY KIND OF TRANSACTION AND ANY BUSINESS MODEL
- 48. 48 Protecting the Code Base
- 49. 49 Open Source 2.0: Strategic Use in a Transaction • Go beyond compliance • Create leverage • Control the diligence process • Create concessions • Get better terms
- 50. 50 Final Thoughts Use of open source software is unavoidable and can have a major impact on a transaction Often insufficient to rely on reps alone The more you look the more you find Almost impossible to undo the impact of poor practices A little can go a long way
- 51. 51 Anthony Decicco Member GTC Law Group 617.314.7892 adecicco@gtclawgroup.com www.gtclawgroup.com Thank You This material is provided for your convenience and does not constitute legal advice or create an attorney-client relationship. Prior results do not guarantee similar outcomes. Attorney Advertising