[development] Modules that integrate non-GPL PHP apps violate theGPL.
eric at semperex.com
Thu Aug 30 17:03:11 UTC 2007
Going high level ...
There are commercial enterprises now and probably more so in the future who want to build sophisticated sites with proprietary features and would love to use Drupal as their base platform. Also, there are existing products/services that people want to integrate with Drupal. Modifications and improvements to the Drupal core, core modules, or contrib modules under GPL can be necessary and will be thus be contributed to the community.
However, it is unreasonable to expect companies who have proprietary algorithms in custom modules or even want to integrate with a third party API (or perhaps Google's nifty search-in-a-box) to let a CMS licensing constraint hold them back. Thus, these companies will turn away from Drupal if licensing does not permit it.
Not that many years ago, companies like IBM contributed massive resources to move Linux into an enterprise-ready product and subsequently built a big consulting business around it. Linux was already very good. These companies helped make it fantastic. The world got a solid, very scalable, very versatile operating system. What's more, IBM actively promotes the use of all kinds of open source software. Solutions they sell to their customers run a mix of open source and proprietary and/or custom developed systems. And of course the end motivation is profit, but the benefit to the community is immense.
I don't think it's a big leap to say that a CMS is not merely a single software product but will increasingly become more akin to an operating system. Ideally, every piece of code for a site somehow sits somewhere in that CMS. The CMS ties everything together. It's the kernel and the glue. The database is like the hard drive. The web server is like the CPU.
If Oracle could never install their database product on Linux, would they use Linux? If a hot new site wants to build or integrate a proprietary map API, would they use Drupal?
I am all for a GPL-like license for the core, but I believe the long term interest of the Drupal project is best served by ensuring that third party modules can be developed with their authors choosing the license that is best for them much like developing an app that happens to run on an operating system.
Let's make sure that the ability to build third party modules under any license stays that way.
----- Original Message -----
From: "FGM" <fgm at osinet.fr>
To: development at drupal.org
Sent: Thursday, August 30, 2007 4:06:06 AM (GMT-0600) America/Chicago
Subject: Re: [development] Modules that integrate non-GPL PHP apps violate theGPL.
A commonly held view is that this is possible if, and only if,
- they integrate using web services, and not direct invocations: it's
commonly known as the "web services loophole". I don't agree with the
FSF's interpretation that invoking independent PHP scripts
constitutes linking, but that appears to be their stance.
- the GPL is version 2, not 3 (to be clarified for GPL3: there was
discussion about closing that loophole during the GPL3 design)
---- Original Message ----
From: jeff at viapositiva.net
To: development at drupal.org
Subject: RE: [development] Modules that integrate non-GPL PHP apps
Date: Thu, 30 Aug 2007 02:08:56 -0500
>For quite some time, it has been commonly understood in the Drupal
>community that non-GPL software (like a third-party PHP message board
>system) can be integrated into Drupal legally by using an
>intermediary 'bridge' module. After some in-depth emails with the
>Free Software foundation's license gurus, it's become clear that this
>is NOT the case.
>Before going any further, I want to make clear that I'm not
>expressing approval or disapproval of this: I'm just relaying the
>conclusions that were reached after several days of discussion and
>questioning with the FSF.
>Why do these modules violate the GPL?
>1) Under the FSF's accepted interpretation of the GPL, if a module is
>integrating Drupal and another PHP script, by calling one's APIs when
>triggered by the other for example, its purpose is to make a single
>unit of software out of those parts.
>2) If multiple programs are operating together and functioning as one
>unit, all the pieces must be GPL'd.
>There are a lot of angles to approach the question from, but that's
>what it boils down to. From a developer's perspective, if
>debug_backtrace() can ever include functions from both Drupal and an
>external program, you've turned them into a single program.
>There are some potential solutions, though none of them are ideal.
>1) Add a notice to Drupal's license that clarifies that writing such
>modules IS explicitly allowed. This is problematic, however, because
>that would make Drupal non-GPL'd itself, a GPL variant, and we would
>require explicit relicensing permission by the authors of any GPL
>code we wish to include.
>2) Remove modules that integrate with third-party non-GPL code from
>the CVS repository, even if they do not *include* the aforementioned
>3) Continue on as we are, and don't try to police these issues as
>there are NOT likely to be any real complaints. (No one that I know
>of is trying to SELL modules that integrate with non-GPL resources,
>This is an important question for us, and other GPL'd projects, to
>work through. Many GPL CMS's rely on integration components for
>critical functionality (message boards and mass mailing are two
>common examples). I can provide some detailed snippets from the
>correspondence to those who want them, but I'm not sure it would be
>useful for me to spend any more time corresponding. I exhausted my
>list of questions, and I'm just summarizing what I found out.
More information about the development