We want to share our thoughts about open source and how we should license our code. This is entirely new to us, and we are still figuring out the best solution and opportunities so if you have any reading recommendation do not hesitate to tell us.

As a quick reminder: at Meili, we are building an instant search engine, in Rust 🦀, and we want to open source it. We are still wondering about the right business plan for us, and we may write about it too but the subject of the day is license!

Why did we choose to go open source?

We believe that every application deserves a decent search engine. That means that search engine technology should become a commodity. We found a sweet spot between Algolia which is very developer-friendly but proprietary and Elastic Search which is difficult to set up for an instant search.

This is were we stand



We think that if you want to become the standard technology in your field, you should be open source, that way you get to build your features with the people who use it and you gain trust around your code. Also, because we are cool developers, we are using a lot of open source code, and we want to give back by contributing to open source and also sharing our projects.

What is open source?

Open source is complicated, and if you ask two persons a definition of open source, you may realize that there are many definitions of open source. Steve Klabnik wrote a very interesting blog post about the culture war at the heart of open source in which we learned about open source history and why people are fighting over its definition.

Buffalos drinking water

In the beginning, there was the Free Software Foundation, which was created in 1985. The FSF was founded by Richard Stallman to support the GNU Project and the concept of Free Software: the idea that software should be free to use, free to copy it and free to redistribute it. However, the term Free is very restrictive. For the FSF, a Free Software must be under a copyleft license. Copyleft implies that all the work deriving from it must also be copyleft. We call this a “hereditary” or “contaminating” license, and we quickly understand that this kind of license could scare businesses.

Then there was the Open Source Initiative, a non-profit organization created in 1998. Eric S. Raymond and Bruce Perens wrote the Open Source Definition which frames less restrictive licenses (MIT, Apache, BSDs, etc.). These licenses all require to credit the author of the software you are using, but what you are building can have any other license. One of the goals of this Open Source Definition was to be more "business-friendly" because the term "Free" could scare companies, and by having a more friendly name and less restrictive licenses you can encourage companies to invest and participate in open source.

To illustrate the differences, we can take two OS based on Unix: On one side there is the Linux kernel which is licensed under the GPLv2 (copyleft), and this is why Linux-based Android is open source. On the other hand, there is Berkely Software Distribution (BSD) which is licensed under the BSD license, and its most famous fork are iOS and Mac OS which are proprietary and private.

Deep thinking

These are today's definitions of open source, and the problems are:

Everyone does not agree on one definition because everyone has its ideology of open source

Everyone does not play by the same rules: while some companies are releasing their GPL's licensed projects on some obscure FTP, others are releasing their code publicly on GitHub without an OSI approved license. What is open source to you?

Open source nowadays

As you may have read in the last months, some "open source" projects changed their license for the same reasons. We think that MongoDB explains it very well:

This is a time of incredible opportunity for open source projects, with the potential to foster a new wave of great open source server-side software. The reality, however, is that once an open source project becomes interesting, it is too easy for large cloud vendors to capture all the value but contribute nothing back to the community.

And they are not the only project worrying about this situation.

Redis, for example, is licensing some of its Redis Modules under its own license, the Redis Source Available License. They were previously using the Commons Clause over an Apache license. The Commons Clause adds some restriction on commercial distribution over an already existing license like the Apache one. But they changed it for confusion reason; people were not sure whether it was open source or not.

Confluent changed its license too, from Apache they choose to create the Confluent Community License because they were afraid of some big cloud companies too.

A gang of giraffes going in the same direction

Open source and Meili

The point is not about whether big companies should contribute more or differently to open source but that open source is evolving, and we need a new definition, a new term to gather around and know what we are talking about.

Maybe we need labels to define and frame the ideology we are supporting as a company? Perhaps we need a patent-style system which states that every code that you release as a company will be under the MIT License or any other license 3 years after you wrote it. This way you could monetize your code for a period while enabling public disclosure of your code?

At Meili, we do not have a clear vision on these issues yet, but we are thinking about it a lot. We want our code to be available to anyone, free to use it and modify it for your projects. If you're going to use it for some personal project, go for it, if you want to use it for your company you should too. We do not wish to any cloud provider to git clone our project and be a competitor on a SaaS offering. Because we believe that our project will thrive more if we can build a sustainable business on it.

Today our code is still under the MIT license, but tomorrow we might change it for the Commons Clause or write our public license as MongoDB and Confluent did. No, it won't be open source as the OSI state it, but we believe that making a publicly available source code is still better than closed source, too bad there is not a clear term of it today.