开源还是不开源？

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

快速提醒：在 Meili，我们正在用 Rust 🦀 构建一个即时搜索引擎，我们希望将其开源。我们仍在思考适合我们的商业计划，我们也可能会写一篇关于它的文章，但今天的主题是许可！

我们为什么选择开源？

我们认为每个应用程序都应该拥有一个体面的搜索引擎。这意味着搜索引擎技术应该商品化。我们在 Algolia（对开发者非常友好但专有）和 Elastic Search（难以设置即时搜索）之间找到了一个完美的平衡点。

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

什么是开源？

开源是复杂的，如果你问两个人开源的定义，你可能会发现开源有很多定义。Steve Klabnik 写了一篇非常有趣的博客文章，讲述了开源核心的文化战争，我们从中了解了开源的历史以及人们为何争论其定义。

最初，存在自由软件基金会（FSF），它成立于 1985 年。FSF 由 Richard Stallman 创立，旨在支持 GNU 项目和自由软件的概念：软件应该可以自由使用、自由复制和自由再分发。然而，“自由”这个词非常严格。对于 FSF 来说，自由软件必须采用 copyleft 许可证。Copyleft 意味着所有派生作品也必须是 copyleft。我们称之为“继承性”或“污染性”许可证，我们很快就明白这种许可证可能会吓跑企业。

然后是开放源代码促进会（Open Source Initiative），一个成立于 1998 年的非营利组织。Eric S. Raymond 和 Bruce Perens 撰写了《开放源代码定义》，它框定了限制较少的许可证（MIT、Apache、BSD 等）。这些许可证都要求注明您正在使用的软件作者，但您正在构建的作品可以使用任何其他许可证。这个《开放源代码定义》的目标之一是更加“对商业友好”，因为“自由”这个词可能会吓跑公司，而通过拥有更友好的名称和限制较少的许可证，您可以鼓励公司投资并参与开源。

---

为了说明这些差异，我们可以以两个基于 Unix 的操作系统为例：一方面是 Linux 内核，它采用 GPLv2 许可（copyleft），这就是基于 Linux 的 Android 是开源的原因。另一方面是 Berkely Software Distribution (BSD)，它采用 BSD 许可证，其最著名的分支是 iOS 和 Mac OS，它们是专有和私有的。

这些是当今开源的定义，问题在于

• 每个人对一个定义都存在分歧，因为每个人都有自己的开源理念。
• 每个人都不遵守相同的规则：虽然有些公司在一些鲜为人知的 FTP 上发布其 GPL 许可项目，但其他公司则在 GitHub 上公开其代码，却没有 OSI 批准的许可证。对您而言，什么是开源？

现今的开源

正如您在过去几个月可能读到的那样，一些“开源”项目出于同样的原因改变了它们的许可证。我们认为MongoDB 解释得非常好：

这是一个开源项目拥有令人难以置信机遇的时代，有可能催生新一波优秀的开源服务器端软件。然而，现实是，一旦开源项目变得有趣，大型云供应商就太容易攫取所有价值，却不回馈社区。

他们并非唯一担心这种情况的项目。

例如，Redis 正在将其部分 Redis 模块置于自己的许可证下，即 Redis 源代码可用许可证。他们之前在 Apache 许可证之上使用 Commons Clause。Commons Clause 对现有许可证（如 Apache 许可证）的商业分发增加了一些限制。但是他们因混淆原因更改了它；人们不确定它是否是开源的。

Confluent 也更改了其许可证，他们从 Apache 许可证改为创建 Confluent Community License，因为他们也担心一些大型云公司。

开源与 Meili

重点不在于大公司是否应该更多地或以不同的方式为开源做出贡献，而在于开源正在演变，我们需要一个新的定义，一个新的术语来凝聚共识并知道我们正在谈论什么。

也许我们需要标签来定义和界定我们作为一家公司所支持的理念？也许我们需要一个专利式的系统，规定您作为一家公司发布的所有代码在您编写三年后都将采用 MIT 许可证或任何其他许可证。这样您就可以在一段时间内将您的代码货币化，同时允许公开披露您的代码？

在 Meili，我们对这些问题还没有清晰的愿景，但我们正在深入思考。我们希望我们的代码对任何人开放，可以自由使用和修改用于您的项目。如果您想将其用于个人项目，请尽管使用；如果您想将其用于公司，也应该这样做。我们不希望任何云提供商克隆我们的项目并成为 SaaS 产品上的竞争对手。因为我们相信，如果我们能在此基础上建立可持续的业务，我们的项目将会更加蓬勃发展。

今天，我们的代码仍然采用 MIT 许可证，但明天我们可能会将其更改为 Commons Clause，或者像 MongoDB 和 Confluent 那样编写我们自己的公共许可证。不，它不会像 OSI 所说的那样是开源的，但我们相信公开源代码仍然比闭源更好，可惜今天还没有一个明确的术语来形容它。