1. 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
Tel: (630)
Fax: (630)
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.

2. 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

3. 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)

4. 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!

5. 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

6. 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

7. 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+

8. 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+

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

10. 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+

11. 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

12. Software Licensing at DOE Labs . . . an evolution
Rigid
Flexible
Pre-2002
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.

13. DOE M&O OSS Contract Req.
CLAUSE I DEAR   RIGHTS IN DATA-TECHNOLOGY TRANSFER, subparagraph (f)
Lab report software and decides whether OSS is desired
Obtain Program Approval
Form DOE F 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)

14. 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.

15. 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

16. 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)

17. Where can I find DOE funded OSS?
SciDAC.gov
SciDAC funded software list
DOE Office of Science and Technical Information (osti.gov)
Energy Science and Technology Software Center (ESTSC)
Sample DOE Lab Software Sites
Argonne National Laboratory
Lawrence Berkeley National Laboratory
Los Alamos National Laboratory
Sandia National Laboratories
Sample Direct OSS Sites
Globus Toolkit
Chombo

18. SciDAC Software website

19. Example of licensing DOE sponsored OSS Software

20. Violating OSS License Terms real world consequences
Jacobsen v. Katzer (U.S. Court of Appeals)
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

21. 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
Tel: (630)
Fax: (630)

22. 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