Scaling DevTools: Founders guide to Open Source Licenses
Published about 11 hours ago • 3 min read
24 Nov 2024
There are more and more Open Source DevTools startups. I’ve interviewed dozens. But I am still confused about open source licenses. So I decided to ask questions to two people who actually understand them: my friends Eric and Matt - founders of open source background jobs tool Trigger.dev.
If you are mission critical and your project is difficult to run and scale, you should be fine with a permissive license.
That’s Trigger, so they chose Apache-2. Trigger aren’t worried about enterprises not paying them because they will value Trigger’s operational expertise of running it because a) it’s complex and b) they don’t want it to fall down.
Separately, they also don’t expect AWS to compete with them. And besides, in their minds, that would be a good problem to have.
On the other hand, if your code is easy to deploy and scale and it’s not super mission critical, it will be difficult to build a business if all your code is open source with a permissive license.
What are the benefits of permissive licenses?
Matt points out that everyone talks about the risks but not the benefits of permissiveness:
Developer Adoption - Reduced friction, Community trust, Faster growth
Ecosystem Growth - More contributions, Better integrations, Stronger community.
What are the main licenses?
Two most permissive open-source licenses:
MIT - The "most permissive license" according to Matt - allows virtually any use.
Apache-2 - similar to MIT but with trademark protection. Supabase use Apache-2.
Protective open source licenses
GPL: Requires derivative works to be open source
AGPL: Closes the "SaaS loophole"
FSL: New 2-year competitor protection model
Open Core
Some code has an open license, e.g. MIT or Apache 2.0. While some folders in the codebase have a commercial license.
This means some features are not open source and can't be used without paying for a commercial license.
This is most commonly used for enterprise features (in /ee folders) like Single Sign-On and Role Based Access Controls, which enterprises really care about. It protects against enterprises running at scale without giving back.
PostHog is an example of OpenCore with MIT + ee folders. They have scalability features, like ClickHouse, and enterprise requirements like SSO.
Mixture of public and private repositories
Some open source startups have parts of their product be in an OSS repo but have other private repos which might have other enterpriser features or scalability stuff.
Why shouldn’t you write your own (open source) license?
According to Matt, this is one of the biggest mistakes, because companies will not agree with it unless you are very important to them. So you are losing a lot of the benefits of open source.
What is Copyleft?
Copyleft is a play on “copyright” - instead of restricting copying (right), it ensures sharing (left). Think of it as saying "you can use this code, but if you do, you've got to share your changes too." GPL was the first and most famous copyleft license.
Key Aspects of Copyleft
Basic definition
Collection of licenses including GPL
Requires derivative works to also be open source
Uses copyright law to enforce sharing
How Copyleft actually works
Not "infectious" - using GPL code doesn't automatically change your code's license
Only applies when you distribute software using GPL code
Only copyright holders can enforce the terms
Common enterprise concerns
Technical integration questions (linking, API calls)
Uncertainty about what constitutes "derivative work"
Often requires legal review
Closing the SaaS loophole (AGPL)
GPL primarily affects distributed software
Running GPL code as a service (SaaS) bypassed sharing requirements
Solution: AGPL created in 2007. Specifically covers network/SaaS use
To a lot of younger people, if they can see the code and open a pull request, it’s open source no matter what the license says.
In the dictionary definition it may not be because there are only 100 or so licenses designated as open source. But Eric argues perhaps we’re moving more towards fair source and other definitions.
*Disclaimer: This newsletter provides general information, absolutely not legal advice.*
By the way, this week I also put together a big list of DevTools from the Scaling DevTools guests.
Scaling DevTools is sponsored by WorkOS. If you're working with enterprise customers, they can help you cross the feature chasm and give you features out the box like SSO, audit logs and user provisioning/de-provisioning.
17 Nov 2024 John O'Nolan is the founder of Ghost, a publishing platform that's grown to $7.2M+ in revenue while tearing up the startup playbook. John was once WordPress.org's VP of Design (a voluntary role) and his experience of the tensions between the open source project and Automattic's commercial interests led him to start Ghost. Ghost is structured as a non-profit, John and his cofounder have no ownership stake and they did not take any external investment. In our conversation, we...
Scaling DevTools Newsletter 11 Oct 2024 I just hit 100 episodes of Scaling DevTools. It feels symbolic for me because of this Mr Beast quote I read early on. "If you are just getting started on YouTube, do not expect to pull any type of viewership in your first year. If this isn't something you can accept, don't start. But if you can, then you need to do this: make 100 videos. It doesn't matter what they are because they will be terrible, but do something you like doing. Your first 10 videos...
Scaling DevTools 01 Sep 2024 One of the things I get asked a lot is "How do open source projects make money"? And this week I chatted with Vlad Matsiiako from Infisical - an open source secrets management tool. So I decided to delve into the how's and why's of Open Source companies. Vlad and I How do Open Source companies make money? Here are the main ways I've seen: SaaS/cloud - like any other SaaS, they sell a hosted version of their software. Within this there might be parts of the product...
