Suppose a program uses an API which has two implementations:

  • An MIT implementation which uses GPL libraries
  • A newer version of it which no longer uses any GPL libraries

Neither is distributed along with the program, one is already present on the system. I don't know which version the programs will be linked to. It may be the first, and therefore (transitively) link to GPL libraries, or the second, and not link to any GPL libraries.

Does the program have to be GPL-compatible?

  • 2
    Maybe the API it has a third (or fourth) implementation which is under a completely different license, or not (yet) released at all. If you would say which aPI you are talking about it would make this easier to answer definitively.
    – Brandin
    Sep 16 '19 at 7:11
  • "one is already present on the system" -- For this case, the GPL has a special exception. See the section about "system libraries" (GPL v3) or the phrase "as a special exception" (GPL v2).
    – Brandin
    Sep 16 '19 at 13:21

You are not responsible for what other people do with the software. If someone else links with a GPL library they are perfectly allowed to do that: GPL does not trigger on use or linking, only on distribution/propagation of the covered software.


  • your project shall not be derived of GPL software, in particular do not give the impression that you designed your software for that particular GPL library
  • do not distribute GPL software alongside your software
  • do not offer scripts etc that installs GPL components


  • do feel free to test for compatibility with different library implementations, incl. that GPL library
  • do mention in your documentation that this GPL library is compatible

Additionally, if you want yourself or someone else to be able to distribute the software alongside the GPL library, stick to a GPL-compatible license such as the MIT.

From the little information you're providing it seems that everything you are already doing is perfectly fine.

  • 5
    "do not distribute GPL software alongside your software" But bundling aggregates is okay, even with proprietary software! So why do you warn against this? Sep 16 '19 at 4:13
  • 4
    @curiousdannii Aggregate means "we're distributing a CD that contains a 100 independent programs". Bundling DLLs required by your application alongside your application is not what's described in your link as "bundling aggregates" (quote: "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.").
    – Luaan
    Sep 16 '19 at 12:58
  • And the next sentence says communicating by sockets is fine. And the shared address space rule hasn't been tested in court to my knowledge. That's just one interpretation. Sep 16 '19 at 13:15
  • @curiousdannii: "Hasn't been tested in court" isn't the measuring stick you should be using. If something is clearly contrary to the intent of whoever published the software you intend to disatribute and their intent is not some weird loophole interpretation of the license but the universally understood intent that OSI and FSF and others agree qualifies as FOSS, then attempting to do that something is clearly being a bad actor in the FOSS community regardless of whether a court would rule against you. Sep 16 '19 at 14:31
  • @R.. It's not a bad actor to dispute the FSF's position on shared libraries, there's a lot of disagreement about it. I wrote this pair of questions about it: 1, 2. Personally I think that most of the time the license should only cover what you distribute, and if you don't distribute something then you're not bound by it, even if you compile your code with it later. Sep 16 '19 at 21:23

The GPL is a copyright license. Its restrictions are a subset of those imposed by copyright law.

In very broad terms, copyright protects copying, distribution, modification, and various similar rights such as "public performance or display" (usually for artistic works). So, if you never distribute, modify, or copy* GPL'd code or binaries, then the GPL does not apply to you and it does not matter whether someone, downstream of you, does one or more of those things. However, that hypothetical person might have difficulty complying with both your license and the GPL, and might therefore choose not to distribute your software at all. Whether you consider that a problem is your decision, of course.

The position of the Free Software Foundation, and most other people in the open source and free software communities, is that APIs cannot be copyrighted. Numerous people have said as much during the Oracle v. Google lawsuit. If this is in fact legally correct, then "using an API" also does not require a license. If this is legally incorrect (in your jurisdiction), then you may need a license from whoever developed the API in the first place, which complicates this analysis somewhat. However, I would certainly hope and expect that most reasonable authors would be willing to place their APIs under permissive terms or a CC0 public domain dedication. Unfortunately, this is a relatively new problem, and most existing licenses do not take it into account.

* In general, most if not all of the GPL's obligations attach at time of distribution. Making private copies or modifications does not usually trigger any obligations by itself. This is not true of, for example, the AGPL, for which section 13 attaches at time of modification.

  • It should probably be noted that much of early GPL software by the FSF was indeed explicitly designed to preserve existing interfaces of proprietary Unix applications and systems. It would be pretty weird if you couldn't do the same thing in reverse.
    – Luaan
    Sep 16 '19 at 13:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy