How can a GPLv2 dependency affect licensing of adjacent components that form an aggregate project?

Question

I've read some of the GPL questions on here that seem relevant, but I haven't found an understandable answer for my particular case. I'll note them here for reference.

• When does a dependency imply a derivative work?
• Software: If I bundle built (compiled) GPL 2 licensed software with commercial software package how does it affect my software license?
• How should I mark a source file with GPLv2 as a derivative work?
• Can license-incompatible program communicate with GPLv2 program via websocket?

I've also read this, which seems relevant.

Hopefully this is not a duplicate.

Background

I have a project that's mostly written in C with many dependencies. Many are MIT, some ISC, some custom, and some GPL with special exceptions.

I want the project to have a permissive license. I'd like to be able to allow people to use parts of my project for proprietary applications without being affected by things like GPL. To do that, my thought was to decouple invasive dependencies such as GPL from select parts of my work.

The project is comprised of multiple components.

MyLib (author: me)

• A custom library that can be shared OR static depending on platform.
• It only depends on projects with permissive licenses.
• It implements a REST API that takes in (and returns) data types of its own definitions which don't depend on any restrictive licenses.

MyServer (author: me, but depends on a GPLv2 project)

• A server application that depends on a GPLv2 networking stack.
• I have not made modifications to the networking stack source code.
• The network stack source is compiled directly into the server program.
• The server also uses MyLib as a dependency, but this dependency does not utilize any of the facilities from the network stack. The reverse is also true. Instead, it is the server application's responsibility to transform data from the networking stack into primitive data types that can be consumed by MyLib without exposing any implementation details of the GPLv2 project, and vice-versa.

MyClient (author: me)

• A web client with no dependencies which talks to MyServer and utilizes the REST API as defined by MyLib.
• As mentioned before, the logic and data structures for the REST API is defined in MyLib which is agnostic to the server implementation.

The idea is that the server implementation could use ANY framework and the client/library on each end wouldn't care. The middleman is completely opaque to them.

Questions

1. Can I have a separate, more permissive license for MyLib and MyClient?
2. Does static linkage between MyLib and MyServer change how the GPLv2 license applies to distributed binaries?
3. What happens if I or some user of this project does modify the GPLv2 network stack?
4. Would the following project structure comply with the GPLv2 license?

    my_project_repo/
      server/
        LICENSE.txt - GPLv2
        server.c - MyServer which includes network.c and abitrarily links to MyLib 
      client/
        LICENSE.txt - Whatever
        index.html
      lib/
        LICENSE.txt - Whatever
        mylib.c - MyLib
      extern/
        network_project/
          LICENSE.txt - GPLv2
          network.c - Networking stack

My intuition says that this situation is making myself the user of a dependency I made. This means the same rules apply to my other permissive dependencies. That is, it doesn't make sense to say a project with the zlib license becomes GPL just because someone out there compiled it into a project that also includes a GPL project.

I believe this means that MyServer becomes treated as the "default" server implementation. The restriction on users who wish to use a server component for proprietary purposes would be that they need to reimplement the server using MyLib and a different networking framework to evade the GPL license.

Is that a correct assumption?

Answer 1

I'm not a lawyer, and this is not legal advice.

Can I have a separate, more permissive license for MyLib and MyClient?

Absolutely, you said they dependencies of MyLib have permissive licenses. I assume you are referring to the MIT & ISC license types here. For these two licenses you just need to convey the copyright and license information to be compliant.

Does static linkage between MyLib and MyServer change how the GPLv2 license applies to distributed binaries?

Yes. If you are distributing a binary in which MyServer has statically linked (would also apply to dynamic linking too) in MyLib, then the combined work is licensed under the GPL2. Hence, you would have to treat both MyLib and MyServer as licensed as GPLv2 if you are distributing the binaries of the two things linked together. If you are only distributing the source, you are free to license MyLib under a license that is compatible with the permissive licenses that it depends on.

What happens if I or some user of this project does modify the GPLv2 network stack?

If you distribute the binary that has included a modified GPLv2 network stack, then you must also distribute the source that includes these network stack changes. It's important to note which files you have modified if you care about your copyright. Supplying the modifications via a patch file would be an appropriate way to convey your changes.

Would the following project structure comply with the GPLv2 license?

Sure, that structure could comply with the GPLv2 terms and conditions, but you run the risk of licensing cross contamination by placing differently licensed software in the same repository. Just be careful that MyLib doesn't accidentally start using headers and other source files from MyServer. If MyLib starts using components from MyServer, you may end up having to license MyLib under the GPLv2. I think your structure is fine as long as you have the diligence to make sure your permissively licensed software isn't using the code from the more restrictive GPLv2 components. Personally, I would make it a configure time option to specify which library MyServer links to, if that is applicable in this case. That makes it a little more clear that MyServer and MyLib are distinct components. Putting them in separate repositories may also help prevent any confusion or contamination.

UDPATE

MyServer compiles server.c and network_stack.c into an executable. [note: depends on a GPLv2 project] This executable uses headers from MyLib and links to it. On MacOS builds it links statically. On Windows and Linux it links dynamically. MyLib is irrefutably a distinct component. It's still very confusing what the distinctions are between GPL compliance as a project that's broken into several components, and creating a binary release of the project. Does the GPL "infect" MyLib even if someone rips it out and uses it in a separate project, or only if they're building/releasing MyServer with MyLib as a component?

NB: there is no "infection" in the GPL. There are permissions and conditions instead. The same way that when you buy a commercial license for a proprietary ware, this does not "infect" your wallet: it only makes it lighter ;)

Things are therefore simple: whether this is dynamic or static linking does not matter to the GPL. Whether MyLib shared library is build as a distinct component does not matter either.

What matters is that MyServer and MyLib collectively depend on a GPL-licensed component that will run in the same process at run time and therefore the GPL applies to this runtime combo.

When used separately and without this GPL dependenency, the GPL does not apply.