ttw+drupal@cobbled.net skrev:
On 31.08-17:52, Thomas Barregren wrote: [ ... ]
The issue original brought up by Jeff Eaton was about the fact that it is not permissible to write modules that bridge software with a license not compatible with GPL.
[ ... ]
You surprise me. GPL has been around for *18 years* and this reciprocity (a.k.a. "copyleft") is the very heart of the license.
[ ... ]
Wrong. You are allowed to integrate GPL-application with any non-GPL application.
i believe you contradict yourself. the issue is the extension of GPL to include interfacing software, as below
No, I don't contradict myself. :-) The first snippet was meant to bring the discussion back to the original issue: what regulations applies to a module that tries to bridge GPLed code with non-GPLed code. I was a little careless in my choice of words. I should have written "distribute" instead of "write". Thus, the correct wording should have been: "The issue original brought up by Jeff Eaton was about the fact that it is not permissible to *distribute* modules that bridge software with a license not compatible with GPL." The third snippet states a fact. You are allowed to integrate GPL-application with any non-GPL application. I could perhaps have added that this right doesn't imply a right to also distribute the resulting derived work. But I didn't, because I thought it is a corollary of the following paragraph in my answer (which you didn't quote). I don't understand what the second snippet has to d with my alleged contradiction.
[ ... ]
* to study and modify the program.
--unless, of course, you want to bridge it with a non-GPL application, apparently.
Wrong. You are allowed to study and modify the program for any reason, including for the purpose of bridging it with non-GPL application.
[ ... ]
So, to solve the problem that the licensing of Drupal currently force us to "dumbing down" or "bypassing of established application methodologies", I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks.
if you are allowed to study and modify the program for the purpose of bridging it with non-GPL code then there is no cross pollination of the licenses. this has traditionally been done (i.e. the use of GPL'd header files in compilation) but often brought under question by more aggressive GPL proponents.
You are allowed to study and modify the program as much as you want. No GPL proponents, aggressive or not, say something else (if they know what they are talking about). But, to *distribute* the derived work, you must license the derived work under GPL. If you cannot do that, for instance because you have integrated code under a license not compatible with GPL, you are not allowed to distribute it. But you may still use it.
i think the original author is confused about the exact status of GPL, especially, in relation to something like hooks where, it would appear to me, there is no issue. essentially, i see no reason you could not interface an application using hooks and keep that application propiertory. Generally, you cannot "interface an application using hooks and keep that application propiertory" as explained here:
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MoneyGuzzlerInc But, as this discussion is about, this can also pose a hindrance for situations where it can seem reasonable to include software with license not compatible with GPL. For an example, imagine someone who has put in a lot of effort to write code that integrates a popular but proprietary software with Drupal. So far it is okay under GPL. But now he wants to share his effort with the community. Since the integration code calls functions and share data structures with both the proprietary software and Drupal, it is not allowed. Fortunately, there is a solution. As long as you don't revoke any rights granted by GPL, you can add your own terms and conditions. This can be used to allow integration with software under a license incompatible with GPL. Two examples on this: * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib... * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControl... So, to solve the problem with bridging modules integrating 3rd party integration, I suggest that the Drupal licensing is supplemented with an exception for module developers linking through hooks. Best regards, Thomas