Dynamically Linking a Proprietary Module to a GPL-Covered Library (C/C++)

Question

Context

Suppose I have two projects called:

1. Foo
2. Bar

Goal: The Foo compiles to some sort of dynamic linking library such as a windows .dll and links to project Bar dynamically. And some of the headers files of the Foo project are included in the Bar project. And the Bar project links to the Foo project dynamically for getting the declarations. Below is a more detailed explanation.

Project Foo contains the following two files:

Interface.hpp:

#pragma once

#ifdef __WINDOWS__
    #ifdef BUILD_DLL
        #define API __declspec(dllexport)
    #else
        #define API __declspec(dllimport)
    #endif
#else
    #error only supports Windows!
#endif

#include <iostream>
#include <string>

class API Foo {
 public:
  Foo();
  ~Foo();
  void greet(std::string name);
};

Implementation.cpp:

#include "Interface.hpp"

void Foo::greet(std::string name) {
  std::cout << "Hello" + name << std::endl;
  return;
}

And the Bar Project contains a main.cpp file with the following:

#include "Interface.hpp"

int main(int argc, char* argv[]) {
  Foo instance = Foo();
  instance.greet("Nasir");
  return 0;
}

What I'm Asking

I would like to understand if this project setup complies with the GNU General Public License (GPL). Specifically, I am seeking clarification on whether project Bar, being proprietary and dynamically linking to project Foo while including the interface file (Interface.h) for function definitions, adheres to the requirements imposed by the GPL. If it doesn't adhere to the requirements imposed by the GPL, give me some guidance and resources or point-out what I am doing wrong and what I can do for a similar result.

Note: I am aware of the implications and restrictions imposed by the GPL when combining GPL-covered code with proprietary software. However, I am uncertain about the compliance aspect in the described scenario. I would greatly appreciate insights and guidance on ensuring compliance with the GPL within this context, considering the utilization of a controlled interface and dynamic linking between the Bar project (proprietary module) and the GPL-covered Foo project (library).

What did I try and what I’m expecting?

I Have Done My Research

I have read this article. And this is my main source of confusion.

I Have Produced the Confusion

To ensure compliance with the GNU General Public License (GPL), I have utilized a controlled interface approach, where Foo provides an API (defined in Interface.hpp) that is explicitly declared as either dllexport or dllimport based on the build configuration. The Bar project includes Interface.hpp for accessing the function definitions.

What Solution I’m Expecting

My expectation was to clarify whether this project setup adheres to the requirements of the GPL. I am aware of the restrictions and implications of the GPL when combining GPL-covered code with proprietary software. However, I seek guidance and insights regarding the compliance aspect in this particular scenario. Specifically, I would like to understand if the dynamic linking of the proprietary Bar project with the GPL-covered Foo project, while including the interface file (Interface.hpp) for function definitions, complies with the GPL.

If this project setup does not conform to the requirements imposed by the GPL, I would appreciate guidance, resources, or suggestions on what steps I can take to achieve a similar result while ensuring compliance with the GPL.

Answer 1

I would like to understand if this project setup complies with the GNU General Public License (GPL). Specifically, I am seeking clarification on whether project Bar, being proprietary and dynamically linking to project Foo while including the interface file (Interface.h) for function definitions, adheres to the requirements imposed by the GPL.

No, your setup does not comply with the GPL license.

The GPL license does not make any provisions for different forms of linking (static, dynamic, with or without a controlled interface). If you link to a GPL-licensed library, then your main program and all other code linked to it needs to comply with the GPL requirements, which implies that it needs to be licensed under a GPL-compatible open-source license.

There are three main ways to get into compliance, and which of those are open to you depends on whether or not you are the sole copyright owner of either Foo or Bar.

1. If you are the sole copyright owner of Bar (or there are few enough copyright owners that you can realistically get a unanimous agreement from all of them), you can change the license of Bar to the GPL license.
2. If you are the sole copyright owner of Foo (or there are few enough copyright owners that you can realistically get a unanimous agreement from all of them), you can change the license of Foo to a license that allows to combine it with proprietary code. That could be a permissive license, like MIT or Apache 2.0, or a weaker copyleft license like the LGPL.
3. You can replace the Foo library with another library that has better licensing terms for your use case.

Note that for changing a license, you need a positive confirmation from all copyright holders. A single one not responding already counts as a veto.

---

The FSF FAQ entry that is causing you confusion (https://www.gnu.org/licenses/gpl-faq.en.html#LinkingOverControlledInterface) proposes a variation on option 2 mentioned above. That variation is to change the license of Foo to "GPL + custom exception", where the exception text gives the recipients of Foo additional permissions that they would not have with the GPL alone.

I did not mention it as a possibility, because writing such an exception is not easy and I expect you would end up with something similar to the LGPL license anyway. In that case, it is better to just go with the well understood LGPL license.

Answer 2

GPL allows open-source software to be linked with arbitrary code, open-source or otherwise, provided that no derivative work of GPL code is distributed in ways which do not satisfying the GPL requirements, and which are not otherwise authorized by the author of the person whose work is incorporated into the derived work. For purposes of this requirement, aggregations are not considered derivative works.

If e.g. one wanted to adopt a GPL chess program for use with a proprietary chess engine, one could write and publish as open-source an interface module which would interact with the chess engine and with the DLL, and publish the specifications for how the DLL works, along with an open-source sample implementation (e.g. a simple chess engine that makes arbitrary random modes). Anyone who wanted to adapt that for use with a better chess engine, open source or otherwise, would be free to do so, provided that any closed-source code would be kept separate from GPL code until linked (likely at runtime) by the final recipient.

If the creator of the interface code were to write a closed-source DLL that exploited details of the interface which weren't clearly published, it could be argued that failure to publish such details meant the person hadn't really published the full and complete source code of the interface. If, however, the person creating that interface publishes everything that would be necessary for anyone else to use it the same way as the author does, there's no reason the author should have any less freedom to write closed-source DLL for use with it than any other person would have.