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

[Thomas Barregren]

David Strauss skrev:

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

Wrong. You are allowed to add ny terms and condition you which as long
as long as you don't impose any further restrictions on the recipients'
exercise of the rights granted in GPL. See paragraph 6 of GPL v2 (which
is used by Drupal). In fact, FSF/GNU tells you to add such notice to
allow use of non-GPL libraryies. Read the FAQ:

  * http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense
  * http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
  * http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface

MySQL is an example of this:

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

In fact, if MySQL didn't add that notice, Drupal had not been able to
use MySQL, since the PHP licence isn't compatible with GPL v2.


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

Wrong. If a module depends on a software with a license not compatible
with GPL, then that module can't be distributed under GPL.

Read the FAQ:

  * http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
  * http://www.gnu.org/licenses/gpl-faq.html#MoneyGuzzlerInc


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

Isn't that to live by double standard? Why is it okay to violate the GPL
when it comes to modules, but not when it comes to the core itself?


The solution, IMHO, is to add a FLOSS exception to Drupal.

Regards,
Thomas

[Piermaria Maraziti]

At 01.50 31/08/2007, you wrote:

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

It is a fairly small difference to me. An API is an API and the fact
that it is compiled in a DLL or scripted, apart from the visibility
of code has no real philosophical or legalese difference.
#include in a scripting language or dll loading instructions in
C/C++/Delphi are, semantically, equivalent and the difference that in
the first case PHP will parse & tokenize the non-GPL'ed script on the
fly while the DLL was compiled away and given as-is is a minor one.

Please, if you tell me I'm "completely wrong" at least have the
kindness of saying me why. Thanks. :-)

Added: I just read from Thomas about the "Paragraph 3 in GPL v2".
This is a completely different thing obviously. However, I saw Delphi
programs distributed under GPL and they probably include Delphi
(redistributable) libraries. Are, perhaps, the authors of those
programs interpreting in a wrong way the GPL? If so I retire in good order ;-)

Ciao!

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

[Thomas Barregren]

Jakob Petsovits skrev:

> 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

Let us be careful with the wording here.

As soon as you make a derivative of a GPL:ed code, it automatically
becomes non-GPL:ed. That is because you and only you have the right to
derivative work by copyright laws.

GPL don't prohibit you from using the derivative. On the contrary, GPL
was written to ensure you this right. It is one of the four fundamental
freedoms that GPL strives to give you.

But you are not allowed to *distribute* your derivative work without GPL it.

Thus, any company or individual are free to download and integrate
Drupal with their very secret and proprietary software. As long as they
don't distribute it, they are not violating GPL.

BTW, many people seems to believe that just because a derivative work is
made from a GPL:ed software, they can demand a copy of the derivative
work. If the derivative work never has been distributed, they are wrong.
If the derivative work has been distributed including the source code,
they are wrong. But, if the derivative work has been distributed with
only an offer to obtain the source code, e.g. by downloading it, they
are right. See § 3 (and § 3b in particular) in GPL v2.

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

You can that because of an exception in § 3 of GPL v2.

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

You are right so far.

> - Whereas it should be possible to call functions from the integrated software
>   from the module.
>  

It depends on how the module calls the function in the integrated
software. Read the FAQ:

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

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

Again, this only applies to derivate works which is distributed.

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

What do you mean? Drupal is not integrated with Apache HTTP Server (as
far as I understand). It only runs on it.

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

Wrong. Jeff Eaton is right. If two programs are so tight integrated that
"...debug_backtrace() can ever include functions from both...", both
must be GPL:ed.

The only exception is "...anything that is normally distributed (in
either source or binary form) with the major components (compiler,
kernel, and so on) of the operating system..." according to § 3 in GPL v2.

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

I think you are wrong.

PHP: The PHP license is not compatible with GNU v2. If you want to add a
GPL:ed extension to PHP, that is a problem (which easily can be remedied
with a FLOSS Exception). But it is not a problem from Drupal. Why? The
GPL permits this because PHP falls under the exception in § 3 of GPL v2.

XML-RPC: IMHO, a program accessing Drupal through XML-RPC need not to
generally be under GPL. Why? In normal use of XML-RPC the client is
separate from Drupal, and hence not subject for reciprocity of GPL.
Compare this with one program calling another program though fork and
exec. Read more in the FAQ:

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


Best regards,
Thomas

[Thomas Barregren]

Jeff Eaton wrote:

<SNIP>

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

See also http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#WMS

Best regards,
Thomas

[Thomas Barregren]

Larry Garfield skrev:
> 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?

Illegal. See

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

However, if both Drupal and the module makes an exception, it is legal.
There are two common exceptions made: The FLOSS Exception and the
Controlled Interface Exception. See

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

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

Legal. The output of Drupal is not a derivative work based on Drupal.
Hence GPL don't apply. Furthermore, the template is just data to Drupal.

There are several related answers in the GPL FAQ. Here are a few:

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


Best regards,
Thomas

[Thomas Barregren]

Laura Scott wrote:

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

That might be due to the fact that both FSF/GNU and RIAA/MPAA use the
same copyright law. :-)

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

The beauty of GPL is that is doesn't fight the copyright laws. Quite the
opposite! GPL leverage on the copyright laws to protect your freedom to

    * to run the program for any purpose.
    * to study and modify the program.
    * to copy the program so you can help your neighbor.
    * to improve the program, and release your improvements to the
public, so that the whole community benefits.

Or, as Dr. Debora Halbert put it:

    "Essentially, Stallman has codified sharing in order to prevent
    profiteers from stealing from the public domain. The GPL cleverly
    uses the power of copyright law (which allows the author of the
    product to control its use and distribution) to provide software for
    free.[56] In this way he transformed the rules of the game and
    redefined copyright (what he calls copyleft) into a tool the
    supports the creator and users of software."

    See § 46 in
    http://www.murdoch.edu.au/elaw/issues/v10n4/halbert104_text.html#GNU/GPL%20License_T.

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

GPL allows you to use both GPL:ed and non-GPL:ed API:s to bridge
different applications. GPL also allows you to distribute the derivative
work which emerges thereby. But to make sure that *you* don't deny the
receiver the same rights as you got, GPL requires you to distributed the
derivative work under GPL. Therefore I think this reciprocity of GPL
(a.k.a. "copyleft") is something very good.

The reciprocity prevents *distribution* of works derived partly from a
third-party software with a license which is not compatible with GPL.
Normally, this is also something good. As is said on the GPL FAQ:

    "If we permitted company A to make a proprietary file, and company B
    to distribute GPL-covered software linked with that file, the effect
    would be to make a hole in the GPL big enough to drive a truck
    through. This would be carte blanche for withholding the source code
    for all sorts of modifications and extensions to GPL-covered software."

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


But, as this discussion is about, this can also pose a hindrance for
situations where it can seem reasonable to include software with license
not compatible with GPL.

For an example, imagine someone who has put in a lot of effort to write
code that integrates a popular but proprietary software with Drupal. So
far it is okay under GPL. But now he wants to share his effort with the
community. Since the integration code calls functions and share data
structures with both the proprietary software and Drupal, it is not allowed.

Fortunately, there is a solution. As long as you don't revoke any rights
granted by GPL, you can add your own terms and conditions. This can be
used to allow integration with software under a license incompatible
with GPL. Two examples on this:

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

So, to solve the problem 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.

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

Pardon???

All what had been said applies to GPL v2 as well as v3. So you concerns
must consequently also apply to GPL v2 which is used by Drupal. Correct?


Best regards,
Thomas

[Thomas Barregren]

Gerhard Killesreiter skrev:

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

I wonder if you have misunderstood the subject of the discussion. The
issue original brought up by Jeff Eaton was about the fact that it is
not permissible to write modules that bridge software with a license not
compatible with GPL.

But I cannot refrain from asking what problem you see with "the nature
of how PHP and probably other scripting languages work."? If it is the
meaning of "linking" you are troubled by, please read:

  * http://www.gnu.org/licenses/lgpl-java.html

If it is the fact that program in a scripting language is linked with
its interpreter, please read:

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


Best regards,
Thomas

[Thomas Barregren]

mark burdett skrev:
> 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)

Please read

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


Best regards,
Thomas

[Jeff Eaton]

On Aug 31, 2007, at 3:45 AM, Piermaria Maraziti wrote:

> At 01.50 31/08/2007, you wrote:
>
>> The difference here could be that these are compiled programs and  
>> DLLs... could be different legalese than a script lang like PHP.
>
> It is a fairly small difference to me. An API is an API and the  
> fact that it is compiled in a DLL or scripted, apart from the  
> visibility of code has no real philosophical or legalese difference.

Actually, according to the terms of the GPL, and the FSF's  
interpretation of it and the public FAQs they have posted, *only DLLs  
that are part of the OS would be allowed to the included in such a way*.

--Jeff

[Laura Scott]

On Aug 31, 2007, at 6:05 AM, Thomas Barregren wrote:

> The issue original brought up by Jeff Eaton was about the fact that  
> it is not permissible to write modules that bridge software with a  
> license not compatible with GPL.

This interpretation is tragic for GPL applications, imho. It makes  
GPL toxic to other non-GPL applications out there. IANAL. I speak  
only to my perception of how such reasoning can effect the adoption  
of GPL throughout the world.

>>
>> This reasoning seems to employ arguments made by the RIAA and  
>> MPAA, except to opposite effect.
>
> That might be due to the fact that both FSF/GNU and RIAA/MPAA use  
> the same copyright law. :-)

Law is open to interpretation, and the legal tactics of the RIAA and  
MPAA are hardly universally viewed as being consistent with copyright  
law.

Not to mention how they are attacking their own customers in the  
process and undermining their own markets. I believe the cliche is  
"to cut off ones nose to spite ones face."

>
>> 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.
>
> The beauty of GPL is that is doesn't fight the copyright laws.  
> Quite the opposite! GPL leverage on the copyright laws to protect  
> your freedom to
>
>    * to run the program for any purpose.

--except to integrate with any non-GPL application.

>    * to study and modify the program.

--unless, of course, you want to bridge it with a non-GPL  
application, apparently.

>    * to copy the program so you can help your neighbor.

--unless, of course, you want to help your neighbor integrate a GPL  
application into his non-GPL universe.

>    * to improve the program, and release your improvements to the  
> public, so that the whole community benefits.

--unless, of course, you software doesn't, in effect, ignore the non-
GPL world.

Suddenly there are caveats in there.

>
> GPL allows you to use both GPL:ed and non-GPL:ed API:s to bridge  
> different applications. GPL also allows you to distribute the  
> derivative work which emerges thereby. But to make sure that *you*  
> don't deny the receiver the same rights as you got, GPL requires  
> you to distributed the derivative work under GPL. Therefore I think  
> this reciprocity of GPL (a.k.a. "copyleft") is something very good.
>
> The reciprocity prevents *distribution* of works derived partly  
> from a third-party software with a license which is not compatible  
> with GPL. Normally, this is also something good. As is said on the  
> GPL FAQ:
>
>    "If we permitted company A to make a proprietary file, and  
> company B
>    to distribute GPL-covered software linked with that file, the  
> effect
>    would be to make a hole in the GPL big enough to drive a truck
>    through. This would be carte blanche for withholding the source  
> code
>    for all sorts of modifications and extensions to GPL-covered  
> software."
>
>    See
>    http://www.gnu.org/licenses/old-licenses/gpl-2.0- 
> faq.html#TOCMoneyGuzzlerInc
>
>
> But, as this discussion is about, this can also pose a hindrance  
> for situations where it can seem reasonable to include software  
> with license not compatible with GPL.
>
> For an example, imagine someone who has put in a lot of effort to  
> write code that integrates a popular but proprietary software with  
> Drupal. So far it is okay under GPL. But now he wants to share his  
> effort with the community. Since the integration code calls  
> functions and share data structures with both the proprietary  
> software and Drupal, it is not allowed.

That's the problem, isn't it? Suddenly "free" does not mean what it  
means. That also seems to mean that proprietary systems need not try  
to integrate with Drupal, even if they want to offer such integration  
to the community under GPL. According to the reasoning at the top of  
this thread, GPL prevents them from doing that. That is a shame  
because it could seriously hinder or prevent the adoption of Drupal  
and other GPL software throughout the business world (where I argue  
it could do a lot of good).

>
> Fortunately, there is a solution. As long as you don't revoke any  
> rights granted by GPL, you can add your own terms and conditions.  
> This can be used to allow integration with software under a license  
> incompatible with GPL. Two examples on this:
>
>  * http://www.gnu.org/licenses/old-licenses/gpl-2.0- 
> faq.html#GPLIncompatibleLibs
>  * http://www.gnu.org/licenses/old-licenses/gpl-2.0- 
> faq.html#LinkingOverControlledInterface
>
> So, to solve the problem 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?


>> Laura (who's still wondering what was wrong with GPLv2)
>
> Pardon???
>
> All what had been said applies to GPL v2 as well as v3. So you  
> concerns must consequently also apply to GPL v2 which is used by  
> Drupal. Correct?

That signoff followed  "Time to stop developing software and start  
developing new licenses and lawsuits!" It was deliberately snarky,  
and as such perhaps confusing to some. My apologies.

Laura

[Larry Garfield]

On Friday 31 August 2007, Piermaria Maraziti wrote:

> At 01.50 31/08/2007, you wrote:
> >The difference here could be that these are compiled programs and
> >DLLs... could be different legalese than a script lang like PHP.
>
> It is a fairly small difference to me. An API is an API and the fact
> that it is compiled in a DLL or scripted, apart from the visibility
> of code has no real philosophical or legalese difference.
> #include in a scripting language or dll loading instructions in
> C/C++/Delphi are, semantically, equivalent and the difference that in
> the first case PHP will parse & tokenize the non-GPL'ed script on the
> fly while the DLL was compiled away and given as-is is a minor one.
>
> Please, if you tell me I'm "completely wrong" at least have the
> kindness of saying me why. Thanks. :-)

Actually there is a legal difference between "statically linked"
and "dynamically linked" (DLL) code.  That's why the GPL and LGPL exist as
two separate licenses.

Of course, that predates the concept of powerful interpreted languages
(PHP), "everything is dynamic by design" languages (Java), etc.  I don't know
off hand if that distinction has been tested in court yet in interpreted
languages (but lots of LGPLed code exists for in PHP, like Smarty, so it
seems the common wisdom is that it's OK, rightly or wrongly.)

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

[Thomas Barregren]

Larry Garfield skrev:

> On Friday 31 August 2007, Piermaria Maraziti wrote:
>  
>> At 01.50 31/08/2007, you wrote:
>>    
>>> The difference here could be that these are compiled programs and
>>> DLLs... could be different legalese than a script lang like PHP.
>>>      
>> It is a fairly small difference to me. An API is an API and the fact
>> that it is compiled in a DLL or scripted, apart from the visibility
>> of code has no real philosophical or legalese difference.
>> #include in a scripting language or dll loading instructions in
>> C/C++/Delphi are, semantically, equivalent and the difference that in
>> the first case PHP will parse & tokenize the non-GPL'ed script on the
>> fly while the DLL was compiled away and given as-is is a minor one.
>>
>> Please, if you tell me I'm "completely wrong" at least have the
>> kindness of saying me why. Thanks. :-)
>>    
>
> Actually there is a legal difference between "statically linked"
> and "dynamically linked" (DLL) code.  That's why the GPL and LGPL exist as
> two separate licenses.
>  

Could you please explain this "legal difference".

Regards,
Thomas

[Thomas Barregren]

Laura Scott skrev:

> On Aug 31, 2007, at 6:05 AM, Thomas Barregren wrote:
>
>> The issue original brought up by Jeff Eaton was about the fact that
>> it is not permissible to write modules that bridge software with a
>> license not compatible with GPL.
>
> This interpretation is tragic for GPL applications, imho. It makes GPL
> toxic to other non-GPL applications out there. IANAL. I speak only to
> my perception of how such reasoning can effect the adoption of GPL
> throughout the world.

You surprise me. GPL has been around for *18 years* and this reciprocity
(a.k.a. "copyleft") is the very heart of the license.

I don't think the reciprocity has any negative effect on the adoption of
GPL. Look at GNU/Linux, MySQL, Java and many more high profile
projects.  They don't look hampered to me. On the contrary! I believe
GPL actually foster new generations of Free and Open Source Software
(FOSS) contributors. As support for this opinion I plead the fact that
GPL is the most used FOSS license. "As of August 2007, the GPL accounted
for nearly 65% of the 43,442 free software projects listed on Freshmeat,
and as of January 2006, about 68% of the projects listed on
SourceForge.net," says Wikipedia. The numbers talk for them self.

>>> 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.
>>
>> The beauty of GPL is that is doesn't fight the copyright laws. Quite
>> the opposite! GPL leverage on the copyright laws to protect your
>> freedom to
>>
>>    * to run the program for any purpose.
>
> --except to integrate with any non-GPL application.

Wrong. You are allowed to integrate GPL-application with any non-GPL
application.


>>    * to study and modify the program.
>
> --unless, of course, you want to bridge it with a non-GPL application,
> apparently.

Wrong. You are allowed to study and modify the program for any reason,
including for the purpose of bridging it with non-GPL application.

>>    * to copy the program so you can help your neighbor.
>
> --unless, of course, you want to help your neighbor integrate a GPL
> application into his non-GPL universe.

Wrong. You are allowed to give your neighbor a opy of the GPLed program,
and you are allowed to help him to integrate it into his non-GPL universe.

>
>>    * to improve the program, and release your improvements to the
>> public, so that the whole community benefits.
>
> --unless, of course, you software doesn't, in effect, ignore the
> non-GPL world.

If you modify the GPLed program it becomes a derived work. You are free
to distribute it under the same license as you obtained it in the first
place. Do you consider it unfair?

> Suddenly there are caveats in there.

Yes, there are caveats in GPL v2. For an example Tivoization
<http://en.wikipedia.org/wiki/Tivoization>. But I assume it is not that
kind of caveats you allude to. :-)

>> GPL allows you to use both GPL:ed and non-GPL:ed API:s to bridge
>> different applications. GPL also allows you to distribute the
>> derivative work which emerges thereby. But to make sure that *you*
>> don't deny the receiver the same rights as you got, GPL requires you
>> to distributed the derivative work under GPL. Therefore I think this
>> reciprocity of GPL (a.k.a. "copyleft") is something very good.
>>
>> The reciprocity prevents *distribution* of works derived partly from
>> a third-party software with a license which is not compatible with
>> GPL. Normally, this is also something good. As is said on the GPL FAQ:
>>
>>    "If we permitted company A to make a proprietary file, and company B
>>    to distribute GPL-covered software linked with that file, the effect
>>    would be to make a hole in the GPL big enough to drive a truck
>>    through. This would be carte blanche for withholding the source code
>>    for all sorts of modifications and extensions to GPL-covered
>> software."
>>
>>    See
>>    
>> http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TOCMoneyGuzzlerInc 
>>
>>
>>
>> But, as this discussion is about, this can also pose a hindrance for
>> situations where it can seem reasonable to include software with
>> license not compatible with GPL.
>>
>> For an example, imagine someone who has put in a lot of effort to
>> write code that integrates a popular but proprietary software with
>> Drupal. So far it is okay under GPL. But now he wants to share his
>> effort with the community. Since the integration code calls functions
>> and share data structures with both the proprietary software and
>> Drupal, it is not allowed.
>
> That's the problem, isn't it? Suddenly "free" does not mean what it means.

Free in the "Free Software" sense can be compared to Free Speech. You
are free to do/say what you want as long as you don't do/say something
that threatens the very same freedom.

> That also seems to mean that proprietary systems need not try to
> integrate with Drupal, even if they want to offer such integration to
> the community under GPL. According to the reasoning at the top of this
> thread, GPL prevents them from doing that. That is a shame because it
> could seriously hinder or prevent the adoption of Drupal and other GPL
> software throughout the business world (where I argue it could do a
> lot of good).

In my experience, as a software developer and entrepreneur, GPL is very
business friendly compared to many of the proprietary software licenses
I have encountered. Obviously, I am not alone of thinking so. Consider
all companies doing business with help of GPL, e.g. Red Hat, MySQL,
SpikeSource and many more. And both your and my companies are good
examples on companies that prosper thanks to GPL.

Being President of pingVision, a company that obviously makes money on a
GPL software, you are surprising ignorant of the license under which
your company are operating.

>> Fortunately, there is a solution. As long as you don't revoke any
>> rights granted by GPL, you can add your own terms and conditions.
>> This can be used to allow integration with software under a license
>> incompatible with GPL. Two examples on this:
>>
>>  *
>> http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLibs 
>>
>>  *
>> http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingOverControlledInterface 
>>
>>
>> So, to solve the problem 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?

Yes, that is how the copyright law works. But I am sure that it should
not an insurmountable difficulty.


Best regards,
Thomas

[David Timothy Strauss]

Thomas Barregren wrote:
> Wrong. You are allowed to add ny terms and condition you which as long
> as long as you don't impose any further restrictions on the recipients'
> exercise of the rights granted in GPL. See paragraph 6 of GPL v2 (which
> is used by Drupal). In fact, FSF/GNU tells you to add such notice to
> allow use of non-GPL libraryies. Read the FAQ:

The license itself says, "Everyone is permitted to copy and distribute
verbatim copies of this license document, but changing it is not
allowed." Paragraph 6 says nothing about producing a modified version of
the GPL. MySQL's exception is rendered as a separate exception document,
not a modification of the GPL. This distinction is important because
people redistributing the code aren't obligated to allow the exceptions
granted by the original licensor.

So, I stand by my statement that, "Direct GPL variants are only allowed
with approval of the FSF." See the AGPL for an example of an approved
variant.

>> I'm not sure that's a problem. The GPL only affects redistribution, not
>> what a person does on his or her own computer. Just ensure the forbidden
>> integration isn't distributed. (If I'm wrong here, I'd like to know.)
>
> Wrong. If a module depends on a software with a license not compatible
> with GPL, then that module can't be distributed under GPL.

If you're going to call someone "wrong," you had better be right:

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

That FAQ item gives instructions for releasing something under the GPL
that links to non-free libraries.

I said, "The GPL only affects redistribution" because the original
distributor has the right to include any exceptions in a supplement to
the license. Re-distributors cannot add such an exception. However, I
also said, "Just ensure the forbidden integration isn't distributed"
because even the owner of the GPL software doesn't have the right to
redistribute software without permission.

>> 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
>
> Isn't that to live by double standard? Why is it okay to violate the GPL
> when it comes to modules, but not when it comes to the core itself?

I didn't say it was OK. I said it wasn't worth policing contributed modules.

[ttw+drupal]

On 31.08-17:52, Thomas Barregren wrote:
[ ... ]
> >>The issue original brought up by Jeff Eaton was about the fact that
> >>it is not permissible to write modules that bridge software with a
> >>license not compatible with GPL.
[ ... ]
> You surprise me. GPL has been around for *18 years* and this reciprocity
> (a.k.a. "copyleft") is the very heart of the license.
[ ... ]
> Wrong. You are allowed to integrate GPL-application with any non-GPL
> application.

i believe you contradict yourself.  the issue is the extension of GPL
to include interfacing software, as below

[ ... ]
> >>   * to study and modify the program.
> >
> >--unless, of course, you want to bridge it with a non-GPL application,
> >apparently.
>
> Wrong. You are allowed to study and modify the program for any reason,
> including for the purpose of bridging it with non-GPL application.
[ ... ]
> >>So, to solve the problem that the licensing of Drupal currently force
> >>us to "dumbing down" or "bypassing of established application
> >>methodologies", I suggest that the Drupal licensing is supplemented
> >>with an exception for module developers linking through hooks.

if you are allowed to study and modify the program for the purpose of
bridging it with non-GPL code then there is no cross pollination of
the licenses.  this has traditionally been done (i.e.  the use of
GPL'd header files in compilation) but often brought under question
by more aggressive GPL proponents.

i think the original author is confused about the exact status of GPL,
especially, in relation to something like hooks where, it would appear
to me, there is no issue.  essentially, i see no reason you could not
interface an application using hooks and keep that application
propiertory.

i am still unclear as to how this may be effected by GPLv3.

[Cog Rusty]

I am all for system thinking and intended uses, but somehow I am
losing the "parts" view here, things like responsibilities,
consequences, legal or other.

Suppose I write a spelling checker for MS Word in VBA (I don't really
know VBA, just an example), with the clear intention to be used with
MS Word and nothing else. I slap a GPL license file with no caveats on
it and I distribute it. What happens now? What does it mean not to be
GPL-compliant in this case, practically?

MS or anyone else can take it, package it in some other software and
sell it, claiming that it is not really GPL? Is that it?

Also, because I have met lawyers before, are there any information
about how the "system" interpretation ever did in court?

[David Timothy Strauss]

Cog Rusty wrote:

> I am all for system thinking and intended uses, but somehow I am
> losing the "parts" view here, things like responsibilities,
> consequences, legal or other.
>
> Suppose I write a spelling checker for MS Word in VBA (I don't really
> know VBA, just an example), with the clear intention to be used with
> MS Word and nothing else. I slap a GPL license file with no caveats on
> it and I distribute it. What happens now? What does it mean not to be
> GPL-compliant in this case, practically?
>
> MS or anyone else can take it, package it in some other software and
> sell it, claiming that it is not really GPL? Is that it?

One of the beautiful things about the GPL is that, when it fails, normal
copyright takes over. So, if the GPL is shown to be invalid on something
you've created, other parties have *no rights* to distribute your work
without other permission.

> Also, because I have met lawyers before, are there any information
> about how the "system" interpretation ever did in court?

For better or worse, the GPL hasn't seen too much time in court.

[Gerhard Killesreiter]

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

David Strauss schrieb:

> Cog Rusty wrote:
>> I am all for system thinking and intended uses, but somehow I am
>> losing the "parts" view here, things like responsibilities,
>> consequences, legal or other.
>>
>> Suppose I write a spelling checker for MS Word in VBA (I don't really
>> know VBA, just an example), with the clear intention to be used with
>> MS Word and nothing else. I slap a GPL license file with no caveats on
>> it and I distribute it. What happens now? What does it mean not to be
>> GPL-compliant in this case, practically?
>>
>> MS or anyone else can take it, package it in some other software and
>> sell it, claiming that it is not really GPL? Is that it?
>
> One of the beautiful things about the GPL is that, when it fails, normal
> copyright takes over. So, if the GPL is shown to be invalid on something
> you've created, other parties have *no rights* to distribute your work
> without other permission.
>
>> Also, because I have met lawyers before, are there any information
>> about how the "system" interpretation ever did in court?
>
> For better or worse, the GPL hasn't seen too much time in court.

Not much, but there have been several recent cases in Germany where
hardware vendors selling Linux based appliances were taken to court and
the courts ordered them to abide by the GPL and include source code etc.

See http://gpl-violations.org/

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

iD8DBQFG2Ehxfg6TFvELooQRAv7mAJ46XYQtaRrlW+Rq05xzqT+mrDKJmwCgsIZs
mp/lKjcDv/h3crOCsHPFm5c=
=ggyT
-----END PGP SIGNATURE-----

[Cog Rusty]

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Strauss schrieb:
> > Cog Rusty wrote:
> >> I am all for system thinking and intended uses, but somehow I am
> >> losing the "parts" view here, things like responsibilities,
> >> consequences, legal or other.
> >>
> >> Suppose I write a spelling checker for MS Word in VBA (I don't really
> >> know VBA, just an example), with the clear intention to be used with
> >> MS Word and nothing else. I slap a GPL license file with no caveats on
> >> it and I distribute it. What happens now? What does it mean not to be
> >> GPL-compliant in this case, practically?
> >>
> >> MS or anyone else can take it, package it in some other software and
> >> sell it, claiming that it is not really GPL? Is that it?
> >
> > One of the beautiful things about the GPL is that, when it fails, normal
> > copyright takes over. So, if the GPL is shown to be invalid on something
> > you've created, other parties have *no rights* to distribute your work
> > without other permission.

I see. So practically nobody would have an interest in challenging the
GPL status of my software, not MS or another vendor, not the user, not
I (except if I changed my mind later). Only a project like Drupal
might challenge it, with the intention to maintain the "virality" of
its software.

> >> Also, because I have met lawyers before, are there any information
> >> about how the "system" interpretation ever did in court?
> >
> > For better or worse, the GPL hasn't seen too much time in court.
>
> Not much, but there have been several recent cases in Germany where
> hardware vendors selling Linux based appliances were taken to court and
> the courts ordered them to abide by the GPL and include source code etc.
>
> See http://gpl-violations.org/
>
> Cheers,
>         Gerhard
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG2Ehxfg6TFvELooQRAv7mAJ46XYQtaRrlW+Rq05xzqT+mrDKJmwCgsIZs
> mp/lKjcDv/h3crOCsHPFm5c=
> =ggyT
> -----END PGP SIGNATURE-----
>

[Jeff Eaton]

On Aug 31, 2007, at 11:43 AM, ttw+drupal@... wrote:

> i think the original author is confused about the exact status of GPL,
> especially, in relation to something like hooks where, it would appear
> to me, there is no issue.  essentially, i see no reason you could not
> interface an application using hooks and keep that application
> propiertory.

If I'm the original author being referred to, it's important to  
remember that I'm summarizing the position articulated to me by the  
FSF after three days of communication, including detailed  
descriptions of how Drupal's hook system operates and how dynamic  
script languages like PHP handle bridging projects.

Please read earlier messages. The FSF's position is that, if two  
projects are calling each others' functions or sharing in-memory data  
structures and so on (even if they do it via an intermediary plugin),  
they are operating as a single unit. There is a LOT of technical  
wrangling in the details of that, but it comes back to the rule of  
thumb:

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

I say this not because I am a torch-waving opponent of proprietary  
software, nor because I am a critic of the GPL. I just think that  
there is a great deal of confusion in the OSS CMS community, and I  
hope to help achieve some clarity. If you have an issue, or a point  
you feel needs to be clarified, ** DO WHAT I DID. CONTACT THE FREE  
SOFTWARE FOUNDATION. ** They're great folks to talk to, and even if  
you don't like the results of your questions, they're very patient  
and willing to help work through the thorny technical details.

--Jeff