GPL policy: request for clarification
The GPL appears to allow us to combine GPL and "compatible" code in a single GPL-licensed package. Can we include such code in drupal.org CVS? This is a pressing issue because there is considerable interest in using external GPL-compatible but non-GPL Javascript libraries (Prototype, jQuery), at least in contrib and possibly as candidates for core. Our CVS policy states "All code must be licensed under GNU/GPL" (contributions README.txt). The practice has been to interpret this as meaning that open source libraries with "MIT" or similar licenses may not be included in Drupal CVS. However, the Free Software Project has designated a number of licenses, including the "MIT" license, as "compatible" with the GPL, because they impose no restrictions that conflict with the GPL, see http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses. The GPL FAQ specifically states, http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean, that the GPL permits you to "combine code released under the other [compatible] license with code released under the GNU GPL in one larger program" privided that "such a combination ... is released under the GNU GPL". In other words, apparently, we can GPL the combination of GPL code and code with compatible licenses. So, it appears, we should be free to include "MIT" and other compatible-licensed code in our CVS and releases, provided we make it clear we are thus GPL-ing the combination. So, can we go ahead and put such combinations in CVS? Can we consider/propose them for core?
On Sun, 28 May 2006 21:28:00 -0700 Nedjo Rogers <nedjo@islandnet.com> wrote:
The GPL appears to allow us to combine GPL and "compatible" code in a single GPL-licensed package. Can we include such code in drupal.org CVS?
This is a pressing issue because there is considerable interest in using external GPL-compatible but non-GPL Javascript libraries (Prototype, jQuery), at least in contrib and possibly as candidates for core.
Our CVS policy states "All code must be licensed under GNU/GPL" (contributions README.txt).
The practice has been to interpret this as meaning that open source libraries with "MIT" or similar licenses may not be included in Drupal CVS.
However, the Free Software Project has designated a number of licenses, including the "MIT" license, as "compatible" with the GPL, because they impose no restrictions that conflict with the GPL, see http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses. The GPL FAQ specifically states, http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean, that the GPL permits you to "combine code released under the other [compatible] license with code released under the GNU GPL in one larger program" privided that "such a combination ... is released under the GNU GPL".
In other words, apparently, we can GPL the combination of GPL code and code with compatible licenses. So, it appears, we should be free to include "MIT" and other compatible-licensed code in our CVS and releases, provided we make it clear we are thus GPL-ing the combination.
According to a GPL Compliance Engineer from the FSF this is correct. I specifically wrote them to ask about releasing a BSD licensed module, and he confirmed that when released together with Drupal the collection was GPL'd, but when my module was downloaded on its own it had the additional permissions allowed under the less restrictive BSD license. http://lists.drupal.org/archives/documentation/2005-07/msg00054.html
So, can we go ahead and put such combinations in CVS?
Can we consider/propose them for core?
I think the problem is when people commit changes into CVS -- then there is question as to whether the changes are under the GPL, or under the specific license of the module/library/whatever. All said, I'm very interested to hear additional feedback on your query. Cheers, -Jeremy
On 29 May 2006, at 06:28, Nedjo Rogers wrote:
Our CVS policy states "All code must be licensed under GNU/ GPL" (contributions README.txt).
While some licenses are compatible, we feel it is best not to mix licenses. Drupal.org's package management system automatically adds the GPL license to all packages. If we allow other licenses in CVS, it is going to get messy, and sooner or later we're going to run into licensing issues. Already, we get quite a few questions about Drupal's license. If we are going to add more licenses to the mix, it is going to be harder to audit, or provide answers to such questions. So, not allowing other licenses in CVS is a deliberate choice. We've also decided against mirroring other projects in our CVS repositories -- unless there are good reasons to do so. So when people need a Javascript library (as per your example), it is best to instruct them to download that library from that project's website. -- Dries Buytaert :: http://www.buytaert.net/
not allowing other licenses in CVS is a deliberate choice.
Thanks Dries for the explanation. This policy makes sense and I support it. Since the details and reason for this policy seem worthy of capturing for posterity, I've drafted a brief handbook page, http://drupal.org/node/66113.
Since the details and reason for this policy seem worthy of capturing for posterity, I've drafted a brief handbook page, http://drupal.org/node/66113.
A small addendum. The LGPL permits the relicensing of any single copy of an LGPL library from LGPL to GPL (article 3 of the LGPL, http://www.gnu.org/licenses/lgpl.html). In three cases in the Javascript Tools package (jscalendar, wforms, columns) I have relicensed LGPL libraries to GPL and included them in CVS. Other modules using LGPL code, e.g., TinyMCE, presumably could choose to do the same. This practice is in full compliance with the GPL. I assume it's also in full compliance with Drupal CVS policies, as the software in CVS has only one license, the GPL. If there are any issues with this approach, please speak up! Otherwise, I'll add a note on this to the Handbook page.
On 5/30/06, Nedjo Rogers <nedjo@islandnet.com> wrote:
Since the details and reason for this policy seem worthy of capturing for posterity, I've drafted a brief handbook page, http://drupal.org/node/66113.
A small addendum. The LGPL permits the relicensing of any single copy of an LGPL library from LGPL to GPL (article 3 of the LGPL, http://www.gnu.org/licenses/lgpl.html). In three cases in the Javascript Tools package (jscalendar, wforms, columns) I have relicensed LGPL libraries to GPL and included them in CVS. Other modules using LGPL code, e.g., TinyMCE, presumably could choose to do the same. This practice is in full compliance with the GPL. I assume it's also in full compliance with Drupal CVS policies, as the software in CVS has only one license, the GPL.
If there are any issues with this approach, please speak up! Otherwise, I'll add a note on this to the Handbook page.
There is an issue here, although it is in part up to the module maintainer. You *could* check third-party libraries with compatible licenses into CVS, but it's discouraged: the latest releases, bugfixes, security updates, and so on will always be maintained by the source distributor/maintainer of the library/package/whatever. It's "convenient" to have it one package, but it's more work for the maintainer to keep up with the upstream packages, and then be maintaining non-Drupal code in Drupal CVS. It's especially discouraged if the libraries are very large....this last factor is no longer as big an issue now that we have solid hosting/support. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
Nedjo Rogers wrote:
Since the details and reason for this policy seem worthy of capturing for posterity, I've drafted a brief handbook page, http://drupal.org/node/66113.
A small addendum. The LGPL permits the relicensing of any single copy of an LGPL library from LGPL to GPL (article 3 of the LGPL, http://www.gnu.org/licenses/lgpl.html). In three cases in the Javascript Tools package (jscalendar, wforms, columns) I have relicensed LGPL libraries to GPL and included them in CVS. Other modules using LGPL code, e.g., TinyMCE, presumably could choose to do the same. This practice is in full compliance with the GPL. I assume it's also in full compliance with Drupal CVS policies, as the software in CVS has only one license, the GPL.
If there are any issues with this approach, please speak up! Otherwise, I'll add a note on this to the Handbook page.
I am ok with the relicensing (but I know that Dries doesn't really like it), but what I am not ok with is that you included third party software in our cvs. This is generally not a good idea because people might not get the most recent version of the software that is available from the original author. It also bloats our cvs which already has more than half a GB. I know that this way of handling third party software has been used (and even occassionally enforced) for a long time, but I actually couldn't find it in the Terms or the FAQ. Could somebody write me a nice paragraph about it? Cheers, Gerhard
Op woensdag 31 mei 2006 09:49, schreef Gerhard Killesreiter:
I am ok with the relicensing (but I know that Dries doesn't really like it), but what I am not ok with is that you included third party software in our cvs.
The most often heard reason why people want to include 3rd party tools is "that it is easier for installation". What I am working at (and hopefully together with jmrenouard soon :)) is to develop a 3rdparty autopuller system. This is how RoR plugin/engines/tools/ets work in general, and I like it very well. After/during installation of a Drupal module, that module asks some 3rd party lib from some location. The install scripts (commandline, in our case) will pull them in from that remote site, unpack them etc. Hope this somehow defeats the "but it is easier for installation to have it all together" arguments. Bèr
On 5/31/06, Bèr Kessels <ber@webschuur.com> wrote:
The most often heard reason why people want to include 3rd party tools is "that it is easier for installation". What I am working at (and hopefully together with jmrenouard soon :)) is to develop a 3rdparty autopuller system.
Easier installation has two audiences: people doing lots of installations ("developers") and people doing one or two installations ever ("hobbyists").
Hope this somehow defeats the "but it is easier for installation to have it all together" arguments.
That argument is largely from the hobbyist, but your solution is only for people who have shell access on the server i.e. only the "developers". I'm not sure there is a really great solution - especially not for the hobbyist who doesn't want to learn the shell but does want to use 3rd party modules. Perhaps the CivicSpace started installer will provide some greater ease on this front? Or at least the fact that it will help making distros easier which will make bundling 3rd party code easier. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
Op woensdag 31 mei 2006 17:16, schreef Greg Knaddison - GVS:
I'm not sure there is a really great solution - especially not for the hobbyist who doesn't want to learn the shell but does want to use 3rd party modules.
My philosophy is: "Once you have proper commandline tools, or proper libraries, interfaces will grow around them". An interface in this particular Drupal case could be a plugin for plesk, or a one-ring-to-rule-them-all-drupal module (running off a special apache on a special port) that allows you to install modules on a huge flock of sites. Or a YaST module that allows you to install modules on your local server. Or apt-get/apt-reconfigure etc. And so on. Imagine being able to fire "adept", the Ubuntu installer: select Drupal, answer a range of questions in an ubuntu-configuration-wizard-thing, and then find yourself with a running, customised Drupal site! In the end that is far better for that hobbyist than any HTML installer built into drupal can ever be. The more because letting your PHP app write its own PHP (which is what webbased installers do) is considered extremely unsafe, and therefore dont work on a lot of hosting environments. (And IMO should work on even less environments :) ) Bèr
I'm not familiar with "adept", but I've seen how RubyGems works. It seems like a very good model to follow for command-line based installers/updaters. I'm sure it using some magic meta programming that can't be ported to php. Has anyone thought about using the PEAR installer? I heard alot of hype about it in the PHP community at one point, then it died down. I think http://pearified.com gives a list of a few channels already setup. We could create a drupal channel and have core, it's modules, and all the modules in contribs available through it. Then to install drupal core after they've "discovered" our channel, someone could do "pear install drupal/drupal_core". I believe it already has a bit of versioning/dependency checking built into it. I know that it is preferred to not rely on any third party projects, but (AFAIK) PEAR is supported with the official PHP project. If we do have to hack it to our needs, this could be a way to give back to the "mother project", so to speak. This could possibly lower the bar of entry to installing new modules. Following with Bèr's philosophy, a decent web-based module retriever/installer/updater could grow up around it allowing an administrator to update their site without ever leaving it. Those are my (likely over-ambitious) thoughts on this. On 5/31/06, Bèr Kessels <ber@webschuur.com> wrote:
Op woensdag 31 mei 2006 17:16, schreef Greg Knaddison - GVS:
I'm not sure there is a really great solution - especially not for the hobbyist who doesn't want to learn the shell but does want to use 3rd party modules.
My philosophy is: "Once you have proper commandline tools, or proper libraries, interfaces will grow around them".
An interface in this particular Drupal case could be a plugin for plesk, or a one-ring-to-rule-them-all-drupal module (running off a special apache on a special port) that allows you to install modules on a huge flock of sites. Or a YaST module that allows you to install modules on your local server. Or apt-get/apt-reconfigure etc. And so on.
Imagine being able to fire "adept", the Ubuntu installer: select Drupal, answer a range of questions in an ubuntu-configuration-wizard-thing, and then find yourself with a running, customised Drupal site!
In the end that is far better for that hobbyist than any HTML installer built into drupal can ever be. The more because letting your PHP app write its own PHP (which is what webbased installers do) is considered extremely unsafe, and therefore dont work on a lot of hosting environments. (And IMO should work on even less environments :) )
Bèr
I'm not familiar with "adept", but I've seen how RubyGems works. It seems like a very good model to follow for command-line based installers/updaters. I'm sure it using some magic meta programming that can't be ported to php. The meta programming is doable in php. In the end php is a template programming language of sorts. It just doesn't really help you with the task by hiding its strongest features very well indeed. With a bit of hackery you can have lisp-like macros in php, which is quite a powerful tool or a way to shoot your leg from the head down.
Has anyone thought about using the PEAR installer? I heard alot of hype about it in the PHP community at one point, then it died down. I think http://pearified.com gives a list of a few channels already setup. Having a drupal pear channel is a possibility and it should be doable, at least in theory, with the dependecies api. That could be of help to the more adept end-user. This would essentially be a delivery method. Unfortunately we have quite a few miles to go until we are concerned with the delivery.
We could create a drupal channel and have core, it's modules, and all the modules in contribs available through it. Then to install drupal core after they've "discovered" our channel, someone could do "pear install drupal/drupal_core". Yep, it can be done.
This could possibly lower the bar of entry to installing new modules. Following with Bèr's philosophy, a decent web-based module retriever/installer/updater could grow up around it allowing an administrator to update their site without ever leaving it. That is a good goal. But the required infrastructure is not there yet.
Those are my (likely over-ambitious) thoughts on this. Overy ambitious? You don't even reach the half of the Amsterdam pipe dreams we share with Adrian for a while. It's just putting our time where our dreams go is a bit hard.
participants (9)
-
Boris Mann -
Bèr Kessels -
Corey Bordelon -
Dries Buytaert -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Jeremy Andrews -
Nedjo Rogers -
Vladimir Zlatanov