[development] Modules that integrate non-GPL PHP apps violate theGPL.
jeff at viapositiva.net
Thu Aug 30 17:20:33 UTC 2007
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
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.
More information about the development