开源软件的中年危机如何破解？

作者 | Paul Dix
译者 | 弯月
责编 | 郭芮
出品 | CSDN（ID：CSDNnews）

以下为译文：

2018年12月，Confluent宣布他们将改变平台上一部分功能的授权，不再使用Apache2，而改用Confluent Community License；

而这之前，AWS刚刚在Re:Invent 2018上发布了AWS管理的Kafka服务；

RedisLab将其特定的插件授权改成了Commons Clause授权；

MongoDB也将其授权从AGPL改成了Server Side Public License；

之前还有CockroachDB宣布将采取CockroachDB Community License；

......

所有这些都有一个共同点：它们的目标都是利用新的授权维护这些公司的软件在托管服务上的垄断地位——这一切都是为了抵抗AWS、GCP、Azure等公有云服务商给他们的商业活力造成的威胁。

在这篇文章中，我将提炼这些改变招致的各种非议和愤怒，并从多个角度阐述我的个人观点。最后我会证明，宽容的开源授权加上封闭的商业产品，才是那些靠开源项目为生的公司最理想的开源之路。实际上，后一点正是我们在InfluxData采取的策略，因此我提出这个观点也许并不是太突兀，但我想说的是，InfluxData也走了许多弯路，在看到它与其他开源供应商、项目和社区的交流之后，我在这个问题上有了更清晰的看法。

与往常一样，这些观点还在不断变化，所以我现在写的只是我目前的看法。将来我可能会觉得我现在的观点很愚蠢，也可能会赞成我现在对于开源、云和商业的看法。免责声明说完了，现在我们来回顾下历史……

我们启动InfluxDB时，一切都是MIT授权，开发也完全在开放的环境下进行。这符合我当时（也是现在）对于开源的理念，即开源软件应当可以免费使用、集成并创建派生的作品，对于任何人、任何使用条件都是如此，也无论是用于商业目的还是非商业目的。尽管我认为我们的所有软件都应当采取MIT授权并保持免费，但在2016年早期，我们在商业化上碰壁了，所以不得不将产品中的集群和高可用性部分改成了封闭的商业授权。在我宣布这项变动的文章中，我写出了我的顾虑：担心云服务商会把我们的软件当作服务来提供。

有一段时间，我曾想过我们可以在AGPL或类似的授权下提供集群功能，以限制云服务商，同时保护我们在OEM和受管理的服务（managed service）方面的商业机会。但在最近看到各种授权改变的行为后我意识到，AGPL、SSPL和Community Licenses只是在搅混水，他们带来了大量大型组织无法认可的授权。一些公司禁止使用AGPL授权，比如Google。但在分析这些授权之前，我先提炼下各种争议的焦点，大致如下：

• 人们认为软件厂商声称开源但实际上并非开源而产生的愤怒；

• 以开源的名义作为诱饵获得开源贡献，之后再改变授权；

• 从开源授权改成有限制的授权的趋势（或者用Bryan Cantril的话来说，开源软件的中年危机）。

人们愤怒是因为他们认为所谓“开源”只不过是诱饵。开源厂商已经声明，新的社区授权不是开源授权，只是提供源代码而已。而人们依然拿着猎叉和火把围聚在厂商门前，因为他们觉得一些本应开放的东西被厂商拿走了。而且他们还认识到，社区会因为厂商的社区授权中的限制而遭受到局限或伤害。我认为，开源软件的短暂历史表明，整个项目和生态环境的授权越宽松，社区就越大、越有活力（尽管只有授权并不能保证开源项目的成功）。

认为以开源作为诱饵之后再改变授权的观点就有点夸张了。编写开源软件的厂商、个人甚至基金会都没有承诺永远以开源模式开发软件并改进。你的贡献是在现有软件的基础上作出的。社区可以分裂，项目可以分叉，用户和贡献者可以消失，厂商也会破产，或者被有着不同目标的公司收购。一个公司作为开源项目的主要开发者，如果它无法找到在长期内收回成本的途径，那么最后一条路是不可避免的。

一个项目，不论是由社区驱动，还是由一家公司驱动，如果你不喜欢它的新方向，你可以在它改变授权之前的版本上创建新的分叉（或在拒绝一些你不想要的拉取请求之后），然后在派生的项目上继续使用、开发并培养新的社区。这就是为什么对于社区来说，宽容的授权要比“社区授权”更好的原因，它不限制派生的作品。尽管如此，我们也应当更友善（同时也是更现实）地认为，厂商的这些决定是根据当前的环境作出的，而不是多年处心积虑诱惑开发者贡献代码再让项目人间蒸发的计划的一部分。就算真的有这种计划，贡献者和布道者们的努力也没有白费（参考上面关于分叉并创建派生作品的建议）。

最后一种观点认为这种趋势是开源软件的末日。同样，我认为这种看法也太夸张了。如果这的确是个问题，那么早在几年前SaaS和云服务成为软件发布的主流模型时就应该出现了。SaaS和云服务都是与开源运动直接对立的，因为它们都代表了闭源软件而不是开源软件（尽管它们主要是在开源软件的基础上构建的）。如果这是趋势，那么早在15年前就应该出现了。抛开夸张的一面不谈，我还认为，在开源和闭源中间应该还有一种混合模式。如果基础设施供应商想要把社区认为重要的东西改成闭源，那么其他项目和公司都会来解决同样的问题。开源意味着选择，只要开发者还有电脑、编辑器和网络，就会不断有新的选择出现。

好了，现在我们来聊聊授权。像AGPL、SSPL这种copyleft（反版权）从整体的社会益处来说，比MIT、Apache2等自由授权要弱一些。copyleft有两种解释，我分别称之为“十字军”和“资本家”。在十字军的解释下，开发者宣称他们希望一切都是开放的。他们强迫世界上的一切都是自由的、分享的，想要创造一种类似于星际迷航那种不需要金钱的社会。这是个伟大的梦想，但我认为它不可能出现。人们的热情并不仅靠目标和伟大的理想来维持，他们需要自己的人生，需要家庭和后代（也就是资本）。Copyleft完全忽略了后者，简单地认为一切都没问题。

而资本家解释则是利用copyleft授权来保护商业模型。但是，资本家通常会伪装成十字军，因为大部分人更喜欢这种说辞，而不是说“我想用我的工作来赚钱”（尽管这种说法完全合理）。通常，授权的选择造成了所谓的“偶然资本家”。例如，我怀疑MySQL在选择GPL的时候考虑的就是在OEM合同中销售软件的商业授权，从而可以绕开GPL，这是他们（早期）的主要盈利模式。Mongo可能也是同样的方式，但我还没有机会直接询问Dwight或Elliot（我也不期待他们会毫无保留地回答，毕竟他们要运营一个上市公司）。最终，资本家会将这个授权伪装成开源，同时保留一种商业化的途径。

如果软件是个持续进化的过程，需要在前人的基础上构建，那么copyleft带来的就是进化的死胡同，而自由授权则代表了树上不断生长的新枝。原因是，自由授权的软件可以用来创建任何其他授权的软件，可以是copyleft，也可以是商业授权软件。而Copyleft软件只能被用来创建其他copyleft软件（除非一个公司拥有该copyleft授权，并将其卖给其他商业作品，这样也能产生进化的新叶）。再加上copyleft不仅对嵌入了代码的程序有要求（比如GPL），还对通过网络访问代码的程序有要求（比如AGPL或更严格的SSPL），这只会加剧这个问题。不管OSI怎么说，最终在我看来，copyleft代表的是真正的开源。Copyleft是一种限制。

社区授权也是同样。只要你遵守它们的规则和约束，它们就是开放、免费的，可以随意修改。而它们是否属于开源，实际上只是语义之争。如果你认为它们不是开源，那么copyleft授权也不是，除非你采用十字军的解释。如果你非要这样说，那我建议你还是准备迎接世界崩溃的残酷现实吧。

社区授权还有个很严重的潜在问题，这个问题我没有听任何人说起过。如果你是开发者，决定建立一个开源项目或者分叉一个开源项目，来代替某个社区授权中的部分功能和API，那么你可能会接到该社区授权拥有者的起诉。你可能没有用到它们的一行代码，但只要你读过社区的代码，就可能需要为此付出代价。至少在商业软件中，厂商并不能向法庭证明你访问并复制了他们的源代码。当然，我不是律师，所以这也许并不是问题，但针对个人或小公司的诉讼可能是毁灭性的。所以从开源的角度来看，这些社区授权代表了软件进化树的死胡同。

需要明确的是，我并没有责备RedisLabs、Elastic、Confluent、Cockroach或任何急于创建社区授权的开源软件厂商。他们完全有权利这样做，我甚至认为，尽管有各种限制，但这样做甚至是件好事。这样他们才能打造商业流程，以此为昂贵的开源开发提供资金。只是，这些社区授权不再是开源授权而已。

即使copyleft和社区授权被用于商业，它们也不是没有任何价值和好处。它们为软件能被自由使用和改动的规则提供了样本。对于一些用户来说，这完全没有意义。他们只需要接受这个事实，即采用了这些授权的代码代表了他们一切商用产品的基础。社区授权的最大问题是，大量各不相同的授权在许多大企业或高风险的组织中是禁止使用的。所以这些代码惠泽的人群范围将大大减少。尽管有了这些限制，许多商业依然依靠copyleft软件，所以我认为依靠社区授权软件的商业也不会少。所以相比之下，社区授权代表了对社会的好处，只不过是没有MIT和Apache2等开源授权那么大而已。

在Influx我们曾经研究过AGPL授权。第一版Flux中采用该授权的是Chronograf（我们的UI项目）。但后来我们将Flux改成了MIT授权，Chronograf移动到了InfluxDB中作为UI，采用InfluxDB 2.0的MIT授权。改变的原因是，这不仅对社区有好处，而且也有益于我前面说过的软件进化。我们希望更多的人使用这些代码，并建立最大的社区。因此，我们甚至请我们的竞争对手来修改并使用我们的代码。

原因是，我们早就认识到，Flux的价值在于集成了Flux和可能集成Flux的系统的数量。这条经验来自Telegraf，这是我们的一个数据收集项目，它一直都是MIT授权，并且收到了大量社区的贡献（它是我们最广泛使用、收到贡献最多的开源软件）。在建立Telegraf的时候似乎没有任何理由建立一个数据收集项目，但我们希望有些东西能无缝集成到InfluxDB的数据模型中。但我们需要激励社区，让社区愿意构建一些插件，从多个地方获取数据。因此我们决定，不应该将Telegraf限制为仅兼容InfluxDB。最的的结果是，我们接受了一些拉取请求，这些拉取请求可以将Telegraf集成到我们的竞争对手中。但是，当我们有了来自社区的几百个插件后，我们的竞争对手也有了同样的几百个插件。这些插件对我们有好处，也对他们有好处。所以，开源从来不是个零和游戏。

最后来揭示我对于创建开源业务的回答：采用自由授权的软件（如MIT或Apache2），并给你希望商业化的软件提供闭源商业授权。因为几乎所有SaaS产品或云平台都会在这种模型下为开源软件作出贡献，他们是否也能称自己为开源软件业务？我认为他们不应该。但是我认为，如果你有相当一部分开发者是全职编写开源软件，那你也可以声称自己是开源软件。在Influx，我们超过半数的开发者一直在编写开源代码。我们一直就是一家开源公司。

我已经写过很多文章讨论为什么我喜欢开放授权。我同时也喜欢商业授权，因为它在开放与封闭之间有明确的界限。其中开放就意味着任何人都可以做任何事。这给社会和社区带来了巨大的好处。而且，如果社区决定创建开源项目与你的商业授权软件竞争，他们也无需获得你的许可。尽管一些商业公司不喜欢这一点，但这种授权给予了社区必要的控制和权力，使之能够为你的项目做贡献并推广。如果你不喜欢这一点，那大可保持闭源，但要清楚，社区参与和保持控制力（以及商业化）两者不可兼得。最后，即使是闭源的API，也有可能被开源项目取代（我不想说Oracle引发的诉讼的事情）。

我听到过一些观点认为，社区授权还是要比闭源商业授权更好，因为闭源授权代表了你无法窥探的黑盒子。如果你这样认为，那你就不应该使用任何SaaS产品甚至云平台，因为它们都是闭源的黑盒子。你也需要雇佣真正懂得社区授权的开发者来工作。与人们一般的认知相反，你能阅读其代码并不代表它不是黑盒子。对于许多开发者来说，数据库的代码就是黑盒子，而实际上这并不是坏事。我们直接使用建立好的抽象，不需要每个开发者都要理解一切。

所以我喜欢完全自由的开源授权和商业授权。但是我更倾向于在一切地方都使用自由授权。但比尔盖茨也不会平白无故给我钱，所以通过开源给开发者们发工资的唯一途径就是让他们同时开发闭源软件，以此建立业务。我之前说过，开源软件永远都需要资金支持，我们必须认清这个现实。

同时，我们需要继续研究怎样才能为世界提供更多开源软件。这是我毕生的奋斗目标。

原文：https://dzone.com/articles/copyleft-and-community-licenses-are-not-without-me

本文为 CSDN 翻译，如需转载，请注明来源出处。

---

 热 文 推 荐 

print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！ ");
cout << "点个好看吧！" << endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"

点击“阅读原文”，打开 CSDN App 阅读更贴心！

喜欢就点击“好看”吧！