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

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 | Next >

Re: Modules that integrate non-GPL PHP apps violatethe GPL.

by larry@garfieldtech.com :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Fri, 7 Sep 2007 09:14:52 -0600, Laura Scott <laura@...> wrote:

> On Sep 6, 2007, at 4:28 PM, Thomas Barregren 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.
>
> I wonder whether that in fact is true. By this logic, if you write an
> application that interfaces with Word, then Microsoft owns it as a
> derivative of their product. Is that how copyright works? Every time
> two different applications touch, we have litigation as to who has
> the most cooties?

No, only if Word's license explicitly said that they own any Macros you write.  AFAIK it doesn't (although I've not actually purchased a copy of Word since last century).  

If Word were GPLed, they still wouldn't own your macros.  There is no transfer of ownership in the GPL.  There is only a requirement of GPL re-licensing for derivative works, e.g., Word plus your Macros wrapped up together.

> If someone pulls on a door handle, does he become a derivative of the
> door? Some things are designed to be utilized by other systems. APIs
> exist in large part to allow different systems to interface with each
> other. To claim that not only must a bridge module (to use the
> example we've been tossing about) be GPL but anything it touches must
> be GPL as well seems to be a rather far-reaching legal claim ... or
> tragically self-isolating interpretation for policy.
>
> Can GPL exist only in isolation from all other systems? Does mere
> communication or interaction imply derivation? That's what the RIAA
> and MPAA claim in their dragnet lawsuits, pre-litigation settlement
> demands and things like the Sony Rootkit. What next? A GPL rootkit?
>
> I wonder how Lawrence Lessig would interpret GPL.
>
> Laura

The amount of FUD in this thread is starting to amaze me.  (Not you specifically, Laura; in general.)  I think some people here are reading from the Microsoft anti-GPL playbook with the "transfer of ownership" nonsense.  

Folks, the GPL is not as evil ("viral") as some here are making it out to be.  It says, simply, "you can do anything you want with this code, but *if* you redistribute it, *even if it's part of a derivative work*, then it, and as a result the derivative work, must be distributed under the GPL."  That is all.  There is no transfer of ownership, no "viral infection", no "loss of property" (since copyright is not property to start with, but we won't get into that.)

The only question at hand is exactly where the line for "derivative work" is, in particular for modules that interface with 3rd party systems.  The only relevant questions here are:

1) If a Drupal module exists only to interface between Drupal and a non-GPL system using in-process PHP function calls, does that violate the GPL?  (FSF, according to Jeff, believes it does.  I say to ask a lawyer not in the FSF's employ in order to get a more unbiased answer.)

2) If a Drupal module exists only to interface between Drupal and a non-GPL system using non-in-process APIs (SOAP, RSS, REST, reading a CSV, exec/fork, etc.), does that violate the GPL?  (FSF, according to Jeff, says "not in letter, but in spirit".  Given the number of RSS feeds coming off of non-Free systems that we all read on a regular basis using Aggregator, I don't think many people agree with the "spiritual violation".  For the letter, again, we should ask a lawyer.)

Bottom line: Unless you are a lawyer or have recently spoken to one on this subject, you have nothing constructive to contribute to this thread any more.  Yes, I include myself in that statement as I am not a lawyer.  Can we move the GPL FUD to some other forum and get back to something useful, like getting Drupal 6 finished?

--Larry Garfield


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

by mark burdett-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Well I was just regurgitating
http://www.gnu.org/philosophy/license-list.html which describes PHP
License as incompatible with GPL.  I do have my own "readings" of the
various licenses, IP law, etc. but won't waste the list's time ;)

--mark

On 9/7/07, Earnie Boyd <earnie@...> wrote:

> Quoting mark burdett <mfburdett@...>:
>
> > Well it's not even as nice as the rms quote, since we also have
> > barriers to integrate with non-proprietary FLOSS, from AGPL to GPL 3.
> > And then there's all the PEAR libraries which use PHP license.
> >
>
> My read of the PHP license leads me to believe it is compatible with
> GPL so the PEAR and PECL libraries shouldn't be a problem.
>
> Earnie -- http://for-my-kids.com/
> -- http://give-me-an-offer.com/
>
>

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

by Earnie :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting mark burdett <mfburdett@...>:

> Well I was just regurgitating
> http://www.gnu.org/philosophy/license-list.html which describes PHP
> License as incompatible with GPL.  I do have my own "readings" of the
> various licenses, IP law, etc. but won't waste the list's time ;)
>

I suppose because of this
<blockquote>
  6. Redistributions of any form whatsoever must retain the following
     acknowledgment:
     "This product includes PHP software, freely available from
     <http://www.php.net/software/>".
</blockquote>

Which is in direct conflict with this
<blockquote>
  3. The name "PHP" must not be used to endorse or promote products
     derived from this software without prior written permission. For
     written permission, please contact group@....
</blockquote>
because you cannot do 6 without it being considered an endorsement and
you would need permission from PHP.

Earnie

P.S.: How is it a waste of developers time to understand the legalities
of what they agree to license their copyright with?

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

by Earnie :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting ttw+drupal@...:

> On 06.09-07:28, Earnie Boyd wrote:
> [ ... ]
>> So that's the reason why I need to go to MySql to get the PHP loadable
>> module that PHP no longer distributes!  PHP wants to be GPL free.
>
> i do not think it is precicesly a 'legal' reason but more the divergance
> in doctrines.  RMS' statement about not accepting people into a
> community because they choose not to join is the fundamental issue.
> freedoms cannot be given or taken away or chosen, they are rights of
> a free individual, all we can do as a society is choose to recognise
> them or not.  this is an issue that we should talk about forever
> because basically it is far more important than software.
>

RMS strives to have everyone in one community and has created a license
that removes your rights to join other communities.

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


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

by Dries Buytaert-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 30 Aug 2007, at 09:08, 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.

Because some people e-mailed me in private about this; it's going to  
take me a couple more days to respond to this thread.  I'm also going  
to consult some other Open Source projects about this.  In the mean  
time, keep on discussing as all input is valuable before we refine  
our stance. :)

--
Dries Buytaert  ::  http://www.buytaert.net/


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

by Earnie :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting ttw+drupal@...:

> On 07.09-00:28, Thomas Barregren 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.

--8<--
> i would re-state what an earlier poster said which is, it would be
> better to put together a list of copyright holders and correct
> current licensing discrepancies.  then tackle how you wish to
> address this issue internally.  only then should you start
> propounding this sort of dictum.
>

While a preamble is indeed a good idea the lack thereof doesn't harm
the copyright or the license with which the package is distributed.  
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.  It can
also be contrived that since I freely gave the code that is covered by
my copyright to Drupal that I also transferred the copyright to Drupal.

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


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

by Angela Byron-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 7-Sep-07, at 3:23 PM, Dries Buytaert wrote:

>
> On 30 Aug 2007, at 09:08, 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.
>
> Because some people e-mailed me in private about this; it's going  
> to take me a couple more days to respond to this thread.  I'm also  
> going to consult some other Open Source projects about this.  In  
> the mean time, keep on discussing as all input is valuable before  
> we refine our stance. :)

Ok, I was keeping quiet in this thread, but since you seem to want  
input...

IMO, the only thing we can do is exactly what Joomla! did:

- Do not fork the GPL by creating our own interpretation of it  
(adding exceptions, etc.). Adding exceptions anyway is a physically  
impossibility; you'll never find all of the copyright holders of  
Drupal to sign off on it, and many of us would oppose such an action.

- Remove any code from our repositories that combine with non-GPLed  
code. This would be things like SMF, vBulletin, CiviCRM integration  
bridges. If those companies want to put themselves in potential legal  
jeopardy by providing bridges for our CMS, then they can host it on  
their own infrastructure, not ours, or they can dual-license their  
software so that it's GPL-compatible.

I think a lot of the discussion in this thread is just out-right  
denial. I'm quite sure that the folks at Open Source Matters looked  
into this issue extensively before Joomla! made their decision to  
quit distributing their SMF bridge, especially since the vast  
majority of their users are non-programmers who would never in a  
million years be able to create one by themselves, and since Joomla!  
does not have a core forum system of their own.

On a personal note, I fully support the viral nature of GPL, and see  
it as a critical feature, not a bug. The GPL is part of the primary  
reasons I spend my time working on applications like Drupal; it  
preserves the freedoms I was given for all future users of my code.

-Angie


Re: Modules that integrate non-GPL PHP appsviolate the GPL.

by larry@garfieldtech.com :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Fri, 07 Sep 2007 15:34:39 -0400, Earnie Boyd <earnie@...> wrote:
> While a preamble is indeed a good idea the lack thereof doesn't harm
> the copyright or the license with which the package is distributed.
> 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.  It can
> also be contrived that since I freely gave the code that is covered by
> my copyright to Drupal that I also transferred the copyright to Drupal.

Not true, unless you explicitly signed a document stating that you transfered copyright ownership to Dries Buytaert.  Unless I missed it, there is no such automatic transfer involved in committing to CVS.  (Some projects do have that, but not Drupal.)  

The "GPL means someone else owns my code now" line is a lie.  Period.  They can *use* your code, and can even redistribute it however they want as long as they do so under the GPL, but ownership remains with you until you legally turn it over to someone else.

(This email, by the way, is copyright 2007 Larry Garfield.  Forwarding it, including quoting it in a reply, counts as redistribution and is illegal under modern US copyright law without license.  License to redistribute this email and its contents are hereby granted to all readers under the GNU GPL.  That does not in any way shape or form diminish the copyright claim of Larry Garfield upon the work herein.  Welcome to modern copyright law.)

--Larry Garfield


Re: Modules that integrate non-GPL PHP appsviolate the GPL.

by Steven Peck-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 9/7/07, Larry Garfield <larry@...> wrote:

> (This email, by the way, is copyright 2007 Larry Garfield.  Forwarding it, including quoting it in a reply, counts as redistribution and is illegal under modern US copyright law without license.  License to redistribute this email and its contents are hereby granted to all readers under the GNU GPL.  That does not in any way shape or form diminish the copyright claim of Larry Garfield upon the work herein.  Welcome to modern copyright law.)
>
> --Larry Garfield

Email disclaimers, their validity and enforcement of, is a separate
subject with an entirely different set of criteria and morass that is
outside the scope of this discussion with it's own set of case law and
associated technologies.

Let's not complicate this already diverse thread with yet another
indirect example that merely muddies the water further.

Steven Peck
Enterprise Email Admin

Re: Modules that integrate non-GPL PHP appsviolate the GPL.

by Laura Scott :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sep 7, 2007, at 2:32 PM, Larry Garfield wrote:

> (This email, by the way, is copyright 2007 Larry Garfield.  
> Forwarding it, including quoting it in a reply, counts as  
> redistribution and is illegal under modern US copyright law without  
> license.  License to redistribute this email and its contents are  
> hereby granted to all readers under the GNU GPL.  That does not in  
> any way shape or form diminish the copyright claim of Larry  
> Garfield upon the work herein.  Welcome to modern copyright law.)

But what about all the servers that are passing this email along  
through the net? What about all the people using Yahoo and GMail --  
is reading a GPL-licensed email on a proprietary system a violation?  
Shall GPL emails be distributed and read only on GPL systems?

Okay, that's being silly. However, I do not intend to muddy the  
waters. I'm wondering if we can agree on the questions at hand....

Where the line is drawn that makes something a derivative of Drupal  
(or whatever GPL-licensed system) seems to be the issue that will be  
at the crux of any legal challenge down the line, and sorry, I don't  
believe there is any cut-and-dried interpretation, except in the  
minds of advocates, and lawyers with vested interests. Sorting out  
these kinds of issues is what courts are for.

So isn't the issue, then, what D.o should do about modules that claim  
to be GPL but possibly may not legitimately be so? If the module  
creator says the module is licensed as GPL, is that not enough? Or is  
it D.o's job to research all possible ways the module might touch a  
non-GPL system and, thereby, enforce what seems to be one not-quite-
universal interpretation of GPL?

Laura

Re: Modules that integrate non-GPL PHP appsviolate the GPL.

by Earnie :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting Laura Scott <laura@...>:

>
> So isn't the issue, then, what D.o should do about modules that claim
>  to be GPL but possibly may not legitimately be so? If the module  
> creator says the module is licensed as GPL, is that not enough? Or is
>  it D.o's job to research all possible ways the module might touch a  
> non-GPL system and, thereby, enforce what seems to be one not-quite-
> universal interpretation of GPL?
>

At the end of the day it will all come down to who has the biggest
wallet that will win.  There will only be an issue if some copyright
holder gets upset and decides to sue.  The question we need to ask is
are we protected enough by the license we use to continue using it and
do the modules that people contribute cause an issue that might harm
Drupal as a community.

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


Re: Modules that integrate non-GPL PHP appsviolate the GPL.

by Earnie :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting Larry Garfield <larry@...>:

>
> On Fri, 07 Sep 2007 15:34:39 -0400, Earnie Boyd
> <earnie@...> wrote:
>> While a preamble is indeed a good idea the lack thereof doesn't harm
>> the copyright or the license with which the package is distributed.
>> 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.  It can
>> also be contrived that since I freely gave the code that is covered by
>> my copyright to Drupal that I also transferred the copyright to Drupal.
>
> Not true, unless you explicitly signed a document stating that you
> transfered copyright ownership to Dries Buytaert.  Unless I missed
> it, there is no such automatic transfer involved in committing to
> CVS.  (Some projects do have that, but not Drupal.)
>
> The "GPL means someone else owns my code now" line is a lie.  Period.
>  They can *use* your code, and can even redistribute it however they
> want as long as they do so under the GPL, but ownership remains with
> you until you legally turn it over to someone else.
>

I said that it can be contrived to mean; meaning that some court
*could* (not would) give Drupal that right.  Copyright law changes with
each courts interpretation.  FSF forces the issue and makes you and
everyone else that owns you sign a document for you to contribute code
that is distributed by the FSF just to make it clear that FSF owns the
copyright.

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


Re: Modules that integrate non-GPL PHP appsviolate the GPL.

by Peter Wolanin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

So - a question regarding only the Drupal core - if the license was to
be changed, would those who'd need to agree only be the core
committers?  Technically, only they have added any new code to Drupal
core.

For example the only change I might suggest is to change the license
to GPL 2.0 or later, or to add a FOSS exception.  I think one or both
of these needs to be considered otherwise it seems that we are in
trouble regarding Drupal integration with CiviCRM and other FOSS
packages that are GPL 3.0 or GPL 3.0 compatible.

-Peter

Re: Modules that integrate non-GPL PHP appsviolate the GPL.

by Gerhard Killesreiter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Peter Wolanin schrieb:
> So - a question regarding only the Drupal core - if the license was to
> be changed, would those who'd need to agree only be the core
> committers?  Technically, only they have added any new code to Drupal
> core.

We may have added it, but that doesn't give us copyright on the code or
make us the author.

> For example the only change I might suggest is to change the license
> to GPL 2.0 or later, or to add a FOSS exception.  I think one or both
> of these needs to be considered otherwise it seems that we are in
> trouble regarding Drupal integration with CiviCRM and other FOSS
> packages that are GPL 3.0 or GPL 3.0 compatible.

We may be, yes.

But in order to change the license to anything else you'd have to find
and get approval of all copyright holders/authors.

Compiling the list of all these people will be fun. Some people's
changes might have been removed by other people's changes. Some people's
patches might be so small that they probably would not enjoy copyright
protection, etc...

It is probably simpler to ask who is opposed to any particular change,
then you can stop asking after a small number of people. :p

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

iD8DBQFG4fYDfg6TFvELooQRAuqFAKCst6NuSEJgG3HBaMqGXSdS8n8NAACgjcle
J8t4Jp+vBwwlkO4badov/8g=
=Dq4L
-----END PGP SIGNATURE-----

Re: Modules that integrate non-GPL PHP apps violatethe GPL.

by David Metzler :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I think the core question in this still is, "What constitutes a  
derivative work", which if my research is correct, cannot be answered  
as a technical question.

I actually just started with searching for wikipedia on the GPL and  
looked from there. Here are a couple of interesting things I found.

Linus Torvald on the subject:
from - http://lkml.org/lkml/2006/12/17/79

For example, glibc could easily have just come out and said the thing  
that
is obvious to any sane person: "using this library as just a standard
library does not make your program a derived work".

... and later in the same post....

And don't get me wrong: I do not say that "linking" _never_ creates
derived works. I'm just saying that "linking" is just a technical step,
and as such is not the answer to whether something is derived or not.
Things can be derived works of each other _without_ being linked, and  
they
may not be derived works even if they _are_ linked.

And some other stuff from a Lawrence Rosen, a lawyer for OSPI:
http://www.linuxjournal.com/article/6366

These questions are important because some licenses require you to  
publish the source code of your portion of the resulting derivative  
work program, a burden you may not want to accept. Here's how I would  
decide in the cases described above.

1) The primary indication of whether a new program is a derivative  
work is whether the source code of the original program was used,  
modified, translated or otherwise changed in any way to create the  
new program. If not, then I would argue that it is not a derivative  
work.

2) The meaning of derivative work will not be broadened to include  
software created by linking to library programs that were designed  
and intended to be used as library programs. When a company releases  
a scientific subroutine library, or a library of objects, for  
example, people who merely use the library, unmodified, perhaps  
without even looking at the source code, are not thereby creating  
derivative works of the library.

3) Derivative works are not going to encompass plugins and device  
drivers that are designed to be linked from off-the-shelf,  
unmodified, programs. If a GPL-covered program is designed to accept  
separately designed plugin programs, you don't create a derivative  
work by merely running such a plugin under it, even if you have to  
look at the source code to learn how.

4) In most cases we shouldn't care how the linkage between separate  
programs was technically done, unless that fact helps determine  
whether the creators of the programs designed them with some apparent  
common understanding of what a derivative work would look like. We  
should consider subtle market-based factors as indicators of intent,  
such as whether the resulting program is being sold as an  
``enhanced'' version of the original, or whether the original was  
designed and advertised to be improvable ``like a library''.

Anyway,  I thought this might help us get past the technicalities of  
what "linking" means.

Dave



On Sep 7, 2007, at 8:33 AM, Larry Garfield wrote:

>
> On Fri, 7 Sep 2007 09:14:52 -0600, Laura Scott <laura@...>  
> wrote:
>> On Sep 6, 2007, at 4:28 PM, Thomas Barregren 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.
>>
>> I wonder whether that in fact is true. By this logic, if you write an
>> application that interfaces with Word, then Microsoft owns it as a
>> derivative of their product. Is that how copyright works? Every time
>> two different applications touch, we have litigation as to who has
>> the most cooties?
>
> No, only if Word's license explicitly said that they own any Macros  
> you write.  AFAIK it doesn't (although I've not actually purchased  
> a copy of Word since last century).
>
> If Word were GPLed, they still wouldn't own your macros.  There is  
> no transfer of ownership in the GPL.  There is only a requirement  
> of GPL re-licensing for derivative works, e.g., Word plus your  
> Macros wrapped up together.
>
>> If someone pulls on a door handle, does he become a derivative of the
>> door? Some things are designed to be utilized by other systems. APIs
>> exist in large part to allow different systems to interface with each
>> other. To claim that not only must a bridge module (to use the
>> example we've been tossing about) be GPL but anything it touches must
>> be GPL as well seems to be a rather far-reaching legal claim ... or
>> tragically self-isolating interpretation for policy.
>>
>> Can GPL exist only in isolation from all other systems? Does mere
>> communication or interaction imply derivation? That's what the RIAA
>> and MPAA claim in their dragnet lawsuits, pre-litigation settlement
>> demands and things like the Sony Rootkit. What next? A GPL rootkit?
>>
>> I wonder how Lawrence Lessig would interpret GPL.
>>
>> Laura
>
> The amount of FUD in this thread is starting to amaze me.  (Not you  
> specifically, Laura; in general.)  I think some people here are  
> reading from the Microsoft anti-GPL playbook with the "transfer of  
> ownership" nonsense.
>
> Folks, the GPL is not as evil ("viral") as some here are making it  
> out to be.  It says, simply, "you can do anything you want with  
> this code, but *if* you redistribute it, *even if it's part of a  
> derivative work*, then it, and as a result the derivative work,  
> must be distributed under the GPL."  That is all.  There is no  
> transfer of ownership, no "viral infection", no "loss of  
> property" (since copyright is not property to start with, but we  
> won't get into that.)
>
> The only question at hand is exactly where the line for "derivative  
> work" is, in particular for modules that interface with 3rd party  
> systems.  The only relevant questions here are:
>
> 1) If a Drupal module exists only to interface between Drupal and a  
> non-GPL system using in-process PHP function calls, does that  
> violate the GPL?  (FSF, according to Jeff, believes it does.  I say  
> to ask a lawyer not in the FSF's employ in order to get a more  
> unbiased answer.)
>
> 2) If a Drupal module exists only to interface between Drupal and a  
> non-GPL system using non-in-process APIs (SOAP, RSS, REST, reading  
> a CSV, exec/fork, etc.), does that violate the GPL?  (FSF,  
> according to Jeff, says "not in letter, but in spirit".  Given the  
> number of RSS feeds coming off of non-Free systems that we all read  
> on a regular basis using Aggregator, I don't think many people  
> agree with the "spiritual violation".  For the letter, again, we  
> should ask a lawyer.)
>
> Bottom line: Unless you are a lawyer or have recently spoken to one  
> on this subject, you have nothing constructive to contribute to  
> this thread any more.  Yes, I include myself in that statement as I  
> am not a lawyer.  Can we move the GPL FUD to some other forum and  
> get back to something useful, like getting Drupal 6 finished?
>
> --Larry Garfield
>


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

by Thomas Barregren :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello everyone,

Following this discussion thread, it seems that great many developers
are not sufficiently familiar with copyright and licensing of free and
open source software (FOSS). A very good brief on this matter, which I
can really recommend to everyone to read, is the 13 pages short
publication "The Open Source Legal Landscape" by the Australian lawyer
Brendan Scott. Follow this link to download it as PDF:

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

Please, notice that the paper discusses *Australian* law. The law of
other jurisdictions may (or may not) be different.

With Brendan's kind permission, I have below included the most
interesting parts with respect to our discussion.

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.

1.4 For example, if a person buys both a screwdriver and some
software from someone, they may do what they like with the
screwdriver, including modifying it, improving it, renting it to
others etc. However, the scope of actions that they can undertake
with the software is strictly limited (subject to some
qualifications) to those things over which they have been granted
permission from (ie licensed by) the holder of copyright in the
software. [...]

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.

4.1 Open source licensing is a customer driven market reaction to
the high transaction costs and anti-competitive effects that the old
model has produced. It effectively says that, through judicious use
of copyright, customers can acquire software with rights analogous
to ownership. In the example above, if the software is open source
software, the person acquiring the software would have property-like
rights over the use of the software in a manner analogous to the
rights they have over the screwdriver.

7.1 One of the characteristics of open source licences is that they
must “/permit”/ the source code of modifications to the software to
be licensed under an open source licence. [...] Some open source
licences go further, not only permitting, but /requiring/ that
modifications of the software or other, related, software be
licensed under an open source licence, typically under the terms of
the same licence. [...]

7.2 The GNU General Public License (GPL) is the best known, and
perhaps the most widely implemented of the strong licences. It
requires that if modifications to GPLed software are published or
distributed, they must be licensed under the terms of the GPL. It
further requires that works which: (a) include as part of them a
modification of software licensed under the GPL; and (b) which are
distributed must also be licensed under the GPL and that access to
the source code of the software must also be provided. [...]

9.1 One of the consequences of strong licensing is that care must be
exercised when combining source code from two or more different
projects which are licensed under different licences. [...] If the
requirements of these licences are /per se/ inconsistent then there
is no legal basis on which the output product can be licensed.

14.5 The GPL permits the making of changes to the software and does
not require the distribution of changes made. However, if you do
distribute those changes, and they are “derived from” the software,
you must distribute those changes on the terms of the GPL. This
makes the GPL a strong licence. [...]

I have deliberately omitted the paper's definition of "strong licence"
above. That is because Brendan, in private correspondence, has asked me
to downplay the characterization because he is increasing coming to the
conclusion that distinction between "weak" and "strong" licenses is not
all that clear.

Please, read the full publication which can be downloaded from the web
site of Open Source Law <http://www.opensourcelaw.biz/>.

Best regards,
Thomas (IANAL)

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

by FGM :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The same should be noted about other countries too: a lot of people chiming
in on this discussion seem to assume there is just one legal system and the
GPL is valid under it.

Actually, some parts of the GPL are invalid in some legal systems and the
matching provisions are automatically deemed unwritten in that case. This
for instance the case with french law and provision 11 and 12 which are void
when the user is an end-user. Accordingly, provision 7 could be interpreted
as implying that this forbids any person, physical or moral, operating in
France, to distribute GPL software he did not author. Other countries may
have similar dispositions.

This is actually one of the main points behind the creation of the CeCILL by
the french government: it was designed to be applicable both under the
french, US and some other legal systems, and also fixes a few technical
problems like the definition of applicable law, which is missing from the
GPL.

Note that the FSF also worked on this problem: the equivalent provisions in
GPLv3 (15 and 16) have been extended by provision 17 which takes into
account the fact that the former writing was not applicable in some
countries. In that regard at least, the GPLv3 should be more universal than
GPLv2.

----- Original Message -----
From: "Thomas Barregren" <thomas@...>
To: <development@...>
Sent: Saturday, September 08, 2007 10:52 AM
Subject: Re: [development] Modules that integrate non-GPL PHP apps violate
the GPL.
[...]
> Following this discussion thread, it seems that great many developers
> are not sufficiently familiar with copyright and licensing of free and
> open source software (FOSS). A very good brief on this matter, which I
> can really recommend to everyone to read, is the 13 pages short
> publication "The Open Source Legal Landscape" by the Australian lawyer
> Brendan Scott. Follow this link to download it as PDF:
>
>
http://opensourcelaw.biz/publications/papers/BScott_OSS_Legal_Landscape_060328.pdf
>
> Please, notice that the paper discusses *Australian* law. The law of
> other jurisdictions may (or may not) be different.
[...]


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

by Thomas Barregren :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Angela Byron skrev:

>
> On 7-Sep-07, at 3:23 PM, Dries Buytaert wrote:
>
>>
>> On 30 Aug 2007, at 09:08, 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.
>>
>> Because some people e-mailed me in private about this; it's going to
>> take me a couple more days to respond to this thread.  I'm also going
>> to consult some other Open Source projects about this.  In the mean
>> time, keep on discussing as all input is valuable before we refine
>> our stance. :)
>
> Ok, I was keeping quiet in this thread, but since you seem to want
> input...
>
> IMO, the only thing we can do is exactly what Joomla! did:
>
> - Do not fork the GPL by creating our own interpretation of it (adding
> exceptions, etc.).

We should definitely *not* fork GPL. That would be committing hara-kiri.

But adding a "FOSS Exception" or "Linked Under Controlled Interface
Exception" is *not* forking. On the contrary! It is a proper way to
solve situations like the one we are discussing. The technique is
proposed and fully described with template and everything on FSF/GNU's
web site:

    * 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


In fact, it *might* be necessary to add a FOSS Exception for the
PHP-license. Why? The PHP-license is not compatible with the GPL. That
itself doesn't prevent PHP-programs to be distributed under GPL. But
since Drupal *make use* of GD and other libraries distributed under the
PHP-license, it is possible to argue that Drupal in part is a derivative
of GD and the other libraries. If this cannot be deemed to fall under
the platform exception in GPL, it is not possible to distribute Drupal
under GPL without adding a notice saying that it is okay. Again, adding
a such notice is not forking GPL.

> Adding exceptions anyway is a physically impossibility; you'll never
> find all of the copyright holders of Drupal to sign off on it, and
> many of us would oppose such an action.

I am not completely convinced that it is a "physically impossibility".
After all, it is a limited number of people who have committed code to
the core. I suppose most of them are still members of Drupal.org, and
hence possible to get in contact with. Why not try? Likely, a vast
majority of all core contributors will accept a "FOSS Exception" and
possible also a "Linked Under Controlled Interface Exception" for a
"Module Programming Interface" (e.g. hooks and some utility functions).

There will of course be some persons who cannot be contacted or who
won't give their permission. But their numbers will probably be very
small, and therefore easy to just replace their code with new code with
the same functionality. After all, copyright doesn't protect ideas, only
the expression of ideas.

BTW, something similar has been done before, and in much larger scale,
namely BSD.

> - Remove any code from our repositories that combine with non-GPLed
> code. This would be things like SMF, vBulletin, CiviCRM integration
> bridges. If those companies want to put themselves in potential legal
> jeopardy by providing bridges for our CMS, then they can host it on
> their own infrastructure, not ours, or they can dual-license their
> software so that it's GPL-compatible.

Yea!

> I think a lot of the discussion in this thread is just out-right
> denial. I'm quite sure that the folks at Open Source Matters looked
> into this issue extensively before Joomla! made their decision to quit
> distributing their SMF bridge, especially since the vast majority of
> their users are non-programmers who would never in a million years be
> able to create one by themselves, and since Joomla! does not have a
> core forum system of their own.

Very good point. I can only add, for those who think they can prove GPL
unfeasible, that GPL has been around and scrutinized for 18 years.

> On a personal note, I fully support the viral nature of GPL, and see
> it as a critical feature, not a bug.The GPL is part of the primary
> reasons I spend my time working on applications like Drupal; it
> preserves the freedoms I was given for all future users of my code.

I can only agree.


Best regards,
Thomas

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

by Thomas Barregren :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

FGM skrev:
> The same should be noted about other countries too: a lot of people chiming
> in on this discussion seem to assume there is just one legal system and the
> GPL is valid under it.
>  
[...]
> Note that the FSF also worked on this problem: the equivalent provisions in
> GPLv3 (15 and 16) have been extended by provision 17 which takes into
> account the fact that the former writing was not applicable in some
> countries. In that regard at least, the GPLv3 should be more universal than
> GPLv2.

This alone is a VERY good reason for Drupal.org to move from to GPL v3.

Best regards,
Thomas

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

by Gerhard Killesreiter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Angela Byron schrieb:
>
> On 8-Sep-07, at 5:51 AM, Thomas Barregren wrote:
>

>> I am not completely convinced that it is a "physically impossibility".
>> After all, it is a limited number of people who have committed code to
>> the core. I suppose most of them are still members of Drupal.org, and
>> hence possible to get in contact with. Why not try? Likely, a vast
>> majority of all core contributors will accept a "FOSS Exception" and
>> possible also a "Linked Under Controlled Interface Exception" for a
>> "Module Programming Interface" (e.g. hooks and some utility functions).
>
> Interesting. So the act of committing code transfers authorship? My

No, no, no, and no. This does not happen. I think Thomas doesn't know
how Drupal development works, which made him use the term "core committer".

I hereby state that for none of the patches not written by me that I've
committed to core or contrib I accept transfer of copyright or
authorship (the latter is actually impossible under German law) of the code.

> offering up code and saying, "Please commit this to core" is synonymous
> with "I hereby abandon all rights I have as the author of this code, and
> trust that the core committers will not someday do something silly with
> it?"
>
> That's something I didn't know before. It was my understanding that
> copyright was retained by each individual who has contributed code to
> the project, regardless of who actually pulled the "commit" trigger.

That is my understanding too.

Cheers,
        Gerhard

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

iD8DBQFG4rpyfg6TFvELooQRAgbGAJ4nE1FCxwsXHqB0dwsGDd2cDwfrzQCbBDhQ
PnHmlBl6GL1cy2xqf2vTH7A=
=2QNh
-----END PGP SIGNATURE-----
< Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 | Next >