蚊章汇 - 付钦伟
type: channel
link: https://linuxcn.bwsl.wang/author/668/
description: 付钦伟
items: 源码被倒卖，大厂薅羊毛，开源真的只能被予取予求？
items: 中国 GPL 诉讼第一案：关于 GPL 问题的探讨
items: 专利告诉你，为何 Apache 禁用 FB + PL 代码

源码被倒卖，大厂薅羊毛，开源真的只能被予取予求？
type: item
date: 2020-03-24T18:05:00+08:00
description: 今天看到一篇文章《开源项目在闲鱼、b 站上被倒卖？这是什么骚操作？》，我突然想起了之前两个类似的案例，发现群众的开源知识普及依然不足，借这个机会再聊聊开源，从开源著作权人的角度做一次讨论。案例 1：倒卖开源代码本案例中，作者十三发现自己开源的代码被贩卖，一脸郁闷。先不讨论这些倒卖者的行为，笔者从作者提供的代码托管官网上看到其开源许可证是 MIT。MIT 作为一个宽松型开源许可证，授予使用者几乎无限制的权限。也就是说倒卖者的行为固然让人讨厌，但其确实是可以这么做的。当然，作者十三除了困惑于开源的东西为何还有人拿去卖钱以及竟然还有人买之外，整体上是淡定、大度的。而倒卖者利用的正是大众的这种专业知识的缺失和信息的不对称性，严格意义上这是存在经济正当性的。案例 2：王垠闭源这个案例是 2017 年的旧闻，但很具代表性。BSD 许可证开源的软件被商业公司商业使用，还聘请了原开发者，最后闹的鸡飞狗跳。注：原博文《为什么我的代码进入闭源状态》地址已经 404 无法访问，大家可以搜索相关转载。王垠此人我不甚了解，据说曾经国内人气非常高，知乎、v2ex、csdn 博客上到处都有对他的评价和争论。但至少从这篇帖子可以看出，其对开源的理解很浅、也很狭隘（在 2017 年时，不代表现在）。其对开源抱有不该有的幻想，期待过高。案例3：swoole 修改开源协议这个案例也是 2017 年的，以 Apache 许可证开源的软件 swoole（撰文时经核实 swoole 依然是 Apache 许可证），与其复刻分支版本之间纷争。这个案例更像各种 Android 发布版与 Google Android OS 之间的关系，以宽松型许可协议开源的软件被各种修改版骚扰、蹭热度的现象很普遍。开源知识普及之路漫长以上三个案例都可以称之为开发者的控诉，暂不评论其控诉是否合理。仅以这些事件本身以及在网上引起的纷争，都说明距离开源在国内普及，还有很长的路要走。但值得欣慰的是，从 2017 年到 2020 年我们看到了这种进步，案例 1 中的作者对开源的理解上虽有偏颇，但并没有出现知识或法律方面的硬伤。 从开源软件概念引入中国，到近几年开源运动如火如荼的开展，已有几个年头。但据笔者与企业及业内人士的接触发现，公众对开源的认知和理解程度依旧参差不齐。究其原因有以下几点：大部分关注开源的人，更多的是关注技术，不会关注其背后的许可证问题；开源许可证更偏向法律，真正做技术的不关注、也不懂；开源许可证法律条文晦涩难懂，不容易理解；懂技术、会看代码的专利、著作权、商标等领域的律师甚少，没有技术背景的律师纵使法律水平再高，在理解涉及开源软件相关问题时也力不从心；开源领域国内诉讼不多，没有充分引起大部分企业、学界等人员的重视；也因为诉讼少，经济驱动力有限，很难吸引律师深入研究这一领域。重赏之下必有勇夫，若有足够的利益驱动，修个计算机学位又何妨，或者报个代码速成班也不是不可能吧。笔者有缘在多年前接触开源治理、合规问题，时不时看到网上爆出浅层次开源“事故”，说明大众的开源知识有限。今天蹭个热乎劲，再探讨一下开源基础知识（开源科普的知识网上并不少，没人关注归根结底还是这个领域内生动力不足所致）。既然内生动力不足，就靠外部热点的外部动力吧。开源“事故”，你是否理解开源？开源是什么？开源就是奉献，无私或有私的奉献。此处不接受反驳。开源运动起源于自由软件运动，自由软件运动的发起人 理查德·马修·斯托曼 （ Richard Matthew Stallman ） 是自由软件运动精神领袖。自由软件运动所要反对的就是后来以比尔盖茨（曾经）为代表的软件私有化运动。所以说，自由软件是旗帜鲜明的追求奉献、共享和软件自由的。开源运动的兴起是自由软件运动向商业化的妥协（可以这么说，毕竟经济基础决定上层建筑），所以说开源软件运动虽然有别于曾经的自由软件运动，奉献和协作依然深深的烙在其血液里。如果你无法理解这一点，就再看 10 遍开源软件的定义（直到看懂为止）。开源运动淡化了自由软件运动乌托邦式的理想主义，穿上了实用主义的外衣，毕竟空洞的理想是填不饱肚子的。开源“事故”，背后的起因网上时不时爆出的开源“事故”大都归于两类：类型一：批判拿来主义者坐收渔利、不劳而获、贩卖别人劳动成果……。这一类主角，多是软件开发者自己，站在自己的立场上看待开源软件的使用者（合法使用者、不合法使用者）。该类“事故”的原因有：软件的开发者没有充分理解开源的要义；对开源许可证不理解，开源自己软件时没能正确选择许可证，导致自己有被白piao的感觉；想借助大众或社区的力量优化自己的软件，获得免费劳动力；想借助开源扩大自己影响力（自我营销），却没考虑为此要付出的代价；看到其他人利用自己的开源软件获利，心理上有些许不平衡。类型二：批判开源软件收费、许可证不人性…

中国 GPL 诉讼第一案：关于 GPL 问题的探讨
type: item
date: 2019-12-17T16:57:01+08:00
description: 2019 年 11 月初，数字天堂（北京）网络技术有限公司（下称：数字天堂）诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司（下称：两柚子）侵犯计算机软件著作权纠纷案，由北京高级人民法院二审作出终审判决。笔者曾密切关注该案，终审判决生效前，囿于关联代理关系的利益冲突，不便多谈。现将本案相关若干问题梳理成文，愿与各位探讨之。本案之所以受关注，是因为本次计算机软件著作权侵权案涉及开源软件和 GPL 许可证，本案的判决对未来开源软件诉讼实践有重要意义。本案一审法院对 GPL 相关条款作了阐述，二审法院回避了 GPL 问题。本文，笔者基于本案事实和法院判决做些思考，分享给大家讨论。本文将仅对涉及开源软件及 GPL 许可证的内容进行论述，其他法律问题不作探讨。案情简介为节省篇幅，以下对案情进行摘要和总结，详细案情可见一审链接和二审链接。经过一审和二审对事实的调查和确认，两柚子认可：数字天堂是 HBuilder 软件的著作权人；数字天堂拥有 HBuilder 软件中的代码输入法功能插件、真机运行功能插件、边改边看功能插件源代码著作权；两柚子的 APICloud 软件中对应插件源代码部分与涉案的三个插件具有同一性。基于此，针对本著作权侵权控诉，两柚子抗辩理由只有 GPL 开源许可协议这一个突破口。而二审中对涉案代码量、侵权产品数量的认定，以及基于此对赔偿额的认定，只是量的维度问题。开源许可证是法律文件一审法院虽未明确 GPL 许可证的法律效力，但在论述涉案三个插件是否受 GPL 协议限制时，默认了 GPL 许可证具有法律约束力。这一点虽然是意料之中，但毕竟开源理念和大部分开源协议来源于国外，且应用于开源社区特定人群，这一认定给未来涉及开源软件的诉讼消除了部分不确定性。为了强调协议内容，下文涉及 GPL 许可证的除特指许可证本身外，都以 GPL 协议指代。法院虽然默认了 GPL 协议具有约束力，即类似于协议或合同的法律效果，但并未进一步将 GPL 协议条款基于我国著作权法进行解释。社区内关于 GPL 协议的解释，特别是关于 GPL 传染性的解释是基于美国版权法，其能否为国内法院认可，依然存在不确定性。随着开源理念的深入以及开源软件在世界范围内的普及，本案作为中国 GPL 第一案，对未来开源软件相关的诉讼意义重大。稍有遗憾的是，两审法院并未就开源软件以及 GPL 协议的关键问题进行阐述。当然，也不可能期待 GPL 问题通过一次诉讼案件完全解决，未来还需要更多的法律、学术、技术等人士贡献智慧。关于一审认定的思考既然法院确认了 GPL 协议的法律约束力，那么对 GPL 协议的解释要么采取社区通说解释，要么基于我国著作权法作独立解释。否则很容易出现矛盾或模糊，以至于增加企业开源实践中的法律不确定性。关于 GPL 协议约束力范围（传染性），一审法院以涉案的三个插件可以独立运行，分别存放在三个独立的文件夹中且三个独立文件夹中无 GPL 许可证，据此认为涉案三个插件不属于 GPL 协议中所指应被开源的衍生产品或修改版本。GPL 许可证中有关的原文如下：The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".)——GPL 3.0To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.A “covered work” means either the unmodified Pro…

专利告诉你，为何 Apache 禁用 FB + PL 代码
type: item
date: 2017-08-10T17:17:00+08:00
description: 关于 React.js 的开源许可证从去年 7 月份争议到现在，Apache 基金会终于确认了立场，反对使用 React.js 和 Facebook 其他使用此许可证（BSD+Patents licensed）的流行软件。最近，随着开源运动不断壮大，这边 LC3 大会刚过去不久，人们的热情还是未曾消去，那边 Apache 和 Facebook 又搅动着整个社区。作为本次事件焦点的 Facebook Patents license 已经不是第一次出风头了，时不时成为人们讨论的主题。上一次挑动大众神经是在 2016 年 7 月，Facebook 给 React 应用的开源许可协议是，在 BSD3-clause 协议基础上加上旨在保护 Facebook 自身的扩展协议。而这一次依然是围绕 Facebook Patents license 展开，简单梳理此次事件：2017 年 4 月，Apache Cassandra 项目正考虑增加 RocksDB 作为存储引擎，但考虑到专利授权的问题，Jeff Jirsa 向 Apache 法律社区寻求意见。2017 年 6 月，Apache 法律社区开始讨论 Facebook Patents license 协议专利授权的不对称性问题，且该协议与Apache Software License（即 Apache 2.0 等）不兼容。2017 年 7 月 15 日，Apache Software Foundation（以下简称 ASF）主管兼法律事务副主席 Chris Mattmann 正式发表声明称：Facebook BSD+Patents license（以下简称 FB+PL）已经正式被列入 “CategoryX” 列表，因此 Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码；而已经发布的代码，涉及 FB+PL 许可证的，需要在 8 月 31 号前完成替换。这一结论一出场便自带光环，引起了整个社区的关注，包括国内著名社交论坛知乎。当然，其对 Apache 项目自身的影响不比外界的关注度低。如，虽然 Facebook 已于本月 17 号将 RocksDB 许可证更新为 Apache 2.0 和 GPLv2 双许可，但更大的问题是 React 也是基于 FB+PL 开源，Apache 的 CouchDB 项目、Apache Superset 项目等都依赖于 React，但是要让其开发人员在一个月内摆脱对 React 的依赖似乎也不是一件简单的事情。到底是什么原因让 ASF 对 Facebook 的 FB+PL 许可协议下禁止令？要回答这个问题，需要先分析一下 FB+PL 许可协议。众所周知，Facebook 也算是开源社区的中坚力量，截至目前已经发布了很多开源软件技术，包括使用广泛的 React.JS 框架和键值数据库 RocksDB。不过，Facebook 没有像其他社区一样，自定义自己的开源许可证，也没有仅采用现存的开源许可证，而是采用 “BSD+Patents license” 许可证组合授权其大部分项目，该协议组合也被称为 FB+PL 组合。其中，BSD 是指 BSD3-clause license，是被 OSI 和 FSF 都认可的开源软件许可证，也是被业界称为“宽松型”的开源许可证。正是这个“宽松型”的 BSD 许可证附加了专利条款的开源许可协议，已经被 ASF 列为 “Category X”，杜绝了任何以 FB+PL 授权的软件进入 Apache 项目中的可能性，等于 FB+PL 已被 Apache 明确打入冷宫。FB+PL 协议中，BSD3-clause license 本身没有问题，问题自然就出在 Facebook Patents license，即 Facebook 开源软件组合协议 FB+PL 中的附加专利许可条款。以下是 Facebook Patents license 条款内容：Additional Grant of Patent Rights Version 2"Software" means the React software distributed by Facebook, Inc.Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software ("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable (subject to the termination provision below) license under any Necessary …