Open Source License Selection
by
Paul Roberts
Hogan Lovells
202.637.8628
Paul.Roberts@hoganlovells.com
Page 1
Open Source License Selection
Abstract: This paper describes a ten step method for determining what type of open source
license to select depending on the needs of the Author or Contributor of an open source Program.
Additionally, many of the basic principles of open source licensing will be discussed, but an
understanding of patent law may be helpful to the reader. The appendix of the paper also
provides a detailed chart listing the properties and distinguishing characteristics of fourteen of
some of the more common open source licenses.
Author: Paul A. Roberts' practice focuses on litigation, licensing, and prosecution of computer
hardware and software patents, encryption, security, and telecommunication technology. As
both a retired patent examiner and an active member of the ABA Section of Intellectual Property,
Paul maintains an interest in all areas of computer law, and will be speaking on Open Source
Licensing in April, 2011 at the Annual Meeting in Arlington, VA.
Disclaimer: the contents of this paper are provided for informational purposes only. While the
information herein has been verified to extent possible, no guarantees about its accuracy are
intended or implied. Individuals requiring counsel involving open source licensing should obtain
specific legal advice from a qualified attorney.
Open Source Versus Proprietary Software
In a nutshell, proprietary software generally refers to software wherein the Author keeps the
source code a trade secret. Open source software typically refers to software where the Author
distributes the source code. Advocates for open source software suggest that the open source
model creates a better product, by encouraging the software community to build and error check
the software, resulting in more robust software. In contrast, advocates for proprietary software
suggest the economies of private development provide resources to develop a superior product.
Frequently, open source programs are distributed for free (or at least their source code is freely
distributed). Companies involved in the open source arena often make money through providing
customized versions of the software, providing support, or providing specialized packages for the
software product. Open source software distribution is often more about the freedom to modify
the source code, than it is about being free of charge. Freedom to modify, freedom to distribute,
not free of charge.
Page 2
Open Source Framework
In this paper, the Author is the person who
makes the Original Work or Program.
Arrows show the license flow.
A Contributor incorporates the Original
Work into an Improved Work. Some
open source licenses allow the Contributor
to add amalgamate multiple original
works together into a collective work,
others require the Contributor to own the
copyright to all works.
A User obtains the improved work or the
original work from a Distributor.
The license governing the Improved
Version will not necessarily be the same as the license governing the Original Work, because
Contributor can license his contributions under a different license unless the license to the
Original Work required otherwise.
License Models
The options Authors have in selecting an open source license form a spectrum starting from the
relatively permissive such as that of the Massachusetts Institute of Technology License (MIT)
and Berkeley Software Distribution (BSD) licenses allowing most uses of the software to the
relatively restrictive general public licenses (GPL) which go to lengths to prevent proprietary use
of the software. Newer licenses like the Mozilla Public License and the Common Development
and Distribution License provide more of a hybrid approach.
When a license is said to be more restrictive, the license restricts a Contributor’s ability to
convert the software for proprietary use. Typically the “more restrictive” licenses allow the
Contributor or User to have more freedom to modify and distribute the software so long as such
modification and distribution does not involve incorporating the software into proprietary
programs.
Page 3
Common License Options
Below you find 14 of the web’s most popular open source licenses. These fourteen represent a
small fraction of the two hundred or so available open source licenses to choose from, but about
90-95% of the world’s open source licensed software is licensed through one or more of these
licenses. Other popular licensees include Sleepycat (Berkeley Database License), Apple Public,
Academic Free License 3.0, and these licenses and many others may be analyzed through the
same following method.
In the proprietary license world, the proliferation of many different licenses is accepted, because
Users buying proprietary licenses do not expect to be able to able to incorporate the software,
distribute it, or otherwise use it beyond home or commercial user. When a user buys a copy of
PowerDVD or Nero Burning Rom for example, one expects in the accompanying end user
license that he or she can only use the software on one computer, cannot transfer the license,
cannot review the source code, cannot reverse engineer the object code, etc. Whereas the
licenses for VLC player and InfraRecorder are free open source equivalents of these above
software packages. Most users would agree PowerDVD and Nero Burning Rom have more
features and a cleaner more intuitive interface, but VLC Player and InfraRecorder are lighter
weight, have strong community support, and of course free. Some companies produce free
software to promote their brand as well such Ashampoo which makes the popular and free but
proprietary closed source Ashampoo Burning Studio Free software, while other companies
utilize an open source core, but charge for implementation or integration of the core, such as
Source Fire and the open source Snort Engine, or Red Hat’s Linux operating system.
From the user perspective the proliferation of open source may be good for the software
community, but the proliferation of various open source licenses may not. Open source software
thrives on the engagement of the community for development and improvement of the software,
and when Contributors have to wade through a myriad of complicated open source licenses,
some of which may be incompatible with packages the Contributor wishes to use, the
development of open source software may be slowed by the very instrument which creates its
existence –the open source license.
Nearly every significant variation of the terms of an open source license has already been
written, but Authors tend to produce new ones, rather than examine what is already in existence.
With the hundreds of open source licenses available, making a decision as to which license to
Page 4
choose becomes a formidable task, and user tend to pick a common one like the GPL or simply
write their own license. The key to choosing an appropriate license is understanding the
differences between them.
PERMISSIVE LICENSES
1.
2.
3.
4.
5.
Beer
BSD
MIT
Apache License V2
WC3
Permissive licenses are licenses that grant a contributor or user a relatively broad license to use
and modify the source code.
1. The Beer license is the grand daddy of permissive licenses. It basically works like this.
The author provides the rights to distribute, modify, and copy the source code and
executable code of a program to the user, and if the user likes the software and
encounters the author in a bar in the future, the user should buy the Author a beer.
Obviously, the enforceability of this license may be questionable, but it nicely illustrates
the creativity of licenses being prepared by our open source community.
2. The BSD/MIT licenses are largely similar and fairly interchangeable. You may suggest
these licenses when the Author wants to place the software in the open source
community with as little restriction as possible. The downside of course is others can
modify the software and make it proprietary which may defeat some of the benefits of
open source.
3. The MIT license may be a little clearer in spelling out the rights conveyed by the license
as compared to the BSD license.
4. The Apache License v2 is similar to the WC3 license, and adds a patent grant,
overrideable heredity (discussed below), and an attribution requirement.
5. WC3 License (World Wide Web Consortium) has some unique features including a
prohibition for charging for the software created using the open source code.. This is
unusual for open source software. The license also uses a tracked changes requirement
Page 5
HYBRID LICENSES
6. Eclipse
7. CPL
8. MPL 1.1
9. CDDL
10. Artistic License 2.0
11. APL
Hybrid Licenses generally feature heredity, strong patent grants with license revocation for
claims of infringement, a source code distribution requirement, and allow for merging of various
licenses.
6. Eclipse: One of the least restrictive licenses featuring heredity and source code
distribution requirements. It is based on the CPL. It requires New York Law to
apply.
7. CPL: Separate object and source code distribution requirements; the source code must
be distributed under this license, the object code under a different license but the
source code for the object code must be distributed under the license.
8. MPL 1.1: Compared to the CPL/Eclipse licenses the MPL features a very organized
structure, an attribution requirement (though nearly all licenses requirement
distribution of the original license and copyright notice), and a strong license
revocation clause. The MPL 1.1 makes many of the patent grant license terms very
explicit, for example a User has to disclose if it owns any reasonably necessary
patents for implementation of an API.
9. CDDL: Generally clean and easy to read compared to the MPL, but it has similar
coverage with a few minor differences.
10. Artistic License: Despite the name, this license was developed for distribution of
PERL. It has very unusual ways of accomplishing basically same thing as the CDDL.
For example, rather than forcing you to distribute the source code, you have to make
it available to the Author, and the Author can distribute it. The artistic license is
especially useful for licensing new software languages.
11. APL: is a customizable license that works as a template for other licenses. Some
variable clauses include the patent grant, attribution, and jurisdiction.
Page 6
RESTRICTIVE LICENSES
12. LGPL
13. PL2
14. GPL3
The General Public Licenses (GPL) represent the lion’s share of the open source licensing used
because of their strong copyleft provisions. They also are incompatible with other licenses, and
do not allow for a different license for the object code and source code (unlike the Hybrid
Licenses.)
Some of the variations between these licenses are software libraries licensed under the Lesser
General Public License (LGPL) can be incorporated into proprietary programs, whereas GPL2/3
code cannot. The LGPL includes all the language from the GPL (version 2 or 3), but adds a few
sections which modify certain GPL requirements. The GPL3 was recently published by GNU in
response to three major changes in the law since the release of GPL2. GPL3 adds patent grant, a
prohibition against using the licensed software with DRM media, and adds hardware lock
protection (Tivolization) to the GPL2.
Major License Features
About 40 of the most popular licenses were reviewed in preparing the below list. These ten
differences represent some of the more significant variations open source licenses can have.
1. Heredity
2. Strong, Weak, or no copyleft
3. Static, active, or no linking
4. Open source improvements
5. Patent grant
6. Merging
7. Distribution
8. Change tracking
9. Attribution
10. Hardware Locks
11. Miscellaneous (warranty disclaimer, choice of law, license revocation, etc)
The above 11 categories may provide an approach for figuring out which license one needs, one
can answer the questions and check the attached chart to determine the license having these
features.
1. Heredity: relates to a license’s requirement for any subsequent license on contributions to
be licensed under the same terms. Most licenses requiring Heredity (and many of the
other features just mentioned) grant the license conditioned upon the acceptance of all
terms, thereby preventing a contributor from removing restrictions from the license.
Often extra terms can be added, but not in all licenses such as the GPL.
Page 7
2. Copyleft: The ability of a contributor or distributor to add restrictions to a work. While
most open source software allows you to use and modify the code as you want, open
source software incorporating copyleft provisions prevent a contributor from making the
future software proprietary.
3. Linking: Linking is the difference between strong and weak copyleft. Programs which
are compiled and draw in other programs are called static linking. Most weak copyleft
licenses require the statically linked code to have the same terms as the contribution.
Active linking refers to drawing in programs at run time. Only the GPL3 and arguably
GPL2 require the active linking also to be compliant with the terms of the GPL License.
4. Open source improvements: This is a general distribution requirement that any
contributor works must also be open source.
5. Patent Grant: There are a number of different types/styles of patent grants that different
open source licenses require. Most of them are untested, and selection of any appropriate
one, largely depends on how specific the Author feels is necessary to protect himself and
his future users. Also most licenses include an automatic license withdrawal provisions
triggered by asserting the license.
6. Merging: Refers to whether this software can be merged with other software having a
different license. Most licenses allow merging
7. Distribution: What requirements does the license provide for distributing source or
executable versions of the software.
8. Change Tracking: Some licenses require the contributor specify what he changed in
relation to the original program
9. Attribution: Most licenses require the original copyright notices and licenses to be
included, but some also require attribution to all intervening contributors who added code
to the software
10. Hardware Locks: can you use hardware to lock the code (via a watermark or key) as to
prevent users from effectively modifying the code. This tactic was performed by TiVo,
which led to the development of GPL3
11. Miscellaneous: This just includes all the random differences licenses have from choice of
law, whether there is a warranty disclaimer, whether there is a license revocation clause,
etc.
If one thinks of a license type as the answer to the list of 11 questions, answering the eleven
questions will provide the type of license you should consider. For example, if one selects: yes
to heredity, prefers weak copyleft protection, didn’t want to place restrictions on linking wanted
a patent grant, to allow merging, want to force Contributors to make their source code available,
didn’t want to enforce change tracking, but did want attribution, didn’t want to enforce hardware
locks, and wanted a warranty disclaimer the Common Public License or Eclipse license would
fit. (The following is excerpted version of the chart from the appendix.)
Page 8
Category
Heredity
Eclipse
Yes
CPL
Yes for source code
Weak, Strong,
or no Copyleft
Static, active, or
no linking
Weak
Weak
No restriction
No restriction
Open source
improvement
Yes because of heredity
Yes
Patent Grant
Yes
Yes
Merging
Allowed
Allowed
Distribution
Source code must be made
available in a reasonable
manner
Source code must be made available in a reasonable
manner
Change
tracking
None
None
Attribution
None
None
Hardware
Locks
None
None
Miscellaneous
(warranty
disclaimed
unless
otherwise
noted)
Prospective license
termination if a user asserts
a claim of patent
infringement against the
Author or a Contributor.
New York Law Applies
Prospective license termination if a user asserts a claim
of patent infringement against the Author or a
Contributor.New York Law Applies
Link
Significant
Differences
Eclipse
One of the least restrictive
licenses featuring heredity
and source code distribution
requirements. It is based on
the CPL
CPL
Separate object and source code distribution
requirements; the source code must be distributed
under this license, the object code under a different
license but the source code for the object code must be
distributed under the license.
This is not to say the Eclipse license is the same as the Common Public License (the Eclipse
License actually is a successor-e.g. version 2.0) of the Common Public License. And while these
two licenses bear great similarity both should be reviewed, and the one having the more desired
word smithing selected. By way of example both the MPL and CDDL licenses feature heredity
and a patent grant, but the scope of the MPL heredity clause differs from the CDDL as does the
scope of the patent grant.
As shown in the following chart, the heredity clause of the CDDL is arguably broader (in least
broad enough to warrant the departure from the original MPL wording) than the heredity clause
of the MPL. Similarly, the scope of the patent grant is larger for the CDDL because the CDDL
includes a patent grant for code separated from the Original or Modified Work.
Page 9
Most of the licenses featured in the chart in the appendix have various revisions: BSD has three
versions, the Artistic License two versions, GPL three versions, etc. Each having different
wording for each category, and some having opposite answers for each category. In general, one
should select the most recent version of each license, as the custodian of the license (the
organization that wrote it) updated because it felt that the preexisting one was not clear enough
or did not adequately protect the software. A notable exception is the GPL license. Some
commenters believe that GPL3 is too strong of a copyleft license, and others (notable fans of
GNU) believe it strikes the right balance of ensuring that open source software stays open source
in all of its applications.
Page 10
Category
MPL 1.1
1.9 Modifications means any
addition to or deletion from the
substance or structure of either the
Original Code or any previous
Modification
A. Any addition to or deletion from
the contents of a file containing
Original Code or previous
Modifications.
B. Any new file that contains any
part of the Original Code or previous
Modifications.
Patent Grant 2.1 (b) to make, have made, use,
practice, sell, and offer for sale,
(Author)
and/or otherwise dispose of the
Original Code.
Scope of
Heredity
CDDL
Comments
1.9 A. Any file that results from an
addition to, deletion from or
modification of the contents of a file
containing Original Software or
previous Modifications.
B. Any new file that contains any part
of the Original Software or previous
Modifications.
The CDDL in nearly all
cases has a broader
heredity clause than the
MPL.
2.1 (b) to make, have made, use,
practice, sell, and offer for sale, and/or
otherwise dispose of the Original
Software.
Under CDDL if you
separate code from the
Original Code, the User
must grant patent rights
covering the separated
2.1 (d) no patent license is granted: 2.1 (d) no patent license is granted: (1) code. Not so with the
1) for code that You delete from the for code that You delete from the
MPL. Under the
Original Code; 2) separate from the Original Software; or (2) for
CDDL, to avoid the
Original Code; or 3) for
infringements caused by (i) the
paten grant, the User
infringements cause by i) the
modification of the Original Code or must use all the code, or
modification of the Original Code or (ii) the combination of the Original
none of it.
ii) the combination of the Original Software with other software or
Code with other software or devices. devices.
2.2(b) to make, use, sell, offer for sale, In 2.2(b), the CDDL
Patent Grant 2.2(b) to make, use, sell, offer for
have made, and/or otherwise dispose clarifies that a patent is
(Contributor) sale, have made, and/or otherwise
dispose of: 1) Modifications made by of: (1) Modifications made by that
granted for portions
that Contributor with its Contributor Contributor with its Contributor
whereas the MPL 1.1
Version and 2) the combination of Version; and (2) the combination of does not. While the
Modifications made by that
Modifications made by that
removal of the
Contributor with its Contributor
Contributor with its Contributor
separation term may
Version.
Version (or portions of such
seem insignificant,
(d) No patent license is granted: 1) combination)
because patent claims
for any code that Contributor has
(d) No patent license is granted: (1)
usually cover positive
deleted from the Contributor
for any code that Contributor has
recitation of elements,
Version; 2) separate from the
deleted from the Contributor Version; but since claims can
Contributor Version; 3) for
(2) for infringement caused by: i) third also negatively claim
infringement caused by: i) third party party modification of Contributor
elements the withdrawal
modification of Contributor Version Version, or (ii) the combination of
of the license grant from
or ii) the combination of
Modifications made by that
the MPL allows a
Modifications made by that
Contributor with other software
Contributor or Author
Contributor with other software or (except as part of the Contributor
to better forecast which
other devices; or 4) under Patent
Version) or other devices; or (3) under of its patents will be
Claims infringed by Covered Code in Patent Claims infringed by Covered licensed by User
the absence of Modifications made Code in the absence of Modifications activity.
by that Contributor.
made by that Contributor.
Page 11
Conclusion
Determining which open source license best fits a software package is a matter of deciding how
forceful the Author wishes to be in making sure that none of the software can be incorporated
into any proprietary programs. In many open source licenses, even the Author cannot stop the
distribution of the software, once it has been released. However, sometimes an Author’s
interests are best served with a Hybrid License which allows a company to distribute source code
and object code under different licenses, and sometimes very little protection is needed at all.
And while there is something to say for keeping open source software free from proprietary use,
the use of the GPL3 license will never be a one size fits all license for every open source
software manufacturer. By stepping through the various categories in the paper, one can arrive
at the precise level protection from incorporation into proprietary programs that the Author
needs.
Page 12
Exhibit
Chart of Open
Source Licenses
Page 13