This webinar focuses on the issues related to improper use of open source software and how this can impact M&A and other partnering opportunities. Attendees will learn techniques to uncover potential issues and the benefits of properly managing your software assets to minimize delays and risks. Russell Hartz of SAP’s Corporate Development organization discusses their strategy and perspective on the subject and how they approach this kind of technical due diligence.

1. Technical Due Diligence for M&A: A Perspective from Corporate Development at SAP

2. Speakers Peter Vescuso EVP of Marketing & Business Development, Black Duck Software Hal Hearst Sr. Director, Olliance Group Russell Hartz Corporate Development, SAP

3. Agenda Market trends Why technical DD is needed M&A Issues How it works Code Scanning Analysis SAP: Perspective from a Major Acquirer Summary Note: All registered participants will receive a follow-up email with a copy of the slides and a link to the webinar recording.

6. Need: address challenges of Multi-Source development:

7. Compliance/Management – IP, security, export

10. Universities

11. Corporate DevelopersRussia Your Software Application Obligations YOUR COMPANY – TOOLS, PROCESSES “Open source is a necessary component of all organizations' supply chain strategies. It is essentially a way to manage cost and mitigate 3rd party dependencies.” Brian Prentice, Gartner Group 5

12. Why Technical DD is Needed: Issues Open Source Problems Open source issues arise in the development process and software supply chain Discovery of open source post open source representations Anonymous: Entire source code posted on SourceForge Risks Lose deal Delay deal Reduced price/valuation Lost revenue

13. Why Technical DD is Needed: Issues Use of open source is widespread (despite what your CTO tells you) “A ‘don’t ask, don’t tell’ pact obscures the reality of OSS use” (Jeffery Hammond, Forrester Research,) Major acquirers and licensees are increasingly sensitive to uncertainty in general and this issue in particular (some have separate due diligence process for open source) Difficult to correct problems during merger frenzy Delay may be deadly to the deal

14. Open Source Licenses Open source licenses give broad rights Copy, modify, redistribute Includes express or implied patent rights But also obligations, which are triggered on distribution not on use Product Risks Uncertain "pedigree" "AS IS“ Copy left nature of GPL & other licenses

15. Risks of Unmanaged Code Loss of Intellectual Property License Rights and Restrictions Software Defects Export Regulations Injunctions Contractual Obligations Security Vulnerabilities Escalating Support Costs

17. Cisco

18. Verizon

19. Monsoon Multimedia

20. Xterasys

21. High-Gain Antennas

22. Bell Microproducts

23. Super Micro Computer

24. Motorola

25. Acer

26. Skype

27. D-Link

29. ASUS eeePC laptop

30. DieboldValuation Infringement Remediation Costs New revenue Support costs Vulnerability

31. Technology Allows Easy Discovery of Unknown Open Source Black Duck Analysis Compare code in target’s code base against comprehensive KB of open source components Generate a software Bill of Materials, identify license obligations and conflict analysis Code Base Validation Server Open Source Report Third Party Code KnowledgeBase License Conflict Bill ofMaterials Internal Code Projects Licenses

33. Name, description, versions, URL

34. License, programming language, OS

35. National Vulnerability Database

36. Cryptography

37. Code prints of source/binary

38. Customer-specific/contributed

39. Addresses the “long tail” of OSS projects

40. Continuously expanded

41. Custom code printing to add your own code

42. Daily security vulnerability alerts

44. Source Code Analysis Code matching Compare Code Prints of your source code to the Black Duck KnowledgeBase Detects matches of components, files and code fragments Finds reused code even when altered Reports project / license for confirmation Language independent Dependency analysis Import/include statements Integrated string search Standard string search queries Custom strings Find licenses, copyrights, URL’s, company names, user comments (“taken from”), … Analysis results that are unachievable by a manual process

45. Binary Code Analysis File matching Compares checksum value to the KnowledgeBase Libraries, class files, executables, archives, images, and more. Dependency analysis Detect dependencies embedded in JAR, CLASS, DLL, SO, etc, … Archives and Compressed Files Descends into archive files (zip, jar, tar, war, …) Recursively performs source and binary analysis. -MD5- The Black Duck KnowledgeBase simplifies binary file identification

46. License Analytics Over 2,000 open source and other licenses With full license text Licenses organized according to 24 attributes Rights and obligations to simplify license review Display of license conflicts Automated approval process Obligation fulfillment checklist Add custom licenses Speed license reviews and make better choices, earlier in the development process

47. Remediation Code Audit may reveal issues that need remediation Remediation can be done… Pre-acquisition as a condition of the sale Post-acquisition as part of the integration Primary Concern during Due-Diligence Phase Does the remediation impact valuation? What is cost & effort? Who should do it? When is it done? How much risk is Acquirer taking? Remediation options will depend upon OSS detected (license)

48. What are the Remedies? Conform to the License Verify Compliance to License Obligations Check for File Modifications Confirm file level obligations are met Copyright statements retained Modification notices in place License Text in place Publish / distribute software if necessary Update documentation/splash screens if necessary And a host of others depending upon the license Implement Changes Typically done during Integration (post sale) Change Usage Some obligations depend upon usage scenario Re-architect so usage of component is less integrated Comply with more desirable license terms

49. What are the Remedies? - Cont. Remove Offending Code Black Duck Service can detect “Fossils” Verify code can be safely removed with no impact Typically forced on Sellers Replace Code Replace with other OSS Replace with Commercial Alternative Replace with In-house developed Code Need Clean Room Environment? Can be difficult if OSS component is critical Can be lengthy and expensive

51. > 2,000 OS components identified in target solutionsEcosystem Services and Support Optimize Performance and Balance RiskSAP BusinessObjects Implement Flexible Business Processes SAP Business SuiteSAP Solutions for SME SAP NetWeaver

52. SAP’s Experience with Evolution of Target’s Response to Open Source Due Diligence Past: Skepticism Present: Industry Standard Why is SAP performing OS diligence? Open source due diligence is expected Many questions about process / NDA heavily negotiated Few process questions / little negotiation of NDA Require code scan to be performed on site Allow remote code scan

53. SAP – M&A Due Diligence on Open Source SAP asks targets (typically prior to signing a term sheet): Provide a list of all open source in use Do you have a policy regarding open source use? Do you have a governance process to monitor & control the use of open source in your products? Following execution of a non-binding term sheet, SAP engages Black Duck to scan the target’s code for open source. Scan results are evaluated by SAP’s open source licensing and legal groups prior to finalizing transaction

54. SAP M&A Open Source Evaluation Process Evaluate and categorize risk of open source components used in target’s products High risk components must be removed prior to SAP’s shipment of product post-closing Non-high risk components are dealt with following closing as part of SAP’s standard open source governance process SAP may terminate a transaction evaluation due to the amount of open source found in the target’s code and/or the cost of remediating high risk components

56. Support offerings

57. General license grant

58. Export restrictions

59. Does the license allow for modifications?

60. What terms apply to modifications?

61. Required text for documentation

62. Copyright notices

63. Distribution pre-requisites in general

64. Product’s characteristics

65. Contribution policy