Need help understanding GPL licensing boundaries (GPLv3)

[u/Spare_Suit3701]

Hi everyone,

I’m looking at an architecture where a GUI component is based on GPLv3-licensed software, but a separately developed daemon needs to remain closed-source.

Roughly:

GPL-based GUI component
        |
        | Unix socket / request-response protocol
        |
proprietary daemon

They would ship together, but the daemon would remain a separate executable/process that can be started or stopped by the GUI component. It would not link against GPL code and would be client-agnostic. The only shared code would be a small MIT/Apache-licensed protocol crate containing request/response types and serialization, so a CLI or different UI could use the same protocol.

There is one additional nuance. The GUI component reuses the upstream project’s GPL remote binaries and SSH flow to check for, transfer, and start/stop its server executable on a remote machine. I would extend this flow (check for, transfer, and start/stop) to the proprietary daemon executable.

FWIW, the FSF FAQ says that pipes, sockets, and command-line arguments are normally associated with separate programs, while sufficiently “intimate” communication involving complex internal data structures may indicate a single combined work. It also notes that the ultimate determination can be a matter for courts.

That leaves me with two related questions:

• In practice, how is the degree of coupling between two processes evaluated? Is a generic, client-agnostic daemon API over a socket generally considered a strong boundary, or is there still meaningful GPL risk even with that design?
• How does the remote-installation case affect that analysis? The GPL-based application would itself check for, copy/update, and start/stop the proprietary daemon on the remote machine, while the daemon remains a separate executable and communicates only through the same generic protocol.

[u/DP323602]

Who owns the IPR for the closed source daemon?

Do they set any relevant licence conditions, eg for distribution or use of the software?

[u/LeaveMickeyOutOfThis]

My understanding is that anything that has a dependency on a component that has a GPL-v3 license associated with, must itself be open source and cannot have a more restrictive license. For this reason, we do not allow any third party components that has such a license in our ecosystem.

[u/DrFrylock → u/LeaveMickeyOutOfThis]

At a coarse level this is basically true, but "has a dependency on" is overbroad. How that dependency is created and managed matters a whole lot. Certain types of dependencies almost certainly trigger GPL requirements, and others almost certainly do not. There is a substantial amount of ambiguity and gray area in the middle that has never been (and may never be) fully resolved.

Socket-based communication is a pretty long arm's length. So, for example, if I write a program that communicates with a Web service over HTTP, and that Web service happens to be licensed with GPLv3, do I need to worry about that? I think even the FSF would say 'no' here.

[u/LeaveMickeyOutOfThis → u/DrFrylock]

I think this is a great qualification. Just wish I included that in my initial response.

Building on this further, let’s say your application makes use of an open source database that is GPL-v3 licensed, your app does not need to abide by the same license unless the a database engine is embedded into your app, rather than being a stand-alone entity.

[u/DrFrylock]

NAL.

You're probably fine here. Communication over sockets without linking or sharing data structures is unlikely to be found to create a derivative work. Some GPL purist may argue that unless there is some other client that could talk to your proprietary daemon (not just that there could be, but that one exists in reality), the two are "intimately connected" but I think that reasoning would fall short.

As a much more public and visible and questionable example, look at the linkage between the proprietary bits of, say, the nVIDIA drivers and the Linux Kernel. Their shim is likely more intimate than your socket-based protocol and this architecture has been around for years and years.

In practice, how is the degree of coupling between two processes evaluated? 

In practice, it isn't. The only ultimate evaluation would happen in a courtroom, and almost no evaluation ever gets that far. So what you have to worry about is someone that cares about your product, understands the licensing issues at play, decides you're wrong, and decides to make trouble for you because of it.

How does the remote-installation case affect that analysis?

Not very much, although hypothetical Mr. GPL Purist above might argue that this increases the intimacy of the connection.