|
[Documentation feature] CVS: Update FAQ.txt to clarify the impact of GPL on: msg#00118php.drupal.documentation
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: Documentation in CVS Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Eaton Updated by: grohk Status: patch (ready to be committed) Looks good to me. Two small nits (which are not big enough to warrant holding this patch back): 1) CVS is capitialized differently in places in the patch. 2) Do we need to make it clearer that files checked into the repository need to be legally unencumbered and GPL compatible (in a way in which they can be relicensed as GPL) in order to be uploaded in the first place? grohk 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. ------------------------------------------------------------------------ Mon, 27 Mar 2006 18:39:46 +0000 : Eaton 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? ------------------------------------------------------------------------ Tue, 28 Mar 2006 16:33:48 +0000 : RayZ I agree that this patch covers the first 2 issues mentioned by Eaton in #13. I think this is RTBC, unless there are serious objections to doing so in the next few days. I suggest we (Eaton?) open a separate issue for the third item. -- Pending work: http://drupal.org/project/issues/documentation/ List archives: http://lists.drupal.org/pipermail/documentation/ |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | [Documentation bug] Instructions for .htaccess are overly complicated and unnecessary: 00118, Morbus Iff |
|---|---|
| Next by Date: | CVS-level documentation: 00118, Neil Drumm |
| Previous by Thread: | [Documentation bug] Instructions for .htaccess are overly complicated and unnecessaryi: 00118, krestivo |
| Next by Thread: | CVS-level documentation: 00118, Neil Drumm |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |