Andrew Hall, The Hall Law Firm: Open Source Licensing Fundamentals for Financial Services.
Andrew and Lena will address fundamental concepts of open-source licensing to assist executives in better understanding the benefits, obligations, restrictions, and risks involved in leveraging and contributing to open-source solutions and incorporating open-source licensing into commercial strategies.
The discussion will include: an overview of the different categories of open-source licenses (such as copyleft, prohibitive, and permissive); the obligations and restrictions commonly associated with the use of open-source software; the “copyleft,” “tainting,” or “viral” effect of copyleft licenses; community and private open-source license enforcement trends; and the adoption of open-source software and licensing in support of commercial product and service offerings.
4. Free & Open-Source Software Definitions
› Free Software Foundation (fsf.org | gnu.org)
› “Free Software” | the “Four Freedoms”
› Roughly, the license must grant recipients the freedom to run,
copy, distribute, and modify the software.
› Open Source Initiative (opensource.org)
› “Open Source” | 10 license criteria
› Roughly, the license must be royalty-free, cover source code,
permit copying and distribution, and cannot discriminate against
persons, groups, uses, or technologies.
5. Common use of “open source” in software community
“Open source” is often used more generally to
refer to any software that is licensed:
1. to the public;
2. in source code form; and
3. under a standard (non-negotiable) royalty-
free license.
Perhaps more accurately referred to as “public source” licensing
6. Common OSS License Requirements
1. Provide OSS recipients with certain OSS notices such as the text of the OS license,
notice of OSS use, author attributions, warranty disclaimers, descriptions of
modifications, or offers for source code.
2. Provide OSS recipients with the “corresponding source code” and other supporting
materials for OSS distributed in non-source form (binary, bytecode, et cetera).
3. Grant outbound IP licenses covering OSS or derivatives or impose IP enforcement
penalties (such as OSS license termination) for asserting IP against the OSS or
contributors.
4. Grant OSS recipients certain additional use and development rights such as the right to
replace or reverse engineer the OS software or to “crack” any anti-circumvention
protection limiting access to the OS software.
7. Distinguishing OSS licenses from typical commercial software licenses
open-source Licensing Commercial Software Licensing
Software from many different licensors is licensed
to the general public under standard, non-
negotiable licenses.
Licensing terms are often negotiable and vary by
provider, customer, purchased products and
services, and intended use.
Software is delivered in source form and licensed
for source or binary use.
Software is typically delivered in binary form and
licensed only for binary use.
Licenses generally permit modification, subject to
varying obligations and restrictions.
Licenses typically include prohibitions on reverse-
engineering and modification of the software.
Licenses generally permit royalty-free
redistribution of the software, subject to varying
obligations and restrictions.
Licenses typically prohibit or impose royalty fees on
redistribution of the licensed software.
Licenses generally include explicit disclaimers of
warranty and liability for downstream use of the
software.
License may include warranties and
indemnification from the licensor.
Ownership interests in the software are often
distributed among many contributors.
Ownership interest in the software is typically
consolidated in a single entity.
9. What is Copyleft?
› Copyleft (aka viral, hereditary, reciprocal) licenses require that
certain software combined with the copyleft software be
licensed in source code form under the terms of the same
copyleft license
› The software subject to the license’s copyleft (or “tainting”)
requirements varies by license but are often categorized
generally as either “strong” or “weak” copyleft.
10. License Categories and Features
› open-source licenses are often categorized by the scope of their
copyleft (or “tainting”) effect:
▪ Strong-copyleft
▪ Weak-copyleft (aka “file-level” copyleft)
▪ Permissive (aka “attribution,” “academic”)
› Licenses may also be distinguished by unique restrictions and
requirements:
▪ GNU
▪ Prohibitive/restricted
▪ Network
11. Strong-Copyleft Licenses
› Copyleft requirements can extend to derivative works of
the OS software which may include certain software
combined with the OS software.
› Which software combinations create derivative works is
debated within legal and software communities and not
clearly delineated under U.S. statutes and case law.
› Examples: ▪ General Public License (GPL)
▪ Affero General Public License (AGPL)
▪ Creative Commons Share-Alike Licenses (CC *-SA-*)
12. Weak-Copyleft Licenses
› require modifications or enhancements to the weak-copyleft
OSS to be licensed under the terms of the same weak-copyleft
license.
› Whether combined software is considered a “modification” or
“enhancement” usually depends on how the combined software
and open-source software are combined (e.g., separate processes,
linked runtime library, direct source code combination).
› Examples: • Mozilla Public License (MPL)
• Eclipse Public License (EPL)
• Common Public License (CPL)
• Common Development and Distribution License (CDDL)
13. Permissive Licenses
› Permissive open-source licenses do not have a copyleft
effect, regardless of how the open-source software is
modified or combined with other software
› Sometimes referred to as “attribution” or “academic” licenses.
› Examples: ▪BSD
▪MIT
▪Apache
▪Boost
14. GNU licenses
› Examples of GNU licenses:
▪ Library/Lesser General Public License (LGPL): weak-copyleft
▪ General Public License (GPL): strong-copyleft
▪ Affero General Public License (AGPL): network strong-copyleft
› Unique user/licensee-focused requirements
▪ Enabling recipients to replace the GNU software included or
embedded within products
▪ Permitting reverse engineering or cracking anti-circumvention
protections limiting access to the OS software.
15. Restricted/Prohibitive Licenses
› Restricted/Prohibitive licenses forbid specific uses of the
open-source software
› Examples:
▪ Creative Commons Non-Commercial licenses (CC *-NC-*) prohibits commercial
use
▪ Oracle Binary Code License Agreement prohibits modification or use on dedicated
hardware.
▪ Microsoft Limited Public License (MS-LPL) prohibits use on non-Windows
platforms (e.g., Linux, Mac open-source).
▪ The JSON license prohibits using the software for evil.
16. Network Licenses
› Unlike many other open-source licenses, the requirements of
network licenses are triggered by either distribution or certain
hosted uses of the OSS (e.g., SaaS deployments).
› Examples of network copyleft licenses:
▪ GNU Affero General Public License (AGPL)
▪ Creative Commons Share-Alike Licenses (CC *-SA-*)
▪ Open Software License (OSL)
18. Community OS License Enforcement
› Enforcement primarily driven by the open-source community and OS
interest groups such as the Software Freedom Law Center, Software
Freedom Conservancy, Free Software Foundation, and GPL-
Violations.org.
› OS software licensed under the General Public License (GPL) has
typically been the focus of enforcement efforts
› Defendants that have settled or lost lawsuits include Cisco, Best Buy,
D-Link, Samsung, Skype, TomTom, Westinghouse, Verizon, and JVC.
› Plaintiffs have been successful in U.S., Germany, and France.
19. Private OS License enforcement
> Dual Licensors: Licensor releases source code under a “dual-licensing”
model (licensees select either the OS license or fee-based commercial
license). Licensors often police and pursue allegedly non-compliant
use of the dual-licensed software.
> Open Trolling: individual copyright holders release software under
only an OS license, police non-compliant use, and offer commercial
licenses to non-compliant users and distributors.
> B2B Software Licensing Disputes: OS license obligations or OS license
non-compliance relied upon for affirmative defenses, counterclaims,
or leverage in commercial software disputes.
19
21. Common Open-Source Business Strategies
OS business models generally rely upon one or more of the
following strategies:
1. Dual-licensing proprietary company software;
2. Providing commercial or enterprise versions or
extensions to open-source software or platforms;
3. Offering maintenance, support, consulting or other
services related to or in support of open-source software
4. Closed-source distributions of open-source software
including proprietary modifications or combinations with
proprietary or other open-source software.
22. 1. Dual Licensing
Company offers software for use under either an OS license or a
paid commercial license. The OS license often prohibits or limits
commercial use of the OS software. Licensees wishing to avoid such
restrictions can purchase a commercial license. Commercial licenses
may additionally or alternatively:
▪ provide access to company services (support, maintenance,
customization)
▪ include warranties or indemnification not available under the open-
source license;
▪ provide early access to updated versions of the software; or
▪ serve to resolve company infringement claims.
› Examples: MySQL, Java EE/SE, MongoDB, Qt
23. 2a. Open Core
› Open Core (Freemium): Company offers a version of its product
under an open-source license while offering enhanced versions (aka
an “enterprise” version) of the software under a commercial license.
› Examples: Sendmail, Java EE/SE, Sourcefire Snort, Qt
24. 2b. Open Platform
› Open Platform: Company releases a software platform under an
open-source license and offers proprietary plug-ins, extensions,
applications, or content through the platform under commercial
licensing terms.
› Examples: Android, Eclipse, Wordpress
25. 3. Providing Related Services
› Company offers services related to OS software that may or
may not be owned by the company.
› Related services can include training, customization,
implementation, maintenance, hosting (SaaS, PaaS, IaaS),
certification, support, or compiling, building, or packaging
services.
› Examples: Red Hat, AWS, MongoDB, IBM, Oracle, and Microsoft.
26. 4. Closed-Source Open Source
› Company releases commercial (closed-source) versions of open-
source originally licensed under a permissive license (e.g.,
Apache 2.0) or offers commercial plugins or extensions to an
open-source project or platform. The distributions are often
specialized for a particular industry or use case.
› Examples: Cloudera, Hortonworks, MapR and AWS (offering
virtual server space incorporating numerous open-source
projects).