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

[Larry Garfield]

Hrm.  So, a few applied examples:

Suppose for a moment that TinyMCE was non-GPL.  Someone other than the TinyMCE authors writes our TinyMCE module, which is a wrapper with value-add around TinyMCE to make it work in Drupal.  The TinyMCE module is distributed GPL, and end-users are expected to download TinyMCE themselves and put them together.  There is no distribution of the combined code.  Legal or illegal?  

I was always under the impression that was legal, since there was no distribution of non-GPLed code and GPLed code together.  nVidia is, too, since that's how the nvidia drivers for Linux work. :-)  (non-Free driver and GPLed wrapper that goes into the kernel.)

Scenario 2: A theme engine that is designed to consume non-PHPTemplate template files produced by a non-Free system, such as Dreamweaver or a design-time CMS.  Legal or illegal?  I was also under the impression this was legal, since the engine is GPLed and the files generated by the non-Free system are technically output of it (which is explicitly not affected by the GPL) rather than the code itself.

(A linked work, according to the FSF's GPL FAQ (wow that's a lot of TLAs), means sharing the same memory space or data structures in memory.  PHP certainly does that, as each server process has only one memory space and code can access any data structure it wants.)

--Larry Garfield

On Thu, 30 Aug 2007 09:32:56 -0500, Jeff Eaton <jeff at viapositiva.net> wrote:
> 
> 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