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

[Jeff Eaton]

For quite some time, it has been commonly understood in the Drupal  
community that non-GPL software (like a third-party PHP message board  
system) can be integrated into Drupal legally by using an  
intermediary 'bridge' module. After some in-depth emails with the  
Free Software foundation's license gurus, it's become clear that this  
is NOT the case.

Before going any further, I want to make clear that I'm not  
expressing approval or disapproval of this: I'm just relaying the  
conclusions that were reached after several days of discussion and  
questioning with the FSF.

Why do these modules violate the GPL?

1) Under the FSF's accepted interpretation of the GPL, if a module is  
integrating Drupal and another PHP script, by calling one's APIs when  
triggered by the other for example, its purpose is to make a single  
unit of software out of those parts.

2) If multiple programs are operating together and functioning as one  
unit, all the pieces must be GPL'd.

There are a lot of angles to approach the question from, but that's  
what it boils down to. From a developer's perspective, if  
debug_backtrace() can ever include functions from both Drupal and an  
external program, you've turned them into a single program.

There are some potential solutions, though none of them are ideal.

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.

3) Continue on as we are, and don't try to police these issues as  
there are NOT likely to be any real complaints. (No one that I know  
of is trying to SELL modules that integrate with non-GPL resources,  
for example.)

This is an important question for us, and other GPL'd projects, to  
work through. Many GPL CMS's rely on integration components for  
critical functionality (message boards and mass mailing are two  
common examples). I can provide some detailed snippets from the  
correspondence to those who want them, but I'm not sure it would be  
useful for me to spend any more time corresponding. I exhausted my  
list of questions, and I'm just summarizing what I found out.

--Jeff

[Karoly Negyesi]

> For quite some time, it has been commonly understood in the Drupal  
> community that non-GPL software (like a third-party PHP message board  
> system)

If a license is GPL-Compatible http://www.gnu.org/philosophy/license-list.html is that enough? Or we need genuine GPL?

[David Timothy Strauss]

Jeff Eaton wrote:
> 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.

Direct GPL variants are only allowed with approval of the FSF.

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

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

> 3) Continue on as we are, and don't try to police these issues as there
> are NOT likely to be any real complaints. (No one that I know of is
> trying to SELL modules that integrate with non-GPL resources, for example.)

As long as Drupal core is GPL-clean, I think this is acceptable. I don't
think anyone but a lawyer would be qualified to do the policing, anyway.

[David Timothy Strauss]

David Strauss wrote:
> 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.)

The reason I think this is the case is because the GPL code is not
distributed with the non-GPL code.

It's OK to distribute a C++ program that uses STL, even though there are
proprietary STL implementations. It's also OK for me to compile GPL code
against a proprietary STL implementation, as long as I don't
redistribute the binary.

The only distinction left is that some Drupal modules can *only* link to
non-GPL code, but that seems to be a dubious place to draw the line. If
we draw the line there, applications using Cocoa break the GPL.
Applications using parts of the Windows API absent from Wine break the GPL.

[Jakob Petsovits]

On Thursday, 30. August 2007, Jeff Eaton wrote:

> For quite some time, it has been commonly understood in the Drupal
> community that non-GPL software (like a third-party PHP message board
> system) can be integrated into Drupal legally by using an
> intermediary 'bridge' module. After some in-depth emails with the
> Free Software foundation's license gurus, it's become clear that this
> is NOT the case.
>
> Before going any further, I want to make clear that I'm not
> expressing approval or disapproval of this: I'm just relaying the
> conclusions that were reached after several days of discussion and
> questioning with the FSF.
>
> Why do these modules violate the GPL?
>
> 1) Under the FSF's accepted interpretation of the GPL, if a module is
> integrating Drupal and another PHP script, by calling one's APIs when
> triggered by the other for example, its purpose is to make a single
> unit of software out of those parts.

My understanding was that non-GPL software may not be a derivative work of
GPL code, but that it can go the other way round. As David Strauss mentioned,
it is indeed possible to write GPL software by using the Win32 or Cocoa API.

Following this reasoning, it would mean the following for Drupal modules:
- Drupal modules are based on Drupal, so they are GPL in any case.
- Thus, modules may not incorporate code that make the integrated software
  derive (call functions) from Drupal or the module itself.
- Whereas it should be possible to call functions from the integrated software
  from the module.

For example, that would mean no authentication in the integrated software that
is based on Drupal users and passwords. Or displaying any information that
comes from Drupal.
But it should be possible to manage and display stuff from the integrated
software from Drupal. Like is done with Apache, for example (which uses the
GPLv2 incompatible Apache license). I'm sure there are lots of other good
examples.

Would this make sense?

> 2) If multiple programs are operating together and functioning as one
> unit, all the pieces must be GPL'd.
>
> There are a lot of angles to approach the question from, but that's
> what it boils down to. From a developer's perspective, if
> debug_backtrace() can ever include functions from both Drupal and an
> external program, you've turned them into a single program.

David's argument that the GPL only covers distribution, not usage, is a good
counter argument to this point of view. Of course, this is somewhat of a
difficult issue, quite comparable to the kernel module blobs for the ATI and
nVidia graphics card drivers which are widely considered a legal gray area.

Also, you could extend the issue not only to PHP code but also to XML-RPC
calls, where you do not even know if the software that you communicate with
is GPL or not.

That is, I'm a big fan of the FSF and their views, but I think their opinion
on this specific issue is a tad too radical, and not legally binding as well.

Regards,
  Jakob

[Jeff Eaton]

On Aug 30, 2007, at 7:02 AM, Jakob Petsovits wrote:

> My understanding was that non-GPL software may not be a derivative  
> work of
> GPL code, but that it can go the other way round. As David Strauss  
> mentioned,
> it is indeed possible to write GPL software by using the Win32 or  
> Cocoa API.
>
> Following this reasoning, it would mean the following for Drupal  
> modules:
> - Drupal modules are based on Drupal, so they are GPL in any case.
> - Thus, modules may not incorporate code that make the integrated  
> software
>   derive (call functions) from Drupal or the module itself.
> - Whereas it should be possible to call functions from the  
> integrated software
>   from the module.

This was my understanding for a while, but the FSF's position is that  
the use of the thre components together creates a single piece of  
software, at least when implemented in the way that bridge modules  
generally do. GPL software *may not derive from non-GPL components*  
unless the copyright holders make them GPL'd as well. This is,  
according to the GPL, to protect the GPL license from being abused by  
companies that write proprietary software with a thing GPL'd  
"wrapper" that is useless when not used with the pricey software.

> For example, that would mean no authentication in the integrated  
> software that
> is based on Drupal users and passwords. Or displaying any  
> information that
> comes from Drupal.
> But it should be possible to manage and display stuff from the  
> integrated
> software from Drupal. Like is done with Apache, for example (which  
> uses the
> GPLv2 incompatible Apache license). I'm sure there are lots of  
> other good
> examples.
>
> Would this make sense?

That's similar to a question I asked. The issue ultimately lies in  
HOW the software is integrated. 'loosely coupled' mechanisms like  
REST, most XMLRPC stuff, direct manipulation of databases without  
calling APIs, etc., are generally OK because they are 'standard  
mechanisms that separate porgrams use to communicate with each  
other.' No matter what we call it, most bridge modules ultimately  
work out to: "Program 2 is sucked into the execution chain of some  
Drupal code, via a bridge module."

I'll quote Brett Smith, the helpful GPL guy who spent a couple days  
hashing this out with me.

----
Perhaps you meant some kind of web services API, like a REST
interface.  That's a little more borderline.

There could also be other ways to construct the bridge that even more
clearly avoid making a derivative work.  For example, if the bridge  
didn't
call functions from either program, and instead just read from or  
wrote to
their underlying databases directly, that probably wouldn't create a
derivative work.  If there were command-line tools available that the
bridge could call to help with its work, using system() or similar
functionality, that probably wouldn't make a derivative work either.

I should also point out that if CMS developers want to make this sort of
bridge development unambiguously okay, they could do so by providing  
some
sort of licensing exception as described at
<http://www.fsf.org/licensing/licenses/gpl- 
faq.html#LinkingOverControlledInterface>.
This requires the assent of all the copyright holders, so I realize  
it may
not be a feasible option for every free CMS, but it is out there.
----

> David's argument that the GPL only covers distribution, not usage,  
> is a good
> counter argument to this point of view. Of course, this is somewhat  
> of a
> difficult issue, quite comparable to the kernel module blobs for  
> the ATI and
> nVidia graphics card drivers which are widely considered a legal  
> gray area.
>
> Also, you could extend the issue not only to PHP code but also to  
> XML-RPC
> calls, where you do not even know if the software that you  
> communicate with
> is GPL or not.

Regarding graphics cards and so on, I asked the same question:

----
"So, for example, we believe that programs that merely run on top of  
a given
kernel are not derivative works of that kernel, even if they make basic
system calls that the kernel provides.  Because of this, the license  
of the
kernel doesn't matter to a GPLed application.

"The second thing that comes into play is called the System Library
exception.  This isn't the technical definition, but in short, the  
GPL also
doesn't worry about the licenses of libraries that are essential to the
operating system.  This is also in the fifth paragraph of section 2."
----

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.

So, while no one is going to root around your server seeing if you've  
called include() on something non-GPL, distributing that middle  
component is, in the FSF's eyes, an attempt to circumvent the GPL.  
I'll quote again:

----
"The developers of the bridge are just looking to accomplish a
particular task and find a license that doesn't get them in trouble.
Unlike my scenario, nobody's obviously scheming to thwart the GPL.  But
when you just look at the structure of all the code when all's said and
done, the two cases look very similar.  And the structure of the code is
overwhelmingly what concerns copyright law.  It would be very hard to
distinguish between these cases in a legally secure way in the license."
----

Again, I want to make clear that I'm not saying that I agree or  
disagree, just that I went through the work of asking and clarifying  
the FSF's position on a lot of these edge case questions, and hope to  
clarify.

More than anything, I want to make sure that the advice we give to  
other developers when we're asked, "Hey! Can I do X?" is accurate.

I should also clarify that in our discussions it was obvious that  
things like images, CSS, HTML, etc was NOT in fact covered. So, for  
example, it would be perfectly legal to create a Drupal theme that  
consists of nothing but images and CSS files (using drupal 6's  
new .info file format) and release it under a non-GPL license.  
Obviously, it couldn't be checked into Drupal's CVS repository in  
that case.

--Jeff

[Larry Garfield]

Hrm.  So, a few applied examples:

Suppose for a moment that TinyMCE was non-GPL.  Someone other than the TinyMCE authors writes our TinyMCE module, which is a wrapper with value-add around TinyMCE to make it work in Drupal.  The TinyMCE module is distributed GPL, and end-users are expected to download TinyMCE themselves and put them together.  There is no distribution of the combined code.  Legal or illegal?  

I was always under the impression that was legal, since there was no distribution of non-GPLed code and GPLed code together.  nVidia is, too, since that's how the nvidia drivers for Linux work. :-)  (non-Free driver and GPLed wrapper that goes into the kernel.)

Scenario 2: A theme engine that is designed to consume non-PHPTemplate template files produced by a non-Free system, such as Dreamweaver or a design-time CMS.  Legal or illegal?  I was also under the impression this was legal, since the engine is GPLed and the files generated by the non-Free system are technically output of it (which is explicitly not affected by the GPL) rather than the code itself.

(A linked work, according to the FSF's GPL FAQ (wow that's a lot of TLAs), means sharing the same memory space or data structures in memory.  PHP certainly does that, as each server process has only one memory space and code can access any data structure it wants.)

--Larry Garfield

On Thu, 30 Aug 2007 09:32:56 -0500, Jeff Eaton <jeff@...> wrote:

>
> On Aug 30, 2007, at 7:02 AM, Jakob Petsovits wrote:
>
>> My understanding was that non-GPL software may not be a derivative
>> work of
>> GPL code, but that it can go the other way round. As David Strauss
>> mentioned,
>> it is indeed possible to write GPL software by using the Win32 or
>> Cocoa API.
>>
>> Following this reasoning, it would mean the following for Drupal
>> modules:
>> - Drupal modules are based on Drupal, so they are GPL in any case.
>> - Thus, modules may not incorporate code that make the integrated
>> software
>>   derive (call functions) from Drupal or the module itself.
>> - Whereas it should be possible to call functions from the
>> integrated software
>>   from the module.
>
> This was my understanding for a while, but the FSF's position is that
> the use of the thre components together creates a single piece of
> software, at least when implemented in the way that bridge modules
> generally do. GPL software *may not derive from non-GPL components*
> unless the copyright holders make them GPL'd as well. This is,
> according to the GPL, to protect the GPL license from being abused by
> companies that write proprietary software with a thing GPL'd
> "wrapper" that is useless when not used with the pricey software.
>
>
>> For example, that would mean no authentication in the integrated
>> software that
>> is based on Drupal users and passwords. Or displaying any
>> information that
>> comes from Drupal.
>> But it should be possible to manage and display stuff from the
>> integrated
>> software from Drupal. Like is done with Apache, for example (which
>> uses the
>> GPLv2 incompatible Apache license). I'm sure there are lots of
>> other good
>> examples.
>>
>> Would this make sense?
>
> That's similar to a question I asked. The issue ultimately lies in
> HOW the software is integrated. 'loosely coupled' mechanisms like
> REST, most XMLRPC stuff, direct manipulation of databases without
> calling APIs, etc., are generally OK because they are 'standard
> mechanisms that separate porgrams use to communicate with each
> other.' No matter what we call it, most bridge modules ultimately
> work out to: "Program 2 is sucked into the execution chain of some
> Drupal code, via a bridge module."
>
> I'll quote Brett Smith, the helpful GPL guy who spent a couple days
> hashing this out with me.
>
> ----
> Perhaps you meant some kind of web services API, like a REST
> interface.  That's a little more borderline.
>
> There could also be other ways to construct the bridge that even more
> clearly avoid making a derivative work.  For example, if the bridge
> didn't
> call functions from either program, and instead just read from or
> wrote to
> their underlying databases directly, that probably wouldn't create a
> derivative work.  If there were command-line tools available that the
> bridge could call to help with its work, using system() or similar
> functionality, that probably wouldn't make a derivative work either.
>
> I should also point out that if CMS developers want to make this sort of
> bridge development unambiguously okay, they could do so by providing
> some
> sort of licensing exception as described at
> <http://www.fsf.org/licensing/licenses/gpl-
> faq.html#LinkingOverControlledInterface>.
> This requires the assent of all the copyright holders, so I realize
> it may
> not be a feasible option for every free CMS, but it is out there.
> ----
>
>
>> David's argument that the GPL only covers distribution, not usage,
>> is a good
>> counter argument to this point of view. Of course, this is somewhat
>> of a
>> difficult issue, quite comparable to the kernel module blobs for
>> the ATI and
>> nVidia graphics card drivers which are widely considered a legal
>> gray area.
>>
>> Also, you could extend the issue not only to PHP code but also to
>> XML-RPC
>> calls, where you do not even know if the software that you
>> communicate with
>> is GPL or not.
>
> Regarding graphics cards and so on, I asked the same question:
>
> ----
> "So, for example, we believe that programs that merely run on top of
> a given
> kernel are not derivative works of that kernel, even if they make basic
> system calls that the kernel provides.  Because of this, the license
> of the
> kernel doesn't matter to a GPLed application.
>
> "The second thing that comes into play is called the System Library
> exception.  This isn't the technical definition, but in short, the
> GPL also
> doesn't worry about the licenses of libraries that are essential to the
> operating system.  This is also in the fifth paragraph of section 2."
> ----
>
> 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.
>
> So, while no one is going to root around your server seeing if you've
> called include() on something non-GPL, distributing that middle
> component is, in the FSF's eyes, an attempt to circumvent the GPL.
> I'll quote again:
>
> ----
> "The developers of the bridge are just looking to accomplish a
> particular task and find a license that doesn't get them in trouble.
> Unlike my scenario, nobody's obviously scheming to thwart the GPL.  But
> when you just look at the structure of all the code when all's said and
> done, the two cases look very similar.  And the structure of the code is
> overwhelmingly what concerns copyright law.  It would be very hard to
> distinguish between these cases in a legally secure way in the license."
> ----
>
> Again, I want to make clear that I'm not saying that I agree or
> disagree, just that I went through the work of asking and clarifying
> the FSF's position on a lot of these edge case questions, and hope to
> clarify.
>
> More than anything, I want to make sure that the advice we give to
> other developers when we're asked, "Hey! Can I do X?" is accurate.
>
> I should also clarify that in our discussions it was obvious that
> things like images, CSS, HTML, etc was NOT in fact covered. So, for
> example, it would be perfectly legal to create a Drupal theme that
> consists of nothing but images and CSS files (using drupal 6's
> new .info file format) and release it under a non-GPL license.
> Obviously, it couldn't be checked into Drupal's CVS repository in
> that case.
>
> --Jeff

[FGM]

First, mandatory disclaimer: IANAL, so this is only an interpretation in
general terms, not advice to anyone, for which they'd have to consult a
lawyer. This being said...

The last "obviously" is not so obvious: since committers have had to agree
to only submitting code to be distributed by d.o. under GPLv2, everything
they commit will be distributed by d.o. under that license.

But it does not prevent *additional* licenses to be available for the same
code, as long as they are compatible with the GPLv2.

Case in point: my own modules are originally created and distributed under
the CeCILL 2.0, because the GPL has various issues under french law.
According to both the FSF and the CeCILL authors, both licenses are
compatible with each other, so no incompatibility arises.

Details at:
http://www.fsf.org/licensing/licenses#CeCILL
http://www.cecill.info/licences.en.html

Now, since I commit this code to d.o., I have to make it available from d.o.
under the GPLv2 (actually: licensing it to d.o. under the GPLv2), because
this is a prerequisite to be allowed to commit there. As a consequence, any
user obtaining the code from d.o. obtains it under both licenses, at his
choice: the GPLv2, available for everything downloaded from d.o. due the
requirement on committers, or CeCILLv2, because an *additional* compatible
license to GPLv2 has been specified in the module files.

This is only possible because the license are compatible, otherwise this
would be a violation of the GPL and possibly of the other license, but any
user will probably want to use the product under the CeCILL because it is
better for them. There's a rather good explanation on wikipedia, even better
than on the very site of the CeCILL:
http://en.wikipedia.org/wiki/CeCILL#CeCILL_version_2

The same dual (or even multiple) licensing mechanism would work with any
GPL-compatible license. Not there are that many available, actually...

So code released under a non-GPL license can be checked into Drupal's CVS
repository, as long as:
- it is also released under the GPL
- the other license does not prevent it.

FGM

----- Original Message -----
From: "Jeff Eaton" <jeff@...>
To: <development@...>
Sent: Thursday, August 30, 2007 4:32 PM
Subject: Re: [development] Modules that integrate non-GPL PHP apps
violatethe GPL.
[...]
> So, for
> example, it would be perfectly legal to create a Drupal theme that
> consists of nothing but images and CSS files (using drupal 6's
> new .info file format) and release it under a non-GPL license.
> Obviously, it couldn't be checked into Drupal's CVS repository in
> that case.
>
> --Jeff
>

[Jeff Eaton]

On Aug 30, 2007, at 1:06 PM, FGM wrote:

> So code released under a non-GPL license can be checked into  
> Drupal's CVS
> repository, as long as:
> - it is also released under the GPL
> - the other license does not prevent it.

FGM, that's correct. Sorry I was unclear when I said that. :)

The only caveat mentioned by the FSF was that such dual-licensing  
would NOT be an acceptable workaround to the 'bridge code' problem.  
In other words, "Drupal is GPL, my module is GPL AND LGPL, so the  
piece that connects to my module isn't affected by the GPL" is  
invalid due to the fact that anything sharing address space with  
Drupal (ie, included PHP files) has to be compatible with ITS  
license, not just the module's license.

--Jeff

[FGM]

Indeed. Which brings back the web services loophole.

I reread about it, and it appears it wasn't eventually closed in GPLv3: they
created the Affero GPL for that specific purpose.
http://gplv3.fsf.org/agplv3-dd1-guide.html

I suppose this improves the likelihood of more code being moved over to
GPLv3. The AGPL provisions should only appeal to a limited crowd.

----- Original Message -----
From: "Jeff Eaton" <jeff@...>
To: <development@...>
Sent: Thursday, August 30, 2007 8:19 PM
Subject: Re: [development] Modules that integrate non-GPL PHP appsviolatethe
GPL.

> On Aug 30, 2007, at 1:06 PM, FGM wrote:
>
> > So code released under a non-GPL license can be checked into
> > Drupal's CVS
> > repository, as long as:
> > - it is also released under the GPL
> > - the other license does not prevent it.
>
> FGM, that's correct. Sorry I was unclear when I said that. :)
>
> The only caveat mentioned by the FSF was that such dual-licensing
> would NOT be an acceptable workaround to the 'bridge code' problem.
> In other words, "Drupal is GPL, my module is GPL AND LGPL, so the
> piece that connects to my module isn't affected by the GPL" is
> invalid due to the fact that anything sharing address space with
> Drupal (ie, included PHP files) has to be compatible with ITS
> license, not just the module's license.
>
> --Jeff
>

[Vivek Puri]

Just for background this issue has come up because
Joomla  have decided to "fully" comply with GPL. This
raised a few question for SMF team and they discussed
it with FSF. The final result of that discussion is if
php ( or any other scripting language ) which is
distributed in source form is bridged to a non GPL
software also distributed in source form then it
violates the GPL.

The immediate effect for drupal is that VB and SMF
bridges are violating GPL. It doesn't matter if its
being distributed via d.o. or not.

This discussion is very interesting because it clearly
highlights that for some people GPL means free
software i.e. free as in beer ;)




       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

[Laura Scott]

On Aug 30, 2007, at 8:32 AM, Jeff Eaton wrote:
> GPL software *may not derive from non-GPL components* unless the  
> copyright holders make them GPL'd as well. This is, according to  
> the GPL, to protect the GPL license from being abused by companies  
> that write proprietary software with a thing GPL'd "wrapper" that  
> is useless when not used with the pricey software.

I'm all behind this reasoning. However....

>
> I'll quote Brett Smith, the helpful GPL guy who spent a couple days  
> hashing this out with me.
>
> ----
> Perhaps you meant some kind of web services API, like a REST
> interface.  That's a little more borderline.
>
> There could also be other ways to construct the bridge that even more
> clearly avoid making a derivative work.  For example, if the bridge  
> didn't
> call functions from either program, and instead just read from or  
> wrote to
> their underlying databases directly, that probably wouldn't create a
> derivative work.  If there were command-line tools available that the
> bridge could call to help with its work, using system() or similar
> functionality, that probably wouldn't make a derivative work either.
>
> I should also point out that if CMS developers want to make this  
> sort of
> bridge development unambiguously okay, they could do so by  
> providing some
> sort of licensing exception as described at
> <http://www.fsf.org/licensing/licenses/gpl- 
> faq.html#LinkingOverControlledInterface>.
> This requires the assent of all the copyright holders, so I realize  
> it may
> not be a feasible option for every free CMS, but it is out there.

This reasoning seems to employ arguments made by the RIAA and MPAA,  
except to opposite effect.

I write this as a GPL advocate and a big believer in open source. GPL  
open source software is greatly advantaged to dominate the software  
world eventually, but trying to force that through legal ownership  
assertions strikes me as a great way to undermine the whole movement.  
For example, this API argument: by prohibiting use of APIs to bridge  
differently-licensed applications (and aren't APIs developed  
*precisely* to bridge two different applications?) we're forcing a  
"dumbing down" of work (and sundry other potential problems and  
risks) by legally requiring the bypassing of established application  
methodologies (such as security protocols) to write direct queries to  
databases.

How are we going to build an integrated world when GPL starts  
claiming rights to all that touch it? We're going from the freedom  
that comes from building a commons to the restriction that comes from  
making that commons a fenced-in zoo.

Maybe I'm wrong and going off in high spirits for no reason. The net  
result, I fear, is the creation of a GPL ghetto where anybody with  
one foot in the proprietary -- i.e., real -- world is given reason to  
hesitate coming within a country mile of GPL, just when GPL apps are  
poised (and have already started) to transform the mainstream  
business world.

Vivek Purl wrote:

> Just for background this issue has come up because
> Joomla  have decided to "fully" comply with GPL. This
> raised a few question for SMF team and they discussed
> it with FSF. The final result of that discussion is if
> php ( or any other scripting language ) which is
> distributed in source form is bridged to a non GPL
> software also distributed in source form then it
> violates the GPL.
>
> The immediate effect for drupal is that VB and SMF
> bridges are violating GPL. It doesn't matter if its
> being distributed via d.o. or not.

So GPL apps are prohibited from touching non-GPL apps. I'll be snarky  
and say this is the kind of thing that happens when lawyers get  
involved. Time to stop developing software and start developing new  
licenses and lawsuits!

Laura (who's still wondering what was wrong with GPLv2)

[Piermaria Maraziti]

At 23.04 30/08/2007, you wrote:

<delurking>

>For example, this API argument: by prohibiting use of APIs to bridge
>differently-licensed applications (and aren't APIs developed
>*precisely* to bridge two different applications?) we're forcing a
>"dumbing down" of work (and sundry other potential problems and
>risks) by legally requiring the bypassing of established application
>methodologies (such as security protocols) to write direct queries to
>databases.

If GPL programs do exist in windows (and mac) environments it is
fairly obvious that use API of differently-licensed applications...
or they write pixels directly in the graphic card and sectors
directly in the hard disk?

Sorry to be rude but this had to be said this way... if I'm wrong I
apologize, but I think I'm not.

</delurking>

Ciao!

--8<-----------------------------------fnord-----
Piermaria Maraziti piermaria@... KALLISTI
ICQ744473  MSN:kallisti@...  +3934735GILDA
www.gilda.it   www.eridia.it   www.hovistocose.it

[Gerhard Killesreiter]

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

Piermaria Maraziti schrieb:

> At 23.04 30/08/2007, you wrote:
>
> <delurking>
>
>> For example, this API argument: by prohibiting use of APIs to bridge
>> differently-licensed applications (and aren't APIs developed
>> *precisely* to bridge two different applications?) we're forcing a
>> "dumbing down" of work (and sundry other potential problems and
>> risks) by legally requiring the bypassing of established application
>> methodologies (such as security protocols) to write direct queries to
>> databases.
>
> If GPL programs do exist in windows (and mac) environments it is fairly
> obvious that use API of differently-licensed applications... or they
> write pixels directly in the graphic card and sectors directly in the
> hard disk?
>
> Sorry to be rude but this had to be said this way... if I'm wrong I
> apologize, but I think I'm not.

You are completely wrong and you had better stayed in some dark corner.

The "problem" we are facing is due to the nature of how PHP and probably
other scripting languages work. The situation isn't comparable to a
compiled programms.

One could argue that one shouldn't place PHP programms under the GPL
license.

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

iD8DBQFG10/Ifg6TFvELooQRAjQwAJ9Gd/Fa1wyyzBdOCoUoU/X1R9p4EACgpj9m
yAQXsDpzuHapE0cB3hf10OA=
=f12K
-----END PGP SIGNATURE-----

[mark burdett-3]

Is there a similar situation with javascript executing in the browser
environment?
It's common to integrate various javascript libraries which may have
different licenses (and pull in js from other sites via <script> tags)

--mark

On 8/30/07, Gerhard Killesreiter <gerhard@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Piermaria Maraziti schrieb:
> > At 23.04 30/08/2007, you wrote:
> >
> > <delurking>
> >
> >> For example, this API argument: by prohibiting use of APIs to bridge
> >> differently-licensed applications (and aren't APIs developed
> >> *precisely* to bridge two different applications?) we're forcing a
> >> "dumbing down" of work (and sundry other potential problems and
> >> risks) by legally requiring the bypassing of established application
> >> methodologies (such as security protocols) to write direct queries to
> >> databases.
> >
> > If GPL programs do exist in windows (and mac) environments it is fairly
> > obvious that use API of differently-licensed applications... or they
> > write pixels directly in the graphic card and sectors directly in the
> > hard disk?
> >
> > Sorry to be rude but this had to be said this way... if I'm wrong I
> > apologize, but I think I'm not.
>
> You are completely wrong and you had better stayed in some dark corner.
>
> The "problem" we are facing is due to the nature of how PHP and probably
> other scripting languages work. The situation isn't comparable to a
> compiled programms.
>
> One could argue that one shouldn't place PHP programms under the GPL
> license.
>
> Cheers,
>         Gerhard
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG10/Ifg6TFvELooQRAjQwAJ9Gd/Fa1wyyzBdOCoUoU/X1R9p4EACgpj9m
> yAQXsDpzuHapE0cB3hf10OA=
> =f12K
> -----END PGP SIGNATURE-----
>

[Gerhard Killesreiter]

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

mark burdett schrieb:
> Is there a similar situation with javascript executing in the browser
> environment?
> It's common to integrate various javascript libraries which may have
> different licenses (and pull in js from other sites via <script> tags)

That's a very interesting question. I guess the FSF guy would happily
discuss this with you.
Let us know what he says.

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

iD8DBQFG11awfg6TFvELooQRAmgcAKCL98oncaRTzxEEpc5oAgBjwWZ6pgCgt5nd
Vl24O60+MBYR3cFNUp1LVWE=
=sPhT
-----END PGP SIGNATURE-----

[Karoly Negyesi]

> If GPL programs do exist in windows (and mac) environments it is
> fairly obvious that use API of differently-licensed applications...
> or they write pixels directly in the graphic card and sectors
> directly in the hard disk?

The difference here could be that these are compiled programs and DLLs... could be different legalese than a script lang like PHP.

[Vivek Puri]

> I write this as a GPL advocate and a big believer in
> open source.

ahem whats the point of advocating something which you
don't understand ?

>
> How are we going to build an integrated world when
> GPL starts  
> claiming rights to all that touch it?

That has always been the case, don't you know GPL is
also called viral license for a reason ;)

> So GPL apps are prohibited from touching non-GPL
> apps. I'll be snarky  
> and say this is the kind of thing that happens when
> lawyers get  
> involved. Time to stop developing software and start
> developing new  
> licenses and lawsuits!
>

Unfortunately like many you misunderstood GPL to be
free as in beer. This issue is not new interpretation
its has always been like that. People started building
bridges between GPl & proprietary licensed software
without fully understanding GPL ( this is all relevant
to software distributed in source form)

> Laura (who's still wondering what was wrong with
> GPLv2)

This issue is relevant to GPLv2 we are not even
discussing impact of GPLv3
>
>
>



       
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow 

[Vivek Puri]

--- mark burdett <mfburdett@...> wrote:

> Is there a similar situation with javascript
> executing in the browser
> environment?
> It's common to integrate various javascript
> libraries which may have
> different licenses (and pull in js from other sites
> via <script> tags)

You have a valid point but as I see most prominent
javascript libraries are distributed either under BSD,
LGPL or MIT licenses. And these licenses are somewhat
liberal in this sense.
Again you are free to mix and match as long as you
dont distribute. If you start distributing GPL
software with other's the other license must be GPL
compatible.




       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

[Thomas Barregren]

David Strauss wrote:

> David Strauss wrote:
>  
>> 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.)
>>    
>
> The reason I think this is the case is because the GPL code is not
> distributed with the non-GPL code.
>
> It's OK to distribute a C++ program that uses STL, even though there are
> proprietary STL implementations. It's also OK for me to compile GPL code
> against a proprietary STL implementation, as long as I don't
> redistribute the binary.
>
> The only distinction left is that some Drupal modules can *only* link to
> non-GPL code, but that seems to be a dubious place to draw the line. If
> we draw the line there, applications using Cocoa break the GPL.
> Applications using parts of the Windows API absent from Wine break the GPL.
>  

Applications depending on Cocoa or Windows API *do not* violate GPL.
Paragraph 3 in GPL v2 (which is used by Drupal) clearly and loudly states:

> However, as a
> special exception, the source code distributed need not include
> anything that is normally distributed (in either source or binary
> form) with the major components (compiler, kernel, and so on) of the
> operating system on which the executable runs, unless that component
> itself accompanies the executable.

RTFL ;-)

Regards,
Thomas