License to Code

Why Empathy.co chose Apache 2.0 to go open source with Interface X frontend components

One of the most strategic decisions in launching an open-source project is to choose a license. This license will drive how the contributors will see you, how third parties can consume, exploit, improve, fork, and create derivative works. In summary, how the community will embrace the project. Think of the license as the most obvious personality trait of the project.

Understanding the range of license options is not an easy task, but we can categorise them into two big groups:

• Copyleft: These kinds of licenses, such as GPL, Affero, or MPL, stand for reciprocal behaviour. These licenses imply that derivative works must be distributed under the same license. This is the way to maintain software freedom, forcing third parties using the project to be under the same copyleft license.
• Permissive: A permissive license, like MIT or Apache, stands for openness and the offer to third parties to take your work, wrap it, license it and make money off it if they have that interest.

At first look, and being a profit organisation, a copyleft license would seem the way to go because you keep the control, but with great power comes great responsibility. Going copyleft means the organisation will have more control over the code and derivative works. This prevents forking, for example, as the forked project must be copyleft too so the organisation could join that fork in the future and take advantage of that work.

Going copyleft would mean that if a commercial customer of the organisation wants to use the project, they should maintain your project license and open their software too — and we know not every customer is open to do that. Also, copyleft licenses add complexity in legal compatibility. For this type of scenario, Weak Copyleft licenses may be used to avoid the necessity of your customer opening their code.

Let’s say that copyleft is the philosophical choice for Free Software religion; all the code from other projects using your code will be free. So this simple fact may be the deciding factor in choosing the license for your project, because using a copyleft project in your dependencies forces you to adopt the same license.

On the other hand, a permissive license will empower freedom of choices that is in some ways way better than control. Going open source with the permissive route will make the community even more interested in your project because they can use your code in any way they choose. This interest might lead to more contributors and popularity based on the value of the code. Your commercial customer will not be worried about the license because they are not obliged to anything. They could even take the code and transform it to fit their own needs; and that will be fantastic because they might discover new paths to be adopted by your organisation.

Think of your competitors. They could take your project, study it, find value, download it, shape it, mark it under a different license and sell it themselves to your very same customers. But wouldn’t you love to say to the world that this just happened? That your open source project is at the heart of a competitor’s work?

Every project and every organisation has different philosophies, needs, and particularities, so the decision made here about publishing Empathy’s Interface X under Apache 2.0 permissive license could be totally wrong in other scenarios, even in this scenario. But we will love to discover that. What do you think?

I invite you to read more about our open source journey and come be part of it.

Special thanks to Malcolm Bain and his huge support in software licensing.