Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By eaton on
I've spent the last couple of days chatting with some of the core Drupal developers and reading up on the GPL licensing agreement that covers Drupal. There's been some confusion about what it means, exactly, and how it affects those of us who use Drupal in work for clients.
My words are not canon, and anyone is free to correct me if I am factually incorrect...
The following are automatically released under the GPL license:
- Any files checked into the Drupal CVS repository
- Any Drupal modules, even if they are not checked into the CVS
- CODE from Drupal themes (ie, the page.tpl.php, template.php, and so on)
As long as they are not checked into the Drupal CVS repositiry, the following are NOT automatically released under the GPL license:
- CSS files, image files, media files, and any other non-PHP files
- Programs (including PHP code) that do not directly interface with Drupal. (For example, the TinyMCE text editor project is a separate program, with a Drupal module that 'connects' it to Drupal. The module is automatically GPL'd, but the TinyMCE project is not.)
Now, what does it mean to say that something is 'released under the GPL license?' There are a lot of lawyer-ish terms to throw around, but after much discussion, it seems to boil down to this:
- You can charge a client for your work that is released under the GPL.
- You can host GPL-licensed stuff on your web site and charge people for downloading it.
- You cannot control what someone ELSE does with software released under the GPL once they have it. (This is because anyone who has a copy of GPL-covered software has the right to modify it or give it away to anyone else.).
- You CAN control, via licenses or agreements or what not, stuff that isn't covered by GPL. (images, css layouts, media, and 'helper' programs like TinyMCE that don't directly connect to Drupal). This distinction is important.
What it boils down to is this. If you want to make money off of your work with Drupal, there are a couple of options:
- Charge consulting clients for the time it takes you to do the work
- Petition the community for 'sponsors' if you think a project would be valuable, but can't afford to donate the time (this is sometimes called a reverse auction)
- Sell your Drupal modules and themes. After people purchase them, they can give away *anything that's covered by the GPL.* You, though, don't have to give technical support or accept feature requests from those who didn't pay.
- Write your custom software as an external program (in PHP or some other language) that can be used without Drupal. Then write a simple module that 'connects' it to Drupal. The module is GPL'd, but people can't distribute the separate program without your permission.
- For themes, the basic template files and php files will be GPL'd. Anyone who has your theme can hand those files to their friends willy-nilly, but they must still obtain your permission to redistribute the images, media, and CSS files that make your theme distinctive.
I may be wrong -- if I've gotten the facts wrong (not 'what you would like to be different,' just the facts), I'd appreciate a post here. Hopefully, it'll clear up some of the recent confusion. :)
--Jeff Eaton
Comments
There's no way a module
There's no way a module written completely separately from Drupal that ties into the system could be governed by the GPL. If that were the case, you could argue that they have to follow the PHP license because they've written it in that language and it interfaces with it. If I wanted to make a closed-source, encrypted module for Drupal I would be able to to legally.
My understanding is that you are incorrect.
Note my comment: Programs (including PHP code) that do not directly interface with Drupal are not automatically covered under the GPL.
Your example regarding PHP isn't directly applicible. PHP does NOT use the GPL, but rather uses the 'QPL' license. This discussion is about how the GPL license plays out in the context of Drupal development. I am not talking about 'what you prefer,' or 'what killes prefers' or 'what dries prefers' but rather, what the implications of the GPL are.
In all of the discussions I've had with those knowledgable about GPL and Drupal, I've been told that if your write a Drupal module, you're not writing something 'completely separate from Drupal.' The GPL classifies this as derivitive or linked software. Thus the use of TinyMCE as an example -- the TinyMCE drupal module is GPL-licensed, but the TinyMCE editor that it interfaces with is NOT. If you want to write an encrypted, closed-source Drupal enhancement, it would probably be far less problematic to create it as a separate program, ala TinyMCE.
This has been hashed through in numerous other threads, and I'm simply trying to boil down what the end result is for developers.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Pretty much.
Thanks a lot for that clear, bullet-point version of what counts, and what it means (handbook page, anyone?)
I was studying the GPL again last week with this in mind.
Yes, the 'automatic' encompassing of code made to work with Drupal is the GPL 'infection' some folk talk of. And it's quite intentional.
Yes, a 'Module' made for Drupal is automatically GPL.
BUT.
If you made it to run on your own server, you are providing a service, not distributing software. You are not required to release the source to anyone or anything else.
If you SELL or give away your custom module, you ARE required to release the source to the client (Seeing as it's PHP, that's pretty moot). They are then allowed to do with it what they want once it's in the wild.
An alternative, if you find this distasteful, is to bundle your clever stuff into stand-alone libraries with no core Drupal hooks and write a wrapper module that provides the Drupal interface to your code. While the Gnu folk like to say 'it's a separate program if you fork to it', that doesn't translate well to PHP.
Your stub module is GPL, but your library is your own.
As long as your code can (even if theoretically) be of use without Drupal, I think you can call it independant. If you could call it from a non-drupal page, or write another wrapper for another system, it's immume.
Basically, it comes down to which physical files you stick which functions into.
... my understanding anyway.
http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
yep
dman, that's exactly how I understand it as well. Thanks for the more detailed explanation of how a stub module and an external library could be used to integrate a commercial/restricted-license product into Drupal without violating the GPL.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
I feel this is
I feel this is correct.
There could very well be an instance where a someone could write one module that just happens to work with two different softwares.
For example, imagine that we have the open source Drupal, and another closed source CMS, Brupal.
The two CMS's are completely different projects, and one is not based on the other.
There could be a case where a file (in this instance, a module) written to perform some task would work with both systems.
There are many unique ways to write code, but its very probable that PHP written for one system could work with another; the simpler the task, the more probable this is.
This new module that works with both could be under whichever liscence it's creator applies to it, based on how they wrote it an other factors.
-----------------
Josh Stevens
Electric Transcendentalism
need more clarification
Thank you Jeff for these very helpful clarifications. Please do put this into a handbook page.
I think there are still two questions I have left over from another thread [1] on this topic:
(1) It is still fine to write a module for your own use and never distribute it, right?
(2) Does the GPL cover the HTML as well as the PHP code in Drupal? If not, why not? And if so, what are the implications for the content of a web-site built on Drupal? It is certainly integrated with the GPL'd HTML code from Drupal in that case, right? (See [2], [3]).
Please incorporate these clarifications in the handbook page. And thanks again for taking the time to write this up.
[1] http://drupal.org/node/37504
[2] http://drupal.org/node/37504#comment-91098
[3] http://drupal.org/node/37504#comment-91814
My humble answers :)
(1) Absolutely, yes. In fact, a lot of consulting gigs involve writing stuff for clients that will *never* be distributed or released outside of that client's server. The GPL just means that IF they offered it to someone else, the client couldn't control what that 'someone else' did with it.
(2) This last one seems to be a confusing one for many folks. I'm inclined to say that GPL does not cover the HTML because it is output from a program rather than the code of a program. For example: the Drupal 'book' module has some imbedded HTML in the module. Someone can use that module, but just because you've used that module, too, does not mean any HTML you publish while using it is suddenly GPL'd. In the same way, using a GPL word processor does not make your book uncopyrightable -- even if its grammary checker generated several of the words in it.
I'll do more looking, but http://drupal.org/node/37504#comment-91156 seems to deal with it pretty clearly, as well.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Software Freedom Law Center
Software Freedom Law Center is here to answer just these questions.
http://www.softwarefreedom.org/
One of the big issues with module licensing is the intent of the licensors. We had SFLC do our licensing FAQs for CiviCRM and we specifically say if you use the API, you're not subject to AGPL. Drupal can make the same statement, releasing module authors from the GPL requirement. Alternatively you can do the opposite, and make all modules subject to AGPL.
Then somone will write a wrapper and challenge the licensing :)
Call SFDC, get them to write up the facts. It will help make expectations of members of the Drupal community clearer.
David Geilhufe
Social Source Foundation
Try CiviCRM http://www.civicrm.org/
Thanks!
Part of the difficulty, as I inderstand it, is that there are currently different opinions inside the community of very active core contributors to Drupal about that 'intent' clause. Since Drupal as it currently stands has been made by quite a few people, with different expectations of what the GPL implications are, the most literal interperetation of GPL is necessary.
Again, I could be wrong on that one. It sounds like the SFLC folks are the ones who are best suited for this sort of thing. My interest was just to hammer out some clarity around what was starting to look like a very contentious issue for some folks. :)
--Jeff
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
GPL status of output
According to the GPL FAQ, it really looks to me like in the case of Drupal the HTML output is also covered by GPL.
[1] states ...
I would love to find a different way to interpret this, but I don't see how. Certainly the HTML included in the the Drupal core is part of Drupal and therefore covered by GPL. Since it is copied to the output, the above states pretty clearly that the output is also covered by the GPL.
The only way I can see around this is to somehow claim that it is only the PHP code in Drupal that is distributed under the GPL and that the embedded HTML is specifically excluded. This seems very problematic to me.
This issue is obviously very important and has huge implications.
[1] http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL
That's my understanding as well
Regarding (1) - I spent considerable time a while ago researching GPLV2. I'm no lawyer but what I came up with indicates that you can develop stuff based on GPL code and keep it to yourself. It's the distribution to another party that triggers the requirement to provide (or make available) source code to the recipient.
Running GPL (and GPL-derived) code behind a web server is not considered to be distribution, and therefore does not trigger a requirement to make the source code available to anyone.
I'd love to consider evidence to the contrary, if anyone knows of credible sources.
Thank-you
This is the best discussion that I have seen.
The big problem it highlights is that it is easy to get around GPL for modules but hard for themes, because how do you separate code from HTML and JavaScript? You can't have multiple licenses in one file.
If you do work for a client and they get a copy, even as backup, that constitutes distribution under GPL and creates a whole swarm of legal issues.
Clarification
Actually, you can. It's called dual-licensing, and allows your theme (released under GPL) to ALSO be released under a license that is GPL compatible but makes allowances for third-party libraries. (The LGPL is one example). MySQL is licensed in just such a way -- as a user, you can use it under the GPL license, or under the alternate license that allows integration with closed-source code. DRUPAL isn't dual-licensed, but your module or theme CAN be.
Because those DHTML libraries you use are obviously generic (they are used in many themes, and in other applications that have nothing to do with your themes) they're clearly a separate piece of code. When you hand off the theme to your client, along with the DHTML libraries and images and all that other stuff, you're doing it under the LGPL, or some other GPL-compatible license that allows those components to be used without violation.
It's a little complicated (conceptually, at least) but in practice it's very simple. THIS, I think, is an important clarification.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
You can't just "release" someone else's code under GPL
If you do not hold the copyright to something, you cannot release it as GPL. You do not have the right. That includes using it in a site developed for a client.
For example, a licence requiring a notice is not permitted under GPL (eg. the original BSD license). This means that you may not use any code from, for example, dynamic drive, in a template, as that code requires a notice.
You certainly can't go to hotscripts.com and find a php library to solve a problem. You are required to spend weeks rolling your own.
You are incorrect. :)
The steps are as follows.
This is called 'Dual Licensing.' It means that you are not releasing someone else's code under GPL. YES, this issue can use some clarification. I'm attempting to provide that clarification, but you have voted against the changes to the Drupal FAQ that would provide it. I am baffled by that.
And no, dual licensing does not specifically cover the inclusion of non-GPL copyrighted HTML mixed in with GPL-covered PHP code in a single file. My feeling is that the best solution is a BISON-like exception in the Drupal license, clarifying that mixed HTML/PHP templates used by a drupal theme are not considered "derivative works," though dedicated PHP files full of support functions and so on are.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
That's all I was asking for
It is silly to require an arcane and un-maintainable structure like having every bit of template HTML and Javascript in a seperate include file just to protect it from Crusaders of The GNU.
What you are suggesting is all that I suggested in the first place.
It is what the FSF recommended for Drupal.
By the way, I did not see your follow-up to the faq suggestion because for some reason it does not show up on the recent posts list when you add to that thread.
Clarification
Two points, lekei:
First, HTML contained in PHPTemplate .tpl files is, as I've said, a very specific issue and one that requires further investigation and possibly a BISON-lke exception in the license. The other scenerios (code libraries, generated HTML, images, CSS), however, are NOT.
If you are using a third-party code module, it is not 'arcane' or 'un-maintainable' to put them in a separate file. I would go so far as to say that if you're putting your javascript inline in raw HTML files, THAT is unmaintainable.
Thanks for your comments, by the way, in the issue about the FAQ update. I believe the changes you suggested in that thread would be both incorrect and misleading to users, and don't support them, but I appreciate that you're participating in a specific attempt to improve things.
It's obvious that your complaint is with the GPL license. Comments about 'Crusaders of The GNU' reveal a bit of bitter snarkiness that tends to poison productive conversation. I'd really suggest that you step back and take a breather. This conversation is not about anyone proving anyone else right or wrong. It is about clarifying something some users are confused by.
I'd also point out an interesting bit in the GPL FAQ:
I thought it might be helpful.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
More clarification
The unmaintainable aspect I was talking about was to have every bit of HTML and/or simple in-line JavaScript that comes from a commercial template in series of little external files. I think we are both in agreement on that point.
I thought that an introduction like the one in the Linux license (http://www.kernel.org/pub/linux/kernel/COPYING) would have been more appropriate, stating that themes are the normal use of Drupal and do *not* fall under the heading of "derived work".
A "BISON-like exception" as you suggest was all that I originally suggested and it was what is recommended by the FSF licence guidelines and the open source licencing experts that I have consulted.
The people that I refer to as the 'Crusaders of The GNU' are those who believe religiously that the GPL is a Holy Document that must not be altered. Amazingly, this does not even include the Free Software Foundation, who advise the use of modified licences in many cases, including those that generate HTML.
Getting back to cases
How relevant is the combined-html-and-php in theme files problem?
From a human perspective, I'd say that including drupal core function calls in the source of your theme file pretty much ties it in for use with and only with Drupal. It's a derived work, and yes, gets infected.
If my (or any other-sourced) javascript is worth protecting, it's probably worth a library. That library is re-usable, generic, seperate and not infected.
A third-party library may even bring its own license, which, if 'infectious' would also carry over into the theme file that uses it.
The theme now has to comply with two licenses.
If this library is significantly different or contains restrictions like attribution (which I hear is prohibited under Gnu?) I can see there would be a problem releasing it.
But is creating a commissioned work for a client or building it for an employer 'releasing' it? I'd say not.
Even if you think it does, all GNU does is give the recipient visibility of the source, and control over what happens to it next. They have the choice to redistribute it, but if it's only being used to render their website as a service, they have no obligation to do so.
In most cases, the last people who are wanting to release their handmade site source are the ones who paid for it.
(there may be some design, tutorial or consulting places that will, but that's their licensing issue)
If the source is not released (only used) I don't see how the Gnu problems would even manifest themselves.
It's only the redistribution of themes like here at drupal.org where this is a worry, not for most custom theme developers, right?
.dan.
http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
I think that an "official" statement on this issue is required
I think that an "official" statement on this issue is required as a matter of urgency, though I appreciate that it may not be a legally-binding one at present. Rather it would be informed opinion on the licence issues, which could later give rise to a legal precedent.
FYI, I plan to offer a "Drupal plus" hosting service soon. My understanding of the GPL is that I would not be required to distribute any new code etc., even if it falls under the terms of the GPL. Thus I would be able to protect my intellectual property simply by keeping it private.
Of course I greatly appreciate the efforts of the Open Source community, so I intend that my way of contributing would be to donate some of my profits to further Drupal development. I will be reluctant to proceed at all however if there might be an expensive court battle over the licensing in the future, so this whole issue needs to be clarified.
Richard
The existing licence-related handbook page should be updated.
The existing (most readily available) handbook page covering licencing is focused on handbook contributions:
http://drupal.org/node/14307
Maybe it should be replaced (hooked into) a new page that takes a broader approach, inclucing an "approved" version of the issues discussed here - a "public statement" from (or one that is "approved by) the Drupal Association, perhaps?
.
--
( Evaluating the long-term route for Drupal 7.x via BackdropCMS at https://www.CMX.zone )