I want to use the 7-Zip program to do some archive manipulation and creation.
I have an app that has a proprietary closed source license.
For this scenario, I would include the 7-Zip program in its entirety as a dependency of my application (bundled with the install), and call the application from my code via shell execution (e.g. CLI OS calls, not library imports into my source code natively).
I would use Node.JS to call the OS API to run 7-Zip's executable.
To the best of my knowledge this isn't statically or dynamically linked but I may be lacking in knowledge of this area.

Do I need to publish the part of my code that calls the external application because my app is using the external app?

1 Answer 1


7-zip is principally published under LGPLv2+, with an additional restriction relating to reimplementing the rar algorithm. As I read it, this additional restriction comes nowhere near affecting your proposed use of 7-zip. As a result, I don't think you have a problem, for two reasons.

Firstly, fork-and-exec is generally considered to keep your program far enough away from GPL (sic) code that the GPL's requirement to license your own code under it, as a derivative work, doesn't apply.

Secondly, the whole point of LGPL is to allow the use of covered code as a library module without that requirement applying to your code; so even if "fork-and-exec while passing a file name to compress/decompress" wasn't arms-length enough to avoid such a requirement, LGPL would except you from it.

LGPL does still have some requirements. You're required to be clear about the LGPL status of 7-zip, to provide its source to your users on demand, and to allow your users to upgrade their installed version of 7-zip without breaking its interaction with your program (which, assuming 7-zip doesn't release any backwards-incompatible upgrades, fork-and-exec should make easy). Decide which version of LGPL you will be operating under, and read the license carefully. But my feeling is that, if you do that, you should be fine.

  • 4
    Perfect! This was just what I was looking for :-) Aug 11, 2022 at 13:20
  • 2
    presumably in "allow your users to upgrade..." you don't actually have to account for backwards-incompatible upgrades that 7-zip might make? (My reading of the license is that this is term 4d1 and that it wouldn't require you to cope with changes to the interface)
    – DavidW
    Aug 11, 2022 at 20:16
  • 3
    @DavidW that is my feeling, too, but I don't know of any jurisprudence on the matter.
    – MadHatter
    Aug 12, 2022 at 5:41
  • 3
    @DavidW: I would think that one's program should be designed to work with any program that behaves in the manner documented by the version of 7-Zip that one included. If future versions of 7-Zip meet that description, one should naturally be compatible with them without having to do anything, and if they don't meet that description, anyone wishing to use them with your program should be responsible for modifying them as needed to conform to the documentation supplied with your program.
    – supercat
    Aug 12, 2022 at 22:40
  • 1
    LGPL doesn't mention anything about "upgrading versions". You simply must allow people to re-build your executable using a different library that satisfies the same interface.... so basically 1) you must provide a way to re-build/re-link your executable with a different library and 2) you cannot perform checks on the linked library to restrict its usage.
    – Bakuriu
    Aug 13, 2022 at 8:10

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.