TL;DR: Lago chose the AGPLv3 license
Its terms and conditions can be found here.
At Lago, we’re on a mission to build the “Modern Pricing Stack”: an open and fair approach that enables any team to build the pricing system that fits their business needs, and not the other way around.
Open source seemed to be the only approach to achieve this. In a previous post, we went through the five reasons we chose open source:
- Open architecture;
- Developers first;
- Fair pricing;
- Composability; and
- Participative approach to address the long tail of edge cases.
Therefore, the license we would choose for our project had to reflect this mission. What were the other elements that fueled our thought process?
Incentivizing community contributions
We’ve spoken with hundreds of teams who built their billing system from scratch and are now struggling to maintain it. It’s a nightmare for engineers. In this context, opening our code was a no-brainer as we want teams to be able to build on Lago and customize it to fit their specific needs.
We had two different use cases in mind:
Case 1: You fork our code to build your own billing system at your company. It’s awesome and we would be grateful if you could take some time to share your code as well, as it could help other companies. This is strongly encouraged but not required, as we understand not all companies can afford to do this.
Case 2: You fork our code to build a product that you will then commercialize and earn money from. In that case, we think you must contribute back. There are two ways to do so: by sharing your own source code with the community, or by buying a commercial license from Lago, so that we can invest this money in our product, which benefits the whole community.
This is also a guardrail to avoid what Airbyte (the Open Source ETL) described very accurately:
“Some huge companies take the Airbyte project and start offering a clone of Airbyte Cloud. Yes, it has happened to MANY other Open Source companies.
The story is widely known already, but here is what would happen. They start with a fork of Airbyte. They start building features that go against Airbyte’s vision. The quality is lower, which negatively affects the perception others have of Airbyte. The documentation is split across multiple vendors. They keep 100% of the revenues they make. They don’t invest in the community or share any of their revenues with contributors who are working hard at making Airbyte better.”
Building for the long term: Sustainable Open Source
The other major element in our thought process is sustainability: if we want Lago to have a long-term impact, we need to become financially sustainable.
Indeed, although contributions from people who can afford to do unpaid work on Open Source projects (to build a reputation, or as a “creative outlet”) are very much appreciated, we can’t rely solely on them to change the paradigm around the pricing stack. It’s an ambitious mission, in a sector with a lot of powerful incumbents. Spearheading change requires resources, resilience and tenacity.
Marko Saric, co-founder of Plausible (the Open Source Google Analytics alternative) nailed it very well:
“In general, more resources going into open source projects will mean that more people will be able to spend more quality time focused on those projects which would make those products better and more useful to more people. That would help get more people to give a chance to open source products and even permanently switch from closed and proprietary options.”
It is also a concept coined by Ghost, the Open Source platform for journalism:
“We call this Sustainable Open Source.
The more people who use Ghost, the more customers we have, the more revenue we receive, the more great people we can hire to work for the foundation, the better the software gets, the more people use Ghost… and so on.
It's a virtuous cycle which means that we can keep creating open, adaptable software with a vibrant future, forever.”
Keeping it simple
At Lago, we optimize for speed of impact.
The billing and pricing stack space has a huge surface area, and powerful historical players. Making our mission a reality means being agile, smarter, and making more with less. So we’re obsessed with making things impactful, while keeping them as simple as possible.
Therefore, having our product split into several open-source or fair-use licenses sounded like “overengineering” at this stage: that would have been confusing for the community and meant extra-work for our tiny team, away from addressing real technical challenges.
What the AGPLv3 license is, and what it involves
Given the criteria listed above, we found the AGPLv3 license was the best fit for Lago.
We’ve done a lot of research on licensing and the clearest explanations we found were those of Marko Saric, co-founder of Plausible, on their blog.
Here is an extract from the paragraphs on the GNU AGPLv3 license:
“What is the GNU AGPLv3 license?
Copyleft license: “If you make a derivative work of this, and distribute it or run it as a service on a server to others then you have to provide the source code under this license”.
In the early 2000s, Stallman and others tried to close this cloud computing loophole and protect open source from this abuse by creating a new license. The GNU Affero General Public License (AGPL) was born.
What are the benefits of the AGPLv3?
The AGPL license is identical to the original GPL license with the only additional term being to allow users who interact with the licensed software over a network to receive the source for that program.
AGPL is designed to ensure corporations contribute back to the open source community even when running the software as a service in the cloud.
If you used AGPL-licensed code in your web service in the cloud, you are required to open source it. It basically prevents corporations that never had any intention to contribute to open source from profiting from the open source work.
It explicitly prohibits corporations from parasitically competing with an open source project. They won’t be able to take the code, make changes to it and sell it as a competing product without contributing those changes back to the original project.
Here’s that extra paragraph:
“If you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.”
What are the restrictions with the AGPLv3?
- A corporation needs to be clear and provide a prominent mention and link to the original project so people that are considering to use their version of software can be aware of the original source
- If a corporation modifies the original software, they need to open source and publish their modifications by for instance contributing back to the original project
So how can a corporation commercialize a FOSS (Free Open Source Software) project without open sourcing their modified code? They can purchase a commercial license to remove the copyleft restrictions and in that way support the original project.
FSF recommends the AGPLv3 license for projects in the cloud
Free Software Foundation (FSF) and the GNU project state:
“We recommend that people consider using the GNU AGPL for any software which will commonly be run over a network.”
“If it is likely that others will make improved versions of your program to run on servers and not distribute their versions to anyone else, and you’re concerned that this will put your released version at a disadvantage, we recommend the GNU Affero General Public License (AGPL). The AGPL’s terms are almost identical to the GPL’s; the sole substantive difference is that it has an extra condition to ensure that people who use the software over a network will be able to get the source code for it.””
If you have any questions, please get in touch with us at firstname.lastname@example.org.
To conclude, we would like to thank Marko Saric and the Plausible team for their impactful product and support to the Open Source community.