License Profile: The Eclipse Public License

AuthorKatie Osborne
PositionSolicitor, Moorcrofts LLP
Pages1-12
License Profile: Eclipse Public License 1
License Profile: The Eclipse Public License
Katie Osborne,a
(a) Solicitor, Moorcrofts LLP
DOI: 10.5033/ ifosslr.v7 i1.73
Abstract
The Eclipse Public License (“EPL”) is an open source license that
is widely used in various open source projects, most notably by the
Eclipse Foundation. The EPL is often described as a weak copyleft
license, and contains a narrower and, some argue, more precise
reciprocity obligation than that of the GNU General Public License
(“GPL”). Further, the EPL includes a patent retaliation provision
intended to discourage patent litigation, but still limited in scope so
as to not scare off companies with large patent portfolios. This
article provides a summary and overview of the EPL.
Keywords
Eclipse Public License; Law; information technology; Free and
Open Source Software;
1: License History and Usage
The Eclipse Public License version 1.0 (“EPL”) is an open source license intended to be
business friendly, while still supporting and encouraging collaborative open-source
development, through its weak copyleft features. 1 The EPL is most notably used by the
software projects hosted by the Eclipse Foundation, but is also the default license for new
projects within the Linux non-profit organization Linaro.2 Furthermore, the EPL was the
1Eclipse and Eclipse Foundation Home Page, http://www.eclipse.org/. The Eclipse Foundation is
a not-for-profit, member supported corporation that hosts the Eclipse projects and helps
cultivate both an open source community and an ecosystem of complementary products and
services. (see http://www.eclipse.org/org/ (last visited March 16, 2015). The full text of the
EPL is available at: http://www.eclipse.org/legal/epl-v10.html (last visited March 16, 2015).
2Linaro, Home Page, http://www.linaro.org/. Linaro sets out its license selection and approval
process on a webpage that is available at: https://wiki.linaro.org/TSC/LicenseSelection (last
visited March 16, 2015). Linaro is a not-for-profit engineering organization consolidating and
optimizing open source Linux software and tools for the ARM architecture.
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 2
default license for the Symbian mobile operating system stewarded by Symbian Foundation,
now transitioned to a licensing-only organisation.3 Although open source license usage
statistics remain a controversial topic, it is still worth noting that the EPL currently occupies
the 10th spot on the Open Source Lice nse Top 20 Rank published by Black Duck Software,
Inc.4
The EPL is derived from the Common Public License version 1.0 (“CPL”), which was
published by IBM.5 The EPL introduces very few changes to the CPL, with the only
significant one being that the scope of the patent retaliation clause is considerably narrower.
The EPL conforms to the Open Source Definition, and was approved by the Open Source
Initiative in May 2004.6 The agreement steward for the EPL is the Eclipse Foundation
whereas for CPL it was IBM. In the form of Frequently Asked Questions, the Eclipse
Foundation has provided guidance on how to best apply the EPL. 7
The EPL is classified as a copyleft license. This means that it supports a reciprocity concept
just like as the GNU General Public License (“GPL”),8 GNU Lesser General Public License
(“LGPL”)9 and Mozilla Public License (“MPL),10 in that changes and additions to the
software that are being distributed must be made available in source code form and under the
applicable open source license. Although the scope of changes and additions that the EPL
requires to be published are narrower than required by the GPL, thus the characterization of
the EPL as a “weak” copyleft lice nse the EPL, arguably, do require closer attention from
software developers and in-house legal counsels that consider using EPL software, as
compared to permissive licenses such as the Apache License 2.0,11 BSD license12 or MIT
license.13
3Symbian Home Page, http://licensing.symbian.org/. The Symbian source code is still available
at: http://code.google.com/p/symbian-incubation-projects/ (last visited March 16, 2015).
4See the Open Source License Data available at:
http://osrc.blackd ucksoftware.com/data/licenses/ (last visited March 16, 2015). The Open
Source License Data shows the top 20 licenses used in open source projects in Black Duck's
Knowledgebase.
5IBM, Common Public License Frequently Asked Questions Page,
http://www.ibm.com/developerworks/opensource/library/os-cplfaq/index.html. The full text of
the CPL is available at: http://www.eclipse.org/legal/cpl-v10.html (last visited March 16,
2015).
6See the Open Source Definition of the Open Source Initiative (OSI), available at:
http://www.opensource.org/docs/osd (last visited March 16, 2015).
7See the Eclipse Public License (EPL) Frequently Asked Questions Page, available at:
http://www.eclipse.org/legal/eplfaq.php (last visited March 16, 2015).
8Th e full text of the GPL is available at: http://www.gnu.org/licenses/gpl.html (last visited
March 16, 2015).
9Th e full text of the LGPL is available at: http://www.gnu.org/licenses/lgpl.html (last visited
March 16, 2015).
10 The full text of the MPL 2.0 is available at: http://www.mozilla.org/MPL/2.0/ (last visited
March 16, 2015).
11 The full text of the Apache License 2.0 is available at:
http://www.apache.org/licenses/LICENSE-2.0.html (last visited March 16, 2015).
12 Th e full text of the BSD license is available at: http://www.opensource.org/licenses/bsd-3-
clause (last visited March 16, 2015).
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 3
The narrow copyleft scope, together with the conventional legal language used in the license
and the possibility of relicensing EPL programs in object code under proprietary licensing
terms, have led many to describe the EPL as a business friendly license. 14 Finally, in terms of
length, the EPL is far longer than the BSD and MIT licenses, roughly equal in size to the
Apache License 2.0, and significantly shorter than the GPL 3.0.
2: Content of the License
The EPL starts off with a list of definitions, and continues with the copyright and patent
license grants. These are followed by a list of requirements for distribution of EPL programs
in object code and source code form. The EPL concludes with warranty a nd liability
disclaimers and a number of general provisions.
2.1: Key Definitions
The definitions in the EPL, albeit few and short, are key to an understanding of the EPL.
Contributors and Recipients
There are two types of parties defined in the EPL: Contributors and Recipients.
“Contributors” means any person or entity that distributes the EPL program, whether
modified or not. Including mere re-distributors in the definition could appear somewhat odd,
especially since the lay meaning of the word contributor arguably includes only persons or
entities who add code to the program (i.e. one who “contributes”). However, most other open
source licenses do also limit the definition of Contributors this way.15 “Recipients” means
anyone who receives the Program under the EPL, including all Contributors. Recipients are
often called “you” in other open source licenses.
Contribution and Program
The definition of “Contribution” is two-fold and covers either (a) the initial software
distributed under EPL, or (b) certain changes and additions made to that software. Depending
on the context, the term Contribution will have either of these meanings, but never both.
Conversely, the term “Programs” means the Contributions that are distributed in accordance
with EPL, i.e. both (a) the initial software distributed under EPL and (b) certain changes and
additions made to the software. Consequently, when a company creates changes or adds to the
Program, the change or addition is a Contribution and becomes part of the Program.
Focusing again on the definition of “Contribution”, its most important aspect is that it also
describes the scope of the changes and additions that are covered by the copyleft scope of the
13 T he full text of the MIT license is available at: http://www.opensource.org/licenses/mit-
license.php (last visited March 16, 2015).
14 Heather J. Meeker, The Open Source Alternative:Understanding Risks and Leveraging
Opportunities 41 (John Wiley & Sons, Inc., 2008).
15 See the Apache License 2.0 (article 1) and the MPL 2.0 (article 1.1).
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 4
EPL. This is addressed in Section 2.5 below. It should be noted that the term “Contribution”
includes not only software code, but a lso documentation. This is different from many other
open source licenses that cover solely software.16
2.2: Copyright License Grant
The EPL has a broad and very permissive copyright license grant, presumably modelled after
the statutory rights enumerated in Section 106 of the US Copyright Act. The grant is “non-
exclusive, worldwide and royalty-free” and includes the rights to “reproduce, prepare
derivative works of, publicly display, publicly perform, distribute and sublicense the
Contributions of such Contributor, if any, and such derivative works, in source code and
object code form”. This broad copyright license grant is similar to other “modern” open
source licenses, like the Apache Lic ense 2.0. Note that the “older” licenses, like the BSD and
MIT, have simpler and more ambiguous license grants, such as: “Redistribution and use in
source and binary form, with or without modification, are permitted…”.
The EPL copyright license grants rights from each Contributor. Thus, the user does not
receive a full sub-license from the person or entity that distributed the EPL program, but
rather a separate license from each author to their respective portions. This reflects what is
often ca lled the direct licensing model of open source software.17 This model is implicit in
many open source licenses, and is most clearly spelled out in article 10 of the GPL 3: “ Each
time you convey a covered work, the recipient automatically receives a license from the
original licensor…” It should though be noted that the EPL license grant still includes the
right to sublicense the Contributions. This may seem contradictory in light of the aforesaid,
but it is not inconsistent because the EPL allows sublicensing in object code form under
proprietary license terms in Section 3.
2:3 Patent license grant
The EPL also c ontains an express patent license grant, seemingly based on US statutory law.
This differs from the BSD and MIT licenses which do not even mention patents. The EPL
patent license grant is “non-exclusive, worldwide, royalty free” and includes the rights to
“make, use, sell, offer to sell, import and otherwise transfer the Contribution of such
Contributor, in source code and object code form”.
The license is granted from e ach “Contributor”, which, as mentioned above, covers any
person or entity that merely distributes the unmodified versions of the Program. This might
lead the reader to fear that by engaging in the m ere act of re-distribution of an EPL program
one would, as a result, also be granting a license to any patent that he or she owns should
those patents read on any part of the EPL program. This is certainly not the intention. The
EPL patent license explicitly limits the grant to “the Contribution of such Contributor”, i.e. to
the distributor ’s modifications, if any. If the Contributor does not make any changes to the
Program, no patent license is granted. This is a logical result of the direct license model
16 See for instance the MPL 2.0 (article 1).
17 Heather J. Meeker, supra note 14, at 29.
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 5
employed by the EPL, where the rights are granted directly from each author to all licensees.
The same approach is taken by all major copyleft licenses.18
The license also grants rights under the “Licensed Patents”. This term covers patent claims
licensable by a Contributor that are necessarily infringed by the use or sale of its Contribution
alone or when combined with the Program. The license though applies only to the
combination of the Contribution and the Program, if, at the time the Contribution is added by
the Contributor, such addition causes such combination to be covered by the Licensed
Patents.19 Note the use of the words “at the time” – the patent license does not cover
subsequent downstream modifications. The patent license also does not cover combinations of
the Contribution with any software other than the Program. This is a logical lim itation, which
is found in most open source licenses. Contributing entities, especially corporations with large
patent portfolios, would want to be able to review and track which of their patents are being
exposed to licensing by their Contributions.20 Finally, the license will not cover a
Contributor’s pending patent applications if the application has not been issued as a patent at
the time the Contribution was added.
2.4: The EPL Copyleft
The Reciprocity Obligation
The EPL is a copyleft license and thus it contains a so-called reciprocity obligation. A
reciprocity obligation implies, somewhat simplified, that changes and additions to the open
source program that the user elects to distribute must be made available in source code form
and under the original open source license terms. The EPL spells out the reciprocity
obligation in Section 3, which states that when the Program is made available in source code
form, it must be made available under the terms and conditions of the EPL. As mentioned
above, the term “Program” includes the Contributions, which in turn include ce rtain changes
and additions made to the Program by the user. This is much like the GPL 3.0, although the
scope of the copyleft is narrower, as outlined below.
The reciprocity obligation also follows indirectly from the EPL patent license grant: The
license is granted by Contributors, which include distributing entities, and covers
“Contributions,” which comprise the changes and additions the distributing entity has made.
For clarity, the re ciprocity obligation in the EPL is, according to its Section 3, triggered first
when the changes and addition are distributed. This also follows from the definition of
Contributions, which only covers changes and additions that originate from “and are
18 Note, however, that under article 10 of the GPL 3.0, the distributor of the GPL 3.0 software is
prohibited from imposing “further restrictions”. This means that the distributor may not impose
a license fee, royalty, or other charge for exercise of rights granted under the GPL 3.0.
19 Lawrence Rosen, Open Source Licensing – Software Freedom and Intellectual Property Law
165 (Prentice Hall 2004),available at:http://www.rosenlaw.com/pdf-files/Rosen_Ch08.pdf
(last visited March 16, 2015).
20 For a good summary of patent portfolio management aspects of open source contributions, see
Heather J. Meeker, supra note 14, at 98.
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 6
distributed by” the particular Contributor. Changes and a dditions made solely for internal use
are thus not within the scope of the reciprocity obligations of the EPL.
Scope of the Copyleft
The EPL is normally referred to as a “weak” copyleft license since the scope of the changes
and additions that are covered by the reciprocity obligation in the EPL are narrower than
under “strong” copyleft licenses like the GPL 3.0. The scope of the EPL copyleft is set out in
the definition of Contribution.
First, “changes” to the Program always fall within the definition of a “Contribution” so
“changes” are always considered to be covered by the scope of copyleft.
Second, “additions” to the Program are a lso considered to be Contributions unless both of the
following conditions are met:
(1)The addition is a separate module of software. The term “module of software” is not
defined in the EPL.
(2)The addition is not a derivative work of the Program. The term “derivative work” is not
defined in the EPL, but the term would most certa inly be construed in accordance with the
U.S. Copyright Act because the EPL is governed by the laws of the state of New York and the
intellectual property laws of the United States and because the EPL FAQs state that the
Eclipse Foundation interprets the term “derivative work” in a way that is consistent with the
U.S. Copyright Act’s definition.
It is notable that the two conditions are c onjunctive – a software addition placed in a se parate
module from the original EPL program could still be covered by the reciprocity obligation if it
constitutes a derivative work of the EPL program. The EPL FAQs give little concrete
guidance on the matter but do however explain that merely interfacing or interoperating with
Eclipse plug-in APIs (without modification) will not make an Eclipse plug-in a derivative
work. The FAQs do not rule out that linking to Eclipse program could create a derivative
work.
Some believe that the EPL contains a rather clearly defined scope of copyleft 21 or that it is at
least clearer than that of the GPL, which many believe raises doubts as to whether the linking
and other software communication methods may or may not be covered by GPL’s reciprocity
obligation.22 But this may not be a completely correct analysis; distinguishing between what
is a change (which always falls within the definition of a Contribution) and what is an
21 When announcing the open sourcing of the Symbian platform, the Symbian Foundation made
the following statement showing its preference for the EPL’s more clearly defined boundaries:
“The Symbian Foundation has instead chosen the EPL because it wants to be absolutely clear
about this: device manufacturers will be able to add new features and support new hardware
without having to make all of that code open source, except where they are changing or
making certain additions to EPL code supplied by the Symbian platform.” Note that the
Sym bian Fou ndati on ha s now tr ansit ioned to a lic ensin g onl y au thori ty. See
http://licensing.symbian.org ( la st v i si te d M ar ch 1 6 , 2 0 15 ). S ee a ls o
http://en.wikipedia.org/wiki/Eclipse_Public_License (last visited March 16, 2015) (describing
the EPL license).
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 7
addition (which may not fall within the definition of a Contribution) may not always be an
easy thing to determine in practice, secondly, the concept of derivative works as applied to
software is also far from clear-cut.
2.5: Distribution Requirements
General Requirements
Section 3 of the EPL includes a couple of general requirements for the distribution of the EPL
software, and certain specific requirements for object code and source code distribution, both
of these requirements are explained in the subsequent chapters and summarized below.
First, Contributors may not remove or alter a ny copyright notices contained within the
Program. This is a standard requirement found in most open source licenses, particularly
historic licenses such as the BSD license. Second, the EPL requires each Contributor to
identify itself as the originator of its Contribution, in a manner that reasonably allows
subsequent Recipients to identify the originator of the Contribution. The requirement reflects
what is considered to be a good practice in open source communities. The identification is
normally done by placing appropriate copyright notices in the header of each source file
and/or in separate contributor text files.
Object Code Distribution
The EPL permits a Contributor to distribute the EPL program in object code form under its
own license agreement provided that the Contributor complies with the EPL and the license
agreement contains effective warranty disclaimers and liability exclusions. Section 3 of the
EPL contains the precise wording of these requirements.
The EPL does not require the source code of the program to be made available together with
the object code, but the Contributor’s license agreeme nt must state that the source code of the
EPL program is available from the Contributor and inform licensees how to obtain it in a
reasonable manner on or through a medium customarily used for software exchange. For this
reason, it may sometimes be advisable to distribute the relevant source code simultaneously
with the object code, especially if the distributor wishes to avoid the added work of having to
monitoring future requests and dealing at a later date with its obligation to provide the source
code. On the other hand, if the strategy is to deter users from making derivative works of the
EPL software, it may be wise to only attach a pointer to the source code and thus require an
explicit action by the user to obtain it.23
22 See Heather J. Meeker, supra note 14, at 183-221 (giving a further description of the “linking
deba te. ”); se e als o Lothar D eterman, Dangerous Liaisons Software Combinations as
Derivative Works? Distribution, Installation and Execution of Linked Programs under
Copyright Law, Commercial Licenses and the GPL, 21 BERKELEY TECH. L.J. 1421, 1291 (2006);
Van Lindberg, Intellectual Property and Open Source, A Practical Guide to Protecting Code
226-238 (O’Reilly Media, Inc., 2008).
23 See A pac he So ftw are Fo und ati on Le gal Pr evi ous ly A ske d Q ues tio ns Pa ge,
http://www.apache.org/legal/resolved.html#category-b (la st vi sit ed M arc h 1 6, 2 015 )
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 8
Source Code Distribution
When an EPL program is made available in source code form it must be made available under
the terms of the EPL. Unlike the GPL 3.0, the EPL does not explicitly state that the distributor
may not impose any other terms on others with respect to the Program. Further, in connection
with source code distribution, a copy of the EPL must be included with each copy of the
Program. The EPL does not specify e xactly how the copy of the EPL must be included in the
distribution.
Specific Responsibility for Commercial Distributors
Section 4 of the EPL stipulates a specific additional responsibility for commercial distributors
of EPL programs: Contributors who include the Program in a commercial product offering
should do so in a manner that does not create potential liability for other Contributors. This
implies that commercial distributors accept an indemnity obligation with respect to losses,
damages and costs arising from claims against the other contributors. The indemnity
obligation expressly excludes any clai ms or losses related to intellectual property
infringement.24
2.6: Other Provisions
Warranty and Liability Disclaimers
Sections 5 and 6 of the EPL contain a warranty disclaimer and a limitation of liability which
are not very different from those found in most other open source licenses. Furthermore,
Section 2(c) contains language that overlaps somewhat with the aforementioned sections and
stipulates that the Contributors provide no assurances that the Program does not infringe any
third party intellectual property rights. The same section also cla rifies that if a third party
patent license is re quired to allow the Recipient to distribute the Program, then it is the
Recipient’s responsibility to acquire that license before distributing the Program.
Patent Retaliation
The EPL also contains a specific provision variably known as a patent termination, patent
retaliation or patent defence clause. The basic message conveyed in such a clause is that a
licensee cannot take advantage of both using the open source software and at the same time
alleging that the software infringes his patents. This discourages patent litigation and is
certainly not an unreasonable bargain. More specifically, Section 7 of the EPL provides that a
Recipient that institutes patent litigation alleging that the EPL program infringes the
Recipient’s patent will see his patent license term inated. The EPL patent termination clause is
often described as a “weak” one, mainly because it is triggered only by infringement actions
concerning the licensed EPL program. This is contrary to the patent termination clause in the
(recommendation of Apache Software Foundation for usage of code subject to weak copyleft
licenses).
24 For a further analysis of Section 4 of the EPL, see Lawrence Rosen, supra note 19, at 173.
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 9
EPL’s predecessor, the CPL, as well as the MPL 1.1, where the patent license would terminate
for the institution of patent litigation against a contributor with respect to any software (not
only the licensed program). Such strong patent termination clauses were generally considered
as as overbroad.
Further, under the EPL the institution of patent litigation would terminate the patent license
only and not the copyright license. This is different from the MPL 2.0 and the Common
Development and Distribution License (“CDDL” ),25 where both the copyright license and the
patent license terminate if patent litigation is instituted. Finally, it should be mentioned that
under the EPL a cross claim or counterclaim for patent infringement would also lead to the
loss of the patent license. This is similar to the Apache License 2.0, but different from the
MPL 2.0, which excludes declaratory judgments, cross claims and counterclaims alleging
patent infringement from the scope of the patent retaliation clause.
Governing Law and Disputes
Unlike most other Open Source licenses, the EPL includes a governing law clause. Section 7
of the EPL provides that the EPL is governed by the laws of the State of New York and the
intellectual property laws of the Unites States of America. Furthermore, the same section of
the EPL includes a mutual jury trial waiver.
Time Bar
Section 7 of the EPL provides that “No party to this Agreement will bring a legal action under
this Agreement more than one yea r after the cause arose”. Note that the one year period
begins to run when the claim a rose, not when the potential claimant bec ame aware of the
claim. There is therefore no tolling of the one year time bar for failure to discover the claim.
Such a clause is not common in other open source licenses.
3: Compatibility
3.1: EPL and GPL
The EPL and GPL are generally considered to be incompatible. This means that components
licensed under these licenses will be difficult to use in a common environment if they would
interact in such a way that either of them would constitute a derivative of the other. According
to the Eclipse Foundation, the EPL and GPL are not compatible in any combination where the
result would be considered either (a) a “Contribution” under the EPL, or (b) a work “based
on” the GPL program, as that phrase is used in the GPL.26 Further, the foundation states that
EPL and GPL code may not be combined in any scenario where source code governed by
25 The full text of th e Common Devel opment Di stribution License is availab le at:
http://www.opensource.org/licenses/CDDL-1.0 (last visited March 16, 2015).
26 See Eclipse Public License (EPL) Frequently Asked Questions Page, supra note 7, question 32,
available at http://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE (last visited March
16, 2015).
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 10
both licenses are found in the same source code module. This applies to both the GPL 2.0 and
GPL 3.0. The Free Software Foundation shares the Eclipse Foundation’s view. 27
3.2: EPL and LGPL
For the reasons given in chapter 3.1 above, the EPL and LGPL are also incompatible.
However, since the LGPL copyleft is not as strong as that of the GPL, it is more likely that the
LGPL and EPL components may be used in a common environment in a way that is
compliant with both licenses. For instance, interaction between such c omponents through
dynamic linking should normally be permissible.
3.2: EPL and Apache License 1.1 and 2.0
The Apache Licenses 1.1 and 2.0 are on the current list of licenses approved for use by the
Eclipse Foundation for use by third party code redistributed by Eclipse projects and further
the EPL 1.0 is on the Apache Foundation's “Category B List”, that is, the list of those licenses
under which software may be included in binary form within an Apache Product (provided
that the inclusion is appropriately labelled)28. Because the Apache License 2.0 expressly
permits the user to relicense the Apache software under additional or different licensing terms,
this means that if Apache code is combined with EPL code such that it forms part of a
“Contribution”, then the original Apache code must, if distributed, be licensed under the EPL.
4: Conclusion
The EPL is a weak copyleft license that, in the author’s opinion, successfully manages to
balance the open source community’s need to incentivize collaborative software development
with participating companies’ concerns about exposing their proprietary code and patent
portfolio. This may mean that we will see increased usage of the EPL in the future, especially
if the trend towards increased usage of weak copyleft licenses predicted by some influential
Open Source bloggers becomes reality.29 However, it should be noted that there are some
features of the EPL that might play against it. For instance, the scope of the copyleft under the
EPL is by no means crystal clear, e.g. because it relies on the concept of derivative work
under US copyright law. As applied to software, that concept is very much open and unclear.
Further, EPL is not compatible with the GPL 2.0 or GPL 3.0, which may limit its potential
usage in software environments dominated by programs governed by these licenses. Thus, it
may be argued that MPL 2.0 with its file-based copyleft approach and new-born GPL
compatibility provides a more predictable solution for software developers.
27 See FSF’s li st o f Vario us Li cense s and Co mment s Abo ut Th em, availabl e at:
http://www.gnu.org/licenses/license-list.html#EPL (last visited March 16, 2015).
28 See Eclipse Public License (EPL) Frequen tly As ked Questions Page, availa ble at
http://www.eclipse.org/legal/eplfaq.php (last visited March 16, 2015) and Apache Software
Foundation Legal Previously Asked Questions Page, available at
http://www.apache.org/legal/resolved.html (last visited March 16, 2015).
29 See Simon Phipp s, What's next after GPL and Apache? Infoworld (May 18, 2012)
http://www.infoworld.com/d/open-source-software/whats-next-after-gpl-and-apache-193376
(last visited March 16, 2015).
International Free and Open Source Software Law Review Vol. 7, Issue 1
License Profile: Eclipse Public License 11
About the author
Kati e Os bor ne is a solicitor at specialist corporate and technology firm
Moorcrofts LLP and practises in the areas of technology and intellectual property
law and has a keen interest in open source issues. [With special thanks to Martin
Gudmundsson for his support and guidance with this article.]
International Free and Open Source Software Law Review Vol. 7, Issue 1
Licence and Attribution
This paper was published in the International Free and Open Source Software Law Review, Volume 7,
Issue 1 (November 2015). It originally appeared online at http://www.ifosslr.org.
This article should be cited as follows:
Osborne, Katie (2015) 'License Profile: The Eclipse Public License version 1.0', International Free and
Open Source Software Law Review, 7(1), pp 1 – 11
DOI: 10.5033/ifosslr.v7i1.73
Copyright © 2015 Katie Osborne.
This article is licensed under a Creative Commons 4.0 licence, share, adapt, attribution, CC-BY-4.0
available at
http://creativecommons.org/licenses/by/4.0/
As a special exception, the author expressly permits faithful translations of the entire document into any
language, provided that the resulting translation (which may include an attribution to the translator) is
shared alike. This paragraph is part of the paper, and must be included when copying or translating the
paper.

VLEX uses login cookies to provide you with a better browsing experience. If you click on 'Accept' or continue browsing this site we consider that you accept our cookie policy. ACCEPT