Using GPL licensed library over a service for non-GPL softwares

Question

I want to use a GPL v2 licensed library(esper) for commercially distributed non-GPL softwares but I need to make sure non-GPL software not violate GPL license.

Can I use this library indirectly using a wrapper service(can be a windows service, web service, rest api etc.) ? This wrapper service will provide a generic interface to utialize this library and will be licensed with GPL. Any commercial software can communicate with this service using its plugins.

Lets explain through the figure below.

alternative image link : https://ibb.co/nRjxr7

• E is GPL licensed library that is I want to use. It is not modified in any way.
• C is my GPL licensed service that using E and running independently of A/B . Any client software can use it.
• A and B are my commercial web apps that will use C over adaptors. A and B can work without C. So there is not strong dependency for C. A, B and C are not running in the same process. They can work even on different machines.
• Adaptor A/B will call C over tcp/http.
• C service will provide generic operation interfaces. Adaptors will use the data contracts that provided by C. So, Adaptors needs to know what data models are supported on C operations

Is this scenario appropriate? Is there any proper way to achive my problem ?

How should I distrubute Adaptor A/B ? Are they need to be GPL licensed ( A/B distrubuted with an .exe file to installation without containing adaptors)

Lastly, what is the way of I distributing C and mentioning in my commercial applications to tell users to install it and integrate with other applications. (I can specify with a description that explains how to utilize C service for the A/B users. Also I can make C program source and installation file available on my server for download.)

Answer 1

IANAL/IANYL. That said, the devil, as usual, is in the details, and you don't give us much information about how these adaptors work.

If, for example, the B-C adapter is a piece of software that works by linking against libraries that form part of B, and also against libraries that form part of C, then you've created a single, large, derivative work of both B and C, and you have a big licensing problem on your hands.

If, instead, the adapter uses userspace as a mediating tool (eg, B puts files on the file system, then the adapter moves them into C's bit of filespace and calls C through fork-and-exec to deal with them, or C runs as a daemon that periodically checks whether there are new files to deal with), then B and C are separate works for copyright purposes, and you don't have a problem.

The one about your obligations with respect to C is pretty well covered elsewhere, but in brief, if you tell your users that they must download and install it, and you make both source and executable available from the same place on your website, that would suffice. If you distribute C directly to them, your obligations with respect to source provision are a bit more extensive, but not much so.

---

Edit: you have clarified that both A and B adapters will interact with C via HTTP. Provided they do this using RFC-standard HTTP operations (POST, GET, etc.), that seems likely to me to be at arm's-length enough to make them separate for copyright purposes; certainly my web browser doesn't need to know about the GPL status of the web servers with which it interacts. If they're thus separated, then A and B adapters can be proprietary software which you distribute along with A and B.

I'm still a bit nervous about "Adaptors will use the data contracts that provided by C. So, Adaptors needs to know what data models are supported on C operations", because I don't understand what you mean.

Edit 2: given your subsequent clarification, it depends on how knowledge of the structures is acquired. Generally, if there is a separate written specification, and you implement this de novo in your code, all is likely to be fine (there has been at least one attempt to claim that an API can be copyrighted, but it wasn't hugely successful). If there is no separate written specification, and you read (in your example's) Amazon's library code to work out what the API is, or worse still, use their code as a basis for your own, there is a problem.

I note that you have yourself written C, wrapping it around the pre-existing GPL library E. That puts you in a position to write that specification, but not to implement it. Clean-room practice is that person A reads the "contaminated" code and writes the functional spec, and a person B implements that spec, without any further reference to person A. You cannot be both of those people.

---

Note that this whole analysis assumes that linking creates derivative works, and as we note elsewhere, this is not yet a certainty; arguments can be made both for and against the issue. It is generally accepted, however, that interaction-through-userspace keeps two programs far enough apart that neither is entangled by the other from a copyright point of view.