License Profile: The Eclipse Public License
Katie Osbornea
DOI: 10.5033/ifosslr.v7i1.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. 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. Furthermore, the EPL was the default license for the Symbian mobile operating system stewarded by Symbian Foundation, now transitioned to a licensing-only organisation. 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 License Top 20 Rank published by Black Duck Software, Inc.
The EPL is derived from the Common Public License version 1.0 (“CPL”), which was published by IBM. 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. 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.
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”), GNU Lesser General Public License (“LGPL”) and Mozilla Public License (“MPL), 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 license 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, BSD license or MIT license.
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. 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 and 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. “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 EPL. This is addressed in Section 2.5 below. It should be noted that the term “Contribution” includes not only software code, but also documentation. This is different from many other open source licenses that cover solely software.
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 License 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 called the direct licensing model of open source software. 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 contains 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 each “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 mere 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 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.
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. 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 limitation, 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. 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 certain 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 reciprocity 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 distributed by” the particular Contributor. Changes and additions 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 also 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 certainly 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 conjunctive – a software addition placed in a separate 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 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. 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 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 any 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 agreement 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.
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 exactly 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 claims or losses related to intellectual property infringement.
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 clarifies that if a third party patent license is required 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 terminated. 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 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”), 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 year after the cause arose”. Note that the one year period begins to run when the claim arose, not when the potential claimant became 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. Further, the foundation states that EPL and GPL code may not be combined in any scenario where source code governed by 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.
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 components 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)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. 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.
About the author
Katie Osborne 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.]
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.