5

We have two applications developed by two teams. One is open-source under GPL, another closed-source without any possibility to open the code.

Also there's a requirement to implement some kind of API between them, where open-source acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.

However, what about IPC? Are there any precedents of exchanging queries and data between open- and closed-source applications using system-provided IPC, like pipes, shared memory or sockets? Should we prove someway that closed-source app just a service provider and loosely connected to open-source app?

UPDATE citation from GPL

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

So, not only way if communication, but is this communication "intimate enough". This is very vague term and could be used for speculations

6
  • Does the closed-source application depend on the GPL application in any way to fulfill its requirements? Or is the dependency only the other way around? Oct 19, 2018 at 9:40
  • It's hard to say how deep dependency is. Closed-source application is able to work without open-source so as open-source can work alone, but functionality of closed-source application could be described as "service provider", so it's useless without some client application, which is our open-source in our case (sorry for abstract terms)
    – user13416
    Oct 19, 2018 at 9:51
  • 3
    Related: Calling GPL'd programs from a shell script
    – Brandin
    Oct 19, 2018 at 11:30
  • Is the IPC interface already present in the GPL'ed program, or do you plan to add this on to the GPL program (and of course make these changes available per the GPL)?
    – Brandin
    Oct 19, 2018 at 11:30
  • Sure, it will require some changes in GPL application sources, and the client side code will be available as GPL requires, it would look like some advanced SQL query interface to the service. However, service side should stay closed
    – user13416
    Oct 19, 2018 at 12:05

2 Answers 2

4

According to the GPL, you can distribute GPL programs together with closed source programs as long as the programs are separate. The GPL calls such a collection an "aggregate":

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

Emphasis added. https://www.gnu.org/licenses/gpl-3.0.html

"I'm not linking with the GPL program; I'm just using sockets or IPC"

[We want] to implement some kind of API between [the GPL program and our closed-source app], where [the GPL program] acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.

Conventional Internet wisdom on this topic seems to go something like this: "if you statically link with an LGPL program, your program must also be (L)GPL'ed. If you dynamically link with an LGPL program, your program can remain closed source. If you statically or dynamically link with a GPL program, your program must also be GPL'ed."

However, this is not at all what the GPL says and it is unlikely that a judge would see it this way if there is actually a legal dispute. Section 5 of the GPL covers your main obligation of what you must do when you distribute GPL programs:

You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.

Emphasis added. If the program is LGPL'ed, or if it is GPL with a linking exception, then there is extra language in the license which clarifies in what circumstances you are allowed to combine the program with yours, without needing to license your program in the same way. However, for the ordinary GPL, the above paragraph is what you need to scrutinize.

So the real question is whether your final product will ultimately be considered as one work or separate works. This is true whether your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or in some other way. The FSF tried to answer this in their FAQ:

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

Emphasis added. https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation

Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what will actually be considered a combined work.

Rather than guessing what a judge may decide, you should first think about how the copyright holder of the GPL program you are redistributing is likely to interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."

From your description, it sounds like you already suspect that combining your closed source program with the GPL program may not be legally possible in the 'conventional' way (via static or dynamic linking), so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. Why is it a disadvantage to the GPL program's copyright holder? Because many software authors license their programs under the GPL specifically to encourage companies to do the same. I.e. "You may copy our code as long as you release yours as well."

On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source program is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.

Related questions and answers

Calling GPL'd programs from a shell script

What are the arguments for considering dynamic links to constitute derivative works?

5
  • I have an example. Let's say, Oracle added Hardening in Virtualbox, licensed under GPLv2, and this module is closed-source. As it's security-related, I suppose communication between them is "quite intimate". Also they package it as a single application. How did they manage to do that?
    – user13416
    Oct 19, 2018 at 13:10
  • 1
    I believe Oracle holds the copyright to VirtualBox code. If that is true they could in theory extend VirtualBox and release a closed source extension under a different license, even if doing so would normally be a license violation. In other words they can give themselves an exception, since they own it.
    – Brandin
    Oct 19, 2018 at 13:16
  • It is not just the little kernel. This is why I call it Gnu/Linux. To avoid the confusion, of people thinking I am just referring to the kernel. When we call the whole thing Linux we get anomalies such as WSL (Windows Subsystem for Linux: Gnu/Linux with the Linux removed). Oct 25, 2018 at 11:43
  • 1
    @ctrl-alt-delor I meant the Linux kernel. A distribution might have Linux plus other closed source (non-GPL) programs. Those closed source programs are not considered by their nature extensions of Linux.
    – Brandin
    Oct 25, 2018 at 13:12
  • @Brandin I mean that much of the user land will probably by licensed with some Free Software license, as well. (one bit of proprietary software will not make it all proprietary). For example the Debian project is Free Software. If Ubuntu add some proprietary applications, it is sad. However most of the system is still Free Software, but the system as a whole is not. Oct 26, 2018 at 6:54
2

As the closed-source service provider does not depend on the GPL client (other than that the GPL client is currently the only known client application) or other GPL code, there is no GPL-related trigger to require opening up the source code for the service provider.1

For the GPL client application (and the interaction with the service provider), there are two options.

  1. The easiest option is if the service provider offers a documented networked API. The client can implement its side of the API based on the documentation and there is no question about either the client or service provider being derived works of each other.

  2. If the service provider is implemented as a library, you can add an additional permission to the GPL license to allow linking the GPL client code to this specific closed-source library. Version 3 of the GPL license explicitly allows this kind additional permission under section 7, but they can only be added by the original licensor of the code (the one who wrote the relevant code).


1: If this were not so, it would have been possible to force Microsoft to release the source code for MS-Word by simply writing a scrip around it that uses some features of MS-Word.

3
  • Do you mean GPLv2 section 7?
    – user13416
    Oct 19, 2018 at 12:45
  • You said "other than that the GPL client is currently the only known client application". This is the truth, open-source client is the first client of the service. We can provide well-documented IPC, we can provide IPC options (sockets, pipes, COM under Windows), we can create demo client application and even publish as a product. However, open-source application is the most useful client for that moment
    – user13416
    Oct 19, 2018 at 12:59
  • 1
    @YuriS.Cherkasov: I meant GPLv3 section 7. GPLv2 does not have clear language that you can give additional permissions. Having a differently (non-GPL) licensed demo client application that can successfully use the service provider and distributing the service provider independently of the GPL client would both strengthen the claim that the service provider is an independent work of the GPL client. Oct 19, 2018 at 14:44

Your Answer

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