11

I have a program written in a shell language that consists of several shell script files. Some of these files execute external commands that have been licensed under GPL.

Do I have to release my shell scripts under GPL? Some sources I have read say no, because the external programs are external (separate) programs. However, I use the programs similarly to libraries in other programming languages. I know that there are eg. Java libraries that do the exact same thing.

I use many external programs, and most of them do file processing, eg. parse data and transfer it to a form that can be easily processed using shell scripts. Some of these external programs are also shell scripts, other are native programs.

|improve this question
  • Note that if even you where required to license your scripts under the GPL, you wouldn't need to release them. – PyRulez Nov 27 '17 at 7:04
  • @PyRulez I know. In this case I need to release the scripts. – fergusq Nov 27 '17 at 7:53
  • But if you release shell scripts the people legally getting them are practically able to read and study them, so in practice your question is not very useful (because shell scripts don't protect any secrets since they are visible by their users). – Basile Starynkevitch Nov 27 '17 at 8:23
  • 1
    BTW, you are seeking exact rules, but you should use common sense and take more time to understand the philosophy of free software. And you should also consider actively contributing to free software! – Basile Starynkevitch Nov 27 '17 at 8:31
16

The GPL is generally interpreted in a manner that licensing your scripts under the GPL would not be required.

The GPLv3 states that you have to license your code under the GPL if it were a “work based on the Program”, which is defined “to copy from or adapt all or part of the work in a fashion requiring copyright permission”. When a copyright violation would occur depends on your local jurisdiction. It is the opinion of the Free Software Foundation, i.e. the authors of the GPL, that:

We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file [or] are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

So normal shell scripting is entirely OK.

My (amateur) opinion is that this interpretation by the FSF is extremely conservative, and tends to over-estimate how coupled two programs would be. If you follow the quoted interpretation, you are likely to be on the safe side.

As an aside, you are never required to release your software under the GPL. You are always allowed to make private modifications that you do not distribute. However, if you wish to release a software that is based on GPL software, then you can only release it under the GPL, no other license.

|improve this answer
  • This is interesting... So calling a GPL'd bash script from a bash script is OK, but calling a Python script from a Python script, or a Java method from a Java method, is not? But if this is the interpretation of the FSF then I should probably trust it. – fergusq Nov 27 '17 at 7:49
  • No, your understanding is excessive – Basile Starynkevitch Nov 27 '17 at 8:13
  • The AGLP is for exactly such cases, especially with cases that use a webservice – Mafii Nov 27 '17 at 10:59
  • 1
    @Mafii: typo, you mean AGPL license. But I don't think that the OP wants to use it! – Basile Starynkevitch Nov 27 '17 at 11:07
  • 1
    @fergusq If you call a GPL Python script from a non-GPL Python script using exec, that is, launching a different interpreter with a different address space, then yes, that would be OK. If you use import or other means to run the two scripts inside the same interpreter, in the same address space, as a single program, then it's not ok. Meaning that if you ever release the second part, it would have to be GPL too. BTW, this makes me think that executing a GPL shell script from a non-GPL shell script would be OK, while sourcing or eval'ing it would not be ok. – Tobia Nov 27 '17 at 15:17
3

Let's say I write the following short script:

#!/bin/sh

cat -n "$1"

The POSIX standard does not define the -n option for cat, but it is supported by GNU cat. Does that mean I am using GPL code in my script? No. BSD cat also provides a -n option that behaves exactly the same, and as the user of your script I could ensure that cat refers to the BSD version.

In the end, your shell script does not include, provide, or even require GPL code; it just relies on behavior that is provided by, but is not exclusive to, a GPL implementation of cat.

|improve this answer
  • This reasoning does not work in general. Replace #!/bin/sh with #include <stdio.h> and replace cat with printf("%s", "foo");. If you include standard library code to compile that program, you will need to consider its license. Of course, glibc makes a specific exception to allow linking like this without needing to have your own program GPL'ed, but it depends on which library you use/redistribute. Also you didn't say whether you are including the GPL implementation of 'cat' in your example. If you don't distribute the libraries and only use what's on the end system, there is no problem. – Brandin Nov 28 '17 at 13:51
  • #include again pulls in whatever file the user has installed on their system; it may or may not be GPL code and is beyond the control of the author. – chepner Nov 28 '17 at 13:54
  • (At least, #include <...> does; it would be poor form to replace such files with a distributed file. #include "..." typically installs files distributed with the code, in which case licensing issues would apply, but that is a matter of distribution, not the #include directive itself.) – chepner Nov 28 '17 at 14:01
2

Notice that shell scripts need (technically) to be released in (nearly) source form.

AFAIK you can write such a program (even some script) which uses GPL programs without being obliged to make your program GPL-ed.

In particular what matters is if the GPL program is tightly coupled to yours (generally not). This would be the case if it is practically meaningless to use that program without your script (which is unusual) .

To be more specific, the doctrine is that a GPL program A is tightly coupled to another program B if it does not make sense to use A outside of B or B without A. In that specific case B should be GPL-licensed too. In other words, coding willingly a GPL wrapper around/for a proprietary program (or vice versa) is considered "cheating" the free software license.

(IIRC, Sun tried such dirty tricks in the 1990s with an optimizing proprietary code generator above some patched GCC compiler, and that made the FSF and other free software enthusiasts angry. I forgot the legal details, and I am sympathetic with the FSF view).

In other words, it is well known that GPL libraries (there are few of them, a good example is readline; many free software libraries are using the LGPL license, different of the GPL license) can only be used from GPL compatible free software. And the doctrine is not that only a technical linking (in the Unix ld sense) is relevant, but more generally some tight "binding" or "coupling". So you cannot cheat by replacing that linking with a tight and specific RPCJSON protocol (to "mix" a proprietary program with a GPL library called from a serializing GPL-ed program).

However, I use the programs similarly to libraries in other programming languages.

So you are safe in using GPL programs from proprietary code when these GPL-ed programs can be meaningfully used without your code, which is generally the case. You are cheating if you write specifically some easy GPL program (e.g. forking some prior GPL software, or calling some GPL-ed library) to circumvent GPL obligations.

For example, you'll find quite easily many proprietary programs (e.g. IDEs) using git or GCC, because the same unmodified /usr/bin/git GPL-ed program (or /usr/bin/gcc, /usr/bin/g++ ....) can be meaningfully and easily used on the command line, or by other free software programs.

However, if you wrote a small GPL program which gives a specific JSONRPC protocol to call readline routines from your proprietary program using that protocol, the court (and the FSF, and me) is likely to consider that as an abuse of the GPL license of readline. You would be safer if you documented properly that protocol (which becomes some "public" or "common" good or knowledge) and wrote a meaningful GPL program using it (hence validating the idea that your protocol and your GPL program using that protocol have sense independently of your proprietary program).

A concrete example of (large, proprietary) shell scripts using GPL programs is provided by installers of proprietary graphics drivers for Linux from NVIDIA (or from ATI in the past). I was so pissed off by such proprietary drivers that I now boycott NVIDIA and use only AMD graphic cards with their free software drivers (even if the performance is slightly lower).

Some of these external programs are also shell scripts, other are native programs.

The fact that an executable file is in ELF format or is some shell (or other) script is irrelevant (also, the programming language used is not relevant). What matters is the (free software) license of the program or software.

IANAL

But I am not a lawyer. Feel free to ask one, or to ask some free software organization and read more carefully the GPL FAQ and take more time to understand the philosophy of free software.

|improve this answer
  • Isn't it the other way around, that it is meaningless to use my script without the program? These rules are very confusing... – fergusq Nov 27 '17 at 7:56
  • I don't understand what confuses you. Take some more time to read about free software (and try to understand the FSF point of view). Don't consider GPL-ed programs as mostly a threat to your proprietary interests. They are not, and they are useful by themselves. – Basile Starynkevitch Nov 27 '17 at 9:01
1

If you don't distribute the GPL programs together with the scripts, then I see nothing that will force upon you any licensing requirements.

Otherwise you may need to.

|improve this answer

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.