像往年一样，法律问题在 2017 年的开源世界中是一个热门话题。虽然我们已经深入到今年的第一季度，但回顾一下去年开源领域最重要的法律新闻仍然值得。
1. GitHub 修订服务条款
2017 年 2 月，GitHub 宣布 它正在修订其服务条款，并就这些变更征求意见，其中几项变更涉及用户上传内容的权利。早期 GitHub 条款 包括用户同意允许他人“查看和 Fork”公共仓库，以及保护 GitHub 免受第三方索赔的赔偿条款。新条款增加了一项用户授予 GitHub 的许可，允许其存储和服务内容，默认的 “入站=出站” 贡献者许可，以及用户同意遵守涵盖上传内容的第三方许可的协议。在保留“查看和 Fork”语言的同时，新条款声明，通过采用开源许可证可以授予更多权利。这些条款还增加了一项 精神权利 的豁免，并附带两级后备许可，第二级许可授予 GitHub 许可，允许其在不署名的情况下使用内容，并进行合理的调整“以渲染网站和提供服务”。
3 月，在新条款生效后，一些开发者提出了担忧，特别是 Thorsten Glaser 和 Joey Hess，他们表示将从 GitHub 中删除他们的仓库。正如 Glaser 和 Hess 理解的新条款，它们似乎要求用户授予 GitHub 和其他用户比第三方许可证允许的更广泛的权利，特别是像 GPL 这样的 Copyleft 许可证和要求署名的许可证。此外，授予 GitHub 的许可证可以被解读为在用户自己的内容中给予它比普通用户在名义许可证下获得的更有利的许可。自由软件基金会 (FSF) 的 Donald Robertson 写道，虽然 GitHub 的条款令人困惑，但它们与 Copyleft 并不冲突：“因为 GitHub 极不可能打算破坏他们的商业模式和用户群，所以我们不认为条款中的歧义是授予或要求超出 GPL 已经授予的过于广泛的权限。”
GitHub 最终添加了一句话来解决这个问题；可以在 当前版本 的条款中看到：“如果您上传的内容已经附带了授予 GitHub 运行我们的服务所需的权限的许可证，则无需额外的许可证。”
2. 内核执行声明
GPLv2 第 4 节 规定，对于违反许可证条款的人，权利将自动终止。到 2006 年，FSF 已经开始认为，在无意违规的情况下，该条款过于严厉。GPLv3 修改了 GPLv2 的终止方法，为首次违规者提供了 30 天的补救机会，以及 60 天的冷静期。许多像 Linux 内核这样的 GPL 项目继续在 GPLv2 下获得许可。
正如我去年 写道，2016 年，前 Netfilter 贡献者 Patrick McHardy 的 GPL 执行策略受到了公众谴责。为了进一步回应 McHardy 的行为，由个人内核开发者选举产生的 Linux 基金会 技术咨询委员会 (TAB) 起草了一份 Linux 内核执行声明，Greg Kroah-Hartman 于 2017 年 10 月 16 日在 Linux 内核邮件列表 (LKML) 上 宣布 了该声明。声明 现已成为内核文档目录的一部分，它逐字纳入了 GPLv3 的补救和冷静期语言，作为“代表我们自己以及我们版权权益的任何继任者对 Linux 内核用户的承诺”。该承诺被描述为根据 GPLv2 授予的额外许可，适用于非防御性地主张 GPLv2 权利的情况。内核声明实际上采纳了 社区导向型 GPL 执行原则 中的建议。迄今为止，该声明已获得 100 多名内核开发者的签署。Kroah-Hartman 发布了一个关于该声明的 常见问题解答 和一份由几位 TAB 成员撰写的详细 解释。
3. 红帽、Facebook、谷歌和 IBM 宣布 GPLv2/LGPLv2.x 补救承诺
在 LKML 上宣布内核执行声明一个月后，由红帽领导，包括 Facebook、谷歌和 IBM 在内的公司联盟 宣布 他们自己承诺 将 GPLv3 的补救 和冷静期机会扩展到其版权涵盖并根据 GPLv2、LGPLv2 和 LGPLv2.1 许可的所有代码。（LGPLv2.x 中的终止条款与 GPLv2 中的条款基本相同。）与内核声明一样，该承诺不适用于防御性诉讼或为回应某些先前的诉讼或索赔而提出的索赔（例如，专利侵权诉讼中的 GPL 违规反诉，如 Twin Peaks Software v. Red Hat 中发生的那样）。
4. EPL 2.0 发布
Eclipse 公共许可证 1.0 版，这是一种弱 Copyleft 许可证，它源于 通用公共许可证，并间接源于 IBM 公共许可证，一直是 Eclipse 基金会项目的主要许可证。它在 Eclipse 之外也得到了广泛使用；例如，EPL 是 Clojure 语言实现的许可证和 Clojure 社区首选的开源许可证，并且是 OpenDaylight 的主要许可证。
经过两年平静的社区审查过程后，Eclipse 基金会在 2017 年 8 月 宣布，EPL 的新版本 2 已获得 Eclipse 基金会董事会和 OSI 的批准。Eclipse 基金会计划将 EPL 2.0 作为 Eclipse 社区项目的默认许可证。
EPL 2.0 是一个相当保守的许可证修订版。也许最值得注意的改变是关于 GPL 兼容性。FSF 和 Eclipse 基金会 都认为 EPL 1.0 与 GPL 不兼容。FSF 认为，这至少是因为这两个许可证中存在冲突的 Copyleft 要求，以及（更值得怀疑的是）EPL 1.0 中的法律选择条款，该条款已在 EPL 2.0 中删除。作为一种弱 Copyleft 许可证，EPL 通常要求至少部分衍生作品以源代码形式分发时，必须在 EPL 下获得许可。FSF 和 Eclipse 几年前发布了关于将 GPL 用于 Eclipse IDE 插件的意见。除了许可证兼容性问题外，Eclipse 基金会通常禁止项目在 GPL 和 LGPL 下分发第三方代码。
虽然 EPL 2.0 默认情况下仍然与 GPL 不兼容，但它允许初始“贡献者”授权在“辅助许可证”——GPLv2、GPLv3 或更高版本的 GPL 下许可 EPL 覆盖的源代码，其中可能包括已识别的 GPL 例外或附加权限，如 Classpath Exception——如果 EPL 覆盖的代码与单独文件中包含的 GPL 许可代码组合在一起。一些 Eclipse 项目已经重新许可为 EPL 2.0，并且正在使用此“辅助许可证”功能，包括 OMR 和 OpenJ9。正如 FSF 观察到，辅助许可证功能的调用大致相当于在 EPL/GPL 下双重许可代码。
5. Java EE 迁移到 Eclipse
Java 社区流程 (JCP) 促进了 Java 技术规范（Java 规范请求，又名 JSR）的开发，包括定义 Java 企业版 平台 (Java EE) 的规范。JCP 建立在以 Java 规范参与协议 (JSPA) 为中心的复杂法律架构之上。虽然 JCP 治理由多个组织和个人参与者共享，但 JCP 绝不是供应商中立的。Oracle 拥有 Java 商标，并对 JCP 具有特殊控制权。几年前通过了一些 JCP 改革，包括强制要求 JSR 参考实现 (RI) 采用开源许可证和开源项目开发实践的措施，但在 Oracle 诉 Google 诉讼期间，JSPA 现代化的努力停滞不前。
2017 年 8 月，Oracle 宣布将探索 将 Java EE 迁移 到开源基金会。在与 Java EE 的另外两个主要贡献者 IBM 和红帽协商后，Oracle 在 9 月宣布，它已 选择 Eclipse 基金会 来托管 Java EE 的继任者。
从那时起，迁移到 Eclipse 的工作一直在进行中。Eclipse 董事会批准了一个新的顶级 Eclipse 项目，EE4J (Eclipse Enterprise for Java)，作为开发继任平台 RI 和技术兼容性套件 (TCK) 的总括项目。GlassFish 项目由 Oracle 作为规范领导的大多数 Java EE JSR 的 RI 源代码组成，主要在 CDDL 和 GPLv2 以及 Classpath Exception 的双重许可下。Oracle 正在 将此代码重新许可 为 EPL 2.0，并将 GPLv2 以及 Classpath Exception 作为辅助许可证（参见 EPL 2.0 主题）。此外，预计 Oracle 将重新许可专有的 Java EE TCK，以便它们可以作为 Eclipse 开源项目进行开发。仍有待确定的是，取代 Java EE 的 Eclipse 拥有的认证标志的名称，以及取代 JSPA 中定义的规范流程的新规范流程的开发。
6. React 许可争议
专门处理专利许可的开源许可证通常将专利许可授予与“专利防御”条款结合起来，在被许可人提起某些诉讼行为时终止专利许可，这种方法借鉴了标准协议。公司对开源许可进行早期实验的特点是对广泛的专利防御条款充满热情（从某种意义上说，相对广泛的行为范围会触发终止）。2004 年 Apache License 2.0 和 Eclipse Public License 1.0 的出现标志着那个时代的结束；它们的专利终止标准基本上仅限于用户指控许可软件本身侵权的专利诉讼。
2013 年 5 月，Facebook 在 Apache License 2.0 下发布了 React JavaScript 库，但 0.12.0 版本（2014 年 10 月）切换到 3 条款 BSD 许可证，并在单独的 PATENTS 文件中附带专利许可授予。使用简单的标准许可开源许可证，并在单独的文件中使用定制专利许可证的想法在 谷歌 和 微软 维护的项目中已经有一些先例。但是，这些案例中的专利防御条款采用了狭隘的 Apache/EPL 方法。React PATENTS 语言在以下情况下终止专利许可：被许可人对 Facebook 或对任何“源于”任何 Facebook 产品的当事方提起专利侵权诉讼，即使索赔与 React 无关，以及被许可人声称 Facebook 专利无效或不可执行的情况。为了回应社区的批评，Facebook 在 2015 年 4 月 修订 了专利许可语言，但修订后的版本继续将针对 Facebook 的专利诉讼和“源于”Facebook 产品的专利诉讼作为终止标准。
Facebook 开始将 React 许可证应用于其许多社区项目。2017 年 4 月，Apache 软件基金会 (ASF) 的“法律讨论”问题跟踪器中打开了一个 问题，内容是关于 Apache Cassandra 是否可以使用 RocksDB，另一个使用 React 许可证的 Facebook 项目，作为依赖项。除了显然已经在使用 RocksDB 的其他几个 ASF 项目外，大量 ASF 项目使用了 React 本身。6 月，ASF 法律事务副总裁 Chris Mattmann 裁定，React 许可证被降级为禁止类别 X（参见我去年对 JSON 许可证 的讨论）—尽管 ASF 长期以来一直将其半受青睐的类别 B 中的具有类似广泛专利防御条款（MPL 1.1、IBM-PL、CPL）的开源许可证。 作为回应，Facebook 在 GPLv2 和 Apache License 2.0 下重新许可了 RocksDB，并在几个月后宣布它正在 重新许可 React 和其他三个具有相同许可的项目，转为 MIT 许可证。最近 Facebook 项目许可证从 React 方法更改为传统开源许可证的包括 osquery (GPLv2 / Apache License 2.0) 和 React Native (MIT)。
社区对 React 许可证的大部分批评都相当不了解情况，并且常常似乎只不过是对 Facebook 的人身攻击。对该主题进行冷静、有充分理由的分析的少数例子之一是 Heather Meeker 在 Opensource.com 上的文章。无论 React 许可证可能具有哪些实际优点，Facebook 在没有使其成为许可方中立且未寻求 OSI 批准的情况下使用它都是战术错误，正如 Simon Phipps 指出的那样。
7. OpenSSL 重新许可工作
涵盖大多数 OpenSSL 的 许可证 是两个 1990 年代早期的 BSD 衍生许可证的结合。第一个许可证与 Apache Web 服务器的早期许可证非常相似。第二个许可证是 OpenSSL 的前身项目 SSLeay 的定制许可证。这两个许可证都包含一个类似于 4 条款 BSD 许可证中的广告条款。SSLeay 许可证的结尾句是对 GPL 的无端讽刺，它支持一种解释，即该许可证是 Copyleft，FSF 支持这种解释，但毫无疑问这是无意的。仅仅因为广告条款，OpenSSL 许可证长期以来一直被理解为与 GPL 不兼容，正如 Mark McLoughlin 在一篇现已成为经典的 文章 中解释的那样。
2015 年，在 Heartbleed 漏洞披露和 Linux 基金会随后成立 核心基础设施倡议 一年后，Rich Salz 在一篇 博客文章 中表示，OpenSSL 计划重新许可为 Apache License 2.0。OpenSSL 团队在 2017 年 3 月跟进发布了一份 新闻稿，宣布重新许可计划，并建立了一个网站，以收集该项目数百名过去贡献者对许可证变更的协议。
发送给已识别的个人贡献者的请求重新许可的电子邮件很快引起了批评，主要是因为其结尾句：“如果我们没有收到您的回复，我们将假定您不反对。” 一些人对 Theo de Raadt 称之为 “批量制造同意” 的方法提出了政策和法律方面的担忧。De Raadt 通过 发布 了一项将 GCC 重新许可为 ISC 许可证 的滑稽尝试来嘲笑这项工作。
Salz 在 6 月发布了关于重新许可工作的 更新。当时，40% 的联系贡献者做出了回应，绝大多数人赞成许可证变更，只有不到 12 人反对，共计 86 个提交，其中一半在主分支中幸存下来。Salz 详细描述了该项目为审查这些反对意见而采取的合理步骤，最终确定最多需要删除和重写 10 个提交。
8. Open Source Security 诉 Perens
Open Source Security, Inc. (OSS) 是 Brad Spengler 维护 Linux 内核的树外 grsecurity 补丁集的商业载体。2015 年，OSS 以用户不遵守 GPL 以及滥用 grsecurity 商标为由，开始 限制 付费客户访问稳定补丁集。2017 年，OSS 停止 发布任何 grsecurity 公共分支。Grsecurity 稳定补丁访问协议 确认 grsecurity 在 GPLv2 下获得许可，并且用户拥有所有 GPLv2“权利和义务”，但声明了一项政策，即如果用户在“GPL 对用户的客户的明确义务之外”重新分发补丁集或更改日志，则终止对未来更新的访问。
2017 年 6 月，Bruce Perens 发表了一篇 博客文章，声称 grsecurity 协议违反了 GPL。OSS 在加利福尼亚州北区起诉 Perens，指控其诽谤、虚假光照和不正当干预预期利益。12 月，法院 批准 了 Perens 的驳回动议，无偏见地驳回了 Perens 根据加利福尼亚州 反 SLAPP 法规提出的撤销动议，并驳回了 OSS 的部分即决判决动议。本质上，法院表示，作为非律师的意见声明，Perens 的博客文章不构成诽谤。OSS 表示打算上诉。
9. Artifex Software 诉 Hancom
Artifex Software 根据 GPL（最近是 AGPL）免费许可 Ghostscript，并根据专有许可证获得收入。2016 年 12 月，Artifex 在加利福尼亚州北区起诉了韩国办公套件软件供应商 Hancom。Artifex 声称，Hancom 已将 Ghostscript 纳入其 Hangul 文字处理程序和 Hancom Office 产品中，但未获得专有许可证或遵守 GPL。起诉书 包括违约和侵犯版权的索赔。除了金钱赔偿外，Artifex 还要求禁令救济，包括强制 Hancom 向 Hancom 的客户分发 Hangul 和 Hancom Office 的源代码的命令。
2017 年 4 月，法院 驳回 了 Hancom 的驳回动议。Hancom 的论点之一是，Artifex 没有陈述合同的存在，因为没有证明双方共同同意。法院不同意，指出有关 Hancom 使用 Ghostscript、未能获得专有许可证以及公开表示其对 Ghostscript 的使用已在 GPL 下获得许可的指控足以陈述合同的存在。此外，Artifex 关于其双重许可计划的指控被认为足以陈述违约损害赔偿。驳回动议被广泛误报和耸人听闻地报道为 GPL 本身是“可执行合同”的裁决。
9 月，法院 驳回 了 Hancom 关于违约索赔的即决判决动议。Hancom 首先辩称，作为一项法律问题，Artifex 无权获得金钱赔偿，主要是因为 GPL 合规性不需要向 Artifex 付款。法院驳回了这一论点，因为特许权使用费许可的价值和不当得利理论可以作为 Artifex 损害赔偿的衡量标准。其次，Hancom 本质上辩称，任何合同违约损害赔偿都不能基于 Hancom 首次开始违反 GPL 运送 Ghostscript 后的持续 GPL 不合规活动，因为在那一刻 Hancom 的 GPL 许可证自动终止。在驳回这一论点时，法院指出，GPLv3 的语言表明，Hancom 的 GPL 义务在其 GPL 权利终止后仍然存在。双方在 12 月达成和解。
特别感谢 Chris Gillespie 对 Artifex 案例的研究和分析。
10. SFLC/Conservancy 商标争议
2006 年，软件自由法律中心成立了一个 独立的非营利组织，并将其命名为软件自由保护协会。到 2011 年 7 月，这两个组织不再有任何共同的董事会成员、官员或雇员，SFLC 停止向 Conservancy 提供法律服务。SFLC 在 2011 年初从 USPTO 获得了 SOFTWARE FREEDOM LAW CENTER 服务商标的注册。2011 年 11 月，Conservancy 申请注册商标 SOFTWARE FREEDOM CONSERVANCY；注册于 2012 年 9 月发布。SFLC 继续由其创始人 Eben Moglen 运营，而 Conservancy 由前 SFLC 员工 Karen Sandler 和 Bradley Kuhn 管理。众所周知，这两个组织在许多重要的法律和政策问题上持有相反的立场（例如，参见我去年对 ZFS-on-Linux 问题的讨论）。
2017 年 9 月，SFLC 向 商标审判和上诉委员会 提交了一份 请愿书，要求根据 1946 年 Lanham 商标法第 14 条，15 U.S.C. § 1064，撤销 Conservancy 的商标注册，声称 Conservancy 的商标与 SFLC 的商标具有混淆性相似。11 月，Conservancy 提交了 答辩，列出了其肯定性抗辩，12 月，Conservancy 提交了关于这些抗辩的 即决判决动议。TTAB 实际上 驳回了即决判决动议，理由是 Conservancy 的答辩中的肯定性抗辩陈述不充分。
Moglen 公开 提议相互解除 所有索赔，“以换取相互不贬低的铁定协议”，包括“永久的、免版税的商标许可，供 Conservancy 保留和使用其当前名称”。Conservancy 在一篇博客文章中回应 说，它不能“接受任何包含我们不需要的商标许可的和解提议。此外，任何商标许可必然会赋予 SFLC 对我们如何开展慈善使命的永久控制权。”
SFLC 动议 允许修改其请愿书，以增加撤销的第二个理由，即 Conservancy 的商标注册是通过欺诈获得的。Conservancy 的 回应 辩称，拟议的修正案没有陈述欺诈索赔。与此同时，Conservancy 已提交了“THE SOFTWARE CONSERVANCY”的 商标申请。
1 条评论