Symfony's views on the GPL
paul at boddie.org.uk
Thu Sep 24 15:36:50 UTC 2015
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
> 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
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 .
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 ? 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.
> 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! :-)
 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
 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".
More information about the Discussion