Please add questions here to ask of the SFLC on behalf of the Drupal Association. Keep them short, specific, to the point, and phased as questions that can be directed at SFLC more or less verbatim. Also, please do not list questions that are easily answered on the SFLC web site.
Important links:
http://www.softwarefreedom.org/
Drupal.org specific issues
Question 1: A Drupal module is written that interfaces with Drupal (which is under the GPL) via PHP function calls, and interfaces with a 3rd party non-GPL system via PHP function calls. It does not include the 3rd party system in its distribution, but the 3rd party system is required for some or all functionality. Is it legal to distribute this module? --Crell and chx
jbatson: What does "...legal to distribute this module?" mean? Are you asking whether the Drupal module can be distributed in some way that is non-open-source (e.g. "compiled" PHP) only, and charge money for the software? Or are you asking whether the non-GPL 3rd-party software that is "distributed" (presumably in tandem with the Drupal module) becomes "entangled" by the Drupal GPL copyleft (e.g. must that 3rd-party PHP software be supplied as open source)? Or.... What??? (I actually am a licensed lawyer, though I don't practice. So I will try to help here by helping articulate the questions well.)
FYI, IMHO, I think the key question here will be: Does the 3rd-party non-GPL system execute its code in the same instance of the PHP interpreter as Drupal? GPL v2 was written to address such questions by applying a test that is the Unix-equivalent of fork/exec. If code Z runs in the same address space as code A, and code A is the code that "started the process," and code A is open source, code Z is covered by copyleft. If, on the other hand, code A did a fork/exec to create a new process with a new address space, code Z is not covered by copyleft.
So In the case of the question above, if the 3rd-party non-GPL system is being accessed by Drupal using PHP function calls, and these PHP function calls are being executed by the same instance of the PHP interpreter (that is running Drupal), and the logic of the code is being executed here (vs. in some application that has been forked/exec'd), I think there is a significant case to be made that the 3rd-party code is covered by the GPL copyleft, and must be open source. This is, IMHO, though.
I say these things NOT because they're intended to be a controlling interpretation; but to guide how the question can be re-stated in order to get an answer that is workable.
Question 2: A Drupal module is written that interfaces with Drupal (which is under the GPL) via PHP function calls, and interfaces with a 3rd party non-GPL system via some out-of-process mechanism (XML-RPC, SOAP, fopen(), HTTP/REST, etc.). It does not include the 3rd party system in its distribution, but the 3rd party system is required for some or all functionality. Is it legal to distribute this module? --Crell and chx
jbatson: IMHO, using the (informal) "same address space" test, I think the 3rd-party non-GPL system is NOT covered by copyleft. This is going to be a slippery-slope area for the GPL/FSF. If the FSF begins to assert that web services that are on the other side of an HTTP interface are "part of the same application," and covered by the GPL, it will be a significant issue for the entire technology industry, not merely Drupal. Again, IMHO (read "not controlling.") (In this case, this comment should be subject to deletion, since this comment serves no purpose regarding improving the question....)
pwolanin: as real-world examples, this group provides links to Drupal modules that does just this via SOAP (AFAIKT): http://groups.drupal.org/imis
TimCullen: like jbatson, I'm licensed, but not practicing, and want to help make sure we ask good questions of the good folks at the SFLC. I second jbatson's concern here about creeping copyleft for v3. One wrinkle to add to the question is whether the status of the 3rd-party + Drupal module interaction is altered by whether the call to the external services is made at at every page load, or whether "going out and getting data" is periodic and cached, or even whether data acquisition was successful at all. The point I'm getting at is wouldn't the input from the 3rd party application be more on the order of a config/data file and not a joint process from the perspective whether this interaction forms a derivative work?
Question 3: 3rd parties may be distributing Drupal bridged/integrated with non-FOSS PHP packages (e.g. vbDrupal) or a simply distributing modules that makes such a bridge. If the answer to #2 is that such bridging does that violate the GPL, what is the appropriate action to take with respect to these 3rd parties? --pwolanin
Crell: Isn't that the same thing as question 1?
pwolanin: partly, but this is focused on 3rd party distribution - rephrased to clarify.
jbatson: I'm not sure even the rephrasing makes this question different.... Can you clarify (in comments) what makes it different?
pwolanin: (note - questions have been re-ordered, I think). I took question #1 to be related to what policy d.o should have, while this question relates more to how we should deal with parties outside the d.o realm of control.
TimCullen: As will all copyrights (in the US at least), the right to sue for a copyright and/or a license violation rests with the owner of the copyright. From a preliminary perusal of the files, it's not clear who, if anyone is asserting copyright over the code. (According to the association, "The copyright of both the Drupal software [...] belongs to all the original authors, though both are licensed under the GPL.") That said, I'd amend the question to ask in addition, who would be the appropriate party(s) to take that action--could a single author with a copyrightable submission to a file being distributed be enough to commence legal action, or would we need everyone's assent? (see: section 5.3 here for a related discussion)
Question 4: Is Drupal licensed under GPL v2 or any GPL version? Drupal's about pages only mention GPL without specifying a version. Accompanying texts (and the source) mention nothing license wise -- there is a LICENSE.txt containing GPL v2. However, the original copyright holder has stated in 2006 that his intention was GPL v2. Drupal was originally released in 2001 and has since had hundreds of contributors.--chx
pwolanin: since there is no copyright notice, it's not even clear that the GPL has been effectively applied to Drupal at all. Certainly a plain reading of the GPL license strongly supports that assuming that Drupal is GPL licensed, it's currently licensed under any GPL version (1.0, 2.0, or 3.0). I see the option to use GPL 3.0 as nearly essential, since it means Drupal can "legally" be combined with GPL 3.0 or AGPL code (e.g. CiviCRM). see also: http://drupal.org/node/174226 and http://www.gnu.org/licenses/gpl-howto.html
Crell: IF that is indeed the case, pwolanin, I'd suggest making Drupal explicitly GPLv2 or later, which gives us the most flexibility and compatibility. That IF, however, has yet to be answered.
jbatson: There may be a thorny issue with code contributed at various points in time. However, I think the two controlling factors are these:
- When you sign up for CVS commit access, you have to click through an agreement saying "I will only commit code that is licensed under terms of the GNU public license, version 2". See http://drupal.org/cvs-account.
- The LICENSE.txt in the top-level directory of a Drupal tarball will be considered controlling, and this is GPL v2.
pwolanin: the GPL version 2 says that if the source does not specify a version, then it can be licensed under any GPL version. So, we have already been through the question of the version of the license being included, and I think that even though v2 is included, there is no indication (via a copyright statement) that we are restricted to only v2.
Quetion 5: What element of Themes are covered by the GPL's provisions? Themes consist of a set of php files that interact with Drupal and while that can and will be affected by the module decision above, themes are also comprised of graphics, css and the overall design itself. Is just the php elements or is the design covered under the GPL too. -sepeck
Crell: I think better phrasing here would be to state that a theme consists of some combination of in-process PHP, HTML, CSS, and graphics, then ask which would be covered by the GPL and which can be something else (e.g., CC).
Killes: I believe this topic is covered by the GPL FAQ.
Eaton: It's not answered in the GPL FAQ -- since CSS, JS, .info files, and so on are not in-process PHP, the FAQ is very much unclear. This may be something that is up to the Drupal community itself.
Question 6: I want to bundle a Flash component with Drupal (e.g. a rating widget, a calender widget or a map widget). Does the Flash binary have to be GPL? Do I need to include the Flash binary's "source code"?
killes: The answer of the second question follows from the answer for the first.
jbatson: The same thing probably applies to Javascript supplied to a browser by a Drupal instance. IMHO, I think 3rd-party-added Flash/Javascript is NOT covered by the Drupal license; this code does NOT run in the code address space of Drupal; it runs in the browser's address space.
TimCullen: I would add that it depends on the degree of interoperability--if the flash binary is making use of Drupal functions to retrieve and store data on the server, that might bring it within the ambit of the REST/SOAP discussion above.
Question 7: Does drupal.org (or all sites within this domain) need to post a notice regarding the copyright of contributed patches or code snippets in the issue queue, handbook, and forum? For example, CiviCRM has this: http://civicrm.org/licensing . For drupal.org, the project module could display a notice, or there could even be a checkbox required when attaching to a follow-up (e.g. "I confirm that none of the attached code is proprietary, and I agree to license it under the GPL").
The handbook has a license on the /handbooks page and a block with the handbook license on all book pages. (Creative Commons License, Attribution-ShareAlike 2.0.) -sepeck
Question 8: Is the Drupal core code and its modifications compliant to the conditions stipulated in the GPL v2? --earnie
Question 9: Are the proprietors of Drupal.org (or any other distributors of drupal code) liable if one of the contributors has in some way contributed proprietary, un-licensable or code which they didn't have rights to? --earnie
TimCullen: If there is the possibility of liability attaching, in what jurisdictions would we be most vulnerable, and what can we do going forward to remedy the situation. To what degree must Drupal.org (or the Drupal Association) police the contributed code?
matt2000: On a side note, assuming Tim's interpretation of the question, the Common Public License addresses this concern thoroughly. It is used by the OpenLaszlo project, and IBM. I don't know if this is considered compatible with the GPL. FYI, I revised the question per Tim, but preserved earnie's version in HTML comments.
Question 10: With the confusion about who owns the various copyrights to Drupal, does it make sense to begin building a list of copyright owners, both for past and future code submissions? If so, what are the best practices of other organizations? What data should be collected?
Question 11: How can the Drupal Community prevent abusive behavior from individual copyright owners? For example, can a theme developer be assured that an individual Core contributor can not claim copyright interest in his theme? Is it possible to declare universally that Themes and Modules may not be considered by any contributor as "Derivative Works" simply by virtue of their usefulness in a Drupal-based system? -matt2000
cf: http://groups.drupal.org/node/12624
Question 12: Drupal is GPLv2/3, CiviCRM 2.x is GNU AGPLv3. Drupal FAQ #11 explicitly states that even installing these two together would bring Drupal (and, one would assume, all installed modules) under the umbrella of the AGPL. CiviCRM's license FAQ explicitly states that accessing CiviCRM via its API's (and not altering CiviCRM source code) is sufficient to keep Drupal a "separate and independent program", and thus not be subject to the AGPL. Both opinions were prepared by/with council from the SFLC. Which is correct? --sethfreach
Consulting issues
Question 1: Does the mere act of writing a Drupal module (or theme, for the sake of argument) mean that that code is instantly virally GPL'd? Or is it the act of uploading it to Drupal's CVS server that GPLs it? [This article](http://jeff.viapositiva.net/archives/2006/02/drupal_and_the_gpl_as_i_und... Drupal as I understand it) implies it's the former, but if that's the case, then why does D.o tell us that we can only upload GPL-licensed modules to CVS? This implies that it's possible to license a module otherwise… -- Garrett Albright
matt2000: This is answered (poorly, IMO) by the FAQ #7, which claims that all Drupal modules ARE virally infected by the GPL, whether or not they are distributed via Drupal's CVS. You are correctly that d.o is inconsistent in its language, and wording in some places does imply that another option exists. I would very much like to see this resolved.