Re: [development] Modules that integrate non-GPL PHP apps violate theGPL.
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. Eric ----- Original Message ----- From: "FGM" <fgm@osinet.fr> To: development@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@viapositiva.net To: development@drupal.org Subject: RE: [development] Modules that integrate non-GPL PHP apps violate theGPL. 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
non-GPL code.
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, for example.)
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.
--Jeff
On Aug 30, 2007, at 12:03 PM, Eric Tucker wrote:
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.
This is where 'distribution' comes into play. I've written modules with proprietary algorithms for clients, and the solution was simple: they didn't distribute the modules to other entities. Integration with third-party APIs like Google's, and the use of external APIs like Amazon's, take place over HTTP protocols. RESTful interaction for example is clearly inter-program communication and not 'derivative work'. Turning away from software with a particular style of license for ideological or business reasons is nothing new.
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.
It's an interesting philosophical discussion, but it would definitely be a stretch. Similar to arguing that Adobe Photoshop is an 'operating system' because there is a large suite of plugins that depend on it, and Photoshop ties them together. While I'm frustrated by some of these barriers, the reason for them is clear: there is no good way to carve out an exception for these things without undermining the point of the GPL: to make software available free.
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?
Please read my earlier response regarding the 'driver' and 'operating system' exceptions that the FSF already includes in the GPL and accounts for in their documentation. If you have 'stump the GPL guy' questions, please contact the FSF directly. I reiterate that I am only relaying the summary of the information I got from them.
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.
This would dramatically change the current state of Drupal development. At present, any module that's distributed must be released under the GPL, or at least dual-licensed. That's one of the reasons for Drupal's thriving developer community.
Let's make sure that the ability to build third party modules under any license stays that way.
There's nothing to 'stay' -- this ability does not currently exist. The question was whether it was possible to use a module to act as a 'bridge' between GPL and GPL-incompatible software like a commercial message board system. --Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Tucker schrieb:
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.
Hehe, you seem to miss the importance of the stuff Jeff posted. This is not a Drupal issue. It is an issue for all GPLed CMSes using PHP, Perl, Python, whatever. So your companies are then welcome to develop their own CMSes or buy one that already exists.
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.
I've been using Linux before IBM "endorsed" it and I don't think big blue's engagement did help /that/ much.
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 think the community could do fine without IBM. Far better than IBM without the community, at least.
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?
No. But who'd care?
If a hot new site wants to build or integrate a proprietary map API, would they use Drupal?
This isn't a question of yes or no. This is a question of "how". XML-RPC and similar stuff is still allowed.
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.
Nope, sorry. Drupal has a license. And what would be using a license at all if we wouldn't stick by its terms? Even if we (including myself) interpreted these terms slightly different.
Let's make sure that the ability to build third party modules under any license stays that way.
This ability has never existed. It has been a long standing agreement (or at least nobody dared to challenge this position of mine) that modules have to be GPLed. What is "new" or rather "was unknown" so far is that intergrating third party non-GPL software through bridge modules is problematic too. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG1v95fg6TFvELooQRAr0tAKDI/kK8EsqyJcaYffYbA3jDYfLdcACgi4+e 3vdONXcUSHcGZOcDPRwRoA4= =8+de -----END PGP SIGNATURE-----
participants (3)
-
Eric Tucker -
Gerhard Killesreiter -
Jeff Eaton