Fact-checked by Grok 2 weeks ago

Eclipse Public License

The Eclipse Public License (EPL) is a license developed by the to govern the distribution and use of its software projects, including the and over 430 other projects (as of 2025). Approved by the (OSI) as a permissive license with elements, it grants recipients broad rights to reproduce, modify, and commercially distribute the covered code while requiring that for EPL-licensed files in derivative works be made available under the same terms. The EPL emphasizes business-friendliness by including explicit patent grants and limiting contributor liability, making it suitable for collaborative development and proprietary integrations. Originating from the Public License (IPL) in 1999 and evolving through the Common Public License (CPL), the was specifically tailored for projects and released as version 1.0 in 2004, receiving OSI approval shortly thereafter. This initial version established a weak model focused on individual files rather than entire projects, allowing unmodified binaries to be licensed separately for commercial purposes. In 2017, after a two-year community review process, the and OSI approved to address modern needs, such as enhanced international usability by removing U.S.-specific choice-of-law clauses and adding optional compatibility with the GNU General Public License (GPL) via secondary licensing. Key provisions of the EPL 2.0 include non-exclusive, worldwide, royalty-free and licenses from contributors to recipients for creating or modified works. Distributions must preserve original notices and provide access, defined to include preferred forms for scripting languages like . Unlike stronger licenses such as the GPL, the EPL permits linking with proprietary code without requiring the entire combined work to be open-sourced, though commercial distributors face indemnification obligations for claims related to their contributions. The license explicitly disclaims all warranties and limits liability to the extent permitted by law, with no obligations for support or maintenance. The 's compatibility improvements in enable projects to dual-license under the EPL and GPL or later, facilitating integration with a wider while reducing in repositories. It remains the default license for new projects, promoting a balance between open collaboration and commercial flexibility that has supported the growth of the since its inception.

Introduction

Overview

The Eclipse Public License (EPL) is a created by the to govern the use and distribution of its projects, such as the IDE. It is designed as a business-friendly weak , balancing open collaboration with commercial flexibility by applying copyleft obligations only to modified files rather than the entire . The EPL evolved from IBM's Common Public License to better suit the needs of the Eclipse community. Under the EPL, recipients are granted a non-exclusive, worldwide, royalty-free copyright license to use, reproduce, prepare derivative works, publicly display, perform, distribute, and sublicense the covered software. Core principles include the requirement to make source code available alongside any distributed object code that incorporates modifications or additions, ensuring reciprocity for changes while allowing contributors to retain copyright notices. Importantly, the license permits linking EPL-licensed code with proprietary software without obligating the disclosure of the proprietary portions, facilitating integration into closed-source products. The EPL has been approved by the (OSI) since May 2004, confirming its adherence to . It is also recognized by the (FSF) as a that is GPL-compatible under specific conditions, such as the inclusion of secondary licenses. Additionally, the EPL complies with the (DFSG), enabling its inclusion in distributions. Stewardship of the EPL is initially held by the Eclipse.org Foundation, Inc., a corporation, which manages updates and interpretations.

History

The Eclipse Public License (EPL) originated from the Common Public License (CPL) version 1.0, which developed and used to govern the initial releases of projects, including the Eclipse SDK, in the early 2000s. As the project transitioned to independent governance under the newly formed in 2004, the EPL 1.0 was created as a modified version of the CPL to better align with the Foundation's structure and principles, replacing references to with the as the steward. The transition from the CPL to EPL 1.0 began on September 9, 2004, and the EPL 1.0 was approved by the (OSI) in May 2004. Development of was motivated by the need to resolve longstanding incompatibilities with the GNU General Public License (GPL), particularly for projects requiring dual-licensing or combination with GPL-licensed code, while also modernizing terms to reflect contemporary practices. The update introduced provisions for secondary licenses, such as the GPL or later, to enable broader compatibility without requiring full relicensing of existing EPL 1.0 code. Following a community-driven review process, the Board and the OSI approved 2.0, which was published on August 24, 2017. On January 14, 2021, stewardship of the transferred from the (a , corporation) to the AISBL, a Belgian international non-profit association based in , as part of the Foundation's strategic shift to European governance to support global expansion and ecosystem growth. No subsequent versions of the have been released as of 2025, with the Foundation continuing to encourage migrations from version 1.0 to 2.0 for improved compatibility and applicability. For instance, the project, an device management solution, completed its upgrade to 2.0 in September 2023 following community discussions and relicensing approvals.

License Versions

Version 1.0

The Eclipse Public License version 1.0 ( 1.0) was released in February 2004 by the as a successor to the Common Public License, tailored specifically for Eclipse projects to balance open source collaboration with commercial interests. This version established the foundational framework for the , emphasizing contributor protections while enabling broader adoption in development tools. The license is structured into seven main sections, which systematically address core elements of licensing. Section 1 provides definitions for key terms, such as "Contribution" (initial or subsequent code additions by contributors), "Contributor" (any entity distributing the program), "Program" (the collective contributions under the agreement), and "Licensed Patents" ( claims infringed by contributions). Section 2 outlines grants of rights, including non-exclusive, royalty-free and licenses allowing , preparation of works, , , , and sublicensing. Section 3 details requirements for distributing the program, mandating that object code distributions include notices, source code availability upon request, and preservation of attributions, while also applying to modifications of individual files. Section 4 covers commercial distribution, requiring commercial contributors to indemnify recipients against third-party claims related to the program. Sections 5 and 6 include standard no-warranty and liability disclaimer clauses, stating the program is provided "" without assurances of merchantability, fitness, or non-infringement, and limiting liability for any damages. Finally, Section 7 addresses general provisions, such as termination upon litigation, governance by law, and the role of the as the initial Agreement Steward. A defining feature of EPL 1.0 is its strict weak mechanism, which applies on a per-file basis: any modifications to EPL-licensed source files must themselves be licensed under EPL 1.0 and distributed with corresponding , but the license does not extend to the entire larger work into which those files are incorporated. This file-level scope allows integration with code via linking or aggregation without triggering copyleft for the whole project, though some interpretations have debated whether certain forms of linking constitute s requiring full disclosure. However, the license's grant—limited to licensed patents necessarily infringed by contributions—creates incompatibility with the GNU General Public License (GPL), as the differing patent provisions prevent seamless combination of EPL 1.0 and GPL code into a single without dual-licensing or other workarounds. Since the introduction of EPL 2.0 in August , the has recommended migrating legacy projects from version 1.0 to the updated license to address compatibility issues and modernize terms, though EPL 1.0 remains valid and in use for existing projects not yet transitioned. The foundation explicitly deprecated EPL 1.0 for new initiatives, citing its limitations in patent handling and with other licenses as reasons for the shift. Despite this, numerous legacy Eclipse-related components and third-party software continue to rely on EPL 1.0, preserving its role in the while encouraging updates for ongoing development.

Version 2.0

The Eclipse Public License version 2.0 (EPL-2.0) was released on August 24, 2017, by the Eclipse Foundation, following approval from the Open Source Initiative and the Foundation's Board of Directors. This version introduces structural updates to enhance clarity and applicability to modern software development practices, including expanded definitions such as "Contributor Version," which refers to the Program incorporating Contributions from initial and subsequent Contributors, and "Larger Work," defined as a work that combines Covered Software or portions thereof with code not governed by the EPL-2.0 terms. The license is organized into seven primary sections—covering definitions, grants of rights, requirements, commercial distribution, warranties, liability, and general provisions—along with an Exhibit A for secondary licensing, providing a more streamlined and globally neutral framework by removing the New York-specific choice of law clause present in version 1.0. These changes, including a shift from "module" to "file" for defining the scope of Contributions, aim to align the license with contemporary community norms while clarifying language around contributions, distributions, and derivative works. Key enhancements in EPL-2.0 focus on improved compatibility and flexibility for contributors. A notable addition is the optional GPL compatibility clause in Section 1.2, which allows initial Contributors to designate the GNU General Public License version 2.0 or later (including exceptions or additional permissions) as a Secondary License, enabling the Program or specific Contributions to be dual-licensed under EPL-2.0 and GPL-2.0+ terms for broader interoperability. Patent grants have been broadened under Section 2(b) to explicitly cover Licensed Patents—those owned or controlled by a Contributor—for making, using, selling, and transferring both the original Program and Derivative Works, providing stronger protection against patent assertions in derivative contexts compared to prior versions. Additionally, Section 3.2 permits individual Contributors to apply secondary licenses to their own Contributions, such as the Apache License 2.0, as long as the core EPL-2.0 requirements are met for those portions, facilitating integration into multi-licensed projects without affecting the overall Program's EPL obligations. Under EPL-2.0's distribution rules outlined in Section 3, forms must be accompanied by the corresponding , either directly or through instructions for obtaining it, ensuring recipients can access and modify the code under the terms. Modifications to individual files containing EPL-2.0 Covered Software require those modified files to be relicensed under EPL-2.0, preserving the effect at the file level; however, merely linking or combining EPL-2.0 code into a Larger Work does not impose EPL-2.0 obligations on the non-EPL components, allowing flexible aggregation without triggering full relicensing of the entire work. EPL-2.0 is designed to be backward-compatible with 1.0 in most scenarios, enabling projects to migrate by updating headers and notices to reference the new without requiring explicit consent from all Contributors, provided any Secondary License opt-ins are appropriately designated by initial Contributors. The recommends discussing migrations on public project mailing lists and provides guidance for ensuring compliance during transitions.

Key Provisions

Copyleft Mechanism

The Eclipse Public License (EPL) employs a weak model that limits its reciprocity requirements to modifications of the licensed code itself, rather than extending obligations to larger aggregated or linked works. This approach ensures that recipients who modify and distribute EPL-covered source files must share their changes under the same license terms, promoting collaborative development while accommodating commercial integration. Unlike strong licenses such as the GNU General Public License, the EPL's scope is confined to the individual files or modules, allowing developers to combine EPL components with proprietary code without forcing the entire product to be open-sourced. Regarding derivative works, the EPL mandates that any alterations to covered files be distributed under the EPL, accompanied by the source code. A key feature preserving commercial flexibility is the EPL's treatment of linking: compiling or dynamically linking EPL-licensed code into proprietary binaries does not classify the resulting executable as a , exempting the proprietary portions from requirements. This exception facilitates the use of EPL libraries in closed-source applications, as long as the original EPL files and any user modifications to them comply with source availability rules. The EPL enforces its copyleft through conditional rights: licensees receive permissions only while adhering to the terms, with automatic termination upon material breach if not cured in a reasonable period of time after becoming aware of such noncompliance. Upon termination, all rights to use, modify, or distribute cease, though downstream recipients who obtained the code independently may retain their licenses if compliant. This mechanism deters violations while maintaining the chain of open contributions.

Compatibility Requirements

The Eclipse Public License (EPL) 1.0 exhibits significant incompatibilities with the GNU General Public License (GPL), primarily due to differences in patent termination clauses and overall licensing terms that prevent the creation of derivative works or combined modules. Specifically, the Free Software Foundation (FSF) has determined that linking EPL 1.0 code with GPL code is not permitted, as the licenses impose conflicting obligations on distribution and modification. To incorporate EPL 1.0 code into GPL-licensed projects, dual-licensing strategies are often required, such as relicensing under both EPL 1.0 and a permissive license like the BSD License, allowing users to choose compatible terms for integration. EPL 2.0 addresses many of these issues through enhancements designed to improve interoperability with other open-source licenses. A key improvement is the optional compatibility with GPL version 2.0 or later, enabled via Section 3.2's secondary license mechanism, where the initial contributor can opt in by attaching an Exhibit A notice specifying the GPL as a secondary license; this requires agreement from all copyright holders for the code to be distributed under GPL terms. Additionally, EPL 2.0 supports compatibility with permissive licenses such as Apache License 2.0 and when forming larger works, often through dual-licensing declarations in file headers using an "OR" operator, facilitating easier integration without relicensing the entire project. Under both versions of the EPL, unmodified EPL-licensed code can generally be included in proprietary software distributions, provided that the original EPL terms are preserved and source code availability notices are included where required. However, any modifications to EPL code must be licensed under the EPL and made available in source form, enforcing a file-level copyleft that applies only to the modified files rather than the entire aggregated work. This approach avoids the "viral" propagation seen in stronger copyleft licenses like the GPL, limiting reciprocity to direct derivatives. The FSF recognizes EPL 2.0 as a free software license for its freedoms but highlights the need for the secondary license opt-in to achieve full GPL compatibility, while the Open Source Initiative (OSI) has approved EPL 2.0 for its promotion of better interoperability across open-source ecosystems.

Patent and Secondary License Grants

The Eclipse Public License (EPL) provides contributors with explicit grants of rights to recipients, ensuring broad permissions for use while protecting against infringement claims. Under both versions 1.0 and 2.0, contributors grant recipients a non-exclusive, worldwide, to reproduce, prepare derivative works of, publicly display, publicly perform, distribute, and sublicense their contributions in source or form. This grant is perpetual and applies to the contributions alone or as part of the overall program, with no warranties provided and all liability disclaimed by contributors. Regarding patents, the EPL requires each contributor to grant recipients a non-exclusive, worldwide, royalty-free patent license under their "Licensed Patents"—defined as patent claims necessarily infringed by the use or sale of the contributor's contribution alone or when combined with the program. This license permits recipients to make, use, sell, offer to sell, import, and otherwise transfer the contribution, extending to combinations where the addition of the contribution causes infringement. In EPL 1.0, these patent rights terminate upon a recipient's material breach of the license if not cured within a reasonable time, or immediately if the recipient initiates patent litigation against the program. EPL 2.0 maintains similar termination conditions but clarifies that the patent grant focuses on "essential" patents tied directly to the contribution's infringement, without extending to unrelated hardware or broader combinations. A key innovation in EPL 2.0 is the provision for secondary licenses, introduced in Section 3.2 and Exhibit A, which allows the program to be distributed under additional licenses such as the GNU General Public License version 2.0 or later, provided an explicit notice is attached to the source code. This mechanism enables contributors to offer their own contributions under commercial or GPL-compatible terms without altering the EPL grants for other contributors' work, facilitating greater flexibility in dual-licensing scenarios. Unlike EPL 1.0, which permits limited separate licensing for object code distributions under Section 3 but with stricter conditions like warranty disclaimers and source code availability requirements, version 2.0 explicitly supports secondary licenses to enhance compatibility and adoption. These grants collectively support derivative works by ensuring recipients can modify and redistribute without infringing core IP rights, though full details on sharing obligations appear elsewhere.

Comparisons

With Common Public License

The Eclipse Public License version 1.0 (EPL 1.0) was directly derived from the Common Public License version 1.0 (CPL 1.0), which published in 2001 as a weak license for . While the CPL served as the initial licensing framework for the Eclipse SDK and related projects, the EPL introduced targeted revisions to better align with the needs of the emerging Eclipse ecosystem, including a shift in stewardship from to the . This change designated the as the ongoing maintainer and interpreter of the license terms, providing a more neutral, community-oriented governance structure compared to the corporate stewardship under the CPL. Key textual differences between the EPL 1.0 and CPL 1.0 emphasize clarity and reduced restrictions. The EPL simplifies the sections on contributions by streamlining the process for submitting and incorporating code, encouraging broader participation without the procedural complexities present in the CPL. Additionally, the EPL revises the language for greater clarity by deleting the first sentence of CPL Section 7, which stated that patent licenses would terminate if a recipient instituted litigation against a contributor; this removal addressed concerns that the clause was overly broad and could deter growth. Regarding termination, the EPL retains core provisions from the CPL but omits the patent litigation trigger, resulting in fewer automatic terminations and a more stable licensing environment. The transition from the CPL to the began in 2004 as a deliberate policy by the to unify licensing across its projects, with dual licensing (under both CPL and EPL) applied to ongoing releases and maintenance streams for approximately six to eight months to facilitate contributor consent. By early 2005, new development fully shifted to the EPL, and existing CPL-licensed projects were relicensed where possible, marking the CPL's retirement as an active license in favor of the EPL's more permissive framework tailored to the Eclipse community's collaborative model. This evolution positioned the EPL as the standard for the ecosystem, enhancing compatibility and adoption without further development of the CPL.

With Mozilla Public License

The Eclipse Public License (EPL) and (MPL) are both classified as weak licenses, meaning they require modifications to the licensed code to be shared under the same license terms, but they do not impose obligations on the entire larger work or project into which the code is incorporated. This file-level or module-level approach allows developers to link EPL- or MPL-licensed code with without forcing the proprietary portions to be open-sourced, promoting flexibility in mixed-source environments. A key difference lies in their mechanisms for compatibility with stronger copyleft licenses like the GNU General Public License (GPL). The MPL 2.0 includes an explicit compatibility addendum in Section 3.3, enabling code to be distributed under secondary licenses such as GPL 2.0, LGPL 2.1, or AGPL 3.0, provided the code is not marked as "Incompatible With Secondary Licenses" in its ; this facilitates seamless integration with GPL-family projects without additional steps. In contrast, the EPL 2.0 achieves GPL compatibility through an opt-in secondary license mechanism (defined in Section 1.12 as GPL 2.0 or later, including exceptions), which requires the copyright holder to explicitly include a notice in the copyright header to enable relicensing under GPL terms for combinations with GPL-licensed code. The EPL 2.0 emphasizes this secondary licensing to address prior incompatibilities with GPL, but it limits options to GPL 2.0 variants only, unlike the broader secondary license support in MPL 2.0. Regarding scope, the EPL 2.0 provides a broader for handling contributions within larger works by defining "Contributions" to include initial content and subsequent changes or additions (Section 1), with applying to "Executable Form" distributions that must accompany availability notices (Section 3.2); this encourages reciprocity for modifications while permitting aggregation into larger works. The MPL 2.0, however, is more narrowly scoped to "Covered Software" and "Modifications" at the level (Sections 1.1 and 3.1), explicitly clarifying that use—such as providing functionality over the —does not constitute and thus avoids triggers ( Q17). Additionally, the MPL 2.0 lacks the EPL 2.0's explicit legal protections for contributors, such as requirements for distributors to indemnify contributors against claims related to licensed patents (EPL Section 7). The MPL 2.0 also addresses trademarks more directly by not granting any rights beyond the licensed software, emphasizing compliance with existing notices (Section 2.3). In terms of usage context, the was specifically designed for the Foundation's ecosystem, with a focus on Java-based tools and collaborative development in integrated development environments (), reflecting its origins in the Common Public License for projects. The MPL, conversely, was crafted for Mozilla's browser and web technology projects, such as , prioritizing ease of contribution in dynamic, cross-platform environments while accommodating network-centric applications.

Adoption

Notable Solely EPL-Licensed Projects

The Eclipse Integrated Development Environment (IDE) stands as the flagship project licensed exclusively under the Eclipse Public License (EPL), with its core platform adopting the license since 2004. This extensible tool supports development in Java and over 30 other languages, enabling plugin-based customization and collaborative workflows through the Eclipse Foundation's ecosystem. Its widespread use in enterprise and open-source settings underscores the EPL's role in promoting modular, business-compatible software development. JUnit 5, a prominent framework for , adopted the 2.0 exclusively in 2017 to enhance compatibility with diverse open-source licenses while preserving its focus on expressive and efficient test authoring. As one of the first major projects to transition to this version, it has facilitated seamless integration in large-scale applications, amassing millions of downloads and contributions from a global community. hawkBit serves as a domain-independent backend for managing software updates in environments, particularly for constrained edge devices, and migrated exclusively to the 2.0 in 2023 to align with modern licensing practices. This update server supports scalable deployment scenarios in industrial and consumer , demonstrating the EPL's applicability to embedded systems development. The Plug-in Development Environment (PDE), an integral project, provides comprehensive tooling for building, testing, and debugging Eclipse plugins and features, licensed solely under the 2.0. It empowers developers to extend the platform, contributing to the ecosystem's richness and longevity. These projects illustrate the EPL's suitability for collaborative development in non-GPL ecosystems, leveraging its weak provisions to balance source availability with commercial flexibility and .

Notable Multi-Licensed Projects

One prominent example of multi-licensing involving the Eclipse Public License (EPL) is JRuby, an implementation of the Ruby programming language on the Java Virtual Machine. JRuby has been released under a tri-license since 2013, allowing users to choose between the Eclipse Public License (currently version 2.0), the GNU General Public License version 2.0, or the GNU Lesser General Public License version 2.1, facilitating compatibility with GPL-licensed projects while enabling broader adoption in Java ecosystems. Many top-level projects employ dual licensing under the and the Eclipse Distribution License (EDL), a permissive BSD-like license, to enhance reusability. For instance, components in projects such as Californium, a CoAP for IoT applications, are available under both EPL 2.0 and EDL 1.0, allowing integration into diverse environments without the stricter requirements of the EPL alone. This approach has been recommended by the for non-core code like examples and documentation since 2009, promoting wider community contributions and commercial use. The benefits of such multi-licensing strategies include improved with other open-source licenses and support for extensions. EPL-EDL licensing enables seamless mixing with GPL in collaborative projects, while the EPL's patent grants provide legal protections for contributors. A key application is facilitating contributions to projects; since 2017, projects like —a high-performance originally donated by —have utilized EPL 2.0's secondary license option for 2.0 compatibility, allowing from repositories to be relicensed and integrated into ecosystems without compatibility conflicts. Trends indicate growing adoption of EPL 2.0's secondary licensing mechanism for Apache 2.0 compatibility, particularly in enterprise-focused projects from onward. This feature, introduced in 2017 to address prior incompatibilities, has enabled hybrid models in JVM-related initiatives and frameworks, reflecting a shift toward flexible licensing that balances principles with permissive reuse in cloud-native and distributed systems.

References

  1. [1]
    Eclipse Public License 2.0 (EPL) | The Eclipse Foundation
    Eclipse Public License - v 2.0 · 1. DEFINITIONS · 2. GRANT OF RIGHTS · 3. REQUIREMENTS · 4. COMMERCIAL DISTRIBUTION · 5. NO WARRANTY · 6. DISCLAIMER OF LIABILITY · 7.
  2. [2]
    Eclipse Public License version 2.0 - Open Source Initiative
    Jun 15, 2017 · a) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license ...
  3. [3]
    EPL-2.0 FAQ | The Eclipse Foundation
    This FAQ attempts to provide answers to commonly asked questions related to the Eclipse Public License (EPL). It is provided for informational purposes only.
  4. [4]
    Eclipse Public License 1.0 (EPL) Frequently Asked Questions
    The EPL is an OSI-approved open source license and may be used unaltered by projects regardless of where they are hosted. Many Eclipse tools and wizards use ...
  5. [5]
    Eclipse Public License Version 2.0 Approved By OSI and Eclipse ...
    Aug 29, 2017 · The new EPL v2 is the result of a two year community process to identify and implement improvements to the existing EPL v1 license.
  6. [6]
    DFSGLicenses - Debian Wiki
    Oct 19, 2024 · This page lists licenses for Debian packages to help determine if they meet the Debian Free Software Guidelines (DFSG). It includes DFSG- ...
  7. [7]
    Eclipse Public License 1.0 | Software Package Data Exchange (SPDX)
    The Eclipse Foundation is the initial Agreement Steward. The Eclipse Foundation may assign the responsibility to serve as the Agreement Steward to a suitable ...Missing: stewardship | Show results with:stewardship
  8. [8]
    CPL to EPL Conversion | The Eclipse Foundation
    The Eclipse Public License is an OSI-approved open source license. The Eclipse Foundation began the transition from the CPL to the EPL on September 9th, 2004.
  9. [9]
    Open Source Software Leader the Eclipse Foundation Officially ...
    Jan 14, 2021 · Leading open source foundation forms AISBL based in Brussels to serve as its global base of operations.Missing: stewardship | Show results with:stewardship
  10. [10]
    An update on the Eclipse Foundation's move to Europe
    Aug 20, 2020 · As part of moving to European-based governance, effective October 1st we will be restating our membership dues for both the Belgian-based ...Missing: EPL January
  11. [11]
    Eclipse hawkBit upgrade to Eclipse Public License - v 2.0
    In this article, we want to give an overview of the latest highlights of hawkBit license changes. hawkBit license upgraded to Eclipse Public License - v 2.0.Missing: 2022 | Show results with:2022
  12. [12]
    Switch to EPL 2.0 License · Issue #1393 · eclipse-hawkbit ... - GitHub
    Jul 13, 2023 · It would be good to switch to the newer EPL version 2.0. Some clarification about how to could be found at How Do I Re-license from EPL-1.0 ...Missing: migrations 2022-2023
  13. [13]
    For Approval: Eclipse Public License - v 1.0
    Mar 8, 2004 · When Eclipse evolved into the Eclipse Foundation in February 2004 ... Eclipse Public License v 1.0 (EPL). The EPL is based entirely on the ...
  14. [14]
    Eclipse Public License - Version 1.0
    The license grants non-exclusive, royalty-free copyright and patent licenses, but no assurances of non-infringement are provided. The program is provided "as ...
  15. [15]
    Open Source Software Licenses 101: The Eclipse Public License
    Nov 2, 2021 · An overview of the Eclipse Public License, its key provisions, and its compatibility with other licenses.
  16. [16]
    Various Licenses and Comments about Them - GNU Project
    ... FSF approval. ... However, it gives recipients ways to relicense the work under the terms of other selected licenses, and some of those—the Eclipse Public License ...Software Licenses · Licenses For Documentation · Licenses for Other Works
  17. [17]
    Eclipse Foundation Renews the Eclipse Public License - InfoQ
    Sep 16, 2017 · It is expected that projects that currently use EPLv1, particularly those under the Eclipse Foundation, will gradually migrate to EPLv2; some ...Missing: recommends 1.0 2.0
  18. [18]
    EPL-1.0.txt - Eclipse Foundation
    Eclipse Public License - v 1.0 THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION ...
  19. [19]
    EPL-2.0 - Eclipse Foundation
    Eclipse Public License - v 2.0 THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR ...
  20. [20]
    https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt
  21. [21]
    Eclipse Public License version 2.0 added to license list
    Oct 17, 2017 · We recently updated our list of various licenses and comments about them to include the Eclipse Public License version 2.0 (EPL).
  22. [22]
    https://www.fsf.org/blogs/licensing/eclipse-public-license-version-2-0-added-to-license-list-1
  23. [23]
    https://www.gnu.org/licenses/license-list.en.html#EPL2
  24. [24]
    [PDF] CPL to EPL Transition Plan - Eclipse Foundation
    Sep 2, 2004 · The Eclipse Foundation has made a policy decision to switch from the Common Public. License (“CPL”) to the Eclipse Public License (“EPL”) ...<|control11|><|separator|>
  25. [25]
    Mozilla Public License, version 2.0
    Distributing Source Code Form that is Incompatible With Secondary Licenses. If You choose to distribute Source Code Form that is Incompatible With Secondary ...
  26. [26]
    OSS Licenses part 5: Weak copyleft licenses - Debricked
    Jul 9, 2024 · The Eclipse Public License (EPL) is another weak copyleft license. It is a successor to the Common Public License (CPL) and is very similar to ...
  27. [27]
    MPL 2.0 FAQ - Mozilla
    Jan 30, 2024 · The MPL is a simple copyleft license. The MPL's "file-level" copyleft is designed to encourage contributors to share modifications they make to ...Missing: comparison | Show results with:comparison
  28. [28]
    Eclipse IDE | The Eclipse Foundation
    Free and open source released under the terms of the Eclipse Public License 2.0. Improved Plug-in Development Tooling. Improved JUnit Plugin-test launches with ...Eclipse IDE · Eclipse Platform · Working Group · ProjectsMissing: EPL | Show results with:EPL
  29. [29]
    Eclipse PDE - GitHub
    Before your contribution can be accepted by the project, you need to create and electronically sign the Eclipse Foundation Contributor License Agreement (CLA).
  30. [30]
    Eclipse PDE | projects.eclipse.org
    The Eclipse PDE provides tools to create, develop, test, debug, build and deploy Eclipse plug-ins, fragments, features, update sites and RCP products.
  31. [31]
    https://projects.eclipse.org/projects/eclipse.pde
  32. [32]
    jruby/jruby: JRuby, an implementation of Ruby on the JVM - GitHub
    License. JRuby is licensed under a tri EPL/GPL/LGPL license. You can use it, redistribute it and/or modify it under the terms of the: Eclipse Public License ...
  33. [33]
    JRuby 1.4.0 Released
    Nov 2, 2009 · After three very helpful release candidates we have a final 1.4.0 release. This release ends a long release cycle in which we resolved a huge ...
  34. [34]
    Eclipse Californium™
    Californium (Cf) is dual-licensed under EPL and EDL. The latter is a BSD-like license, which means the Cf CoAP framework can be used together with ...
  35. [35]
    Eclipse OpenJ9 | projects.eclipse.org
    The JVM, formally known as the J9 virtual machine, was donated to the Eclipse Foundation by IBM, who continue their development activities in the open.
  36. [36]
    Top 10 open source legal stories that shook 2017 | Opensource.com
    Feb 27, 2018 · The Eclipse Foundation intends EPL 2.0 to be the default license for Eclipse community projects. ... EPL 1.0, which has been removed in EPL 2.0.
  37. [37]
    Some New License Flexibility | Life at Eclipse
    May 21, 2009 · So here is some good news: Projects can license their example code using the Eclipse Distribution License (EDL) as well as the EPL. The ...