2019 年 4 月许可证审查摘要
在四月份，许可证审查邮件列表
就密码自主许可证进行了广泛的辩论，
尤其是在以下方面
* 其用户数据条款，以及它如何影响用户自由
* 施加于软件运营商的义务
* API 版权
* OSI 的战略考量
* 软件的公开表演权
相应的许可证讨论摘要已在线发布
在
并涵盖了关于以下内容的讨论
非商业许可证，
许可证可撤销性，
以及 LGPL/Apache 兼容性。
## 密码自主许可证 {#cal}
[Van Lindberg][vanl:cal]
提交了他的密码自主许可证 (CAL) 以进行审查。
这是一个网络著作权许可证，但范围比 AGPL 更广。
CAL 的动机是确保基于区块链的应用程序中的用户自主权。
Lindberg 还撰写了一篇 [深入的博客文章][vanl:blog_rationale]
作为一份原理说明文件。
上个月，许可证讨论列表已经对该许可证进行了初步讨论（参见 [摘要][LR:03:cal]）。
在许可证讨论列表上（参见 [摘要][LR:03:cal]）。
[Lindberg][vanl:cal:api2] 和 [Pamela Chestek][chestek:cal:api2]
总结了 CAL 的核心目标
* 衍生作品以著作权方式处理
* 任何提供相同 API 的软件都使用兼容的许可证
* 用户数据是可移植的
注意：本摘要使用术语“运营商”
来描述运行该软件的用户
以便其他最终用户可以与之交互。
### 意见摘要 {#cal-opinions}
虽然该许可证在网络著作权许可领域提出了受欢迎的创新，
但也存在主要的批评
* 运营商受到关于用户数据的不可接受的限制
* 批准 API 著作权许可证不符合 OSI 的利益
* 公开表演权的新颖使用是不明确的、未经测试的、不必要的，并且可能是无效的
[Bruce Perens][perens:cal:market] 不建议批准。
Henrik Ingo [[1][ingo:cal:api],[2][ingo:cal:pperf]]
认为“修订后的、危害较小的许可证版本”最终可能会获得批准。
[vanl:cal]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004028.html
[LR:03:cal]: https://open-source.org.cn/LicenseDiscuss032019#cal
[vanl:blog_rationale]: https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/
### 元数据 {#cal-meta}
虽然 [Perens][perens:cal:meta] 急于尽早听到他的担忧，
[Richard Fontana][fontana:cal:meta] 提醒说不存在紧迫性
根据审查流程，新许可证在任何决定之前都会有 60 天的初步讨论时间
在任何决定之前。
[Simon Phipps][phipps:cal:meta] 补充说
由于 Fontana 作为许可证委员会主任的任期已结束，
在下一次董事会会议任命继任者之前，任何审查进展都将停滞不前。
[berkus:cal:meta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004037.html
[perens:cal:meta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004038.html
[fontana:cal:meta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004041.html
[phipps:cal:meta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004043.html
### 许可证目的 {#cal-purpose}
[Bruce Perens][perens:cal:market]
担心 CAL 超出了许可*软件*的范围，
而是试图建立某种*市场*。
Perens [建议][perens:cal:userdata]
该许可证的商业目的
可能最好通过普通合同来实现。
Van Lindberg [[1][vanl:cal:market],[2][vanl:cal:userdata]]
回应说
虽然 CAL 是因为商业目的而起草的，
但其条款独立于该目的。
这些条款仅涵盖软件的许可，
在某些条件下。
最终，每个许可证背后都有一定的目的。
就 CAL 而言，
商业目的需要网络著作权许可证。
[Perens][perens:cal:misapprehension]
认为虽然其他许可证可能具有自己的目的，
但它们并非特定于某些应用程序。
相比之下，CAL 似乎特定于区块链应用程序。
### 用户数据中的合法权益 {#cal-lawful-interest}
CAL 要求运营商必须提供用户数据
最终用户对这些数据具有合法权益。
例如，
用户可能对其上传到照片存储服务的照片具有所有权权益。
在他们上传到照片存储服务的照片中。
Bruce Perens [[1][perens:cal:market],[2][perens:cal:userdata],[3][perens:cal:misapprehension]] 认为
“合法权益”的定义不够明确，
并且需要关于数据所有权的新颖理论
“存在一些观点，但案例法很少。”
如果第三方确立了合法权益，甚至可能需要向他们披露。
Van Lindberg [[1][vanl:cal:market],[2][vanl:cal:userdata],[3][vanl:cal:locking]] 回应说
合法权益是使用已知的法律术语定义的。
CAL 不授予用户数据新的权利
要么法律承认某种数据所有权，要么不承认。
你最终不可能拥有你原本没有的权利。
[Lindberg][vanl:cal:userdata] 澄清说
CAL 引用 GDPR 不是为了定义合法权益，
而是为了澄清运营商必须如何提供用户数据。
[Perens][perens:cal:misapprehension] 指出
如果用户已经拥有对其数据的权利，
为什么许可证需要对此进行规定？
[Lindberg][vanl:cal:locking] 回应说
“仅仅因为我拥有数据的所有权
并不意味着你现有法律责任将数据给我。
这正是 CAL 解决的问题。”
### 用户自由和数据 {#cal-freedom-data}
Van Lindberg [[1][vanl:cal:userdata],[2][vanl:cal:locking]]
解释了他为什么认为关于用户数据的条款是必要的。
维护用户自由是自由软件的核心。
必须保护用户数据，才能使这种自由有效
> 深刻的见解是，越来越多的
> 数据和代码需要结合在一起才能实现程序的功能。
> 现有的开源许可证，例如 GPLv3 系列，认识到这一点，并且
> 要求提供加密密钥，以防止代码的执行。
> CAL 认识到，用户自由还包括提供用户的数据
> 以便程序在用户选择的环境中完整且充分地发挥作用。
>
> […] 我可能*拥有*我的数据。
> 我也许能够获得源代码的副本。
> 但是 […] 除非我可以使用该软件来处理我自己的数据，
> 否则我也没有有效的自由。
CAL 不会妨碍或限制用户数据，
它只是防止数据被锁定在平台中
– 类似于 GPLv3 的反 Tivoization 条款。
这样的条款是必要的
因为哈希链应用程序提供了锁定程序的新方法。
[Bruce Perens][perens:cal:misapprehension]
不相信最终用户自由需要披露此用户数据。
并且该许可证不仅必须保护最终用户的自由，还必须保护运营商的自由，
那么为什么强迫运营商采取行动是可接受的呢？
[Pamela Chestek][chestek:cal:tivo] 和 [Bruce Perens][perens:cal:misapprehension]
不同意与 GPL 的反 Tivoization 条款进行比较。
当嵌入式软件的设备所有权发生变更时，它适用，
以便新所有者可以在其硬件上安装修改后的软件。
相比之下，CAL 的用户数据条款给软件运营商带来了负担
以提供对用户数据的访问权限。
这是一种根本不同的义务。
### 运营商义务 {#cal-operator-obligations}
Bruce Perens [[1][perens:cal:market],[2][perens:cal:userdata],[3][perens:cal:misapprehension]]
担心运营商关于用户数据的义务
是不明确且过度的
* CAL 的要求仅在使用软件时触发，
这看起来像是违反了 OSD #6 和 #9。
禁止或强制执行某项操作怎么可能不是使用限制？
* 仅仅在 OSI 批准的许可证下运行软件应该是可以的，
而无需阅读它。
CAL 的用户数据要求打破了这种期望。
运营商必须聘请律师来了解其义务的范围。
这是一个不合理的负担，限制了他们的自由。
* CAL 影响使用该软件处理的数据。
Van Lindberg [[1][vanl:cal:userdata],[2][vanl:cal:locking],[3][vanl:cal:freedom]] 反驳说
* CAL 的用户数据要求与
AGPL 的源代码披露要求一样具有限制性
“该许可证强制被许可人采取行动
– 使源代码和数据可用。
这与每个著作权许可证下要求的操作类型完全相同。”
* CAL 不扩展到数据
“在任何其他作品中均未创建任何权利或义务。”
* CAL 不限制使用。
它仅要求在可用的范围内提供用户数据。
例如，数据可能必须为具有合法权益的用户解密，
但 CAL 注意不要求披露私钥。
* CAL 仅在运营商提供服务时强制执行操作。
他们可以随时停止。
[Lindberg][vanl:cal:freedom] 赞赏这一点
用户应该能够在不阅读许可证的情况下运行软件。
但是对于 CAL，最终用户的法律负担仍然为零。
额外的负担仅施加在想要将软件作为服务提供给其他人的运营商身上，
这与 AGPL 应用额外要求的场景相同。
而且无论如何：“如果你向他人提供服务，
你已经承担了巨大的法律责任。”
[Lindberg][vanl:cal:freedom] 对 Peren 的例子感到惊讶
归结为保留运营商锁定其用户数据的自由。
“在某些更宽松的许可证下，这种自由肯定是授予的，
但维护用户权利是自由软件的核心方面，
这是 CAL 所针对的传统。”
[Henrik Ingo][ingo:cal:pperf]
指出开源许可证通常授予用户权利
*并*保护他们免受法律风险。
例如，对 DRM 的限制是“保护用户权利的一个很好的例子”。
Peren 的反对意见似乎主要与 P2P 软件有关
在 P2P 软件中，最终用户同时充当运营商。
### 解决社会问题 {#cal-social}
Bruce Perens [[1][perens:cal:locking]]
同意数据被劫持是一个合理的问题
– 但这是一个*社会*问题。
OSI 之前拒绝了试图解决软件以外的社会问题的许可证。
虽然 OSI 批准的许可证有时要求披露源代码，
但同时要求披露用户数据将是越权行为。
[Van Lindberg][vanl:cal:freedom] 不同意。
CAL 与 996 或 JSON “不做恶”等（非自由）许可证不在同一个范畴。
CAL 试图解决一个问题（用户自主权）
“以与 GPL 解决软件自由的社会问题完全相同的方式。”
### API 版权 {#cal-api}
Pamela Chestek [[1][chestek:cal:api],[2][chestek:cal:api2],[3][chestek:cal:sas]]
总结了 CAL 与 API 版权的关系
任何 CAL 涵盖的 API 的重新实现
都必须在 CAL 或兼容许可证下提供。
CAL 对仅使用/消费 API 的软件没有著作权影响。
假设 API 版权（Oracle 诉 Google 案）被推翻，
CAL 将不会受到影响
因为 CAL 涉及 API 的公开表演，而不是其复制。
但是，如果没有先例，如何限制其他实现？
Van Lindberg [[1][vanl:cal:api],[2][vanl:cal:api2]]
确认 Chestek 的分析是正确的，
但认为 API 版权被推翻的可能性很小。
即便如此，CAL 也会利用专利权作为强制执行著作权的次要手段。
Richard Fontana [[1][fontana:cal:apileft],[2][fontana:cal:apileft2]]
指出，当 API 重新实现的
二进制文件被分发或其接口被公开表演时，它们必须开源。
他批评了“公开表演接口”的概念，认为它不明确，
并认为相关条款的措辞含糊不清。
这引发了关于牛津逗号的题外话。
[Richard Fontana][fontana:cal:apileft]
询问了欧盟 API 版权的法律状况
根据 2012 年 [SAS Institute Inc. 诉 World Programming Ltd.][sascase] 的裁决。
[Carlo Piana][piana:cal:sas]
解释说，SAS 裁决排除了
语言 API、编程语言和文件格式
在欧盟的版权保护之外。
[sascase]: https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Programming_Ltd
### 关于 API 版权的战略考量 {#cal-strategy}
理查德·丰塔纳警告说，CAL 将会是第一个许可证
有意将著作权扩展到 API。
亨里克·英戈对林德伯格的解释感到震惊
“这不可能是你的本意”。
他们提请注意一些战略问题。
[丰塔纳][fontana:cal:apileft] 认为
当前的社区共识是反对 API 著作权。
他认为“一项根深蒂固的政策
反对在自由软件/开源中 […] 限制性地应用接口版权
在自由软件/开源中 […]
这应该被解读为 OSD 以及我们对软件自由的理解”。
“[社区] 对甲骨文诉谷歌案的结果普遍敌视”支持了这一点
以及 FSF 反对 API 可版权性的政策。
虽然许可证可能会承认 API 的可版权性，
但它应该仅在高度宽松的条款下这样做
并且不应使用它来施加著作权要求。
[亨里克·英戈][ingo:cal:api]
希望 OSI “不会也不能批准” 这种版权最大化的特性。
相反，开源社区有兴趣推广这样一种观点
即接口实现始终或通常属于合理使用。
也许，多年以后 API 确实变得广泛享有版权。
只有到那时，社区利用这种权力才符合利益。
英戈还提到，目前，
OSI 批准具有 API 版权要素的许可证将是非常不可取的
因为甲骨文的律师可能会将此用作证据
证明这种观点在行业和开源社区中被广泛接受。
[范·林德伯格][vanl:cal:pperf] 理解这些战略上的反对意见，
但不认为“使用法律术语和判例法是一种延伸
这些术语和判例法已经推定适用于软件。”
[布鲁斯·佩伦斯][perens:cal:scholarship]
询问 OSI 批准使用公开表演权的许可证是否符合其利益
使用公开表演权
“用于*除了*要求发布源代码*之外*的目的”。
还有一个先例问题。
[佩伦斯][perens:cal:scholarship] 指出 FSF
（尽管不赞成软件的公开表演）
在 AGPL 上做了类似的事情，而 OSI 最终批准了它。
[帕梅拉·切斯特克][chestek:cal:scholarship] 认为这导致了
“OSI 决策过程可能难以预测，这是可以理解的抱怨”，
尤其是在没有人声称 CAL 的 API/公开表演方面
会违反 OSD 的情况下。
### 公开表演 {#cal-public-performance}
亨里克·英戈 [[1][ingo:cal:pperf],[2][ingo:cal:pperf2]] 提醒说
“在软件许可证中使用公开表演是新颖且未经测试的。”
这对用户来说是冒险的。
许可证甚至不需要公开表演权即可工作
但可以使用“更枯燥但经过更好测试且更安全的法律方法”。
那么，除了最大化其版权权力之外，许可证应该依赖公开表演权的原因是什么？
除了最大化其版权权力之外，许可证应该依赖公开表演权的原因是什么？
范·林德伯格 [[1][vanl:cal:pperf],[2][vanl:cal:pperf2]]
从根本上不同意这一点，并认为公开表演是 CAL 的关键。
实际上，AGPL 是唯一可用的网络著作权许可证。
但林德伯格发现其网络著作权条款存在不足
* 它们不会为未修改的版本触发
* 它们可以通过使用代理来规避
* 它们不适合确保用户数据访问
* 它们在企业环境中不明确
林德伯格认为 [[1][vanl:cal:pperf2],[2][vanl:cal:corporate]]
最好使用*公开表演*
——版权法中一项已确立的权利——
而不是定义像“网络互动”这样的独特术语。
公开表演与一些其他定义的结合使用
也明确了企业的合规性。
[亨里克·英戈][ingo:cal:agpl] 同意林德伯格对 AGPL 的分析，
并欢迎替代方案。
英戈批评了代理漏洞，
及其类似 GPL 的思维模式，即软件将在
单台计算机上的单个进程中执行
该进程接受网络连接。
然而，[英戈][ingo:cal:agpl] 强烈反对公开表演会是一个解决方案。
这完全是未知的领域，
而 CAL 未能限制其影响。
公开表演“只会增加不确定性，但几乎没有实际价值。”
AGPL 通过明确且无限制地允许运行程序来保护用户。
它没有限制公开表演，
而是使用了一种笨拙的结构，强制执行软件的功能
而不是运营商的行为。
其他许可证不必使用这种方法，
但简单明了的法律条款有助于保护用户。
也许可以通过简单地将“网络互动”替换为“互动”来修复 AGPL
通过简单地将“网络互动”替换为“互动”来修复 AGPL
[布鲁斯·佩伦斯][perens:cal:fud]
感到困惑的是，如果公开表演权被赋予，
AGPL 为什么要费力合成一个单独的类似公开表演的权利。
[帕梅拉·切斯特克][chestek:cal:pperf]
想知道 CAL 在欧盟将如何运作，因为欧盟可能不存在等效的公开表演权。
[卢卡斯·阿特金森][atkinson:cal:pperf] 指出“向公众传播”，
并建议 CAL 可以参考 WIPO 条约，其中对此进行了定义。
斯科特·彼得森 [[1][peterson:cal:fud],[2][peterson:cal:fud2]]
担心 CAL 试图引入这样的概念
即软件互操作可能是版权持有者的专有权利。
这将引起恐慌、不确定和怀疑 (FUD)。
影响版权法解释的行为
应考虑其更广泛的影响。
[布鲁斯·佩伦斯][perens:cal:fud] 提到了林德伯格的论点
即公开表演是软件的一项现有权利
因为软件是一种文学作品。
[麦考伊·史密斯][smith:cal:scholarship]
链接到一篇文章，该文章认为软件的公开表演权*确实存在*，
但通常*不适用*
（洛塔尔·德特曼 (2015)
*云端发生了什么：软件即服务和版权。*
载于：29 Berkeley Tech. L.J.
DOI
### 其他要点 {#cal-other}
[帕梅拉·切斯特克][chestek:cal:comments]
对许可证中不明确的语言进行了仔细分析。
亨里克·英戈担心反 DRM 条款可能无效，
这导致了一些与 GPLv3 的比较
[[1][ingo:cal:pperf],[2][vanl:cal:pperf],[3][ingo:cal:pperf2],[4][vanl:cal:pperf2]]。
[perens:cal:market]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004029.html
[vanl:cal:market]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004031.html
[perens:cal:userdata]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004032.html
[vanl:cal:userdata]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004033.html
[perens:cal:misapprehension]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004034.html
[vanl:cal:locking]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004035.html
[perens:cal:locking]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004036.html
[vanl:cal:freedom]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004044.html
[chestek:cal:tivo]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004052.html
[chestek:cal:api]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004053.html
[vanl:cal:api]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html
[chestek:cal:api2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004057.html
[vanl:cal:api2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004061.html
[fontana:cal:apileft]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004062.html
[fontana:cal:apileft2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004063.html
[piana:cal:sas]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004064.html
[chestek:cal:sas]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004067.html
[ingo:cal:api]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004059.html
[ingo:cal:pperf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004040.html
[vanl:cal:pperf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004045.html
[ingo:cal:pperf2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004046.html
[vanl:cal:pperf2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004047.html
[vanl:cal:gpl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004048.html
[fleming:cal:corporate]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004049.html
[vanl:cal:corporate]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004050.html
[ingo:cal:agpl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004058.html
[chestek:cal:pperf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004054.html
[atkinson:cal:pperf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004055.html
[chestek:cal:comments]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004051.html
[peterson:cal:fud]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004070.html
[peterson:cal:fud2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004071.html
[perens:cal:fud]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004072.html
[smith:cal:scholarship]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004075.html
[perens:cal:scholarship]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004076.html
[chestek:cal:scholarship]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004079.html