返回列表 发新帖

如何解决开源软件的中年危机?

[复制链接]

该用户从未签到

1万

主题

1万

帖子

3万

积分

合购之王

Rank: 3Rank: 3

积分
39469
发表于 7 天前 | 显示全部楼层 | 阅读模式

抱歉!您还未登录!请登录后继续浏览完整内容

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

作者 | Paul Dix译者 | 弯月责编 | 郭芮出品 | CSDN
2008年12月,confluent宣布将更改平台上某些功能的许可,而不是使用apache2,并改用fluent社区许可;2018年12月,confluent宣布将更改平台上部分功能的授权,不再使用apache2,但在此之前使用fluent community,AWS刚刚在Re:invent 2018上发布了AWS管理的Kafka服务;redislab将其特定插件授权改为common-clause授权;mongodb也将其授权从agpl改为服务器端public-license;在此之前,蟑螂宣布将采用蟑螂社区许可证,GCP、azure等公共云服务提供商对其业务活力构成威胁。
对于依赖开源项目的公司来说,最理想的开源道路是一个宽容的开源许可加上封闭的商业产品。和往常一样,这些观点还在变化,所以我现在写的是我目前的观点。将来,我可能会觉得我目前的观点很愚蠢,或者我可能会同意我对开源、云计算和业务的看法。现在免责声明已经结束,让我们回到开放源代码概念的历史,也就是说,开源软件应该能够免费为任何人和任何使用条件下使用、集成和创建衍生作品,无论是出于商业目的还是非商业目的。对于开源的概念,即开源软件应该能够免费为任何人和在任何使用条件下使用、集成和创建衍生作品,无论是出于商业目的还是非商业目的。曾经有一段时间,我认为我们可以在agpl或类似授权下提供集群,以限制云服务提供商,保护我们在OEM和托管服务方面的商业机会。但是最近,在看到各种授权更改之后,我意识到agpl、SSPL和社区许可证只是混水而已。它们带来了很多大型组织无法识别的授权。一些公司禁止使用agpl许可证,比如Google。然而,在分析这些许可证之前,我将首先细化各种争议的焦点,大致如下:(n)认为软件供应商声称自己是开源但实际上不是开源的人所引起的愤怒;(n)认为软件供应商声称开源但实际上不是开源的人所产生的愤怒开源;以开源的名义为诱饵,获取开源贡献,然后更改许可证;
所有这些都有一个共同点:它们的目标都是利用新的授权维护这些公司的软件在托管服务上的垄断地位——以开源名称为诱饵获取开源贡献,然后更改授权;
在这篇文章中,我将提炼这些改变招致的各种非议和愤怒,并从多个角度阐述我的个人观点。最后我会证明,从开源许可到限制许可的趋势(或者,用布莱恩·坎特里尔的话说,是开源软件的中年危机)。实际上,后一点正是我们在InfluxData采取的策略,因此我提出这个观点也许并不是太突兀,但我想说的是,InfluxData也走了许多弯路,在看到它与其他开源供应商、项目和社区的交流之后,我在这个问题上有了更清晰的看法。
开源供应商已经声明,新的社区许可证不是开源许可证,它只是提供源代码。
我们启动InfluxDB时,一切都是MIT授权,开发也完全在开放的环境下进行。这符合我当时(也是现在)认为以开源为诱饵改变授权有点夸张。编写开源软件的厂商、个人甚至基金会都没有承诺永远在开源模式下开发和改进软件。您的贡献基于现有软件。社区可以分裂,项目可以分化,用户和贡献者可能消失,供应商可能破产,或者他们可能被目标不同的公司收购。作为开源项目的主要开发者,如果一家公司长期无法找到收回成本的方法,那么最后一条路是不可避免的。尽管我认为我们的所有软件都应当采取MIT授权并保持免费,但在2016年早期,我们在商业化上碰壁了,所以不得不将产品中的集群和高可用性部分改成了封闭的商业授权。在我宣布这项变动的文章中,我写出了我的顾虑:担心云服务商会把我们的软件当作服务来提供。
对于社区而言,宽松的许可比“社区授权”更好的原因是它不限制衍生作品。
开源和开源之间应该有一个混合模型。最终,资本家将把许可证伪装成开源,同时保留一种商业化的方式。如果软件是一个不断进化的过程,需要在前人的基础上构建,那么copyleft就给进化带来了死胡同,而自由授权则代表着树上一个不断增长的新分支。
人们愤怒是因为他们认为所谓“开源”只不过是诱饵。社区赋权也是如此。只要你遵守他们的规章制度,他们是开放的,自由的,可以随意修改。它们是否属于开源实际上是一个语义上的争论。如果您认为它们不是开源的,那么copyleft许可就不是,除非您使用Crusader的解释。如果你不得不这么说,我建议你为世界崩溃的残酷现实做好准备。而人们依然拿着猎叉和火把围聚在厂商门前,因为他们觉得一些本应开放的东西被厂商拿走了。而且他们还认识到,社区会因为厂商的社区授权中的限制而遭受到局限或伤害。我认为,开源软件的短暂历史表明,整个项目和生态环境的授权越宽松,社区就越大、越有活力(尽管只有授权并不能保证开源项目的成功)。
明确地说,我并没有责怪redislabs、elastic、fluent、cockroach或任何急于创建社区许可证的开源软件供应商。他们完全有权这么做,我甚至认为这是一件好事,尽管有种种限制。为了给他们提供昂贵的开源开发资金。但是,这些社区许可证不再是开源许可证。
一个项目,不论是由社区驱动,还是由一家公司驱动,如果你不喜欢它的新方向,你可以在它改变授权之前的版本上创建新的分叉(或在拒绝一些你不想要的拉取请求之后),然后在派生的项目上继续使用、开发并培养新的社区。这就是为什么即使copyleft和community authorization用于业务,它们也不是没有任何价值和好处的。它们提供了一个可以自由使用和更改软件的规则示例。对于一些用户来说,这完全没有意义。他们只需要接受这样一个事实,即采用这些授权代码是他们所有商业产品的基础。社区授权的最大问题是,许多大型企业或高风险组织禁止大量不同的授权。因此,这些法规所惠及的人群范围将大大减少。尽管有这些限制,许多企业仍然依赖copyleft软件,所以我认为依赖社区许可软件的企业不会减少。所以相比之下,社区许可代表了一种社会利益,只是没有像MIT和Apache2这样的开源许可那么大。尽管如此,我们也应当更友善(同时也是更现实)地认为,厂商的这些决定是根据当前的环境作出的,而不是多年处心积虑诱惑开发者贡献代码再让项目人间蒸发的计划的一部分。就算真的有这种计划,贡献者和布道者们的努力也没有白费(参考上面关于分叉并创建派生作品的建议)。
最后一种观点认为这种趋势是开源软件的末日。同样,我认为这种看法也太夸张了。如果这的确是个问题,那么早在几年前SaaS和云服务成为软件发布的主流模型时就应该出现了。SaaS和云服务都是与开源运动直接对立的,因为它们都代表了闭源软件而不是开源软件(尽管它们主要是在开源软件的基础上构建的)。如果这是趋势,那么早在15年前就应该出现了。抛开夸张的一面不谈,我还认为,所以开源从来不是一个零和游戏。如果基础设施供应商想要把社区认为重要的东西改成闭源,那么其他项目和公司都会来解决同样的问题。开源意味着选择,只要开发者还有电脑、编辑器和网络,就会不断有新的选择出现。
后来透露了我创建开源业务的答案:使用免费许可的软件(如MIT或apache2),并为想要商业化的软件提供封闭源代码的商业许可。既然几乎所有的SaaS产品或云平台都将在这种模式下为开源软件做出贡献,那么它们是否也可以称自己为开源软件企业?我认为他们不应该。但我认为,如果你有相当多的开发人员全职编写开源软件,你也可以自称是开源的。在inquist,我们一半以上的开发人员一直在编写开源代码。我们一直是一家开源公司。
而资本家解释则是利用copyleft授权来保护商业模型。但是,资本家通常会伪装成十字军,因为大部分人更喜欢这种说辞,而不是说“我想用我的工作来赚钱”(尽管这种说法完全合理)。通常,授权的选择造成了所谓的“偶然资本家”。例如,我怀疑MySQL在选择GPL的时候考虑的就是在OEM合同中销售软件的商业授权,从而可以绕开GPL,这是他们(早期)的主要盈利模式。Mongo可能也是同样的方式,但我还没有机会直接询问Dwight或Elliot(我也不期待他们会毫无保留地回答,毕竟他们要运营一个上市公司)。即使是封闭源代码的api也可能被开源项目所取代(我不想谈论Oracle的诉讼)。
我听过一些观点,认为社区授权比开源商业许可更好,因为开源许可代表了一个你无法窥探的黑匣子。如果你这么想的话,你不应该使用任何SaaS产品甚至云平台,因为它们是封闭源代码的黑盒子。你还需要雇佣真正了解社区授权的开发人员。与流行的观点相反,仅仅因为你可以阅读代码并不意味着它不是一个黑匣子。对于许多开发人员来说,数据库代码是一个黑匣子,这不是一件坏事。我们直接使用已建立的抽象,不需要每个开发人员都能理解所有内容。原因是,自由授权的软件可以用来创建任何其他授权的软件,可以是copyleft,也可以是商业授权软件。而Copyleft软件只能被用来创建其他copyleft软件(除非一个公司拥有该copyleft授权,并将其卖给其他商业作品,这样也能产生进化的新叶)。再加上copyleft不仅对嵌入了代码的程序有要求(比如GPL),还对通过网络访问代码的程序有要求(比如AGPL或更严格的SSPL),这只会加剧这个问题。不管OSI怎么说,最终在我看来,copyleft代表的是真正的开源。Copyleft是一种限制。
原文:https://dzone.com/articles/copyleft-and-community-licenses-are-not-without-me
原文:https://dzone.com/articles/copyleft-and-community-licenses-are-not-without-me
本文由CSDN翻译。如需转载,请注明出处。
原因是,我们早就认识到,Flux的价值在于集成了Flux和可能集成Flux的系统的数量。这条经验来自Telegraf,这是我们的一个数据收集项目,它一直都是MIT授权,并且收到了大量社区的贡献(它是我们最广泛使用、收到贡献最多的开源软件)。在建立Telegraf的时候似乎没有任何理由建立一个数据收集项目,但我们希望有些东西能无缝集成到InfluxDB的数据模型中。但我们需要激励社区,让社区愿意构建一些插件,从多个地方获取数据。因此我们决定,不应该将Telegraf限制为仅兼容InfluxDB。最的的结果是,我们接受了一些拉取请求,这些拉取请求可以将Telegraf集成到我们的竞争对手中。但是,当我们有了来自社区的几百个插件后,我们的竞争对手也有了同样的几百个插件。这些插件对我们有好处,也对他们有好处。
我已经写过很多文章讨论为什么我喜欢开放授权。我同时也喜欢商业授权,因为它在开放与封闭之间有明确的界限。其中开放就意味着任何人都可以做任何事。这给社会和社区带来了巨大的好处。而且,如果社区决定创建开源项目与你的商业授权软件竞争,他们也无需获得你的许可。尽管一些商业公司不喜欢这一点,但这种授权给予了社区必要的控制和权力,使之能够为你的项目做贡献并推广。如果你不喜欢这一点,那大可保持闭源,但要清楚,社区参与和保持控制力(以及商业化)两者不可兼得。最后,
所以我喜欢完全自由的开源授权和商业授权。但是我更倾向于在一切地方都使用自由授权。但比尔盖茨也不会平白无故给我钱,所以。我之前说过,开源软件永远都需要资金支持,我们必须认清这个现实。
回复

使用道具 举报

发表回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表