在 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 条评论