2017 开源软件排行_震撼2017年的十大开源法律故事

2017 开源软件排行

像每年一样，法律问题在2017年是开源世界中的热门话题。虽然我们已经深入到今年第一季度，但回顾一下去年开源领域的顶级法律新闻仍然值得。

1. GitHub修改ToS

2017年2月，GitHub 宣布将修改其服务条款并邀请对此更改发表评论，其中一些涉及用户上传内容的权利。 较早的GitHub条款包括用户达成的允许其他人“查看并分叉”公共存储库的协议，以及保障GitHub免受第三方索赔的赔偿条款。 新条款将用户的许可添加到GitHub以允许其存储和提供内容，默认的“入站=出站”贡献者许可以及用户同意遵守涵盖上载内容的第三方许可的协议。 在保留“视图和分叉”语言的同时，新条款规定可以通过采用开源许可证来授予更多权利。 这些条款还通过两级回退许可证增加了对精神权利的放弃，第二个许可证授予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通过为初次违规者提供30天的治愈机会以及60天的休息时间来修改GPLv2终止方法。 许多GPL项目（如Linux内核）继续获得GPLv2的许可。

正如我去年写的那样 ，2016年公开谴责了前Netfilter贡献者Patrick McHardy的GPL实施策略。 为了进一步回应McHardy的行为，由各个内核开发人员选出的Linux Foundation 技术咨询委员会 （TAB）起草了Linux内核执行声明，该声明由Greg Kroah-Hartman在Linux内核邮件列表（LKML）上宣布 。 2017年10月16日。该声明现已成为内核的“文档”目录的一部分，其中包含GPLv3的固化和逐字放置语言，以表示“对Linux内核用户的承诺，代表我们自己和我们版权权益的任何继承人”。 该承诺被描述为根据GPLv2授予的额外许可，适用于GPLv2权利的非防御性主张。 实际上，内核声明采用了面向社区的GPL强制执行原则中的建议。 迄今为止，该声明已由100多个内核开发人员签署。 Kroah-Hartman发表了有关该声明的常见问题解答以及由TAB的几位成员撰写的详细解释 。

3.红帽，Facebook，谷歌和IBM宣布了GPLv2 / LGPLv2.x的治疗承诺

在宣布有关LKML的内核执行声明一个月后，由Red Hat领导并由Facebook，Google和IBM组成的公司联盟宣布了自己的承诺，即扩展GPLv3的解决方案，并为其版权和许可范围内的所有代码提供机会在GPLv2，LGPLv2和LGPLv2.1中。 （LGPLv2.x中的终止条款与GPLv2中的条款基本相同。）与内核声明一样，该承诺不适用于针对某些先前程序或主张而提出的防御性程序或主张（例如，违反GPL的反诉）曾在Twin Peaks Software诉Red Hat案中发生的专利侵权诉讼中。

4. EPL 2.0发布

Eclipse Public License版本1.0是弱基础的copyleft许可证，它是Common Public License的缩写，并间接来自IBM Public License ，它已成为Eclipse Foundation项目的主要许可证。 它也可以在Eclipse之外使用。 例如，EPL是Clojure语言实现的许可证，也是Clojure社区的首选开源许可证，并且是OpenDaylight的主要许可证。

在进行了为期两年的安静的社区审核过程之后，Eclipse基金会于2017年8月宣布 Eclipse基金会董事会和OSI已批准了EPL的新版本2。 Eclipse Foundation打算将EPL 2.0作为Eclipse社区项目的默认许可证。

EPL 2.0是一个相当保守的许可证修订版。 也许最值得注意的变化涉及GPL兼容性。 ESF 1.0被FSF和Eclipse Foundation都认为是GPL不兼容的。 FSF建议，这至少是由于两个许可证中的Copyleft要求存在冲突，以及（更可疑的是）EPL 1.0中的法律选择条款已在EPL 2.0中删除。 作为较弱的Copyleft许可证，如果以源代码形式分发，那么EPL通常要求至少有一部分衍生作品要按照EPL进行许可。 FSF和Eclipse几年前发表了有关将GPL用于Eclipse IDE插件的意见。 除许可证兼容性问题外，Eclipse Foundation通常禁止项目在GPL和LGPL下分发第三方代码。

尽管默认情况下EPL 2.0仍与GPL不兼容，但它使初始的“贡献者”能够根据“二级许可”（GPLv2，GPLv3或GPL的更高版本）授权EPL覆盖的源代码的许可。如果将EPL覆盖的代码与单独文件中包含的GPL许可的代码结合使用，则GPL异常或其他权限（例如， Classpath Exception）是附加的。 某些Eclipse项目已经获得了EPL 2.0的许可，并正在使用此“辅助许可证”功能，包括OMR和OpenJ9 。 正如FSF 观察到的那样 ，二级许可功能的调用大致等效于EPL / GPL下的双重许可代码。

5. Java EE迁移到Eclipse

Java社区流程 （JCP）有助于Java技术规范（Java规范请求，又名JSR）的开发，包括那些定义Java Enterprise Edition平台（Java EE）的规范。 JCP基于以Java规范参与协议（JSPA）为中心的复杂法律体系。 尽管JCP治理在多个组织和个人参与者之间共享，但JCP绝不与供应商无关。 Oracle拥有Java商标，并对JCP具有特殊控制。 几年前通过了一些JCP 改革 ，包括对JSR参考实现（RI）强制要求开放源代码许可和开放源代码项目开发实践的措施，但是在Oracle诉Google诉讼未决期间，JSPA现代化的努力停滞了。

2017年8月，Oracle宣布将探索将Java EE迁移到开放源代码基础的方法。 经过与其他两个Java EE的主要贡献者IBM和Red Hat的磋商，Oracle在9月宣布，它已选择Eclipse Foundation来容纳Java EE的后继者。

从那以后一直在向Eclipse迁移。 Eclipse董事会批准了一个新的顶级Eclipse项目EE4J （Java的Eclipse Enterprise），作为后继平台的RI和技术兼容性套件（TCK）开发的总体项目。 GlassFish项目由Oracle担任规范负责人的大多数Java EE JSR的RI的源代码组成，大多数情况下已获得CDDL和GPLv2的双重许可以及Classpath Exception。 Oracle正在使用GPLv2加上Classpath Exception作为辅助许可证将此代码重新许可给EPL 2.0（请参阅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文件中授予了专利许可。 在Google和Microsoft维护的项目中，使用简单的标准许可开放源代码许可和定制的专利许可在单独的文件中的想法具有先例。 但是，在这些情况下，专利抗辩条款采用了狭窄的Apache / EPL方法。 如果被许可人对Facebook或“任何” Facebook产品引起的任何一方提起专利侵权诉讼，即使该主张与React无关，以及被许可人声称存在专利侵权，React PATENTS语言PATENTS终止该专利许可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和3 MIT许可下的其他相同许可项目。 从React方法到常规开源许可证的最新Facebook项目许可证更改包括osquery （GPLv2 / Apache License 2.0）和React Native （MIT）。

社区对React许可证的许多批评都是误导，通常似乎只不过是针对Facebook的人身攻击。 Heather Meeker在Opensource.com上的文章是对此主题进行清醒，理性分析的几个例子之一。 正如Simon Phipps所指出的那样 ，无论React许可证有什么实际优点，Facebook决定在不使其与许可证颁发者无关且未寻求OSI批准的情况下使用它都是战术上的错误。

7. OpenSSL许可工作

涵盖大部分OpenSSL的许可证是两个1990年代老式BSD衍生许可证的结合。 第一个非常类似于Apache Web服务器的早期许可证。 第二个是OpenSSL的前身项目SSLeay的定制许可证。 这两个许可证都包含广告条款，类似于4条款BSD许可证中的广告条款。 SSLeay许可证的结尾句是GPL的免费sn语，它得到了FSF的认可，但无疑是无意的，该许可证是copyleft。 正如Mark McLoughlin在现在的经典文章中解释的那样，长期以来，仅由于广告条款，OpenSSL许可证就被认为与GPL不兼容。

在2015年披露了Heartbleed漏洞以及Linux基金会随后形成核心基础设施计划一年之后，Rich Salz在博客中表示，OpenSSL计划重新许可使用Apache License 2.0。 OpenSSL团队在2017年3月发布了一份新闻稿，宣布了重新许可计划，并建立了一个网站，以收集该项目的数百名前贡献者对许可变更的协议。

发送给确定的个人贡献者的表格电子邮件要求获得许可，很快引起了批评，主要是因为它的结尾句：“如果我们没有收到您的来信，我们将假定您没有异议。” 一些人对西奥·德·拉德（Theo de Raadt）所谓的“ 批量制造同意书 ”方法提出了政策和法律方面的关注。 德若特被嘲笑的努力张贴一个幽默的企图重新许可GCC到ISC许可证 。

萨尔茨（Salz）在6月发布了有关许可工作的最新信息。 到那时，已经有40％的联系贡献者做出了回应，其中绝大多数人赞成更改许可证，只有十多个反对意见，共计86次提交，其中一半还存在于主分支中。 Salz详细描述了该项目为审查这些异议而采取的合理步骤，从而确定最多需要删除10个提交并重写。

8.开源安全v。Perens

开源安全公司（OSS）是Brad Spengler通过其维护针对Linux内核的树外grsecurity补丁集的商用工具。 2015年，出于对用户不遵守GPL和滥用grsecurity商标的担忧，OSS开始将付费用户只能使用稳定补丁程序。 在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软件诉Hancom

Artifex软件根据GPL （最近是AGPL）许可免费提供Ghostscript，并根据专有许可获得收入。 2016年12月，Artifex起诉了位于加利福尼亚北区的韩国办公套件软件供应商Hancom。 Artifex指控Hancom在未获得专有许可或未遵守GPL的情况下将Ghostscript纳入了其Hangul文字处理程序和Hancom Office产品中。 投诉包括违反合同以及侵犯版权的索赔。 除了金钱损失外，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年初从美国专利商标局获得了服务标记“软件自由法律中心”的注册。2011年11月，美国保护协会申请注册了软件自由保护商标。 SFLC的注册于2012年9月发布。SFLC继续由其创始人Eben Moglen经营，而Conservancy由SFLC的前雇员Karen Sandler和Bradley Kuhn管理。 众所周知，这两个组织在许多重要的法律和政策事务上有相反的立场（例如，参见我去年关于Linux上的ZFS问题的讨论）。

九月2017年，SFLC提交了一份请愿书与商标评审和上诉委员会取消1946年的兰哈姆商标法，第14下水利的商标注册15 USC § 1064 ，声称保护协会的标志是混淆性相似SFLC的。 在11月，音乐学院提交了答案，列出了其肯定的辩护；在12月，音乐学院就这些辩护提出了简易判决动议 。 实际上，TTAB 否决了即决判决动议 ，理由是，未对音乐节的答复中的肯定性辩护提出充分辩护。

Moglen公开提议所有权利要求相互释放 ，“以换取互不相让的铁腕协议”，其中包括“为Conservancy保留和使用其当前名称的永久性，免版税的商标许可。” Conservancy在博客文章中回复说，它“不能接受任何包含我们不需要的商标许可的和解提议。此外，任何商标许可都必须使SFLC永久控制我们的慈善使命。”

SFLC 提出请假以修改其请愿书，以增加第二条撤销理由，即Conservancy的商标注册是通过欺诈获得的。 保护组织的回应认为，拟议的修正案并未提出欺诈指控。 同时，Conservancy提交了“软件保护” 商标申请。

翻译自: https://opensource.com/article/18/2/top-10-open-source-legal-stories-shook-2017

2017 开源软件排行