|
|
|
|
|
by vaultsandbox
160 days ago
|
|
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. |
|
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.