/POSSCon-Policy-Preso-3-20-11 by Matt Hudson

Open Source Policy: “Tips for Becoming a Good Open Source Citizen” POSSCON Steven Grandchamp, CEO, OpenLogic

Today’s discussion ! ! ! ! !

Do you need an open source policy?   What level of compliance with open source licenses?   Why should I be concerned?   What should I do about it?   What are the key elements of an open source policy?

About OpenLogic OpenLogic helps enterprises to successfully and safely acquire, deploy, support and control all of the free and open source software they use. !   Scanning Tools !   Open Source Audits !   Open Source Support

Thenâ&#x20AC;Ś

Now...

Open Source is Used in 88% of Android Apps & 41% of iOS Apps

Source: OpenLogic Mobile Research 9/2010 Copyright OpenLogic 2006

So… 6

More Than A Theoretical Risk: Legal Action Source: Ars Technica

Source: cnet

Source: The Inquirer

Free Software Foundation has been active in GPL enforcement. Copyright OpenLogic 2006

More Than A Theoretical Risk: Bad PR? Source: Network World

Source: Matthew Garrett http://www.codon.org.uk/~mjg59/android_tablets/

Compliance Concern

Many Apps Arenâ&#x20AC;&#x2122;t Consistently Complying with Open Source Licenses Copyright OpenLogic 2006

Takedown Requests to Android Market Feb 2011 = 206 Takedown Requests

Source: Chilling Effects Clearinghouse, Takedown Complaints for Android Market Copyright OpenLogic 2006

Research Methodology !   Scanned 635 Top Apps with OSS Deep Discovery !  123 Android Apps !  512 iOS Apps

!   Picked top paid and free apps across categories !   Identified 68 Apps with GPL, LGPL or Apache !  52 with Apache !  16 with GPL/LGPL

!   Examined those apps for compliance with key obligations

Four Areas of Compliance Analyzed

Apache

GPL/LGPL

Provide copy of license

Notices/Attributions

Provide source code

Failure to Comply

Comply 29% Do Not Comply 71%

71% of Apps using Open Source under GPL, LGPL and Apache do not comply Source: OpenLogic Mobile Research 3/2011 Copyright OpenLogic 2006

REALLY? Do I need to care? 14

Three Reasons to Comply

1.  It’s the right thing to do 2.  Protect your IP 3.  Money in your pocket Copyright OpenLogic 2006

It’s The Right Thing to Do

Free software… but please comply

Protect your IP

©©© ©©© ©©©

Copyleft open source licenses can impact licensing of your IP

Protect your IP

Open Source under â&#x20AC;&#x153;Copyleftâ&#x20AC;? license

Linking

Your code

Derivative work? Depends on the license and how you combine the code Copyright OpenLogic 2006

Money in Your Pocket

Non-compliance can result in: Takedowns Injunctions Lawsuits Legal costs

OK, OK I get it. 20

How to Become A Good Open Source Citizen 1.  2.  3.  4.  5.

Understand open source licensing Create an open source policy Track all open source usage Conduct a scan or audit of your code Develop a compliance checklist

1. Understand OSS Licensing !   Official definition of OSS license !  Approved by the Open Source Initiative (OSI) !  http://www.opensource.org/

!  Currently over 60 approved licenses !  Key Criteria ! ! ! !

Free distribution  Source code is available  Derived works are allowed  Non-discrimination

Categorizing Open Source Licenses Liberal No Strings !M   IT/X !  W3C

Strings Attached !O   riginal BSD !  Apache Software License !  Eclipse Public License

Copyleft “Traditional” Open Source !G   NU GPL !  GNU LGPL

Additional Clauses !G   NU GPL v3 !  Common Public License !  Mozilla Public License !  SISSL !  IBM Public License

Dependency Issues Impact Licensing !   OSS often depends on or bundles other OSS !   Need to look at all the dependencies and bundled projects and their licenses !  Important: The licenses may not be the same !  Important: Can be at odds with each other !  Important: Have multiple and conflicting obligations

!   Example: !  Geronimo (Apache license) uses MySQL (GPL) through the MySQL driver (formerly LGPL but now GPL)

2. Create an Open Source Policy !   Things to include !  Licenses allowed !  Approval processes !  Audit and compliance processes

!   Considerations !  Keep it lightweight !  Don’t let fear guide you

Elements of an Open Source Policy ! ! ! ! ! ! ! ! ! ! !

Strategy and Stance Sourcing – where developers should get open source Certification – what criteria (technical, legal, community) Approvals – what needs to be approved by whom Approval Criteria – which licenses, packages, usage Scanning & Compliance– what audits, when, by whom Tracking & Reporting – what needs to be tracked Support & Maintenance – what support is required Contribution Policy & Community Interactions – what’s allowed Open Source Review Board – or designated group to manage policy Technical Infrastructure – repository, approval workflow, tracking, scanners

Strategy !   Pro ? Con ? Neutral ? !   Risk – can vary by use model !  Standalone !  Bundled !  Embedded

!   High – Legal Risk, distribution, mission critical, non approved license !   Medium – Customer facing, mission critical, immature community !   Low – not Medium or High Copyright OpenLogic 2006

3. Track all Open Source Usage: Why? !   Know what you are using !   Best practices for software asset management

!   Identify opportunities for sharing or savings !   Find out what open source is being used so you can leverage expertise, support, etc. across teams

!   Legal & compliance ! ! ! !

Validate that you are complying with licenses Be able to determine impact of license changes Provide an audit trail for regulatory compliance Assess impact of lawsuit or IP infringement

!   Maintenance !   Be prepared to handle security patches or critical issues !   Able to plan for maintenance updates

!   Support !   Understand level of support necessary !   Share support resources (whether internal or external)

3. Track all Open Source Usage: What? ! ! ! ! ! ! ! ! ! ! !

What open source packages are used What versions are used The exact source/object code Where you got it from (source) What license it’s under What applications it’s used in What machines they are used on What operating system they are used with Whether the project is internal, external or for distribution When distributed and to whom Approval trail – who approved, when approved, for what purpose Copyright OpenLogic 2006

4. Conduct a scan or audit of your code !   Outcome of an OSS audit: ! ! ! !

List of open source packages  List of open source licenses  List of license obligations  List of licenses that may have conflicting terms

!   Options !  Scanning tools !  Manual review !  Audit services

Scanning & Compliance

Why Scan? !   If distributing and application !  Ensure an accurate bill of materials and bill of licenses and obligations for license compliance

!   If deploying internally !  Understand license obligations – some may apply to internal use !  Understand support and maintenance requirements for operational issues !  Ensure policy compliance

Scanning !   Why Scanning vs Self-reporting? !  Self-reporting is inaccurate because: ! ! ! ! !

Developers forget about things they included  Developers often aren t aware of bundled packages  Developers often aren t aware of additional licenses  Outsourcers are notoriously inaccurate at self-reporting  Commercial packages may include open source

!  Our Application Audit experience !  100% of our App Audits find much more than the developers reported !  In many cases we find GPL that the company was not aware of

Best Practices: “Going Forward” !   Start with any upcoming new products/releases !   Baseline current shipping version !  First scan and reconciliation will take the most time !  Delta scans can be done after that

!   Scan at multiple points in SDLC !  Scan during development !  Scan prior to ship !  Final scan of shipped code

Best Practices: “Remediation” !   Consider whether previously shipped products need to be scanned ! ! ! ! ! !

Is there a newer version that has been scanned?  Did we find OSS in later scanned versions?  How widely used is the product?  How long has it been out?  Are most people upgrading to latest versions?  What is risk we are willing to take?

!   Put in place any remediation needed for older products

About Compliance !   Scanning and reconciliation is only the first step !   You need to ensure you are in compliance !   Expect to spend some “back and forth” time between legal and development to get it right !   Usage will change obligations that are applicable !  Legal and development will need to work together

!   Be aware of your own EULAs/Contracts – they may need to change

5. Develop a compliance checklist !   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?

Special Outsourcing Considerations !   Outsourcer contracts !  Contract should require they fully disclose of all open source and licenses including bundled packages !  Contract should require your approval of open source use and licenses !  May want to require warranty/indemnification if they give you an inaccurate list (Verizon example) !  May want to specify remedies if they screw up and you need to make changes or remove open source !  May want to recommend or require scanning of code !  They do it !  You do it !  They pick or you specify third party service Copyright OpenLogic 2006

Special Outsourcing Considerations !   Outsourcer processes !  Discuss open source with them early in the project !  Plan to get list of open source (through scanning or selfreporting) early in development cycle !  Get a final list when they provide final code !  Either scan all incoming code that you plan to distribute or consider spot audits

Thanks! !   Slides? !  www.openlogic.com/downloads !  www.slideshare.net

!   Learn more !  www.openlogic.com

!   To receive more details !  steven.grandchamp@openlogic.com

!   Follow !  @openlogic