Inquiry regarding GPLv2 compliance in a Client-Server architecture with proprietary backend modules

Non-technical Questions
1

Hello DHTMLX Team and Community,

I am planning the architecture of a financial/accounting application and I would like to ensure full compliance with the DHTMLX GPLv2 license before moving forward.

Our proposed architecture is a decoupled Client-Server model, and we want to verify if our approach fully respects the boundaries of the GPLv2 “copyleft” effect. Here are the specifics of our technical and licensing design:

  1. Frontend (Client Side): The entire user interface will be built using the GPL version of the DHTMLX Suite. In strict compliance with the GPLv2, 100% of the frontend source code will be made open-source and distributed under the GPLv2. Any user or client will have full access to this code.

  2. Backend Core (Server Side): The frontend will communicate with the server exclusively via standard network protocols (REST API / HTTP fetching JSON payloads). The core functionalities of this backend will be released under a permissive open-source license (MIT).

  3. Backend Commercial Modules (Plugins): We plan to offer premium, closed-source (proprietary) modules running strictly on the server side. These modules will handle advanced processing (e.g., automated tax auditing).

Crucial Architecture Points:

  • The frontend code utilizing DHTMLX will not be modified, recompiled, or adapted to support these premium modules.

  • The frontend will remain identical for both free and premium users; it will simply display or hide UI elements based on the feature-flags and permissions returned by the backend API responses.

  • There is no static or dynamic linking in memory between the DHTMLX-powered frontend and the proprietary backend plugins. They run in entirely separate execution environments and communicate solely over standard network transport layers.

Based on the Free Software Foundation’s guidelines regarding the “stricter” interpretation of independent programs communicating via network RPC/APIs, it is our understanding that the backend does not constitute a “derivative work” of the GPL frontend, and therefore the GPLv2 copyleft provisions do not extend to our proprietary server-side plugins.

Could you please confirm if the DHTMLX team considers this specific architecture compliant with your GPLv2 licensing terms?

Thank you very much for your time, guidance, and for providing such an excellent suite of tools.

Best regards,

Elihu Diaz A.

2

Hello @cstff,

Your main conclusion is correct: a backend that talks to the DHTMLX frontend only over the network (REST/HTTP + JSON), in separate processes with no DHTMLX code linked in, is an independent program. GPLv2 copyleft does not reach it, so both your MIT core and your closed-source server modules are fine. (DHTMLX Suite is GPLv2, which has no SaaS/network clause.)

The only thing that matters is the frontend, since that’s where DHTMLX actually runs. To stay compliant:

  1. The whole frontend you serve, your code plus any other JS libraries bundled with DHTMLX, must be GPLv2 (or compatible), with no proprietary parts.
  2. Every user the JavaScript is served to must get the full source under GPLv2, with license notices kept intact.
  3. Premium logic stays on the server. Showing/hiding UI via API permissions is fine, as long as the frontend you ship is identical for all users and fully GPL.

If those hold, your design complies. (Only if you ever need to keep part of the frontend closed would you need a commercial license, the backend doesn’t.)

For a formal confirmation, our licensing team is happy to review: info@dhtmlx.com

Kind regards,

1 Like