2019年1月许可证讨论摘要
在1月份，许可证讨论邮件列表讨论了
* opensource.dev 信息站点
* 开放数据
* 开源许可证中的“亲密性”
* 流程和接口边界
* 相应源代码
* FSF 引入一个新词是否是个问题？
* 理解法律和明确界限
* 许可方期望
* 重新许可和维护者-社区动态
* VanL 即将推出的著作权强制许可
相应的许可证审查摘要已在线发布
在
并涵盖了关于 SSPL v2 和 C-FSL 的讨论。
## opensource.dev
[Chris DiBona (Google)][dibona] 宣布
一个关于 Google 开源的信息页面。
它似乎与 OSI 的解释一致
并受到列表中的普遍赞扬和赞赏。
[Christopher Sean Morrison][morrison_opensource.dev]
赞扬了关于开源的良好资源集合，
并指出它对新开发人员和非开发人员都非常容易访问。
对新开发人员和非开发人员也同样容易访问。
opensource.dev 站点链接到 [OSI 的许可证页面]。
有 [一些讨论][cowan_epl] 关于 EPL 和 CDDL 是否
真的应该在流行的许可证列表中。
虽然没有人不同意 CDDL，
[Mike Milinkovich (Eclipse 基金会)][milinkovich_epl]
指出许多 Eclipse 项目
是一个使用 EPL 的强大社区
– 尽管有些人可能 [不同意][glaser_epl]
基金会是否是一个社区。
[dibona]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020193.html
[morrison_opensource.dev]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020198.html
[cowan_epl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020202.html
[OSI’s licenses page]: https://open-source.org.cn/licenses
[milinkovich_epl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020204.html
[glaser_epl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020207.html
## 开放数据
[Christopher Sean Morrison][morrison_open]
宣布美国已签署一项新的开放数据法生效。
[Gil Yehuda][yehuda_open] 想知道
是否存在一个被广泛接受的开放数据定义，
类似于 OSD 和软件的四个自由？
[Sander van der Waal (开放知识基金会, OKFN)][SvdW_open]
指向 OKFN 的
它受到了 OSD 的启发。
OKFN 还为开放数据许可证提供许可证审查流程。
但是，知识共享许可证的第 4 版
可能会使特殊的开放数据许可证变得不必要。
（注意：例如，CCv4 也考虑了数据库权利。）
[morrison_open]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020219.html
[yehuda_open]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020220.html
[SvdW_open]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020222.html
## AFL “署名声明”
[Antoine Thomas (PrestaShop)][thomas_afl]
请求澄清
衍生作品应如何在学术自由许可下提供署名
在学术自由许可下。
没有人在线回复 🙁
[thomas_afl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020221.html
## 开源中的亲密性
[Gil Yehuda][yehuda_intimacy] 询问 (A)GPLv3 中“亲密数据通信”是什么意思。
“亲密数据通信”是什么意思。
例如，数据库客户端/驱动程序
是否与数据库服务器没有亲密通信？
或者它们是完全独立的作品？
[Lawrence Rosen][rosen_intimate] 也提出了这个问题
这如何与 API 可版权性相互作用
以及这对网络著作权强制许可（如 AGPL 和 SSPL）意味着什么。
随之而来的是广泛的讨论。
[yehuda_intimacy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020208.html
[rosen_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020224.html
### 流程和接口边界
[John Cowan][cowan_intimate] 认为
当数据结构在内存中共享时，通信是亲密的。
调用 shell 不算作亲密
因为那使用了软件的标准接口。
（注意：虽然结论似乎是正确的，
但 GPL 对标准接口的定义更狭窄。）
[Luis Villa][villa_intimate] 同意 Cowan 的观点
甚至建议通过明确定义的接口进行通信
不能是亲密的。
[Nicholas Weinstock][weinstock_ccs] 认为
这种观点是有道理的
并且可以解释下游用户为何/何时受 (A)GPL 约束，
但想知道这是否会与“Torvalds 例外”相悖
（一项声明，用户空间程序
不是 Linux 内核的衍生品）。
[Bruce Perens][perens_downstream]
证实了 Weinstock 的理解，即著作权强制许可会影响下游使用，
但指出 Torvalds 例外与其说是例外
不如说是对 GPL 本来含义的澄清。
Perens 警告说，如果 API 确实具有可版权性（参见 Oracle 诉 Google）
那么动态链接
不会使下游用户免受 GPL 覆盖代码的影响。
总的来说，[Perens 赞同][perens_intent] 这样的观点，即
当使用公共 API 时，亲密性不适用
“程序员希望您使用 API
连接到其他程序”并且
“亲密性需要侵入程序的内部结构
超出为程序员发布的 API。”
但是有了 API 可版权性，
“创建衍生作品不需要亲密性”
并且一个软件将是衍生的
“即使它仅使用库发布的 API。”
[Weinstock][weinstock_intext] 指出
内部 API 和外部 API 之间的区别并不明确，
例如，当一个分支可以公开以前的内部 API 时。
[cowan_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020209.html
[villa_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020210.html
[perens_downstream]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020228.html
[weinstock_intext]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020232.html
### 相应源代码
[Lukas Atkinson][atkinson_intimate] 指出
GPL 仅在讨论亲密通信
作为软件的相应源代码中必须包含内容的一个例子。
相应源代码必须包括所有必要的内容
来构建、安装和运行软件，即任何 *上游* 依赖项。
当查看软件的 *下游* 使用情况时，谈论亲密通信或不同类型的链接
是没有意义的
GPL 没有也不能定义什么是衍生作品，
因为那是版权法的工作。
[Nicholas Weinstock][weinstock_ccs]
询问这是否意味着 GPL 应用程序
被禁止依赖不兼容许可的库，
以及非必要的库是否不属于亲密关系。
[Bruce Perens][perens_resp]
同意 Atkinson 对相应源代码的理解
并确认
GPL 软件的依赖项必须使用兼容的许可证。
[Perens 补充说][perens_intent] GPL 附加许可机制
可用于避免一些不兼容性。
[atkinson_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020215.html
[weinstock_ccs]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020227.html
[perens_resp]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020228.html
[perens_intent]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020231.html
### FSF 引入一个新词是否是个问题？
有人不满 GPLv3 引入了术语“亲密性”
这个词在许可证或法律用法中都没有定义。
这样一个模糊的词语带来了法律上的不确定性，
并且可能 [劝退][rosen_intimate] (A)GPL 的使用。
因此，许多人希望看到 FSF 发表明确声明
关于这个词的含义，
特别是关于两个程序何时执行亲密通信。
[Bruce Perens][perens_was_there] 解释了为什么这不会发生
GPL 试图 [阻止规避许可证的尝试][perens_nope]，
所以它不会使用狭隘的语言。
作为一项策略，FSF 不会发布此类澄清
因为那会限制他们。
他们希望能够使用
[管辖范围内可用的最大解释][perens_downstream]。
[Scott Peterson][peterson_intimate] 指出
GPL 常见问题解答中讨论亲密性的示例
以及 [GPLv3 基本原理文档]。
许可证草案最初谈到
“复杂”数据通信，但这被认为暗示了不正确的解释
> “亲密”是我们所知道的最有用的术语
> 来描述那种曲折的交互和深入的了解
> 这表明一个部分是专门设计
> 为需要另一部分。
[Lawrence Rosen][rosen_gpl3rationale] 对
“曲折的交互”和“深入的了解”的法律相关性持怀疑态度
并认为相应源代码的概念
是“GPLv3 草案中最糟糕的错误。”
[John Cowan][cowan_readline] 认为
“设计为需要”是一个有用的测试。
Cowan 指出 CLISP，它在 GPL 下可用
因为它需要 readline 库。
但是当考虑替代实现时，事情变得模糊不清
一个使用替代实现的程序
是否被设计为需要（GPL 覆盖程序的接口）？
FSF 似乎是这样认为的，
导致了不同 API 和兼容性包装器的激增。
[perens_was_there]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020246.html
[peterson_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020216.html
[GPLv3 rationale documents]: http://gplv3.fsf.org/gpl3-dd3-rationale.pdf
[rosen_gpl3rationale]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020217.html
[cowan_readline]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020218.html
[perens_nope]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020233.html
### 理解法律和明确界限
在与工程师交谈时，[Nicholas Weinstock][weinstock_ccs]
也听到了一些关于这里亲密性可能意味着什么的其他想法
也许两个程序如果它们的交互是共同开发的，那么它们就是亲密的？
或者“亲密”可能指的是数据类别，而不是通信机制？
[Bruce Perens][perens_resp] 警告说
法律话题不一定对工程师有意义。
许可证合规是必需的
“无论它是否符合您所在行业的传统流程。”
与其试图找到将著作权强制许可与专有代码结合使用的方法，
更好的方法是架构软件
以使它们清晰地分开。
[Rick Moen][moen] 同意
一个作品是否是衍生的，由判例法决定，
而不是由工程师或许可证决定。
并且没有理由认为
法院会对编码员关于内部或外部 API 或不同类型的链接的想法印象深刻。
关于内部或外部 API 或不同类型的链接的想法印象深刻。
这不仅关乎 GPL，还关乎使用任何类型的受版权保护的材料。
解决方案是聘请法律帮助，
支付许可证例外费用，
或者只是远离争议领域。
[John Cowan][cowan_court] 指出，一个词的行业用法
很可能与法院有关，
但不幸的是，“亲密”没有行业用法。
[Lawrence Rosen][rosen_no_true_fossman] 希望更清楚地了解
安全地允许使用著作权强制许可接口的技术架构。
“任何禁止这样做的 FOSS 许可证都不是真正的开源！”
[Bruce Perens][perens_come_on] 似乎对这种态度有点厌烦
一些许可证明确旨在
防止与专有软件结合使用。
“开源并没有说
他们必须给任何人免费搭车”。
合适的架构显然避免了衍生作品
并保持一条“明确界限”，这对“任何法院都非常清楚”。
[Gil Yehuda][yehuda_nolawyer] 认为
如果创建一个合规的架构需要律师，
那就是许可证的问题。
（注意：但是这个讨论是关于 *避免* 需要许可证合规的架构！）
（注意：但是这个讨论是关于 *避免* 需要许可证合规的架构！）
没有许可证可以是简单的，正如 [Perens][perens_simple] 指出的那样，
因为这些法律文件建立在大量的判例法基础上。
即使是简单的文档也可能产生复杂的结果，
例如 BSD 许可证中的隐含专利授权。
[moen]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020241.html
[rosen_no_true_fossman]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020237.html
[perens_come_on]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020236.html
[cowan_court]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020244.html
[yehuda_nolawyer]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020245.html
[perens_simple]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020247.html
### 伟大的期望
[Gil Yehuda][yehuda_tale_of_two] 认为
区分使用著作权强制许可的两种不同动机很重要
有些人想要自由软件，
但其他人想要一个许可证
该许可证足够宽松，可以看到他们的软件被广泛采用，
但仍然受到充分限制，可以将一些用户转换为商业许可证。
双重许可没有任何问题
（事实上，[Bruce Perens][perens_dual_funding]
认为双重许可是有益的
因为它资助了更多开源软件的生产）
但是当双重许可企业使用自由软件许可证时，出现误解和挫败感是不足为奇的。
当双重许可企业使用自由软件许可证时，出现误解和挫败感是不足为奇的。
例如，Lawrence Rosen 多次建议
他的 OSL 3.0 作为比 AGPL 更温和的网络著作权强制许可。
[Rosen 提醒][rosen_more] 开源不仅仅是 GPL。
许多其他许可证正在被提出
因为 GPL 没有满足这些许可方的动机。
“也许我们应该考虑 SSPL 许可方的意图
并帮助他们创建或使用替代的非 GPL 许可证？”
[Bruce Perens][perens_beyond] 指出 SSPL 也远远超出了 OSL 的范围。
[他写道][perens_move_on]
“不幸的是，这些公司想要做的很多事情
无法作为开源实现，
最好各方都理解这一点并继续前进。”
[yehuda_tale_of_two]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020251.html
[perens_dual_funding]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020246.html
[rosen_more]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020254.html
[perens_beyond]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020255.html
[perens_move_on]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020252.html
## 重新许可和维护者-社区动态
在许可证审查列表上关于 C-FSL 的讨论之外，
形成了一个关于
维护者-社区动态、
分支和许可证变更的历史示例的讨论。
对于背景信息，C-FSL 赋予了一些原始作者
更改代码许可的权利，
而无需获得所有版权持有者的额外许可。
许可证变更的典型机制
是联系所有版权持有者。
如果少数版权持有者拒绝更改，
他们的贡献可以被删除。
这是可行的，正如历史所指出的那样
Dungeon Crawl、Toybox、Mozilla、OpenSSL、OpenStreetMap 被
[Brendan Hickey][hickey_relicensing]
和 [Rob Landley][landley_relicensing] 提及。
[Rob Landley][landley_epic]
写了一封史诗般的电子邮件，其中包含许多项目历史。
分支不一定是某些项目的替代版本，
但也可能是一个现有社区围绕其团结起来的新项目。
例如，Linux 可以被解释为 Minix 社区的一个分支。
特别值得关注的是 XFree86，
它遭受了管理层的重新许可。
但是：“代码幸存下来，在新的维护和新名称下分叉，
与许多相同的开发人员
并继承了几乎所有用户。”
展望未来，[Landley 问道][landley_methods]
“坏事 *无论如何* 发生了。
什么样的组织方法 *幸存* 了坏事？”
[Bruce Perens][perens_abscond] 指出
“对于开源许可证来说，开发者可以逃离糟糕的管理，这绝对是一个非常好的和重要的特性。”
“对于开源许可证来说，开发者可以逃离糟糕的管理，这绝对是一个非常好的和重要的特性。”
对于 C-FSL，这意味着给予一组维护者过多的权力
以防止分支为目的可能是一个非常糟糕的主意。
以防止分支为目的可能是一个非常糟糕的主意。
对于 MongoDB 的重新许可，[仍有待观察][landley_mongodb]
社区是留在原始项目还是转移到分支。
[John Cowan][cowan_fork] 警告说，分支可能有许多命运
虽然有些可能会吞噬其父项并继承名称（如 GCC 3）
或以不同的名称吞噬其父项（如 LibreOffice）
有些也会逐渐消失（如 MySQL 中的 Drizzle）。
但是“开源软件
不一定需要开源开发”。
如果软件是以教堂式而不是社区的方式维护的，
那么给予原始开发者特殊权利可能没什么大不了的。
（注意：但是如果原始维护者不再是好的管理者怎么办？
请参阅上面的 XFree86。）
[hickey_relicensing]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003897.html
[landley_relicensing]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003898.html
[landley_epic]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003900.html
[landley_methods]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003906.html
[perens_abscond]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003903.html
[landley_mongodb]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003939.html
[cowan_fork]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003907.html
## 开发新的开源许可证
Van Lindberg [[1][vanl_ann],[2][vanl_classpath]] 宣布
他正在为 Holo Ltd. 起草一个新的开源许可证
并将提交给 OSI 批准。
该许可证将类似于 AGPL
但可以选择 LGPL/Classpath 风格的例外。
[Bruce Perens][perens_aal] 注意到
该许可证计划扩展到
所有“实现兼容 API”的软件。
这种著作权强制许可的扩展将违反
OSD #9 “许可证不得限制其他软件”
并且 OSI 似乎不希望批准。
[Van Lindberg][vanl_careful_interface] 理解
并试图在这方面谨慎行事，
特别是考虑到他曾批评 SSPL 的类似问题。
但是如果接口是可版权的（参见 Oracle 诉 Google）
那么这样的要求只会影响衍生作品，
而不是不相关的软件。
VanL 不会定义接口
而是 [考虑公共表演权][vanl_performance]。
这类似于 AGPL 网络交互条款，
但更符合版权。
（注意：我反而会说 AGPL
只是选择使用公共表演的一个小方面。）
[Bruce Perens][perens_extensions]
对任何著作权强制许可/版权的扩展持怀疑态度，
并以开放硬件为例。
风险在于法院可能会认为这是有效的，
从而扩展版权。
但这将产生抑制作用，尤其是在开放硬件方面。
“扩展版权对开源不利，
即使它帮助我们更有效地执行许可证。
它总是会在更大程度上对我们不利
[比] 它可以为我们所用。”
[vanl_ann]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020257.html
[vanl_classpath]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020258.html
[perens_aal]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020259.html
[vanl_careful_interface]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020264.html
[vanl_performance]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020263.html
[perens_extensions]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020261.html