5

The closed source commercial software (CSCS), will just make system(3) calls to GPL applications.

The user machine will run CSCS and it will call these GPL applications, in realtime, in the very same way a user could use the command line and call the very same applications. Even a log of such actions could be provided, and user could replicate these actions manually.

In Java it would be like: Runtime.getRuntime().exec("echo Hello");
In C it would be like: system("echo Hello");

The point is, the CSCS is calling a GPL application to just generate realtime output, and in a predetermined way and hard coded on it, so CSCS depends on GPL app to work.

The GPL application is NOT a library. Is a regular command line application.

And, I am NOT going to distribute any GPL application (neither its sources) packaged together with CSCS. It will just depend that the OS have such GPL apps already installed. Also, CSCS can run with at least the version of the GPL application that was used in the development time (or newer), so it will NOT depend on a specific GPL app version to run.

1) Can the CSCS remain closed source on this sole specific situation?

2) Or should CSCS only use statically generated output from GPL applications, being prevented to use them in realtime, if it wants to remain closed source?

3) Alternatively could be created a LGPL software composed by scripts like ls -l $1 whose parameters would be dynamic data provided by any application including this CSCS. In this case, all the logic of these scripts would be exposed and reusable by anyone, therefore not proprietary. So, such "protocols" would all be LGPL. Can that be done? Or this would simply fall under something like indirect use of GPL sofware, and so GPL would infect every application using it (including this very LGPL software, forcing it to become GPL)?

I would appreciate also excerpts confirming the answer, thanks!

PS.: I have read this Can I use GPL software in a commercial application, and it doesnt seem to answer my specific question.
And, I need to know this before I can consider any kind of realtime GPL application usage on my software.

Linking: https://softwareengineering.stackexchange.com/a/161938/112610
I was unable to avoid linking this: https://meta.stackexchange.com/a/91116/222324
Another Link: https://softwareengineering.stackexchange.com/a/211357/112610

Obs.: (2 days after, considering all commented tips and answers) These may contain the answer:
A) I think this very question could actually be "What is a GPL derived work?" considering the "Networked Systems" section.
B) See "Mere Aggregation" in the GPL FAQ "pipes, sockets and command-line arguments are communication mechanisms".

PS.2: just as a final disclaimer, we all here seem to not be lawyers, and even if you do it all correct in this line, and even if you are sure of your license interpretations, something you do not expect may happen, https://softwareengineering.stackexchange.com/a/158925/112610

Community
  • 1
Aquarius Power
  • 361
  • 1
    Ask your lawyer, or perhaps the author of the GPL application. And define what you mean by "system calls": syscalls(2) or system(3) ? Also, what exact GPL applications are you using and how? What is your CSCS? So please edit your question (which is off-topic or borderline here) to improve it – Basile Starynkevitch Dec 14 '14 at 19:08
  • 1
    Be aware that in Linux e.g. the system-call-interface is a public API and a licence-barrier. – Deduplicator Dec 14 '14 at 19:11
  • @Deduplicator are you speaking about system(3) ? or both? – Aquarius Power Dec 14 '14 at 19:22
  • 1
    Even after the edit, you don't explain what GPL software is invoked with system(3) and what is your program doing. Is the "protocol" between them specific to your application or not? – Basile Starynkevitch Dec 14 '14 at 19:24
  • @AquariusPower: It means that the licence covering the kernel does not reflect upon the valid licences for user-space. It does not mean that two programs used with that API are not dependent works. The question is, what kind of interface of the GPL-program are you using? – Deduplicator Dec 14 '14 at 19:28
  • @BasileStarynkevitch that is the problem... I need to know what I can do, after that I will consider if I can use GPL apps system(3) calls... So, I was thinking on using ls that is from coreutils, and is GPL. It doesnt matter alternatives to it, it just matter if I can use it or not, becase, based on that I will know if I can use other GPL applications too. But for this example, I could use the output generated by ls -l to gather the filenames and create a list on the screen in columns, the same way ls -l shows, but actually editable. Should I put this example there? – Aquarius Power Dec 14 '14 at 19:29
  • I am not a lawyer, but IIRC there have been lawsuits when the protocol between the two apps (a GPL one + a proprietary one) was deemed proprietary and ad-hoc. You should consult a lawyer. – Basile Starynkevitch Dec 14 '14 at 19:31
  • 1
    And if only using ls, just use stat & readdir syscalls instead. Or consider making all your application as GPLv3 free software – Basile Starynkevitch Dec 14 '14 at 19:34
  • @Deduplicator I think, the interface you are referring to is the command line interface, like ls -l – Aquarius Power Dec 14 '14 at 19:35
  • @BasileStarynkevitch that is what I want to avoid by providing an specific example, because tomorrow I may want to use another GPL command line call and would have to ask again :(, but I may edit my question if it is required and specify to ppl not provide specific answers based on that example may be? – Aquarius Power Dec 14 '14 at 19:36
  • @BasileStarynkevitch, about proprietary protocol (I think I could call it "the command line with parameters"). Could I create a LGPL software composed by scripts like ls -l $1 whose parameters would be dynamic data provided by any aplication including this CSCS. In this case, all the logic of these scripts would be exposed and reusable by anyone, therefore not proprietary. So, such "protocols" would all be LGPL. Can that be done? Or this would simply fall under something like indirect use of GPL sofware, and so GPL would infect every application using it? – Aquarius Power Dec 14 '14 at 20:05
  • Again, I am not a lawyer. Please consult your lawyer, or at least a free software organization. – Basile Starynkevitch Dec 14 '14 at 20:07
  • @BasileStarynkevitch, do you think this question would fit better in another stackexchange site as it may not be a specific programming question? I have no money for a lawyer yet, that is why I need (I think I need) a closed source to generate income enough and not have a boss.. :(. I will try to contact the free software foundation or the GPL ppl and see if they can look at this question, thanks on that tip! if someone really knows that, it is them!! – Aquarius Power Dec 14 '14 at 20:12
  • Note that the issue isn't about using, it is about distributing (that's what copyright control). If you don't distribute things for which you don't hold the copyright (you probably won't for ls), you are save from copyright infringement – AProgrammer Dec 14 '14 at 21:32
  • @AProgrammer, the whole point is to distribute, so I can actually sell it. If I created myself a code that looks like ls -l 123 $1, I am distributing the code I created, not the ls application. My concern is, by calling from within my code, a GPL application to it dynamically generate an output in realtime on user's machine, am I forced to release my software source code freely? what would actually prevent me from making income as soon someone sells it too.. :(. Dang... if I won lottery I would just make my project for free, GPL, til then I dont want to have a boss so it must be CSCS... – Aquarius Power Dec 14 '14 at 22:22
  • You can depend on GPLed code as much as you want as long as you don't distribute GPLed code. If you don't distribute ls, your application can depend on it. If you distribute ls, then things become muddy and I'd strongly suggest lawyer advice. – AProgrammer Dec 15 '14 at 12:07
  • @AProgrammer, very interesting. No I wont (and know I know I must never) distribute ls, and dont even touch its code; I just updated my question, thx. – Aquarius Power Dec 15 '14 at 16:08

2 Answers2

7

This situation is covered in the GNU GPL FAQ, in the section "I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?"

in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

Community
  • 1
Philipp
  • 23,306
  • [bash here is just to exemplify, it could be any other GPL application] that means that, for ex.: as bash is GPL, any bash script (that depends 100% on bash to run), must be released as GPL? also, /bin/bash application is and will continue being a single application on itself that can run independently of myApplication, I did not modify bash to depend on myApplication to run; but.. myApplication, will only be a runnable application if bash is present, that makes bash+myApplication a single application? or just makes myApplication a broken one? because bash could not be present? – Aquarius Power Dec 15 '14 at 00:36
  • so in short: by depending on bash to run, myApplication must be GPL too? – Aquarius Power Dec 15 '14 at 00:38
  • 1
    "if the two programs are combined so that they become effectively two parts of one program", well, myApplication will do the combining step, making myApplication+bash one application, and so myApplication must be GPL, or am I wrong? – Aquarius Power Dec 15 '14 at 00:43
  • In theory, one could write a bash clone under a different license, so it isn't strictly speaking true that bash scripts depend 100% on bash to run. – Gort the Robot Dec 15 '14 at 00:46
  • @StevenBurnap, I just found this that says exactly what you said. So, I would be coding in a language, but the interpreter license would not affect the code made in that language, as another equivalent interpreter could have other license. – Aquarius Power Dec 15 '14 at 00:53
  • @StevenBurnap, but in the moment I type on my script #!/bin/bash I state what interpreter, and therefore, what dependency, I am forcing my script to use (unless I make a symlink to the interpreter where I could use like #!/bin/bashInterpreter on my script, then it would be user's choice, not developer one) – Aquarius Power Dec 15 '14 at 00:55
  • @StevenBurnap, in the same way of thinking, if I use ls -l 123 $1, I could create a symlink and code listFiles -l 123 $1, that would work both with ls and another implementation created with another license. – Aquarius Power Dec 15 '14 at 00:58
  • @StevenBurnap but this all seems very similar to this talk where libnoreadline.a, as an alternative to libreadline.a, would still be forbidden if a choice to use libreadline.a was available... (despite it is not about libraries I am speaking here, it almost makes it work like a library does) – Aquarius Power Dec 15 '14 at 01:02
  • @AquariusPower, if you don't distribute bash, there is no problem in distributing a script which depend on bash with a license not compatible with the GPL. If you distribute both as a package, see a lawyer. The text cited in this answer hints that if the packaging make it clear that it is two different things -- and probably allows to use another version of bash easily --, the FSF does not consider it as infringement. How is that interpretation binding for them? I don't know. How is it binding for someone else who release GPLed software? my guess is not at all. – AProgrammer Dec 15 '14 at 12:18
  • @AProgrammer, I will not distribute bash,neither its source.I just updated my question;The problem I see now is,how to make it clear they are two different things if myApplication 100% depends on bash or ls realtime outputs/execution? yes,it allows to use other bash versions;any tip where FSF specifies that?because that excerpt from this answer seems to allow contrasting interpretations;and,at last,to call an application like it does in a command line, can have basically a final similar result of linking directly to its libraries, despite there is no linking, it could be clarified also. – Aquarius Power Dec 15 '14 at 16:26
  • @AProgrammer, it seems that, by NOT depending on a specific GPL app VERSION to run, clarifies that the two programs are actually separate ones, and so, they become separated enough. I just expect this is not another assumption of mine... – Aquarius Power Dec 15 '14 at 16:35
3

And, I am NOT going to distribute any GPL application (neither its sources) packaged together with CSCS.

Copyright controls who is allowed to distribute something, not who is allowed to use it. If you don't distribute the GPL application, you can't infringe copyright, even if you depend strongly on it.

Your user could infringe the conditions on which they got the application you use, but GPL does not include such clauses.

AProgrammer
  • 10,472
  • also, as an example, I just found this bash guide, there it says "When not to use shell scripts" -> "Proprietary, closed-source applications (Shell scripts put the source code right out in the open for all the world to see.)". So it basically says we should not create proprietary bash scripts for our algorithm safety, but it does NOT say that we cannot do it, that we are forbidden from doing it. – Aquarius Power Dec 15 '14 at 18:22
  • 1
    Copyright does not just protect distribution; making derivative works is one of the exclusive rights a copyright holder has. Whether this is a derivative work is a legal question (though the FSF doesn't seem to think so, and they're the ones most likely to want to enforce the GPL). – cpast Dec 16 '14 at 08:56
  • @cpast I found something that may be worth reading: http://en.wikibooks.org/wiki/FOSS_Licensing/How_to_Make_the_Source_Free_or_Open, look for "proprietary": "..and has source code from all three programs.", so what in case it has NOT source code from the GPL program? – Aquarius Power Dec 16 '14 at 20:03
  • I just thought also that, if a GPL program is prefered over a proprietary one to perform the same task (output), like I suggest in the question, that puts that GPL application above the proprietary one, what is actually good. But that is just a thought... – Aquarius Power Dec 16 '14 at 20:05
  • 1
    @AquariusPower Something could potentially be a derivative without including any source code whatsoever. Derivatives include copyrightable elements of the original work; everything hinges on what about software is copyrightable. There is an active court case in the US where a federal appeals court has ruled that APIs are copyrightable, for instance (the case is still ongoing, but the point is it's a question for lawyers). – cpast Dec 16 '14 at 20:16
  • @cpast, at the end it is always a question for laywers.. also "A GPL-ed program cannot be incorporated into a proprietary program", what exactly incorporated means? could the question subject be considered as "incorporated"? that dependency, could be seen as incorporated? even when the GPL application is not distributed together? – Aquarius Power Dec 16 '14 at 20:19
  • @AquariusPower By 'incorporated' they're referring to code that is copy/pasted from a GPL application into another or an application that is distributed with a library that came from GPL application. Unless, the library is licensed under LGPL. The same rule applies to media asstes, etc. You could, for instance, create a wrapper that extends a GPL application by wrapping/automating it's usage (ex GUI for FFMPEG) but the user would have to acquire the GPL application separately on their own since distribution is not allowed in that case. – Evan Plaice Dec 16 '14 at 21:39
  • @EvanPlaice and cpast, look at the end of my edited question; I think the "communication mechanisms" (or command line) makes the proprietary and the GPL, separate programs. – Aquarius Power Dec 16 '14 at 21:58
  • AProgrammer, I think the "networked systems" consideration, and at GPL FAQ where it speaks about "Mere Aggregation"; exerpts from these two could further reinforce your answer. – Aquarius Power Dec 16 '14 at 22:21