开源许可证_限制API的许可证是否应符合开源条件？

开源许可证

在2014年Oracle诉Google判决中，美国联邦巡回上诉法院裁定Java SE API的方法声明和“结构，顺序和组织”（SSO）受版权保护。 这一备受批评的结果与数十年来的业界和专业人士认为API是公有领域的假设相矛盾，反映了API连续重新实现的一种持续的惯例，甚至在法律规定了软件的一般版权保护之后仍然存在。 毫不奇怪，这种共识塑造了开放源代码中API的观点。 特别是开放源代码许可证不涉及API，并且通常不了解其条件适用于API。

如果版权保护性裁决在美国最高法院的当前审查中得以保留，则有理由担心Oracle诉Google最终将对开源许可产生不利影响。 许可证作者可以起草新的许可证，以将熟悉的开源许可证条件明确扩展到仅涉及API的活动。 在推动Oracle v。Google的影响下，也可能会做出类似的努力，以重新诠释现有的开源许可证。

我们已经看到了一个新的类似开放源代码的许可证示例，该许可证限制了API。 去年，Holochain通过其律师Van Lindberg提交了加密自治许可证 （CAL），以供开放源码组织（OSI）批准。 1.0版Beta版草案包括对仅包含或衍生自许可作品中包含或衍生的接口的作品提出的源可用性和许可要求。 （由于接口copyleft功能以外的原因，OSI 拒绝了CAL 1.0-Beta。随后的CAL修订版删除了对接口的显式引用，并且OSI在今年早些时候批准了CAL 1.0。）诸如CAL 1.0-Beta之类的许可证将将copyleft扩展到没有原始代码的API的重新实现。 尽管可能性较小，但新的许可许可证可能会将通知保存要求类似地扩展到仅API的副本。

在我看来，限制API的许可证（尽管类似于FOSS）将不符合开源标签的条件。 为了简化实际上是一个复杂而有争议的问题，让我们接受这样一种观点，即OSI的许可批准决定（解释开放源代码定义 （OSD））是确定许可是否为开放源代码的权威依据。 OSD没有提及软件接口。 一些放宽批准开放源代码许可证标准的倡导者认为，如果OSD未明确禁止某种限制，则应在开放源代码许可证中视为可接受。 为了防范这种等同于“操纵” OSD的策略 ，OSI在2019年明确表示，批准流程的目的是确保批准的许可证不仅符合OSD，而且还提供软件自由。

尽管路易斯·维拉（Luis Villa）担心会引起“ 非真正的苏格兰人 ”问题，但我相信，将软件自由作为基础原则的强调将使OSI能够有效，合理地，可预测地处理许可问题提交的材料暴露了OSD中无法预见的差距或模糊性，这在OSI上很难修改。 （披露：对许可证审查流程进行更改时，我在OSI董事会上。）这也是诚实的承认，OSD就像由Free Software Foundation维护的Free Software Definition一样，是不可避免的不完美和不完整的尝试。提炼出关于什么是FOSS的基本社区规范和期望。

软件自由是长期文化的产物。 判断将FOSS规范性条件扩展到API的许可是否提供软件自由应该从检查传统开始。 这得出一个简单的结论。 如上所述，从开发的最初阶段到现代开放源代码共享的兴起，软件开发一直处于不中断的早期，软件开发人员共享并采取了对无条件重新实现软件接口权利的信念。 从历史的角度来看，很难将任何东西视为重新实现的权利，这是软件自由的核心。

但是，由于对软件自由的理解必然会随着新的社会或技术发展而变化，因此这种询问不能完全是后向的。 值得一问的是，偏离传统的对无限制API的期望是否会促进开放源代码许可的更广泛目标。 乍一看，Copyleft许可似乎是正确的，因为从理论上讲，API Copyleft许可的合规采用可以扩展开源软件的通用性。 但是将copyleft的范围扩展到API重新实现（传统上被视为与原始工作无关的软件）将违反另一个开放源代码规范，即开放源代码许可证的有限范围，这在OSD 9中得到了部分体现。

Oracle诉Google风格的API版权与某些类型的软件专利声明有些相似。 不难想象，采用API限制许可的版权购买者会采用专利巨魔的诉讼策略。 除了这种风险外，接受API限制许可作为开放源代码将进一步使API版权合法化，例如在美国（目前尚未解决法律问题）的司法管辖区。

受Oracle v。Google影响的现有开放源代码许可的解释将类似地将熟悉的开放源代码许可条件扩展到仅涉及API的活动。 此类重新解释会将这些许可证转换为无法提供软件自由并无法实现开源目标的许可证，原因与适用于新许可证案的原因相同。 此外，他们将颠覆这些许可的作者以及几乎所有许可人和被许可人的意图和期望。

有人可能会争辩说，由于开放源代码许可证主要（ 尽管不是排他性的 ）是版权许可证，因此有必要（即使不是有利的）让开放源代码的条件密切跟踪版权向API的扩展。 对于新的开放源代码许可证，情况并非如此，可以明确起草以消除Oracle v。Google的影响。 至于对现有开放源代码许可证的重新解释，尽管API版权问题尚未解决，但放弃传统的解释以预料Oracle对谷歌诉Google影响的法院不熟悉开放源文化的决定将是不合适的。 关于开放源代码许可证的诉讼仍然很少见，并且有影响力的开放源代码解释已在技术社区中出现，而很少考虑法院的行为方式。 无论如何，很可能会说服负责解释常用开放源代码许可证的法院将API视为不受约束的。

有人建议对GPL的解释应充分利用基础版权的范围。 这与copyleft的观点有关，后者是“ 侵犯版权 ”或“ 柔道举动 ”，即“ 使压迫者对压迫者本身施加暴力 ”。 在Software Freedom Conservancy和FSF赞助的copyleft教程中可以检测到它，该教程 说 ：“最强大的copyleft努力尽可能广泛地[使用]版权授予作者的专有权，以最大程度地提高软件自由度。” 对于具有这种观点的人来说，专门宣传GPL的API版权解释似乎是合乎逻辑的。 但是我不知道这样做的拥护者，也没有这样做的人，而且GPL的文本和解释历史也不支持这样的解读。

有时有人对API版权和GPL解释有不同的看法，那就是Oracle诉Google可能会将强版权法的学说放在更可靠的法律基础上。 同样，有时有人断言，强大的copyleft始终依赖于API版权的某些概念，这表明Oracle v。Google提供了某些追溯法律合法性。 FSF不持有后一种观点，FSF在较早的时代曾反对将版权扩展到用户界面。 这种立场进入了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的活动施加任何限制。

翻译自: https://opensource.com/article/20/6/api-copyright

开源许可证