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.