开源许可:每位技术专家都应该了解的知识

了解不同类型的开源许可证,并获得常见许可问题的解答。
1057 位读者喜欢这篇文章。
A diagram of a branching process

Opensource.com

如果您是当今的软件开发人员,您就知道如何使用开源软件,但您是否了解开源许可的起源以及原因?了解一些背景知识将有助于您理解许可证的工作方式及其原因。

开源许可的起源

当今的技术专家在 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 种许可证通常分为两类:宽松许可证和 copyleft 许可证。

宽松许可证很简单,是最基本的开源许可证类型:它允许您对软件做任何您想做的事情,只要您遵守通知要求即可。宽松许可证按“原样”提供软件,不提供任何保证。因此,宽松许可证可以总结如下:

  • 对代码做任何你想做的事情
  • 风险自负
  • 承认作者/贡献者

Copyleft 许可证在宽松许可证的基础上增加了要求。除了上面列出的要求外,copyleft 许可证还要求:

  • 如果您分发二进制文件,则必须提供这些二进制文件的源代码
  • 源代码必须在您获得代码时所依据的相同 copyleft 条款下提供
  • 您不能对被许可人行使许可证施加额外限制

下表根据宽松和 copyleft 框架对流行的开源许可证进行分类。copyleft 许可证也按强度升序排列,从顶部最强到底部最弱。“强度”指的是周围软件可能需要遵守相同 copyleft 要求的程度。例如,GPL 很强,因为它要求任何包含 GPL 代码的程序必须只包含 GPL 代码。LGPL 较弱,因为它允许动态链接到其他专有代码,而无需使链接的代码遵守相同的 GPL 要求。最弱的 copyleft 许可证 EPL 和 MPL 允许与任何类型的其他代码集成,只要 EPL 或 MPL 代码位于其自己的文件中即可。

宽松许可证

Copyleft 许可证

  • BSD(伯克利软件发行版)
  • MIT
  • Apache 2
  • Affero GPL (AGPL)
  • GPL
  • Lesser GPL (LGPL)
  • Mozilla 公共许可证 (MPL)
  • Eclipse 公共许可证 (EPL)
  • 通用开发和分发许可证 (CDDL)

热门开源问题

当我为客户提供开源许可方面的建议时,他们最常问的四个问题是:

  1. 什么是“分发”?
  2. 开源许可证如何影响软件中的专利权?
  3. 什么是“通知”要求,我该如何遵守?
  4. 什么是“衍生作品”,以及,将 GPL 代码合并到我的专有代码中是否会导致专有代码也必须以 GPL 许可?

这些问题的简短答案如下:

  1. 什么是“分发”? 简单来说,分发指的是将受版权保护的作品(如软件)的副本从一个法人转移到另一个法人。分发概念很重要,因为只有在分发软件时才会触发开源许可证的要求。因此,不分发软件的人不会违反开源许可证的条款。并且由于“法人”包括公司,因此如果软件仅在同一公司的员工之间转移,则不存在分发——因此也不存在违反许可证条款的风险。

今天,对于通过互联网、云或 SaaS 模型部署软件的企业来说,分发可能是一个更棘手的问题。允许用户通过互联网与软件应用程序交互是否符合分发的条件?对于大多数开源许可证,答案是否定的。实际上,GPLv3 使用术语“转让”而不是“分发”,正是为了明确 SaaS 使用不会触发任何许可证要求。但 Affero GPL (AGPL) 许可证是一个例外,它采取了不同的方法。一旦软件被修改并可通过网络使用和交互,就会触发 AGPL 的要求(与 GPL 相同)。

  1. 开源许可证如何影响软件中的专利权? 一些开源许可证(例如,Apache 2、GPLv3)包含明确的专利许可条款,这些条款授予接收者使用涵盖该软件产品的任何专利的许可。其他开源许可证(例如,BSD、MIT、GPLv2)对专利许可保持沉默。尽管如此,对于这些许可证,法院可能会使用“默示许可”原则来认定接收者仍然获得许可,并免受因使用许可的软件产品而引起的任何专利侵权指控。通过这样做,法院阻止许可方“咬苹果两次”,并因使用他们已许可的软件而起诉专利侵权。总而言之,除非另有明确说明,否则开源许可证限制了作者起诉遵守许可证的接收者涉嫌专利侵权的能力。
  1. 什么是“通知”要求,我该如何遵守? 通知要求意味着开源软件的分发者必须告知接收者,在交付给接收者的软件中包含某些根据通知许可证提供的开源软件。每个开源许可证都有其自己的特定通知要求。通常,这些要求包括提供适用许可证的完整副本,并承认作者和贡献者。最佳实践是预先交付许可证涵盖的源代码,因为许可证的完整副本通常作为文本文件包含在源代码包中。另一个最佳实践是遵循 GPL 的通知要求,因为它们被认为是其中最严格的要求。因此,遵守 GPL 的通知要求通常可以确保遵守其他适用的开源许可证的通知要求。
  1. 衍生作品和病毒式 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 日在密苏里州圣路易斯举行。em>

标签
Heather Meeker
Heather Meeker 是 O’Melveny & Myers 律师事务所硅谷办公室的合伙人。她为客户提供技术交易和知识产权方面的咨询。她是国际公认的开源软件许可专家。

4 条评论

我完全支持开源软件,并相信当代码公开可用时,每个人都会受益。

仅仅是为了唱反调:当然,如果您有衍生作品并且您不符合许可证的要求,没有人会强迫您以 GPL 发布您的专有代码。您当然可以仅仅停止分发您花费多年开发、耗资数百万美元开发且您的业务依赖的软件。因此,虽然您没有被“强迫”以 GPL 许可您以前的专有软件,但公司通常只有极少的选择来补救这种情况(并继续分发其专有软件)。根据依赖的 GPL 软件的版权所有者是谁,您或许可以从版权所有者那里获得例外(可能需要花钱)。如果您无法获得例外,您唯一的选择是停止分发侵犯许可证的软件或以 GPL 发布您的软件。

嗯,另一种选择是将集成重新架构为“插件”。这意味着您取出您的“保留所有权利”或以不同方式许可的代码库,将其与您想要使用的 GPL 许可代码分开,并尝试仅通过定义的 API 非常松散地将两者连接在一起。可能是您的代码是“主软件”,而 GPL 部分是“插件”,反之亦然。

根据具体情况,这可能比其价值更麻烦,而且显然,如果您一开始就考虑以这种方式进行操作,则更容易完成。

回复 ,作者:airfishey

我不得不赞同 airfishey 的观点。

关于衍生作品的关键部分与以下声明有关:“版权侵权的补救措施是损害赔偿(金钱)或禁令(停止使用 GPL 代码)。”

这引出了一个问题——在支付任何损害赔偿后,衍生作品的状态是什么?它是否仍然受 GPL 条款约束,还是现在不受其约束?或者这是否取决于协议(和数量)?

我认为这取决于版权侵权是如何解决的。我不是律师,这也不是法律建议。

版权所有者可能会起诉您要求损害赔偿,并且仍然要求您遵守 GPL。根据您使用的 GPL 版本,版权所有者可能必须明确授予您恢复分发软件的权限(大概是在他们验证您现在符合许可证要求之后)。我相信其他版本的 GPL(我认为是第 3 版)允许您在您遵守许可证后立即恢复您的权利(仅限初次违规)。

另一种支付损害赔偿的方式是版权所有者授予您例外以换取某些东西。这可能意味着版权所有者允许您在您的闭源/专有程序中使用他们的软件,以换取金钱(例如,版税或其他费用)、广告、为他们开发另一款软件、做家务等。版权所有者可以选择以他们喜欢的任何方式许可他们的软件,所以这真的取决于他们如何/是否授予您例外。如果版权所有者是您最好的朋友,他们可能只会授予您例外,让您随意使用他们的软件,而无需支付任何真正的“损害赔偿”。

使用带有版权所有者例外的 GPL 的一个例子是 GNU Classpath:https://gnu.ac.cn/software/classpath/license.html

GCC 运行时库例外:https://gnu.ac.cn/licenses/gcc-exception-3.1.en.html

回复 ,作者:tmz

© . All rights reserved.