开源还是不开源？

我们想分享我们关于开源以及我们应该如何许可我们的代码的想法。这对我们来说是全新的，我们仍在研究最佳解决方案和机会，所以如果您有任何阅读建议，请随时告诉我们。

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

我们为什么选择开源？

我们认为每个应用程序都应该有一个像样的搜索引擎。这意味着搜索引擎技术应该成为一种商品。我们找到了 Algolia 和 Elastic Search 之间的最佳平衡点，Algolia 非常开发者友好但专有，而 Elastic Search 对于即时搜索来说设置起来很困难。

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

什么是开源？

开源很复杂，如果你问两个人关于开源的定义，你可能会意识到开源有很多定义。Steve Klabnik 写了一篇非常有趣的博客文章，内容是关于开源核心的文化战争，我们在其中了解了开源的历史以及人们为什么对其定义争论不休。

最初，有自由软件基金会，它成立于 1985 年。FSF 由 Richard Stallman 创立，旨在支持 GNU 项目和自由软件的概念：软件应该可以自由使用、自由复制和自由再分发。但是，术语“自由”非常具有限制性。对于 FSF 来说，自由软件必须在 copyleft 许可证下。Copyleft 意味着所有源自它的作品也必须是 copyleft 的。我们称之为“遗传性”或“污染性”许可证，我们很快理解这种许可证可能会吓到企业。

然后是开源促进会，一个成立于 1998 年的非营利组织。Eric S. Raymond 和 Bruce Perens 编写了开源定义，该定义框架了限制性较小的许可证（MIT、Apache、BSD 等）。这些许可证都要求署名您正在使用的软件的作者，但您正在构建的内容可以具有任何其他许可证。开源定义的其中一个目标是更“商业友好”，因为“自由”一词可能会吓到公司，并且通过使用更友好的名称和限制性较小的许可证，您可以鼓励公司投资和参与开源。

---

为了说明差异，我们可以以两个基于 Unix 的操作系统为例：一方面，Linux 内核是在 GPLv2（copyleft）下许可的，这就是为什么基于 Linux 的 Android 是开源的。另一方面，伯克利软件发行版（BSD）是在 BSD 许可证下许可的，其最著名的分支是 iOS 和 Mac OS，它们是专有的和私有的。

这些是今天的开源定义，问题是

• 每个人对一个定义意见不一致，因为每个人都有自己的开源意识形态
• 每个人都不遵守相同的规则：当一些公司在一些晦涩的 FTP 上发布其 GPL 许可的项目时，另一些公司在 GitHub 上公开发布他们的代码，而没有 OSI 批准的许可证。对您来说，什么是开源？

如今的开源

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

对于开源项目来说，这是一个绝佳的机会，有可能促进新一波伟大的开源服务器端软件。然而，现实情况是，一旦一个开源项目变得有趣，大型云供应商就很容易获取所有价值，但对社区没有任何贡献。

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

例如，Redis，正在根据其自己的许可证 Redis Source Available License 许可其一些 Redis 模块。他们之前在使用 Apache 许可证之上的 Commons Clause。Commons Clause 在像 Apache 许可证这样的现有许可证之上增加了一些关于商业分发的限制。但是他们出于混淆原因更改了它；人们不确定它是否是开源的。

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

开源和 Meili

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

也许我们需要标签来定义和框定我们作为公司支持的意识形态？也许我们需要一个专利式系统，该系统规定您作为公司发布的每段代码将在您编写后的 3 年内受 MIT 许可证或任何其他许可证的约束。这样您可以在一段时间内将您的代码货币化，同时允许公开披露您的代码？

在 Meili，我们对这些问题还没有明确的愿景，但我们正在对此进行大量思考。我们希望我们的代码对任何人可用，可以自由使用和修改它用于您的项目。如果您要将其用于某些个人项目，请去做吧，如果您想将其用于您的公司，您也应该这样做。我们不希望任何云提供商 git clone 我们的项目并在 SaaS 产品上成为竞争对手。因为我们相信，如果我们能够在其上建立可持续的业务，我们的项目将会更加蓬勃发展。

今天我们的代码仍然在 MIT 许可证下，但明天我们可能会将其更改为 Commons Clause 或像 MongoDB 和 Confluent 那样编写我们的公共许可证。不，它不会像 OSI 规定的那样是开源的，但我们相信，使源代码公开可用仍然比闭源要好，可惜今天没有明确的术语来形容它。