我们想分享我们对开源的看法以及我们应该如何授权我们的代码。这对我们来说是全新的,我们仍在寻找最佳解决方案和机会,如果您有任何阅读推荐,请随时告诉我们。

简单提醒一下:在 Meili,我们正在构建 一个即时搜索引擎,使用 Rust 🦀,我们想将其开源。我们仍在思考适合我们的业务计划,我们也可能会写一些这方面的内容,但今天的话题是许可证!

我们为什么要选择开源?

我们相信每个应用程序都应该拥有一个体面的搜索引擎。这意味着搜索引擎技术应该成为一种商品。我们找到了 Algolia 和 Elastic Search 之间的甜蜜点,Algolia 对开发人员非常友好,但属于专有软件,而 Elastic Search 对于即时搜索来说设置起来很困难。

这是我们的立场


我们认为,如果您想成为您所在领域的标准技术,您应该开源,这样您就可以与使用它的人一起构建您的功能,并获得对您代码的信任。此外,因为我们是酷炫的开发人员,我们使用了大量的开源代码,我们希望通过贡献开源并分享我们的项目来回馈社区。

什么是开源?

开源很复杂,如果您问两个人对开源的定义,您可能会发现开源有许多定义。 Steve Klabnik 写了一篇非常有趣的博客文章 关于开源核心中的文化战争,在这篇文章中我们了解了开源的历史以及为什么人们会争论它的定义。

喝水的野牛

最初,有自由软件基金会,该基金会成立于 1985 年。自由软件基金会由理查德·斯托曼创建,旨在支持 GNU 项目和自由软件的概念:软件应该可以自由使用、复制和重新发布。然而,术语“自由”具有很大的限制性。对于自由软件基金会来说,自由软件必须是 copyleft 许可的。copyleft 意味着所有衍生作品也必须是 copyleft 许可的。我们将其称为“遗传性”或“污染性”许可,我们很快意识到,这种许可可能会吓跑企业。

然后出现了开源倡议,一个成立于 1998 年的非营利组织。Eric S. Raymond 和 Bruce Perens 编写了开源定义,该定义框架了限制性较小的许可(MIT、Apache、BSD 等)。这些许可都要求对您使用的软件的作者进行署名,但您构建的内容可以采用任何其他许可。开源定义的目标之一是更加“对商业友好”,因为“自由”一词可能会吓跑公司,而拥有更友好的名称和限制性较小的许可可以鼓励公司投资并参与开源。


为了说明差异,我们可以以两个基于 Unix 的操作系统为例:一方面是 Linux 内核,它是根据 GPLv2(copyleft)许可的,这就是为什么基于 Linux 的 Android 是开源的。另一方面是 Berkely 软件发行版(BSD),它是根据 BSD 许可授权的,它最著名的分支是 iOS 和 Mac OS,它们是专有和私有的。

深入思考

这些是当今的开源定义,问题是

  • 每个人对开源的定义都不一致,因为每个人都有自己的开源意识形态
  • 每个人都遵守不同的规则:一些公司在一些不知名的 FTP 上发布其 GPL 许可的项目,而另一些公司则在 GitHub 上公开发布其代码,却没有使用 OSI 批准的许可。什么是您眼中的开源?

当今的开源

正如您在最近几个月可能读到的那样,一些“开源”项目出于相同的原因改变了其许可。我们认为 MongoDB 解释得很好

这是一个开源项目前所未有的机会,有可能促进新一波优秀的开源服务器端软件的发展。然而,现实是,一旦开源项目变得有趣,大型云供应商很容易就能获取所有价值,却对社区毫无贡献。

而且它们并不是唯一担心这种情况的项目。

例如,Redis 正在将其一些 Redis 模块授权给自己的许可,即 Redis Source Available License。他们之前使用 Apache 许可下的 Commons Clause。Commons Clause 在现有 Apache 许可之上添加了关于商业分发的某些限制。但是 他们出于混乱的原因将其更改;人们不确定它是否开源。

Confluent 也改变了其许可,从 Apache 转为创建 Confluent Community License,因为他们也害怕一些大型云公司。

一群长颈鹿朝着同一个方向前进

开源和 Meili

重点不在于大型公司是否应该更多或以不同方式贡献开源,而在于开源正在不断发展,我们需要一个新的定义,一个新的术语来凝聚在一起,并知道我们在谈论什么。

也许我们需要标签来定义和框架我们作为公司支持的意识形态?也许我们需要一个类似于专利制度的东西,它规定公司发布的任何代码在您编写代码后的三年内都将根据 MIT 许可或其他任何许可授权。这样您就可以在一段时期内将代码货币化,同时允许公开披露您的代码?

在 Meili,我们还没有对这些问题形成明确的愿景,但我们一直在认真思考。我们希望我们的代码对任何人都是可用的,可以自由地将其用于您的项目并进行修改。如果您要将其用于个人项目,请随时使用;如果您想将其用于公司,也应该使用。我们不希望任何云提供商克隆我们的项目,成为 SaaS 产品的竞争对手。因为我们相信,如果我们能够在这个项目上建立一个可持续的业务,它将更加繁荣。

今天 我们的代码仍然是根据 MIT 许可授权的,但明天我们可能会将其更改为 Commons Clause,或者像 MongoDB 和 Confluent 一样编写我们自己的公共许可。不,它不会像 OSI 那样是开源的,但我们相信,公开发布源代码仍然比闭源好,只是今天还没有一个明确的术语来描述它。