Licensing OSS it’s not as hard as you think Brian Lally Assistant Chief Counsel Intellectual Property Law Division U.S. Dept. of Energy 9800 S. Cass Ave. Argonne, IL 60439 brian.lally@ch.doe.gov Tel: (630) 252-2042 Fax: (630) 252-2779 This presentation is intended for general information purposes only and does not constitute legal advice. The presentation should not be used or relied upon as a substitute for independent legal advice.

What is Open Source Software (OSS)? Open source = a licensing approach Open source = License Community the license defines the community and how it will interact different licenses create different communities

Open Source Software Definition More than just access to the source code OSS is software licensed under an agreement that conforms to the Open Source Definition*: Freedom to Redistribute Access to Source Code Freedom to Modify-Derivative Works No Discrimination against persons or groups or fields of endeavor Integrity of Author’s source code Redistribution accordance with the Open Source Licensing Agreement License must not be specific to a product, must restrict other software and must be technology neutral *see, open source initiative (opensource.org)

Open Source Licensing choosing the right license matters Protect yourself and your organization Most OSS licenses release the authors from any responsibility. Choose a license that protects you from liability. If joining an existing community -understand the licenses within the OSS community that you are contributing to -adopt a license that is compatible with the predominant license the community If you are building a new community -the type of license you chose will help determine how your community develops -Do you want to encourage participation by commercially entities? Do you want to ensure that the source code always remains open? Pick the right license for the community you want to develop. Consider dual licensing Consider a GPL compatible license Pragmatism v. Ideology When in doubt contact your IP Counsel!

OSS Licensing Families permissive (commercially friendly) Restrictive (copyleft) Academic Licenses Permissive Licenses Weakly Protective Licenses Protective Licenses “freedom” to users of the code “freedom” to users of the code with more robust terms Divides code but ensures that original code remains “free” ensures code stays “free” Commercially friendly Limited Commercial Use Limits commercial adoption Examples: Berkeley (BSD) (new/modified) MIT/X11 Apache (AL) Mozilla (MPL) Eclipse (EPL) Common Public License (CPL) LGPL GPL

Academic and Permissive Licenses You can use, modify, and redistribute the code in your product, but you must give attribution to the original author. derivatives can relicense gives most of the control to the user allows for commercial development (closed source) permissive license similar to academic with more robust terms and conditions (patent, TM, contribution provisions) MIT/X11 New/Modified BSD Apache 2.0

Weakly Protective Licenses partially closed licenses Derivative or File based distinctions divides code into pieces allows linking (use of library) to proprietary program the source code of the original library (and any modifications) must be redistributed freely however, the application itself can remain closed commonly used for libraries and platforms Mozilla (MPL) 1.1 LGPL 2.1 LGPL 2.1 + LGPL 3.0 and 3.0+

Strongly Protective Licenses reciprocal licenses (viral licenses) Derivative works remain under the original license. Copyleft. ensures the code will remain open no artificial separation of code derivative works remain under the license copyright holder retains much control limits commercial development GPL 2.0 GPL 2.0 + GPL 3.0 and 3.0+

You can’t just mix and match OSS licenses They must be compatible* * When in doubt consult with your IP counsel

OSS License Compatibility permissive (commercially friendly) Restrictive (copyleft) Mozilla (MPL) 1.1 GPL 2.0 Public Domain LGPL 2.1 GPL 2.0 + MIT/X11 LGPL 2.1 + New/Modified BSD Apache 2.0 LGPL 3.0 and 3.0+ GPL 3.0 and 3.0+ Only compatible with GPL 3.0 and 3.0+

DOE OSS Approach An evolutionary approach: DOE policies on OSS have evolved over time DOE is reducing barriers to accessing OSS at our Labs DOE policies are aimed at granting flexibility to our Lab contractors. Lawyers should not be mandating how software is distributed Allow Labs to select appropriate licenses. Address misperceptions about working with DOE and our Labs Be prepared to adapt to a changing scene

Software Licensing at DOE Labs . . . an evolution Rigid Flexible Pre-2002 2002-2003 2003-2010 2010-present Required Approvals* DOE Program and DOE Patent Counsel DOE Program No affirmative approval necessary* Blanket Program Approvals Not contemplated Allowed Available licenses traditional DOE copyright license terms Industry standard OSS licenses Custom OSS Licenses that meet DOE minimum requirements * but must provide DOE program two weeks notice to object.

DOE M&O OSS Contract Req. CLAUSE I.112 - DEAR 970.5227-2  RIGHTS IN DATA-TECHNOLOGY TRANSFER, subparagraph (f) Lab report software and decides whether OSS is desired Obtain Program Approval Form DOE F 241.4 to ESTSC Select an OSS License Lab must maintain an OSS Log and provide Public Access to the OSS Periodic Export Control Reviews Technology transfer mission clause of the M&O Contracts is not applicable (e.g., product liability indemnification, U.S. competitiveness, U.S. preference clauses are not required)

Laboratory created OSS Labs have flexibility to choose standard OSS Licenses (or create custom licenses that meet min req) Lab should provide public access to OSS and may monitor to determine effective dissemination DOE prefers Labs to allow liberal distribution without much restriction on redistribution of derivative works. Lab may request/accept voluntary contributions to Laboratory distributed OSS. Labs should use reasonable efforts to: Ensure 3rd party has legal right to make submissions Log/track submittals that add significant code/functionality Check for viruses Lab should inform DOE of any 3rd party infringement claim Dual licensing: Labs may license both commercial and non-commercial versions however: Lab needs DOE approval to commercially license software.

Program Approvals DOE Program Approvals: ASCR/ASCI – Blanket Approval for all software developed under OASCR/ASCI program funding to be licensed as OSS All other DOE Programs (funding 50% or more of software development) “opportunity to object” with two (2) weeks prior notice of licensing as OSS Exceptions: specific export controls prohibitions (e.g., encryption), 3rd party proprietary code, classified code, DOE program overrides (e.g., HPSS), DOE objection within 2 weeks of notification, special contract terms DHS funding – “programmatic “approval” needed on individual basis (even if only partially funded by DHS) for licensing as OSS at this point DoD funding – No additional programmatic approval for licensing as OSS NIH funding – No additional programmatic approval for licensing as OSS NSF funding – No additional programmatic approval for licensing as OSS

3rd Party OSS at DOE Labs Creating Derivative works of 3rd party OSS: Labs may assert copyright as OSS derivative works without notice to DOE program or approval from DOE patent counsel . (also no requirement to deposit in ESTSC) Copyright transfer to 3rd party: some licenses transfer copyright to 3rd party licensor. If Lab contribution < 25% of total OSS code, than transfer is permitted. (no notice or deposit requirement). If greater than 25% DOE patent counsel must be consulted. When a lab creates a derivate work, a 3rd party OSS license may control and Lab counsel should be consulted. Be careful of pass-through of legal terms (warranties etc.) If Lab wishes to commercially license a software package that combines 3rd party OSS then the Lab is required to obtain approval from both DOE program and DOE patent counsel. DOE encourage Labs to use OSS when appropriate however: -Lab counsel should be consulted to ensure that 3rd party license terms don’t contain terms contrary to DOE policy. (Lab issued guidance)

Where can I find DOE funded OSS? SciDAC.gov SciDAC funded software list https://outreach.scidac.gov/scidacoverview/init/default/scidac_current?mode=all DOE Office of Science and Technical Information (osti.gov) Energy Science and Technology Software Center (ESTSC) http://www.osti.gov/estsc/ Sample DOE Lab Software Sites Argonne National Laboratory http://www.anl.gov/techtransfer/Software_Shop/OpenSourceSoftware.html Lawrence Berkeley National Laboratory http://www.lbl.gov/tt/techs/oss.html Los Alamos National Laboratory https://computing.llnl.gov/?set=resources&page=os_projects Sandia National Laboratories https://software.sandia.gov/ Sample Direct OSS Sites Globus Toolkit http://www.globus.org/toolkit/ Chombo https://seesar.lbl.gov/anag/chombo/

SciDAC Software website https://outreach.scidac.gov/scidac-overview/init/default/scidac_current?mode=all

Example of licensing DOE sponsored OSS Software

Violating OSS License Terms real world consequences Jacobsen v. Katzer (U.S. Court of Appeals) -- 2008 An OSS License terms were “conditions” not just “covenants” Not merely breach of contract Copyright Infringement – generally available: Injunctions Statutory Damages ($750 to $30,000 per infringement, up to $150,000 per violation if the copyright owner can prove willful infringement.   Attorneys fees Oracle v. Google (U.S. District Court, Northern District Calif.) filed August 12, 2010 Android (released under an Apache OSS licensed) allegedly infringed 7 patents and one copyright (Java, released under GPL) owned by Oracle (which bought Sun Microsystems earlier 2010). Oracle requesting: Destroy copies, treble damages, attorneys’ fees

Questions? Contact Information: Brian Lally Assistant Chief Counsel Intellectual Property Law Division U.S. Dept. of Energy-Chicago Office 9800 S. Cass Ave. Argonne, IL 60439 brian.lally@ch.doe.gov Tel: (630) 252-2042 Fax: (630) 252-2779

Open Source v. Proprietary Software Licensor distributes source code Licensor distributes object code only License flows with the code unilateral permission No negotiation No affirmative assent “arms length transaction” -meeting of the minds -sometime negotiated -affirmative assent (click, sign etc.) Modifications are allowed Modifications are generally prohibited Permissive Use -source and object code -may copy, modify and distribute -may allow others to do the same Use Restrictions -object code only -limited copying -no reverse engineering -no distribution licensee may do its own development and support and may hire a third party to do it upgrades, support and development is done by the licensor Licensor Obligations -No warranties -No updates/upgrades -No support obligations -no indemnification Licensor Obligations: Warranties Updates Maintenance/Support Indemnification