Symfony's views on the GPL

[Paul Boddie]

On Thursday 24. September 2015 14.58.20 Jann Eike Kruse wrote:
> 
> You're right, let's talk about "derivative works".
> Let's consider the following simplified, but very common and typical
> scenario:
> 
> Say, I have programmed one PHP script (myApp.php), which calls another
> PHP script (gplSort.php) in order to sort some values in a database. I
> put myApp.php and my COPYING.txt and gplSort.php and the GPLv3.txt in a
> ZIP file and sell it on USB sticks as SuperMineTM.
> 
> Central questions: A) Is SuperMineTM a derivative work of gplSort.php?
> B) Is SuperMineTM a bundle of two software packages "myApp" and "gplSort"?

There will be people on this list who are better qualified than I am to 
comment on this. However, it is always illustrative to consider the running 
program when trying to determine what is affected by which licence...

> Case A: myApp.php would have to be (when released to the public) under
> the same (GPL) license as gplSort.php.
> Case B: If myApp.php is considered to be a work independent from
> gplSort.php - then the choice of licence is up to me.

So, when someone receives SuperMineTM and deploys it, the running program will 
be your code (myApp.php), the GPL-licensed code (gplSort.php) and some other 
stuff (like the PHP runtime and so on, which we can ignore here for various 
reasons). The issue now is under what terms the recipient can distribute this 
to others.

For example, can they use some kind of convert-to-binary tool on myApp.php, 
perhaps after changing the code, and distribute the result? If they do this, 
does the person receiving it from them have the right to ask for the sources 
for this binary?

The way to think about this is to consider the intention of the person who 
wrote the GPL-licensed code. By using the GPL, it is as if they wished to only 
ever have their code incorporated into programs for which the sources would 
always be available. Thus, by using that GPL-licensed code, you are agreeing 
that if your code and their code show up in the same running program, you will 
also share your sources with the person running that program, too. And the 
same applies for anyone receiving the program under those terms.

So, if someone now takes your code, modifies it, makes a binary from it, and 
then gives it to someone else, and if that code uses gplSort.php when run, the 
person running the result has the right to ask for the sources that can be 
transformed to produce that running program. If the person making the binary-
only version does not provide the sources, then there is an argument that they 
violated the licence of gplSort.php because the complete source of the running 
program cannot be obtained by the recipient. In this case, gplSort.php may 
already be in source form, but there would be a binary blob corresponding to 
myApp.php that the recipient would not be able to properly understand.

This is where the "derivative works" aspect appears to enter the picture. Some 
might claim that myApp.php is not a derivative work of gplSort.php, but it is 
less about the status of that individual file and more about the status of the 
entire program. Some might also claim that myApp.php only uses gplSort.php but 
could use mitSort.php instead. Here, the GPL actually provides some 
flexibility: it merely requests that myApp.php be licensed under a GPL-
compatible licence, not necessarily the GPL itself, if myApp.php is ever to be 
used with gplSort.php [1].

Some might also claim that the mere presence of gplSort.php in a program 
should not affect the obligations on the authors of other parts of that 
program, particularly if those authors actually intended their code to run in 
a program based on mitSort.php instead. Here, Sam's observations about people 
doing what they like with copyrighted works in private seems to apply. Should 
anyone combining such code with gplSort.php realistically expect to demand 
sources from the authors of that code [2]? What is perhaps less in dispute is 
that anyone distributing combinations of that code and gplSort.php would need 
to be in a position to provide the sources to recipients.

> I see that there are many people who are uncertain about such cases, and
> possibly there are many people with different opinions on what is the
> legal situation. Maybe it would be a nice idea, if we (FSF/E) would
> develop a case-by-case guide for software developers to help them with
> these things. Does something like that exist? Maybe in the FAQs?
> It would be a pity, if developers choose to not use (A/L)GPL, only out
> of confusion!

The GPL FAQ does answer general questions, and specific questions should be 
answered by properly-qualified people. Nevertheless, there is an area of 
general understanding that doesn't seem to be very well documented.

[...]

> PS:
> The above is a thought experiment to illustrate a common situation.
> Personally, I would solve that problem by releasing SuperMineTM (if it
> existed) under the GPL, of course! ;)

Of course! :-)

Paul

[1] This is needed because the GPL governs the distribution of gplSort.php and 
what happens when you ask for the sources of any program using it. If 
myApp.php were distributed under a GPL-incompatible licence, it might not be 
possible to satisfy that licence's conditions and the GPL at the same time. 
But there are plenty of Free Software licences that could be applied to 
myApp.php that would uphold the GPL-governed properties of the resulting 
program.

[2] This is possibly closest to the situation with non-free graphics drivers 
on Linux, where the claim is that these drivers use the same interface on 
different platforms, are thus not specifically intended to interact with GPL-
licensed code, and that it isn't the vendor's fault that people use them on 
Linux. Personally, I think such arguments are rather weak: it is obvious that 
those vendors ship drivers to work on Linux and that they will be running as 
part of a Linux-based "program".