Modules that integrate non-GPL PHP apps violate the GPL.

[Jeff Eaton]

On Aug 31, 2007, at 11:40 AM, David Strauss wrote:

> The license itself says, "Everyone is permitted to copy and distribute
> verbatim copies of this license document, but changing it is not
> allowed." Paragraph 6 says nothing about producing a modified  
> version of
> the GPL. MySQL's exception is rendered as a separate exception  
> document,
> not a modification of the GPL. This distinction is important because
> people redistributing the code aren't obligated to allow the  
> exceptions
> granted by the original licensor.
>
> So, I stand by my statement that, "Direct GPL variants are only  
> allowed
> with approval of the FSF." See the AGPL for an example of an approved
> variant.

The 'exception document' is an interesting idea, and I'd like to  
explore this concept further with some advice from the FSF. We don't  
want to create an altered version of the GPL (obviously), but I  
wonder if the exception document would make sense to include in  
Drupal's default download, clarifying some things like the status of  
theme template files, 'intermediate' integration modules, etc.

As noted by the FSF, however, it's difficult to open the door to  
integration modules 'officially' without opening the door to closed-
source modules. It becomes easy for someone to simply build their  
functionality as a closed source module, and wrap it in a  
'compatibility layer' rather than engaging with the community and  
participating in the sharing of code and resources that has made the  
Drupal world thrive.

--Jeff

[Boris Mann]

On 8/31/07, Jeff Eaton <jeff@...> wrote:

> *** If you can, at any point, call debug_backtrace() and see BOTH
> drupal functions AND functions from a non-GPL-compatible piece of
> software, the terms of the GPL are being violated. ***

Let me amend / extend this -- They are being violated, if and only if,
you distribute the code.

--
Boris Mann
Office 604-682-2889
Skype borismann
http://www.bryght.com

[Jeff Eaton]

On Aug 31, 2007, at 3:33 PM, Boris Mann wrote:

> On 8/31/07, Jeff Eaton <jeff@...> wrote:
>
>> *** If you can, at any point, call debug_backtrace() and see BOTH
>> drupal functions AND functions from a non-GPL-compatible piece of
>> software, the terms of the GPL are being violated. ***
>
> Let me amend / extend this -- They are being violated, if and only if,
> you distribute the code.

This is very true. It's also important to keep in mind that the FSF  
gets annoyed when people distribute code that "Is GPL Compliant, Wink  
Wink Nudge Nudge" but doesn't actually do anything until you put it  
in the presence of non-GPL code.

So, while the GPL wouldn't prevent someone from whipping up a  
compatibility module themselves or a one-off module like that for a  
client, the FSF would consider it a violation of the GPL if that  
person distributed the resulting module with a see-no-evil "Well,  
it's just some code I wrote, people might install X and Y together,  
but how am I to know?" excuse.

--Jeff

[David Timothy Strauss]

Jeff Eaton wrote:

> This is very true. It's also important to keep in mind that the FSF gets
> annoyed when people distribute code that "Is GPL Compliant, Wink Wink
> Nudge Nudge" but doesn't actually do anything until you put it in the
> presence of non-GPL code.
>
> So, while the GPL wouldn't prevent someone from whipping up a
> compatibility module themselves or a one-off module like that for a
> client, the FSF would consider it a violation of the GPL if that person
> distributed the resulting module with a see-no-evil "Well, it's just
> some code I wrote, people might install X and Y together, but how am I
> to know?" excuse.

To avoid this sort of GPL Hell, we have very specific terms on which we
work with clients:

(1) The client owns the work we do specifically for them.

(2) The client licenses .module files and their dependencies back to us
under the GPL, version 2, and all future versions as published by the FSF.

The terms of (2) mean their internal staff can contribute to the
project, but the final working modules are licensed back to us in a
GPL-clean way that allows us to return the work to the community.

[Laura Scott]

On Aug 31, 2007, at 2:56 PM, David Strauss wrote:

> Jeff Eaton wrote:
>> This is very true. It's also important to keep in mind that the  
>> FSF gets
>> annoyed when people distribute code that "Is GPL Compliant, Wink Wink
>> Nudge Nudge" but doesn't actually do anything until you put it in the
>> presence of non-GPL code.

The no-distribution loophole seems to contradict what was quoted  
earlier, but if true that's very reassuring. Thanks. The not-
permitted- even-if-not-distributed thing was what sounded so alarming.

It's a darned shame though that a GPL module that enhances a free-
standing GPL system (e.g., a module that bridges Drupal with an  
outside system) is lumped together with a "GPL" widget that is wholly  
dependent upon a proprietary system. The former is what I would  
consider a powerful enhancement of another existing GPL system, while  
the latter is clearly a licensing gimmick to get away with something.  
And yet legally they should be considered the same? Ouch!

Hypothetical: Could one argue that the GPL bridging module that  
bridges, say, Drupal and ASP.NET does not depend upon the proprietary  
system in order to be there and available for Drupal? I mean, if I  
can, for example, see the module active and available in the Drupal  
admin area, even if the ASP site is not connected, would not that  
module be considered as not requiring a proprietary system to run?

> To avoid this sort of GPL Hell, we have very specific terms on  
> which we
> work with clients:
>
> (1) The client owns the work we do specifically for them.
>
> (2) The client licenses .module files and their dependencies back  
> to us
> under the GPL, version 2, and all future versions as published by  
> the FSF.
>
> The terms of (2) mean their internal staff can contribute to the
> project, but the final working modules are licensed back to us in a
> GPL-clean way that allows us to return the work to the community.
>

That's a very interesting contractual approach. Thanks for sharing that!

Laura

[Earnie]

Quoting Thomas Barregren <thomas@...>:

>
> Could you please explain this "legal difference".
>

LGPL libraries allows for use of the binary version of that library by
other binaries without infecting the using binary with the GPL while
GPL libraries (static or dynamic linked) force the GPL on the binaries
using the library.  There is no difference for distribution of the LGPL
binary or source.  Note, the libstdc++ library adds other statements of
use so that you can include its header files in your proprietary source
with infecting that source or binary with the GPL.

I find it amusing that a discussion of "non-GPL *PHP* apps" is ensuing
because PHP itself isn't L/GPL.  I would almost label this thread as an
example of oxymoron.  But, however, my use of the Drupal API (a CMS
library covered by a version of the GPL license) requires that my
source also be GPL.  If my code can be used without the Drupal library
then that requirement doesn't fit and I am free to license as I please.
  If my source requires another library that isn't GPL but still
requires Drupal (a GPL licensed library) then I am still forced to
cover my source with GPL.  My use of the non-GPL licensed library does
not force Drupal to the license of the other library.  My use of the
non-GPL licensed library along with Drupal doesn't force my code to be
covered by the other library either unless it is ``copyleft'' as well
in which case I'm screwed.

All-in-all, I can use Drupal along with all of the other programs I
use.  Drupal CVS can store contributed modules even if it includes
non-GPL modules without affecting Drupal since the contribution isn't
required to execute Drupal.  No one can force me to not use GPL
alongside non-GPL or force me to not use GPL on Windows or any other
proprietary system.

Earnie

[Earnie]

Quoting Jeff Eaton <jeff@...>:

>
> *** If you can, at any point, call debug_backtrace() and see BOTH  
> drupal functions AND functions from a non-GPL-compatible piece of  
> software, the terms of the GPL are being violated. ***
>

Then any project that uses PHP and claims to be GPL is violating the
terms of the GPL as a rule of thumb.  PHP isn't GPL licensed[1] and its
functions are viewable in a debug_backtrace().

[1] http://www.php.net/license/3_01.txt

Earnie

[Thomas Barregren]

ttw+drupal@... 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#GPLIncompatibleLibs 

 *
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControlledInterface 


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

[Thomas Barregren]

Earnie Boyd skrev:

>
>
> Quoting Jeff Eaton <jeff@...>:
>
>>
>> *** If you can, at any point, call debug_backtrace() and see BOTH  
>> drupal functions AND functions from a non-GPL-compatible piece of  
>> software, the terms of the GPL are being violated. ***
>>
>
> Then any project that uses PHP and claims to be GPL is violating the
> terms of the GPL as a rule of thumb.  PHP isn't GPL licensed[1] and
> its functions are viewable in a debug_backtrace().

First, it is just a rule of thumb. (And a darn good one IMHO.)

Second, this situation is explained in the GPL FAQ:

 
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#InterpreterIncompat

Third, the best solution would be is Drupal included a FLOSS Exception:

 
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLibs

A good example of this is MySQL FLOSS Exception:

  http://www.mysql.com/company/legal/licensing/foss-exception.html

Best regards,
Thomas

[Thomas Barregren]

David Strauss skrev:

> Jeff Eaton wrote:
>  
>> This is very true. It's also important to keep in mind that the FSF gets
>> annoyed when people distribute code that "Is GPL Compliant, Wink Wink
>> Nudge Nudge" but doesn't actually do anything until you put it in the
>> presence of non-GPL code.
>>
>> So, while the GPL wouldn't prevent someone from whipping up a
>> compatibility module themselves or a one-off module like that for a
>> client, the FSF would consider it a violation of the GPL if that person
>> distributed the resulting module with a see-no-evil "Well, it's just
>> some code I wrote, people might install X and Y together, but how am I
>> to know?" excuse.
>>    
>
> To avoid this sort of GPL Hell, we have very specific terms on which we
> work with clients:
>
> (1) The client owns the work we do specifically for them.
>
> (2) The client licenses .module files and their dependencies back to us
> under the GPL, version 2, and all future versions as published by the FSF.
>
> The terms of (2) mean their internal staff can contribute to the
> project, but the final working modules are licensed back to us in a
> GPL-clean way that allows us to return the work to the community.

The other way around works as well. You can keep the intellectual
property rights yourself and license the software under GPL to your
customer.

Regards,
Thomas

[David Timothy Strauss]

Thomas Barregren wrote:

>> To avoid this sort of GPL Hell, we have very specific terms on which we
>> work with clients:
>>
>> (1) The client owns the work we do specifically for them.
>>
>> (2) The client licenses .module files and their dependencies back to us
>> under the GPL, version 2, and all future versions as published by the
>> FSF.
>>
>> The terms of (2) mean their internal staff can contribute to the
>> project, but the final working modules are licensed back to us in a
>> GPL-clean way that allows us to return the work to the community.
>
> The other way around works as well. You can keep the intellectual
> property rights yourself and license the software under GPL to your
> customer.

Doing it that way requires that the client transfer ownership of even
their own employees' work on the project back to us. That's a lot harder
to convince a client to do considering that they're paying you to do the
work.

If we desired the ability to relicense work, we would probably still use
the scheme I mentioned but with a BSD (or similar) license.

[Laura Scott]

On Aug 31, 2007, at 4:48 PM, Thomas Barregren wrote:

>> To avoid this sort of GPL Hell, we have very specific terms on  
>> which we
>> work with clients:
>>
>> (1) The client owns the work we do specifically for them.
>>
>> (2) The client licenses .module files and their dependencies back  
>> to us
>> under the GPL, version 2, and all future versions as published by  
>> the FSF.
>>
>> The terms of (2) mean their internal staff can contribute to the
>> project, but the final working modules are licensed back to us in a
>> GPL-clean way that allows us to return the work to the community.
>
> The other way around works as well. You can keep the intellectual  
> property rights yourself and license the software under GPL to your  
> customer.

Does it? That's the real bone of contention in this thread, at least  
for me and I suspect not a few others. I guess that whether licensing  
the result of consulting/development work that is *not* work-for-hire  
constitutes "distribution."

Laura

[Jeff Eaton]

On Aug 31, 2007, at 4:31 PM, Laura Scott wrote:

> Hypothetical: Could one argue that the GPL bridging module that  
> bridges, say, Drupal and ASP.NET does not depend upon the  
> proprietary system in order to be there and available for Drupal? I  
> mean, if I can, for example, see the module active and available in  
> the Drupal admin area, even if the ASP site is not connected, would  
> not that module be considered as not requiring a proprietary system  
> to run?


Well, since ASP.NET isn't running as PHP code, it's almost certain  
that it would involve some sort of clean XMLRPC gateway or RESTful  
interface. Or do you mean, Drupal running on ASP.NET? The latter  
would, I believe, fall under the OS/system libraries clauses that  
Thomas Barregren has linked to a number of times. Carefully exploring  
that clarified a couple of the "Wait, but, does that mean..." kinds  
of questions I was posing to the FSF folks.

--Jeff

[Thomas Barregren]

Laura Scott wrote:

> On Aug 31, 2007, at 2:56 PM, David Strauss wrote:
>
>> Jeff Eaton wrote:
>>> This is very true. It's also important to keep in mind that the FSF
>>> gets
>>> annoyed when people distribute code that "Is GPL Compliant, Wink Wink
>>> Nudge Nudge" but doesn't actually do anything until you put it in the
>>> presence of non-GPL code.
>
> The no-distribution loophole seems to contradict what was quoted
> earlier, but if true that's very reassuring. Thanks. The
> not-permitted- even-if-not-distributed thing was what sounded so alarming.

You must have misunderstood this part. You are permitted to do what ever
you want with a GPLed code as long as yo don't distribute it. But, if
you distribute the code, with or without modifications, you must do that
under GPL. It is as simple as that.

> It's a darned shame though that a GPL module that enhances a
> free-standing GPL system (e.g., a module that bridges Drupal with an
> outside system) is lumped together with a "GPL" widget that is wholly
> dependent upon a proprietary system. The former is what I would
> consider a powerful enhancement of another existing GPL system, while
> the latter is clearly a licensing gimmick to get away with something.
> And yet legally they should be considered the same? Ouch!
>
> Hypothetical: Could one argue that the GPL bridging module that
> bridges, say, Drupal and ASP.NET does not depend upon the proprietary
> system in order to be there and available for Drupal? I mean, if I
> can, for example, see the module active and available in the Drupal
> admin area, even if the ASP site is not connected, would not that
> module be considered as not requiring a proprietary system to run?

Suppose you have a GPLed program A and another program B. The fact that
A depends on B (or vice versa) is not enough to trigger the requirement
that B also is GPLed. For an example it is perfect legal to let B be non
GPLed if A use fork and exec and similar mechanisms to call B. A special
case of this proviso is the "web service loophole". It is only if A uses
a function, an object or some other internals of B, or vice versa, that
B is required to be GPLed. Thus, for any construction where A and B can
collaborate without knowing or assuming anything about each others
internals, it is acceptable that B isn't GPLed.

So, if you want to build a module that can be used to integrate a
software with a license incompatible with GPL, I *believe* that a
solution is to build a GPLed Service Provider Interface (SPI) which
makes no assumption about the internals of the service providers.

Regards,
Thomas

[Thomas Barregren]

Laura Scott skrev:

>
> On Aug 31, 2007, at 4:48 PM, Thomas Barregren wrote:
>
>>> To avoid this sort of GPL Hell, we have very specific terms on which we
>>> work with clients:
>>>
>>> (1) The client owns the work we do specifically for them.
>>>
>>> (2) The client licenses .module files and their dependencies back to us
>>> under the GPL, version 2, and all future versions as published by
>>> the FSF.
>>>
>>> The terms of (2) mean their internal staff can contribute to the
>>> project, but the final working modules are licensed back to us in a
>>> GPL-clean way that allows us to return the work to the community.
>>
>> The other way around works as well. You can keep the intellectual
>> property rights yourself and license the software under GPL to your
>> customer.
>
> Does it? That's the real bone of contention in this thread, at least
> for me and I suspect not a few others. I guess that whether licensing
> the result of consulting/development work that is *not* work-for-hire
> constitutes "distribution."

For consulting there is at least three different ways to do it:

  * The David Strauss way (which is very nice)
  * The other way around (as I described)
  * The neighbourly way

By "the neighbourly way" I allude on "the freedom to redistribute copies
so you can help your neighbor (freedom 2)". You download Drupal and
distribute it without modifications to your customer. Then you help your
customer to integrate their copy of Drupal with the non-GPLed software.
Since the derived work never is distributed it is not a violation of GPL.

Regards,
Thomas

[Gerhard Killesreiter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Laura Scott schrieb:

>
> On Aug 31, 2007, at 4:48 PM, Thomas Barregren wrote:
>
>>> To avoid this sort of GPL Hell, we have very specific terms on which we
>>> work with clients:
>>>
>>> (1) The client owns the work we do specifically for them.
>>>
>>> (2) The client licenses .module files and their dependencies back to us
>>> under the GPL, version 2, and all future versions as published by the
>>> FSF.
>>>
>>> The terms of (2) mean their internal staff can contribute to the
>>> project, but the final working modules are licensed back to us in a
>>> GPL-clean way that allows us to return the work to the community.
>>
>> The other way around works as well. You can keep the intellectual
>> property rights yourself and license the software under GPL to your
>> customer.
>
> Does it? That's the real bone of contention in this thread, at least for
> me and I suspect not a few others. I guess that whether licensing the
> result of consulting/development work that is *not* work-for-hire
> constitutes "distribution."

How can consulting/development work not be work for hire?

Cheers,
        Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG2KWpfg6TFvELooQRAuAIAKDERj5sflTc7W4xn6BH0wflmQxDswCfai+3
3N0vI35aZpYaG2uKrElVdBc=
=lt20
-----END PGP SIGNATURE-----

[Thomas Barregren]

David Strauss skrev:

> Thomas Barregren wrote:
>  
>>> To avoid this sort of GPL Hell, we have very specific terms on which we
>>> work with clients:
>>>
>>> (1) The client owns the work we do specifically for them.
>>>
>>> (2) The client licenses .module files and their dependencies back to us
>>> under the GPL, version 2, and all future versions as published by the
>>> FSF.
>>>
>>> The terms of (2) mean their internal staff can contribute to the
>>> project, but the final working modules are licensed back to us in a
>>> GPL-clean way that allows us to return the work to the community.
>>>      
>> The other way around works as well. You can keep the intellectual
>> property rights yourself and license the software under GPL to your
>> customer.
>>    
>
> Doing it that way requires that the client transfer ownership of even
> their own employees' work on the project back to us. That's a lot harder
> to convince a client to do considering that they're paying you to do the
> work.
>  

The other way around approach is easy to use if you can isolate a module
on which only your guys/gals work on. If the project team is a mix of
your and your customers employees, I think your approach (which I never
had though of - thank you) is better.

Regards,
Thomas

[Laura Scott]

On Aug 31, 2007, at 5:35 PM, Gerhard Killesreiter wrote:

> How can consulting/development work not be work for hire?

IANAL, but my understanding after a lot of years in business, is this:

In the US, "work for hire" is a legal phrase that implies that all  
you do is owned by your employer. That's how most employer/employee  
relationships are defined. However, most consulting and contracting  
jobs are not work for hire. The contractor does work under terms  
specified within the contract. Except for what is provided in the  
agreement, the contractor owns all of his/her own work.

Rather OT, but since you asked... ;)

Laura

[Thomas Barregren]

David Strauss skrev:

> Thomas Barregren wrote:
>  
>> Wrong. You are allowed to add ny terms and condition you which as long
>> as long as you don't impose any further restrictions on the recipients'
>> exercise of the rights granted in GPL. See paragraph 6 of GPL v2 (which
>> is used by Drupal). In fact, FSF/GNU tells you to add such notice to
>> allow use of non-GPL libraryies. Read the FAQ:
>>    
>
> The license itself says, "Everyone is permitted to copy and distribute
> verbatim copies of this license document, but changing it is not
> allowed." Paragraph 6 says nothing about producing a modified version of
> the GPL. MySQL's exception is rendered as a separate exception document,
> not a modification of the GPL. This distinction is important because
> people redistributing the code aren't obligated to allow the exceptions
> granted by the original licensor.
>
> So, I stand by my statement that, "Direct GPL variants are only allowed
> with approval of the FSF." See the AGPL for an example of an approved
> variant.
>  

It is true that the GPL itself cannot be modified without permission
from FSF. But you are entitled to add a notice to allow for instance
linking against non-GPLed libraries.

>>> I'm not sure that's a problem. The GPL only affects redistribution, not
>>> what a person does on his or her own computer. Just ensure the forbidden
>>> integration isn't distributed. (If I'm wrong here, I'd like to know.)
>>>      
>> Wrong. If a module depends on a software with a license not compatible
>> with GPL, then that module can't be distributed under GPL.
>>    
>
> If you're going to call someone "wrong," you had better be right:
>
> http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
>
> That FAQ item gives instructions for releasing something under the GPL
> that links to non-free libraries.
>  

Yes, but that is not what I claimed to be wrong. The problem lies in the
fact that Drupal.org distributes modules which depends on non-GPLed
code. That is not permitted, since Drupal.org doesn't have the proviso
described in the FAQ. (I would certain endorse a such proviso.)

Regards,
Thomas

On Friday 31 August 2007, Thomas Barregren wrote:

> Suppose you have a GPLed program A and another program B. The fact that
> A depends on B (or vice versa) is not enough to trigger the requirement
> that B also is GPLed. For an example it is perfect legal to let B be non
> GPLed if A use fork and exec and similar mechanisms to call B. A special
> case of this proviso is the "web service loophole". It is only if A uses
> a function, an object or some other internals of B, or vice versa, that
> B is required to be GPLed. Thus, for any construction where A and B can
> collaborate without knowing or assuming anything about each others
> internals, it is acceptable that B isn't GPLed.
>
> So, if you want to build a module that can be used to integrate a
> software with a license incompatible with GPL, I *believe* that a
> solution is to build a GPLed Service Provider Interface (SPI) which
> makes no assumption about the internals of the service providers.
>
> Regards,
> Thomas

So you are claiming, then, that a Drupal wrapper module for a non-GPLed system
that communicated only via REST calls (or similar) but still had no actual
function of its own without that non-GPLed system, is legal?

Just for the record, how many of the people in this thread actually *are*
lawyers? :-)

--
Larry Garfield AIM: LOLG42
larry@... ICQ: 6817012

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it."  -- Thomas
Jefferson