3

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:

  1. Component 1 (Open Source MIT licensed) - deployed as container on k8s "cluster-1"

  2. Component 2 (Closed Source) - deployed as container on k8s "cluster-1"

  3. Component 3 (Open Source GPL licensed) - open-source unmodified binary built on alpine image deployed as container on k8s "cluster-1"

  4. 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):

  1. Components 1, 2 and 3 all provide a REST interface

  2. 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

  3. 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.

  4. Component 2 and 3 extensively interface with Component 4 via JDBC and REST

Diagram:

component overview

Improve this question
13
  • 4
    How are you using them? As standalone binaries? As libraries? As a core system to which you have written a proprietary plugin? Without knowing quite a lot more (preferably, what are the components, and exactly how are they used) it's hard to answer this question.
    – MadHatter ♦
    Commented Feb 6, 2023 at 11:16
  • 1
    Please study the GPL FAQ and then refine your question with the items that remain unanswered.
    – Martin_in_AUT
    Commented Feb 6, 2023 at 14:33
  • 1
    @NextGenMetrics You will need to be more specific, especially w.r.t. the question if the components form a 'combined program' or an Aggregate (see gnu.org/licenses/gpl-faq.html#MereAggregation)
    – Martin_in_AUT
    Commented Feb 7, 2023 at 14:56
  • 1
    @NextGenMetrics, the question basically is if the (A)GPL parts and the closed-source parts form one executable or if they are independent executables that don't need knowledge of each other's internals. That is a major factor in determining your obligations under the (A)GPL.
    – Bart van Ingen Schenau
    Commented Feb 7, 2023 at 18:06
  • 1
    You've told us what the components are, for which many thanks, but we still don't know how they interact. Particularly of interest are all interactions with components 3 and 4. JSON via HTTPS, or database calls, perhaps? Do humans interact with component 4, or is it solely providing a back-end service to other numbered components?
    – MadHatter ♦
    Commented Feb 8, 2023 at 11:07

1 Answer 1

Reset to default
5

From your description of the system above it is clear that component 4 (with AGPL license) is not user-facing (towards public suscribers) and therefore the situation "users interacting with it remotely through a computer network" (Section 13 of the AGPL License) does not apply. There is a discussion if Section 13 demands that the source code must be disclosed also to company-internal users, but I do not think so, I think the first paragraph of this answer in the GPL FAQ is also applicable here.

The communication between Cluster 1 and Cluster 2 through JDBC and REST interfaces is a clear indicator, that the communication between the 2 clusters falls under the definition of an 'aggregate' as described in the GPL FAQ.

The same is true for the communication between Component 1 and Component 3, the REST API successfully isolates the two from being a 'combined program'. They run independently and are not communicating through a close link.

The remaining interfaces are no-brainers, there is no impact on the licensing of your service.

In the setup described in your question above you only need to comply with the clauses of the MIT license towards the public. This means that you have the proper license and attribution language in the HTML interface of your service. This will also cover the JavaScript code that is under the same license.

There is no 'moral' obligation to give attribution to authors of the back-end software. This is rarely done and not expected. It might even cause confusion w.r.t. the scope of your actual obligations.

Improve this answer
5
  • OP is pretty clear from the diagram that there is a class of users who interact directly with component 4, and the language of s13 triggers on interaction not conveyance, so I can't agree that company-internal users don't trigger it. Nevertheless, this is not the place for that discussion, and I agree with the rest of your analysis, so +1 from me, subject to that reservation.
    – MadHatter ♦
    Commented Feb 9, 2023 at 10:15
  • Thank you @MadHatter . We had the same discussion (AGPL for internal use) here and we do not need to repeat the arguments.
    – Martin_in_AUT
    Commented Feb 9, 2023 at 11:01
  • 1
    @Martin_in_AUT, many thanks for your detailed response and clarification. We are still processing the detail. One of the questions raised by my team: "does your answer stay valid whether the software is delivered as a managed service (SaaS) and/or as a distributed docker containers?" Secondly, we are developing this software for our client (who may or may not chose to commercialize/monetize with a SaaS tenancy model) - in which case, does my client (as a service provider) need to declare the "embedded" licensing chain to protect themselves legally.
    – NextGen Metrics
    Commented Feb 10, 2023 at 10:14
  • The question here really is, what levels of display/attribution would cover the service provider/software distributor/vendor legally? I guess, the next thing for us to worry about is how and through what means do we accomplish that - via disclaimers, legal clauses, etc.
    – NextGen Metrics
    Commented Feb 10, 2023 at 10:14
  • @NextGenMetrics The answer relies on the assessment of the relationship and communication between the different components (i.e. the determination that we are dealing with an 'aggregate' and not with 'combined sw'). It does not depend on who programmed it and sold it. Due to the fact that the AGPL-licensed parts are clearly separate, there is also no material impact in the change from SaaS to actual software shipment. You need to be careful to include a proper 'license.txt' (best case: separate for each cluster). There are numerous questions and answers about that part here on Open Source SE.
    – Martin_in_AUT
    Commented Feb 11, 2023 at 12:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.