Sign in Subscribe

Founders guide to Open Source Licenses

Founders guide to Open Source Licenses
Speaking To Matt and Eric on Scaling DevTools podcast

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.

This article is based on this podcast episode.

Two key questions for license selection

1. How mission critical is your product?

  • Does your product handle critical infrastructure?
  • What's the impact of failure?
  • How integrated is it into core operations?

2. How complex Is your product?

  • Deployment difficulty
  • Operational complexity
  • Scaling challenges
  • Maintenance requirements

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:

  1. Developer Adoption - Reduced friction, Community trust, Faster growth
  2. Enterprise Acceptance - Pre-approved license lists, Simpler legal review, Faster procurement
  3. 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
  • Example: MongoDB initially used AGPL

Real world example: MongoDB

  • Started with AGPL
  • Switched to dual licensing model
  • License complexity actually helped drive commercial sales
  • Enterprises would pay to avoid AGPL uncertainty

Post Open Source movement

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. 

Trigger:

Licenses

*Disclaimer: This episode provides general information, not legal advice.*