在 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 的活动施加任何限制。
4 条评论