弱著佐权(Weak Copyleft)

Eclipse Public License 2.0

EPL 代码及其修改部分必须公开,但作为独立模块编写的代码可以使用商业许可证,是对企业友好的弱著佐权。

SPDXEPL-2.0

许可·条件·限制一览

许可

  • 商业使用原作品及衍生作品可用于商业目的。
  • 分发可以分发代码。
  • 修改可以修改代码。
  • 专利使用贡献者明确授予专利使用权。
  • 私人使用可以在内部使用和修改而不公开。

条件

  • 公开源代码分发时必须提供源代码。
  • 版权与许可声明分发时必须附上许可证副本和版权声明。
  • 相同许可证分发修改版或衍生作品时,必须使用相同(或兼容)的许可证。

限制

  • 责任限制明确声明不对损害承担责任。
  • 无担保明确声明不提供任何担保。

许可·条件·限制分类来源:choosealicense.com(GitHub,MIT 许可证)数据。

这是什么样的许可证

EPL 2.0 由 Eclipse 基金会于 2017 年 8 月发布。Eclipse IDE、Jakarta EE 以及多个 Eclipse 基金会项目都在使用。分发适用 EPL 的程序及其修改部分(「Contribution」)时须公开源代码,但分离为独立模块、且并非衍生自 EPL 代码的代码可以按其他许可证(包括商业许可证)分发。它包含明确的专利许可,以及有人声称该程序侵犯专利并提起诉讼时终止其专利许可的条款。

与 EPL-1.0 相比的变化

分发时须遵守的事项

常见误解

如何应用

将原文放在 LICENSE 中,如有需要,再为每个文件加上 Exhibit A 格式的 Secondary License 声明。EPL 没有像 GNU、Apache 那样规定的文件头文字,因此建议使用 SPDX 标识符 EPL-2.0 的文件头(将 GPL-2.0 指定为 Secondary License 时,SPDX 表达式有时写作 EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0)。

适用场景

适合希望平台或框架的核心保持公开、同时允许其上的扩展模块作为商业产品销售的企业主导型生态。以文件为单位、更简单的替代方案是 MPL-2.0

EPL-2.0 代码能放进其他项目吗?

以下是将以此许可证发布的代码合并到下列许可证的项目中一起发布时的一般判定。 在兼容性检查器中查看其他组合 →

目标项目判定备注
专有(商业)软件 有条件可以EPL 代码及其修改部分须保持 EPL-2.0 并提供源代码。分离为独立模块的自有代码可以使用其他许可证。
MIT 有条件可以EPL 代码及其修改部分须保持 EPL-2.0 并提供源代码。分离为独立模块的自有代码可以使用其他许可证。
Apache-2.0 有条件可以EPL 代码及其修改部分须保持 EPL-2.0 并提供源代码。分离为独立模块的自有代码可以使用其他许可证。
MPL-2.0 有条件可以EPL 代码及其修改部分须保持 EPL-2.0 并提供源代码。分离为独立模块的自有代码可以使用其他许可证。
LGPL-2.1 有条件可以只有在原作者通过 Exhibit A 将 GPL 等指定为 Secondary License 时,才能合并并按 GNU 许可证发布。未指定则不兼容。
LGPL-3.0 有条件可以只有在原作者通过 Exhibit A 将 GPL 等指定为 Secondary License 时,才能合并并按 GNU 许可证发布。未指定则不兼容。
GPL-2.0 有条件可以只有在原作者通过 Exhibit A 将 GPL 等指定为 Secondary License 时,才能合并并按 GNU 许可证发布。未指定则不兼容。
GPL-3.0 有条件可以只有在原作者通过 Exhibit A 将 GPL 等指定为 Secondary License 时,才能合并并按 GNU 许可证发布。未指定则不兼容。
AGPL-3.0 有条件可以只有在原作者通过 Exhibit A 将 GPL 等指定为 Secondary License 时,才能合并并按 GNU 许可证发布。未指定则不兼容。

本网站内容仅为一般信息,不构成法律意见。实际发布、合同或纠纷的判断,请咨询律师等专业人士。