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

[Thomas Barregren]

Earnie Boyd skrev:

> Quoting Thomas Barregren <thomas@...>:
>
>> Earnie,
>>
>> You said that "...there is a legal difference between 'statically
>> linked'  and 'dynamically linked' (DLL) code." And "[t]hat's why the
>> GPL and LGPL exist as  two separate licenses."
>>
>
> I don't think that was me.  I did respond to the query to explain.

You are right. I am sorry. It was Larry Garfield who said that.

Best regards,
Thomas

[Jeff Eaton]

On Sep 2, 2007, at 9:43 AM, Darren Oh wrote:

> So far this whole discussion seems to be a case of ask the wrong  
> question, get the wrong answer. I have seen no evidence to suggest  
> that one cannot write some code that depends on non-free software,  
> release it under the GPL, and have the GPL apply to that code. What  
> would be against the spirit of the GPL would be to write code that  
> depends on GPL software and to release only a compatibility layer  
> under the GPL, keeping the main functionality non-free. Since 1)  
> the third-party apps that are being integrated do not depend on  
> Drupal and 2) the module authors do not own the rights to the code  
> in the third-party apps, this issue is irrelevant to the situation  
> under discussion.

I used to take this position as well, but it's apparent after quite a  
bit of research that this is based on loose use of the phrase  
"depends on" to define the terms of the discussion. The GPL doesn't  
use those words. It doesn't recognize a difference between a piece of  
software that *uses* a library, and the library that *is used by*  
another program. It simply sees those two programs being combined to  
form a single work if they interoperate in certain ways.

As such, if they do not share compatible licenses, they can't be  
distributed together. And if one component is clearly designed to  
work *only in the presence of the other component* it is an implicit  
violation of the GPL. (According to the FSF).

That's their official interpretation.

--Jeff

[Peter Wolanin]

On a practical note, SugarCRM is being released under GPL 3.0:

http://www.sugarforge.org/content/faq/gplv3.php

and

CiviCRM is AGPL (compat with GPL 3.0, but not 2.0):

http://wiki.civicrm.org/confluence/display/CRMDOC/AGPL+vs.+GNU

While these are FOSS licenses, they represent technical violations (I
think) if an integration module is offered on d.o or by that project,
right?

-Peter

On 9/2/07, Jeff Eaton <jeff@...> wrote:

> On Sep 2, 2007, at 9:43 AM, Darren Oh wrote:
>
> > So far this whole discussion seems to be a case of ask the wrong
> > question, get the wrong answer. I have seen no evidence to suggest
> > that one cannot write some code that depends on non-free software,
> > release it under the GPL, and have the GPL apply to that code. What
> > would be against the spirit of the GPL would be to write code that
> > depends on GPL software and to release only a compatibility layer
> > under the GPL, keeping the main functionality non-free. Since 1)
> > the third-party apps that are being integrated do not depend on
> > Drupal and 2) the module authors do not own the rights to the code
> > in the third-party apps, this issue is irrelevant to the situation
> > under discussion.
>
> I used to take this position as well, but it's apparent after quite a
> bit of research that this is based on loose use of the phrase
> "depends on" to define the terms of the discussion. The GPL doesn't
> use those words. It doesn't recognize a difference between a piece of
> software that *uses* a library, and the library that *is used by*
> another program. It simply sees those two programs being combined to
> form a single work if they interoperate in certain ways.
>
> As such, if they do not share compatible licenses, they can't be
> distributed together. And if one component is clearly designed to
> work *only in the presence of the other component* it is an implicit
> violation of the GPL. (According to the FSF).
>
> That's their official interpretation.
>
> --Jeff
>

[ttw+drupal]

On 02.09-15:47, Jeff Eaton wrote:
[ ... ]
> As such, if they do not share compatible licenses, they can't be  
> distributed together. And if one component is clearly designed to  
> work *only in the presence of the other component* it is an implicit  
> violation of the GPL. (According to the FSF).

thank you for finally putting this clearly.  i am not a lawyer but
i concur.

what still confuses me, however, is that i recall a law suit with one
of the larger software companies about 10 years ago where they sued
a smaller company for reverse engineering their code to write compatible
software.  the case was lost (as i recall) on the basis that once you
had purchased something you were entitled to use it to access your
data (which you still had ownership over) in whatever manner you chose
(including reverse engineering and interfacing with those components
to better access your information).  my understanding of the gpl is
that it was created precisely in response to this sort of corporate
behaviour.  thus it appears to me contradictory to suggest that i
cannot interface with free software (which is based upon shared
ownership) unless i also make my software free.  this appears to be
the goal of some GPL proponents.  and i don't believe possible under
law (at least the majority of EU law).  hence my earlier assersion
that using drupal hooks in any software is not illegal or problematic,
nor is distributing that software (unless you also distribute drupal).

i re-iterate that i agree about the distribution of free software and
libraries as a reasonable incentive toward free software and as a
reasonable barrier to wholesale consumption of free software into
commercial products.  i disagree that we can prevent someone from
communicating with free software on the basis of copyright and think
this directly contradictory to the notion of freedom that we wish to
preserve and propogate.

[Darren Oh-2]

Sometimes my first attempt to express my thoughts confuses people.  
For those who are still confused, I hope this is clearer:

The viral nature of the GPL means that an app that uses Drupal is  
automatically licensed under the GPL, whether or not the developer of  
the app says so. That's exactly what we want, and it's the reason  
Drupal is distributed under the GPL. This discussion has established  
the illegality of attempting to circumvent the GPL. It would be  
against the spirit of the GPL for a developer to write an app  
designed to work only in the presence of Drupal, integrate it using a  
module, and claim that the GPL applies only to the module. I see no  
reason why we would want to enable developers to do this.

Based on the evidence presented in this discussion, it would not be  
against either the spirit or the letter of the GPL for a developer to  
distribute a module that integrates an existing third-party app that  
does not use Drupal and to which the developer does not own the  
rights. (Of course, the app can't be distributed with Drupal, but we  
already prohibit third-party apps from being included in Drupal's  
repository.) Therefore, it is incorrect to say that "if  
debug_backtrace() can ever include functions from both Drupal and an  
external program," the external program must be distributed under the  
GPL. That test is applicable only if the developer also owns the  
external program. And remember, if the external program uses Drupal,  
it is already under the GPL.

I repeat, this discussion has been a case of right answer, wrong  
question. Module developers can stop worrying and go back to making  
Drupal better.

On Sep 3, 2007, at 4:47 AM, Jeff Eaton wrote:

> On Sep 2, 2007, at 9:43 AM, Darren Oh wrote:
>
>> So far this whole discussion seems to be a case of ask the wrong  
>> question, get the wrong answer. I have seen no evidence to suggest  
>> that one cannot write some code that depends on non-free software,  
>> release it under the GPL, and have the GPL apply to that code.  
>> What would be against the spirit of the GPL would be to write code  
>> that depends on GPL software and to release only a compatibility  
>> layer under the GPL, keeping the main functionality non-free.  
>> Since 1) the third-party apps that are being integrated do not  
>> depend on Drupal and 2) the module authors do not own the rights  
>> to the code in the third-party apps, this issue is irrelevant to  
>> the situation under discussion.
>
> I used to take this position as well, but it's apparent after quite  
> a bit of research that this is based on loose use of the phrase  
> "depends on" to define the terms of the discussion. The GPL doesn't  
> use those words. It doesn't recognize a difference between a piece  
> of software that *uses* a library, and the library that *is used  
> by* another program. It simply sees those two programs being  
> combined to form a single work if they interoperate in certain ways.
>
> As such, if they do not share compatible licenses, they can't be  
> distributed together. And if one component is clearly designed to  
> work *only in the presence of the other component* it is an  
> implicit violation of the GPL. (According to the FSF).
>
> That's their official interpretation.

[Jeff Eaton]

On Sep 3, 2007, at 10:04 AM, Darren Oh wrote:

> Based on the evidence presented in this discussion, it would not be  
> against either the spirit or the letter of the GPL for a developer  
> to distribute a module that integrates an existing third-party app  
> that does not use Drupal and to which the developer does not own  
> the rights.

This is exactly the opposite of what the FSF said when I asked them  
that question directly.

--Jeff

[Bryan Ruby]

Jeff Eaton wrote:

> On Sep 3, 2007, at 10:04 AM, Darren Oh wrote:
>
>> Based on the evidence presented in this discussion, it would not be
>> against either the spirit or the letter of the GPL for a developer to
>> distribute a module that integrates an existing third-party app that
>> does not use Drupal and to which the developer does not own the rights.
>
> This is exactly the opposite of what the FSF said when I asked them
> that question directly.
>
> --Jeff

Hey folks, I'm not much of a developer but I'm a pretty good observer.  
A few months ago Joomla! when through this very same issue, check out:
http://www.joomla.org/content/view/3510/1/ .  I think a lot of time can
be wasted in a discussion in reinterpreting FSF's own interpretation of
what the GPL license says and doesn't say.  I think for the sake of
discussion, it's best to assume Jeff's original post (
http://lists.drupal.org/pipermail/development/2007-August/026130.html )
is correct, because I think most GPL projects are starting to
acknowledge they have a problem with bridges that connect GPL and
non-GPL work.

Joomla's response was to provide no exceptions or compromise to their
extensions (equivalent to Drupal's contributed modules).  However, is
there not room for compromise with a combination of Jeff's first two
potential solutions?

    1) Add a notice to Drupal's license that clarifies that writing such  
    modules IS explicitly allowed. This is problematic, however, because  
    that would make Drupal non-GPL'd itself, a GPL variant, and we would  
    require explicit relicensing permission by the authors of any GPL  
    code we wish to include.

    2) Remove modules that integrate with third-party non-GPL code from  
    the CVS repository, even if they do not *include* the aforementioned  
    non-GPL code.
     

Could we not provide a notice to Drupal's license (yes a variant of the
GPL) that does allow an exception for contributed modules that bridge
GPL with non-GPL software?  At the same time require modules included in
the Drupal core and supported at Drupal.org to remain fully GPL
compliant?  Of course those contributed modules that are not complaint
to the GPL would need to be and could be hosted off-site elsewhere.

In some way it's sad that a strict GPL license that helps us keep "free
code" free prevents us from freely sharing the code we use to connect
with non-GPL software. The reality is such a variant in the GPL license
would reflect the "real world" realities that Laura Scott discussed in
an earlier post (
http://lists.drupal.org/pipermail/development/2007-August/026167.html )
and really how Drupal's own open source culture has evolved.

I of course only presented a suggestion, as in the past months I have
yet to come up with real answers on my own (
http://cmsreport.com/node/1091 ).

Bryan Ruby

[David Timothy Strauss]

Why don't we just allow contributed projects to check a box that adds an
EXCEPTION.txt to their packaged modules/themes that allows "linking" to
non-GPL code?

We can even make the exception as narrow as possible:

(x) My module does not require any non-GPL libraries.
( ) My module requires a non-GPL but FLOSS library.
( ) My module requires a proprietary library named [             ].

[FGM]

One thing you need to keep in mind is the explicit allowance of reverse
engineering by law within the EU member states, transposing an EU directive,
which AFAIK does not an equivalent in the USA, where reverse engineering can
land you in deep trouble.

The case you mention could fall under this legal situation.

----- Original Message -----
From: <ttw+drupal@...>
To: <development@...>
Sent: Monday, September 03, 2007 1:05 PM
Subject: Re: [development] Modules that integrate non-GPL PHP apps
violatethe GPL.

> On 02.09-15:47, Jeff Eaton wrote:
> [ ... ]
> what still confuses me, however, is that i recall a law suit with one
> of the larger software companies about 10 years ago where they sued
> a smaller company for reverse engineering their code to write compatible
> software.  the case was lost (as i recall) on the basis that once you
> had purchased something you were entitled to use it to access your
> data (which you still had ownership over) in whatever manner you chose
> (including reverse engineering and interfacing with those components
> to better access your information).  [...]

[Hunter C]

US copyright law does not ignore the need for reverse engineering in these circumstances (i.e., for compatibility purposes)...

 

Title 17, Section 1201 of the US code says, in part ..

(f) Reverse Engineering.  ... a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title.

...
 

Heavy on legalese, but you get the idea.

 

On 9/3/07, FGM <fgm@...> wrote:

One thing you need to keep in mind is the explicit allowance of reverse
engineering by law within the EU member states, transposing an EU directive,
which AFAIK does not an equivalent in the USA, where reverse engineering can
land you in deep trouble.

The case you mention could fall under this legal situation.

----- Original Message -----
From: < ttw+drupal@...>
To: <development@...>
Sent: Monday, September 03, 2007 1:05 PM
Subject: Re: [development] Modules that integrate non-GPL PHP apps
violatethe GPL.

> On 02.09-15:47, Jeff Eaton wrote:
> [ ... ]
> what still confuses me, however, is that i recall a law suit with one
> of the larger software companies about 10 years ago where they sued
> a smaller company for reverse engineering their code to write compatible
> software.  the case was lost (as i recall) on the basis that once you
> had purchased something you were entitled to use it to access your
> data (which you still had ownership over) in whatever manner you chose
> (including reverse engineering and interfacing with those components
> to better access your information).  [...]

[ttw+drupal]

On 03.09-18:53, FGM wrote:

> > [ ... ]
> > what still confuses me, however, is that i recall a law suit with one
> > of the larger software companies about 10 years ago where they sued
> > a smaller company for reverse engineering their code to write compatible
> > software.  the case was lost (as i recall) on the basis that once you
> > had purchased something you were entitled to use it to access your
> > data (which you still had ownership over) in whatever manner you chose
> > (including reverse engineering and interfacing with those components
> > to better access your information).  [...]
>
> One thing you need to keep in mind is the explicit allowance of reverse
> engineering by law within the EU member states, transposing an EU directive,
> which AFAIK does not an equivalent in the USA, where reverse engineering can
> land you in deep trouble.
>
> The case you mention could fall under this legal situation.

i believe you are correct here but the bigger question is what is
right and what is wrong.  i believe that trying to use copyright to
prevent someone doing anything except copying your code is not only
legally untenable (at least within the EU) but wrong.  using the notion
of freedom to impose freedom may be an appealing notion but what is
the value of imposed freedom?  rings of certain, current, foreign
policies.

[ttw+drupal]

On 03.09-23:04, Darren Oh wrote:
[ ... ]
> The viral nature of the GPL means that an app that uses Drupal is  
> automatically licensed under the GPL, whether or not the developer of  
> the app says so. That's exactly what we want, and it's the reason  
> Drupal is distributed under the GPL. [ ... ]

i am unsure who you define as "we" but if it's the reason that Drupal
is distributed under the GPL then i would be severly disappointed.
personally, i understand the purpose of the GPL (as opposed something
like the BSD license) is to ensure that developments are returned to
the community and that the code remains free.

the "spirit" of the GPL can only be captured by capturing the spirit
of freedom.  this means accepting that people may use certain aspects
of that freedom in a manner contrary to you expectation or wishes.

[FGM]

That's a nice improvement over the previous situation, then. I'd read it was
under discussion years ago, but didn't think it would make it. Looks like it
did :-)

----- Original Message -----
From: "Hunter C" <hunterc@...>
To: <development@...>
Sent: Monday, September 03, 2007 8:33 PM
Subject: Re: [development] Modules that integrate non-GPL PHP appsviolatethe
GPL.


> US copyright law does not ignore the need for reverse engineering in these
> circumstances (i.e., for compatibility purposes)...
>
> Title 17, Section 1201 of the US code says, in part ..
>
> *(f) Reverse Engineering.  ... a person who has lawfully obtained the
right
> to use a copy of a computer program may circumvent a technological measure
> that effectively controls access to a particular portion of that program
for
> the sole purpose of identifying and analyzing those elements of the
program
> that are necessary to achieve interoperability of an independently created
> computer program with other programs, and that have not previously been
> readily available to the person engaging in the circumvention, to the
extent
> any such acts of identification and analysis do not constitute
infringement
> under this title. *
> ...
>
> Heavy on legalese, but you get the idea.
[...]

[Darren Oh-2]

Since the FSF does not hold the copyright for Drupal, all that  
matters is what the GPL actually says. To quote, "The FSF folks, when  
I asked about this, basically said that it was probably violating the  
spirit of the GPL but not the letter."

I still think the wrong question was answered. The GPL is a one-way  
infection: non-free software cannot GPL components, but GPL code can  
use non-free components. To quote again: "While the GPL only covers  
distribution, they consider it a GPL violation to *distribute  
software that is intended to be used in violation of the GPL*. In  
other words, distributing a proprietary commercial piece of software  
that relies on GPL libraries, and telling people, 'We can't put X  
into our program, but you can to make it work...' is creating a GPL-
derived program just as much as rolling the GPL'd libraries in and  
then distributing."

There is a possibility that a third-party app may have a similarly  
viral license that is incompatible with the GPL. In that case, it  
would not be legal to distribute a module that makes use of the app.

On Sep 3, 2007, at 11:32 PM, Jeff Eaton wrote:

> On Sep 3, 2007, at 10:04 AM, Darren Oh wrote:
>
>> Based on the evidence presented in this discussion, it would not  
>> be against either the spirit or the letter of the GPL for a  
>> developer to distribute a module that integrates an existing third-
>> party app that does not use Drupal and to which the developer does  
>> not own the rights.
>
> This is exactly the opposite of what the FSF said when I asked them  
> that question directly.
>
> --Jeff

[Jeff Eaton]

On Sep 3, 2007, at 6:43 PM, Darren Oh wrote:

> I still think the wrong question was answered. The GPL is a one-way  
> infection: non-free software cannot GPL components, but GPL code  
> can use non-free components.

Your position is one interpretation of the GPL. It is contradicted by  
the GPL FAQ, and what the original authors of the GPL said when  
specifically asked. I can't really say anything more, I'm just  
relaying what I have been told.

--Jeff

[David Timothy Strauss]

Darren Oh wrote:
> I still think the wrong question was answered. The GPL is a one-way
> infection: non-free software cannot GPL components, but GPL code can use
> non-free components.

I'm not a lawyer, but I think that's impossible. The GPL cannot tell me
what I can and cannot do with my own, proprietary code, even if I
provide instructions to end users telling them to compile my code with a
GPLed library.

And unless calling a library's functions constitutes a derivative work
(which it doesn't seem to, see <http://www.rosenlaw.com/lj19.htm>), the
GPL cannot prevent me from downloading a GPL library and working on my
own proprietary code that compiles against the library. I can then
distribute that proprietary code with the aforementioned instructions
(though not the library itself).

I know this isn't how most people interpret the viral nature of the GPL,
but I simply don't see the mechanism that the GPL would use to prevent
proprietary software developers from compiling their code against GPLed
libraries in development and distributing the proprietary source code in
a non-GPL form to be compiled with GPL code by end users. At what point
would the developers be forced to accept the GPL's terms?

You have to agree to the GPL if you (re)distribute GPLed works -- but
not if you only download them, use them, or install them. If you
download a GPL library and develop proprietary code that uses the
library, you have not been forced to accept the GPL. For this reason, I
think it's ridiculous when GPLed programs ask me to "accept" the GPL on
installation.

The GPL is quite clear about this:
> Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.

Moreover:
> You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.

Now, if the GPL required that you accept it to *use* code, it might be a
different matter because you would be agreeing to the infection clause
in the library's license. But this infection clause seems to go well
beyond what normal copyright would consider a derivative work.

I would love to have someone clear up any errors in my interpretation.
While I love the FSF, they have a vested interest in presenting the GPL
as viral as possible. So, I don't consider their FAQ to be a reliable,
unbiased source.

On Tuesday 04 September 2007, David Strauss wrote:

> I would love to have someone clear up any errors in my interpretation.
> While I love the FSF, they have a vested interest in presenting the GPL
> as viral as possible. So, I don't consider their FAQ to be a reliable,
> unbiased source.

I think we're at the point where we all need to wait while someone finds a
real lawyer to ask, since we're just going around in circles and even
admitting it. :-)

So, what pertinent questions should be asked of an actual lawyer, not employed
by FSF, by whoever it is that is doing so (Drupal Association, a consulting
firm, whoever)?  I would start with:

Scenario: There exists non-GPL system.  A Drupal module is written that allows
Drupal to access that system via its APIs within a PHP process.  That module
is committed to Drupal CVS, and therefore distributed under the GPL.  Legal
or illegal?

Scenario: There exists non-GPL system.  A Drupal module is written that allows
Drupal to access that system via some external API (XML-RPC, SOAP, REST,
HTTP, or some other non-shared-memory-space system).  That module is
committed to Drupal CVS, and therefore distributed under the GPL.  Legal or
illegal?

Scenario: There exists a non-GPL system.  A Drupal module is written that
allows Drupal to access that system via either of the methods listed above
(in-process or out-of-process).  That module is provided by its author to a
client/customer for use with their non-GPL system, without going through
Drupal CVS.  Under what licenses (GPL, non-GPL, or ownership transfer with
reverse license) could that module be legally provided to said client?  

(Scenario 3 is actually a couple of scenarios rolled into one, but it's easier
than restating every possible combination.)

We're not lawyers.  Let's find one so we can put this issue to rest and get
back to writing GPLed code in the first place. :-)

--
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

On Monday, 3. September 2007, Bryan Ruby wrote:
> In some way it's sad that a strict GPL license that helps us keep "free
> code" free prevents us from freely sharing the code we use to connect
> with non-GPL software. The reality is such a variant in the GPL license
> would reflect the "real world" realities that Laura Scott discussed in
> an earlier post (
> http://lists.drupal.org/pipermail/development/2007-August/026167.html )
> and really how Drupal's own open source culture has evolved.

That may be true, but if that is the case then the GPL is simply the wrong
license for Drupal. My impression is that all the people requesting
"more freedom" (which is a wrong statement in itself because there's obviously
various opinions on "what software freedom actually is") would rather have an
LGPL Drupal than a GPL one.

Also (I believe this has been mentioned before), you can't add such a license
exception without tracking down *all* the copyright holders of Drupal code
and getting their approval for this license change. (It's really a change,
yes.)

I find it tiresome to read about license amendments when we haven't even got a
list of copyright holders. Could we please defer the "license exception"
discussion until there's proper copyright headers in the source files?
It's impossible to change the license until we've got those.

Thanks,
  Jakob

[Darren Oh-2]

On Sep 4, 2007, at 1:26 PM, David Strauss wrote:

> You have to agree to the GPL if you (re)distribute GPLed works -- but
> not if you only download them, use them, or install them. If you
> download a GPL library and develop proprietary code that uses the
> library, you have not been forced to accept the GPL. For this  
> reason, I
> think it's ridiculous when GPLed programs ask me to "accept" the  
> GPL on
> installation.
>
> The GPL is quite clear about this:
>> Activities other than copying, distribution and modification are  
>> not covered by this License; they are outside its scope.
>
> Moreover:
>> You are not required to accept this License, since you have not  
>> signed it. However, nothing else grants you permission to modify  
>> or distribute the Program or its derivative works.
>
> Now, if the GPL required that you accept it to *use* code, it might  
> be a
> different matter because you would be agreeing to the infection clause
> in the library's license. But this infection clause seems to go well
> beyond what normal copyright would consider a derivative work.
>
> I would love to have someone clear up any errors in my interpretation.
> While I love the FSF, they have a vested interest in presenting the  
> GPL
> as viral as possible. So, I don't consider their FAQ to be a reliable,
> unbiased source.

The argument being made is that distributing a module that allows  
Drupal to use separately distributed third-party code would make the  
third-party code a modification of Drupal (and therefore illegal if  
the module author cannot also release the third-party code under the  
GPL). If that is really what the FSF is claiming, I too would  
question the reliability of their interpretation.

[ttw+drupal]

On 04.09-14:05, Jakob Petsovits wrote:
[ ... ]
> I find it tiresome to read about license amendments when we haven't
> even got a list of copyright holders. Could we please defer the "license
> exception" discussion until there's proper copyright headers in the
> source files? It's impossible to change the license until we've got
> those.

this seems like a very sensible note on which to terminate this
discussion.