Anthony Decicco, shareholder, GTC Law Group presented at FLIGHT West 2018. His session description included: A buyer and investor focused discussion of key open source software-related issues and deal points. Understanding the key legal and technical risks, as well as strategies for mitigating them, will help you to focus due diligence, speed and smooth negotiations and get better deal terms, increasing overall value and avoiding post-transaction surprises. For more information, please visit us at www.blackducksoftware.com

1. 1
1
A Buyer/Investor Playbook for Successfully
Navigating Open Source Software Issues in M&A
and other Transactions

2. 2
• Background
– Casting the Net
• Motivation
– Why Should You Care About Open Source?
• Transactions
– Buyer/Investor Playbook
• 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
Transaction Playbook
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
LOI/Transaction Kick-Off
• Both sides should work to set
expectations early
• Avoid surprises
• Surprises cause conflict

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

25. 25
Due Diligence Requests: Sample

26. 26
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?

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

28. 28
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?

29. 29
Due Diligence Requests
Provide responses quickly, but
accurately!
Note how long it takes to obtain responses!
If all else fails…

30. 30
Definitive Agreement: Scheduling Reps

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

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

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

34. 34
Definitive Agreement: Substantive Reps

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

36. 36
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…

37. 37
Definitive Agreement: When All Else Fails…

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

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

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

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

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

43. 43
• 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

44. 44
The Takeaways

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

46. 46
Protecting the Code Base

47. 47
Open Source 2.0: Strategic Use in a Transaction
• Go beyond compliance
• Create leverage
• Control the diligence process
• Create concessions
• Get better terms

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

49. 49
Anthony Decicco
Shareholder*
GTC Law Group & Affiliates
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
* Shareholder, GTC Law Professional Corporation, the Canadian affiliate of GTC Law Group PC