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

[Peter Wolanin]

Angela,

this text describes the copyright statement that *should* be in all
the source files.  As far as I can tell, since none of the files
actually specify the version of the license tht applies, we're in a
bit of a muddle.

-Peter

On 9/9/07, Angela Byron <drupal-devel@...> wrote:

>
> On 9-Sep-07, at 10:42 AM, Karoly Negyesi wrote:
>
> >> IMO, you already have because of the "any future version" clause.
> >
> > Which can be found exactly where..? Drupal tarball is distributed
> > with the GPL v2, the contributions FAQ link to the GPL v2 and
> > however hard I seek I can't find a single mention of that.
>
> It's written in LICENSE.txt:
>
> "    This program is free software; you can redistribute it and/or
> modify
>      it under the terms of the GNU General Public License as
> published by
>      the Free Software Foundation; either version 2 of the License, or
>      (at your option) ***any later version***.
> "
>

[mark burdett-3]

Here's the FAQ, by the Software Freedom Law Center, on why you can
distribute CiviCRM (AGPL licensed, incompatible with GPL v2) as part
of a GPL-licensed piece of software (e.g. drupal+civicrm distribution
like civicspace was):  http://civicrm.org/node/166

--mark

On 9/9/07, Darren Oh <darrenoh@...> wrote:

> Further simplification of the claims being made now appears possible.
> There are two:
>
> 1. You cannot use a GPL-incompatible license for an app if it calls
> functions in Drupal or in a Drupal contributed module. This claim is
> not disputed.
>
> 2. You cannot use the GPL for code that calls functions in a third-
> party app if you cannot distribute your code and the third-party app
> together as a single work using the GPL. This claim is disputed.
>
> On Sep 7, 2007, at 6:28 AM, Thomas Barregren wrote:
>
> > Since you already have accepted to distribute your module under GPL
> > and nothing by GPL, the license of the other program must allow its
> > derivative works to be licensed under GPL. A license which allows
> > that is said to be compatible with GPL. Examples of compatible
> > licenses include the revised BSD and the MIT licenses. If the other
> > program's license is not compatible with GPL, then you cannot
> > distribute your module. It is as simple as that.
>

[Thomas Barregren]

Peter Wolanin skrev:
> Angela,
>
> this text describes the copyright statement that *should* be in all
> the source files.  As far as I can tell, since none of the files
> actually specify the version of the license tht applies, we're in a
> bit of a muddle.
>  

Very interesting point. That would be another interesting question for
Drupal Association to bring up with a lawyer.

Regards,
Thomas

[Peter Wolanin]

Ok - enough talk - in Drupal things should be solved with patches ;-)

Here's a patch to at least add the standard copyright statement from
GPL 2.0 to the Drupal HEAD index.php file.  right now since none of
the source files have such a notice to even make it clear that they
are GPl licensed:

http://drupal.org/node/174226



On 9/9/07, Peter Wolanin <pwolanin@...> wrote:

> Angela,
>
> this text describes the copyright statement that *should* be in all
> the source files.  As far as I can tell, since none of the files
> actually specify the version of the license tht applies, we're in a
> bit of a muddle.
>
> -Peter
>
> On 9/9/07, Angela Byron <drupal-devel@...> wrote:
> >
> > On 9-Sep-07, at 10:42 AM, Karoly Negyesi wrote:
> >
> > >> IMO, you already have because of the "any future version" clause.
> > >
> > > Which can be found exactly where..? Drupal tarball is distributed
> > > with the GPL v2, the contributions FAQ link to the GPL v2 and
> > > however hard I seek I can't find a single mention of that.
> >
> > It's written in LICENSE.txt:
> >
> > "    This program is free software; you can redistribute it and/or
> > modify
> >      it under the terms of the GNU General Public License as
> > published by
> >      the Free Software Foundation; either version 2 of the License, or
> >      (at your option) ***any later version***.
> > "
> >
>

[Gerhard Killesreiter]

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

mark burdett schrieb:
> Here's the FAQ, by the Software Freedom Law Center, on why you can
> distribute CiviCRM (AGPL licensed, incompatible with GPL v2) as part
> of a GPL-licensed piece of software (e.g. drupal+civicrm distribution
> like civicspace was):  http://civicrm.org/node/166

Quote:

> Can I distribute CiviCRM as part of a GPL-licensed piece of software? How does that work?

> Yes, so long as CiviCRM is a separate and independent program from the GPL-licensed software. You cannot combine code licensed under both licenses into a single program and then redistribute that combination because the AGPL and the current version of the GPL are incompatible.


The problem is that it is disputed that CiviCRM would be an independent
programm when using civicrm.module to hook into Drupal.

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

iD8DBQFG5DcEfg6TFvELooQRAv7TAJ92fF3WCA/5YqF25957ittIkqbkngCgpN5D
xU/RBTJCrnv2449B22NZvRE=
=VsB+
-----END PGP SIGNATURE-----

[mark burdett-3]

I don't know what it means if SFLC conflicts with FSF on this issue :)
  But just wanted to point out SFLC's legal theory that the GPL
civicrm module could call the CiviCRM API, even though the civicrm API
files themselves are AGPL..

--mark

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> mark burdett schrieb:
> > Here's the FAQ, by the Software Freedom Law Center, on why you can
> > distribute CiviCRM (AGPL licensed, incompatible with GPL v2) as part
> > of a GPL-licensed piece of software (e.g. drupal+civicrm distribution
> > like civicspace was):  http://civicrm.org/node/166
>
> Quote:
>
> > Can I distribute CiviCRM as part of a GPL-licensed piece of software? How does that work?
>
> > Yes, so long as CiviCRM is a separate and independent program from the GPL-licensed software. You cannot combine code licensed under both licenses into a single program and then redistribute that combination because the AGPL and the current version of the GPL are incompatible.
>
>
> The problem is that it is disputed that CiviCRM would be an independent
> programm when using civicrm.module to hook into Drupal.
>
> Cheers,
>         Gerhard
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG5DcEfg6TFvELooQRAv7TAJ92fF3WCA/5YqF25957ittIkqbkngCgpN5D
> xU/RBTJCrnv2449B22NZvRE=
> =VsB+
> -----END PGP SIGNATURE-----
>

[Thomas Barregren]

ttw+drupal@... skrev:

> On 07.09-15:34, Earnie Boyd wrote:
> [ ... ]
>  
>> The copyright is owned by the producer of the code and the license
>> allows the copyright holder to give you the right to use it. [ ... ]
>>    
>
> giving someone freedoms to use your code does not allow you to
> dictate basic freedoms to them .. i.e. you cannot restrict the basic
> rights given to them in copyright law just because you are giving
> them more access than copyright law dictates.
>  

It seems to me that you don't know what you are talking about. Or worse,
that you are trying to spread FUD.

In any case, let me quote from the 13 pages short publication "The Open
Source Legal Landscape" by the Australian lawyer  Brendan Scott:

    1.3 Copyright operates by prohibiting numerous categories of action
    in respect of a copyright work. [...] In the absence of a permission
    from the copyright holder, there is an absolute prohibition on
    exercising any of the rights comprised in copyright in respect of
    that work.


    2.3 [...] Open source licences effectively exempt the permitted
    activities from copyright infringement, subject to compliance with
    certain conditions (which are different depending upon the licence).
    A failure to comply with the conditions in the licence will mean
    that the activities are no longer exempted from infringement of
    copyright. If the activity in question results in an infringement of
    copyright, then the copyright owner will have an action against the
    person engaging in the activity.

You can download the full paper here:

    http://opensourcelaw.biz/publications/papers/BScott_OSS_Legal_Landscape_060328.pdf


Thomas

[Thomas Barregren]

ttw+drupal@... skrev:

> On 07.09-15:34, Earnie Boyd wrote:
> [ ... ]
>  
>>>> Assume you write a module for Drupal. Any meaningful module to Drupal
>>>> implements at least one hook. That alone makes the module a derived work
>>>> of Drupal.
>>>>        
>>> this is wrong.  it is an over zealous attempt to extend the legal
>>> coverage of copyright and licensing laws.  you may interface to
>>> software as you like, what you cannot do is copy and modify and
>>> distribute that software as your own.
>>>
>>>      
>> I don't see how Thomas is wrong.  What he says is the heart of the GPL.
>>    
>
> because the GPL is a copyright license and this statement is in
> direct conflict with copyright law and, as such, is a zealous
> attempt to extend the coverage of copyright.  for example, if your
> write a book and i quote your work (for any wide range of reasons)
> you cannot sue me under copyright.

Quoting a book falls under the notion of Fair Use. Creating a derivative
work doesn't.

Read more at http://en.wikipedia.org/wiki/Fair_use.

Thomas

[Thomas Barregren]

David Metzler skrev:
>> f your code link to another code and call functions and share data
>> structures with that other code, your code becomes a derived work of
>> the other code.
>
> You keep insisting this, but I don't agree its that cut and dry.

I believe that legal issues never are cut and dry. GPL is no exception.
It is always possible to construct circumventions to the intent of GPL.
Tivoization is a good example.

> Current literature on the subject suggests otherwise when calling code
> that is "designed as a library".  Regardless as to whether it is
> statically linked or otherwise.  Creating a derivative work is not a
> technical definition, it's a legal one.  Most of the reading I've done
> outside of the GPL FAQ agrees with this.

I agree that code that links to a library, which were *designed* and
*intended* to be used as a library, not necessarily makes the code a
derived work of the library, but just a collective work. But as I
understand it, that is not the subject matter. We are talking about
modules that bridge Drupal with third-party software. Let me elaborate
on my arguments:

Drupal is not *designed* nor *intended* as a library. It is an
application. A module, which links to Drupal, calls functions in Drupal
and shares data structures with Drupal, can therefore not be said to
merely using Drupal. In fact, the very purpose of the module is to
modify how Drupal works. Therefore, Drupal and the module, as a whole,
is a derived work of Drupal. And as a such, it must be under GPL.

Now, suppose we develop a module that bridges Drupal with another
application. The very need of a bridging module implies that the
application is not *designed* nor *intended* as a library. As a bridge,
the module must obviously link to the application, call functions in the
application and share data structures with the application. In fact, the
very purpose of the module is to be a proxy for the application.
Therefore, the application and the module, as a whole, is a derived work
of the application. And as a such, it must be under a license compatible
with the license for the application.

Thus, the module can only be licensed if and only if the license of the
application is compatible with GPL. Q.E.D. :-)


> Drupal's strength IMHO relies on its community, and defining the risks
> we're willing to take in terms of technical semantics feels like a
> step in the wrong direction.  I agree, that the SMF bridge case takes
> it too far.  Distributing non-gpl code using the drupal infrastructure
> would be a step backward for us also.  I think we should continue to
> feel free to distribute code that says it's GPL, no matter what, but
> not try and second guess lawyers on what is considered a derived work
> or not.

I think your position is naive. Every time someone is downloading a
contrib module, Drupal.org is distributing that module. By copyright
laws, that is absolutely prohibited without permission. The GPL gives
that permission. Now, suppose the module violates the GPL. A failure to
comply with the conditions in the GPL will mean that downloading is no
longer exempted from infringement of  copyright. Ouch! Therefore it
should be important for Drupal.org to make whatever is reasonable to
control that the modules they distribute really do comply with GPL.

Lack of such control can be utilized by unscrupulous. For an example,
suppose a closed source company in the CRM business wants to put and end
to its worst competitor: Drupal. They engage a decoy who check in a
module bridging Drupal with their own closed source licensed CRM. Next,
they sue Dries, in his capacity of owner of the drupal.org domain, for
copyright infringement... Okay, it is not likely to happen (I hope), but
it is an illustration why copyright and licensing should not be taken
easily.


Best regards,
Thomas

[Darren Oh-2]

I wrote this quickly and failed to sum fully sum up the two claims  
being made. Clarification:

1. The first claim concerns third-party code: you cannot use a GPL-
incompatible license for an app designed to be used with Drupal or a  
Drupal module.

2. The second claim concerns the code of Drupal and contributed  
modules: you cannot use the GPL for code designed to be used with a  
third-party app unless a) you can distribute your code and the third-
party app together under the GPL as a combined work or b) you add an  
exception clause giving up the first claim.

On Sep 9, 2007, at 11:43 PM, Darren Oh wrote:

> Further simplification of the claims being made now appears  
> possible. There are two:
>
> 1. You cannot use a GPL-incompatible license for an app if it calls  
> functions in Drupal or in a Drupal contributed module. This claim  
> is not disputed.
>
> 2. You cannot use the GPL for code that calls functions in a third-
> party app if you cannot distribute your code and the third-party  
> app together as a single work using the GPL. This claim is disputed.

[Glenn Wybo]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Ok, thanks,

well, was considering if  it would be necessary to use BLOB's to  upload the images to a database between our server and the compunter of the client. The thing is that my boss wants to upload many images (corresponding with the company of the customer) to another database when the customer logs in on the website. This database will only be used for storing the images and the corresponding data. The only reason for this is to improve speed. When the customer selects a couple of images,  it may only be a matter of milliseconds to select the images (and the data that corresponds with it) in the database and upload it to the screen of the user.

thanks for the advice,

Glenn

> Date: Fri, 7 Sep 2007 10:20:27 -0500
> From: mark.m.fredrickson@...
> To: development@...; nevets@...
> Subject: Re: [development] table vs tables
>
> > The "obvious" way to break up the table would be to use 1000 a smaller
> > tables, but too many tables can also cause a problem.
>
> You might also look at table partitioning:
>
> http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html
> http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
>
> Basically, it splits one tall table into many, smaller chunks that
> look and behave like a single table. So you don't have to change your
> queries but you could possibly get some performance benefits by not
> having to scan or load as much of a table into memory.
>
> I'm not a DBA, so I don't know how this really ends up working in
> practice, but that's the theory at least.
>
> -Mark

---

Bekijk de beste Live Earth concerten op MSN 07/07/07 Live Earth

[Gerhard Killesreiter]

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

mark burdett schrieb:
> I don't know what it means if SFLC conflicts with FSF on this issue :)
>   But just wanted to point out SFLC's legal theory that the GPL
> civicrm module could call the CiviCRM API, even though the civicrm API
> files themselves are AGPL..

Yeah, I know this theory and I used to think it is correct. Based on
this theory I recommended to Donald Lobo that the civicrm module itself
be dually licensed, to which he agreed.

I am personally not too happy with the "new" situation. However, we need
to resolve it.

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

iD8DBQFG5P3Hfg6TFvELooQRAmZSAJ9mOCLud9DxaRxpipNYYs8LVN2gjQCfd2UH
yMcSlVv4r0kTwEnldrAgYdU=
=7PH1
-----END PGP SIGNATURE-----

On Sunday, 9. September 2007, Peter Wolanin wrote:
> Ok - enough talk - in Drupal things should be solved with patches ;-)
>
> Here's a patch to at least add the standard copyright statement from
> GPL 2.0 to the Drupal HEAD index.php file.  right now since none of
> the source files have such a notice to even make it clear that they
> are GPl licensed:
>
> http://drupal.org/node/174226

Yeah! Way to go!

[Jakob Persson]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Glenn,

In the future, please create a new email instead of replying to a threaded one. Your question ended up in the middle of a long discussion about Drupal and GPL. Emails that are threaded are tagged so your email client can tell which emails relate. When you replied, your email got tagged making it appear being part of the GPL discussion. Creating a new (untagged) email, your email will be considered to be a new thread and will end up at the "root" level.

Thank you,

Jakob Persson


Glenn Wybo wrote:

Ok, thanks,

well, was considering if  it would be necessary to use BLOB's to  upload the images to a database between our server and the compunter of the client. The thing is that my boss wants to upload many images (corresponding with the company of the customer) to another database when the customer logs in on the website. This database will only be used for storing the images and the corresponding data. The only reason for this is to improve speed. When the customer selects a couple of images,  it may only be a matter of milliseconds to select the images (and the data that corresponds with it) in the database and upload it to the screen of the user.

thanks for the advice,

Glenn




> Date: Fri, 7 Sep 2007 10:20:27 -0500
> From: mark.m.fredrickson@...
> To: development@...; nevets@...
> Subject: Re: [development] table vs tables
>
> > The "obvious" way to break up the table would be to use 1000 a smaller
> > tables, but too many tables can also cause a problem.
>
> You might also look at table partitioning:
>
> http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html
> http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
>
> Basically, it splits one tall table into many, smaller chunks that
> look and behave like a single table. So you don't have to change your
> queries but you could possibly get some performance benefits by not
> having to scan or load as much of a table into memory.
>
> I'm not a DBA, so I don't know how this really ends up working in
> practice, but that's the theory at least.
>
> -Mark

---

Bekijk de beste Live Earth concerten op MSN 07/07/07 Live Earth

[jp.stacey]

Hi,

There's a lot of noise here that comes of us all not being legal experts,
but as Dries has sanctioned discussion then I'll throw in my two pence of
opinionated blaring. I hope nobody minds.

My own rather basic reading of the law is that, as long as GPL and non-GPLed
software types are not bundled together, then you're "more or less OK". You
can infer my legal credentials from the fact that I use such obscure
terminology. But this would mean that you can link your non-GPL application
dynamically to GPL libraries, but you can't compile them in statically; you
can develop the TinyMCE bridge, but the consumer of the software has to
fetch TinyMCE separately.

Angela Byron wrote:
> On a personal note, I fully support the viral nature of GPL, and see it
> as a critical feature, not a bug.

Does this count as an email disclaimer? ;) If so, for the record I agree
wholeheartedly with the above statement: the viral nature of GPL protects
the freedoms expressed within it, at the expense of other freedoms that GPL
instigators have deemed less fundamental.

However, the virality stops at certain boundaries, doesn't it? If not, then:

  * How does Cygwin survive, translating the calls of potentially GPL
programs to the language of the wholeheartedly un-GPL OS it sits in? By
extension, how does any GPL program conscience working on Windows (by which
I don't mean morally....)? How can something like Automatix work, sprinkling
software of all sorts of licences like fairy dust through your Ubuntu box?

  * How can you build GPL webservice clients, and would their use in
requesting data or processing from a non-GPLed webservice count as licence
infringement? What would a GPLed webservice even look like? Richard
Stallman, I think, is on record as saying that the proprietary nature of
services such as Amazon's doesn't bother him, but it bothers other people.

  * How does networking software not transmit the GPL in its very packets,
when it lets proprietary and GPL software communicate and potentially share
processing?

Before you wonder, I'm not saying that the above cases justify us playing
fast and loose with the GPL, if that's indeed what we're doing. But I think
we need to make sure we make a right and consistent decision, and maybe we
can learn from more than just kissing cousins like Joomla.

Cheers,
J-P
--
J-P Stacey
[phone]
http://torchbox.com

On Monday, 10. September 2007, J-P Stacey wrote:

> However, the virality stops at certain boundaries, doesn't it? If not,
> then:
>
>   * How does Cygwin survive, translating the calls of potentially GPL
> programs to the language of the wholeheartedly un-GPL OS it sits in? By
> extension, how does any GPL program conscience working on Windows (by which
> I don't mean morally....)? How can something like Automatix work,
> sprinkling software of all sorts of licences like fairy dust through your
> Ubuntu box?
>
>   * How can you build GPL webservice clients, and would their use in
> requesting data or processing from a non-GPLed webservice count as licence
> infringement? What would a GPLed webservice even look like? Richard
> Stallman, I think, is on record as saying that the proprietary nature of
> services such as Amazon's doesn't bother him, but it bothers other people.
>
>   * How does networking software not transmit the GPL in its very packets,
> when it lets proprietary and GPL software communicate and potentially share
> processing?

I don't want to be rude, but all of these questions have already been answered
in this thread. Before another well-explained, but extensive Thomas Barregren
mail is coming up again, I suggest you look it up by yourself.

Yeah, I know it's daunting to read and understand all of this thread, it's too
large already.

[Jakob Persson]

See I shot myself in the foot here. Quite embarrassing frankly...

"Reply to Sender Only" is obviously not working as it should in my version of Thunderbird.

Anyhow, do not make my mistake please.

Thank you for your consideration.

Sincerely,

Jakob Persson

Jakob Persson wrote:

Hi Glenn,

In the future, please create a new email instead of replying to a threaded one. Your question ended up in the middle of a long discussion about Drupal and GPL. Emails that are threaded are tagged so your email client can tell which emails relate. When you replied, your email got tagged making it appear being part of the GPL discussion. Creating a new (untagged) email, your email will be considered to be a new thread and will end up at the "root" level.

Thank you,

Jakob Persson

[Thomas Barregren]

mark burdett skrev:
> Here's the FAQ, by the Software Freedom Law Center, on why you can
> distribute CiviCRM (AGPL licensed, incompatible with GPL v2) as part
> of a GPL-licensed piece of software (e.g. drupal+civicrm distribution
> like civicspace was):  http://civicrm.org/node/166

The CiviCRM's FAQ about AGPL loudly and clearly states:

    You cannot combine code licensed under both licenses [AGPL and GPL]
    into a single program and then redistribute that combination because
    the AGPL and the current version of the GPL are incompatible.

Thus, you cannot distribute CiviCRM as *part of* a software licensed
under GPL. However, you can distribute CiviCRM as "a separate and
independent program from the GPL-licensed software".

It is important to make a distinction between "derived work" and
"combined work".

Derivative works are subject to the GPL’s reciprocity provision (a.k.a.
copyleft) while combined works are not. The matter is thoroughly
discussed in Lawrence Rosen's book "Open Source Licensing: Software
Freedom and Intellectual Property Law" available online from

    http://www.rosenlaw.com/oslbook.htm.

Rosen says in the book that he belief that GPL "will ultimately be read
by the courts to mean that derivative works are subject to the GPL’s
reciprocity provision, but collective works are not."

Best regards,
Thomas

[Thomas Barregren]

Jakob Petsovits skrev:

> On Monday, 10. September 2007, J-P Stacey wrote:
>  
>> However, the virality stops at certain boundaries, doesn't it? If not,
>> then:
>>
>>   * How does Cygwin survive, translating the calls of potentially GPL
>> programs to the language of the wholeheartedly un-GPL OS it sits in? By
>> extension, how does any GPL program conscience working on Windows (by which
>> I don't mean morally....)? How can something like Automatix work,
>> sprinkling software of all sorts of licences like fairy dust through your
>> Ubuntu box?
>>
>>   * How can you build GPL webservice clients, and would their use in
>> requesting data or processing from a non-GPLed webservice count as licence
>> infringement? What would a GPLed webservice even look like? Richard
>> Stallman, I think, is on record as saying that the proprietary nature of
>> services such as Amazon's doesn't bother him, but it bothers other people.
>>
>>   * How does networking software not transmit the GPL in its very packets,
>> when it lets proprietary and GPL software communicate and potentially share
>> processing?
>>    
>
> I don't want to be rude, but all of these questions have already been answered
> in this thread. Before another well-explained, but extensive Thomas Barregren
> mail is coming up again, I suggest you look it up by yourself.
>  

Lol. I should perhaps "rest my case". :-)

> Yeah, I know it's daunting to read and understand all of this thread, it's too
> large already.

The easiest way to see the whole thread, which currently consists of 198
messages, is by Nabble:

    * http://www.nabble.com/Modules-that-integrate-non-GPL-PHP-apps-violate-the-GPL.-tf4352313.html

If you prefer the "official" mailing archive, you have to jump around a
little:

    * http://lists.drupal.org/archives/development/2007-08/threads.html#00568
    * http://lists.drupal.org/archives/development/2007-09/threads.html#00000
    * http://lists.drupal.org/archives/development/2007-09/threads.html#00025
    * http://lists.drupal.org/archives/development/2007-09/threads.html#00082
    * http://lists.drupal.org/archives/development/2007-09/threads.html#00200

Best regards,
Thomas

[Darren Oh-2]

In that case, Drupal modules that do not include third-party code are  
legal, since they merely allow Drupal to be combined with "separate  
and independent" programs. No work derived from the third-party code  
is being distributed. I know it's repetitive, but this discussion has  
been answering the wrong question.

On Sep 10, 2007, at 5:40 PM, Thomas Barregren wrote:

> The CiviCRM's FAQ about AGPL loudly and clearly states:
>
>    You cannot combine code licensed under both licenses [AGPL and GPL]
>    into a single program and then redistribute that combination  
> because
>    the AGPL and the current version of the GPL are incompatible.
>
> Thus, you cannot distribute CiviCRM as *part of* a software  
> licensed under GPL. However, you can distribute CiviCRM as "a  
> separate and independent program from the GPL-licensed software".
>
> It is important to make a distinction between "derived work" and  
> "combined work".
>
> Derivative works are subject to the GPL’s reciprocity provision  
> (a.k.a. copyleft) while combined works are not. The matter is  
> thoroughly discussed in Lawrence Rosen's book "Open Source  
> Licensing: Software Freedom and Intellectual Property Law"  
> available online from
>
>    http://www.rosenlaw.com/oslbook.htm.
>
> Rosen says in the book that he belief that GPL "will ultimately be  
> read by the courts to mean that derivative works are subject to the  
> GPL’s reciprocity provision, but collective works are not."
>
> Best regards,
> Thomas