Licenses and how they impact a project or product

Feb 2, 2021 · 6 minute read · Comments
licenças opensource portuguese

"papers with law description"

How to decide about what technologies, frameworks and/or platforms will be the base to develop products and services aren’t many times rational decisions. They are strongest influenced by personal experience, buzzwords, etc.

This is clear when people in the leadership role decide on A or B technology, many times the decision is too influenced by previous successful projects, a recommendation for other people, or commercial partners. There isn’t any issue about how to decide like situations mentioned previously since there is a clear idea about what technology has good and bad versus how the team is prepared to adopt the tech decided.

An example is when I was CTO of EdTech, one of my responsibilities was picking technologies to develop a new platform until hire software engineers and we can decide together. The stack was Python and Django as backend, [PostgreSQL] as database, for frontend would one of those more popular (at least for me), Angular, Reac or Vue. We waited for frontend people to hire and discuss with them how these frameworks will use.

I chose Python and Django (REST) was Python because is a programming language with a low learning curve compared to other languages (doesn’t mean it’s easy), it’s very popular and more smooth to hire software engineers than other languages. Another important part of the stack foundation is that any artifact will release by container, not just because containers are cool but when apply in the whole development pipeline have a gain of productivity (DevOps State Report 2018). Initially using Docker and deploy VMs and nearly move to Kubernetes.

PostgreSQL is a really cool database that we can use for kinds of purposes, most cloud providers offer it as managed service, and Python ORMs as SQLAlchemy and Django ORM have good support for it. In a previous AI startup that I worked on, PostgreSQL was used to store Event Sourcing data. Thank you (Mario Idival)[https://twitter.com/marioidival] for your insight and implementation.

Certainly, I can’t say that I didn’t have a bias to decide about technologies. Even though I token decisions based on good arguments, I have to recognize that I have some bias. Containers to delivery artifacts and PostgreSQL as default database were chosen base on previous projects that have success in my experience.

There isn’t any problem to make decisions but it’s better when you can bring your team because will they use these technologies and become easier to identify the limits and weaknesses of each technology in your development cycle and production environment. Also, they will say they are comfortable learning that and look at other technologies without the pressure of obligation to learn base on a decision top-down.

However, there is a side that a few discuss when decide what are technologies will adopt. But, this is change after MongoDB and Elastic change license to SSPL, this becomes a subject important.

An important note: I’m not a lawyer, this analysis is an opinion. Don t use the content below as a reference, check a specialized company if want an opinion about that you adopt open source in your company.

In the startup example mentions before, most of part the snack is based on the permissive license (BSD): PostgreSQL, Django e Django REST. Python (PSF License Agreement) and Psycopg2 (LGPL-3) are “derivaded” of GPL-2 and GPL-3. React and Next.js use MIT license, most of dependencies libraries of projects that we developed used BSD, MIT or Apache-2.

Many time we thought to use ElasticSearch as part of our foundation stack, but if consider today to start a project in a company while I’m writing this text I confess that I’ll think two times.

1. ElasticSearch isn’t under an Open Source license

Always that possible I prefer to adopt technologies with open source license and have good and transparence governance. This potentializes an amazing technological and economic collaboration environment, a good example is CNCF Landspace mapped as open source that has a market cap estimate of $10.65T.

The SSPL license isn’t conside Open Source for Open Source Initiave (OSI).

2. Broke the ecosystem and users become clients after the 7.11 version.

Volunteer or not, Elastic had the strongest ecosystem around Elastic that companies have growth like Logz, CrateDB and Aiven but the ecosystem is broken because of the license change. This means that a part of a robust ecosystem (users, clients, partners, coopetitors, volunteers, etc…) around an Open Source project will eliminate. It isn’t Elastic that change to SSPL, MongoDB was a pioneer, and the last year Graylog change too.

Sure, it’s understandable why they change the license, but it’s not something like - “We are good and they are evil”.

What’s the better license?

Do you know the default consultor answer? “Depends…”

As a technology user

Follow what developers (people and/or companies) are thinking about the future of the project that it’s based on your stack. Changes like that don’t arrive overnight.

As technology user and developer too

It’s the same as that phrase above but an important thing to add. If you or your organization think to contribute to a project, take a look at how the governance project happens. The projects under the Apache Foundation and CNCF have a good and clear governance process.

As a developer technology

The license of a project must choose base on the business model that the company wants to follow. For any kind of Open Source license that has a good case success, here some examples:

Canvas é um LMS com a licença AGPL desenvolvido pela Instructure
Next.js é um “React Framwork” com a licença MIT desenvolvido pela Vercel
MariaDB é um banco de dados com a licença GPL-2 desenvolvido pela MariaDB
PostgreSQL é um banco de dados com a licença BSD

There isn’t any problem If you want to use in your stack some project with SSPL, but you must know that it isn’t Open Source. 😉

Fernando Ike