Great Wide Open Conference April 2, 2014
An Introduction to Free and
Open-Source Software
Licensing and Business Models
Andrew J. Hall
Fenwick & West LLP
This presentation is licensed for use and distribution under the
Creative Commons Attribution-NonCommercial-ShareAlike 3.0
https://creativecommons.org/licenses/by-nc-sa/3.0/legalcode
© 2014 Andrew J. Hall, Fenwick & West LLP
2
Presentation Overview
“Free” and “Open-Source” Software (FOSS)
Categories of FOSS Licenses
Common FOSS License Requirements
FOSS Business Models
“Free” and “Open-Source” Software
3
“Free” and “Open Source” Software
4
Free Software Foundation:
“Free Software” (four freedoms)
Open Source Initiative (OSI.org):
The “Open Source” Definition (ten requirements)
Also referred to a “OSS,” “FOSS,” and “FLOSS.”
FOSS License Examples:
GNU General Public License (GPL)
GNU Lesser General Public License (LGPL)
Mozilla Public License (MPL)
Eclipse Public License (EPL)
MIT and BSD Licenses
Apache Software License
Common usage of “open source” and “FOSS”
5
Software made available:
1. to the public;
2. in source code form;
and
3. under a standard,
non-negotiated
license.
May be more accurately referred to as “public source” licensing
FOSS is not Public Domain
6
Public domain software is software:
1. That the copyright holder has explicitly
dedicated to the public; or
2. For which the copyright term has expired.
Public Domain software can be used without a
license and without restriction.
FOSS is licensed software that must be used
in accordance with the terms of the applicable
FOSS license(s).
How FOSS licensing differs from commercial software licensing
7
FOSS 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.
Categories of FOSS Licenses
8
What is Copyleft?
9
Copyleft (aka viral or hereditary) licenses require that software combined with the copyleft software be made available to (a) in source code form and (b) under the terms of the same copyleft license.
Open-source licensing of proprietary software can effectively preclude collecting license fees for the combined software, but does not prevenet revenue generation using the software.
Copyleft vs. Weak Copyleft
10
The precise scope of the copyleft effect depends on the particular license, but copyleft licenses generally fall into one of the two following categories.
(Strong) Copyleft: Examples include the General Public License (GPL); Affero General Public License (AGPL); Creative Commons Share-Alike Licenses (CC-SA).
Weak Copyleft: Examples include the Lesser General Public License (LGPL); Mozilla Public License (MPL); Eclipse Public License (EPL); Common Public License (CPL)
Licenses with a viral or hereditary effect where derivative works must be licensed in source form under the same copyleft license.
Examples: AGPL, GPL, EUPL, Creative Commons Share-Alike (CC SA), Berkley DB (Sleepycat) License
The viral effects of many copyleft licenses (including the GPL) are triggered by distribution of the copyleft software (aka are subject to the “SaaS Loophole”)
Closed-source companies often strictly scrutinize the use of copyleft software to avoid losing exclusive rights to their proprietary software.
(Strong) Copyleft Licenses
11
Weak-Copyleft Licenses
Licenses that require modifications or
enhancements to (as opposed to derivative
works of) the weak-copyleft FOSS to be made
available (a) in source code form and (b) under
the terms of the same weak-copyleft license.
Often used for licensing software libraries.
Examples: LGPL, MPL, CPL, EPL, CDDL
As with copyleft FOSS licenses the viral effects of
most weak-copyleft FOSS licenses are triggered by
distribution of the weak-copyleft FOSS.
14
Weak-Copyleft Modifications
Use of weak-copyleft FOSS is often closely
scrutinized by closed-source companies to
ensure that sensitive proprietary code not
intended for public use or consumption is not
considered a modification (or equivalent term)
under the FOSS license, which typically depends
on whether the FOSS is:
1. Linked to (used as a library) or directly
combined with proprietary software; or
2. Dynamically linked or statically linked
to by the proprietary software.
15
Permissive Licenses
FOSS licenses that do not have a copyleft effect, regardless of how the FOSS is used
Examples: BSD, MIT, Apache, Boost, Zlib/libping
As with copyleft and weak-copyleft licenses,
permissive licenses typically require some combination of:
Acknowledging use of the FOSS;
Providing a copy of the license and copyright notices included with software;
Attributing the FOSS to the author; and
Providing notice of modifications to the FOSS. 16
Copyleft, Weak Copyleft, and Permissive
17
Copyleft Weak Copyleft Permissive
Intended copyleft
scope
Derivative works of the
FOSS
Modifications or enhancements
to the FOSS None
Imposes source
code obligations
on distributed or
hosted use of the
FOSS?
Nearly all distributions impose source code obligations,
regardless of modification. Some also impose source
obligations on hosted or other network uses of the FOSS.
Rarely
Attribution,
licensing,
disclaimer, or IP
notice obligations
Almost always
Common FOSS License Requirements
18
Common FOSS License Requirements
19
1. Providing corresponding source code
2. Providing acknowledgement, attribution
3. Providing IP notices and disclaimers
4. Identifying or providing access to
modifications to the FOSS
5. Patent grants and restrictions
6. Providing copies of proprietary materials
7. Granting additional use and distribution
rights
FOSS Business Models
20
21
FOSS Business Models
FOSS business models generally rely upon one or more of the following strategies:
“Dual-licensing” of proprietary software;
“Open Core” or “Freemium” licensing of proprietary software; and
Offering services relating to or in support of the company’s or a third party’s FOSS-licensed software.
FOSS Business Models:
Dual Licensing
Some companies offer the same software under either of a FOSS or
commercial license, a practice referred to as “dual licensing.” Examples of dual-
licensed products include MongoDB, MySQL, Java SE/EE, Berkeley DB, Wurfl,
Asterisk, Ext JS, Threaded Building Blocks, and iText.
The FOSS license selected for dual-licensing is typically a commercially
unfriendly license. Licensees that wish to incorporate the software into a
commercial product or service may need to take a commercial license in order to
avoid the undesirable effects of the FOSS license.
Alternatively, commercial licenses may provide access to product support or
customization services or include warranties and indemnification that are not
available under for the FOSS-licensed software.
Challenge: Third parties may be able to “fork” the software creating an
alternative implementation under the same or another FOSS license that is out of
the client’s control. Examples include MariaDB and Drizzle, which are forked
versions of Oracle’s dual-licensed MySQL product.
22
FOSS Business Models:
Open Core / Open Platform
Open Core/Freemium: Some companies offer standard versions of certain products under a FOSS license, while offering enhanced or “enterprise” versions of the software under a commercial license. Examples include Sendmail Sentrion, Sourcefire Snort, and Alfresco’s CMS software.
Open Platform: Some companies release a platform or other software under a FOSS license and offer proprietary plug-ins, extensions, modules, and add-ons under commercial licensing terms. Examples include the Eclipse platform (IBM), Android, Adobe Flex, and the Drupal, Joomla, and Wordpress CMS platforms.
Challenge: Third parties are often able to offer competitive commercial products and services for the same open platform.
23
FOSS Business Models:
Offering Related Services
Some companies release proprietary software under a FOSS license and offer related services for the software such as customization, implementation, hosting, certification, and support services. Examples of companies that have adopted this model include Red Hat, IBM, MongoDB, Hewlett Packard, and Microsoft.
Challenge: Third parties are often able to offer competitive services. Companies adopting this or the open platform strategy often assume that they will able to (i) provide better companion products or services for software with which they are intimately familiar, (ii) create market advantages through, for example, release scheduling or certification processes, or (iii) rely on their brand strength in a competitive marketplace.
24
Other Benefits of
FOSS Licensing and Contributions
Companies choose to license their proprietary software under a FOSS license or
to contribute to existing FOSS project for many different reasons. Some of the
expected benefits more commonly cited include:
Increased adoption of the FOSS products or platforms for or through which
the company sells add-ons, plug-ins, content, or support services or for which
clients offer a premium or enterprise version under commercial terms;
Reduced engineering costs through crowd-sourced or cooperative
development or otherwise externalizing engineering costs by, for example,
“upstreaming” modifications to FOSS projects on which company relies;
Creating goodwill in the FOSS community, which can offer many different
benefits including benefits to developer recruiting and retention and resolving
FOSS-related disputes that may arise; and
Increased influence over the development roadmap for a FOSS project on
which the company relies.
25
26
Presentation Overview
“Free” and “Open-Source” Software (FOSS)
Categories of FOSS Licenses
Common FOSS License Requirements
FOSS Business Models