Page 1

The Ins and Outs of Open Source Audits Dave McLoughlin

About OpenLogic !   Help enterprises successfully and safely use open source software !   Services ! ! ! !

 Open Source Policy Workshops  Open Source Audits  Open Source License Obligation Analysis  Open Source Fulfillment Center

!   Products !  Scanning Tools !  Open Source Governance

!   Open Source Technical Support

What is an OSS audit? !   What OSS do you have and under what licenses? !   Outcome of an OSS audit: !  Bill of Materials of what open source packages or pieces of packages are present in your code !  Bill of Materials of what licenses are associated with those packages !  Complete list of license requirements for compliance !  Specific list of requirements will depend on usage

!  List of licenses that may have conflicting terms

Why do I need an audit? !   You need to care what open source you have because: ! ! ! ! ! !

 You need to support and maintain it  You need to comply with your policies  You need to comply with licenses  Litigation risk is real  Remedies under © law and contract law  It may be required by other parties

When do I need an audit? !   Commercial products !  Any product that includes OSS needs to be in compliance

!   M&A deals

!  Buyer: Becoming more common to ask for list of OSS used; recourse is still limited, so diligence is key !  Target: If company might be acquired in future, want to be proactive

!   Financing !  May include or require an open source warranty and disclosure

!   OEM/Distribution deals !  Open source warranties becoming standard


Open source use realities !   Most developers ARE using open source – whether they know it or not !  OSS is downloaded – not just from open source projects (e.g. blogs) !  OSS is in third party commercial software !  OSS bundles other open source !  OSS use changes over time…

“Adoption of open-source software (OSS) is becoming pervasive, with 85 percent of companies surveyed currently using OSS in their enterprises and the remaining 15 percent expecting to in the next 12 months” Source: Gartner, Inc.


Open source use realities: use changes •  Revisions made to OSS •  Linked to or bundled with proprietary code

Use by wholly owned sub

Use by an outsourcer or contractor

Software distributed to end users

Internal Use Software shared with “partner” during further development

Use of OSS under GPL

Using OSS

Sub is sold to a 3rd party

Distributing OSS

Distributing OSS often triggers additional clauses in open source software licenses and therefore requires careful attention

Audit Options !   Self-reporting !  Asking developers or providers what OSS is included

!   Manual !  Inspecting files and code to determine what OSS is included

!   Scanning !  Using scanning technology to identify OSS and licenses !  Still need human eyes to investigate best matches and research code

!   Audit Services !  Engage company to perform audits (using scanning tools)

How scanning works ! ! ! ! ! ! ! !

  Name matching   Path matching   Namespace matching   File hash code matching   Source block hash matching   Source essence matching   Code term matching   License matching


Scanning Tool Considerations !   Scanning techniques !  What techniques does it use? Does it look for licenses, files, code snippets, modified code?

!   Noise issues !  How does the tool avoid or reduce false positives and redundant matches?

!   Size of the “fingerprint repository” !  How many projects can it match against?

!   Technical requirements !  What technical requirement are needed to run the scanner?

Scanning Services Considerations !   Onsite or offsite? !   Do you want the auditor to come onsite or will you provide code to them offsite? !  If onsite, what are the technical requirements? !  If providing code, what are the security procedures?

!   Who gets the results? !   If a M&A deal, who is commissioning the audit and who gets the results?

!   What tools are used? !   Multiple tools and methods?

!   What, if any, warranty or indemnification is provided for the results? !   What is the timeframe? !   Who is responsible for answering questions on your side?

Audit issues !   Code that doesn’t have an obvious license included !   Licenses that don’t seem to belong to any particular code !   License included is different from the one identified on the project website !   Dual or disjunctive licensing situations !   Code that has only a © notice and “all rights reserved” with no license text !   Comments in code that have additional terms (not in license) !   Multiple packages, multiple licenses, multiple dependencies !   OSS packages often have more than one license embedded inside !   OSS packages often bundle many other packages with DIFFERENT licenses

Multiple Packages, Multiple Licenses When a developer downloads and installs those projects they also get additional open source components that are installed automatically (over 90 additional!!) Ant (7 bundled)

AspectJ (19)

Spring Framework (61)

- Apache xml-apis (1.5) - Xerces (2.6.2) - BCEL (5.1)

- Ant (1.6.3) - Apache Avalon (4.1.2) - ASM (2.0)

- ActiveMQ (1.1) - Ant (1.6.5) - ANTLR (2.7.5H3)

- Commons Validator (1.1.4) - dom4j (1.6) - EasyMock (1.1)

- JAX-RPC (1.1) - Jaxen (1.1-beta4) - JDBC (2_0)

- BeanShell (1.3.0) - BSF (2.3.0)

- ASM (2.2.1) - Batik (unknown)

- AOP Alliance (1.0) - Apache (OJB) (1.0.4)

- Ehcache (1.1) - Enterprise Java Beans (2.0)

- JDO (2.0) - JMX (1.0)

- JUnit (3.8.1) - JDK (1.4.2_12)

- BCEL (5.1) - Commons BeanUtils (unknown) - Commons Digester (unknown)

- Apache xml-apis (1.2.01) - c3p0 ( - cglib (2.1.3)

- Free Marker (2.3.4) - Hessian (3.0.1) - Hibernate (2.1.7)

- JOTM (2.0.9) - JTA (1.0.1B) - JUnit (3.8.1)

MySQL Connector (9)

- Commons Logging (unknown) - DocBook XML (4.1.2)

- com.oreilly.servlet (1.0) - Commons Attributes (2.1)

- Hibernate (3.0.5) - HSQLDB (1.8.0)

- jxl (2.6) - Log4j (1.2.13)

- Ant-Contrib (1.0-b2) - AspectJ (1.2)

- DocBook XSL Stylesheets (1.44) - FOP (0.20.5) - JDiff (unknown) - JUnit (3.8.1) - Jython (2.1)

- Commons BeanUtils (1.6) - Commons Codec (1.3) - Commons Collections (3.1) - Commons DBCP (1.2.1) - Commons Digester (1.6)

- iBATIS (2.1.7) - iText (1.3) - J2EE Connector Arch (1.0) - Jakarta JSTL (1.0.3) - Jamon (1.0)

- ORO (2.0.8) - POI (2.5.1) - Quartz (1.5.2) - Rowset (1.0.1) - Struts (1.2.8)

- Regexp (1.2) - Saxon (unknown) - Xalan (2.4.1)

- Commons Discovery (0.2) - Commons Fileupload (1.0) - Commons HttpClient (3.0)

- Jasper Reports (1.0.3) - Java Servlet API (2.4) - JavaBeans (JAF) (1.0.1)

- Tag Libs (1.0.6) - TOPLink (1.0) - Velocity (1.4)

- JDK (1.4.2_12)

- Commons Lang (2.1) - Commons Logging (1.0.4) - Commons Pool (1.2)

- JavaMail (1.3) - JavaServer Faces (1.1)

- Velocity Tools (1.1) - XDoclet (1.1)

- c3p0 (0.9.1-pre6) - Commons Logging (1.0.4) - JBoss Application Server (3.2.7) - JDBC (2_0) - JTA (1.0.1) - JUnit (3.8.1) - Log4j (1.2.9)

Multiple Packages, Multiple Licenses List of Unique Licenses found for these packages Antlr Software License Apache 1.1 Software License Apache 2.0 Software License BSD License com.oreilly.servlet license Common Public License dom4j Software License Eclipse Public License GNU General Public License HSQLB software License J2EE Connector Arch Specification License !   JAMon License Agreement ! ! ! ! ! ! ! ! ! ! !


JavaMail Software License Jaxen Software License JTA Specification License LGPL MIT License MPL andLGPL Dual Public Domain License Sun Community Source License Sun Microsystems, Inc. Binary Code License agreement for the JDK 5.0 !   Sun Microsystems, Inc. Entitlement for Software !   Xdoclet Software License ! ! ! ! ! ! ! ! !


The Audit Report !   Elements of your audit report: !  Bill of Materials of what open source packages are present in your code !  Bill of Materials of what licenses are associated with those packages !  Complete list of license requirements for compliance !  Specific list of requirements will depend on usage

!  List of licenses that may have conflicting terms

!   An audit provides the facts, not the legal analysis

Limitations of an audit Legal analysis will include: !   Usage !   Audit may list ALL license requirements and it will then be up to you to determine which are actually triggered depending on your use

!   Compliance !   What does compliance mean? !   How do you comply with the many terms and conditions of multiple licenses?

!   Incompatibility !   Licenses can be at odds with each other, need to know if there are conflicting obligations

!   Risk !   Ultimately you want to be compliant and protect yourself from possible non-compliance actions or infringement suits


License Analysis !   Many (most) OSS licenses were not written by attorneys !   No judicial opinions involving interpretation !  But there is information from the open source community

!   Can you break license requirements into an IF – THEN statement? !  WHAT is the requirement? !  HOW does it need to be met?

Who should participate in an audit? !   Engineering team !  There will be technical questions that need to be answered and explained in order to determine the license requirements !  i.e. how different components are linked, what is used in the build environment v. distributed, etc.

!   Lawyers !  Audit is the facts, not the legal analysis

!   Executive management !  What level of risk is your company/client comfortable with?

After the Audit: How to ensure compliance? !   Create a compliance checklist: !  Notices in code and/or documentation !  Source code provided in proper way !  Is there an EULA for your product?

!   If there are conflicts or compliance is not possible: !  Can you live without this code? !  Is there an alternative to the code? !  Can you contact the author and ask for an exception/different license?

!   Risk management: !  What is likely to get litigated? !  What are your sticking points that prevent perfect compliance?

Best Practices: Being prepared for an audit !   Before the audit: !   Get together ALL the relevant code for your software !   Exclude “build artifacts” that are not shipped or distributed !   Get a list of OSS the developers believe they are using

!   During the audit: !   Gather usage info to determine what obligations apply !   Communicate; have a cross-functional team involved !   Be explicit; Track everything!

!   After the audit: !   Ensure and document compliance with all relevant obligations !   Determine fulfillment options (to provide source code) !   Include all necessary licenses and source code to customers

Best Practices: Compliance going forward !   Build knowledge of OSS issues in your organization !   Have an OSS policy in place !   Track what OSS packages & versions are used, where they are used and how !   Keep the exact source and object code for all OSS !   Track licenses, keep copies of licenses matched to the version number !   Track modifications made to OSS !   Have an approval process and maintain an approval trail !   Define who is responsible for this process !   Document your compliance!


Questions? Dave McLoughlin

Copyright Š 2010 OpenLogic, Inc. This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 United States License.

To view a copy of this license, visit licenses/by-sa/3.0/us/