API限制性许可是否应被视为开源?

探讨备受关注的关于版权和 API 的法律案件可能如何影响开源许可
135 位读者喜欢这篇文章。
Two government buildings

Opensource.com

在 2014 年的 Oracle v. Google 判决中,美国联邦巡回上诉法院裁定 Java SE API 的方法声明和“结构、顺序和组织”(SSO) 受版权保护。 这一备受批评的结果与数十年来业界和专业人士的共识假设相悖,即 API 属于公共领域,这反映在不断重复实现 API 的常见做法中,即使在软件的一般版权性已由法规确定后,这种情况仍然存在。 毫不奇怪,这种共识影响了开源内部对 API 的看法。 特别是,开源许可证没有涉及 API,并且它们的条件通常不被理解为适用于 API。

如果版权裁决通过了美国最高法院当前的 复审,就有理由担心 Oracle v. Google 最终会对开源许可产生一些不利影响。 许可证作者可能会起草新的许可证,明确将熟悉的开源许可证条件的范围扩展到仅涉及 API 的活动。 也可能会出现类似的努力,以推进受 Oracle v. Google 影响的对现有开源许可证的重新解释。

我们已经看到了限制 API 的新型类开源许可证的例子。 去年,Holochain 通过其律师 Van Lindberg 向开源倡议组织 (OSI) 提交了 密码学自主许可 (CAL) 以供批准。 1.0-Beta 草案包括对仅包含或衍生自许可作品中包含或衍生的接口的作品的源代码可用性和许可要求。 (CAL 1.0-Beta 因接口著作权问题以外的原因被 OSI 拒绝。 CAL 的后续修订版删除了对接口的明确引用,OSI 今年早些时候批准了 CAL 1.0。) 像 CAL 1.0-Beta 这样的许可证会将著作权扩展到与原始代码没有共同代码的 API 的重新实现。 尽管可能性较小,但新的宽松许可证可能会类似地将通知保留要求扩展到 API 的简单副本。

我认为,API 限制性许可证虽然在其他方面类似于 FOSS,但并不符合开源标签的要求。 为了简化实际复杂且有争议的问题,让我们接受 OSI 对 开源定义 (OSD) 的解释的许可批准决定,以此作为确定许可证是否开源的权威依据。 OSD 没有提及软件接口。 一些主张放宽批准开源许可证标准的人认为,如果 OSD 没有明确禁止某种类型的限制,则应认为它在开源许可证中是可以接受的。 为了防止这种相当于 “利用”OSD 的策略,OSI 在 2019 年 澄清,批准流程的目的不仅是确保批准的许可证符合 OSD,还要确保提供软件自由。

虽然 Luis Villa 提出了担忧,认为它会导致 “没有真正的苏格兰人” 问题,但我相信对软件自由的强调作为基本原则,将使 OSI 能够以充分理由、可预测的方式有效地处理许可证提交暴露了 OSD 中无法预见的空白或模糊之处的情况,OSI 很难对其进行修订。 (披露:我是在对许可证审查流程进行此更改时担任 OSI 董事会成员。) 这也是对 OSD 的诚实承认,就像自由软件基金会维护的 自由软件定义 一样,是对提炼围绕 FOSS 是什么这一主题的基础社区规范和期望的不可避免的不完美和不完整的尝试。

软件自由是长期文化的产物。 判断将 FOSS 规范性条件扩展到 API 的许可证是否提供软件自由,应首先检查传统。 这得出了一个简单的结论。 如上所述,从编程的早期开始,一直到现代开源社区的兴起,软件开发人员都共享并遵循对重新实现软件接口的无条件权利的信念。 从历史的角度来看,很难想到有任何东西像这种重新实现的权利一样,是软件自由的核心。

然而,调查不能完全回顾过去,因为对软件自由的理解必然会随着新的社会或技术发展而变化。 值得问的是,偏离对不受限制的 API 的传统期望是否会促进开源许可的更广泛目标。 乍一看,对于著作权许可来说,这似乎是正确的,因为从理论上讲,API 著作权许可的合规采用可以扩展开源软件社区。 但是,将著作权的范围扩展到 API 重新实现——传统上被视为与原始作品无关的软件——将违反另一项开源规范,即开源许可证的有限范围,这部分包含在 OSD 9 中。

另一个观察结果是,软件自由受到过度复杂且不可预测的许可安排的危害,这些安排使合规过于困难。 对于 API 限制性类 FOSS 许可证来说,尤其是在著作权方面,情况很可能就是如此。 例如,著作权许可证通常对准备衍生作品的许可授予施加条件。 试图弄清楚什么是 Java 方法声明的衍生作品,或者一组 API 的 SSO,可能会变成一场合规噩梦。 它是否包括 API 的重新实现? 仅仅调用 API 的代码? Oracle v. Google 风格的 API 版权的基本模糊性与某些类型的软件专利权要求有些相似。 不难想象,API 限制性许可证涵盖的版权的收购者会采用专利流氓的诉讼策略。 除了这种风险之外,接受 API 限制性许可证作为开源还会进一步使 API 版权在像美国这样的司法管辖区合法化,在这些司法管辖区,法律问题目前尚未解决。

Oracle v. Google 影响的对现有开源许可证的解释同样会将熟悉的开源许可证条件扩展到仅涉及 API 的活动。 出于与新许可证案例相同的原因,这种重新解释会将这些许可证转变为无法提供软件自由和促进开源目标的许可证。 此外,它们还会颠覆这些许可证的作者以及几乎所有其许可人和被许可人的意图和期望。

可能会有人认为,因为开源许可证主要是(虽然不是唯一)版权许可证,因此如果它们的条件与版权扩展到 API 的情况密切相关,那么对于它们来说,即使不是有益的,也是必要的。 对于新的开源许可证来说,情况并非如此,可以明确地起草它们来消除 Oracle v. Google 的影响。 至于对现有开源许可证的重新解释,虽然 API 版权问题仍未解决,但不应放弃传统解释,而倾向于预测受 Oracle v. Google 影响的、不熟悉开源文化的法院会做出什么决定。 关于开源许可证的诉讼仍然很少见,并且有影响力的开源许可证解释已经在技术社区中出现,而很少考虑法院可能会如何行动。 无论如何,从事解释常用开源许可证的法院很可能会被说服将 API 视为不受约束的。

有人认为,GPL 的解释应该充分利用底层版权的范围。这与将 copyleft 视为一种“对版权的黑客行为”或一种“柔道策略”,即“将压迫者的暴力力量返还给压迫者本身”的观点有关。这可以在软件自由保护协会和 FSF 赞助的 copyleft 教程中发现,该教程指出:“最强的 copyleft 试图尽可能广泛地[使用]版权授予作者的专有权,以最大限度地提高软件自由。” 对于持有这种观点的人来说,专门提倡对 GPL 进行 API 版权解释似乎是合乎逻辑的。 但我不知道有任何强 copyleft 的倡导者这样做过,而且 GPL 的文本和解释历史也不支持这种解读。

偶尔有人提出一种略有不同的关于 API 版权和 GPL 解释的观点,即 *Oracle v. Google* 可能会为强 copyleft 的理论奠定更坚实的法律基础。 同样,有时有人断言,强 copyleft 一直基于某种 API 可版权性的概念,这意味着 *Oracle v. Google* 提供了一些追溯性的法律合法性。 FSF 不持有后一种观点,FSF 早些时候曾反对将版权扩展到用户界面。 这一立场体现在 GPLv2 中,GPLv2 包含一个基本被忽视的条款,授权原始许可方排除那些通过“专利或版权界面”限制“发行和/或使用……”的国家。 FSF 还严厉批评了 Oracle 对 Java API 版权所有权的主张。 而且,FSF 从未质疑在非 GPL 许可下重新实现 GPL 许可软件的 API 的权利(例如,FSF 版权的 GNU Readline 和 BSD 许可的 libedit)。 如果能够证明强 copyleft 理论存在某种法律缺陷,而 API 可版权性能以某种方式修复该缺陷,我认为最好要么接受对 GPL copyleft 的较弱理解,要么寻求修改 GPL,以重新制定强 copyleft,而不依赖于 API 版权。

如果 API 可版权性经受住最高法院的审查,那么许可证管理者、现有开源许可证的许可方以及新开源许可证的起草者应采取建设性措施,以最大限度地减少对开源的影响。 广泛使用的开源许可证的管理者(如果存在)可以发布解释性指南,澄清 API 不受许可证的限制。 对现有开源许可证的更新和全新的许可证可以将不受限制的 API 作为一项明确的政策。 现有开源许可证的许可方可以在标准化许可证声明中或通过外部承诺明确表示,他们不会将开源许可证条件视为对仅涉及 API 的活动施加任何限制。

接下来阅读什么
标签
Richard Fontana
Richard 是 Red Hat 法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在与开源相关的法律问题上。

4 条评论

Richard,我认为你的文章应该更正。 你错误地描述了 CAL 许可证。 它不是“限制 API 的新型类开源许可证”。 CAL 许可证具有与目前使用中的许多许可证完全相同的 copyleft 范围,其中一些许可证早于 AGPLv3,它们将 copyleft 的范围定义为版权的范围。 CAL 在这方面并没有突破性,如果 OSI 因此而拒绝它,那么 OSI 将会因为其许可证审查过程是主观的而不是客观的而受到质疑。 正如你所指出的,最初的草案专门用于捕获 API,但这是 OSI 在拒绝第一个版本时质疑的一个方面,正如你所指出的,这方面没有出现在第二个版本中,这表明 OSI 会拒绝一个将 copyleft 扩展到版权范围之外的许可证。

现在将其称为“类开源”也是不真诚的。 你在文章中没有提到你投票批准了 CAL 许可证作为 OSI 批准的许可证。 你在 2020 年 2 月 6 日说:“在审查了最新草案后,我投“通过”票。 我对该许可证以及 Holochain 或其他未知许可方滥用的可能性仍然存在担忧,这部分基于之前的起草历史、Van 之前对这些草案的一些评论以及对由狭隘商业利益专门推进的新 copyleft 许可证的普遍怀疑。 但是,我不认为这些担忧充分植根于当前的许可证文本中,因此我不会建议拒绝或进行更长时间的讨论。 如果该许可证获得批准,我不建议任何人使用它。 但就其表面而言,该许可证(包括核心的有趣的用户数据要求功能)在我看来与 OSD 和软件自由的精神是一致的。”

嗨,Pam,我在该段中提到的“类开源许可证”不是 CAL 1.0(OSI 今年早些时候批准的许可证),而是 CAL 1.0-Beta,即 Van Lindberg 在 2019 年初最初提交的早期草案。 你是对的,我支持 OSI 批准 *后来* 版本的 CAL,该版本没有界面 copyleft 功能。 我还对 *早期* 版本的 CAL(CAL 1.0-Beta)的 OSD 符合性提出了担忧,原因是界面 copyleft 功能。 自收到你的评论以来,我已经多次阅读该段,并与我在 Red Hat 的一些同事讨论过,我觉得已经足够清楚,不需要对文章进行编辑,但我希望对你的评论的回复有助于为读者澄清事情。

回复 作者 pchestek

作为一个外行,我能够理解它是类开源的 CAL 1.0-Beta 许可证,而不是通过 OSD 的 CAL 1.0 许可证。

顺便说一句,我认为这次讨论非常有趣。 我必须说我的第一反应是,Copyleft to API 似乎很好,但你彻底说服了我,我们需要倡导重新实现 API 的固有权利,而与软件许可证无关。 我现在认为这是最好的选择,堆栈排名。 针对你的观点,我认为第二好的选择是,如果 Oracle 与 Google 的案例使 API 具有可版权性,那么开源许可证应明确扩展以包含此权利。 这至少可以保护开源代码,开源代码正成为世界上最大的代码部分,因此它自然会扩展。

回复 作者 fontana

与单独的软件源代码相比,API 的主要区别(简单地说)是 API 需要数据和/或其他资源才能工作。 您可以传输和复制源代码,但除非您拥有数据、设备、照明、建筑物或 API 公开的任何其他资源,否则单独的源代码许可模式将无法保证 API 的可用性。 或者,如果代码安装在其他地方,API 将不会提供相同的资源并以相同的方式工作。 因此,从这个意义上讲,许可 API 并不(总是)与许可软件相同。 如果有人感兴趣,我们今年在芬兰开源、开放数据和 API 社区花费了大量时间来弄清楚这一点。 我们的一些发现都在这篇长文中 https://www.osaango.com/blog/what-is-an-open-api。 总的来说,我们认为开源许可涵盖并且可以涵盖 API 许可的很大一部分,但不是全部。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© 2025 open-source.net.cn. All rights reserved.