nexb- Software Audit for Acquisition Due Diligence

Transcription

1 nexb- Software Audit for Acquisition Due Diligence

2 Agenda About nexb What nexb does Our experience Software Audit: M&A License Violation Risks & Recent Audit Issues Software Audit Process Software Audit Tools Additional Information Why nexb? Contact us Lessons Learned

3 About nexb What nexb does Enable component-based software development Software provenance analysis services Software asset management tools Expertise in all software IP Software audit services Acquisitions Software product releases Active OSS developers

4 About nexb Our experience is our difference Recognized by the buyers and target companies as: experts in software origin analysis a fair and trusted intermediary We identifies issues along with practical remediation steps 350+ software audit projects completed to-date

5 License Violation Risks Free Software Binary-only (Proprietary) source code available Adobe Reader Freeware / Shareware many Java libraries source with limitations (Proprietary) FOSS Microsoft shared source Sun SCSL Copyleft Attribution GNU GPL GNU LGPL MPL CDDL EPL BSD Apache MIT

6 Recent Audit Issue Examples Dependency Issue Workarounds License violation

7 Emerging Audit Issue Examples Cloud computing and Dual Licensing Personal Devices and Application store markets

8 Software Audit Process

9 Software Analysis Scope Commercial Code Original Code Open Source Code

10 Software Analysis Deliverables Complete inventory of OSS and third-party components in Development codebase(s) Bill of materials for Deployed product components Specific Action items and recommended actions for resolution that can be factored into the deal terms Including possible exposure for older product versions Detailed analysis for copyleft contamination Checklist of commercial components as input to due diligence for contract review Analysis of how much code is original versus borrowed (OSS) or purchased (Commercial)

11 Preparation 1 week (1/2) Establish NDA with seller Two-way or three-way Scope audit effort Audit profile (questionnaire) Size of code base - # files and lines of source code Disclosure of known third-party and open source software Onsite or remote access to the code Prepare/agree quote always fixed fee, no surprises Schedule project

12 Preparation (2/2) è Many targets are anxious about the process General level of anxiety is inversely proportional to prior M&A experience of executives We do some hand holding to make them feel comfortable Assure seller that they review all findings first so no surprises Explain the process and tools to the seller

13 License & Origin Analysis 2 weeks (1/2) Analysis Activities Scan files for license, copyright and other origin clues Match target code to reference code repository for origin and license detection (based on digital fingerprints ) Map Deployed code to Development code to: Validate that we have a complete Development codebase Filter issues based on the effective Deployed/Distributed code Analyze software interaction and dependency patterns for copyleftlicensed components as needed Additional domain-specific investigations typically for embedded devices and applications of media codecs

14 License & Origin Analysis (2/2) Results Software Inventory and Bill(s) of Materials Draft Action items & recommendations

15 Review & Report 1 week (1/2) Activities Draft findings review with product team Ask product team to respond to each Action item Accept recommended solution or propose another approach Acknowledge & investigate Not a request to fix anything during the audit Incorporate feedback and answers from product team into the Software BOM and Report We may agree to disagree e.g. we then present two points of view: ours and the seller s. Complete final report Second review cycle with product team Release the report Conference call with buyer to present findings & answer questions

16 Review & Report (2/2) Results Final Software Inventory / BOM spreadsheets Final Report - narrative with executive summary, project data and summary of the Action items and Responses

17 Software Audit Tools nexb typically uses a combination of tools for a software audit Our own DejaCode toolkit is the primary tool Other tools used as needed or as licensed by a customer (open source or commercial) Multiple layers of analysis Direct scan for license and copyright notices Component matching for open source and publicly available thirdparty components (freeware/proprietary) Analysis of source code and pre-built libraries (binary) Interaction and dependency analysis as needed Review and validation by software experts All require expert humans to interpret the results!

18 Additional Information Why nexb (1/2) 100% of our customers are repeat customers and references We have a balanced approach Automated code analysis AND analysis by software experts Direct consultation with engineering, management and legal teams Concrete Action items with recommended nexb action resolution and seller Responses

19 Additional Information Why nexb (2/2) Trusted third party Mitigates confidentiality concerns of a seller company Maintains proper segregation of information during acquisition negotiations Enables objective analysis with appropriate consideration of feedback from all parties

20 Additional Information Contact us Contact person: Pierre Lapointe, Customer Care Manager More information:

21 Additional Information Lessons Learned Acquisitions (1/2) Schedule is always a major issue Initiate a software audit early because Seller company will probably not have done this before Negotiation of an NDA takes longer than you expect Negotiation of access to artifacts and people takes longer than you think The review of findings and recommendations may require several iterations with target company Get answers for open issues Get agreement about remediation strategies Get agreement that report is objective and reasonable

22 Additional Information Lessons Learned Acquisitions (2/2) Identify the crown jewels and key platforms of the seller technology Concentrate the audit on the most important parts For products with multiple operating system versions, focus on the most important platforms Some issues can be specific to the open source policies of the Buyer For instance tolerance for certain version of open source licenses or proprietary Linux drivers varies among companies We apply Buyer company policies if available, Otherwise we apply conservative community standards Exceptional cases may require additional discussion with legal and and business teams to evaluate the risks