4

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?

Improve this question
2
  • 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, 2019 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, 2019 at 13:21

2 Answers 2

Reset to default
14

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.

However:

  • 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

But:

  • 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.

Improve this answer
6
  • 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?
    – curiousdannii
    Sep 16, 2019 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, 2019 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.
    – curiousdannii
    Sep 16, 2019 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.
    – R.. GitHub STOP HELPING ICE
    Sep 16, 2019 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.
    – curiousdannii
    Sep 16, 2019 at 21:23
7

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.

Improve this answer
1
  • 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, 2019 at 13:00

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.