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