CVS: Update FAQ.txt to clarify the impact of GPL on HTML output

As per chx's recommendation:

+Q: Does the GNU/GPL license apply to the HTML generated by a Drupal site?
+A: No. It is the intent of the Drupal developers that the license apply to Drupal,
+ as well as any modules, theme engines, or PHP theme code written to interact
+ with it. The output generated by a live Drupal site -- including CSS, HTML,
+ images and other media files, as well as Javascript code used by a theme --
+ are NOT automatically released under the same license simply because they
+ are sent from the server to a user's browser.
+
+ Any file checked into the Drupal CVS repository, of course, is automatically
+ released under the GPL for public use.

Clarifying the 'php' aspect, and the fact that images, css, and generated HTML output are not automatically GPL'd. lekei, this modification is meant to clarify the GPL status of generated output for a web site, not the issue of third-party libraries. That question is probably best settled in another issue.

RayZ, thanks for the feedback. I've added an additional question to this patch that should also help clarify the way third-party code can be used with themes and modules.

Q: I want to write a Drupal module or theme that uses third-party PHP code
   incompatible with the GPL (for example, integrating with a commercial web-chat
   product). Can I do that without violating the GPL?
A: Yes, you can. It requires an extra step, but it's perfectly acceptable and
   several examples of it already exist. According to the GPL, code written to
   interface directly with Drupal (like modules, PHP code in themes, etc.) is
   'derivative work' and automatically inherits Drupal's GPL license.

   You can, however, license your module or theme under an ADDITIONAL less restrictive
   license called the LGPL. This dual-licensing allows your module or theme to act as
   a buffer between Drupal's GPL license and the non-GPL code libraries you're using.
   You should include a LICENSE.txt in your project noting this.
   
   You MAY NOT add those third-party code libraries to the Drupal cvs repository, 
   however, as all files in the repository must by GPL-licensed. Users of your module
   or theme will have to download that software from another location.

   The TinyMCE.module and sIFR.module projects, available for download at drupal.org,
   demonstrate how this system can work. For more details about dual licensing,
   visit the GNU GPL Frequently Asked Questions page at the following url:
   http://www.gnu.org/licenses/gpl-faq.html
   
Q: Does the GNU/GPL license apply to the HTML generated by a Drupal site?
A: No. It is the intent of the Drupal developers that the license apply to Drupal,
   as well as any modules, theme engines, or PHP theme code written to interact
   with it. The OUTPUT generated by a live Drupal site -- including CSS, HTML,
   images and other media files, as well as Javascript code used by a theme --
   is NOT automatically released under the same license simply because it
   is sent from the server to a user's browser.

   Any file checked into the Drupal CVS repository, of course, is automatically
   released under the GPL for public use.

Lekei, the additions you mention are not, in fact, correct. Specifically:

It is sad that the concensus is that there will never be professionally developed themes for Drupal.... proprietary themes and modules for clients are forbidden.

This is a grave misunderstanding on your part; others have corrected you very clearly and explicitly, but you haven't yet 'gotten the picture.' Please stop repeating it. It is demonstrably untrue, judging by the fact that there are innumerable custom-designed non-distributed themes in use by Drupal sites around the world.

If you as a consultant create a Drupal theme, and give it to your client, it has been 'distributed.' But no one can force either of you to continue distributing it. That means that the only way someone can obtain that custom theme is 1) convincing your client to give it to them, 2) convincing you to give it to them, or 3) hacking into the client's server and downloading it. 3) is already illegal, so I'm not particularly worried about that.

There is one specific point of confusion that I believe will need investigation and clarification outside this patch/issue: If you purchase a third-party HTML template that is not released under a GPL-compatible license, and mix its HTML into PHP code for a Drupal theme, the licensing status of the resulting template file is sketchy. That issue, and that issue alone, is the one that I believe still requires further consultation with qualified GPL experts and (possibly) an addendum to the license similar to BISON's.

Given the points of confusion I've outlined, and the nature of the existing FAQ entries, I would say that the two additions you've proposed would be factually incorrect and very misleading.

lekei, thanks for the clarification.

Part of the trickiness of dealing with licenses is the fact that subtle turns of phrases can have VERY different meanings legally. Heck, if that weren't the case none of us would be confused about the GPL. :-)

In other threads, it's been hashed through that:

1. If anything is checked into the Drupal CVS, it must be released under the GPL
2. If a module or theme interacts directly with Drupal's code (calling functions, etc), its executable code must be released under a GPL-compatible license (See this andthis this for clarification and examples)

I think we're making some progress here, and I'm encouraged by that. One thing I would request, though: the special case we're both talking about, in which a copyrighted non-GPL HTML template is purchased and rolled into PHPTemplate documents... can we come up with a more explicit way of referring to that, to avoid confusion? Perhaps "Commercial third-party HTML templates." That's not TOO awkward, and it helps keep things separate from the other simpler cases (module and theme PHP code, third-party DHTML and PHP libraries that are separate but linked, etc).

Thanks!

lekei,

It's my personal preference that as few aspects of the GPL be touched on as possible in these clarifications. Mostly for simplicity's sake. I'll reiterate that the three areas we're talking about are:

1. Modules and themes that make use of non-GPL code libraries - The modules and themes in question can be released under a GPL-compatible license like the LGPL that allows the use of third-party libraries without modification, as long as the third-party libraries are NEVER checked into the Drupal CVS. No license changes are necessary, people just need to be told how this is done.
   
2. HTML output by Drupal sites - It's been made clear by everyone involved in the Drupal project -- including the most vigorous advocates of the GPL -- that HTML generated and transmitted by a site is NOT GPL'd, and falls into the same category as image files, CSS files, etc, even if chunks of the HTML appear in the theme or module code. In this case, a FAQ would be handy and a license clarification MAY be useful.
   
3. Themes and modules that contain, in their own code files, copyrighted non-GPL material like closed-source HTML templates - The consensus in the Drupal community (even among vigorous strict GPL advocates) is that the copyrighted HTML inside those themes is not automatically GPL'd, or at least should not be. Clearly articulating this in as simple a way as possible is difficult, but important. It will probably require an addendum to the LICENSE as well as the FAQ.

The first two issues, I think, are pretty much solved by this patch, though #2 could probably use an additional handbook page to explain the details. #3 is the tricky one. I'd like to suggest the following: an addendum to the license noting that HTML-generating theme functions can be considered separate works if they were covered by a pre-existing GPL-incompatible license, as long as they are clearly marked as such and contained in their own files to separate them from the GPL-compatible content. That would cover, for example, PHPTemplate .tpl files and separate theme.inc files for modules. I know that you've mentioned the hassle of keeping 'everything separate', but as someone who's broken modules up into admin.inc, theme.inc, and so on before I can say that it's a small burden and the long-term benefit of keeping the GPL content clearly separate from the non-GPL content is a great boon.

This doesn't relate, at least IMO, to client/contractor relationships at all. Adding that issue would confuse matters.

Thoughts? Anyone?