6

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.

6
  • Ate you the sole copyright holder of the projects and especially the gpl library you want to link with a proprietary module? I'm not clear at all what is your code, which is the library and which is a programme using one or the other. Commented Jun 23, 2023 at 3:39
  • The position of the FSF is that if you link with a GPL program, then the GPL says that you must release your main program (Bar, in your example) in a GPL-compatible way. See: gnu.org/licenses/gpl-faq.html#LinkingWithGPL Technical tricks like dllexport and so on are unlikely to help you here. If you want a "workaround" then you'll have to investigate using a CLI (command-line interface) only from your non-GPL program Bar, to communicate with the GPL program Foo. See: gnu.org/licenses/gpl-faq.html#MereAggregation
    – Brandin
    Commented Jun 23, 2023 at 6:58
  • For your question, it's not clear what you mean by "comply with the GPL license" since you didn't say how you want to license Bar. If you license Bar in a GPL-compatible way, then by all means, that will comply. If you don't do so, then no, it won't.
    – Brandin
    Commented Jun 23, 2023 at 6:59
  • "And this is my main source of confusion(hyperlink to LinkingOverControlledInterface)." - If you read that section, that is relevant for software authors (e.g. authors of Foo) that specifically want to allow other to link their (non-GPL programs) with the GPL program by providing an "additional permission". Normally, you'd just use the LGPL for this case. But that FAQ item you linked to shows how you could do it using plain GPL as well, by adding your own "additional permission" to allow that. Note that only the authors (copyright holders) can add such additional permissions, though.
    – Brandin
    Commented Jun 23, 2023 at 7:08
  • @Brandin I want to have a proprietary license for the Bar project as I mentioned in the "What Solution I’m Expecting" section. Commented Jun 23, 2023 at 7:18

2 Answers 2

10

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.

5
  • Great! Another request. Can you clarify this confusion? Or give me some suggestions on what steps I can take to achieve a similar result while ensuring compliance with a weaker copyleft like LGPL. That would be much appreciated. Commented Jun 23, 2023 at 9:36
  • If Bob were to publish a GPL enhancement to a program that would allow the recipient to dynamically link any code of their choosing, open-source or otherwise, nothing in the GPL would forbid him from doing so provided he published the source for that enhancement. If Bob wanted to authorize anyone and everyone to produce DLLs for use with that enhancement that weren't derivatives work of any GPL code other than Bob's enhancement package, I see no basis for GPL prohibiting that, nor do I see why "anyone and everyone" allowed to release closed-source DLLs shouldn't include Bob himself.
    – supercat
    Commented Jun 23, 2023 at 22:03
  • What if only Implementation.cpp is GPL'd and the Interface.hpp is under a permissive license like zlib. Can I then dynamic link the Implementation.dll to the Bar project and call functions and method of the Implementation.dll through the zlib licensed Interface.hpp? It should be allowed since I'm not changing the GPL'd codebase in anyway. I'm not deriving my work from the GPL'd codebase rather I building alongside it. For a definition of derived work according to copyright law, See Here (Under the 'DERIVATIVE WORK' section). Commented Jun 25, 2023 at 10:46
  • @NasirHossain, that won't work. If any part of the executing code is under the GPL, then the GPL applies to the whole thing. Commented Jun 25, 2023 at 12:54
  • @BartvanIngenSchenau: Note, however, that GPL is far more permissive about the kinds of derivative works people may execute than the kinds of derivativve works people may distrubute. The act of dynamically linking a program would likely produce a derivative work that could not legally be distributed, but if that process is done by the end user, the user would be allowed to execute it even if further distribution of the in-memory code image would be forbidden.
    – supercat
    Commented Jun 26, 2023 at 18:16
0

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.

5
  • Your first paragraph may or may not be true. See this answer: opensource.stackexchange.com/a/5090 Commented Jun 24, 2023 at 6:15
  • 1
    @BartvanIngenSchenau The first paragraph is not saying that dynamic linking is not a derivative work (as your linked answer addresses). It is saying that the GPL license terms apply to distribution, not to creating a work. If you want to link a GPL work and a proprietary work on your own personal computer, that is unambiguously allowed by the GPL license.
    – Chris
    Commented Jun 25, 2023 at 16:57
  • @Chris-RegenerateResponse: Yup. And supplying other people a means of doing that on their compuler would not represent facilitation of copyright infringement, since one would be facilitating the process of other people doing something which they are expressly allowed to do.
    – supercat
    Commented Jun 26, 2023 at 18:12
  • @BartvanIngenSchenau: In the described "chess program" example, if nothing in my closed-source chess engine is derived from any GPL code other than the header file I wrote myself, and nothing in that header file is derived from any copyrightable code written by anyone else, is there any reason I shouldn't be allowed to license anyone and everyone to use the header file in any way they see fit without such usage binding them to any aspect of the GPL? Trying to bind the closed-source code by the GPL would be analogous to saying that if a photograph taken in a public place where a...
    – supercat
    Commented Jun 26, 2023 at 18:34
  • ...copyrighted work would be visible, that all copies of the photo--including those where the copyrighted work is blurred out--would be considered derivative works of the copyrighted work that had been captured in the original image. I don't think copyright law has ever been interpreted to say that a work X which contains part of another work Y which was derived from a third work Z is considered a derivative of Z, without regard for whether *the particular portion of Y that was used by X would have been a derivative work of Z.
    – supercat
    Commented Jun 26, 2023 at 18:37

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.