drupal license and code/module/extensions availability

...Is that anything that *includes code from a GPL project* must by GPL. A module, by definition, is a freestanding piece of PHP code that *interacts* with the Drupal core via publically established APIs. Thus, a module or theme developer is free to restrict the distribution of their own work as they see fit.

Our provisioning system is currently completely separate from Drupal -- it runs on Python and PostgreSQL.

We helped make the Drupal codebase suitable for multi-site installs, and that is now part of core.

We're helping to develop install profiles and an installer API, that will also hopefully make it into core.

I'm not even going to go into the many other things that Bryght as a whole has contributed to Drupal, both from code and marketing perspectives. Anyone that would like to manage 100s or 1000s of Drupal sites is welcome to contact us about licensing our provisioning platform.

Regardless of whether or not you distribute, the license is GPL. If you distribute, you must make source available. If you DON'T distribute...well, we'll never know, so you're welcome to not make source available.

...but I think this is restrictive to the point of problems for some business models.

I would rather that at some point we make a ruling, saying that modules don't have to be GPL (e.g. BSD license). Regardless, anything on Drupal.org currently must exist under GPL.

But, I imagine redpineseed has something else in mind. Perhaps he will enlighten us further: is forking what you're talking about?

You can fork all you want...it still has to be GPL, and you have to share source if you distribute.

I am not sure I entirely agree with the author of that part of the GPL FAQ.

In any case there is a workaround to creating commercial modules. Write your module in two parts. Write an API that interfaces with the Drupal API and release it under the GPL. Write your module to interface with your API and release it under whatever (commercial) license you want.

As long as you do not interface directly with Drupal data structures or code, the fact that Drupal is licensed under the GPL is irrelevant to your module. The copyright of your API module is more complicated: you own the copyright to the bits you wrote, but not the API and the data structures of Drupal you interface with. But of course the Drupal GPL allows you to release code under the GPL that uses its API and data structures.

So your API is OK under the GPL, and you can do what you want with the rest of your code.

Note that this post represents the personal opinion of the poster and is provided without liability or warranty.

--------------------- WEBg8 ---------------------

You are NOT permitted to include anyone else's material in the distribution.

Unless you receive permission from them.

Due to the way in which Drupal functions (there is html code generated by the code) it is the position of the FSF that putting a website online constitutes distribution.

Again, this misperception has been corrected by a number of members of the Drupal community. The FSF people that you spoke with even noted that the intent of the copyright holders (i.e., 'This doesn't cover the HTML that's output') trumps hair-splitting over GPL wording.

The difficulty with code is that there are members of the Drupal community who have contributed code, and do NOT want the licensing to be 'looser' -- since it is their work that is affected by it, it looks like a show-stopper. Those same individuals, however, have also vigorously said that GPL shouldn't apply to the HTML. A clarification in the Drupal license would probably be a good idea, but your confidence about this issue isn't justified.

--
Jeff Eaton | I heart Drupal.

Good remarks from the FSF representative in that post.

Some current themes and templates used with Drupal do not contain "library-like calls", nor data-structures part of active use of direct Drupal functions (i.e calling PHP functions with any Drupal PHP-variables).

The same goes for (X)HTML and XML tags - they're not GPL, but free as in public domain. The actual input into data-labels is very different from Drupal's internal non-aggregated representation as well. The tags or data-labels may have existed before template-engine creation time, or was created at the same time - but as independent labels (not datastructures) of any Drupal internal data.

The data-labels are based on external not-Drupal-specific definitions and would therefore not imply falling under Drupal's GPL reach.

Some templates and themes, mainly Smarty and PHPTemplate-based ones, differ from this. Some of these share most datastructures, memory space, function calls and are designed specifically and only for Drupal when using Drupal-function-calls in their templates or themes. That means they function just like any other module or plugin with regards to the FSF's GPL understanding.

XTemplate-based, and perhaps other templates or themes, do in no way share anything with Drupal, but rather define external data-labels in a clean API understood by the template-component and the Drupal-components/-theme-engine.

It is possible to write Smarty or PHPTemplate themes/templates in such a way as to avoid direct Drupal calling, emulating e.g XTemplate behavior. Using data-labels as "API-glue" you can split your theme into two parts: the processing part, and the presentation part.

This would be equal to the "clean API" circumvention like djnz explained.

Smarty is pretty complicated to sum up as giving "module-like" templates, because it normally doesn't include PHP - but can do it.

The fact that you end up with these two parts of functionality might be a little disheartening with regards to using Smarty or PHPTemplate for the purpose of creating "commercially licensed" themes or template. Sometimes splitting the theme or template into two parts is unavoidable when using XTemplate too. This is of course when you design for non-core Drupal modules.

That way you can put whatever license you like on the "pure" template or theme, with absolutely nothing to fear from any GPL violation or FSF reaction.

With regards to my updated XTemplate engine as an example; I see the engine itself as GPLed-but-unreleased, but safely regard all my templates under whatever license I care for.

I made improvements to how templates in XTemplate can do more complex iterations, caching and even do eval's like in Smarty - which would actually be like having templates behave as Smarty but without any legal hassles for commercialization.

PHPXTemplate.org has XTemplate released in version 0.3 under dual license using BSD and LGPL 2.1 from 1999 (first LGPL released version). This license was unchanged for the april 2005 1.7 developement release and the very recent 1.8 release.

See http://cvs.sourceforge.net/viewcvs.py/xtpl/xtpl/license.txt?rev=1.1&view... for the license and http://cvs.sourceforge.net/viewcvs.py/xtpl/xtpl/ for browsing developement version.

edit: just a sidenote about Quicktemplate - which inspired XTemplate and has similar syntax as well as being LGPLed. Homepage at http://quicktemplate.sourceforge.net/ . It seems it has many coding similarities with XTemplate.

As I understand it and people have said in this thread, the LGPL was created as an alternative to the GPL to answer many of the concerns cited here. However, the GPL currently governs distribution and use of Drupal. If I understand things correctly, use of the LGPL cannot be substituted for the GPL where it is already required since it is "less free." The GPL is pretty clear about eliminating the freedoms granted under the GPL. One can't simply choose to switch to the LGPL without the permission of all copyright holders of the GPL licensed code.

I think that the executable parts of a theme are just to be treated as any module. You don't however _have_ to release them. Just as any module you happen to write and use on your (or a client's) site.
--
Drupal services
My Drupal services

At least one CMS did inquire.

If you read carefull what the Post Nuke people said, they say:

This is based on what we believe to be true after making enquiries.

There is no legal precedence for any GPL related dispute yet, simply because no court has had to face any dispute so far.

--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

Since there is no legal precedence yet it continues to be controversial. I have no doubt that the FSF will go out in force and very strongly defend their stance when it somedays becomes necessary.

It is obvious that one can not retract anything from the GPL, only add to the license. That pretty much makes it clear to me, no matter what opinion other developers of CMSes might have.

There is nothing in the GPL which prevents anyone from selling code.

There are some developers offering services at drupal.org official Drupal services offered exclusive list, that doesn't mean that's the only game in town. I don't know if they make $$$$ or even $$$$$ off Drupal work like with the Summer of Code projects, but it is "booming" according to some.

Drupal has no additional license than GPL, and that makes it pretty fair game for anyone. That is regardless of if they want to sell it or not. For the benefit of others, this should be made clear. There have already proven to be so many misunderstandings between (even Drupal) developers.

Reading the full text of documents is often laborous, like you pointed out.

If one wants to herd a pack of GNUs in an efficient manner; one needs to understand the GNU; one has to become the GNU.
;-)

Ok, I've now read the GPLv3 proposal, and it doesn't seem to include the "Website is Distribution" idea. What it does do is:

13. Use with the Affero General Public License.

Notwithstanding any other provision of this License, you have permission to link any covered work with a work licensed under version 2 of the Affero General Public License, and to convey the resulting combination. The terms of this License will continue to apply to your covered work but will not apply to the work with which it is linked, which will remain governed by the Affero General Public License.

It is the Affero General Public License which has the "website is distribution" limitation in it. So I guess some modules may decide to use that license, and then it gets interesting as to what a module that links with both GPL and Affero code is virally infected with (given that the Affero license is just GPLv2 with an extra clause). All I can say is that the law profession must be very pleased with this whole mess - it guarantees them work for a long long time!

So it would seem the "don't distribute your code / get paid for work for hire" plan is still workable. I am still very dubious, however, about the "RPC" workaround. As posted in other threads, a clear answer to this would seem to affect a whole lot of people when it comes to things like adsense modules etc.

Again, any thoughts?

The examples at gnu.org are not very helpful when looking at web applications in general and PHP in particular IMHO. The examples (and the GPL itself) are geared towards C and similar code compiled from source where application developers will compile a number of libraries together with code they have written to produce a single object for distribution.

I would also go further than saying an RPC interface is OK, and suggest that the 'wrapper module' approch is OK provided you don't distribute your proprietory module together with Drupal core. Why? Look closely at the quote from gnu.org:

But if you were to incorporate them both in a larger program, that whole would include the GPL-covered part, so it would have to be licensed as a whole under the GNU GPL.

So just don't do the incorporating, and then there is no whole to be licensed under the GPL. This would be difficult if you were writing a traditional application and trying to sell it - you would have to get users to download your code and the GPL libraries separately, and then run a compiler (assuming they can) to produce an executable file. However with PHP, the user can just do the downloading, put everything in the right place and fire up the web server!

Why use the wrapper module at all? Well, this is not directly down to the GPL, it is more abstract. The GPL allows you to use (and distribute) the code subject to the GPL. It does not allow you to use the concepts behind the code, and in as much as these concepts are intellectual property, it is not clear what rights anyone may claim to that intellectual property. For instance Dries may well lay claim to the concepts underlying Drupal's node system. If you write a module that only works with Drupal's node system, you will be utilising those concepts, and the software you write could be said to be (in part) derived from those concepts. However if your module is abstracted from Drupal so that it uses a wrapper module (licensed under a license compatible with the GPL) to actually create nodes etc. then your module is only using the concepts underlying the wrapper module. Providing the wrapper module could be rewritten to integrate with a different CMS, your module can be shown to be independent of any Drupal intellectual property, and so noone can stop you selling it or make you distribute it.

Note that this is just my own opinion and is offered freely and without warranty or liability.

--------------------- WEBg8 ---------------------