Wrapper library with MPL license vs. GPL

Hi,

I tried to look for an answer regarding this question but could not find a topic discussing it comprehensively.

For me, it is a bit unclear how the licensing goes when interfacing proprietary software with the GPL licensed WinSCP.exe through an MPL licensed wrapper library. In the set up, the interfaces communicate as below:

Proprietary module <=> winscpnet.dll (MPL) <=> WinSCP.exe (GPL)

When looking at the GPL terms, the latter part section 5 of GPL in my opinion states that if you distribute the combination of winscpnet.dll and WinSCP.exe somewhere, the both need to be licensed as GPL. https://www.gnu.org/licenses/gpl.html

"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."

As winscpnet.dll is an extension to WinSCP.exe, the combination of the two cannot be considered as an aggregate. Therefore 5 c) applies and winscpnet.dll is also GPL.

"c) 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. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it."

Whether GPL would now affect the proprietary module in the description above is in my opinion the question of whether we consider it as an extension to WinSCP or not. In my case the answer is not.

However, I am wondering what was the original purpose of licensing the winscpnet.dll under a separate MPL license? Can you shed light on that?

Br,
Toni

The WinSCP .NET assembly interacts with WinSCP binary only. It does not use WinSCP code in any way.
So it's not a compilation.
(Almost) no GPL limitation applies to WinSCP binary. You can use it as you please, as long as you keep a copy of the GPL license along.

I have updated documentation to cover this:
https://winscp.net/eng/docs/library#license

However, I am wondering what was the original purpose of licensing the winscpnet.dll under a separate MPL license? Can you shed light on that?

Well, to give more freedom to users of the library. The GPL is rather restrictive.

martin wrote:

The WinSCP .NET assembly interacts with WinSCP binary only. It does not use WinSCP code in any way.
So it's not a compilation.

Maybe you are using the word compilation with a different meaning here (referring the the compilation and linking process you do after you edit source code). Anyhow, according to the FAQ (https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic) it does not matter how you link the two modules. The two are still a compilation (i.e. a collection of two modules):

"Q: Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)
A: No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination."

So the only relevant thing in evaluating whether the GPL license applies to winscpnet.dll is whether winscpnet.dll is an extension to WinSCP.exe. Whether the code is compiled or whether wrapper uses binaries only, does not really matter.

And as winscpnet.dll is an extension to the covered work (WinSCP.exe), the GPL applies to both.

However, to my understanding another (proprietary) program might not be affected from GPL *if* it would not be considered as an extension to WinSCP.exe or winscpnet.dll and if it were not bundled together with WinSCP (clearly stating that these are separate applications).

But winscp.exe is NOT A LIBRARY/MODULE, it's an APPLICATION. No linking, neither static nor dynamic happens.

It is the same as, as if you asked anyone, who calls a GPL command-line tool from a batch file/script, to GPL that batch file on the grounds that the batch file "links" the tool.

I did not realize the communication between the wrapper and WinSCP happens through command line interface. I guess that's what you were trying to say when talking about interacting in "binary form" (when doing normal linking, the dll's and exe's are also in binary form, right?)

However, I think it is important to realize that the interaction mechanism merely does not dictate whether we consider the software an aggregate of two programs or not. See GPL faq here: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
"Where's the line between two separate programs, and one program with two parts? 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."

So even though two programs would be communicating through CLI, they still can be considered one program because of the semantics of the communication. In this case, the wrapper is quite tightly tied to WinSCP (the wrapper needs to know how to parse the output from WinSCP etc.) so one could argue they are one program and GPL applies if you distribute the combination.

tonitoni wrote:

So even though two programs would be communicating through CLI, they still can be considered one program because of the semantics of the communication. In this case, the wrapper is quite tightly tied to WinSCP (the wrapper needs to know how to parse the output from WinSCP etc.) so one could argue they are one program and GPL applies if you distribute the combination.

Well, I'm not a lawyer.

But historically, there was first the CLI interface (since 2004):
https://winscp.net/eng/docs/scripting

Then we added an XML log output, so that people who automate CLI execution can reliably parse the results. The output is well documented since March 2009:
https://winscp.net/eng/docs/logging_xml

Then we provided a guide for developers on implementing XML logging parser (March 2011):
https://winscp.net/eng/docs/guide_interpreting_xml_log

And only after that we added the .NET assembly as an example implementation for the above guide (December 2011):
https://winscp.net/eng/docs/library

So, anyone, even without understanding of internal workings of the winscp.exe, can develop this on his/hers own, as there's a public well-documented CLI/XML interface (not a programming API).

The .NET assembly does not expose anything that is not readily available already. So I do not think it circumvents the GPL license anyhow. And it was definitely not our goal to do that.