[development] Modules that integrate non-GPL PHP apps violate the GPL.

[Jeff Eaton]

On Aug 30, 2007, at 7:02 AM, Jakob Petsovits wrote:

> My understanding was that non-GPL software may not be a derivative  
> work of
> GPL code, but that it can go the other way round. As David Strauss  
> mentioned,
> it is indeed possible to write GPL software by using the Win32 or  
> Cocoa API.
>
> Following this reasoning, it would mean the following for Drupal  
> modules:
> - Drupal modules are based on Drupal, so they are GPL in any case.
> - Thus, modules may not incorporate code that make the integrated  
> software
>   derive (call functions) from Drupal or the module itself.
> - Whereas it should be possible to call functions from the  
> integrated software
>   from the module.

This was my understanding for a while, but the FSF's position is that  
the use of the thre components together creates a single piece of  
software, at least when implemented in the way that bridge modules  
generally do. GPL software *may not derive from non-GPL components*  
unless the copyright holders make them GPL'd as well. This is,  
according to the GPL, to protect the GPL license from being abused by  
companies that write proprietary software with a thing GPL'd  
"wrapper" that is useless when not used with the pricey software.


> For example, that would mean no authentication in the integrated  
> software that
> is based on Drupal users and passwords. Or displaying any  
> information that
> comes from Drupal.
> But it should be possible to manage and display stuff from the  
> integrated
> software from Drupal. Like is done with Apache, for example (which  
> uses the
> GPLv2 incompatible Apache license). I'm sure there are lots of  
> other good
> examples.
>
> Would this make sense?

That's similar to a question I asked. The issue ultimately lies in  
HOW the software is integrated. 'loosely coupled' mechanisms like  
REST, most XMLRPC stuff, direct manipulation of databases without  
calling APIs, etc., are generally OK because they are 'standard  
mechanisms that separate porgrams use to communicate with each  
other.' No matter what we call it, most bridge modules ultimately  
work out to: "Program 2 is sucked into the execution chain of some  
Drupal code, via a bridge module."

I'll quote Brett Smith, the helpful GPL guy who spent a couple days  
hashing this out with me.

----
Perhaps you meant some kind of web services API, like a REST
interface.  That's a little more borderline.

There could also be other ways to construct the bridge that even more
clearly avoid making a derivative work.  For example, if the bridge  
didn't
call functions from either program, and instead just read from or  
wrote to
their underlying databases directly, that probably wouldn't create a
derivative work.  If there were command-line tools available that the
bridge could call to help with its work, using system() or similar
functionality, that probably wouldn't make a derivative work either.

I should also point out that if CMS developers want to make this sort of
bridge development unambiguously okay, they could do so by providing  
some
sort of licensing exception as described at
<http://www.fsf.org/licensing/licenses/gpl- 
faq.html#LinkingOverControlledInterface>.
This requires the assent of all the copyright holders, so I realize  
it may
not be a feasible option for every free CMS, but it is out there.
----


> David's argument that the GPL only covers distribution, not usage,  
> is a good
> counter argument to this point of view. Of course, this is somewhat  
> of a
> difficult issue, quite comparable to the kernel module blobs for  
> the ATI and
> nVidia graphics card drivers which are widely considered a legal  
> gray area.
>
> Also, you could extend the issue not only to PHP code but also to  
> XML-RPC
> calls, where you do not even know if the software that you  
> communicate with
> is GPL or not.

Regarding graphics cards and so on, I asked the same question:

----
"So, for example, we believe that programs that merely run on top of  
a given
kernel are not derivative works of that kernel, even if they make basic
system calls that the kernel provides.  Because of this, the license  
of the
kernel doesn't matter to a GPLed application.

"The second thing that comes into play is called the System Library
exception.  This isn't the technical definition, but in short, the  
GPL also
doesn't worry about the licenses of libraries that are essential to the
operating system.  This is also in the fifth paragraph of section 2."
----

While the GPL only covers distribution, they consider it a GPL  
violation to *distribute software that is intended to be used in  
violation of the GPL*. In other words, distributing a proprietary  
commercial piece of software that relies on GPL libraries, and  
telling people, 'We can't put X into our program, but you can to make  
it work...' is creating a GPL-derived program just as much as rolling  
the GPL'd libraries in and then distributing.

So, while no one is going to root around your server seeing if you've  
called include() on something non-GPL, distributing that middle  
component is, in the FSF's eyes, an attempt to circumvent the GPL.  
I'll quote again:

----
"The developers of the bridge are just looking to accomplish a
particular task and find a license that doesn't get them in trouble.
Unlike my scenario, nobody's obviously scheming to thwart the GPL.  But
when you just look at the structure of all the code when all's said and
done, the two cases look very similar.  And the structure of the code is
overwhelmingly what concerns copyright law.  It would be very hard to
distinguish between these cases in a legally secure way in the license."
----

Again, I want to make clear that I'm not saying that I agree or  
disagree, just that I went through the work of asking and clarifying  
the FSF's position on a lot of these edge case questions, and hope to  
clarify.

More than anything, I want to make sure that the advice we give to  
other developers when we're asked, "Hey! Can I do X?" is accurate.

I should also clarify that in our discussions it was obvious that  
things like images, CSS, HTML, etc was NOT in fact covered. So, for  
example, it would be perfectly legal to create a Drupal theme that  
consists of nothing but images and CSS files (using drupal 6's  
new .info file format) and release it under a non-GPL license.  
Obviously, it couldn't be checked into Drupal's CVS repository in  
that case.

--Jeff