The Google v. Oracle decision raises an interesting question.

My understanding is that a proprietary application which dynamically links to a GPL-licensed library is considered a derivative work and has to distribute its source along the binary.

However, what if said application could load any DLL that conformed to the GPL'd library API, based on a user-specified configuration (or placed into a specific location)?

The vendor of the application could even provide a stub implementation with basic functionality and low performance, and let the users replace it with the GPL'd library "should they wish to do so".

The vendor is off the hook since the application they distribute does not contain any GPL-licensed code, and does not technically require it.

The users are off the hook since they don't distribute anything, and the GPL places no restrictions on use.

It sounds like a loophole to me. Am I missing something?

  • 3
    And how, exactly, did you fashion your code in order to make these calls to the GPL'ed library? Was it perhaps by a detailed reading of the library code, then a deliberate shaping of what you wrote in order to dovetail with the interfaces offered by the library?
    – MadHatter
    Jul 28 at 6:30
  • @MadHatter, I did not fashion any code, just asked a question about what looks to me to be a loophole or an oversight. Was there a particular reason to try to make this personal? Back on topic, APIs are usually described in documentation.
    – Alex O
    Jul 29 at 3:09

The Supreme Court did not rule that APIs are not copyrightable, just that, if they are copyrightable, Google's use is "fair use"; your use might not be "fair use"; there are also other countries which aren't under the jurisdiction of the USA's Supreme Court and don't even have fair use exceptions. So you'd be on somewhat thin ice to rely on that ruling.

Using common sense, if you copy the API from someone else's library and put it into your library, your library is now a derivative work of that one... unless any of the usual exceptions apply (e.g. the API is too trivial to be copyrightable). You are quite clearly basing your work on theirs.

If the library implements some standard specification, you could write your replacement library based on that specification instead.

I am not a lawyer and this is not legal advice.

  • I do not need legal advice since I am dealing with hypotheticals rather than an actual situation. I just find the question interesting enough to ask.
    – Alex O
    Jul 29 at 3:15

This is similar to how BSD editline (a clone of GPL readline) came to be... as long as the library is written to specification, not by code inspection ("clean room reimplementation" or similar), this is perfectly legal.

  • 1
    Excellent point, but it seemed to me that the question was about the GPL status of code that had been written to link to the library and now linked to another non-GPLed equivalent library, rather than the status of the non-GPLed equivalent library.
    – MadHatter
    Jul 28 at 7:46

The ruling in Google v. Oracle largely confirmed what the free software community already believed and hoped: the reuse of interfaces is (at least under some circumstances) permissable. It is exactly this permission that allows the reimplementation of proprietary components as free software. The principle may be extended to cover reimplementing GPL'd software under a different license; however, an author who reimplements source-available software (as all GPL software is) must take care not to read the original non-interface code lest it influence the authorship of the new code and create a derivative work

Insofar as your software reuses the API of some other software for reasons of interoperability, this probably would be found to be permissible under the same fair use factors covered in Google v. Oracle. The fact that the new reimplemented component can be replaced by a GPL module is not a problem nor a revelation brought on by Google v. Oracle; I would argue it has been an assumed copyright principle that free software authors have relied upon for decades.


It sounds like your question is somewhat related to the plugin Q&A on the GPL FAQ page:

When is a program and its plug-ins considered a single combined program? (#GPLPlugins)

It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.

If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

The interesting feature of this answer is that describes a situation which is a "borderline case". From that, you can see that your program falls squarely on the full GPL side of that borderline: the communication with your .dll sounds like it's far more intertwined than just "invoking the ‘main’ function", and the importance of the .dll sounds like it's greater than just being a "plugin".

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.