2016 年开源领域 7 项值得关注的法律进展

我们来看看 2016 年一些与开源相关的法律进展,这些进展曾成为头条新闻。
633 位读者喜欢这篇文章。
7 notable legal developments in open source in 2016

互联网档案馆图书图片。由 Opensource.com 修改。CC BY-SA 4.0

2016 年,开源领域发生了一些有趣且值得关注的法律进展。以下是七个突出的法律新闻故事

1. 谷歌在 Java API 案件中赢得合理使用权

2012 年,在首次 Oracle 诉 Google 审判中,陪审团裁定谷歌在 Android 中包含 Java 核心库 API 侵犯了 Oracle 的版权。地方法院推翻了该判决,认为 API 本身不具有版权(无论是作为单独的方法声明还是其“结构、顺序和组织”[SSO])。联邦巡回上诉法院适用第九巡回法院法律,推翻了这一裁决,认为“37 个 Java API 包的声明代码和 [SSO] 有权获得版权保护。” 美国最高法院拒绝复审此案,2016 年就谷歌的合理使用抗辩进行了第二次备受关注的审判。2016 年 5 月,陪审团一致裁定谷歌胜诉。

正如 Jeff Kaufman 解释的那样,该判决并未改变关于 API 版权的上诉裁决,但其先例意义有限。合理使用涉及高度具体的案件事实认定,该判决没有明显的更广泛的法律意义。尽管如此,结果对谷歌来说是一次明显的胜利。Oracle 已提起上诉。

虽然 Oracle 诉 Google 本身不是“关于开源的案件”,但值得注意的是,双方都是围绕 Java 开发的相关开源平台的管理者。Oracle 领导 OpenJDK 项目,如果我们将本案中涉及的 API 视为具有版权,则这些 API 在 GPLv2 以及 Classpath 例外下获得许可。Android 平台并未实现所有 Java 核心库 API,其大部分在 Apache License 2.0 下获得许可。它的 Java 核心库 API 实现通常来自 Apache Harmony 项目,该项目最初旨在开发开源 Java 运行时,先于 OpenJDK。去年年底,谷歌证实 Android Nougat 将使用来自 OpenJDK 的 GPL 许可的类库代码,以取代 Apache Harmony 代码。

2. Patrick McHardy 受到谴责

自 2014 年以来,一直有传言称,Linux 内核开发者 Patrick McHardy(曾任 Netfilter 核心团队主席)在德国对多家公司提起了 GPL 执行诉讼。最近的 Black Duck/DLA Piper 幻灯片中讨论了 McHardy 的诉讼。

直到 2016 年,对 McHardy 的诉讼进行公开讨论在某种程度上是一种禁忌。这种情况在 7 月 18 日结束,当时 Netfilter 项目宣布将“暂停”McHardy 在 Netfilter 核心团队的职务,这是其首次采取此类行动,原因是“针对他的许可执行活动风格提出了严厉指控。” 尽管核心团队没有关于这些指控的第一手证据,但这些指控是一致的,并且来自“可信来源”,他们指出,尽管多次尝试联系 McHardy,但他没有回应。该公告以核心团队成员的名义发布,其中包括荣誉成员 Harald Welte,他以在德国发起一系列成功的 GPL 执行诉讼而闻名。

几周前,Netfilter 核心团队发布了一份声明,正式认可了软件自由保护协会和 FSF 于 2015 年发布的社区导向型 GPL 执行原则。核心团队表示,“许可执行是确保所有各方都遵守许可中规定的一套公平规则的必要工具”,但随后,大概是指 McHardy,他们宣布“任何执行行动都应始终以合规为重点,绝不应将经济利益置于首位,绝不应满足于低于合规的条件,并且只有在万不得已的情况下才考虑采取法律诉讼。” 在 7 月 18 日宣布暂停 McHardy 职务的公告中,核心团队表示,McHardy “只要能够回应这些指控和/或在任何未来的执行活动方面共同签署 [保护协会/FSF 原则],仍然欢迎他回到项目中。”

第二天,软件自由保护协会的 Karen Sandler 和 Bradley Kuhn 发表了一篇博客文章,讨论了 McHardy 的主题。他们透露,保护协会在两年内与 McHardy 进行了基本上不成功的沟通尝试。保护协会鼓励 McHardy 与他们共同起草原则,并在原则发布后邀请他认可这些原则,但没有收到他的任何回应。Sandler 和 Kuhn 谴责 McHardy 显然拒绝认可这些原则,并且未能公开为其 GPL 执行行为辩护。

3. Hellwig 诉讼被驳回

2015 年,Linux 内核开发者 Christoph Hellwig 在德国地方法院对 VMware 提起版权侵权诉讼,指控 VMware 的 ESXi 产品违反了 GPL。Hellwig 的法律费用由软件自由保护协会资助。Hellwig 诉讼引起了广泛关注,因为它显然是第一个以诉讼方式解决的 GPL 合规性案件,该案件的中心问题是 GPL 的反向许可要求的范围,有时被认为是“衍生作品”问题。

正如 Scott Peterson 报道的那样,2016 年 7 月,法院驳回了该案件,结论是 Hellwig 未能在 VMware 产品中指出他拥有版权的具体代码行。法院讨论了 GPL 问题,但并未讨论案情实质。该裁决对其他案件没有先例意义。Hellwig 在一份简短声明中宣布,他将对该裁决提出上诉。

4. 美国政府宣布联邦源代码政策

8 月,美国政府管理和预算办公室宣布了联邦源代码政策。该政策旨在减少各机构重复采购基本相似代码的问题,并确保新的定制开发的联邦源代码能够广泛用于整个联邦政府的再利用。Mark Bohannon 撰写了一篇关于该政策的文章

联邦源代码政策建立了一个为期三年的试点计划,要求各机构(除某些例外情况外)每年将至少 20% 的新定制开发软件作为开源软件发布。该政策认识到开源是实现持续改进的一种手段,这种改进源于更广泛的社区对软件的改进。该政策还宣布启动 code.gov,这是一个定制开发代码的“发现门户”,包括根据该政策作为开源发布的代码。

联邦源代码政策的显著之处在于,它强调遵守开放开发的适当标准以及开源许可。指示发布开源代码的机构以鼓励与现有社区互动、促进新社区发展以及促进社区对联邦代码以及联邦雇员和承包商对上游项目的贡献的方式进行发布。各机构还必须确保其开源存储库包含足够的信息,以方便第三方重用和参与,包括许可方面的详细信息。

5. Moglen 卸任 FSF 总法律顾问

自由软件基金会宣布 2016 年 10 月,Eben Moglen 已“卸任”FSF 总法律顾问。Moglen 是软件自由法律中心主席和哥伦比亚大学法学教授,他是自由软件领域最有影响力的律师之一。他在自由软件领域的职业生涯在公众心目中与 FSF 密切相关,他为 FSF 提供了 23 年的无偿法律代理。我预计 Moglen 和 FSF 都将一如既往地参与自由软件法律政策事务,但可能会出现更多公开分歧或意见冲突的情况。

6. Debian 和 Ubuntu 发布 ZFS

在 2000 年代中期,Sun Microsystems 发布了其 ZFS 文件系统,作为 OpenSolaris 的一部分,该文件系统在弱反向许可 CDDL 下获得许可。多年来,将 ZFS 移植到 Linux 的努力受到了法律问题的阻碍,包括关于 GPLv2 和 CDDL 之间许可冲突的担忧。近年来,“ZFS on Linux”项目鼓励 Linux 发行版打包其 ZFS 内核模块。

虽然 Debian 中 ZFS 的打包工作因许可问题而搁置了一段时间,但在 2015 年,Debian 项目负责人 Lucas Nussbaum 透露 Debian 已收到软件自由法律中心关于将 ZFS 包含在 Debian 中的法律建议,他说这“应该会解除困境... 并使我们能够尽快在 Debian 中发布 [ZFS]。” 2016 年 1 月,Nussbaum 的继任者 Neil McGovern 表示 ZFS 将作为 DKMS 软件包包含在 Debian 中,仅以源代码形式提供,并将隔离在“contrib”存档中,该存档包含不被视为官方 Debian 的软件包。

在 Debian 开始这样做之前,Ubuntu 已经包含了一个仅限源代码的 DKMS ZFS 软件包一段时间了。在 2 月份的一篇博客文章中,Canonical 的 Dustin Kirkland 宣布 Ubuntu 将开始发布二进制 ZFS 内核模块。在就 GPL/CDDL 问题进行了一系列辩论之后,Kirkland 在另一篇博客文章中表示,Canonical 已与 Eben Moglen(SFLC 主席)讨论了法律问题,并得出结论,二进制内核模块的发布将符合 GPLv2 和 CDDL。Kirkland 强调,ZFS 模块是“独立的”,不是内核的衍生作品,内核也不是 ZFS 的衍生作品。Kirkland 还认为,“对于许多其他独立的、自包含的、非 GPL 内核模块,也存在类似的例外情况,多年来一直如此。”

在 Kirkland 的第二篇博客文章发布后不久,软件自由保护协会和 SFLC 发布了相互冲突的 分析,分析了 Canonical 发行的合法性。(对于那些不了解的人:SFLC 和保护协会是独立的组织。)然而,他们在两个基本点上达成了一致:(1)Debian 在 contrib 中发布仅限源代码的模块是符合许可的,以及(2)可加载内核模块通常属于内核上 GPL 反向许可的范围。

保护协会声称代表其自身作为 Linux 内核版权受让人以及代表参与其 Linux 开发者 GPL 合规性项目的内核版权持有者发言。保护协会认为,Canonical 发布二进制内核模块违反了 GPLv2,因此侵犯了内核的版权。保护协会认为,涉及 GPL 许可与其他自由软件许可不兼容的衍生作品应与 GPL/专有组合进行相同的法律分析。

根据 SFLC 的说法,Canonical 的二进制 ZFS 模块必须被视为在 GPLv2 下获得许可,因为 CDDL 允许二进制文件在任何许可下,任何其他解释都会假设 Canonical 不符合 GPL。因此,ZFS 二进制模块本身的发布不会违反 GPLv2;但是,Canonical 对 ZFS 内核模块和 Ubuntu 内核的原本合规的相应源代码发布将“字面意义上”违反 GPLv2,因为 Canonical 将根据 CDDL 提供 ZFS 文件系统源代码。GPL 项目的版权持有者社区有充分理由不反对这种字面意义上的 GPLv2 违规行为,因为该行为符合许可的精神或“公平”。

在 SFLC 看来,鉴于 GPLv2 的字面解释和公平解释之间的张力,“内核版权持有者意图的共识……决定了应采用哪种解释模式。” 在这里,没有关于内核版权持有者意图何种类型解释的决定性或令人信服的证据。SFLC 认为,只要内核版权持有者选择不反对 Canonical 的发布,就应假定内核许可者的共识是支持公平解释。SFLC 还指出,Canonical 的潜在责任风险微乎其微。

Neil McGovern 在 DebConf 的一次演讲中讨论了他作为 Debian 项目负责人在 ZFS 主题上的经验。关于 ZFS 问题的其他值得注意的声明是由 Richard Stallman 和 Linux 内核开发者 James Bottomley 提出的。近几个月来,关于这个问题的讨论很少。

7. Apache 软件基金会禁用 JSON 许可证

对于我们这些参与开源法律事务的人来说,Douglas CrockfordJSON 许可证 像一枚劣币一样不断出现。JSON 许可证以在保证免责声明之前添加一句话而闻名,即:“本软件应用于善,而非恶。” 不清楚 Crockford 是否纯粹将该许可证视为一个玩笑,还是作为一种隐晦的政治声明,或者两者兼而有之。许多关心为将许可证归类为自由许可证或开源许可证奠定原则基础的人认为,“应用于善,而非恶”条款与基本定义规范相冲突,这些规范不允许使用领域限制和基于努力领域的歧视。有些人认为该条款不可执行,因此不应认真对待;但是,将 JSON 许可证归类为非自由许可证的 FSF 认为,不能假定该限制不可执行。对该许可证的另一个反对意见是,“善”和“恶”是未定义的,因此允许和禁止的行为范围高度不确定。

JSON 许可证并非完全默默无闻的原因是 Crockford 已将其应用于恰好已被广泛采用的软件,包括工具 JSLintJSMin 以及 JSON Java 库(“JSON-java”)。多年来,Crockford 拒绝了开发人员提出的许多更改许可证的请求,尽管他 吹嘘 曾特别允许 IBM 及其“客户、合作伙伴和爪牙将 JSLint 用于邪恶目的。”

多年来,Apache 软件基金会以其严格的许可规则而闻名,例如,GPL 和 LGPL 被降级为被禁止的“X 类”,它将 JSON-java 视为处于其最受青睐的“A 类”(其中包含非反向许可,例如 Apache License 2.0 本身)。如今,多个 ASF 项目都依赖于 JSON 许可证。2016 年 10 月,在 发布 到 ASF 的 legal-discuss 邮件列表后,Ted Dunning 呼吁 ASF 重新审视其决定,并指出 JSON 许可证“严重阻碍了下游采用”。经过讨论,ASF 法律事务副总裁 Jim Jagielski 宣布 “该许可证不是 CatA,也没有获得批准”,将 JSON 许可证置于 X 类。Jagielski 后来澄清,ASF 项目不允许新使用 JSON 许可证,但一些已经使用该许可证下代码的项目将有几个月的宽限期来过渡到替代方案。2016 年 11 月的 LWN.net 文章 报道了这个问题。

由于许多 ASF 项目已被广泛采用,因此 JSON 许可证禁令似乎很可能对社区产生重大影响,鼓励使用开源替代方案来替代 JSON 许可的软件。

Richard Fontana
Richard 是红帽法律部门产品和技术团队的高级商务律师。他的大部分工作都侧重于与开源相关的法律问题。

3 条评论

精彩回顾。我想知道社区对 BSL [1] 的看法。虽然不是新的(2013 年),但我认为,鉴于去年左右对开源的资金/商业模式的关注度增加,对后现代许可进行有价值的待定辩论是值得的,正如 Eghbal、Okoli/Nguyen 等人所涵盖的那样。人们可能未经证实地接受了成熟的开源许可证将在未来十年继续存在,因为它们已经度过了周期,但在即将到来的阶段可能会面临更大的压力。

[1] http://monty-says.blogspot.com/2016/08/applying-business-source-licensi…

摆脱 JSON 许可证的关键是拥有可行的替代方案。

这就是为什么我更新了 Android 对 JSON-java 的洁净室重新实现,以便在 Maven 中心提供一个具有清洁许可的替代克隆库。

有关更多信息,请参阅 https://github.com/tdunning/open-json

回复 作者:匿名懦夫(未验证)

知识共享许可协议本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.