Regarding this blog post, I don't understand how AGPL is a good fit for the first stated use case.

>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.

And later in the quoted explanation of AGPL:

> "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."

If you fork the project, your company's customers are communicating with your forked code. So are you required to publish your forked changes? Only required to share the fork with paying customers? Or as your desired case states, not required?

(In any case, Lago looks very cool. Thanks for pushing forward the conversation on open licensing!)

I think the difference in cases is that in case 1 above, I read it as your company's employees [or technical systems] are using the software for some internal billing purpose and no outsiders are using the system, but are rather merely receiving a bill which was calculated using that system.

Yes. AGPL is a great choice and counters SaaS companies that are trying to grift and abuse open-source with a modified competing product without contributing back.

I always get confused with AGPL and seems to have differing opinions online, so wanted to ask here. If I use Lago in my app, and don't change it all, do I need to opensource my entire application?

The short answer is "no". The high-level concept of AGPLv3 is to prevent someone who'd like to re-sell the OSS company's features (billing in our case). For instance, let's say you're a vertical SaaS like Mindbody, selling software to yoga studio owners so that they manage their business: scheduling, payment, and billing. If you use Lago to build your own billing feature (and sell it as part of your product), you'd need to either buy a commercial license (we call it "Lago Embedded") from us OR open source your code. Let me know if you need more clarifications!

> OR open source your code

That is - offer your code to your customers under the agpl, not necessarily back to Lago or the community. But, since your customers get the code under AGPL, they in turn are free to distribute it. So, in practice, going that way - it generally makes sense to just open it up, and contribute back directly.

(imagine your only customer is IBM, or some other big company - they might not care/have an interest in re-distribution of the AGPL code - so you could be compliant (offer source to IBM) - but effectively closed off from the community).

As far as I understand it there's no legal precedent, so we're not completely sure. Some say calling an api means it's part of your application, meaning you need to open source your app. Some say that that's not the case. I think this unknown is why the license is banned in some companies.

I think what matters more is how the creators of the software intend the license. In case of Lago it's clear they want you to use it this way, and AGPL is only really meant to restrict businesses that want to fork it and start a proprietary billing service.

That's on point. A "proprietary billing service", or a service that includes billing in the value proposition in general: whether you're a vertical SaaS, an accountingtech, or a payment processor.

If you don't change the source code of Lago, then you don't. Having your app call it via REST, for example, is fine.

Thanks! We're big fans of Plausible and appreciate you mentioning them in your comment. We wanted to be transparent about why we chose this license. Our goal is to create a sustainable open source product, both in terms of quality and vision.

Exactly. We’ve seen people go from “I don’t want to do this because I don’t want to force my users” to “Guys let’s do it AGPL it’s the way to go”.

Restricting your usage tracking to your users is fine until you start shouting to them directly on their phones.