2018 年，当 IBM 宣布以 340 亿美元收购 Red Hat 时，我们清楚地看到了自由和开源软件 (FOSS) 商业模式的重要性。 FOSS 生态系统去年也庆祝了其持久性，开源促进会 (OSI) 庆祝了开源运动 20 周年。
与此同时，旧的法律问题又出现了。我们看到涉及 FOSS 问题的诉讼裁决显着增加，其中一些案件非常重要。 诉讼的增加提醒我们，所有使用 FOSS 的公司（现在几乎包括所有公司）都需要积极的合规计划。
为了延续回顾过去以发现将影响未来的趋势的传统，以下是 2018 年 FOSS 领域十大法律进展。
1. 德国的 Linux 系统版权流氓 McHardy 卷土重来
Patrick McHardy 是 Linux 的早期贡献者，他一直在德国利用诉讼威胁来获得金钱和解，本质上就像一个版权流氓。 他已经活跃了五年，据信已经接触过 80 多家公司。 这个数字很难估计，因为许多公司未经法院诉讼就达成了和解，而且德国法院的诉讼程序是保密的。 McHardy 的诉讼活动于 2016 年首次公开，并在 2017 年沉寂了一段时间。
然而，在 2018 年初，我们看到了他对 Geniatech 执行行动的一项重要裁决：最初，McHardy 赢得了针对 Geniatech 的禁令，禁止其进一步分发卫星电视接收器，因为这些接收器涉嫌违反 Linux 软件的 GPLv2。 然而，在 2018 年 3 月，科隆的上诉法院推翻了该裁决，裁定：
a) McHardy 不是 Linux 内核和 Netfilter 的共同作者；
b) McHardy 可能对衍生作品拥有权利，但没有提供足够的证据证明他的贡献具有版权；以及
c) McHardy 可能滥用了他的权利（如果有的话），但法院指出，这个问题需要进一步分析。 McHardy 通过撤回他的禁令救济请求来避免进一步的诉讼程序。
关于“共同所有权”的认定非常重要，因为如果发现贡献者是相关程序版权的共同所有者，那将非常令人困惑，因为共同所有权的影响因国家/地区而异。
这个案例很不寻常，因为 McHardy 很少出庭； 他的策略是威胁对违反 GPLv2 的公司提起版权诉讼，利用德国法律规定的加速版权执行程序。 然后，他与声称违反 GPLv2 的公司达成“和解”。和解协议包括该公司将遵守 GPLv2 条款的条款，这是德国此类和解中的常见条款。 几个月后，McHardy 回到该公司，根据和解协议提出了另一项要求； 这些要求可能高达数十万欧元。 执行和解协议比执行 GPLv2 简单得多，后者会引发许多新问题（参见下面 VMware 案例的摘要）。 尽管他有时会把他的行为描述为专注于“合规”，但他显然更关心赚钱。
2. 欧盟反垄断机构对 Google 将 Android 软件与其服务捆绑在一起的决定
欧盟委员会 (EC) 因 Google 违反欧盟反垄断规则而对其处以 43.4 亿欧元的罚款。 根据欧盟委员会的说法，自 2011 年以来，Google 对 Android 设备制造商和移动网络运营商施加了非法限制，以巩固其在通用互联网搜索领域的支配地位。 此外，欧盟委员会要求 Google 在 2018 年 7 月 18 日的裁决后的 90 天内有效地停止这种行为，否则将面临高达 Google 母公司 Alphabet 全球平均每日营业额 5% 的罚款。 根据欧盟委员会的说法，Google 使用反碎片协议来使制造商保持在 Google 版本的 Android 上； 目前，大多数 Android 手机（除中华人民共和国外，所有国家/地区）都预装了 Google 的软件和服务。 负责竞争政策的专员玛格丽特·韦斯塔格 (Margrethe Vestager) 确定了三项违反欧盟反垄断法的限制：
a) Google 要求制造商预先安装 Google 搜索应用程序和浏览器应用程序 (Chrome)，作为许可 Google Play（其应用商店）的条件；
b) Google 向某些大型制造商和移动网络运营商付款，条件是他们在其设备上专门预装 Google 搜索应用程序；以及
c) Google 阻止希望预先安装 Google 应用程序的制造商出售任何运行在未经 Google 批准的 Android 替代版本（所谓的 Android 分支）上的智能移动设备。
Google 已对该决定提出上诉。
3. Red Hat 扩大了对 GPL 合作承诺的承诺
Red Hat 扩大了同意 GPL 合作承诺的公司范围。 该承诺是 GPLv2 和 LGPLv2.x 版权所有者签署的声明，它为获得 GPLv2 和 LGPLv2.x 许可的项目提供了“补救”期，以便在许可证自动终止之前纠正无意的违规行为。 这种方法基于 GPLv3 中包含的补救条款。 Red Hat 在 2018 年显着扩大了签署方的数量，从 2017 年的四家公司（Red Hat、Facebook、Google 和 IBM）增加到 2018 年底的 40 家公司。Red Hat 还邀请个人贡献者签署该承诺。 Red Hat 在为社区解决一个重大问题方面表现出了重要的思想领导力。
4. 开放发明网络继续扩张
OIN 在最大限度地减少 Linux 生态系统中潜在的专利诉讼方面发挥了关键作用。 OIN 表示，它是历史上最大的专利非侵权社区，拥有超过 2,750 名社区成员。 2018 年，一些著名的会员加入了 OIN，例如微软、腾讯、蚂蚁金服和阿里巴巴。 微软是一个特别有趣的招募对象，因为早在 2014 年，它就通过向使用 Android 操作系统的产品制造商许可其专利获得了约 34 亿美元的收入。 OIN 还扩大了专利非侵权协议的范围，纳入了 151 个新软件包，使受保护的软件包总数达到 2,873 个。
5. OpenSSL 许可证变更
OpenSSL 项目宣布，它已完成从 OpenSSL/SSLeay 许可证到 Apache 软件许可证版本 2 (ASLv2) 的转变。 该项目于 2015 年宣布了拟议的变更。 最初的 OpenSSL/SSLeay 许可证是一种非标准许可许可证，包含许多条款，特别是与署名相关的条款，这些条款在早期的 FOSS 许可证中很常见，但在最近的许可证中已删除。 这个过程花了三年时间，强调了完成此类转换的难度，因此，在 FOSS 项目开始时选择最合适的许可证非常重要。 ASLv2 正在成为针对企业的 FOSS 项目的首选许可证。
6. FOSS 在区块链项目中的崛起
许多区块链项目都获得了 FOSS 许可。 然而，区块链社区尚未与 FOSS 社区互动，其许多选择对于基础设施技术而言似乎不寻常。 例如，传统的以太坊区块链客户端是在 GPLv3 和 LGLv3.0 下获得许可的。 然而，区块链社区似乎 对这些问题越来越敏感，并且在 ASLv2 下发布新的 PegaSys 客户端代表了对这些问题的新认识。
开发 PegaSys 的团队指出：“为了使以太坊投入生产，我们还需要降低企业的准入门槛。 许多公司的法律或合规部门限制他们使用 GNU 通用公共许可证 (GPL) 下的软件，而主流的以太坊客户端目前正在使用该许可证。 我们听说过一些企业在以太坊上成功完成了试点，但由于公司围绕 OSS 许可证的政策而被阻止投入生产。 我们希望通过在 Apache 2.0 许可证下发布 Pantheon Core 来解决这一痛点，并为采用铺平道路。”
7. Oracle v. Google 重演
联邦巡回上诉法院 (CAFC) 发布了其在 Oracle 诉 Google 案中的第二项裁决，裁定 Google 未经授权在其 Android 操作系统中使用 Oracle 的 37 个 Java 应用程序编程接口 (API) 软件包侵犯了 Oracle 的版权。 CAFC 推翻了第一个地方法院的裁决，即 API 具有版权，并将案件发回地方法院，以对合理使用抗辩做出裁决。 地方法院再次以 Google 使用 API 构成合理使用为由，做出了对 Oracle 不利的裁决。 Oracle 提出了上诉。 CAFC 再次推翻了地方法院的裁决，裁定 Google 对 API 的使用在法律上不构成合理使用。 该案已发回地方法院，以裁定损害赔偿。 鉴于 API 在 FOSS 中的使用越来越多，此案对未来 FOSS 许可证合规具有重要意义。
8. Red Hat 与 IBM 达成 340 亿美元的收购协议
Red Hat 已与 IBM 达成协议，以 340 亿美元的价格被收购。 如果获得批准，这个价格将是迄今为止为一家软件公司支付的最大金额，更不用说一家开源软件公司了。
9. 云冲突和新许可证的兴起
许多 FOSS 公司对云服务提供商使用其程序而没有向 FOSS 公司付款表示担忧。 去年，Redis Labs 更改了许可证，将 Redis Labs 开发的 Redis 模块的许可证从 AGPL 更改为 Apache 2.0，并修改了 Commons Clause（这些 Redis 模块是 Redis 核心之上的附加组件，包括 RediSearch、Redis Graph、ReJSON、ReBloom 和 Redis-ML）。 它引入了 Commons Clause（已添加到其 ASLv2 中），以限制云服务提供商对其产品的使用。 这种混合许可证的引入引起了很大的争议，很少有公司采用它。
迄今为止，Redis Labs 尚未寻求 OSI 批准该许可证。 2018 年 10 月，一个名为 GoodFORM 的组织宣布它将在添加 Commons Clause 之前分叉该代码，并将在 AGPLv3 下提供它。 最近，MongoDB 通过修改 AGPLv3 来创建服务器端公共许可证 (SSPL)，从而采取了不同的方法来解决这个问题。 该许可证对向软件用户提供完整的相应源代码提出了更广泛的义务。 然而，MongoDB 已经宣布它已经将 SSPL 提交给 OSI 批准。
10. FOSS项目与标准制定组织之间的张力
随着FOSS（自由及开放源代码软件）作为一种开发方法日益普及，标准制定组织 (SSO) 一直在努力将 FOSS 方法融入到他们自身的流程中。然而，FOSS 项目和 SSO 的方法论截然不同：FOSS 项目以更加分散的方式运行，并基于非常不同的假设。摩擦的一个来源是 SSO 中常见的做法，即允许成员以收取特许权使用费为基础许可其专利（根据FRAND 条款）。但是，大多数 FOSS 社区都认为 FOSS 项目中的专利应该以免版税的方式许可。
尽管一些 FOSS 许可证有明确的专利许可条款（例如 ASLv2），但在其他 FOSS 许可证中，专利许可的存在和范围更加模糊。这种对专利特许权使用费的不同处理方式正在 FOSS 和 SSO 社区之间造成紧张关系。这个问题不太可能在短期内得到解决。
1 条评论