开源还是不开源？
我们想分享我们对开源以及如何许可我们的代码的看法。在 Meili，我们正在用 Rust 🦀 构建一个即时搜索引擎，并希望将其开源。
我们想分享我们对开源以及如何许可我们的代码的看法。这对我们来说是全新的，我们仍在摸索最佳解决方案和机会，所以如果您有任何阅读建议，请不要犹豫告诉我们。
快速提醒一下：在 Meili，我们正在用 Rust 🦀 构建一个即时搜索引擎，并希望将其开源。我们仍在考虑适合我们的商业计划，可能也会写一篇关于它的文章，但今天的主题是许可证！
我们为什么选择开源？
我们相信每个应用程序都应该拥有一个不错的搜索引擎。这意味着搜索引擎技术应该成为一种商品。我们找到了一个完美的平衡点：Algolia 虽然非常开发者友好但却是专有的，而 Elastic Search 难以设置为即时搜索。
我们认为，如果你想成为你领域的标准技术，你就应该开源，这样你就可以与使用它的人一起构建你的功能，并赢得对你代码的信任。此外，因为我们是很酷的开发者，我们正在使用大量的开源代码，我们希望通过贡献开源和分享我们的项目来回馈社区。
什么是开源？
开源是复杂的，如果你问两个人开源的定义，你可能会发现开源有很多定义。Steve Klabnik 写了一篇非常有趣的博客文章，内容关于开源核心的文化之争，我们从中了解了开源历史以及人们为何对其定义争论不休。
最初，有自由软件基金会（Free Software Foundation），成立于1985年。FSF 由理查德·斯托曼（Richard Stallman）创立，旨在支持 GNU 项目和自由软件的概念：即软件应该可以自由使用、自由复制和自由再分发。然而，“自由”这个术语非常严格。对于 FSF 来说，自由软件必须采用“著作权开放”（copyleft）许可。著作权开放意味着所有派生作品也必须是著作权开放。我们称之为“遗传性”或“感染性”许可，我们很快就明白这种许可可能会吓退企业。
随后是开源促进会（Open Source Initiative），一个成立于1998年的非营利组织。埃里克·S·雷蒙德（Eric S. Raymond）和布鲁斯·佩伦斯（Bruce Perens）撰写了《开源定义》（Open Source Definition），该定义规定了限制较少的许可（如 MIT、Apache、BSD 等）。这些许可都要求注明你所使用软件的作者，但你构建的内容可以使用任何其他许可。这个《开源定义》的目标之一是更加“商业友好”，因为“自由”这个词可能会吓退公司，通过拥有一个更友好的名称和限制较少的许可，可以鼓励公司投资并参与开源。
为了说明这些差异，我们可以举两个基于 Unix 的操作系统：一方面是 Linux 内核，它采用 GPLv2 许可（著作权开放），这就是为什么基于 Linux 的 Android 是开源的。另一方面是 Berkeley 软件发行版（BSD），它采用 BSD 许可，其最著名的分支是 iOS 和 Mac OS，它们是专有和私有的。
这些是当今开源的定义，而问题在于
- 每个人对开源没有一个统一的定义，因为每个人都有自己的开源理念
- 每个人都没有遵守相同的规则：有些公司将他们采用 GPL 许可的项目发布在一些不知名的 FTP 上，而另一些公司则在 GitHub 上公开其代码，但没有获得 OSI 批准的许可。对你来说，什么是开源？
当今的开源
正如您可能在过去几个月读到的，一些“开源”项目出于同样的原因更改了它们的许可。我们认为 MongoDB 解释得非常好
对于开源项目来说，这是一个充满无限机遇的时代，有可能催生新一波优秀的开源服务器端软件。然而，现实是，一旦一个开源项目变得有吸引力，大型云厂商就很容易攫取所有价值，却不回馈社区。
他们也不是唯一一个担心这种情况的项目。
例如，Redis 正在以其自己的许可，即 Redis Source Available License，许可其部分 Redis 模块。他们之前使用的是附加在 Apache 许可之上的 Commons Clause。Commons Clause 在现有许可（如 Apache 许可）之上增加了一些商业分发限制。但是，他们因混淆原因而更改了它；人们不确定它是否是开源的。
Confluent 也更改了其许可，他们从 Apache 许可改为创建 Confluent Community License，因为他们也担心一些大型云公司。
开源与 Meili
关键不在于大公司是否应该更多或以不同方式贡献开源，而在于开源正在发展，我们需要一个新的定义，一个新的术语来凝聚共识，明确我们所谈论的内容。
也许我们需要标签来定义和规范我们公司所支持的理念？或许我们需要一个专利式的系统，规定你作为公司发布的每个代码在你编写三年后都将采用 MIT 许可或其他任何许可。这样你就可以在一段时间内通过你的代码获利，同时允许公开披露你的代码？
在 Meili，我们尚未对这些问题有明确的看法，但我们正在认真思考。我们希望我们的代码能够供任何人使用，自由地用于您的项目并进行修改。如果您想将其用于个人项目，请尽管使用；如果您想将其用于您的公司，也应该如此。我们不希望任何云提供商克隆我们的项目，并在 SaaS 产品上成为竞争对手。因为我们相信，如果能在此基础上建立可持续的业务，我们的项目将会更蓬勃发展。
今天，我们的代码仍采用 MIT 许可，但明天我们可能会像 MongoDB 和 Confluent 那样将其更改为 Commons Clause 或编写我们自己的公共许可。不，它不会像 OSI 所说的那样是开源的，但我们认为提供公开可用的源代码仍然比闭源更好，可惜今天还没有一个明确的术语来形容它。
