I have the following scenario:

  • A software vendor wants to distribute their own commercial software (S1).
  • S1 relies heavily on a third party GPLv2-licensed software (S2) to function. But:
    • They DO NOT modify S2.
    • They DO NOT link S2 (as in a binary-linked library).
    • They DO interact with S2 by configuring it for their needs, running it, and interfacing with it (as in, specifically: S1 invokes S2 via REST APIs, and I guess also takes care of bootstrapping it).
    • They would like to package S1 with S2 in a single software package.
  • This a B2B model, in that this vendor's customers, buying S1, would then allow their end-users/customers to use S1 (which itself uses S2 in the background).

So, it's a model this whole software package contains 2 stand-alone apps, where one relies on the other as a back-end.


  • I make no claims as to whether S1 is also open source or not for now, that's also what I want to determine via the possible options explained later below.
  • By "distribute", I mean here 2 possibilities:
    • sell and offer for electronic download,
    • sell and provide everything already ready on a set-top box system (secondary option though, not the one I'm most interested in for now).


My understanding is that, as S2 is GPLv2-licensed, and they want to distribute S2 with their S1 software, the following options would be acceptable. Please confirm and let me know if that's correct or what would be the recommended approach.

Option 1 - Licence S1 with a GPLv2 compatible license and package both

They decide to package and distribute S2 with their software. As a result, as per GPLv2's terms, S1 has to be distributed with a GPLv2-compatible license.

Also, the vendor needs to distribute both S1's source and S2's source with the package. (Or make it clearly available with visible preambles?)

Follow-up question in this option: what GPLv2-compatible licence would you recommend here?

Option 2 - License S1 as you please and do not package and distribute with S2

The vendor keeps S1 closed-source, and they do not distribute S2 with their software package. The vendors customers have to take care of that themselves, or via an explicit action during installation.

My understanding is that, as S2 is not modified or distributed, this is also legally acceptable.

Option 3 - License S1 as you please and still package S2 with it?

Or I am completely wrong, and as S2 isn't modified, and S1 isn't linking to it as a binary, there are no needs to do this? This seems incorrect to me, as S2 would still be distributed and used, but on the other hand GPLv2 does allow commercial redistribution (and again, there's no modification). Is just providing S2's source all that is required.

Or any other possibility I've missed?

Hope this makes sense.

1 Answer 1


As S1 and S2 communicate over a REST interface (and thus a network connection), their communication is considered to be "at arms length." This means that S1 and S2 are considered independent works for copyright considerations and the GPL license of S2 does not affect S1.

Copyright is also independent of how you package a product or combination of products.

All of this means that you can use whatever license you like for S1 and sell the combination of S1 and S2. The only thing you can't do is restrict the GPL-based rights that your customers get on S2. Thus your customers must have the right to replace the S2 version they got from you with a different version.

  • Many thanks for your answer! And doesn't the fact that S1 bootstraps and starts S2 affect this? Technically it's just spawning a process, so I'd say it doesn't, but I wasn't sure.
    – haylem
    Jan 5, 2020 at 22:06
  • 1
    @haylem: No, the fact that S1 starts S2 does not affect that. It is the manner of communication that is decisive. Jan 6, 2020 at 8:42

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.