← Previous · All Episodes
How not to do Open Source Licensing, with Trigger.dev founders Matt Aitken and Eric Allam Episode 109

How not to do Open Source Licensing, with Trigger.dev founders Matt Aitken and Eric Allam

· 50:05

|
Matt:

Honestly, I don't take a dev tools product seriously if it's not open source

Jack:

Really?

Matt:

In 2024. Yeah.

Jack:

More and more people are launching open source dev tools. But for me at least, licensing is still very confusing. So I invited Eric and Matt, who are the founders of trigger. Dev and know more about open source licensing than any other DevTools founders that I've met. Yeah.

Jack:

Wow.

Eric:

So that's the book there. It's pretty thick. Just show

Jack:

it sideways, you see, I'll figure this.

Eric:

And that's where I'm at.

Jack:

And in this episode, they share what you actually need to know as a founder about open source licensing. It's a good one.

Matt:

That's probably the worst decision you could make. Yeah. Is choose like a weird license. Especially as you start to think about, like, bigger companies.

Eric:

We would love if people set up a switch.

Jack:

Even if you weren't getting paid

Matt:

for that? Everyone has quite a strong opinion, and also they disagree, like, a lot.

Jack:

Something that we were talking about at the pub, well, Matt and I were talking about at the pub was kind of open source licensing.

Matt:

Mhmm.

Jack:

And, you know, I think this is especially on topic right now with what's going on with WordPress. It's kinda taken over everyone's, like, Twitter feeds. But, plus the, the cursor well, no. The Versus code

Eric:

Continue. Continue. Continue.

Matt:

For Yeah.

Jack:

And so there is bit of, like, kind of, you know, stuff. But I know it's something that you guys have looked into a lot. And, also, I think that, you know, of the teams I've met, I think you're among the most, like, passionate about open source and, like, you really want to, like, do it right and also, like, build, like, a build a start up, but, like, be, like, a good kind of Internet citizen. And, I know that yeah. I kinda wanted to hear how you've been thinking about it and what you've learned about licensing.

Matt:

There are also so all of that stuff is totally true. And I guess we we wanted to make Trigger open source and very, like, open source. Like, so MIT is, like, the most permissive license you can have, but basically, you can do whatever you want with it. And then I'd say Apache 2 is, like, the next most permissive, and it just adds trademark, basically. Mhmm.

Matt:

But I guess the reason we got we caught this bug was we built another open source project called JSON Hero, which is, like, completely is that is that even MIT?

Eric:

That's MIT.

Matt:

It's MIT. And that did really well. And we have, like, a hosted version. But that was, like, so exciting

Jack:

Yeah.

Matt:

And fun. That's what basically got us really into it, I think.

Eric:

Yeah. Because, I mean, I've I've worked on mostly closed source stuff for my career even though, like, yeah, even when I was doing, like, code school, that was like a developer education platform. That was all, like, closed source and stuff. Obviously, it was using and teaching open source stuff, but, yeah, it's I think when we did the JSON Hero thing and saw the reception and started the issues coming in and the pull requests and stuff, and it was just like just why wouldn't we do if we're doing anything for developers, like, why wouldn't you do it open source? It makes it makes so much more sense.

Matt:

I feel like honestly, I wouldn't I don't take a dev tools product seriously if it's not open source Really? In 2024. Yeah. Why? I mean, I will always look for an open source alternative if there is, like, a closed source product that we use.

Matt:

It does kinda depend on the product, though. So, like, if you're building, like, an observability product, like logs or something, then I don't think being open source is essential. But if you're something which is, like, part of our because for logs, you're kind of sending a log somewhere, and then you look at them in, like, a a third party product, whether I mean, Sentry is open source, but if you're looking them, you know, in some other products, it doesn't matter so much. But if that thing is part of your tech stack, then, like, I really want it to be open source.

Eric:

Well, also because we are open source. Wow.

Matt:

I kinda have to

Eric:

do it. Yeah. You you you can't, like, go and sign a commercial agreement and then put some, like, commercial license in your open source project. Yeah. It doesn't really it doesn't work.

Eric:

I mean, we can like, there is definitely the rise of costs that were, you know, say like a cal.com or or someone like that where they will use, like in their like to set up their like to self host it, you might have to sign up for some proprietary services

Jack:

or something.

Eric:

But we we try I don't think we have anything like that and then we've always like like for example, we could go and build a feature that like, oh, you have to go sign up for Cloudflare or, like, this feature doesn't work or something because we're using, you know, Cloudflare Workers. So we don't we try not to build anything like that in the open source repo. So it's like it's nothing nothing that is like some separate sort of feature thing that requires some proprietary license.

Matt:

Yeah. We're trying to stay as cloud agnostic as we possibly can. Mhmm. Which is mostly about self hosters, really, but also with an eye to enterprise. Because in our case, because we're, like, we're running user code, most enterprises are gonna want to deploy that in their own cloud.

Jack:

Mhmm.

Matt:

And if you suddenly have a dependency on, let's say, Cloudflare, then that enterprise has gotta be happy with using Cloudflare. So it's both better for self hosters, but it's also better for, like, thinking about enterprise and stuff like that. But we're very, very careful about what dependence we dependencies we use. Definitely, there are many features that would have been a lot easier to build if we had just used some, like, off the shelf proprietary software. And instead, like, we'll use something like Redis or, well, the the

Eric:

the the non

Speaker 4:

I mean, Redis is actually great. The actual open source.

Eric:

Yeah. The open source Redis.

Jack:

They changed it back though, didn't they?

Eric:

Or Did they no. No. They changed it back. There is like a, a a Valkey that's like an alternative to Redis. They're not that's like an open source fork from, you know, the previous version of Redis that was had the permissive license.

Eric:

But, but, yeah, I mean, a good example of this is, our like, we're building this feature right now we call, like, real time, and it basically allows you to get updates about what's happening in your background job, you know, on your server or live to your, like, front end. So you can sort of build experiences where, like, you know, you can do stuff in your background jobs and then show them to your users. And so we were, for a little bit, we were thinking of using Cloudflare Workers and Durable Objects just from, like, then we don't have to, like, you know, do a bunch of stuff. And maybe maybe we're like, oh, maybe that's, like, cloud only. You know, maybe we'll be able to build this like, if you're self hosting, you don't get real time, and maybe that's, like, a cloud only feature.

Eric:

But then, I don't know if you've seen this project, the Electric SQL.

Jack:

Yes. Yeah. Yeah. I think they're British. Some Yeah.

Jack:

Yeah. James is.

Eric:

Yeah. Half the team is, I think.

Jack:

Yeah. Yeah. From here.

Eric:

And, yeah, we saw that coming. We're like, oh, this is perfect. So we we actually built the future with electric. And so that's the permissive open source license. So there we can just ship it ourselves and then if you wanna self host that as well, then you can have the future for the self hosted version.

Eric:

So we always prefer like that going that route.

Matt:

Definitely.

Eric:

And it was good that we sort of, like it was we almost, like, delayed it, and then it was, like, perfect, like, timing because they came out with electric, and we're like, oh, this is Yeah.

Matt:

We got lucky with that. Yeah.

Eric:

Yeah. I didn't go down the route of building it, like, halfway with Cloudflare, but yeah. That's wicked. Yeah. That's wicked.

Speaker 5:

This episode is brought to you by Work OS. At some point, you're gonna land a big customer and they're gonna ask you for enterprise features. That's where Work OS comes in because they give you these features out the box. Features like skin provisioning, SAML authentication, and audit logs. They have an easy to use API and they're trusted by big dev tools like Vercel as well as smaller fast growing dev tools like Nock.

Speaker 5:

So if you're looking to cross the enterprise chasm and make yourself enterprise ready, check out Work OS. We've also done an episode with Michael, the founder of Work OS, where he shares a lot of tips around crossing the enterprise chasm, landing your first enterprise deals, and making sure that you're ready for them. Thanks, Workhorse, for sponsoring the podcast, and back to the show.

Jack:

Okay. And then so, like, there are challenges with open source as well, though. Right? And I I think so to bring it to an analogy, I know that, I was talking to you guys about, like, pricing, and it's like you have I think initially, your pricing was, like, extremely, extremely, like, one line or something. It's just like one thing.

Jack:

And then, like, every line of the pricing is because someone kind of started to, like, abuse, you know, like, doing things that were just, like, completely outrageous. And then you had to be like, okay. Like, you have this you know, you can't quite do this or something. Sending like a a trillion, you know, requests and, like, you know, whatever. And I feel like with open source as well, it's like a lot of the license considerations are like if, you know, AWS come along and build a competing profit for or or someone forks you and and just does like it, sells your product as their own and stuff like that.

Matt:

Yeah. I look we I guess we like to think, but there's so many ways of slicing this, and it's amazing how when you speak to other, like, commercial open source companies, everyone has quite a strong opinion, and also they disagree, like, a lot. So occasionally, we'll get people asking us for, like, advice on what license to choose, and and they'll ask other people, and everyone disagrees. But but the way the way that I like to think about it is there's kind of different things you can, like, protect against by choosing your license. Now if you're MIT or Apache 2, you're basically saying, like, everything is pretty much fair game.

Matt:

If you choose, like, a less permissive license than that, you're kind of either choosing it because you wanna protect against competitors. So I think the classic example of that are database companies. So if you're MongoDB, if you're Elastic, Redis, obviously, now, you know, AWS and Google and Azure are really, really, really good at, like, hosting and, like, delivering products, and enterprises already have agreements with them. Yeah. And so they'll just just take your your software and just, like, make it available to people and do it really well.

Matt:

So, like, if you're in that boat, then, like, you should think really hard about your license. I think we're a lot less worried about that personally for us. We're less worried about competitors. OpenCore is another one, which is where you have generally, the way you implement OpenCore is you have, like, a mixed license on your repo, and you have most of the repo is permissive, like MIT or Apache 2. And then some folders, usually they're called EE folders, are under a different license.

Matt:

But basically, like, you have to pay for, like, a commercial license for it.

Eric:

And that's protecting not against competitors necessarily, but more about our enterprises going to self host and run you, at like scale and never pay anything or give anything back. So that's sort of the protection that people with those type of licenses are looking for. And it's interesting how, you know, which types of projects choose that or not. I think for something like us where, you know, we're it's not a database. We're not a database, but we're kind of more on that side of things.

Eric:

Like more like if you were using us at scale, it'd be like quite a critical piece of infrastructure. It's basically like a compute layer. Right? So I think with with that, you sort of the protection against enterprise running you without, you know, paying you anything is a little bit less of a worry because we know that or we suspect that enterprises when they get to using us at scale will want, like, our, like, operational expertise in running it. And so they'll come to us for, like, some kind of agreement whether that's using our cloud or doing an on prem thing with them or and maybe they have like a bunch of different instances that are scattered around their org and they wanna like unify them and they wanna come to us for helping with that.

Eric:

So I think it depends on if if like is it possible or is it how mission critical is the thing they're using you for? And like can they kind of use you without ever, you know, in that middle area of like you're you're kind of mission critical, but not really. They might be able to just use it and and never do anything back if you don't have that protection.

Matt:

And and also you made the other point, which is how easy is it to, like, deploy and manage

Jack:

and run

Matt:

Mhmm. And scale. Yeah. Those are the 2, like, critical things, I think.

Eric:

Yeah. So for something like, you know, I keep bringing up cal.com, but they're, like, a huge sort of cost. Right? So they have the E license. Right?

Eric:

And you could definitely see like a pretty big enterprise just deploying cal.com across their entire org and using it with like 10,000 employees and not having that much trouble like operating it. Mhmm. So there it's more important for them to have that that license to make sure that they they don't get into a situation where someone's getting like a massive amount of value out of it and just never even Kevin giving you a phone call kind of thing. Mhmm. So that's, yeah, that's that that side of the perception.

Jack:

It's easier. It's more of an issue. If it's easier to deploy it, you might want

Matt:

And scale.

Jack:

And scale, then you but if it's just very difficult, then that kind of is your that's enough anyway.

Eric:

Yeah. It's not even difficult. It's difficulty crossed with, like, how mission critical it is. Mhmm. I think.

Matt:

Yeah. If something goes wrong Yep. Then they they wanna They've gotta they've gotta handle it.

Eric:

They also want, like yeah. They wanna have someone to go to and be like, fix it. Yeah. You know? Yeah.

Eric:

Because we need this fixed now. And, like, also, our customers now are gonna sue us, and we wanna be able to sue you if they sue us. Oops, I hit the microphone. Yeah. I was making a really good point.

Eric:

Yeah. So they might have customers who are gonna sue them, and then they wanna turn around and sue somebody else for causing the outage or something. So there's, like, when when you get to that game of, like, big orgs and big enterprise and stuff, it's there's a lot lot of reasons they might if you're mission critical, they might want to, you know, have some kind of enterprise contract. Not, like, the license has nothing to do with that, obviously.

Matt:

And there is, like, a different so open when people say OpenCore, they mean, like, one I think pretty much they mean 1 repo, and it has, like, a mixed license like we just talked about. But there's kind of another version of OpenCore, which is what we're doing, which is our repo is Apache 2. Mhmm. And self hosters to, like, medium scale can just use us self hosters. Yeah.

Matt:

But, like, there's a lot of code that we have for the cloud product with some auto scaling and, like, other features, things like billing and stuff, which are in a private repo. And so you can kind of you kinda need to think about, like, what code is where? Is that code public or private? Mhmm. And under what license is it?

Matt:

Mhmm. And, like, what does that license or closeness, like, do for me? Yeah. Because there are a lot of advantages to being more open, which we see. Like, Apache 2 like, developers absolutely love Apache 2, and they're our audience.

Matt:

And so you get self hosters who basically become advocates for you. You know, they talk about it on Twitter. We get most of our inbound is just organic, and it's because we're open source. And people choose us over our competitors because we're open source, like, largely. I mean, our model, like, the the kind of product is quite is a lot more different now than our competitors than it was, like, a year ago.

Matt:

But open source is, like, a massive, massive reason that people choose us. So, like, when you're choosing a license, I think you need to also think everyone focuses on the negatives of the license, like, as in, like, the things protecting against. Yeah. Like But you also should think about the positives. Yeah.

Matt:

You should think about, like, well, what if we had a more permissive license, would that actually allow us to, like, grow quicker?

Jack:

Mhmm.

Matt:

And it depends on your audience, I think.

Eric:

It's also like, oh, what if Amazon comes and makes it different? I'm like, yeah. You'd be doing pretty well, I think, if that happened. Like, you would already you would already be at, like, a massive scale.

Matt:

I mean, it has happened. Right? And people do change their licenses. Right.

Eric:

Right. But,

Matt:

yeah. Obviously, it's not ideal.

Eric:

Yeah. It's exactly. But I think it's like a little bit it's a little bit like, premature optimization but for the license side of things. It's like, yeah, if you ever, like, get to that point, then that's a different question. And maybe, you know, it'll become a problem then.

Eric:

But, like, the chances of you ever getting there are so slim.

Speaker 4:

Yeah. You've won. At that point, you have won.

Eric:

Yeah. Things are going well. Maybe that's not the the biggest problem. Like, bigger problems for us that we think about like, we never think about this stuff. Like, we we think about, you know, lots of other things.

Eric:

Like, how are we gonna keep the service running well and available? How do we keep delivering features that our users want? How do we, you know, think about, like scaling the team or not and things like that or positioning. It's like, I think at this point, especially when you're just starting out, like, I think just pick a license that you can be happy with and that is generally quite permissive and just go with it. And if you are worried or if anything starts changing, you can change.

Eric:

I know that's sort of a controversial thing. It's not like when you choose a license, you have to keep that license for the rest of your life. So if you are one of those people who, like, all of a sudden now you need to do, like, the EE thing, you could you could do that. Obviously, then you'll have to suffer the consequences

Jack:

possibly. Yeah.

Eric:

So but, but, yeah, that's another conversation.

Matt:

Yeah. I mean, we were talking about this, like, 2 weeks ago. Yeah. We were at the YC, like, reunion, and, we were talking about to people about licenses. And we basically decided that we're gonna keep our Apache 2 repo and put enterprise features in there.

Matt:

And we're just gonna focus on having the the separate, like, scalable private cloud, like, version, repo, which is, like, kind of how we're we we think about it. Because we're just very attached to the idea of the Apache 2 license.

Jack:

Mhmm.

Eric:

And I mean, it's like it's working pretty well for, like, super base, for example. Yeah. They're they're Apache 2 and it doesn't seem to be, like, slowing them down. So I don't think, like, that the license I think the license isn't gonna change anything. But you could choose, like, a a license that could actually, like, if you choose something that's, like, not open source enough, if you're a dev tool, it could harm you.

Eric:

Yeah. But I think, yeah, I think the other way around, it's just more benefits than anything.

Matt:

Well, just weird licenses. Like, people just choose, like, the weirdest stuff. You see, like, something with a license you don't really you don't you haven't seen before. Like, obviously, that's gonna be that's I think that's sort of like a really that's probably the worst decision you could make, is choose, like, a weird license, because if people don't understand it, they're probably not gonna use you. And especially as you start to think about, like, bigger companies, they have legal departments, and those legal departments have now got to work really hard to figure out what this license means.

Matt:

And if there's any chance that they are worried about it, they're just not gonna use you.

Eric:

Yeah. Well, they probably most likely just have a certain set of

Jack:

Beverage.

Eric:

And just if it's outside of that, then it's probably not gonna happen. Yeah. Unless you're, like, really, really important for some reason. Then they might have to then do another due diligence thing. Yeah.

Eric:

But yeah, I mean, our goal is to like spread throughout organizations in like a self hosting. Like we would love if people self hosted us.

Jack:

Even if you weren't getting paid for that. Yeah. Okay.

Eric:

Yeah. Yeah. Because we think if if we what we've made is good enough, that it then gets into an organization and, like, a bunch of different teams are using us, even just separately. Imagine, you know, like Apple, like, there's how many teams do they have, and they deploy all sorts of stuff. Right?

Eric:

So teams will we hope they'll adopt us and run the self hosted version and, like, get a lot of value out of it, like, increasingly amount of value. And then at a certain point, they'll be like, well, we have all these, like, trigger. Dev installations everywhere. And, like, we're actually, our developers love it. Like, they love trigger.

Eric:

Dev, and they wouldn't, like, work if on something that wasn't trigger dot dev, for example. That's where we wanna get. Because then the org is gonna come to us and be like, can we please sign an enterprise contract? And then we we don't have to do anything.

Jack:

And their motivation for that would be what you mentioned previously, which is that they want someone to ring up at 3 AM and say, fix this.

Matt:

Yeah. Like support contracts, but also, like, kind of scaling, like we talked about.

Eric:

Yeah. Yeah. Unification, I think. Like, how you take take a bunch of different instances and you sort of put them all together in 1, and then there's, like, efficiencies and all sorts of stuff.

Matt:

Versioning is another big thing. Like, especially at the moment, like, the the product moves very fast. Like, we release major new versions, like, the bug fixes. And if you're self hosting, obviously, you have to upgrade. And usually, that's, like, very seamless, and, like, we put a lot of effort into making it seamless.

Matt:

But, you know, you whoever is, like, managing that instance still has to, like, actually do the upgrade and

Eric:

Yeah. I mean, there's a reason. Like, I've heard stories of ClickHouse Cloud or sorry. ClickHouse is, like, quite well, some people say it's easy to run self hosted. Right?

Jack:

Really?

Speaker 4:

Well, people yeah. Like DevOps geniuses. Yeah. Okay.

Eric:

Yeah. Cough baseline. But, like, for like, they're still killing it on their cloud offering. Yeah. You know?

Eric:

Because people want, like, they they think, well, ClickHouse will be able to run it much better than we will. Yeah. You know? And at a certain point, you're just like, let's just use the people who know best about how to run it to run it for

Jack:

us. Yeah.

Matt:

Yeah. Self hosting, for us at least, self hosting is definitely correlated with cloud growth as well. Mhmm. Like, we they they just track, like, exactly. So, like, as the, revenue for the cloud product goes up, like, the number of self hosters go up.

Eric:

And you can see

Matt:

it, like, very clearly in our Discord.

Jack:

And do you think it's, like, the the self hosters are driving the cloud adoption, or is it?

Matt:

I think oh, it's a complicated question.

Eric:

Not yet. I don't think.

Matt:

No. But some people self host for a bit, and then they go, do you know what? I'm just gonna use the cloud product.

Eric:

Yeah. Although some people use the cloud product just to get an idea and try it out. Yeah. And they like it, and then they surface. Yeah.

Jack:

So it works in both directions. Yeah. Yeah. That makes sense. Yeah.

Jack:

And one of the other things that, kind of when I was thinking about, like, the licenses, I realized there's a part that I didn't really understand very well, which was the, copy left, concepts.

Eric:

Yeah. It's very complicated.

Matt:

Eric can definitely take this one. Okay.

Eric:

Well, what do you wanna know specifically? Well,

Jack:

I guess, like, the first thing is, like, what is copy left? What does it what does it mean in general terms?

Eric:

Yeah. So copyleft, I guess, is the sort of, collection of licenses like GPL. So GPL was like the first sort of copyleft, license. And basically the gist of it is that if you use GPL code in a way where your code falls under like a derivative work of the GPL code, then if you wanna continue to use the GPL code without consequences, then you have to release your source code under the same license. So that's why it's called copy left.

Eric:

And, there's sort of the conception that it's like a viral license, right, because like if I'm using like GPL code in my code base, then it's like forcing me to become GPL as well. And so the idea was the FSF who created the license basically wanted to, like, try to force, companies who were using their open source code to also be open source or contribute their modification. So a lot of people were taking some code and modifying it

Jack:

and then trying to put it into their proprietary

Eric:

product and then shipping it. Trying to put it into their proprietary product and then shipping it and making money. So they want to encourage like more contributions, you know, to their back to the community, and this is like their way of trying to do it. There's sort of a misconception where people think if you use g say you're building something that's proprietary, like proprietary software, and you use some code that is GPL, some people think that that means your code is like now GPL. Like it's almost like by law it's like been infected with GPL.

Jack:

I have to admit that is kind of what I was understanding when I was

Matt:

Pretty much everyone thinks.

Eric:

Yeah. So that that's a misconception. What it mean what the only thing it means is that you're if you're not following the conditions of the GPL license, then you don't have the copyright to the GPL code. And then the GPL code authors can bring a copyright infringement like suit against you, and they can sue for damages or an injunction to get you to stop either pay or to stop using your code. There's no way in the law or anything to actually force code to become open source.

Eric:

Oh. So you the only forcing function is like you don't want to have this suit against you. Yeah. And you and so you might, like, settle and part of the settlement is, like, okay. We'll we'll, like, open source this part of the code.

Eric:

Or you could just stop using the code. But it's like there's no way that there's no, like, nothing in the law that says, like, oh, now my code is open source and I have like, I'm forced by the court to, like, distribute it other than the fact that you might not wanna have to pay the damages and stuff. But, yeah, sort of a misconception that, like, you might accidentally, like, have to like, have to go and release your source code on GitHub. That's, like, not the case.

Jack:

Okay. So, like, if the so let's say I made this, like, incredibly popular social network app, and I'm using, like, an LGPL. A GPL. GPL. GPL.

Jack:

GPL. Yeah. Library or something.

Matt:

Mhmm.

Jack:

And then my biggest competitor can't just come and say, like, hey. You're using this GPL. It would firstly, it would have to be the Mhmm. Creators that would Yeah.

Eric:

Because it's it's it's the whole licensing regime is sort of under the copyright sort of law of whatever jurisdiction. Right? So the copyright isn't like some other person who had nothing to do with the copyrightable work can come and, like, say anything to you. Yeah. You know, it's like the copyright owner can can go and and actually say it's funny.

Eric:

There's also, like, precedence where if the copyright owner says something publicly, like, actually, I I know this is GPL, but I'm not gonna actually enforce enforce it, then they don't have any way of enforcing it. Like, the court would see that as, like, them giving up the right to enforce it. Yeah.

Jack:

So, like, even if they just said, like, that's we're not gonna enforce, like, you're kind of you're good to go at that point.

Eric:

Yeah. You basically said that it's not GPL.

Matt:

And there is, like, a lot of case law, isn't there, involved in this stuff? Where stuff like Yeah. Especially if you choose, like, a weirder license. Obviously, stuff does go to court at some point, and then those verdicts can impact, like, what their license means in the future.

Eric:

But there's also, like, there's a question of what falls under like, how do you use the GPL code? And is that is is your code then, like, using in a way that the copyright holders could, like, take a case against you, like sue you. Right? And that's very, very, very complicated. There's like so GPL mostly, is like if your derivative work, if you use it and distribute it, and the way you distribute it is like through software that's running on your computer.

Eric:

So there's like the quote unquote, like, SaaS loophole. So if you're like a SaaS and you use GPL code in your SaaS and then people use your SaaS over the network, right, you're using your browser to access, like Zapier for example. So they could have something deep in their infrastructure or whatever that uses GPL, or maybe they take some GPL code, they modify it, and they put it in their code base. Right? Yeah.

Eric:

Because they're a SaaS, it doesn't matter.

Jack:

Okay.

Eric:

So it's not distributed. So like in GPL's case, like distribution is like actually running a process on your computer. And then, so when GPL3 came out, this is basically known for like a while that this loophole existed. And then GPL 3

Matt:

came out. Before any, like, online software existed, right?

Eric:

Well, GPL 3 was 2007. And they were basically like, they wanted to close the the SaaS loophole, but they didn't do it in GPL 3. They didn't AGPL. And so they released AGPL is basically GPL 3 with the SAS loophole closed. So if you want to write some code that then like people can't run a SAS and use you, then that's the license that you'd wanna pick.

Matt:

Mhmm.

Eric:

And so that's another way of, like, kind of protecting against that's how MongoDB, for example, was licensed for a long time. Because they were they were licensed under AGPL, and they basically as like try to fight, you know, Amazon and stuff.

Jack:

Oh, so they use that's what they used

Eric:

to And and people it's very confusing. Like, what it like, so it's people are very very confused. So, basically, the confusion led to MongoDB. And actually, this is like a feature of the license is the confusion. It's led them to have like their dual licensing model.

Eric:

So you could use, the AGPL MongoDB, But a lot of people were like, well, we don't know if, like, what we're doing is is, like will mean that we're you know, they can have a copyright case against us. So we'll sign a commercial agreement with MongoDB. And then we know we're safe. We're covered. Yeah.

Eric:

So it's sort of a way of, like, forcing someone to come to the table and, like, sign a commercial agreement and pay you money. That's interesting. Yeah.

Jack:

But does it have because I think we spoke about this. Is it like some come if you're working with a big enterprise and you have GPL license, they would be I guess that is the case that they're, like, they're not necessarily comfortable with that.

Eric:

Yeah. Yeah. Definitely. A lot of people will shy away from using anything GPL unless they like know, okay, we're using it's a GPL 3. Like Linux is GPL 2, for example, and you know Amazon hosts Linux like servers and stuff and that's not a problem.

Eric:

But I think there's a lot of different questions around it. Like, what is like if it's you might be only have to do it if you make, like, a modification, or, like, what is using it is, like, is just calling, like, an API. Like literally the question sometimes boils down to like are you shelling out to call the code? Are you like calling code from a statically linked library? Are you calling it from a dynamically linked library?

Eric:

Like it's very, very confusing. And the questions are not settled. Right? Yeah. And so it's like do you just it's it's it leads to this, like, fear fear based kind of regime where you're just like, I'm afraid of that, like, so I'm not gonna touch it.

Eric:

Yeah. And that that so when you think about, like, like, if we were to use some some AGPL thing in our code base, it could not like kind of on the merits and on the like legal analysis of the situation. It might not it shouldn't be a problem maybe for us to then like sell to some enterprise or something or even for the enterprise itself hostess. But based on, like, the risk analysis, blah blah blah stuff, like business case, in the real world, they might just be like, no. We're not even gonna consider that.

Eric:

So I think a lot of why we did Apache was like there is no fear. Like, we don't just why are we why would we put that, like, boundary up? Because I think we like, at this point, any boundaries, like, why would you impose that on yourself? Yeah. Unless you for a very specific reason.

Eric:

So I think if you don't know what that very specific reason is, it's probably just safer to choose a permissive license.

Matt:

Mhmm. Yeah. Totally agree.

Jack:

Yeah. That's that's awesome. It was so good. That was, like, really, like that was amazing.

Matt:

That was,

Jack:

what what is the book you you

Eric:

I have it.

Jack:

You got it with you? Oh, well. Let's do a shout out to the, Well,

Eric:

you should I mean, actually I

Jack:

should read it. Yeah.

Eric:

You should get Heather Maker on that.

Jack:

Oh, yeah. That would be great. Yeah.

Eric:

She's in that. She's in the costume. I mean, she's

Jack:

Oh, yeah.

Eric:

Yeah. Wow. So that's the book there. It's pretty thick. Let's show

Jack:

it sideways to see how thick it is.

Eric:

And that's where I'm at. So I made pretty good work.

Jack:

That's that's impressive.

Eric:

It's a practical guide to open source software licensing. And practical, I think, is probably a good, good way to say it because I when I first got the book, I was thinking it was like the layman's, you know, understanding of it. It's like, no. No. It's definitely like you probably need to know some amount of law to, like, really understand this stuff even in the book.

Eric:

Yeah. It's quite complicated. I mean, she she does a really good job of, like, trying to make it understandable, but, man, yeah. And and a lot of things will kind of, like, circle back on on each other and, like, wait a minute. I thought that was, like, that was fine or that wasn't fine.

Eric:

And it yeah. To parse all this stuff out, is very complicated. So that's part of the reason why I think it's just, like no one's gonna, especially users of an open source project, they're not gonna read this book, right, to understand that they should use it. And so I think it's safer just to choose something that people know and then they don't have to think about like reading your book to figure it out. But Heather is literally the person who wrote like a bunch of the source available so the things we haven't sort of talked about is like the source available licenses and she's written a bunch them.

Eric:

She's a lawyer in Silicon Valley and she's like she goes way back in the whole like open source licensing movement. And so these she's written these source available licenses like the one Mongo uses now and, you know, the new one that Century came out with.

Matt:

FSL. Yeah. That's interesting. Yeah.

Eric:

She was involved in that, I think.

Jack:

First source license.

Matt:

Yeah. The idea behind that is basically, it's to protect against competitors, very, like, explicitly. For 2 years, when a piece of code is released, it's basically no competitor can use it. And then at the that 2 year mark, it turns into Apache 2. So you can imagine it as like a rolling 2 year window that moves with the code.

Matt:

So, like, if I do a commit today, 2 years in the future, that that commit will be available as Apache 2. But stuff that's in that, like, 2 year window is, yeah, Not.

Eric:

And a lot of the, yeah, source available licenses sort of they're trying, like, the Elastic v two one and stuff. They basically they're like, we don't wanna limit self hosters from using us.

Matt:

Like, we

Eric:

don't that is fine. Like, we we're really, really, really, that's fine. But what we're trying to do is like not have Amazon come in and or any of the cloud providers come in and just like, here's an Elasticsearch service and we're gonna make a $1,000,000,000 a year and then Elastic gets nothing. Right? So those source available licenses are very specifically trying to get that to not happen.

Eric:

But they're not technically like open source licenses. So they're like people, if you're like, oh, we're open, like if Elasticsearch was like, oh, we're open source, people would be like, no, you're not. Because open source has a very specific meaning to some people. Yeah. It means like you have an open source approved license, which there is not They're

Matt:

not very manual.

Eric:

Yeah. It's like the GPLs and AGPLs and Apache and MIT and BSD. Like, there's a bunch more, you know, LGPL and stuff. But, yeah, there's like a 100 that are actually open source. And then the source available, like and there's sort of this newer movement that's sort of like, I guess, done or like they're not really as concerned with like the whole because a lot of this originated in nineties.

Eric:

You know, some of the people who are writing code now weren't alive in the nineties. So they're, you know, a lot of it's like post it's almost like post open source. So people would be a lot of newer developers probably be like, there's sources available. Why why can't you say open source? And it's on GitHub and I can do pull requests and I can you know what I mean?

Eric:

It's like I can do every single thing I usually do with open source projects. So why aren't we allowed to call that open source? So there is this sort of like, I think it's called like FairSource or something like that. Yeah. It's like, sort of people trying to rebrand some of that stuff to kind of cover it.

Eric:

Because it is, like a lot of it is just marketing. Or it's like that's what a lot of the concern comes down to, you know? And you're trying to, you know, it's the whole Hacker News crowd thing. Like, oh, well, now you've relicensed to something else and now the Hacker News crowd is gonna get you kind of thing. Yeah.

Eric:

But, yeah, so I think that's like sort of an interesting new area where I think the whole arguments about like GPL versus Apache and all that stuff is sort of a little like older school a little bit. It's starting to become a little bit like And then there are some people who because you can run afoul of open source ethos so poorly that you are in trouble. Like the recent YC company who unfortunately did some very bad things with an open source project. I won't say their name because I am terrible at pronouncing that word, but I think everyone ends up talking about it. But, yeah, so I think it is still important to like it's important even though, there's sort of these newer license out there to sort of know, you know, what you're getting from like a marketing perspective, I guess, when you go with certain licenses.

Jack:

Yeah. And I guess, like, I you've pretty much already answered it, but I wanna ask again is, like, why did you not look at, like, the FAIR this, like, FAIR source license? FSL. FSL.

Matt:

It didn't exist.

Jack:

Didn't exist. Okay.

Matt:

I mean, it's it's, like, 6 months old or 9 months old or something?

Eric:

Yeah. Left. Left. Yeah. Maybe.

Eric:

Some money.

Matt:

I think it's really interesting as a license. But but it protects against competitors. And I don't it like I said earlier, it really depends on, like, what you're trying to protect against and what your product is, but that's not, like, a major concern for us. Yep. Like, we're not really worried about AWS offering, like, trigger dot dev as, like, a managed solution.

Matt:

And, I mean, if it happens, then we're probably in quite a good place anyway. But but FSL didn't exist.

Eric:

I mean, there are no even be able to like, Coolify, I don't think, could deploy us Yeah. With that license.

Matt:

Right? So, like, some deployment platforms which make it easy to deploy self hosted, like, products, like Coolify, probably couldn't even use it. Yeah. Or it'd be, like,

Eric:

a confusion about whether they could use it. Yeah. And we don't why why would we do that?

Matt:

And some and some, like, commercial open source companies would be would see that as a feature Yeah. Of it. But for us, like, we like self hosters, and we see that as, like, good for them, obviously, but also good for, like, our growth

Jack:

Yeah.

Matt:

And for, like, the health of the project as well.

Eric:

Yeah. Yeah. Develop I mean, what we're what we're in the business of doing, is like making developers happy and giving developers tools that they want to use. So anything that gets in the way of that is a problem, I think. Yeah.

Eric:

And, yeah, we want to have the most amount of developers using us as possible. It doesn't matter if they're using the cloud or the self hosted version. The idea is that, I mean, like, oh my gosh, this is such a problem that we've spread so far and we have millions of developers using a self hosted, like, that would be an insanely good outcome. Yeah. Because if you can't get to that outcome and not, like, benefit off of it.

Eric:

Yeah.

Jack:

You know

Eric:

what I mean? Like, if you get to the outcome where you have, you know, imagine every TypeScript developer use us like that. Yeah. And it would be, you know, nothing bad would come from that. Even if they're a bunch of people were using a self hosted.

Eric:

Yeah.

Jack:

Yeah. I think DHH had like a really cool quote. I think, there was this, you know, in the the Wordfresh drama, I think, like, Matt said, you know, you're not make like, I'm making half a 1000000000 a year. You're making, like, barely anything even though in well, he's not, you know, he's making loads, but, like, you got Ruby on Rails and then Shopify. Shopify is $1,000,000,000.

Eric:

All this stuff. And you didn't capture it.

Jack:

Yeah. And he was like, well, I don't care. I'm I'm happy that that all this value was built on top of what I built. Even if I didn't get all the value.

Eric:

That's a whole different yeah.

Jack:

Maybe that's another

Eric:

So yeah. That was that was just it was good. Like, DHS was basically like, yeah. This just makes me sad. This is just so weird.

Eric:

It's like such a weird thing to attack someone for. It's like you've made an insanely popular, like, open source framework. And because because huge companies were built on it, that's, like, an issue. That doesn't make

Jack:

any sense.

Matt:

And also, DHS is is really rich. Yeah.

Jack:

I mean,

Eric:

like, he's insanely wealthy.

Matt:

Like, so it's not like he lost

Jack:

in this situation. Like, it's such a weird argument. I mean,

Eric:

he races, like, 1,000,000 dollar, like, race cars for fun. Yeah.

Jack:

Like, I

Matt:

don't think And presumably crashes sometimes. So, like I think he was doing that right.

Jack:

Maybe he never crashes.

Eric:

I mean, that was I didn't think that came from Rubin Rells, but yeah. Like, yes.

Speaker 4:

Yeah. Sure. But, like.

Eric:

But it did in a way.

Matt:

Yeah. It did in a way because 37 signals Yeah. Reputation, face camp, or whatever they're called now is, like, from that.

Jack:

Yeah. I somehow found that, like, I don't know. It feels like sad. It was like because you got I'm I personally really like DHH. Like, I enjoy reading his stuff, and I just found it, like, quite sad to see someone, like, you know, completely dunking on all of his achievements even.

Jack:

And it just, like, just felt like It

Eric:

was actually it was a great, advertisement. Yeah.

Matt:

It was an advert

Eric:

for him.

Jack:

You mean?

Eric:

Yeah. It made him look amazing.

Matt:

I think it made him look really really

Eric:

good. Yeah.

Matt:

Yeah. Like, developers look at that and go, like, you are, like, DHL is amazing. Yeah. And I mean, let's be honest. He says he says a lot of other controversial stuff.

Matt:

Yeah.

Eric:

Yeah. But it was it was like, oh, compared to Matt, DHH is like Yeah. Is is like a a really nice Yeah. You know, polite individual.

Matt:

Also, like, WordPress really dropped the ball. Like, first of all, like, if you don't if you're not happy with open source, then don't make WordPress. Yeah. Like, it's very obviously, like, very open source, like the original thing. It's been used by, like, everyone or, like, what

Jack:

is this? Like, 60% of the Internet

Matt:

or something crazy? I don't know how reliable those numbers are. But, like, they could if they could have built a good hosted version Yeah. Of WordPress, like, a really good hosted version, and they didn't. And so they could of have made way, way more money by just building, like, a really good Mhmm.

Matt:

Cloud product. And WP Engine is obviously I mean, I haven't used used it, but it's obviously better, I guess. So I think the story here is that, like, they dropped the ball and didn't build a good cloud product and other people did.

Jack:

Kind of win by being I guess it's like you're saying just, like, win by being really good. And then if you build the best thing and you're known as being the best thing, people are gonna the the the dollars are gonna come your way, and everyone's gonna be happy about that because, like, you deserve it and you're doing it right and you're winning by, like, just being superior rather than, like, some kind of snakiness or something.

Matt:

You have an enormous advantage of building the best cloud product Yeah. If it's your product. Yeah. Like, I do it's kind of baffling that you don't win in that situation. I mean, like, you hear you

Eric:

This is from, like, reputation.

Matt:

Well, reputation alone. Win.

Eric:

Yeah. But I think WordPress is interesting because it's sort of, like, very established and probably, like, almost like a commodity. You know? So maybe that it's like done the innovation phase maybe. I don't know.

Eric:

I don't know. I'm not that much into that, the WordPress scene. But it does seem like a lot of the concern about, like, WordPress stuff is, like, security related. Like, they need security updates, like, every day. And if they, like, go 24 hours without needing a new like, getting a security update, it's like a massive problem.

Eric:

Like, that was the whole reasoning behind taking over, like, the that what was that? Secure fields?

Jack:

Maccles. Maccles.

Eric:

Because they couldn't tick the box. Remember that? The the sign in box where you would say, I'm not affiliated with the you couldn't log in if you if you, you know, were affiliated with WP Engine, like, financially or something. So the reason why I was taking over is because they couldn't log in to update their plug in. And because there were security updates, like, that was the reasoning.

Eric:

Like, well, they can't log in and they can't apply these security updates, so we have to take it over. And so these security updates could be applied. And it was like 24 hours after they released the box. I'm like, how many security updates were there like, in the last 24 hours? But anyways, yeah, that's just a whole messy situation.

Eric:

I don't even know what's the WordPress license.

Matt:

It must be really permissive. Yeah.

Eric:

It must be, like, MIT or something.

Matt:

Yeah. But it's not good for open source when stuff like this happens. No. Like, it does it does I mean, we obviously haven't felt any pain from this, but I think it does spread, like, mistrust in open source. And obviously there are other things like, you know, Redis relicensing last year or or whenever it was.

Matt:

Like, it does make people a little bit more people scrutinize open source more, which is maybe not a bad thing. But also, like,

Eric:

it's not like the license is retroactive.

Jack:

Yeah.

Eric:

So the version that was released prior to the yeah, that is still open source. Yeah. And can be forked and has been forked into Valky.

Matt:

Yeah. And

Eric:

the so like, so worst case scenario, you you like, if something you're using is very popular, then you'll be able to use a fork. Yeah. And so that's, like, pretty good outcome. It's not like it's not like, oh my god. Now the only way to use this is to pay.

Eric:

Yeah. Or you just keep using the version that had the license. Yeah. Like, well, we were happy with that. We don't need any of the new features.

Eric:

We'll just continue using the one that had the open source license.

Jack:

Yeah. That's such a really good point. And I feel like there's a lot of, I feel like in particular right now, there's a lot of, like, backlash against, like, VC funded startups that are in open source and stuff. And I think, like, you know, that's a good argument that, like, well, worst case, like, a lot of VC dollars went to, like, fund this thing that's still completely open source. At some point, maybe they changed the license, but, like, it got really, really far and people could build on top of it and, like, I guess with, like, Terraform, stuff and

Matt:

Yeah. VCs are basically funding, like, a massive amount of, like, value given to the world. Yeah. Yeah. Obviously, depends on the open source license, but, like, I don't see that as a bad thing.

Matt:

Yeah. I think the only it's only a good outcome there.

Eric:

Obviously, it's not stopping other non VC projects

Jack:

from here.

Matt:

Yeah. And there's plenty of those. And those probably the people who, like us, who wanna create a startup, it's not like we would have been able to build trigger.dev without some kind of Yeah. Financing.

Jack:

Yeah. You need money to pay to live.

Matt:

Yeah. It costs money to like, the development, and so the alternative is not the alternative universe is not trigger.dev exists, but it's, like, I mean, it is attached to anyway, but it's not VC funded. Yeah. The alternative is that it doesn't exist. Yeah.

Matt:

And, like, obviously, like, will we say anything this person's telling?

Jack:

Yeah. And I and I and I think, like, you know, start like like, I know you guys well. Like, you guys are amazing guys. Like, you would always try and do, like, the best thing possible. And you know, you you have a business, but like, that's not the only thing you care about.

Jack:

And I think that, hopefully this conversation is get shed a bit of light in that like, you know, people are really trying, like open source startups are really trying to, like, do really cool stuff, make technology bet you know, improve the technology in the world and also do believe in open source. And that's why you're doing it. It's not just like, you know, like, I think people say it's just marketing. It's not. Like, you guys care about it way more than that, and you believe in it.

Jack:

And it's like, I think a lot of open source startups are that way. So it's really cool to hear, like, how much you believe in it, what you're trying to do. I think we're actually out of time, but,

Matt:

yeah,

Jack:

I don't know if there was anything else you wanted to talk about, but

Eric:

Well, let me refer. Yeah.

View episode details


Creators and Guests

Elliott Roche
Producer
Elliott Roche
Freelance Podcast Editor
Eric Allam — ☀️/trigger.dev
Guest
Eric Allam — ☀️/trigger.dev
Founder at @triggerdotdev, the OSS serverless platform with no-timeouts. Member of the YC W23 batch. Also building https://t.co/FPMDqZC9Nn. #bitcoin
Matt – Trigger.dev
Guest
Matt – Trigger.dev
Founder @triggerdotdev (YC W23), co-creator of https://t.co/JuvHAucFQf. Programmer and winner of 2 Apple App of the Years

Subscribe

Listen to Scaling DevTools using one of many popular podcasting apps or directories.

Apple Podcasts Spotify Overcast Pocket Casts Amazon Music YouTube
← Previous · All Episodes