在其 2014 年的 Oracle 诉 Google 判决中，美国联邦巡回上诉法院裁定 Java SE API 的方法声明和“结构、序列和组织”（SSO）受版权保护。这一备受批评的结果与数十年来业界和专业人士的共识假设相悖，即 API 属于公有领域，这反映在 API 的持续常见再实现实践中，并且即使在软件的一般可版权性通过法规确定后仍然存在。毫不奇怪，这种共识塑造了开源领域对 API 的看法。特别是开源许可证没有涉及 API，它们的条件通常不被理解为适用于 API。
如果版权裁决在其目前的美国最高法院 复审 中幸存下来，那么有理由担心 Oracle 诉 Google 最终会对开源许可产生一些不利影响。许可证作者可能会起草新的许可证，明确将熟悉的开源许可证条件扩展到仅涉及 API 的活动。也可能出现类似的努力，以推进受 Oracle 诉 Google 影响的对现有开源许可证的重新解释。
我们已经看到了一个限制 API 的新的类开源许可证的例子。去年，Holochain 通过其律师 Van Lindberg 提交了 加密自主许可证（CAL），供开源促进组织（OSI）批准。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 中未预见的差距或模糊性的情况，而 OSD 在政治上难以修订。（披露：当对许可证审查流程进行此更改时，我曾在 OSI 董事会任职。）这也是对 OSD（如自由软件基金会维护的 自由软件定义）不可避免地是不完善和不完整的尝试的诚实承认，旨在提炼围绕 FOSS 是什么的基础社区规范和期望。
软件自由是长期文化的产物。判断将 FOSS 规范性条件扩展到 API 的许可证是否提供软件自由应从审查传统开始。这得出一个直接的结论。如上所述，从几乎编程的早期开始，一直到现代开源社区的兴起，软件开发人员一直在分享和实践对无条件重新实现软件接口的权利的信念。从历史的角度来看，很难想到有什么比这种重新实现的权利更核心的软件自由了。
然而，这种探究不能完全是回顾性的，因为对软件自由的理解必然会随着新的社会或技术发展而变化。值得问的是，背离对不受限制的 API 的传统期望是否会促进开源许可的更广泛目标。乍一看，对于著作权共享许可来说，这似乎是正确的，因为理论上，API 著作权共享许可证的合规采用可以扩大开源软件社区。但是，将著作权共享的范围扩展到 API 的重新实现——传统上被视为与原始作品无关的软件——将违反另一项开源规范，即开源许可证的有限范围，这部分体现在 OSD 9 中。
另一个观察结果是，软件自由受到过于复杂和不可预测的许可安排的威胁，这些安排使合规性过于困难。对于 API 限制性类 FOSS 许可证来说，尤其是在著作权共享方面，情况很可能如此。例如，著作权共享许可证通常对授予准备衍生作品的许可施加条件。试图弄清楚什么是 Java 方法声明的衍生作品，或者一组 API 的 SSO，可能会成为一场合规噩梦。它是否包括 API 的重新实现？仅仅调用 API 的代码？Oracle 诉 Google 风格的 API 版权的基本模糊性与某些类型的软件专利权主张有些相似。不难想象，API 限制性许可证涵盖的版权收购者会采取专利流氓的诉讼策略。除了这种风险之外，接受 API 限制性许可证作为开源许可证还会进一步使美国等司法管辖区的 API 可版权性合法化，而在这些司法管辖区，法律问题目前尚未解决。
受 Oracle 诉 Google 影响的对现有开源许可证的解释也会类似地将熟悉的开源许可证条件扩展到仅涉及 API 的活动。由于与新许可证案例相同的原因，这种重新解释会将这些许可证转变为未能提供软件自由并推进开源目标的许可证。此外，它们还会颠覆这些许可证的作者以及几乎所有许可人和被许可人的意图和期望。
可能会有人认为，由于开源许可证主要（虽然并非完全如此）是版权许可证，因此如果它们的条件密切跟踪版权向 API 的扩展，那么这是必要的，即使不是有益的。对于可以明确起草以消除 Oracle 诉 Google 影响的新开源许可证来说，情况并非如此。至于对现有开源许可证的重新解释，虽然 API 可版权性问题仍未解决，但不宜放弃传统解释，而倾向于预测受 Oracle 诉 Google 影响且不熟悉开源文化的法院会做出什么决定。关于开源许可证的诉讼仍然不常见，有影响力的开源许可证解释已在技术社区中出现，几乎没有考虑法院可能如何行动。无论如何，从事解释常用开源许可证的法院很可能会被说服将 API 视为不受约束的。
有些人建议 GPL 的解释应充分利用基础版权权利的范围。这与将著作权共享视为对版权的“黑客行为”或“柔道动作”，旨在“将压迫者的暴力力量返还给压迫者自身”的观点有关。这可以在软件自由保护协会和 FSF 赞助的 著作权共享教程 中检测到，该教程 说：“最强大的著作权共享力求[尽可能广泛地使用]版权授予作者的专有权，以最大限度地提高软件自由度。” 对于具有这种观点的人来说，专门推广 GPL 的 API 版权解释似乎是合乎逻辑的。但我不知道有任何强著作权共享的倡导者这样做过，并且 GPL 的文本和解释历史不支持这种解读。
偶尔有人表达的对 API 版权和 GPL 解释的略有不同的看法是，Oracle 诉 Google 可能会使强著作权共享原则建立在更可靠的法律基础上。同样，有时有人断言，强著作权共享一直以来都基于某种 API 可版权性的概念，这表明 Oracle 诉 Google 提供了一些追溯法律合法性。自由软件基金会（FSF）不持有后一种观点，FSF 在早期曾 反对将版权扩展 到用户界面。这种立场被纳入 GPLv2，GPLv2 有一个 很大程度上被忽视的条款，授权原始许可人排除会通过专利或受版权保护的接口限制“分发和/或使用……”的国家/地区。FSF 还 严厉批评 了 Oracle 对 Java API 版权所有权的主张。并且 FSF 从未质疑在非 GPL 许可证下重新实现 GPL 许可软件的 API 的权利（例如，FSF 版权所有的 GNU Readline 和 BSD 许可的 libedit）。如果证明强著作权共享理论存在一些法律缺陷，而 API 可版权性可以在某种程度上弥补这些缺陷，我认为最好要么接受对 GPL 著作权共享的较弱理解，要么寻求对 GPL 的修订，以在不依赖 API 版权的情况下重新制定强著作权共享。
如果 API 可版权性在最高法院的复审中幸存下来，那么许可证管理者、现有开源许可证的许可人和新开源许可证的起草者应采取建设性步骤，以最大限度地减少对开源的影响。广泛使用的开源许可证的管理者（如果存在）可以发布解释性指南，澄清 API 不受许可证的限制。对现有开源许可证的更新和全新的许可证可以使不受限制的 API 成为明确的政策。现有开源许可证的许可人可以在标准化的许可证声明中或通过外部承诺明确表示，他们不会将开源许可证条件视为对仅涉及 API 的活动施加任何限制。
4 条评论