I have a closed-source C++ application that includes an embedded CPython interpreter. It ships with a directory full of example Python scripts that I wrote, which perform useful actions within the context of the application.

When the user clicks the "run script" button in the GUI, the C++ application launches a child process (via fork() and execvp() of its own executable), with special command line arguments telling it to run the CPython interpreter on the filepath of the appropriate .py file. The Python script then connects back to the parent process (via a local TCP connection) to interact with it.

My question is, if I include a GPL'd Python script in my directory of example scripts, am I violating the GPL? (I suspect yes, but given that I'd be including the source code of the GPL'd Python script in the distribution, and not linking it to any of the closed-source code, I'm not sure that it would be a violation)

  • 2
    Does your program need that particular Python script in order to function? If it is truly just an "Example" as you've suggested, it sounds like you are performing "mere aggregation", however as the FAQ answer mentions, it is hard to make a definitive answer: gnu.org/licenses/old-licenses/…
    – Brandin
    May 7 '19 at 5:32
  • The program functions fine without the Python script; however, this Python script would add a useful (in certain use-cases) mathematical function to the program that it wouldn't otherwise have. May 7 '19 at 5:33
  • This is going to be hard to give a straight answer to. See also these similar Questions: When must a project that uses GPL licensed projects use a GPL license? and Collective work using a GPL library
    – Brandin
    May 7 '19 at 6:56
  • Not mentioned in the other answers is what the author of that GPL program that you're distributing thinks. If he believes you violated his license by bundling his program with your closed source one in a way that seems to function as one program, he has the opportunity to challenge you (i.e. sue), and a court will need to decide. If you didn't distribute it, or if you bundle it in a way that is separated (e.g. in a similar way Linux distributions package third party programs) and very clearly make it a "mere aggregation" then he wouldn't have that opportunity.
    – Brandin
    May 7 '19 at 6:59

With respect to Brandin's comments above, I think this one's pretty cut-and-dried. It's known that the licence of a compiler doesn't transfer to its output, except in certain odd corner cases. If it's true for a compiler, it seems to me no different for a run-time interpreter. The FSF addresses the issue and reaches a similar conclusion, provided you are not sharing complex state sub rosa, or turning the functions provided by the GPLed code into library functions provided by your interpreter.

You do mention functions in one of your comments, but it's not clear if you're using the word precisely, to denote the creation of some kind of API to the GPL'ed code, or loosely, meaning that some of your scripts in turn call the GPL'ed script.

So: as long as it's the latter, I see this as no different from supplying a proprietary compiler with a bunch of proprietary sample source files, and one GPL'ed source file. As long as you are fulfilling the terms of the GPL with respect to the covered work, its appearance alongside the other programs in your package is "mere aggregation". As ever, though, IANAL/IANYL.

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.