Comment by vaultsandbox | Hacker News Reader

Comment by vaultsandbox | Hacker News Reader

Parent Full thread

I do not see the issue here, either. My plan for developing the commercial add-on (a separate backend server) is for this gateway to connect to it using a REST API. So, if they need to use this, they can integrate it with their system the same way. There is nothing stopping anyone from using the open-source gateway and developing a compatible backend, since I will document that part.

For now I am focusing on phase 1, which is to make it rock solid. Only after that will I start doing that part. In this phase, I wanted to listen to the community to add missing features, but apparently it will not be easy :D

Thanks for your reply.

Edit: One crucial detail I should have mentioned: while the gateway engine is AGPLv3, all the native SDKs (Node, Python, Go, Java, .NET), Frontend and CLI are MIT licensed. This ensures a clean legal boundary; your application code only ever interacts with the MIT-licensed client, which talks to the gateway over the network. This should eliminate any 'GPL infection' concerns for standard CI/CD use cases.

> I do not see the issue here, either.

Despite there not being an issue, there are many companies, including some very significant ones, that have restrictive rules about the use of GPL software just-in-case. Some flat out have a blanket “no GPL code at all” for the libraries and such that they use. I don't know if it still stands, but Android development at Google had a “no GPL in userspace” edict. If your service becomes big, you will get people asking you to change the licence so that they can use it.

You are right, maybe I will change it to MIT. What is the worst that can happen?! I will think about it. Thanks

Of wide adoption is more important than than the key benefits of strong copyleft OpenSource, then something like MIT will help, but personally I'd keep with AGPL3.

I wasn't advocating for change in my previous comments, just pointing out that a fair number of people will ask for that, and why they would. IMO "we can't use it under this license because of company policy" is a them problem, not a you problem!

There is no point in having AGPL if no one uses it! I am the only contributor right now, so I have time to think. I need to change my message. I will talk less about encryption and production. I will talk more about localhost testing benefits. 1. Isolated inbox per test (parallel-safe by default) 2. Deterministic email assertions, no sleeps 3. One container: SMTP, Web UI, CLI 4. Automatic cleanup with expiring inboxes 5. Secure by default, no config required

I got some upvotes, but almost no feedback, negative or positive.

Reply on news.ycombinator.com