[development] Drupal 6.2 theme system standalone

Larry Garfield larry at garfieldtech.com
Fri Jun 13 19:34:09 UTC 2008

Because the code is derived from Drupal, yes, it must be distributed under the GPL if it is distributed. (There is no legal requirement that you distribute your changes at all, just that if you distribute them you do so under the GPL).

Other PHP code that interacts with these "extracted subsystems" *is* affected by the GPL as well.  Because it is interacting in the same memory space and sharing the same data structures, the combined work is then a derivative work of the extracted subsystem, and therefore the GPL on the extracted subsystem requires that the combined work also be distributed under the GPL if it is distributed.  So the sort of API trickery you describe below is irrelevant; the GPL still applies.  If you wanted the trickery below to work, you'd need to be using the LGPL, which exists for exactly that purpose.  (That is an aside, though, since Drupal is under the GPL only.)

In general, as long as the license is followed I have no problem with these "extracted systems".  I think they're actually very good for Drupal, because we *should* be making subsystems that are as insulated from each other and loosely coupled as possible.  I actually would love to see efforts like this contribute back to Drupal to help make our subsystems even more modular and loosely coupled.  I've been seriously considering doing the same to the new database API after it lands for the same reasons; it's cool in its own right, and modularity is a very good thing.

--Larry Garfield

On Fri, 13 Jun 2008 20:10:43 +0200, "Bob Pepin" <bob.pepin at gmail.com> wrote:
> Well for now I've put GPL on it, which makes sense cause a lot of what
> I have done is simply assembling the drupal functions used by the
> theme system into one place. You could even create a script for
> extracting those functions from the drupal codebase, which would also
> make maintenance easier, maybe something like this even exists
> already? Besides, I figured most of the development happening on this
> will be improving compatibility with certain themes by either
> importing or adding stubs for the extra drupal functions used by them,
> which is something where it makes a lot of sense to share
> contributions.
> Anyway, I plan on layering a very thin entry point to this library
> just on top of the drupal callbacks, so the idea is for example not to
> implement any custom cache facility inside this but instead to provide
> hooks where you can register your own routines for handling caching
> from outside the library. This will hopefully prevent the GPL from
> infecting your projects ;)
> But besides, I'd also be interested to know if theoretically I would
> be forced to use the GPL in this particular case, so if we've got any
> license war veterans in here, feel free to comment.
> On Fri, Jun 13, 2008 at 19:15, Ken Rickard <agentrickard at gmail.com> wrote:
>> Question for the pseudo lawyers in the room.  Does this mean that Bob's
> work
>> must be GPL'd?
>> On Fri, Jun 13, 2008 at 1:04 PM, Adrian Rossouw <adrian at bryght.com>
> wrote:
>>> On 13 Jun 2008, at 6:59 PM, Matt Galvin wrote:
>>>> Drupal is open source. Anyone is free to use it for what they wish as
>>>> long as they share their derivative work. He is sharing his. It may
>>>> not be useful for you but it might be for someone. Among other things
>>>> Drupal takes PHPTemplate and builds on top of it for theming. What Bob
>>>> is doing is not all that different.
>>> yeah. tbh, i wrote and tested phptemplate (and formsapi) completely
>>> separately
>>> from drupal before starting to integrate it.
>>> Some of the more recent changes in D6 might make it a bit harder to
>>> separate,
>>> but it should still be workable.
>> --
>> Ken Rickard
>> agentrickard at gmail.com
>> http://ken.therickards.com

More information about the development mailing list