Mixing
IPC between open-source and closed-source applications
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
We have two applications developed by two teams. One is open-source under GPL, another closed-source without any possibility to open the code.
Also there's a requirement to implement some kind of API between them, where open-source acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
However, what about IPC? Are there any precedents of exchanging queries and data between open- and closed-source applications using system-provided IPC, like pipes, shared memory or sockets? Should we prove someway that closed-source app just a service provider and loosely connected to open-source app?
UPDATE citation from GPL
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, not only way if communication, but is this communication "intimate enough". This is very vague term and could be used for speculations
licensing closed-source communication
asked 4 hours ago
Yuri S. Cherkasov
1063
New contributor
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
 |Â
show 1 more comment
up vote
1
down vote
favorite
We have two applications developed by two teams. One is open-source under GPL, another closed-source without any possibility to open the code.
Also there's a requirement to implement some kind of API between them, where open-source acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
However, what about IPC? Are there any precedents of exchanging queries and data between open- and closed-source applications using system-provided IPC, like pipes, shared memory or sockets? Should we prove someway that closed-source app just a service provider and loosely connected to open-source app?
UPDATE citation from GPL
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, not only way if communication, but is this communication "intimate enough". This is very vague term and could be used for speculations
licensing closed-source communication
asked 4 hours ago
Yuri S. Cherkasov
1063
New contributor
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Does the closed-source application depend on the GPL application in any way to fulfill its requirements? Or is the dependency only the other way around?
– Bart van Ingen Schenau
3 hours ago
It's hard to say how deep dependency is. Closed-source application is able to work without open-source so as open-source can work alone, but functionality of closed-source application could be described as "service provider", so it's useless without some client application, which is our open-source in our case (sorry for abstract terms)
– Yuri S. Cherkasov
3 hours ago
1
Related: Calling GPL'd programs from a shell script
– Brandin
1 hour ago
Is the IPC interface already present in the GPL'ed program, or do you plan to add this on to the GPL program (and of course make these changes available per the GPL)?
– Brandin
1 hour ago
Sure, it will require some changes in GPL application sources, and the client side code will be available as GPL requires, it would look like some advanced SQL query interface to the service. However, service side should stay closed
– Yuri S. Cherkasov
1 hour ago
 |Â
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
We have two applications developed by two teams. One is open-source under GPL, another closed-source without any possibility to open the code.
Also there's a requirement to implement some kind of API between them, where open-source acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
However, what about IPC? Are there any precedents of exchanging queries and data between open- and closed-source applications using system-provided IPC, like pipes, shared memory or sockets? Should we prove someway that closed-source app just a service provider and loosely connected to open-source app?
UPDATE citation from GPL
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, not only way if communication, but is this communication "intimate enough". This is very vague term and could be used for speculations
licensing closed-source communication
asked 4 hours ago
Yuri S. Cherkasov
1063
New contributor
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
We have two applications developed by two teams. One is open-source under GPL, another closed-source without any possibility to open the code.
Also there's a requirement to implement some kind of API between them, where open-source acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
However, what about IPC? Are there any precedents of exchanging queries and data between open- and closed-source applications using system-provided IPC, like pipes, shared memory or sockets? Should we prove someway that closed-source app just a service provider and loosely connected to open-source app?
UPDATE citation from GPL
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, not only way if communication, but is this communication "intimate enough". This is very vague term and could be used for speculations
licensing closed-source communication
licensing closed-source communication
asked 4 hours ago
Yuri S. Cherkasov
1063
New contributor
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
Yuri S. Cherkasov
1063
New contributor
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 50 mins ago
asked 4 hours ago
Yuri S. Cherkasov
1063
New contributor
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
Yuri S. Cherkasov
1063
asked 4 hours ago
Yuri S. Cherkasov
1063
1063
New contributor
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Yuri S. Cherkasov is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Does the closed-source application depend on the GPL application in any way to fulfill its requirements? Or is the dependency only the other way around?
– Bart van Ingen Schenau
3 hours ago
It's hard to say how deep dependency is. Closed-source application is able to work without open-source so as open-source can work alone, but functionality of closed-source application could be described as "service provider", so it's useless without some client application, which is our open-source in our case (sorry for abstract terms)
– Yuri S. Cherkasov
3 hours ago
1
Related: Calling GPL'd programs from a shell script
– Brandin
1 hour ago
Is the IPC interface already present in the GPL'ed program, or do you plan to add this on to the GPL program (and of course make these changes available per the GPL)?
– Brandin
1 hour ago
Sure, it will require some changes in GPL application sources, and the client side code will be available as GPL requires, it would look like some advanced SQL query interface to the service. However, service side should stay closed
– Yuri S. Cherkasov
1 hour ago
 |Â
show 1 more comment
Does the closed-source application depend on the GPL application in any way to fulfill its requirements? Or is the dependency only the other way around?
– Bart van Ingen Schenau
3 hours ago
It's hard to say how deep dependency is. Closed-source application is able to work without open-source so as open-source can work alone, but functionality of closed-source application could be described as "service provider", so it's useless without some client application, which is our open-source in our case (sorry for abstract terms)
– Yuri S. Cherkasov
3 hours ago
1
Related: Calling GPL'd programs from a shell script
– Brandin
1 hour ago
Is the IPC interface already present in the GPL'ed program, or do you plan to add this on to the GPL program (and of course make these changes available per the GPL)?
– Brandin
1 hour ago
Sure, it will require some changes in GPL application sources, and the client side code will be available as GPL requires, it would look like some advanced SQL query interface to the service. However, service side should stay closed
– Yuri S. Cherkasov
1 hour ago
Does the closed-source application depend on the GPL application in any way to fulfill its requirements? Or is the dependency only the other way around?
– Bart van Ingen Schenau
3 hours ago
Does the closed-source application depend on the GPL application in any way to fulfill its requirements? Or is the dependency only the other way around?
– Bart van Ingen Schenau
3 hours ago
It's hard to say how deep dependency is. Closed-source application is able to work without open-source so as open-source can work alone, but functionality of closed-source application could be described as "service provider", so it's useless without some client application, which is our open-source in our case (sorry for abstract terms)
– Yuri S. Cherkasov
3 hours ago
It's hard to say how deep dependency is. Closed-source application is able to work without open-source so as open-source can work alone, but functionality of closed-source application could be described as "service provider", so it's useless without some client application, which is our open-source in our case (sorry for abstract terms)
– Yuri S. Cherkasov
3 hours ago
1
1
Related: Calling GPL'd programs from a shell script
– Brandin
1 hour ago
Related: Calling GPL'd programs from a shell script
– Brandin
1 hour ago
Is the IPC interface already present in the GPL'ed program, or do you plan to add this on to the GPL program (and of course make these changes available per the GPL)?
– Brandin
1 hour ago
Is the IPC interface already present in the GPL'ed program, or do you plan to add this on to the GPL program (and of course make these changes available per the GPL)?
– Brandin
1 hour ago
Sure, it will require some changes in GPL application sources, and the client side code will be available as GPL requires, it would look like some advanced SQL query interface to the service. However, service side should stay closed
– Yuri S. Cherkasov
1 hour ago
Sure, it will require some changes in GPL application sources, and the client side code will be available as GPL requires, it would look like some advanced SQL query interface to the service. However, service side should stay closed
– Yuri S. Cherkasov
1 hour ago
 |Â
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
1
down vote
As the closed-source service provider does not depend on the GPL client (other than that the GPL client is currently the only known client application) or other GPL code, there is no GPL-related trigger to require opening up the source code for the service provider.1
For the GPL client application (and the interaction with the service provider), there are two options.
The easiest option is if the service provider offers a documented networked API. The client can implement its side of the API based on the documentation and there is no question about either the client or service provider being derived works of each other.
If the service provider is implemented as a library, you can add an additional permission to the GPL license to allow linking the GPL client code to this specific closed-source library. The GPL license explicitly allows this kind additional permission under section 7, but they can only be added by the original licensor of the code (the one who wrote the relevant code).
1: If this were not so, it would have been possible to force Microsoft to release the source code for MS-Word by simply writing a scrip around it that uses some features of MS-Word.
answered 45 mins ago
Bart van Ingen Schenau
4,579819
Do you mean GPLv2 section 7?
– Yuri S. Cherkasov
25 mins ago
You said "other than that the GPL client is currently the only known client application". This is the truth, open-source client is the first client of the service. We can provide well-documented IPC, we can provide IPC options (sockets, pipes, COM under Windows), we can create demo client application and even publish as a product. However, open-source application is the most useful client for that moment
– Yuri S. Cherkasov
12 mins ago
add a comment |Â
up vote
1
down vote
According to the GPL, you can distribute GPL programs together with closed source programs as long as the programs are separate. The GPL calls such a collection an "aggregate":
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate†if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Emphasis added. https://www.gnu.org/licenses/gpl-3.0.html
"I'm not linking with the GPL program; I'm just using sockets or IPC"
[We want] to implement some kind of API between [the GPL program and our closed-source app], where [the GPL program] acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
Conventional Internet wisdom on this topic seems to go something like this: "if you statically link with an LGPL program, your program must also be (L)GPL'ed. If you dynamically link with an LGPL program, your program can remain closed source. If you statically or dynamically link with a GPL program, your program must also be GPL'ed."
However, this is not at all what the GPL says and it is unlikely that a judge would see it this way if there is actually a legal dispute. Section 5 of the GPL covers your main obligation of what you must do when you distribute GPL programs:
You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.
Emphasis added. If the program is LGPL'ed, or if it is GPL with a linking exception, then there is extra language in the license which clarifies in what circumstances you are allowed to combine the program with yours, without needing to license your program in the same way. However, for the ordinary GPL, the above paragraph is what you need to scrutinize.
So the real question is whether your final product will ultimately be considered as one work or separate works. This is true whether your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or in some other way. The FSF tried to answer this in their FAQ:
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. 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, they are definitely combined in one program. If modules 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.
Emphasis added. https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what will actually be considered a combined work.
Rather than guessing what a judge may deicde, you should first think about how the copyright holder of the GPL program you are redistributing will interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."
From your description, it sounds like you already suspect that combining your closed source program with the GPL program may not be legally possible in the 'conventional' way (via static or dynamic linking), so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. Why is it a disadvantage to the GPL program's copyright holder? Because many software authors license their programs under the GPL specifically to encourage companies to do the same. I.e. "You may copy our code as long as you release yours as well."
On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source program is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.
Related questions and answers
Calling GPL'd programs from a shell script
What are the arguments for considering dynamic links to constitute derivative works?
answered 20 mins ago
Brandin
46938
I have an example. Let's say, Oracle added Hardening in Virtualbox, licensed under GPLv2, and this module is closed-source. As it's security-related, I suppose communication between them is "quite intimate". Also they package it as a single application. How did they manage to do that?
– Yuri S. Cherkasov
38 secs ago
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
As the closed-source service provider does not depend on the GPL client (other than that the GPL client is currently the only known client application) or other GPL code, there is no GPL-related trigger to require opening up the source code for the service provider.1
For the GPL client application (and the interaction with the service provider), there are two options.
The easiest option is if the service provider offers a documented networked API. The client can implement its side of the API based on the documentation and there is no question about either the client or service provider being derived works of each other.
If the service provider is implemented as a library, you can add an additional permission to the GPL license to allow linking the GPL client code to this specific closed-source library. The GPL license explicitly allows this kind additional permission under section 7, but they can only be added by the original licensor of the code (the one who wrote the relevant code).
1: If this were not so, it would have been possible to force Microsoft to release the source code for MS-Word by simply writing a scrip around it that uses some features of MS-Word.
answered 45 mins ago
Bart van Ingen Schenau
4,579819
Do you mean GPLv2 section 7?
– Yuri S. Cherkasov
25 mins ago
You said "other than that the GPL client is currently the only known client application". This is the truth, open-source client is the first client of the service. We can provide well-documented IPC, we can provide IPC options (sockets, pipes, COM under Windows), we can create demo client application and even publish as a product. However, open-source application is the most useful client for that moment
– Yuri S. Cherkasov
12 mins ago
add a comment |Â
up vote
1
down vote
As the closed-source service provider does not depend on the GPL client (other than that the GPL client is currently the only known client application) or other GPL code, there is no GPL-related trigger to require opening up the source code for the service provider.1
For the GPL client application (and the interaction with the service provider), there are two options.
The easiest option is if the service provider offers a documented networked API. The client can implement its side of the API based on the documentation and there is no question about either the client or service provider being derived works of each other.
If the service provider is implemented as a library, you can add an additional permission to the GPL license to allow linking the GPL client code to this specific closed-source library. The GPL license explicitly allows this kind additional permission under section 7, but they can only be added by the original licensor of the code (the one who wrote the relevant code).
1: If this were not so, it would have been possible to force Microsoft to release the source code for MS-Word by simply writing a scrip around it that uses some features of MS-Word.
answered 45 mins ago
Bart van Ingen Schenau
4,579819
Do you mean GPLv2 section 7?
– Yuri S. Cherkasov
25 mins ago
You said "other than that the GPL client is currently the only known client application". This is the truth, open-source client is the first client of the service. We can provide well-documented IPC, we can provide IPC options (sockets, pipes, COM under Windows), we can create demo client application and even publish as a product. However, open-source application is the most useful client for that moment
– Yuri S. Cherkasov
12 mins ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
As the closed-source service provider does not depend on the GPL client (other than that the GPL client is currently the only known client application) or other GPL code, there is no GPL-related trigger to require opening up the source code for the service provider.1
For the GPL client application (and the interaction with the service provider), there are two options.
The easiest option is if the service provider offers a documented networked API. The client can implement its side of the API based on the documentation and there is no question about either the client or service provider being derived works of each other.
If the service provider is implemented as a library, you can add an additional permission to the GPL license to allow linking the GPL client code to this specific closed-source library. The GPL license explicitly allows this kind additional permission under section 7, but they can only be added by the original licensor of the code (the one who wrote the relevant code).
1: If this were not so, it would have been possible to force Microsoft to release the source code for MS-Word by simply writing a scrip around it that uses some features of MS-Word.
answered 45 mins ago
Bart van Ingen Schenau
4,579819
As the closed-source service provider does not depend on the GPL client (other than that the GPL client is currently the only known client application) or other GPL code, there is no GPL-related trigger to require opening up the source code for the service provider.1
For the GPL client application (and the interaction with the service provider), there are two options.
The easiest option is if the service provider offers a documented networked API. The client can implement its side of the API based on the documentation and there is no question about either the client or service provider being derived works of each other.
If the service provider is implemented as a library, you can add an additional permission to the GPL license to allow linking the GPL client code to this specific closed-source library. The GPL license explicitly allows this kind additional permission under section 7, but they can only be added by the original licensor of the code (the one who wrote the relevant code).
1: If this were not so, it would have been possible to force Microsoft to release the source code for MS-Word by simply writing a scrip around it that uses some features of MS-Word.
answered 45 mins ago
Bart van Ingen Schenau
4,579819
answered 45 mins ago
Bart van Ingen Schenau
4,579819
answered 45 mins ago
Bart van Ingen Schenau
4,579819
answered 45 mins ago
Bart van Ingen Schenau
4,579819
4,579819
Do you mean GPLv2 section 7?
– Yuri S. Cherkasov
25 mins ago
You said "other than that the GPL client is currently the only known client application". This is the truth, open-source client is the first client of the service. We can provide well-documented IPC, we can provide IPC options (sockets, pipes, COM under Windows), we can create demo client application and even publish as a product. However, open-source application is the most useful client for that moment
– Yuri S. Cherkasov
12 mins ago
add a comment |Â
Do you mean GPLv2 section 7?
– Yuri S. Cherkasov
25 mins ago
You said "other than that the GPL client is currently the only known client application". This is the truth, open-source client is the first client of the service. We can provide well-documented IPC, we can provide IPC options (sockets, pipes, COM under Windows), we can create demo client application and even publish as a product. However, open-source application is the most useful client for that moment
– Yuri S. Cherkasov
12 mins ago
Do you mean GPLv2 section 7?
– Yuri S. Cherkasov
25 mins ago
Do you mean GPLv2 section 7?
– Yuri S. Cherkasov
25 mins ago
You said "other than that the GPL client is currently the only known client application". This is the truth, open-source client is the first client of the service. We can provide well-documented IPC, we can provide IPC options (sockets, pipes, COM under Windows), we can create demo client application and even publish as a product. However, open-source application is the most useful client for that moment
– Yuri S. Cherkasov
12 mins ago
You said "other than that the GPL client is currently the only known client application". This is the truth, open-source client is the first client of the service. We can provide well-documented IPC, we can provide IPC options (sockets, pipes, COM under Windows), we can create demo client application and even publish as a product. However, open-source application is the most useful client for that moment
– Yuri S. Cherkasov
12 mins ago
add a comment |Â
up vote
1
down vote
According to the GPL, you can distribute GPL programs together with closed source programs as long as the programs are separate. The GPL calls such a collection an "aggregate":
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate†if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Emphasis added. https://www.gnu.org/licenses/gpl-3.0.html
"I'm not linking with the GPL program; I'm just using sockets or IPC"
[We want] to implement some kind of API between [the GPL program and our closed-source app], where [the GPL program] acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
Conventional Internet wisdom on this topic seems to go something like this: "if you statically link with an LGPL program, your program must also be (L)GPL'ed. If you dynamically link with an LGPL program, your program can remain closed source. If you statically or dynamically link with a GPL program, your program must also be GPL'ed."
However, this is not at all what the GPL says and it is unlikely that a judge would see it this way if there is actually a legal dispute. Section 5 of the GPL covers your main obligation of what you must do when you distribute GPL programs:
You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.
Emphasis added. If the program is LGPL'ed, or if it is GPL with a linking exception, then there is extra language in the license which clarifies in what circumstances you are allowed to combine the program with yours, without needing to license your program in the same way. However, for the ordinary GPL, the above paragraph is what you need to scrutinize.
So the real question is whether your final product will ultimately be considered as one work or separate works. This is true whether your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or in some other way. The FSF tried to answer this in their FAQ:
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. 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, they are definitely combined in one program. If modules 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.
Emphasis added. https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what will actually be considered a combined work.
Rather than guessing what a judge may deicde, you should first think about how the copyright holder of the GPL program you are redistributing will interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."
From your description, it sounds like you already suspect that combining your closed source program with the GPL program may not be legally possible in the 'conventional' way (via static or dynamic linking), so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. Why is it a disadvantage to the GPL program's copyright holder? Because many software authors license their programs under the GPL specifically to encourage companies to do the same. I.e. "You may copy our code as long as you release yours as well."
On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source program is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.
Related questions and answers
Calling GPL'd programs from a shell script
What are the arguments for considering dynamic links to constitute derivative works?
answered 20 mins ago
Brandin
46938
I have an example. Let's say, Oracle added Hardening in Virtualbox, licensed under GPLv2, and this module is closed-source. As it's security-related, I suppose communication between them is "quite intimate". Also they package it as a single application. How did they manage to do that?
– Yuri S. Cherkasov
38 secs ago
add a comment |Â
up vote
1
down vote
According to the GPL, you can distribute GPL programs together with closed source programs as long as the programs are separate. The GPL calls such a collection an "aggregate":
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate†if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Emphasis added. https://www.gnu.org/licenses/gpl-3.0.html
"I'm not linking with the GPL program; I'm just using sockets or IPC"
[We want] to implement some kind of API between [the GPL program and our closed-source app], where [the GPL program] acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
Conventional Internet wisdom on this topic seems to go something like this: "if you statically link with an LGPL program, your program must also be (L)GPL'ed. If you dynamically link with an LGPL program, your program can remain closed source. If you statically or dynamically link with a GPL program, your program must also be GPL'ed."
However, this is not at all what the GPL says and it is unlikely that a judge would see it this way if there is actually a legal dispute. Section 5 of the GPL covers your main obligation of what you must do when you distribute GPL programs:
You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.
Emphasis added. If the program is LGPL'ed, or if it is GPL with a linking exception, then there is extra language in the license which clarifies in what circumstances you are allowed to combine the program with yours, without needing to license your program in the same way. However, for the ordinary GPL, the above paragraph is what you need to scrutinize.
So the real question is whether your final product will ultimately be considered as one work or separate works. This is true whether your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or in some other way. The FSF tried to answer this in their FAQ:
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. 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, they are definitely combined in one program. If modules 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.
Emphasis added. https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what will actually be considered a combined work.
Rather than guessing what a judge may deicde, you should first think about how the copyright holder of the GPL program you are redistributing will interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."
From your description, it sounds like you already suspect that combining your closed source program with the GPL program may not be legally possible in the 'conventional' way (via static or dynamic linking), so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. Why is it a disadvantage to the GPL program's copyright holder? Because many software authors license their programs under the GPL specifically to encourage companies to do the same. I.e. "You may copy our code as long as you release yours as well."
On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source program is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.
Related questions and answers
Calling GPL'd programs from a shell script
What are the arguments for considering dynamic links to constitute derivative works?
answered 20 mins ago
Brandin
46938
I have an example. Let's say, Oracle added Hardening in Virtualbox, licensed under GPLv2, and this module is closed-source. As it's security-related, I suppose communication between them is "quite intimate". Also they package it as a single application. How did they manage to do that?
– Yuri S. Cherkasov
38 secs ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
According to the GPL, you can distribute GPL programs together with closed source programs as long as the programs are separate. The GPL calls such a collection an "aggregate":
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate†if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Emphasis added. https://www.gnu.org/licenses/gpl-3.0.html
"I'm not linking with the GPL program; I'm just using sockets or IPC"
[We want] to implement some kind of API between [the GPL program and our closed-source app], where [the GPL program] acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
Conventional Internet wisdom on this topic seems to go something like this: "if you statically link with an LGPL program, your program must also be (L)GPL'ed. If you dynamically link with an LGPL program, your program can remain closed source. If you statically or dynamically link with a GPL program, your program must also be GPL'ed."
However, this is not at all what the GPL says and it is unlikely that a judge would see it this way if there is actually a legal dispute. Section 5 of the GPL covers your main obligation of what you must do when you distribute GPL programs:
You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.
Emphasis added. If the program is LGPL'ed, or if it is GPL with a linking exception, then there is extra language in the license which clarifies in what circumstances you are allowed to combine the program with yours, without needing to license your program in the same way. However, for the ordinary GPL, the above paragraph is what you need to scrutinize.
So the real question is whether your final product will ultimately be considered as one work or separate works. This is true whether your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or in some other way. The FSF tried to answer this in their FAQ:
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. 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, they are definitely combined in one program. If modules 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.
Emphasis added. https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what will actually be considered a combined work.
Rather than guessing what a judge may deicde, you should first think about how the copyright holder of the GPL program you are redistributing will interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."
From your description, it sounds like you already suspect that combining your closed source program with the GPL program may not be legally possible in the 'conventional' way (via static or dynamic linking), so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. Why is it a disadvantage to the GPL program's copyright holder? Because many software authors license their programs under the GPL specifically to encourage companies to do the same. I.e. "You may copy our code as long as you release yours as well."
On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source program is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.
Related questions and answers
Calling GPL'd programs from a shell script
What are the arguments for considering dynamic links to constitute derivative works?
answered 20 mins ago
Brandin
46938
According to the GPL, you can distribute GPL programs together with closed source programs as long as the programs are separate. The GPL calls such a collection an "aggregate":
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate†if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Emphasis added. https://www.gnu.org/licenses/gpl-3.0.html
"I'm not linking with the GPL program; I'm just using sockets or IPC"
[We want] to implement some kind of API between [the GPL program and our closed-source app], where [the GPL program] acts more like a client, so closed-source app should provide an API. As far as I understand, implementing any program-level API like statically or dynamically linked library oblige to open service-providing application code.
Conventional Internet wisdom on this topic seems to go something like this: "if you statically link with an LGPL program, your program must also be (L)GPL'ed. If you dynamically link with an LGPL program, your program can remain closed source. If you statically or dynamically link with a GPL program, your program must also be GPL'ed."
However, this is not at all what the GPL says and it is unlikely that a judge would see it this way if there is actually a legal dispute. Section 5 of the GPL covers your main obligation of what you must do when you distribute GPL programs:
You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.
Emphasis added. If the program is LGPL'ed, or if it is GPL with a linking exception, then there is extra language in the license which clarifies in what circumstances you are allowed to combine the program with yours, without needing to license your program in the same way. However, for the ordinary GPL, the above paragraph is what you need to scrutinize.
So the real question is whether your final product will ultimately be considered as one work or separate works. This is true whether your product is packaged as two executables that use IPC with each other, or one executable plus some DLLs, one executable with statically linked code, or in some other way. The FSF tried to answer this in their FAQ:
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. 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, they are definitely combined in one program. If modules 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.
Emphasis added. https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
Note that this explanation is from the FAQ, not the GPL itself. The FAQ also explicitly says that it is an unanswered question as to what will actually be considered a combined work.
Rather than guessing what a judge may deicde, you should first think about how the copyright holder of the GPL program you are redistributing will interpret what you've done. If the copyright holder considers that your product is an entire work combined with his, and sees that you have not fulfilled your license obligations by releasing your source code as well, he has a copyright infringement claim against you and could take legal action. Then you will be in the position of needing to convince a judge that you were allowed to do what you did. In the worst case, you may even be ordered to release your source code, despite your claim that "[there is] no possibility to open [our] code."
From your description, it sounds like you already suspect that combining your closed source program with the GPL program may not be legally possible in the 'conventional' way (via static or dynamic linking), so you are looking for a workaround. If your workaround is to first add on an IPC interface to the GPL program, then add on a compatible IPC interface to your closed source program, then package them together and ship it to customers as a product and say actually, these are two separate programs, so we don't need to supply you the source code to our closed source part, that would not look good to me. It would look like you are purposefully trying to circumvent the license requirements of the GPL program to your own advantage and the disadvantage of the copyright holder of the GPL program. Why is it a disadvantage to the GPL program's copyright holder? Because many software authors license their programs under the GPL specifically to encourage companies to do the same. I.e. "You may copy our code as long as you release yours as well."
On the other hand, if the GPL program already has an IPC interface, and the copyright holder intends for it to be used as a service to other programs via an IPC mechanism, and you are simply using this program in the way it was intended to be used by calling it from a separate program, you can make a good case that they are in fact separate programs and constitute a "mere aggregation" as defined by the GPL. Commercial Linux distributors do this, for example, when they distribute closed source programs for Linux in combination with the Linux kernel itself, although Linux is GPL licensed. Note that the communication between an application and an operating system kernel can actually be quite intimate, but operating system kernels in general and Linux in particular was designed to supply such services to other programs; no one is claiming that a closed source program is a combined work of Linux or "by its nature an extension of [Linux]" simply because it runs under Linux and/or because it performs intimate communication with Linux.
Related questions and answers
Calling GPL'd programs from a shell script
What are the arguments for considering dynamic links to constitute derivative works?
answered 20 mins ago
Brandin
46938
edited 5 mins ago
answered 20 mins ago
Brandin
46938
answered 20 mins ago
Brandin
46938
answered 20 mins ago
Brandin
46938
46938
I have an example. Let's say, Oracle added Hardening in Virtualbox, licensed under GPLv2, and this module is closed-source. As it's security-related, I suppose communication between them is "quite intimate". Also they package it as a single application. How did they manage to do that?
– Yuri S. Cherkasov
38 secs ago
add a comment |Â
I have an example. Let's say, Oracle added Hardening in Virtualbox, licensed under GPLv2, and this module is closed-source. As it's security-related, I suppose communication between them is "quite intimate". Also they package it as a single application. How did they manage to do that?
– Yuri S. Cherkasov
38 secs ago
I have an example. Let's say, Oracle added Hardening in Virtualbox, licensed under GPLv2, and this module is closed-source. As it's security-related, I suppose communication between them is "quite intimate". Also they package it as a single application. How did they manage to do that?
– Yuri S. Cherkasov
38 secs ago
I have an example. Let's say, Oracle added Hardening in Virtualbox, licensed under GPLv2, and this module is closed-source. As it's security-related, I suppose communication between them is "quite intimate". Also they package it as a single application. How did they manage to do that?
– Yuri S. Cherkasov
38 secs ago
add a comment |Â
Yuri S. Cherkasov is a new contributor. Be nice, and check out our Code of Conduct.
Yuri S. Cherkasov is a new contributor. Be nice, and check out our Code of Conduct.
Yuri S. Cherkasov is a new contributor. Be nice, and check out our Code of Conduct.
Yuri S. Cherkasov is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fopensource.stackexchange.com%2fquestions%2f7492%2fipc-between-open-source-and-closed-source-applications%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Does the closed-source application depend on the GPL application in any way to fulfill its requirements? Or is the dependency only the other way around?
– Bart van Ingen Schenau
3 hours ago
It's hard to say how deep dependency is. Closed-source application is able to work without open-source so as open-source can work alone, but functionality of closed-source application could be described as "service provider", so it's useless without some client application, which is our open-source in our case (sorry for abstract terms)
– Yuri S. Cherkasov
3 hours ago
1
Related: Calling GPL'd programs from a shell script
– Brandin
1 hour ago
Is the IPC interface already present in the GPL'ed program, or do you plan to add this on to the GPL program (and of course make these changes available per the GPL)?
– Brandin
1 hour ago
Sure, it will require some changes in GPL application sources, and the client side code will be available as GPL requires, it would look like some advanced SQL query interface to the service. However, service side should stay closed
– Yuri S. Cherkasov
1 hour ago