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
5
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.
6
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
9
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 (0.9.0.4) - 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
20
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!
25
Questions? Dave McLoughlin dave.mcloughlin@openlogic.com
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 http://creativecommons.org/ licenses/by-sa/3.0/us/