如果你是一名当今的软件开发者，你肯定知道如何使用开源软件，但是你是否了解开源许可的起源以及原因？ 了解一些背景知识将帮助你理解 许可证 的工作方式以及原因。
开源许可的起源
今天的技术人员，在 Microsoft Windows 和专有软件的时代成长起来，可能认为开源许可是一种始于 20 世纪 90 年代的最新趋势。 尽管开源许可在过去二十年中迅速普及，但事实上，开源是软件许可的原始模型，专有许可出现得更晚。
事实上，软件许可的两种模型（开源和专有）都源于一个共同的来源：Unix 操作系统。 Unix 由 AT&T 贝尔实验室于 20 世纪 60 年代末和 70 年代初开发，是第一个通用操作系统。 当时，AT&T 的市场地位非常 dominant，以至于美国司法部发布了一项同意法令，禁止 AT&T 从事其电话服务领域以外的商业活动，而电话服务是 AT&T 的主要业务。 由于同意法令，AT&T 无法将 Unix 作为商业产品进行开发，因此贝尔实验室以源代码形式免费赠送 Unix，条款允许对其进行修改和再分发。 这导致了 Unix 在 20 世纪 70 年代和 80 年代在计算机科学家中的广泛使用和普及。
在美国司法部于 1983 年取消同意法令后，AT&T 转而将 Unix 商业化为专有产品，并采用了更严格的许可条款，只允许以目标代码格式重新分发 Unix。 与此同时，20 世纪 80 年代出现了微型计算机（PC），这导致了软件的标准化。 反过来，这种标准化鼓励公司以仅二进制形式分发其软件，因为用户不太需要调查或排除源代码故障。 因此，专有许可成为软件许可的主导模型。
随着 Linux 操作系统在 20 世纪 90 年代的开发，人们对开源许可的兴趣重新燃起。 自 UNIX 私有化以来，对一种可以自由替代 UNIX 的操作系统的需求激增。 为了有用，该操作系统既需要操作系统内核，也需要安装、运行和开发程序所需的工具。 Linus Torvalds，一位芬兰青少年，开发了第一个 Linux 内核作为学校项目。 与此同时，GNU 项目已经成立来开发这些工具，当这两个部分结合在一起时，就可以免费替代 UNIX 了。 组合后的操作系统（通常称为 Linux）是在 GNU 通用公共许可证 (GPL) 下发布的，该许可模式是由 GNU 项目 的 Richard Stallman 创建的。 GPL 授予接收者不受限制地重新分发软件的权利，但前提是源代码不能保密。 随着 Linux 的普及，拥有数千名贡献者和数十亿用户，业界学会了遵循和采用 GPL 的条款。 到 20 世纪 90 年代末，GPL 和更广泛的开源许可模式获得了广泛的认可和行业范围内的接受。 在 2010 年代，它在技术行业的重要性几乎超过了专有许可证。
开源许可证的类型
如今，Stallman 开创的 GPL 许可证已发展到第三版 (GNU GPLv3)，并且只是几十种开源许可证中的一种。 开放源代码促进会，一个成立于 1998 年旨在推广开源软件并规范该术语使用的组织，已经批准了超过 80 个 开源许可证。 这 80 个许可证通常分为两类：宽松许可证和著佐权许可证。
宽松许可证很简单，是开源许可证最基本的类型：它允许你对软件做任何你想做的事情，只要你遵守通知要求即可。 宽松许可证按原样提供软件，不提供任何保证。 因此，宽松许可证可以总结如下
- 对代码做任何你想做的事情
- 风险自负
- 感谢作者/贡献者
著佐权许可证在宽松许可证中增加了要求。 除了上面列出的要求外，著佐权许可证还要求
- 如果你分发二进制文件，你必须提供这些二进制文件的源代码
- 源代码必须在与你获得代码时相同的著佐权条款下提供
- 你不能对被许可人行使许可权施加额外的限制
下表根据宽松和著佐权框架对流行的开源许可证进行分类。 著佐权许可证也按强度升序列出，从顶部最强到底部最弱。 “强度”指的是周围软件可能需要服从相同著佐权要求的程度。 例如，GPL 很强，因为它要求任何包含 GPL 代码的程序必须只包含 GPL 代码。 LGPL 较弱，因为它允许与其他专有代码进行动态链接，而无需使链接的代码受到相同的 GPL 要求。 最弱的著佐权许可证 EPL 和 MPL 允许与任何其他代码进行任何类型的集成，只要 EPL 或 MPL 代码位于其自己的文件中即可。
|
宽松许可证 |
著佐权许可证 |
|
|
顶级开源问题
当我为客户提供有关开源许可的建议时，他们问的四个最常见的问题是
- 什么是“分发”？
- 开源许可证如何影响软件中的专利权？
- 什么是“通知”要求以及我如何遵守？
- 什么是“衍生作品”，并且，相关地，将 GPL 代码合并到我的专有代码中是否会导致专有代码在 GPL 下获得许可？
这些问题的简短答案如下
- 什么是“分发”？ 简而言之，分发是指将受版权保护的作品（例如软件）的副本从一个法人转移到另一个法人。 分发的概念很重要，因为只有在分发软件时才会触发开源许可证的要求。 因此，不分发软件的人不会违反开源许可证的条款。 并且由于“法人”包括公司，因此如果在同一公司的员工之间仅仅转移软件，则不存在分发，因此不存在违反许可证条款的风险。
如今，对于通过互联网、云或 SaaS 模型部署软件的企业而言，分发可能是一个更棘手的问题。 允许用户通过互联网与软件应用程序交互是否算作分发？ 对于大多数开源许可证，答案是否定的。 事实上，GPLv3 使用术语“convey”而不是“distribute”，正是为了明确 SaaS 的使用不会触发任何许可要求。 但是 Affero GPL (AGPL) 许可证是一个例外，它采用了不同的方法。 一旦软件被修改并可以在网络上使用和交互，AGPL 的要求（与 GPL 相同）就会被触发。
- 开源许可证如何影响软件中的专利权？ 一些开源许可证（例如，Apache 2、GPLv3）包括明确的专利许可条款，这些条款授予接收者任何涵盖该软件产品的专利许可。 其他开源许可证（例如，BSD、MIT、GPLv2）对专利许可保持沉默。 尽管如此，对于这些许可证，法院可以使用“默示许可”原则来认定接收者仍然获得许可，并且受到因使用许可的软件产品而引起的任何专利侵权指控的保护。 通过这样做，法院可以防止许可人“咬两口苹果”，并对使用他们已经许可的软件提起专利侵权诉讼。 总之，除非另有明确说明，否则开源许可证限制了作者起诉遵守许可协议的接收者涉嫌专利侵权的能力。
- 什么是“通知”要求以及我如何遵守？ 通知要求意味着开源软件的分发者必须告知接收者，正在交付给接收者的软件中包含某些根据通知许可证提供的开源软件。 每个开源许可证都有其自己特定的通知要求。 通常，这些要求包括提供适用许可证的完整副本以及感谢作者和贡献者。 最佳做法是预先交付许可证涵盖的源代码，因为许可证的完整副本通常作为文本文件包含在源代码包中。 另一个最佳做法是遵循 GPL 的通知要求，因为它们被认为是其中最严格的。 因此，遵守 GPL 的通知要求通常可以确保遵守其他适用的开源许可证的通知要求。
- 衍生作品与GPL病毒式传播的迷思： 客户普遍担心，将GPL（或类似的Copyleft许可证）许可的代码整合到他们的专有代码中，会导致专有代码被“感染”或“污染”，从而也必须以GPL许可（即，专有代码实际上被转换为GPL代码）或强制进入公共领域。 这种担忧使一些人将GPL视为具有病毒式传播特性，并阻止他们使用GPL代码，因为他们担心任何包含GPL代码的衍生作品也将以GPL许可。
这些担忧很大程度上是没有根据的。 确实，根据GPL，单个程序中的所有代码必须要么都遵守GPL，要么都不遵守GPL。 因此，如果开发人员将GPL代码与专有代码组合并重新分发该组合，则会违反GPL。 但这种违规行为最坏的后果可能是GPL代码的作者可以行使他们的权利，提出版权侵权索赔。 版权侵权的补救措施是损害赔偿（金钱）或禁令（停止使用GPL代码）。 至关重要的是，版权法不支持任何强制违规开发人员以GPL许可他们的专有代码或将该代码放入公共领域的补救措施。 因此，将GPL代码与专有代码组合并不会“感染”专有代码或将其转换为GPL代码。
要了解更多信息，请参加Heather Meeker的演讲，开源软件许可：每个技术人员需要了解的内容，在Strange Loop，该活动将于9月28日至30日在密苏里州圣路易斯举行。
4 条评论