listmonk author here. Interesting to see it on the frontpage again. Some updates to the linked comment (which is from 2019):
- Tons of active development has happened and listmonk crossed 1.0 this year. 2.0 is on the horizon and there are quite a few listmonk instances in production.
- Our production setup at work now has ~7mn subscribers and listmonk works quite well. No issues with deliverability or IP reputation with our self-hosted EC2/Postal SMTP setup.
- listmonk now supports generic "Messenger" HTTP webhooks to which any message provider can be connected, allowing it to send arbitrary message campaigns like WhatsApp and SMS, not just e-mails.
Anyways, I wanted to ask a few questions, if I may:
1. Why is listmonk AGPLd? It doesn't look like listmonk is core to Zerodha (even if it is released on your personal GitHub) and so curious about the licensing, because MIT/Apache could have done just as nicely, especially since xGPLv3 software is pretty much a no at most tech firms.
2. How do you decide if a repo is going to land on knadh vs zerodha GitHub?
3. Any plans to take it fully serverless with Aurora Serverless + Fargate or fly.io, for examples.
1. I think AGPL is a good license for web apps that can also dissuade Elastic/Mongo-like fiascos. Mastodon, Metabase, Grafana, Minio etc. are AGPL and are widely used.
2. We see ourselves as a group of hackers and not really as a corporate entity. Many projects that come out of our team are largely individual efforts. For instance, I have spend considerable personal time working on listmonk over the last couple of years just because I like it. There is no Zerodha mandate involved. Only projects that have to be branded as Zerodha or involve a lot of multi-dev effort go under the official handle (ref: https://zerodha.tech/projects)
3. listmonk offers a one-click Heroku button (a bunch of simple scripts really), so it should just be a matter of creating deployment scripts for other platforms as well. I have not looked into it personally.
Nothing against the xGPLs, because they protect a user's freedom better than MPLs / EPLs / APLs, even if the license's nuances are not well-understood (which is why they're restricted for use by some tech firms).
What would their benefits for releasing it under a permissive license be?
AGPLv3 is a good trade, you get to use it for free but if you make improvements they need to be released, which often means that they are directly unstreamed as that is easier in the long in regard to code maintenance and tarball/source-control hosting for the modified sources.
So win-win for all users and the devs.
> even if the license's nuances are not well-understood
Which nuances are not understood?
> which is why they're restricted for use by some tech firms
Only those companies that want to actually modify the source and directly integrate it in a proprietary project, iow taking all but giving back nothing.
All companies that just want to use it unmodified, just accessing the API or integrate it in a compatible project with releasing any changes are just fine to do so.
> What would their benefits for releasing it under a permissive license be?
Similar benefits to a work released to the public domain (under permissive licenses such as BSD 0-Clause, CC-0, The Unlicense etc) versus any work that isn't. See the linked apache foundation blog-post in my comment above.
> AGPLv3 is a good trade, you get to use it for free but if you make improvements they need to be released...
This can be achieved with just GPLv3, and to an extent (but not quite) with EPLv2, MPLv2, and LGPLv3.
> Only those companies that want to actually modify the source and directly integrate it in a proprietary project, iow taking all but giving back nothing.
Even zerodha, which has closed sourced bits, would do well to seek counsel when using listmonk because there's danger they might violate AGPLv3 (ie, the rights of all contributors to listmonk) themselves if they're not careful enough.
>> AGPLv3 is a good trade, you get to use it for free but if you make improvements they need to be released...
> This can be achieved with just GPLv3, and to an extent (but not quite) with EPLv2, MPLv2, and LGPLv3.
No it cannot be achieved with those in generally, as Elasticsearch and other recent fiascos show.
Only AGPLv3 provides protection against "bad actor" SaaS providers.
>> Which nuances are not understood?
> Ex A: https://opensource.stackexchange.com/questions/5003/agplv3-s...
Seems like a pretty clear answer with lots of good sources backing it up.
I'd appreciate it if you could be a bit more specific in where you see the non-understood nuances.
>> Only those companies that want to actually modify the source and directly integrate it in a proprietary project, iow taking all but giving back nothing.
> Not really. Tech shops also tend to outlaw it for "risks involved". Ex A: https://opensource.google/docs/using/agpl-policy/
I know from personal experience that in practice this is not true in general, there are exemptions and AGPLv3 projects are used (but not derived or directly linked to!) – I cannot give out the specifics though, I'm afraid, so you'd need to take my word on that one.
> Only AGPLv3 provides protection against "bad actor" SaaS providers.
Elastic, Mongo, Redis et al moved away from AGPLv3 to an even more sterner SSPLv1. May be AGPLv3 isn't enough? Also the comparison seems odd since listmonk isn't in the same category as those; listmonk isn't core to the creator's business / income.
> I'd appreciate it if you could be a bit more specific in where you see the non-understood nuances.
Ref the part of the answer to the question which goes:
>> Q: What if in my case... the author of the library insist that the copyleft is triggered even if I am using the library unmodified and that I must redistribute the whole source code, including my own?
>> A: In this special case you should never ignore this interpretation (even though it looks clearly incorrect based on the facts I presented here) and you have two options...
> ...there are exemptions and AGPLv3 projects are used (but not derived or directly linked to!)
My best wishes to those proprietary-software selling tech cos for taking more risk than they should.
listmonk has nothing to do with Zerodha's business though. It's a personal project that I built prompted by usecases at work originally. I like AGPL because it increases the odds of improvements coming back to the upstream project, something into which I invest a lot of personal time.
> I like AGPL because it increases the odds of improvements coming back to the upstream project, something into which I invest a lot of personal time.
A note: MPLv2 (HashiCorp's license of choice) also achieves that just as nicely if improvements not getting back into upstream is a concern. xGPLv3 is of course better at it, but through its virality (not a bad thing but something tech cos are averse to it).
Besides, as mentioned above, Zerodha needs to be careful with its use of listmonk. They are at risk of violation of AGPLv3 themselves if they are not careful, ie violation of the rights of all contributors to listmonk, and not just that of the original author. IANAL.
I'd kind of forgotten about that. Ruby on rails smtp server? Any comment/idea on how it stacks up vis-a-vis postfix or opensmtpd in terms of performance and security?
Unsub has been available from day one. Bounce handling (generic webhooks, POP3, SES+Sendgrid webhooks) is already merged into the repo and will be available in the upcoming release.
- Tons of active development has happened and listmonk crossed 1.0 this year. 2.0 is on the horizon and there are quite a few listmonk instances in production.
- Our production setup at work now has ~7mn subscribers and listmonk works quite well. No issues with deliverability or IP reputation with our self-hosted EC2/Postal SMTP setup.
- listmonk now supports generic "Messenger" HTTP webhooks to which any message provider can be connected, allowing it to send arbitrary message campaigns like WhatsApp and SMS, not just e-mails.