每隔一段时间，社区就流行产品中的有争议的开源许可引起轩然大波会成为头条新闻，导致我们所有人争论开源许可的真正含义。去年，是 Apache 基金会禁止使用 Facebook React 有争议的专利条款的组件，这引起了轰动，促使开发人员竞选 Reddit 板。在过去的几个月里，Redis Labs 和 MongoDB 对其一些最受欢迎的开源数据库的开源许可证进行了更改，这让许多人摸不着头脑，强调需要用人类语言解释开源许可证。
内容
- 基础知识：什么是开源许可证？
- Copyleft 和 Permissive：解释了两种类型的开源许可证
- 备忘单：顶级开源许可证解释
- GNU General Public License (GPL)
- The Apache License
- Microsoft Public Licenses (Ms-PL)
- Berkeley Software Distribution (BSD)
- Common Development and Distribution License (CDDL)
- Eclipse Public License (EPL)
- MIT License
- 了解您的开源许可证，或向法官解释
基础知识：什么是开源许可证？
最简单的解释是，开源许可证是软件组件的作者和用户之间的合法且具有约束力的合同，声明该软件可以在特定条件下用于商业应用程序。 许可证是将代码变成开源组件的原因。 如果没有开源许可证，即使已在 GitHub 上公开发布，其他人也无法使用该软件组件。
每个开源许可证都说明了允许用户对软件组件执行的操作、他们的义务以及根据条款和条件他们不能执行的操作。 这听起来可能很简单，但是那里有 200 多个开源许可证，所以祝你好运，让它们井井有条。 复杂性和要求各不相同，由组织决定哪些许可证与其策略最兼容，以确保它们保持合规性。
Copyleft 和 Permissive：解释了两种类型的开源许可证
开源许可证的两大类通常需要深入解释。开源许可证可以分为两大类：copyleft 和 permissive。此划分基于许可证对用户的要求和限制。
版权是一项限制未经版权所有者许可使用、修改和分享创意作品的权利的法律。想想属于其创作者知识产权的音乐、电影等。当作者在 copyleft 许可下发布程序时，他们对作品的版权提出主张，并声明其他人有权使用、修改和共享该作品，只要维护义务的互惠性.简而言之，如果他们使用具有这种开源许可证的组件，那么他们也必须将他们的代码也开放给其他人使用。
许可型开源许可证是一种非 Copyleft 开源许可证，它保证使用、修改和重新分发的自由，同时也允许专有的衍生作品。宽松的开源许可证，被亲切地称为“Anything Goes”，对其他人如何使用开源组件的限制最小。这意味着这种类型的许可允许不同程度的自由使用、修改和重新分发开源代码，允许其在专有衍生作品中使用，并且在未来的义务方面几乎不需要任何回报。
重要的是要注意没有好或坏的许可证，并且没有一个许可证比另一个更好。任何人都可以创建适合自己的开源许可证，这就是有这么多的原因。这可能会使选择开源许可证变得复杂，特别是对于我们这些不精通法律并且从未彻底解释过开源许可证的人来说。为了帮助缩小决策范围并理解这一切，OSI 整理了一份已批准许可证的列表，其中包含 80 多个最常用的开源许可证。
在 OSI 批准列表中的数十个开源许可证中，有一些是至高无上的，并被一些最流行的开源项目使用。
GNU 通用公共许可证 (GPL)
GNU 的通用公共许可证是最流行的开源许可证。 Richard Stallman 创建了 GPL 来保护 GNU 软件不被私有化，这是他的“copyleft”概念的具体实现。
GPL 是 Copyleft 许可证。这意味着基于任何 GPL 组件编写的任何软件都必须作为开源发布。结果是任何使用任何 GPL 开源组件的软件（无论其在整个代码中的百分比如何）都需要发布其完整源代码以及修改和分发整个代码的所有权利。
关于什么构成“基于”另一部作品的作品一直存在一些混淆，这反过来又触发了 GPL 互惠义务。 FSF 试图在 GPLv3 中更清楚地说明何时触发互惠义务。 FSF 甚至编写了一个新的 GPL 许可证，即 Affero 许可证，以解决被称为“ASP 漏洞”的特定混淆。
此外，FSF 试图增加 GPLv3 与其他许可证的兼容性。要将两个代码组合成一个更大的作品，两个程序都必须允许它。如果两个程序的许可证都授予了此类权利，则它们是兼容的。通过使 GPLv3 更加兼容，FSF 扩展了开发选项。
两个版本之间的第三个区别是 GPLv3 是为了增加全球使用率而编写的。修改了 GPLv3 中用于描述许可权的语言，以确保国际法将其解释为 FSF 的意图，这与 GPLv2 中使用的语言不同，后者被认为非常以美国为中心。 GPLv3 还允许开发人员添加本地免责声明，这也有助于增加其在美国以外的使用率。
The Apache License
Apache 许可证是由 Apache 软件基金会 (ASF) 发布的开源软件许可证。这是一个流行且广泛部署的许可证，由强大的社区支持。 Apache 许可证允许您自由使用、修改和分发任何 Apache 许可产品。但是，在这样做时，您需要遵守 Apache 许可证的条款。
Apache 集团（后来更名为 Apache 软件基金会）于 1995 年发布了其许可证的第一个版本，但您很少会遇到仍然带有此许可证的组件。
2000 年，当伯克利接受自由软件基金会提出的论点并从 BSD 许可证中退出广告条款并形成修改后的 BSD 许可证时，Apache 也这样做并创建了 Apache 许可证版本 1.1。
删除广告条款意味着任何 Apache 许可产品的衍生作品的广告材料不再需要包含 Apache 许可归属。仅在文档中包含归属就可以了。
2004 年，ASF 决定更彻底地脱离 BSD 模型，并通过授予专利权并定义其使用的概念的可靠定义以使其更加连贯，产生了 Apache 许可证 2.0 版。
回答的 10 大 Apache 许可证问题
Microsoft 公共许可证 (Ms-PL)
Microsoft 公共许可证是 Microsoft 发布的免费和开源软件许可证，它是为其作为开源发布的项目编写的。
您可以自由复制和分发根据 Ms-PL 许可许可的任何软件的原始或衍生作品。但是，当您这样做时，您不得使用任何贡献者的名称、徽标或商标。 Ms-PL 通过明确不为使用您的代码提供任何明示保证或保证来保护作者，因此如果代码在某些情况下无法正常运行，作者不承担任何责任。
当您在 Ms-PL 下分发软件（或其部分）时，您不需要分发其源代码。如果您愿意，您可以这样做，但您没有义务这样做。但是，您需要保留软件中最初存在的所有版权、专利、商标和归属声明。
此外，如果您以源代码形式分发软件的任何部分，您只能在 Ms-PL 下执行此操作，方法是在您的分发中包含此许可证的完整副本。如果您以编译或目标代码形式分发软件的任何部分，您只能在符合 Ms-PL 的任何其他许可下这样做。
重要的是要注意，Ms-PL 条款和条件文档非常简短、简洁，并以非常连贯的语言编写。微软希望与开源社区保持非常清晰和直接的关系，这也有助于提高采用率（正如我们从 BSD 许可证中知道的那样）。
伯克利软件分发 (BSD)
BSD 许可证或原始 BSD 许可证及其两个变体——修改后的 BSD 许可证（3 条款）和简化的 BSD 许可证/FreeBSD 许可证（2 条款）是一系列宽松的自由软件许可证。
只要您保留版权声明、条件列表和免责声明的副本，BSD 许可证允许您以源代码或二进制格式自由修改和分发您的软件代码。
原始 BSD 许可证或 4 条款 BSD 许可证还包含广告条款和非认可条款（有关这些条款的详细说明在以下问题中提供）。修改后的 BSD 许可证或 3 条款 BSD 许可证是通过从原始 BSD 许可证中删除广告条款而形成的。此外，FreeBSD 版本或 2 条款 BSD 许可证是通过从修改后的 BSD 许可证或 3 条款 BSD 许可证中删除非认可条款而形成的。
通用开发和分发许可证 (CDDL)
CDDL 是由 Sun Microsystems 发布的开源许可证，用于替代 Sun Public License (SPL)。 Sun（现在的 Oracle）认为 CDDL 许可证是 SPL 版本 2。它的灵感来自 Mozilla 公共许可证 (MPL)。在 2004 年转而依赖 CDDL 之前，Sun 曾经在其 Sun 公共许可证 (SPL) 下发布其自由软件/开源项目。CDDL 通常被称为 MPL 的清理版本，旨在促进可重用性。
您可以自由复制和分发根据 CDDL 许可的任何软件的任何原始或衍生作品。但是，您不得删除或更改软件中包含的任何版权、专利或商标声明。您还必须保留任何许可通知或任何归属于任何贡献者或初始开发者的描述性文本。
当您以可执行形式（源代码以外的任何形式）分发您的软件时，您需要在 CDDL 下提供源代码。可执行形式可以在 CDDL 或任何与 CDDL 兼容的许可下发布。
您必须提供的源代码包括您的贡献，只要它们是对包含原始软件的文件或包含原始程序部分的新文件内容的添加、删除或修改。这意味着，如果您的添加是在不包含原始代码的单独且独立的文件中进行的，则您不必在 CDDL 下发布它。如果您愿意，您可以这样做，但您没有义务这样做。
此外，您必须在分发的任何源代码中包含一份 CDDL 副本。对于您所做的每项修改，您必须通过在修改后的文件中包含通知来将自己标识为修改者。
Eclipse 公共许可证 (EPL)
Eclipse 公共许可证 (EPL) 是由 Eclipse 基金会开发的开源许可证。它源自通用公共许可证 (CPL)。现在在 EPL 下可用的 Eclipse 代码库以前是在 CPL 下获得许可的。
EPL 许可证是一个 copyleft 许可证。如果您修改了 EPL 的组件并将其作为程序的一部分以源代码形式分发，则您需要在 EPL 下披露修改后的代码。如果您以目标代码形式分发此类程序，您需要声明源代码可以根据要求提供给接收者。您还需要共享请求源代码的方法。
Eclipse 基金会明确表示，在他们看来，“仅仅与 Eclipse 插件进行接口或互操作”并不能使您的代码成为插件的衍生作品。
如果您重新分发带有 EPL 组件的程序，您有义务提供完整的许可文本和版权。
如果公司在商业产品中使用他/她的组件，EPL 保护作者免受可能的诉讼或损害。它还提供专利授权。
麻省理工学院许可证（MIT)
麻省理工学院在 80 年代后期创建的 MIT 许可证是最宽松的自由软件许可证之一。基本上，您可以使用根据 MIT 许可许可的软件做任何您想做的事情——只要您添加原始 MIT 许可和版权声明的副本即可。 MIT 许可证非常简单、简短且中肯，这就是为什么它在开发人员中具有如此高的采用率，尽管有些人避免使用它，因为它没有明确授予专利权。商业组织通常更喜欢它，因为它具有“无附加条件”的性质。
了解您的开源许可证，或向法官解释
如果您已经走到了这一步，那么您就会知道开源许可证不适合胆小的人。
然而，考虑到几乎所有软件开发人员都严重依赖开源组件这一事实，了解开源许可的基础知识以及流行的开源许可之间的主要区别至关重要。
我们只希望这种解释使潜在的许可证雷区更易于导航。
原文：https://www.whitesourcesoftware.com/resources/blog/open-source-licenses…