Jan 27
Why we went for the Elastic License
With the Add to Calendar Button, we created a big hit in the open source world.
But is it really open source?
When it comes to licenses, people usually start big fights about that.
With the mentioned project, we finally went with the Elastic License v2 and are now no longer promoting the project as “open source”. Despite the fact that, in our opinion, it still is. Because it is free to use, you get full access to the code, and it still is somehow community driven. However, you cannot sell it as your product.
The latter one should be a no-brainer, but it often is not — and this is the root cause of the big discussion in the open source community.
Protecting open source software
Open source software is essential to the modern world and has become an integral part of many aspects of life. It is created by an international network of developers who work together to make new code free for everyone to use and benefit from. This method of collaborative work has been responsible for some of the most groundbreaking advances in technology.
Open source software is one of the best gifts to come from the internet. It is a form of software provided to the public without crazy restrictions. This means that anyone can use, modify, and explore the code. It also means that open source code can be used to create other forms of software or complete projects without having to pay licensing fees for code that is owned by someone else.
At the same time, using open source code does come with some risks. One of them is code being resold by third parties without proper attribution to the creators. This can be extremely detrimental for those who develop their own versions of the code, investing both time and resources into the project. In order to protect their investment, it is important to protect open source code and make sure it is only used as intended.
The rise of stronger OSS licenses
That is one of the reasons why the Elastic license was created. It is a strong open source license that provides protection against misuse of code and theft. This license is particularly effective at safeguarding the core ideas and concepts of the code. It also safeguards the authors of the original code against malicious changes to their code by others. Essentially, the Elastic license helps to ensure that open source code remains free and available for others to use and build upon.
Overall, protecting open source software is essential for preserving the free exchange of ideas online. By using a strong open source license like the Elastic license, developers can protect their work from potential misuse. This helps to not only protect their investment in developing the code, but it also helps to ensure that open source code remains accessible and can be used for many different kinds of projects.
As mentioned above, there is a lot of discussion about whether this can be still considered open source or not.
The Open Source Initiative (OSI) clearly said “no”, since they are following the idealistic approach, open source had been created from.
Whether this is always the way to go should be questioned.
Fact is: There are a lot of stronger OSS licenses being used every day. May it be a dual-license approach, something like the Elastic license (ELv2), the MariaDB Business Source License (BSL), or the Server Side Public License (SSPL).
If you are interested in more details and controversies, check the following very well written article:
Or this piece by Igor Kotua: https://igorkotua.com/strong-oss-licenses/
It depends on what you are building
The fight is on.
However, it feels not right to paint this black and white.
In the end, it highly depends on what you are building. It makes a difference for both, you and the community.
If you build something, where there is no commercial use, since it is only some middleware, a very soft license might be the way to go. Or imagine a project, where you do not want to do all the work, but only want to work with others on it. This even requires a soft one.
On the other side, if you are doing 99% of the work, you might want to make sure that others do not profit from it without you getting your cut (may it be fame or money). Or something, where it is important that there is clearly 1 specific code base. This is often the case when it is rather used by lay people, that trust that open source code is safe and maintained.
In the end, working on a project with multiple stakeholders depends a lot on the stakeholders, the project, the product, and the goals behind each of those things.
Whether a stronger open source license fits your project always needs to be evaluated individually!
Our case
With the “Add to Calendar Button” project, we were looking at a piece of software, which people really love to use, but actually nothing where a lot would want to contribute. This is due to many reasons. For the sake of this article, let’s simply accept that such a project is mainly driven by the core team.
At the same time, a lot of people started to publish it as their own project; removing copyright notes and replacing them with their own, etc. Something you are not allowed to do with most OS licenses. However, we realized that people were not even aware of the issue here. Many think that if something is open source, you can make it your own — without giving credits. Despite this being a little unfair, it brings a lot of other issues, like people installing this stolen code, which is usually then no longer up-to-date, and then complaining on our side about problems or security issues.
We are not worried that “Big Tech” is stealing our code, but that such unallowed usage harms the overall product and its users.
Last but not least, we already had a quite strict license before. The Apache 2.0 with the “Commons Clause” addition. However, people usually only read “Apache” and did not further investigate whether it really is or not.
All of this (and much more) made us go for the Elastic License in the end.
Elastic License, because it provides a lot of freedom, while being quite strict about offering the software as a product to others.
It is also extremely simple and easily readable (check it out). In the end, we are looking at similar arguments, that Elastic itself used when introducing the license (source). Maybe with the big difference, that the Add to Calendar Button is not part of any core infrastructure, but rather a fancy and useful feature.
What also was important to us: No one is losing anything and if you are using the code in your project (which is not about offering an Add-to-Calendar-Solution), it still makes sense to contribute, if you experience some gaps.
To us, it is still open source and that’s how we interact with the users and contributors — because we believe in the idea of sharing code and offering any freedom possible. However, we now have a stronger argument against all those people messing around and threatening the open source idea (how we see it).
If you are considering using the Add to Calendar Button, please do so!
It is still free and comes without any restrictions in most cases. Check the license for details. In doubt, simply ask! Open source is about collaboration and communication.
That’s it. That’s the story.
And besides that, we are also still publishing “real” open source stuff, like our “Time zones iCal Library” 😉.
