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

Thomas Barregren thomas at webbredaktoren.se
Fri Aug 31 12:05:46 UTC 2007


Laura Scott wrote:
> On Aug 30, 2007, at 8:32 AM, Jeff Eaton wrote:
>> 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.
>
> I'm all behind this reasoning. However....
>
>>
>> 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.
>
> This reasoning seems to employ arguments made by the RIAA and MPAA, 
> except to opposite effect.

That might be due to the fact that both FSF/GNU and RIAA/MPAA use the 
same copyright law. :-)

> I write this as a GPL advocate and a big believer in open source. GPL 
> open source software is greatly advantaged to dominate the software 
> world eventually, but trying to force that through legal ownership 
> assertions strikes me as a great way to undermine the whole movement.

The beauty of GPL is that is doesn't fight the copyright laws. Quite the 
opposite! GPL leverage on the copyright laws to protect your freedom to

    * to run the program for any purpose.
    * to study and modify the program.
    * to copy the program so you can help your neighbor.
    * to improve the program, and release your improvements to the 
public, so that the whole community benefits.

Or, as Dr. Debora Halbert put it:

    "Essentially, Stallman has codified sharing in order to prevent
    profiteers from stealing from the public domain. The GPL cleverly
    uses the power of copyright law (which allows the author of the
    product to control its use and distribution) to provide software for
    free.[56] In this way he transformed the rules of the game and
    redefined copyright (what he calls copyleft) into a tool the
    supports the creator and users of software."

    See § 46 in
    http://www.murdoch.edu.au/elaw/issues/v10n4/halbert104_text.html#GNU/GPL%20License_T.


> For example, this API argument: by prohibiting use of APIs to bridge 
> differently-licensed applications (and aren't APIs developed 
> *precisely* to bridge two different applications?) we're forcing a 
> "dumbing down" of work (and sundry other potential problems and risks) 
> by legally requiring the bypassing of established application 
> methodologies (such as security protocols) to write direct queries to 
> databases.
>
> How are we going to build an integrated world when GPL starts claiming 
> rights to all that touch it? We're going from the freedom that comes 
> from building a commons to the restriction that comes from making that 
> commons a fenced-in zoo.
>
> Maybe I'm wrong and going off in high spirits for no reason. The net 
> result, I fear, is the creation of a GPL ghetto where anybody with one 
> foot in the proprietary -- i.e., real -- world is given reason to 
> hesitate coming within a country mile of GPL, just when GPL apps are 
> poised (and have already started) to transform the mainstream business 
> world.

GPL allows you to use both GPL:ed and non-GPL:ed API:s to bridge 
different applications. GPL also allows you to distribute the derivative 
work which emerges thereby. But to make sure that *you* don't deny the 
receiver the same rights as you got, GPL requires you to distributed the 
derivative work under GPL. Therefore I think this reciprocity of GPL 
(a.k.a. "copyleft") is something very good.

The reciprocity prevents *distribution* of works derived partly from a 
third-party software with a license which is not compatible with GPL. 
Normally, this is also something good. As is said on the GPL FAQ:

    "If we permitted company A to make a proprietary file, and company B
    to distribute GPL-covered software linked with that file, the effect
    would be to make a hole in the GPL big enough to drive a truck
    through. This would be carte blanche for withholding the source code
    for all sorts of modifications and extensions to GPL-covered software."

    See
    http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TOCMoneyGuzzlerInc


But, as this discussion is about, this can also pose a hindrance for 
situations where it can seem reasonable to include software with license 
not compatible with GPL.

For an example, imagine someone who has put in a lot of effort to write 
code that integrates a popular but proprietary software with Drupal. So 
far it is okay under GPL. But now he wants to share his effort with the 
community. Since the integration code calls functions and share data 
structures with both the proprietary software and Drupal, it is not allowed.

Fortunately, there is a solution. As long as you don't revoke any rights 
granted by GPL, you can add your own terms and conditions. This can be 
used to allow integration with software under a license incompatible 
with GPL. Two examples on this:

  * 
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLibs
  * 
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControlledInterface

So, to solve the problem that the licensing of Drupal currently force us 
to "dumbing down" or "bypassing of established application 
methodologies", I suggest that the Drupal licensing is supplemented with 
an exception for module developers linking through hooks.

> Vivek Purl wrote:
>
>> Just for background this issue has come up because
>> Joomla  have decided to "fully" comply with GPL. This
>> raised a few question for SMF team and they discussed
>> it with FSF. The final result of that discussion is if
>> php ( or any other scripting language ) which is
>> distributed in source form is bridged to a non GPL
>> software also distributed in source form then it
>> violates the GPL.
>>
>> The immediate effect for drupal is that VB and SMF
>> bridges are violating GPL. It doesn't matter if its
>> being distributed via d.o. or not.
>
> So GPL apps are prohibited from touching non-GPL apps. I'll be snarky 
> and say this is the kind of thing that happens when lawyers get 
> involved. Time to stop developing software and start developing new 
> licenses and lawsuits!
>
> Laura (who's still wondering what was wrong with GPLv2)

Pardon???

All what had been said applies to GPL v2 as well as v3. So you concerns 
must consequently also apply to GPL v2 which is used by Drupal. Correct?


Best regards,
Thomas


More information about the development mailing list