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

[Jeff Eaton]

The FSF folks, when I asked about this, basically said that it was  
probably violating the spirit of the GPL but not the letter. The  
number of permutations involved is why it's best to ask them -- or a  
lawyer. ;)

--Jeff

On Aug 31, 2007, at 7:31 PM, Larry Garfield wrote:

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

[David Metzler]

This seems like pretty safe ground to me.  Of course what constitutes  
a "derived work" is and will always be subject to legal  
interpretation, And I do think what you "distribute" and how you  
distribute it will make a big difference.  But something that  
communicates over an internet protocol with another service, can  
hardly be considered part of the product you've distributed.  
Particularly if the spec  for the web service is not proprietary. The  
service your consuming hasn't necessarily been distributed (and often  
isn't). This is probably the crux of the static vs, .dll difference  
in some peoples (lawyers or not) interpretation.  Just how stand-
alone does a library need to be in order to be considered an  
independent work vs. a derived work? Would a reasonable person  
believe that some other individual could write a replacement  
"library"?  Would they be able to distribute it as a standalone product?

I'd be interested to see how an interpretive api that was written so  
that anyone can register a callback and therefor inerface with the  
module would measure up in this interpretation, but as Larry hints  
at... that's probably best left to a real lawyer.

I once attended a talk by a copyright lawyer on the subject, and in  
the states at least, most software licensing is considered contract  
law, and not copyright law, so the interface gets muddy in a hurry,  
particularly around commercial software.  From a legal perspective  
you don't own your copy of MS word in the states.  You've just  
purchased (read rented) the rights to use it.

The real question in all this isn't which interpretation is right or  
wrong, but rather what level of risk is drupal.org willing to  
accept.   That interpretation ought to be somewhat conservative  
IMHO.  But I think web services are safe, if the spec is open.

Enough of this, I'm going to write some more code :)

Dave

On Aug 31, 2007, at 5:31 PM, Larry Garfield wrote:

> On Friday 31 August 2007, Thomas Barregren wrote:
>
>> 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

[Ken Rickard]

Jeff-

Two questions, mercifully brief, for all:

1) Should we escalate this to the Drupal Association to pull in some lawyerly resources? 

I presume the answer is "no" here, as I hear killes in my head saying "Drupal follows GPL; end of discussion."

2)  How does this affect Edison Wong's (and many others') work on Oracle / DB2 integration for Drupal core?  Can GPL software invoke data directly from a non-GPL storage system?

- Ken

On Friday 31 August 2007, Ken Rickard wrote:
> Jeff-
>
> Two questions, mercifully brief, for all:
>
> 1) Should we escalate this to the Drupal Association to pull in some
> lawyerly resources?
>
> I presume the answer is "no" here, as I hear killes in my head saying
> "Drupal follows GPL; end of discussion."

That depends what is being asked of the lawyers.  "How can we tweak our
licensing policy" is probably not going to get very far at all, lawyers or
not.  "Would we be breaking the law to host in CVS a module that does X"
would be a question best asked of a lawyer, and I agree that the DA would
probably be the correct party to ask.  (FSF has lawyers who will give us
answers, as Jeff has found, but they are not exactly an unbiased source.  And
I say that as a card-carrying FSF Associate Member.)

> 2)  How does this affect Edison Wong's (and many others') work on Oracle /
> DB2 integration for Drupal core?  Can GPL software invoke data directly
> from a non-GPL storage system?
>
> - Ken

IANAL etc., but since the communication with the server is all via SQL, which
is a (nominal) standard, I'd think it would be no more problematic than
Aggregator, which pulls RSS feeds from both GPLed blogs and proprietary
newspaper sites.  


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

[Walt Daniels]

I have always found that when dealing with lawyers the best approach is to
tell them what you are going to do and ask for possible changes that will
get you into the least trouble. Without that approach the answer is always
NO.

-----Original Message-----
From: development-bounces@... [mailto:development-bounces@...]
On Behalf Of Larry Garfield
Sent: Saturday, September 01, 2007 2:54 AM
To: development@...
Subject: Re: [development] Modules that integrate non-GPL PHP apps violate
the GPL.

On Friday 31 August 2007, Ken Rickard wrote:
> Jeff-
>
> Two questions, mercifully brief, for all:
>
> 1) Should we escalate this to the Drupal Association to pull in some
> lawyerly resources?
>
> I presume the answer is "no" here, as I hear killes in my head saying
> "Drupal follows GPL; end of discussion."

That depends what is being asked of the lawyers.  "How can we tweak our
licensing policy" is probably not going to get very far at all, lawyers or
not.  "Would we be breaking the law to host in CVS a module that does X"
would be a question best asked of a lawyer, and I agree that the DA would
probably be the correct party to ask.  (FSF has lawyers who will give us
answers, as Jeff has found, but they are not exactly an unbiased source.
And I say that as a card-carrying FSF Associate Member.)

> 2)  How does this affect Edison Wong's (and many others') work on
> Oracle /
> DB2 integration for Drupal core?  Can GPL software invoke data
> directly from a non-GPL storage system?
>
> - Ken

IANAL etc., but since the communication with the server is all via SQL,
which is a (nominal) standard, I'd think it would be no more problematic
than Aggregator, which pulls RSS feeds from both GPLed blogs and proprietary
newspaper sites.  


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


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.484 / Virus Database: 269.13.1/981 - Release Date: 8/31/2007
6:13 AM

[David Timothy Strauss]

Ken Rickard wrote:
> 1) Should we escalate this to the Drupal Association to pull in some
> lawyerly resources?

I will see if my company can devote some of its legal resources to
answering this question.

[Thomas Barregren]

Larry Garfield skrev:

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

Yes, I think so.

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

Probably none. I am for sure not a lawyer.

But for what it is worth, I have more than ten years of professional
experience of reading and writing contracts and licenses. I am not an
expert. But I have learned a lot, and think of myself as quite well
versed in these issues. Especially when it comes to Free and Open Source
Software (FOSS) licensing, which I have taken a great interest in for
several years.

For those who are interesting to learn more in this interesting field, I
can recommend following books (available free on-line):

  * http://www.rosenlaw.com/oslbook.htm
  * http://www.oreilly.com/catalog/osfreesoft/book/

Best regards,
Thomas

[Thomas Barregren]

Ken Rickard skrev:
> Jeff-
>
> Two questions, mercifully brief, for all:
>
> 1) Should we escalate this to the Drupal Association to pull in some
> lawyerly resources?
>
> I presume the answer is "no" here, as I hear killes in my head saying
> "Drupal follows GPL; end of discussion."

Since Drupal.org distributes the possible offending modules, it is not
enough to just say that "Drupal follows GPL; end of discussion."

I think there is three issues worth further consideration:

   1. Would Drupal benefit from having some sort of FOSS License
      Exception? Especially considering the problem with libraries under
      the PHP license.
   2. Is it advisable for Drupal.org to distribute modules that depends
      on software under a GPL-incompatible license?
   3. Could a Linking Over Controlled Interface Exception, for hooks and
      some other unctions (e.g. t() and l()), be a a feasible solution
      to allow distribution of modules that depends on software under a
      GPL-incompatible license?


> 2)  How does this affect Edison Wong's (and many others') work on
> Oracle / DB2 integration for Drupal core?  Can GPL software invoke
> data directly from a non-GPL storage system?

It depends. If the access can be done without knowing the internals of
the non-GPLed storage system, for example through SQL, it is not a
problem. But if the access requires a non-GPLed driver, then we have a
problem. I haven't followed the work by Wong et al so I can't speak for
that particular case.

Best regards,
Thomas

[Ken Rickard]

I'm not a lawyer, either.  But in my day job, I'm the last guy who reviews things before calling one.

:-)

- Ken

On 9/1/07, Thomas Barregren <thomas@...> wrote:

Ken Rickard skrev:
> Jeff-
>
> Two questions, mercifully brief, for all:
>
> 1) Should we escalate this to the Drupal Association to pull in some
> lawyerly resources?
>
> I presume the answer is "no" here, as I hear killes in my head saying
> "Drupal follows GPL; end of discussion."

Since Drupal.org distributes the possible offending modules, it is not
enough to just say that "Drupal follows GPL; end of discussion."

I think there is three issues worth further consideration:

   1. Would Drupal benefit from having some sort of FOSS License
      Exception? Especially considering the problem with libraries under
      the PHP license.
   2. Is it advisable for Drupal.org to distribute modules that depends
      on software under a GPL-incompatible license?
   3. Could a Linking Over Controlled Interface Exception, for hooks and
      some other unctions (e.g. t() and l()), be a a feasible solution
      to allow distribution of modules that depends on software under a
      GPL-incompatible license?


> 2)  How does this affect Edison Wong's (and many others') work on
> Oracle / DB2 integration for Drupal core?  Can GPL software invoke
> data directly from a non-GPL storage system?

It depends. If the access can be done without knowing the internals of
the non-GPLed storage system, for example through SQL, it is not a
problem. But if the access requires a non-GPLed driver, then we have a
problem. I haven't followed the work by Wong et al so I can't speak for
that particular case.

Best regards,
Thomas

[David Timothy Strauss]

Thomas Barregren wrote:
> For those who are interesting to learn more in this interesting field, I
> can recommend following books (available free on-line):
>
>  * http://www.rosenlaw.com/oslbook.htm
>  * http://www.oreilly.com/catalog/osfreesoft/book/

Larry Rosen, the author of the book in the first link, is one of the
lawyers my company consults with.

[Karoly Negyesi]

> Larry Rosen, the author of the book in the first link, is one of the
> lawyers my company consults with.

So the question that the list should debate: what are the questions that a lawyer should answer for us? Larry Rosen looks like a good candidate. (Or maybe two lawyers? One in the EU, one in the USA)

On Friday, 31. August 2007, Laura Scott wrote:
> On Aug 31, 2007, at 6:05 AM, Thomas Barregren wrote:
> > 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.
>
> All we need to do is track down everyone who has contributed code to
> the Drupal project and get their okay, right?

These, by the way, are exactly that kind of case where a proper copyright
header would help enormously. You know, the kind of copyright header that is
not used at all in standard Drupal code. Like proposed in the GPL's appendix,
link: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#SEC4

Can we please start adding such copyright headers *now*?
The later those are added, the more inaccurate they will be.
Please.

Thanks,
  Jakob

[Thomas Barregren]

Earnie Boyd skrev:

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

True. But there is no need to make a distinction between static and
dynamic linked libraries.

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

No, you are free to *use* the Drupal API without your source being
GPLed. But you are not allowed to *distribute* your source under another
license than GPL if it make use of the Drupal API.

It is important to keep this distinction clear, since much of the
confusion in this thread comes from people erroneous believing that they
cannot use Drupal with non-GPLed program, or help other (e.g. on
consultant basis) to do that, when GPL in fact gives this right.

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

True, *if* your code make no use whatsoever of Drupal or another GPLed
software.

But, if your code make reference to objects, functions, arrays or other
internals of the Drupal API (or another GPLed software), then it must be
distributed under GPL even if it works without Drupal present.

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

True *if* your code make reference to objects, functions, arrays or
other internals of the Drupal API.

But, if your code don't make use of objects, functions, arrays or other
internals of the Drupal API, but just requires Drupal to provide HTML or
XML or JSON or similar over HTTP, your code can legally be distributed
under another license other than GPL. (Although it might be against the
spirit of GPL.)


> My use of the non-GPL licensed library does not force Drupal to the
> license of the other library.

Of course not, since nobody than the collective owners of Drupal's
Intellectual Property Rights can distribute Drupal under another license
than GPL.

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

You are only "screwed" if you want to distribute a work derived from a
GPLed software and another software which is under a license not
compatible with GPL.

> All-in-all, I can use Drupal along with all of the other programs I use.

True.

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

Completely wrong!

For a a contributed module to be meaningful, it must implement at least
one hook, and probably also call some function or use some
data-structure provided by Drupal. Thus, the module is a derived work of
Drupal. Since Drupal is provided under GPL, it follows that the module
cannot be distributed under any other license than GPL.

Now, if the module is stored in Drupal's CVS, anyone can check it out,
and thereby making Drupal.org a distributor of the module. Consequently,
the Drupal CVS should not store contributed modules which can't be
distributed under GPL.

Please, notice the wording in the last sentence. If an identifiable
section of the module is not derived from Drupal (or another GPLed
software), and obviously is a separate work, e.g. a library, then that
part doesn't need to be under GPL to begin with. But, when that section
is distributed as part of a module, GPL applies to it as well. That is
the reason why third-party libraries and similar must be under a license
compatible with GPL.

Thus, from a legal perspective, it is okay for a module to contain
non-GPLed parts, e.g. libraries, as long as (i) they have nothing to do
with Drupal (or another GPLed software) and (ii) they are under a GPL
compatible license, e.g. BSD, MIT or LGPL. However, Drupal.org doesn't
allow this.

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

No one can force you to use GPL, but...

    "However, nothing else grants you permission to modify or
    distribute the Program or its derivative works.  These actions are
    prohibited by law if you do not accept this License.  Therefore, by
    modifying or distributing the Program (or any work based on the
    Program), you indicate your acceptance of this License to do so, and
    all its terms and conditions for copying, distributing or modifying
    the Program or works based on it."

    See § 5 of GPL v2


Regards,
Thomas

[Ken Rickard]

I think this discussion should happen on a new thread.

- Ken

On 9/2/07, Karoly Negyesi <karoly@...> wrote:

> Larry Rosen, the author of the book in the first link, is one of the
> lawyers my company consults with.

So the question that the list should debate: what are the questions that a lawyer should answer for us? Larry Rosen looks like a good candidate. (Or maybe two lawyers? One in the EU, one in the USA)

[Thomas Barregren]

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

Since I am not aware of a *legal difference* I wondered if I might have
missed some subtlety. After all, I am not a lawyer. So that is why I
asked you to "explain this 'legal difference'." Unfortunately, I didn't
find the answer in your otherwise very interesting, but partly wrong, reply.

I claim that there is no legal difference between statically and
dynamically linked code. Let us assume you have developed a program P
which depends on objects or functions in a library L. Also assume that
you have obtained L under GPL. Now, it doesn't matter whether P links to
L at compile time (static linking) or at runtime (dynamic linking). You
are in both cases obliged to use GPL when distributing P.

In fact, the preamble of LGPL v2 explicit states that there is no
difference between statically linked and dynamically linked (a.k.a.
shared) libraries:

    "When a program is linked with a library, whether statically or
    using a shared library, the combination of the two is legally
    speaking a combined work, a derivative of the original library."


As a corollary, I claim there is another motivation of LGPL. Quoting
LGPL v2 again:

    For example, on rare occasions, there may be a special need to
    encourage the widest possible use of a certain library, so that it
    becomes a de-facto standard. To achieve this, non-free programs must
    be allowed to use the library. A more frequent case is that a free
    library does the same job as widely used non-free libraries. In this
    case, there is little to gain by limiting the free library to free
    software only, so we use the Lesser General Public License.

    In other cases, permission to use a particular library in non-free
    programs enables a greater number of people to use a large body of
    free software. For example, permission to use the GNU C Library in
    non-free programs enables many more people to use the whole GNU
    operating system, as well as its variant, the GNU/Linux operating
    system.



Regards,
Thomas

[Darren Oh-2]

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.

[David Timothy Strauss]

Karoly Negyesi wrote:
> So the question that the list should debate: what are the questions that a lawyer should answer for us? Larry Rosen looks like a good candidate. (Or maybe two lawyers? One in the EU, one in the USA)

One good copyright lawyer in the EU is Jean Baptiste Soufron. He is
affiliated with the EFF and is an expert on international copyright law.
He regularly provides the Wikimedia Foundation with legal advice.

[Earnie]

Quoting Darren Oh <darrenoh@...>:

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

That is how I see the issue.  I have two different components one GPL
licensed one some other license.  I need to write software to
communicate between the two.  I have the right to license it as I see
fit.  Since I wish to use the Drupal methods of distribution I need to
use GPL.  I also have the right as the copyright owner to license this
new work under some other license.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/

[Earnie]

Quoting Earnie Boyd <earnie@...>:

>
> That is how I see the issue.  I have two different components one GPL
> licensed one some other license.  I need to write software to
> communicate between the two.  I have the right to license it as I see
> fit.  Since I wish to use the Drupal methods of distribution I need
> to use GPL.  I also have the right as the copyright owner to license
> this new work under some other license.
>

Correction.  If I use a library API that is GPL licensed I must license
as GPL.

Earnie
-- http://for-my-kids.com/
-- http://give-me-an-offer.com/

[Earnie]

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.

> Since I am not aware of a *legal difference* I wondered if I might
> have missed some subtlety. After all, I am not a lawyer. So that is
> why I asked you to "explain this 'legal difference'." Unfortunately,
> I didn't find the answer in your otherwise very interesting, but
> partly wrong, reply.
>

LGPL provides an exception to the use of the library API.

> I claim that there is no legal difference between statically and
> dynamically linked code. Let us assume you have developed a program P
> which depends on objects or functions in a library L. Also assume
> that you have obtained L under GPL. Now, it doesn't matter whether P
> links to L at compile time (static linking) or at runtime (dynamic
> linking). You are in both cases obliged to use GPL when distributing
> P.
>
> In fact, the preamble of LGPL v2 explicit states that there is no
> difference between statically linked and dynamically linked (a.k.a.
> shared) libraries:
>
>    "When a program is linked with a library, whether statically or
>    using a shared library, the combination of the two is legally
>    speaking a combined work, a derivative of the original library."
>
>
> As a corollary, I claim there is another motivation of LGPL. Quoting
> LGPL v2 again:
>
>    For example, on rare occasions, there may be a special need to
>    encourage the widest possible use of a certain library, so that it
>    becomes a de-facto standard. To achieve this, non-free programs must
>    be allowed to use the library. A more frequent case is that a free
>    library does the same job as widely used non-free libraries. In this
>    case, there is little to gain by limiting the free library to free
>    software only, so we use the Lesser General Public License.
>
>    In other cases, permission to use a particular library in non-free
>    programs enables a greater number of people to use a large body of
>    free software. For example, permission to use the GNU C Library in
>    non-free programs enables many more people to use the whole GNU
>    operating system, as well as its variant, the GNU/Linux operating
>    system.
>

All I can say is that I agree.

Earnie
-- http://for-my-kids.com/
-- http://give-me-an-offer.com/