Winning the Cage-Match: How to Successfully Navigate Open Source Software issues in M&A and other Transactions
•Download as PPTX, PDF•
0 likes•151 views
A blow-by-blow discussion of key open source software-related issues and deal points from the point of view of buyer/investor vs. seller/investee. Understanding the key legal and technical risks, as well as strategies for mitigating them, will help you to speed and smooth negotiations, avoid protracted due diligence and get better deal terms, increasing overall value.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Winning the Cage-Match: How to Successfully Navigate Open Source Software issues in M&A and other Transactions
Similar to Winning the Cage-Match: How to Successfully Navigate Open Source Software issues in M&A and other Transactions (20)
More from Black Duck by Synopsys
More from Black Duck by Synopsys (20)
Recently uploaded
Recently uploaded (20)
Winning the Cage-Match: How to Successfully Navigate Open Source Software issues in M&A and other Transactions
- 1. 1 1 Winning the Cage-Match How to successfully navigate open source software issues in M&A and other transactions
- 2. 2 A. Background: Casting the Net B. Motivation: Why Should You Care About This? C. The Deal: Stages and Issues D. Takeaways Overview
- 3. 3 • Software+ • Transactions • Business Models • Inadvertent Software Companies Background: Casting the Net
- 4. 4 • 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+
- 5. 5 • 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
- 6. 6 • Applies to all sorts of business models • Traditional distributed • Hosting • SaaS • PaaS • IaaS • Internal use • In support of professional services Background: Business Models
- 7. 7 EVERYONE Automotive Retail Healthcare SoftwareInfrastructure Banking & Financial Services Internet of Things Mobile & Home Background: Open Source Software is Everywhere
- 8. 8 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
- 9. 9 Motivation: Why Should You Care About This? • Licensing and Compliance Risk • Security Risk • Business and Operational Risk • Remediation Risk • Recent Enforcement and Litigation
- 10. 10 • Use beyond scope of license • Breach of licenses; automatic termination since no materiality • Copyright infringement • ‘Viral’ infection of proprietary code • Automatic grant of licenses to certain of your patents • Defensive patent termination rights • 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 Motivation: License and Compliance Risk
- 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 • 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
- 13. 13 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
- 14. 14 Motivation: Recent Enforcement and Litigation • Partick McHardy, Harald Welte, and Hellwig v. VMware • Actions aimed at personal financial gain (McHardy) and GPL-compliance (Welte and Hellwig) • McHardy uses aspects of German law to extract ever-increasing settlements from defendants • Welte won a case against Fantec, where the court indicated that it is insufficient for a software vendor to rely on the assurance of GPL license compliance of its suppliers • Christoph Hellwig’s recently dismissed case against VMware (dismissed on procedural grounds) claimed that VMware’s VMkernel is a derivative work of vmklinux, which is a derivative work of the Linux kernel, and therefore is subject to the GPL • Other recent cases: Continuent v. Tekelec • Alleged GPL violations, copyright infringement; sued for “all profits” • Settled in 2014 for undisclosed amount • Remediation appears to have been trivial • Oracle bought Tekelec prior to suit XimpleWare v. Versata • Alleged GPL violations, copyright infringement; sued for $150m • Settled in 2015 for undisclosed amount • Remediation was trivial (patch released in 2 weeks) • Trilogy bought Versata prior to suit CoKinetic v. Panasonic • Business dispute leads to GPL-related claims by licensee • CoKinetic demanded source code first • Damage demands in excess of $300m • Filed in March 2017 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 • Filed in December 2016
- 15. 15 The Deal: Stages • Pre-LOI/Before the Next Transaction • LOI/Transaction Kick-Off • Due Diligence Process • Definitive Agreement • Scheduling reps • Substantive reps • Covenants and closing conditions • Indemnification and escrow • Overall Impact/Open Source 2.0
- 16. 16 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 deals (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
- 17. 17 Pre-LOI/Before the Next Transaction • Buyer: • Line up your team and advisors and develop a game plan • Prioritization plan • By product • By category of component • By license or usage type • Substantive plan • Know what will and will not be approved • Update documents • Diligence requests, reps and warranties, etc.
- 18. 18 Pre-LOI/Before the Next Transaction • Seller: • Get your house in order • Avoid the “no time for this crap” trap • 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 • Ready on both internal code and transactions • Know your likely buyer/investor • Address any known issues; remediation and explanations
- 19. 19 LOI/Transaction Kick-Off • Both sides should work to set expectations early • Avoid surprises • Surprises cause conflict
- 20. 20 LOI/Transaction Kick-Off • Buyer: • Reference the code scan in the LOI • Eliminates surprise, also allows to kick off the code scan process as soon as possible • Decide which product(s) and version(s) should be scanned; prioritization • Require simultaneous self-disclosure • Push for Seller to disclose correct personnel • Seller: • 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)
- 21. 21 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
- 22. 22 Due Diligence Process: Requests
- 23. 23 Due Diligence Requests: Third Party Software Policy • Buyer: • Request copy of third party software policy • Is it written? • Date implemented • What is the approval process? • How is it documented? • Ongoing compliance? • Note how long it takes to obtain responses • Seller: • Have a good story ready if you do not have a written policy • Small development team • Approval by single technical resource • Informal policy
- 24. 24 Due Diligence Requests: List of Third Party Software • Buyer: • 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 • Note how long it takes to obtain responses • Seller: • This is where the pre-LOI preparation really pays off • But mind the reps! • Nuanced approach to whittle down requests • Narrow the scope of usage collection • Try to avoid license collection • Both of these are time-consuming at this stage
- 25. 25 Due Diligence Requests: Additional Requests • Buyer: • Request copy of notice and attribution files • Request copies of open source contribution policy/guidelines • Any open-source products? • Note how long it takes to obtain responses • Seller: • Notice and attribution files • Make sure anything you provide is up-to-date • Sometimes can be created very quickly • Open source contribution • Describe process and oversight (if any)
- 26. 26 Definitive Agreement: Scheduling Reps • This is what it looks like in the real world:
- 27. 27 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 Definitive Agreement: Scheduling Reps • Scope matches that of diligence requests • No duplication of effort • No wasted time
- 28. 28 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 • Buyer: • Match rep to diligence • Reliance on disclosures • True, correct, and complete • Seller: • 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
- 29. 29 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
- 30. 30 Definitive Agreement: Substantive Reps
- 31. 31 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 The 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 Definitive Agreement: Substantive Reps
- 32. 32 Definitive Agreement: Substantive Reps • Buyer: • Standard reps; making sure no viral use • Buyer should not take on Seller’s risk • Current enforcement actions • Financial risk • Seller: • 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
- 33. 33 Definitive Agreement: Covenants and Closing Conditions • Types: • Commercially reasonable or best efforts covenant • Actual closing condition • Typically focused on: • Code remediation • Legal remediation • On-going ability to perform code scans and continue diligence
- 34. 34 Definitive Agreement: Covenants and Closing Conditions • Buyer: • Remediate any non-compliant use • Remediate security issues • Clean code on day 1 • Argue for closing conditions • Especially for high-risk items • Seller: • Clean code = less remediation • Excessive/specific requests • Industry practice
- 35. 35 Definitive Agreement: Indemnification and Escrow • Specific indemnities • Errors/omissions and breaches/non-compliance with in-licensed software related reps • 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 • 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
- 36. 36 Definitive Agreement: Indemnification and Escrow • Buyer: • 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 • Seller: • Clean shop = fewer indemnities • Try to lower risk with narrowly- tailored indemnities • Split costs for remediation • Buyer has skin in the game
- 37. 37 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
- 38. 38 Open Source 2.0: Strategic Use in a Transaction • Go beyond compliance • Create leverage • Control the diligence process • Create concessions • Get better terms
- 39. 39 Takeaways: Protecting and Assessing the Code Base
- 40. 40 Takeaways 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
- 41. 41 Anthony Decicco Member GTC Law Group 617.314.7892 adecicco@gtclawgroup.com www.gtclawgroup.com Thank You Leon Schwartz Associate GTC Law Group 617.903.0352 lschwartz@gtclawgroup.com www.gtclawgroup.com
Editor's Notes
- With a transaction timing is everything Preparation matters for both sides; helps things go smoothly both in everyday business and in transactions The goal is to identify, analyze, and mitigate risks associated with the use of third party software (we will talk about this in more detail in a bit) Poor practices (by either buyer or seller) can lead to: Financial issues: you get sued or you make less at your exit Business issues: injunctions (actual injunction rare)/stop-ships Deal issues: unfavorable terms/risk in your deals Work completed pre-LOI can impact your deal terms Buyer knows what to look for to try to find problems Seller knows what’s in their code (this is rare) and can try to reduce rep burden
- Line up your team and advisors and develop a game plan Internal team: Line up personnel from legal, business, and development groups to handle review and decision-making (sometimes this is one person wearing many hats) Contracts in place with providers (e.g. Black Duck) If want to complete a code scan, need to kick that off right after you sign the LOI; have your agreement in place in advance Prioritization plan What will be reviewed and when; can prioritize review by” Product – by revenue or strategic importance Category of component – embedded/production, dev tools, infrastructure Category of third party license: less review for permissive licenses; pick out likely risky licenses first Tailor the level of review and timing of review to the risk: what needs to be done pre-sign, pre-close, post-close, during integration Why spend precious pre-signing time on reviewing low-risk components, when you can review those post-signing? Allows you to spot deal-breakers early in diligence, so you can avoid high legal and other costs for transactions that will not close Substantive plan Know what will and will not be approved Understand your approach to open source and inbound licenses on the substance, so you know going in what you will approve and not approve, so you are not determining all of this during ‘deal time’ when it could have been done in advance Try to avoid issues of first impression on a deal (especially for well-known, common license types and/or use cases) Documents You will never get answers to questions you do not know to ask Make sure that your diligence requests are up to date and capture all you would want to know Include right to complete code scans in your documents (LOI, on-going right in license agreements) Update your reps and warranties; always easier to have them in the first draft of the agreement than to try to introduce them at a later date