3.89. 科普一下GPL和开源软件

最近关于“自主”的话题很热，我个人对现在的主流论调不以为然，但也不想纠正他们，策略性的东西，说多错多，如果你非要问我，我宁愿说你该干嘛干嘛去，不关你的事，你自己虚心实腹，“智者”才不敢为。

但我想科普一下关于开源的基础知识，作为真想干点正事的人的参考。

我们先来理解一下到底什么是GPL开源协议。

什么是侵犯版权呢？有个人，买了你一本书，然后拿着这个内容，重新印了1000本，每本50块钱卖出去，他只付出了纸和渠道的成本，就借你的知识产权获得利益。这就是侵犯版权。侵犯版权，违反法律，也违反道德，你利用了别人的劳动成果获得收益，挤占了人家的收益。

专利也是一种知识产权，但它和版权是不同的，专利是一种方法（或者用特定方法设计的装置和改进），或者说是一组方法的特征。比如我的程序使用了特定的算法获得一组数据的特征，从而优化了cache的预期效果，这就可以申请为一种“专利”。专利是一组特征，而版权是一个“实现”；专利需要申请，版权不需要；专利申请后需要每年付钱来维持，版权也不需要；专利如果被人证明，在你提出前，已经有人公开类似的方法了，就会失效，版权没有这个问题；专利的保护年限很短（很多国家只有20年左右），版权则长得多；等等。

对此，读者可以先Keep in mind，我们后面谈GPL的具体问题的时候会涉及到。

GPL又称为Copyleft，这是一种英语的调侃，因为Copyright的那个right，有多个含义。用作copyright的时候，right是权利的意思，但它同时还是“右边”的意思。所以叫它Copyleft，表示这是和Copyright是走另一边的。

但Copyleft确确切切是一种Copyright！

如果有人写了一个代码，他自动就拥有这个代码的Copyright了，但他说，我希望更多人来使用它，你们不用跟我协商了，直接用就好了。这不表示他放弃了这个作品的版权，这只是说，他做了授权，授权你使用这个作品而已。有时我们看到，一个作品可以是双授权的，比如一方面是GPL的，同时又是商业授权的，这一点问题没有。因为作品的创作人拥有对自己作品做任何授权的权利。

GPL授权对被授权者是有要求的，它重点强调：

第一，和大部分开源软件一样，这个作品提供给你AS IT IS，作者不为任何物理损失负责。这个是开源授权的一个优势。作者可以少负责很多东西。所以，其实如果你给别人提供一个作品，而且不想负责任，简单使用一个开源授权协议，可以保护你自己的。对公司来说，这背后还有很多游戏可以玩，但那个属于商业机密，我就不在这里说了。

第二，如果你，基于这个作品衍生了新的作品，那么这个新的“作品”，必须符合GPL协议，否则你就失去原作品的授权。

第三，符合GPL协议的作品，在提供给它的使用者的时候，必须同时提供该作品的GPL部分的源代码。不能对该源源代码的使用作出限定。

这第二点是最难解释的，也是现在大量误解的原因。

首先，这个授权没有说明新的作品是否免费，你愿意卖多少钱其实都是可以的。但根据第三条，无论你多少钱卖出去，你的用户应该拿到这个产品的源代码。至于用户是否非要这个源代码，其实这个是两者之间可以协商的，其他人管不着。所以你现在看到的GPL侵权例子大部分都在消费者市场，因为消费者市场的用户无数，你没有办法协商，而且你不能在销售条款中要求消费者接受不找你要源代码，否则你就侵犯了被你衍生的原作品的版权。一旦你侵犯了原作品的版权，原版权拥有者就可以用“侵犯版权”来告你，这在西方国家，下场就是罚款和禁售，这个对商业公司来说，常常是致命的。

我还看过案例，即使不是原版权拥有者也可以用“侵犯版权”来告倒侵权者。这相当于“我在路上看到别人偷东西，虽然不是偷我，我也可以告他”。但不是每个国家都支持这种方式。

所以，GPL主张的是“让产品的使用者真正拥有对产品的控制权”，而不是主张“共产主义，代码属于所有人”。GPL并不要求免费，也不要求别人代码开源，他只是要求你保证：你把产品传递给用户了，用户应该真正拥有这个产品，也就是说，他必须有能力修改它，所以你必须提供源代码给这个用户，这还不仅仅要求代码，你还应该保证这个代码的GPL部分可以被修改后重建，所以，你还需要提供Makefile，可获取的编译器等辅助设施，否则都可以视为侵权的。

更重要的是，这个用户基于GPL拿到一个代码后，如何处置这个代码，提供者无权干涉。

这个在细节上也会引起很多问题，比如硬件只能运行签过名的二进制，那么为了满足这个要求，就会要求提供签名的密钥，但一个商业公司，怎么可以给你提供它签名的密钥呢？这个是对用户的不负责任，GPLv3的很多问题，都是从这里来的。

接着我们来讨论一下什么是“共同作品”。GPL的说法是：如果你的代码和GPL的代码构成“共同作品”，那么你的代码也必须是GPL的。但什么叫共同作品呢？这就看个人看法了……

从广义的“作品”的角度来说，两个东西关联很多，我们就认为它们构成“共同作品”，但多少关联叫“很多”关联呢？这个说不清楚的，这完全看法庭怎么判。有人简单说，如果两个程序在同一个地址空间内，就构成共同作品了。

但如果我把Linux运行在nommu模式，岂不是所有代码必须是GPL版权的？（实际上一个Linux发行版里面有很多软件都不是GPL的）。还有，如果我用一个开源的库，我把它放在一个独立的MMU空间里，然后每次调用的时候都切换一下页表，这难道就应该认为这不是“共同作品”？这其实不符合我们一般对“一个独立著作”的认识的。所以，法庭并不使用简单的“是否同一个地址空间”这样的逻辑来判断“共同作品”的。但确实，如果程序在两个进程中，我们一般认为他们是两个作品。但如果你恶意地靠地址空间把两个程序隔开，实现所谓的“GPL隔离”，那么法庭很可能不会接受你的“两个作品”的辩护的。

有些公司，还曾经用过这样一个手段：他们把一个不开源的代码用二进制提供，提供给用户，在用户的系统上把这个二进制和一些其他简单的源代码一同编译，建立和Linux内核的“关联”，让用户自己插入到Linux内核中。这样，理论上，他们并没有建立和Linux内核的关联，所以没有义务向用户提供源代码，而用户建立了这个关联，所以用户的代码应该是GPL的，但因为用户没有向第三方提供这个“产品”，所以用户没有向任何人开源的义务。

这种小聪明用过很多年，现在怎么样了我不知道，但它带来多少问题我是知道的：），无论如何吧，从这个例子，我们可以更深入了解GPL的版权保护是如何实现的。

其实，很多商业公司也是身不由己的。比如你做了一个解决方案，当初不流行开源的时候，他们没有考虑更多的问题，很多软件是来自第三方的，他们取得了第三方的版权授权，加入到自己的产品中。但现在你给他说要开源，原来的授权怎么办？就算有心去要那家公司的授权，人家在不在都不一定啊。

还有一个问题就是专利了。我版权给你可以，但专利怎么说？专利给你吗？这专利也不一定是我的呀，是我的一个兄弟公司的怎么办？所以，GPLv2是不讨论这个问题的，用户自己看着办。v3想讨论这个问题，所以也有很多的分歧，现在都没有吵清楚。从用户的角度来说——我要不要担心我用了你的代码，以为占点什么便宜，结果等我做大了，你跑来找我要“专利费”？

这背后也有很多的技巧。

所以，我常常说，不要用情怀来说话，做事你才能体会细节。站队，激情，什么屁用没有，只是当“智者”的棋子。

最后，我们来谈谈开源软件的盈利模式，以便读者更容易理解这里面的细节。

比如你做一个Linux发行版，卖给某个客户，你每个实例可以卖1万块钱，但你必须同时提供所有GPL软件的源代码。这样，用户确实是可以这样的：买你一个版本，然后重新编译100份，用于自己的内部网络，这样，用户用了100分拷贝，只给了一份的钱，而且用户还可以接着把这个产品重新卖出去，收5000块钱。这一点问题没有，因为GPL协议说了，你无权阻止用户如何使用这个源代码。

但是，我可能每个星期都会出补丁，你能够一次次这样升级吗？而且你只买了了一个拷贝，你内部拷贝的其他版本出了问题，我可是不负责的。你愿意这样做吗？——实际上很多人是不愿意的，比如大部分的银行，矿山等企业。这样Linux发行版提供的就不是“版权授权”了，而是“Subscription”，我卖你的重点不是那个软件，而是基于这个软件为你提供的服务（这就叫“软件即服务”）。这种模式现在这个阶段养活几家大发行版，却无法在数据中心市场实现开拓，因为这些市场都是买一个版本（甚至不买，某些开发者已经干这种事情了），然后自己维护的主。但其实这个到最后也是个博弈的关系，如果发行版发展不下去了，原来他们负责的那些特性，就没有发展了，这时这个锅会重新烧到云运营商头上。所以国外的运营商对这些发行版提供商还是客客气气的，就国内某些运营商反而傲慢得莫名其妙。等真得打到白热化的时候，你们就知道问题出在哪里了。

其实，真正领头的Linux发行版提供商对此是表现得很大度的，他们明确说你可以这样做，但有一点，你不能使用人家的商标，人家的代码是授权给你的，你要用这个代码人家不会拦你，但你不能使用人家的商标（这又是一个知识产权问题了），不能声称：我这个其实就是XXXX了。这样你就侵犯别人的商标权了。

这是一种模式，其实还有另一种模式，我们知道有些商业发行版是完全免费的，不对客户服务收钱，这种发行版的盈利模式是从硬件提供商哪里收钱：我拥有一大堆的客户，他们的业务建立在我的发行版上，所以你要我的版本支持你的硬件吗？给钱啊。这又是一种思路，比如某“标准AI计算平台”，就是这样取得竞争优势的。

好了，我们建立了一个基本的模型脉络，让读者大概理解开源是什么样的，被什么样的法律和现实力量左右着。我们现在可以进入主题，来讨论什么是开源，和为什么要开源了。

最近很多人谈“自主”，但他们常常把“自主”当作一个名了，似乎“我做的”才是“自主”，使用“开源软件”，不叫“自主”。这和我以前谈《道德经》中常举的“失败的架构师”例子如出一辙：某个系统应该使用方案A，工程师t提出来了，架构师会很不爽：这个名怎么让你占了？我要千方百计证明“A”是不好的，宁愿用一个更差一点的“B”方案来解决这个问题。

这明显是“求名”，对不对？

还有“求礼”的：t，你这么厉害，我看来需要退位了，你上，我冰清玉洁，不能把你的名给遮盖了，闪耀吧，t君！

他妈的还是求名，换个形式而已。

如果你理解开源协议，你就应该明白，一旦一个作品被授权出来了，本来人家就给你授权了，你要求名不用它？然后把这些事情重新做一遍？这是求名求到根子上了，怎么说你好？你迟早变成污泥拿来填池塘。

所以，你用不用一个开源作品，不是因为它是不是开源的，不是因为它是不是签着你的名字，不是因为它是不是签着中国人的名字，而是它是否符合你的要求！

好了，这里涉及我要讨论的核心了：国内大部分公司，都不具备主线维护能力。开源最早的时候，也许是因为一些个人的情怀和期望。但到今天，它早就不是了，开源是保证构架演进的关键手段。

你们可以看看我这里写的一个设计讨论：

Progress and confusion of the IOMMU name space

这是我们要给我们的加速器做一个统一的软件引擎，我已经写好这个代码很久了，也在实际的产品中使用了，但我仍需要这样公开表达出来，因为在我写我的引擎的时候，其他公司也在做他们的加速引擎，做IOMMU构架定义的公司在修改iommu框架，做GPU的公司在加mdev，做网卡的公司在用这个东西取代DPDK的全用户态驱动。我确实可以保证我自己的应用场景，但当我的场景向下展开的时候，他们面对的困难，我同样需要面对。我提早和他们对齐，我做错的可能性就低得多。因为我个人面对的世界太小了。

实际情形是，我写完，拿出来讨论，就马上收到反馈——有人面对的场景不是这样的。他们会利用我的“设计”，但同时他们有他们的考量，我的设计会在这一次次的冲刷中逐渐逼近那个可以生存下去的“道”，这里没有任何道理，只是你有你的要求，我有我的要求，我们形成一个更贴近现实的合作模式而已。

在你看到我这个文档的时候，那个文档更新过5个版本了，几乎每个版本都是完全重写的。

这就叫架构引导。它的目的就是让每个增加的代码都是夯实的，不会向下增加代码的时候，很多逻辑之间就互相冲突了。

当你进行架构引导的时候，你需要考量的是未来怎么活下去，而不是眼前怎么实现功能。很多人想不明白为什么国内做不出操作系统，我看过很多人的策略，他们不可能成功的。因为我们大部分开发组织还处于“求名”的阶段。构架是没有立即的收益的，是没有名的，它是走一条没有立即收益的道路，期望可以“活下去”，“活的更久”。

我们很多组织，使用Linux，使用OpenStack，觉得自己也是“做开源的”，“懂开源的”，“为开源做贡献的”，但他们没有真正懂过开源，所以他们纠缠于“我有情怀，我有责任”，或者“这些人就知道情怀，不知道公司运营”，看来针锋相对，各有观点，其实统统失道。根本就没有搞清楚开源的目的是什么。

我们不少人醉心于拿到一个开源的版本，然后针对自己的场景进行优化，觉得“我做得比开源好，他们根本就不懂”，却不知道自己其实是在消耗构架——是因为有开源在前面稳住了一个架构，才有你现在消耗的机会。你把这个作为你牛逼的原因？——现在你是否明白为什么你总是使用别人的架子？

所以，很多人担心比如Android的代码不能用了怎么办。这根本就不是这么个问题，开源的代码没有什么特别，开给你了，你随时就可以拿来用。关键在于，你如果要开始独立为这个架子的发展负责了，以你这种求礼的心态，你是不是可以稳得住这个架子？

所以，不要老想着要怎么努力获得竞争优势了，你求“竞争优势”这个名，你就不会有竞争优势，做好你本来应该做的。如果你真要做长远投资，找些不那么求名的人来运作……

而国内不少发行版，把代码唔得死死的，以为是“核心竞争力”，其实门都没有入，这种关起门来自High还差不多，拿去竞争？——市场不相信眼泪。

其实这个和开源没有什么关系，只是“架构版本”，现在的最优实践，是开源版本。但不表示你开源了，你就能撑得住这个架构，也不表示你不开源，你就能撑得住这个架构。但开源，是我们最容易理解这个“架构版本”是怎么回事的一个实例。