[documentation] [Documentation feature] CVS: Update FAQ.txt to
clarify the impact of GPL on HTML output
Eaton
drupal-docs at drupal.org
Mon Mar 27 18:39:47 UTC 2006
Issue status update for
http://drupal.org/node/53242
Post a follow up:
http://drupal.org/project/comments/add/53242
Project: Documentation
Version: <none>
Component: Misc
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: Eaton
Updated by: Eaton
Status: patch (code needs review)
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:
* *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.
* *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.
* *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?
Eaton
Previous comments:
------------------------------------------------------------------------
Thu, 09 Mar 2006 19:44:55 +0000 : Eaton
Attachment: http://drupal.org/files/issues/FAQ.txt.patch (901 bytes)
There's been a lot of confusion over the implications of Drupal's GPL
license. In particular, the question of whether HTML output from a
Drupal site is automatically GPL'd. Ideally, this would be included
somewhere in the drupal core distro, but for now a quick addition to
the FAQ.txt file found in the CVS /contributions directory can help.
+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 theme code written to
interact with it.
+ The output generated by that code on a live site, however, is not
automatically
+ released under the same license.
Wording can probably be improved, but based on all the discussions that
have floated around and all the folks that have participated in them, I
think it would be very helpful.
------------------------------------------------------------------------
Wed, 22 Mar 2006 18:01:51 +0000 : RayZ
+10 ... er +1 on adding this to FAQ.txt.
------------------------------------------------------------------------
Wed, 22 Mar 2006 18:34:21 +0000 : lekei
-1 This wording explicitly states that no licensed code may be used in a
theme or module.
------------------------------------------------------------------------
Wed, 22 Mar 2006 18:55:02 +0000 : Eaton
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.
------------------------------------------------------------------------
Wed, 22 Mar 2006 19:07:44 +0000 : RayZ
+1 The updated version in #3 is a definite improvement. An official
clarification like this is long overdue.
------------------------------------------------------------------------
Wed, 22 Mar 2006 22:34:01 +0000 : Eaton
Attachment: http://drupal.org/files/issues/FAQ.txt_0.patch (2.54 KB)
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.
------------------------------------------------------------------------
Sat, 25 Mar 2006 08:10:52 +0000 : lekei
+0.5 I think this is an excellent clarification.
It is sad that the concensus is that there will never be professionally
developed themes for Drupal, but two more faq questions would at least
make it possible to develop Drupal sites using all of the tools at your
disposal:
Q: Does work for a client constitute distribution?
/Currently work for a client where all of the result is not considered
"work product" is considered disribution by the GPL, hence proprietary
themes and modules for clients are forbidden./
Q: Does work on a team constitute distribution?
/Currently work on a team which is not all or part of a corporate
entity is considered disribution by the GPL, hence proprietary themes
and modules for clients are forbidden./
------------------------------------------------------------------------
Sat, 25 Mar 2006 08:33:20 +0000 : Eaton
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.
------------------------------------------------------------------------
Sat, 25 Mar 2006 09:06:51 +0000 : lekei
Sorry for the confusion.
The two questions are the points that I was suggesting to address.
The parts in italics are not intended to suggest the answers in the
faq. Those are the default interpretatons of the GPL as stated in the
GPL FAQ and from the open source licencing experts that I asked.
And the part about professionally developed themes was not themes
developed by professionals, themes that I can buy for a client's site
(from a template supplier) and tweak for them rather than having to do
the whole thing from scratch.
------------------------------------------------------------------------
Sat, 25 Mar 2006 09:38:51 +0000 : Eaton
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:
* If anything is checked into the Drupal CVS, it must be released under
the GPL
* 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 [1] andthis [2] 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!
[1] http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible
[2] http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
------------------------------------------------------------------------
Sat, 25 Mar 2006 10:26:30 +0000 : lekei
The simple solution would be to have a Linux-like preamble to say
templates are the normal use of Drupal.
Since that won't fly, mabe a faq entry that work for hire does not
constitute distribution? See if that floats?
------------------------------------------------------------------------
Mon, 27 Mar 2006 04:36:19 +0000 : cel4145
"work for hire does not constitute distribution?"
I might be misinterpreting where you are going with this, but I'd
verify any talk about what can be done with work for hire and what
"distribution means." Copyright covers all copies, and most developers
work with the code on a local setup or some location other than the
place it is intended to run in a production site. They have to copy it
to move it to a production site. Thus I would wonder whether or not
legally the GPL requires something worked on in one location and moved
to another to be GPL'd if it interacts with GPL'd code, regardless of
where or not one is working for someone else under work for hire.
Notice what the GPL FAQ says about third parties [3]. Is a work for
hire situation a third party? Like I said, I'd research it before
including any information about work for hire and the GPL in the FAQ.
[3] http://www.gnu.org/licenses/gpl-faq.html#TheGPLSaysModifiedVersions
------------------------------------------------------------------------
Mon, 27 Mar 2006 17:38:33 +0000 : lekei
Since the strictest interpretation of the GPL means that what you can
and cannot do in a Drupal site is determined by the relationship
between people who work on and fund the site. If this strict
interpretation is not the intention of the authors, a simple faq entry
would suffice in clarifying it.
More information about the documentation
mailing list