A Practical Approach to Open Source License Compliance

A Practical Approach to Open Source License Compliance Webinar on Feb 23, 2011 Presented by Jilayne Lovejoy, OpenLogic Corporate Counseland Eric Weidner, OpenLogic Co-Founder and Sr. Development Mgr.

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

Practical Approach to Open Source LicenseCompliance Once you know what you have, now what? 1.  Getting familiar with the open source license implicated by the OSS you are using 2.  How are you using the OSS? a.  What license requirements are triggered? 3.  Creating your compliance checklist 4.  Checking off the list a.  What does compliance mean? b.  Practical engineering tips for now and going forward

Why Do I Need to Comply? •  You comply with every other license or contract you enter into – OSS licenses are no different •  Because you could get sued •  Software Freedom Law Center (SFLC) has filed suits – most recent case (Dec 2009) named 14 defendants all of whom were not providing source code for GPL licensed BusyBox package •  All suits SFLC has filed have settled •  Jacobsen v. Katzer – established that OSS licenses are indeed licenses, not contracts  © remedies !   Because it’s the right thing to do!

Who Should Participate in Compliance? !   Engineering team !  First line of defense – catch it early; make compliance easy !  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. !   Legal department !  Legal analysis and license interpretation where there is no precedent !   Executive management !  What level of risk is your company comfortable with?

Getting Familiar With the Licenses !   Many (most) OSS licenses were not written by attorneys !  Look for FAQ or other additional guidance from the license author’s on what was intended !   Disjunctive licensing scenarios – choose one !   Can you break license requirements into an IF (used in this way) – THEN (you must do X) statement? !  HOW does the requirement need to be met? !   Does the license include restrictions or prohibitions?

How Are You Using the Software? !   Is it distributed? !  In source or object form? !  Ruby License: 1. You may make and give away verbatim copies of the source form of the software without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers. !   Is it modified? !   CeCILL Free Software License 2: 5.2 ENTITLEMENT TO MAKE CONTRIBUTIONS The right to make Contributions includes the right to translate, adapt, arrange, or make any or all modifications to the Software, . . . The Licensee is authorized to make any or all Contributions to the Software provided that it includes an explicit notice that it is the author of said Contribution and indicates the date of the creation thereof.

How Are You Using the Software?Have you created a derivative work? !   The derivative works issue !  GPL v2: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: . . . b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. !   If you create a derivative work, you must release it under GPL v2, but what is a derivative work?

How Are You Using the Software?Have you created a derivative work? !   Right to prepare derivative works is one of six delineated rights under Copyright Act. 17 U.S.C. § 106 !   [A] work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, . . . or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a derivative work. 17 U.S.C. § 101 !   In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, method of operation . . . regardless of the form in which it is described, explained, illustrated, or embodied in such work. 17 U.S.C. § 102(b)

How Are You Using the Software?Have you created a derivative work? !   GPL v2 authors and community view considers these scenarios to create a derivative work !  Static or dynamic linking !  Plug-ins that make function calls and share data structures (except operating system libraries) !  Modules included in same executable file !  Modules designed to run linked together in a shared address space !   Would a court agree? Does it matter? !   Tip: Think in terms of the spirit of the license, not the actual words and the intimacy of the integration

How Are You Using the Software?Have you created a derivative work? !   Definitions of linking open to interpretation !  Classic C linking at compile time – static, dynamic !  What about Java runtime classpath loading, Ruby execution loading? !   FSF FAQ’s suggest no derivative work if: !  Unix style output chaining (Pipes) !  Servers listening for connection (Sockets, Remote Procedure Calls) !  Independent execution (Command Line Arguments)

How Are You Using the Software?License-specific use scenarios !   Other specific usage questions particular to a license !  OpenSSL/SSLeay License: 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)" !  CDDL: 3.4. Application of Additional Terms. . . . You may choose to offer, and to charge a fee for, warranty, support, indemnity or liability obligations to one or more recipients of Covered Software. However, you may do so only on Your own behalf, and not on behalf of the Initial Developer or any Contributor. You must make it absolutely clear that any such warranty, support, indemnity or liability obligation is offered by You alone, . . .

Create a Checklist of License Requirements !   Create a list of ALL the requirements for ALL the licenses implicated in your BOM !   Include passive and active requirements !  Active – there is something you have to do now to comply !  Passive – you need to know about this, but no action need be taken, e.g. restrictions, prohibitions, termination clauses !  Apache 1.1: 4. The names "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org.

Checking Off the List: General Tips for Compliance !   Tip: Create a central place in the codebase to hold ALL 3rd party information !  Dedicate a folder to each package to contain all relevant information !   Tip: Clearly document all instances where any 3rd party code was copied into other areas of the codebase both in a central location and at the point of insertion. !  Be very explicit on what is yours and what is not. !   Tip: Create a place in your product interface to display 3rd party information !   Many license requirements have actual engineering value

Checking Off the List: Notices and Licenses !   Example: Include/retain notices and a copy of the license !   BSD: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. !   Example: Notice of modified files !   Apache 2.0: 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: . . . 2. You must cause any modified files to carry prominent notices stating that You changed the files;

Checking Off the List: Notices and Licenses !   Tip: Organize all your licenses into one document or file with the package name they apply to at the heading !   Tip: Put a notice of modification in each file, as well as any text file associated with the package !   Tip: Also include notice of modification in your licenses and attribution notice documentation !  Pay attention to the details of what your notice should include; is it enough to say the file was modified or do you also need a date of modification?

Checking Off the List: Provide Source Code !   Example: Make source code available !   GPL v2: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or •  Note: a link will not satisfy this requirement for GPL v2

Checking Off the List: Provide Source Code !   Tip: Keep copy of all source code that is distributed or used at runtime with your codebase. !  You never know when you will need it. !  The source for your version may be difficult to find in the future. !  It is easiest to comply with the license dictated timelines if you just keep it all together and offer it with your distribution. !  Make sure that written offers will actually be answered and filled.

Checking Off the List: Interfaces !   Example: User interfaces and notices !  GPL v3: !  ... If the work has interactive user interfaces, each must display Appropriate Legal Notices; ... !  ... however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. ... !  GPL v2: !  ... If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement ... !  ... (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)...

Checking Off the List: Interfaces !   Other license that uses different interface terminology: !  Reciprocal Public License v1.5: !  6.4 Required Notices . . . d. User-Visible Attribution. You must duplicate any notice contained in EXHIBIT B (the "User-Visible Attribution Notice") in each user-visible display of the Licensed Software and Your Extensions which delineates copyright, ownership, or similar attribution information. If You create an Extension, You may add Your name as a Contributor, and add Your attribution notice, as an equally visible and functional element of any User-Visible Attribution Notice content. To ensure proper attribution, You must also include such User-Visible Attribution Notice in at least one location in the Software documentation where a user would be likely to look for such notice.

Checking Off the List: Interfaces !   Interface, Interactive Interface, GUI, UI, user-visible display, “normally shows notices during execution” !  How do we reconcile all these different technical meanings !   Tip: Set a standard notification mechanism for your products !  Look at your licenses and determine a minimum bar that meets the applicable licenses’ definition of interface and provide a mechanism to list 3rd party required notices. !   Tip: Set a standard notice for each license type !  Create a template for your developers to follow to reduce mistakes and allow for consistent documentation.

Checking Off the List: Installation Instructions !   Example: Installation instructions !   GPL v3: If you convey an object code work under this section in, or with, or specifically for use in, a User Product, . . . the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). !   Tip: Keep a maintainable, independent, automated build environment available with information on installation for compliance and future reference !   If the build and install instructions are kept in code, they are useful for development, future maintenance, and compliance !   Special build processes or dependencies creates an environment that is difficult to maintain or explain

Checking Off the List: No Further Restrictions !   Example: No further restrictions !  Reciprocal Public License v1.5: 6.0 Your Obligations And Grants. . . . You agree not to offer or impose any terms on any Source Code or executable version of the Licensed Software, or its Extensions that alter or restrict the applicable version of this License or the recipients rights hereunder. !   Tip: If you distribute the software under your own license, you may need to draft a carve-out or exception for conflicting terms with OSS licenses !  Examples of common restrictions: number of copies, kinds of use, no reverse engineering

What If I Can’t Comply? !  If there are conflicts or compliance is not possible: !  Can you live without this code? !  Can you create a work around? !  Is there a newer (or older) version of this code under a different license? !  Is there an alternative project with same function under a different license? !  Can you contact the author and ask for an exception/ different license?

What Are the Risks of Non-Compliance? !  What is likely to get litigated? !  Who are the players? !  Who owns the copyright to the code? !  Is it registered? !  How much risk are you willing to take?

Compliance Going Forward – Making it Easy !   Tip: Have an open source policy !   Tip: Create a pre-approved list with expected compliance steps to streamline approvals. !   Licenses or projects that are pre-approved !   Tip: Train developers to understand issues related to 3rd party software and compliance. !  Example: OSS projects use other OSS projects (and Licenses) too. You may need to consider more than the declared license for the main project you are using. !   Tip: Development moves rapidly. Create a process that can approve OSS for use quickly. !   Today’s agile environments can’t wait weeks to move forward.

Compliance Going Forward – Making it Easy Tip: Classify licenses (3 or 4 levels) and set guidelines for usage before it gets in your code. Example: !   Restricted Licenses !   Guideline: Use only as an independent application to process data. !   Guideline: Avoid running GPL code in same memory space as your code. !   Guideline: No snippet copying. !   Somewhat Restricted Licenses !   Guideline: Use only as part of a plugin or library architecture. !   Guideline: Utilize LGPL code only in a dynamic loading situation where the library is easily replaced. !   Unrestricted Licenses !   Guideline: Retain all attribution and copyright notices and clearly mark places used. !   Special Cases !   Some licenses bring special compliance requirements. Get approval before using.

Compliance Going Forward –Working Together Legal: Engineering: !   Have an OSS policy! !   Engineering is the primary and most important line of compliance! !   Education and collaboration !   Introduce the compliance process as a !   Track licenses, keep copies of primary job requirement. licenses matched to the package !   Track what OSS packages & versions version number are used, where, and how !   Have an approval process and !   Keep the exact source and object code maintain an approval trail for all OSS !   Define who is responsible for this !   Define usage criteria in levels to handle process how to introduce different types of licenses !   Document your compliance! !   Track modifications made to OSS and provide detailed build and installation instructions with the codebase 29

Q&A !   Email !  jilayne.lovejoy@openlogic.com !  eric.weidner@openlogic.com !   Twitter !  @OpenLogic !   Facebook !  http://on.fb.me/cKmVzK Copyright © 2011 OpenLogic, Inc. !   Web This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 United States License. !  www.openlogic.com To view a copy of this license, visit http://creativecommons.org/ !  olex.openlogic.com licenses/by-sa/3.0/us/

A Practical Approach to Open Source License Compliance

by OpenLogic on Apr 05, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

A Practical Approach to Open Source License Compliance — Presentation Transcript