My company is currently developing a commercial software for our clients (it will be offered both under a commercial license for SaaS and also a binary for on-site private network usage). This software uses 4 Unmodified (as-is) GPL and AGPL licensed Open-Source Software components internally. My question:
If we include the GPL License details of these 4 open-source components and also indicate explicitly the location of the open-source codebase on github, is that enough for us to legally commercialize our software? Is it as simple as dropping the GPL licenses in the right folder such as "LICENSE" folder?
It's not entirely clear if we are "legally" and "morally" covered. It's important to know that we will be taking full responsibility and providing support on issues/breaking changes (including the ones that occur within the open-source software - of course through community help and the owners of the open-source software). We will also give credits wherever due to the open-source projects and their owners "explicitly". is that enough?
What is the "best-practice" for commercial vendors who build their offering on top of Open-Source software?
Additional information (edited after a recent exchange of comments): Our SaaS software is composed of 4 components as listed below:
Component 1 (Open Source MIT licensed) - deployed as container on k8s "cluster-1"
Component 2 (Closed Source) - deployed as container on k8s "cluster-1"
Component 3 (Open Source GPL licensed) - open-source unmodified binary built on alpine image deployed as container on k8s "cluster-1"
Component 4 (Open Source AGPL licensed) - deployed as container on k8s "cluster-2"
Please note in the above detail that there are 2 K8s clusters involved (Cluster-1 and Cluster-2).
The Component 1 and 2 don't seem to be the problem here. However, Component 3 is a single binary deployed as a container in the same cluster as Component 1 and 2. Component 4 is an independently operating service that needs to be deployed on an independent k8s cluster.
Note: sources for Component 3 and 4 are "un-modified" and "sourced as-is" from their original location on github. They are, however, packaged as containers (following original instructions of the author/developer as mentioned in github).
So, each component is a different piece of software as mentioned above and exists or is managed or operated independently. Collectively they provide one SaaS offering.
Interactions (updated based on more comments):
Components 1, 2 and 3 all provide a REST interface
Component 1 is the only service that publicly exposes its REST endpoint. So, Component 2 and 3 are hidden from public access, but are proxied via Component 1
Component 4 exposes JDBC and https (as well as REST) interfaces. They remain open for authorized admins, operators, users to directly consume the service. Also note that: Component 4 interfaces are not meant for direct public consumption and therefore not exposed publicly, but more for intra-component integration and internal administration/management purposes.
Component 2 and 3 extensively interface with Component 4 via JDBC and REST