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

[Thomas Barregren]

Darren Oh skrev:
> The argument being made is that distributing a module that allows
> Drupal to use separately distributed third-party code would make the
> third-party code a modification of Drupal...

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.

The law prohibits you to modify or distributing a work or its derivative
works, unless the holder of the Intellectual Property Rights grants you
permission to do otherwise. GPL grants you such rights *if and only if*
you comply to certain terms and conditions. No one force you to accept
these. But as stated in § 5 of the license: "nothing else grants you
permission to modify or distribute the Program or its derivative works."

So, if you distribute your module, either you have accepted the GPL or
you are committing infringement on the intellectual property rights. I
presume you are law-abiding, and hence indeed have accepted the GPL. :-)
As a consequence, your module must also be distributed under the GPL.

Now, suppose your module also make use of another program. If your
module just invokes the other program's main function with some options
and waiting for it to return, for instance by using fork and exec, there
is nothing to worry about. But if your program and the other program are
linked, even if it is done only at runtime, and make function calls to
each other and share data structures, your module is a derivative work
of the other program as well.

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.

There is however a way out. Drupal.org could add an exception to the
license. Examples of such exceptions are described in the GPL FAQ:

    * 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


> If that is really what the FSF is claiming, I too would question the
> reliability of their interpretation.

Some reading sugestions:

    * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins
    * 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#FSWithNFLibs

Best regards,
Thomas

[Karoly Negyesi]

> That alone makes the module a derived work of Drupal.
>
> But if your program and the other program are linked, even if it is done
> only at runtime, and make function calls to each other and share data
> structures, your module is a derivative work of the other program as well.

AAAAAAAAH! Finally somebody explained this whole situation clearly.

So if I am writing a bridge to run with Drupal that's GPL because of Drupal and because it's considered a derivative of some non-GPL code that means I am breaking some clause in the *other* code licence and we know there is such a clause *because* it is non GPL compatible. So the issue looked cloudy because we know the bridge breaks some rule but it can not be told what without studying the other licence. This makes sense to my obsessed-with-math-logic mind. For the first time, this debacle makes sense even if not a pleasant one.

However, there seems to be an escape! http://forum.joomla.org/index.php?topic=190545.0 this ends with "the LGPL would allow someone else to derive code based on it without any restriction you can make a LGPL bridge to buffer your proprietary extention (such as SMF) to a GPL program."

So, if this holds up then we should allow LGPL code in our repo and ask the bridge module authors to LGPL their code. This is a ton easier than, say, changing the licence of Drupal core.

[Earnie]

Quoting Karoly Negyesi <karoly@...>:

>> That alone makes the module a derived work of Drupal.
>>
>> But if your program and the other program are linked, even if it is done
>> only at runtime, and make function calls to each other and share data
>> structures, your module is a derivative work of the other program as well.
>
> AAAAAAAAH! Finally somebody explained this whole situation clearly.
>
> So if I am writing a bridge to run with Drupal that's GPL because of
> Drupal and because it's considered a derivative of some non-GPL code
> that means I am breaking some clause in the *other* code licence and
> we know there is such a clause *because* it is non GPL compatible. So
> the issue looked cloudy because we know the bridge breaks some rule
> but it can not be told what without studying the other licence. This
> makes sense to my obsessed-with-math-logic mind. For the first time,
> this debacle makes sense even if not a pleasant one.
>

Yes, but you could also be breaking a clause in the GPL (the most
likely scenario).  Yes, you must compare both licenses to determine if
they fit together.

> However, there seems to be an escape!
> http://forum.joomla.org/index.php?topic=190545.0 this ends with "the
> LGPL would allow someone else to derive code based on it without any
> restriction you can make a LGPL bridge to buffer your proprietary
> extention (such as SMF) to a GPL program."
>

I don't buy into it.  The GPL and the LGPL are the same except that
LGPL gives others the right to use the binary version of your API
without GPL viral infection.  If you provide no API then the exception
is worthless.  And the statements of the GPL state that you must GPL
the combined work so you can't just apply the LGPL exception to your
module because the Drupal license doesn't allow for it.

> So, if this holds up then we should allow LGPL code in our repo and
> ask the bridge module authors to LGPL their code. This is a ton
> easier than, say, changing the licence of Drupal core.
>

The license of the Drupal core license is the one that rules in this
situation.  Since I must use Drupal API I must GPL accordingly.  The
only option is that the Drupal core license provide exceptions for the
use of third party libraries.  Note the LGPL here isn't sufficient
(check out the FSF libstdc++ exceptions) since *source* code for the
API must actually be included.  The LGPL exception is for the *binary*
use including the declaratives for the API but not code that is
included by other files such as you might find in a C++ header or a PHP
include file.  It's not L'ibrary'GPL it is L'esser'GPL.

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

[Chris Johnson-21]

On 9/7/07, Thomas Barregren <thomas@...> wrote:
> But if your program and the other program are
> linked, even if it is done only at runtime, and make function calls to
> each other and share data structures, your module is a derivative work
> of the other program as well.

If this is true and legally correct (and I understand it), then we are
lucky the FSF doesn't have the money to sue thousands of cases in
court.  Because every time a GPL program is compiled and run on a
non-GPL operating system, it's going to be breaking this "rule."  No
GPL software could be run on Mac OS or Windows, if it called the OS or
any GUI API.

Such is the spiral of insanity that this provision of the GPL causes.

[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 believe this would be defeated in court as were proprietry software
vendors when attempting the same trick.  i would also assert it is
also an infrigement on the freedoms of free software and a direct
contradiction of what free software is about.

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.

[ttw+drupal]

On 07.09-14:01, Chris Johnson wrote:
[ ... ]
> If this is true and legally correct (and I understand it), then we are
> lucky the FSF doesn't have the money to sue thousands of cases in
> court.  Because every time a GPL program is compiled and run on a
> non-GPL operating system, it's going to be breaking this "rule."  No
> GPL software could be run on Mac OS or Windows, if it called the OS or
> any GUI API.

there is in fact a specific exclusion clause to this effect.  but
yes, it is a spiral of insanity, people fighting against the precise
freedoms they attempt to protect.  a lawyer's wet dream.

[ttw+drupal]

On 07.09-12:35, Karoly Negyesi wrote:
[ ... ]
> >
> > But if your program and the other program are linked, even if it is done
> > only at runtime, and make function calls to each other and share data
> > structures, your module is a derivative work of the other program as well.
>
> AAAAAAAAH! Finally somebody explained this whole situation clearly.

i'm afraid this isn't possible.  this situation is unclear, period.

if you have a specific issue i suggest you reference the previous
poster's suggestions on getting around the GPL's problem areas or
talk to a lawyer.

the LGPL is not about using the API it is about distributing code or
binaries based upon that free code.  for example i could write an
photo gallery and use LGPL libraries, then package them up and sell
them as a product.  this would not be possible if they were GPL, you
cannot distribute that code as part of something that does not have
a compatible license.  if those libraries were GPL i could still use
them in my code but the person who installed my proprietry program
would be required to find and either build or install the GPL
libraries instead.  this is considered, by many, to be a loophole.

obviously, from the above the LGPL is not suitable for Drupal as it
would allow me to write a module to extend Drupal and then distribute
an entirely functioning product (which would be 90% stolen code) as
my own, charge for it, and avoid sharing my module with the community.
currently, nothing (that i know of) can stop me writing a module and
distributing it under any license i like but my users would need to
go to Drupal and get that product (where it would explain the
relevance and need for free software) seperately.

basically, if you wish to use free software to produce proprietry
solutions question your conscience first, do the best you can in your
sitation and double check the _specific_ decisions with community and
legal references.  i would suggest that, even if you are legally
covered, if a specific community clearly does not wish you to interface
their product with any proprietry code you must again ask your consience
if you are stealing.  but remember everyone has the same right of
ownership to code as you this is the fundamental action (and power)
of free code.

if you are on the other side (i.e. releasing code) and want to figure
out which license to use, guidance by the FSF around leveraging your
input to help propogate free code is, if your code is 'competing' with
widely available propietory code performing the same function, and,
there is reasonable likely hood that allowing it to be used in non-free
software will increase it's distribution and use then use the LGPL
(simple example would be the code produced by a complier-compiler like
yacc).  in any other circumstance use the GPL.  i.e. the LGPL will
never be suitable for a Drupal module (except, perhaps, in legal
dance where developers need to interface with another incompatible
license ... of course, we all want you to fight for free software
first in this situation, but you can't win them all :-).

as you can tell from the complicated nature of this discussion this
is not clear cut or defined.  many do not want their code to be used
at all unless it is propogating their notions of freedom or notions
of freedom they deem compatible with their own.  this is, quite
obviously, contrary to the notion of freedom but unfortunately a
popular 'free' political doctrine.  it's understandable, people are
basically using free code and products and then basically,
re-branding it and selling it; which is pretty despicable practice.
but that is freedom for you, we have people using the freedom of
speech to say pretty despicable things too.

[ttw+drupal]

On 06.09-17:11, Cog Rusty wrote:
[ ... ]
> By "legitimate interest" I was referring to something different: Under
> law usually, when you see a thief robbing someone, you can report it
> to the police but you can't sue the robber. Only the victim can (or
> the authorities if it is a penal offence and not just a civil one).You
> don't need legitimate interest to do something. You need it to
> challenge something.

the GPL essestially transfers ownership to you and the therefore i
would understand that anyone who uses GPL code has a legitimate
interest.  a legal case will be weakened in the absence of a copyright
holder (and certainaly alterations to licensing are extremely complicated
in their absence) but it is not required.

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

On Friday, 7. September 2007, ttw+drupal@... wrote:

> On 06.09-17:11, Cog Rusty wrote:
> [ ... ]
>
> > By "legitimate interest" I was referring to something different: Under
> > law usually, when you see a thief robbing someone, you can report it
> > to the police but you can't sue the robber. Only the victim can (or
> > the authorities if it is a penal offence and not just a civil one).You
> > don't need legitimate interest to do something. You need it to
> > challenge something.
>
> the GPL essestially transfers ownership to you and the therefore i
> would understand that anyone who uses GPL code has a legitimate
> interest.  a legal case will be weakened in the absence of a copyright
> holder (and certainaly alterations to licensing are extremely complicated
> in their absence) but it is not required.

No, it doesn't transfer ownership. It grants you a license to use, modify and
redistribute the code, but it doesn't transfer ownership.
You'll most likely need a copyright holder to sue violators.

[Earnie]

Quoting Cog Rusty <cog.rusty@...>:

>
> No difference at all if we find that the GPL license text attached to
> a bridge module invalidates itself. But does it, and according to
> which point of the license text? That is my question.
>

The point which is exampled by the original BSD[1] is the one that the
smf module violates because of restrictions the Simple Machines license
places [1],[2] and the fact that the module becomes a combined work
since it includes source code from both for you to use the differing
API.

[1] http://www.fsf.org/licensing/licenses/gpl-faq.html#OrigBSD
[2] http://www.simplemachines.org/about/license.php
[3] http://www.simplemachines.org/about/opensource.php

Earnie

P.S. I am neither for or against the GPL but when I create something
new I do not choose it because its viral nature removes a freedom I do
not wish to remove.  However, I do abide by it if others have chosen it
for their works and will at that time promote it.

[Earnie]

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/

[ttw+drupal]

On 07.09-15:15, Jakob Petsovits wrote:
[ ... ]
> No, it doesn't transfer ownership. It grants you a license to use,
> modify and redistribute the code, but it doesn't transfer ownership.
> You'll most likely need a copyright holder to sue violators.

ownership was a badly chosen term, apologies, it transfers equal rights
of use to all parties.

does than mean in the death or absence of a copyright holder that the
GPL may be, essentiall, ignored?  this seems problematic.  in the case
of copyright i understand rights transfer to the next of kin but with
free software it seems there is little incentive for next of kin to
pursue issues of copyright.  furthermore, in the absence of *all*
copright holders the right to challange may also be brought into
question.  is anyone aware of a case in point?

On Friday, 7. September 2007, ttw+drupal@... wrote:

> On 07.09-15:15, Jakob Petsovits wrote:
> [ ... ]
>
> > No, it doesn't transfer ownership. It grants you a license to use,
> > modify and redistribute the code, but it doesn't transfer ownership.
> > You'll most likely need a copyright holder to sue violators.
>
> ownership was a badly chosen term, apologies, it transfers equal rights
> of use to all parties.
>
> does than mean in the death or absence of a copyright holder that the
> GPL may be, essentiall, ignored?  this seems problematic.  in the case
> of copyright i understand rights transfer to the next of kin but with
> free software it seems there is little incentive for next of kin to
> pursue issues of copyright.  furthermore, in the absence of *all*
> copright holders the right to challange may also be brought into
> question.

That's exactly what I wanted to say, thanks for the to-the-point explanation.
Since I don't want to be known for insisting on copyright headers, I won't
mention them here (...hehe), but you get the point.

> is anyone aware of a case in point?

I'm not.

[Glenn Wybo]

Hi,

I'm starting a project where I need to make a larger database that I'm used to make. I can use a little advise on this project.
Each record in the database will include 1 to 3 photo and some other information, in total aproximately 100k of memory per record. I expect a total of maximum 500 records per category (1000 categories). So 500 x 1000 x 100K = 50G. It is possible to store all data in one table. This database will be used between a larger database and the clients.
My question is: is one table feasable for this amount of data? Or would it be recommended to store the data in different tables. The key factor here is speed. If the client wants to see some information (always with at least 1 photo), the time to get the information from the database to the screen should be minimal.


thanks,

Glenn
_________________________________________________________________
Ontwerp je eigen Space op het net en deel wat je lief is met je vrienden!
http://spaces.live.com

[Shai Gluskin-2]

Glenn,

I think that all the standard ways of storing images in Drupal is to store the file location in the database but to keep the photo itself in the server's /files directory.

Are you doing something different?

Shai

On 9/7/07, Glenn Wybo <glennwybo@...> wrote:

Hi,

I'm starting a project where I need to make a larger database that I'm used to make. I can use a little advise on this project.
Each record in the database will include 1 to 3 photo and some other information, in total aproximately 100k of memory per record. I expect a total of maximum 500 records per category (1000 categories). So 500 x 1000 x 100K = 50G. It is possible to store all data in one table. This database will be used between a larger database and the clients.
My question is: is one table feasable for this amount of data? Or would it be recommended to store the data in different tables. The key factor here is speed. If the client wants to see some information (always with at least 1 photo), the time to get the information from the database to the screen should be minimal.


thanks,

Glenn
_________________________________________________________________
Ontwerp je eigen Space op het net en deel wat je lief is met je vrienden!
http://spaces.live.com

[sringwood]

Glen

        Regarding

>> I'm starting a project where I need to make a larger database that I'm
used to make. I can use a little advise on this project.
>> Each record in the database will include 1 to 3 photo and some other
information, in total aproximately 100k of memory per record. I expect a
total of maximum 500 records per category (1000 categories). So 500 x 1000 x
100K = 50G. It >> is possible to store all data in one table. This database
will be used between a larger database and the clients.
>> My question is: is one table feasable for this amount of data? Or would
it be recommended to store the data in different tables. The key factor here
is speed. If the client wants to see some information (always with at least
1 photo), >> the time to get the information from the database to the screen
should be minimal.

Are you really planning on storing the photo's in the table.  It is
generally more useful to store the image on the file system and just the
path in the database (you just need the image path and not the image for the
browser).  If you are not planning on placing the images in the database
100K is a lot of data, more than make sense to display on a single screen.

As for speed, one of the factors is a unique key for each record another
though is how you plan to look stuff up.  Just the potential number of
records is large (500,000) and almost twice as many comments a drupal.org
has.  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.  The bottom line is it
will take some tweeking to get things "right" and that will depend on the
details of the data and how the data is accesed.

Steve

[Laura Scott]

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?

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

On Fri, 7 Sep 2007 09:51:00 -0600, "Steve Ringwood" <nevets@...> wrote:

> Are you really planning on storing the photo's in the table.  It is
> generally more useful to store the image on the file system and just the
> path in the database (you just need the image path and not the image for
> the
> browser).  If you are not planning on placing the images in the database
> 100K is a lot of data, more than make sense to display on a single screen.
>
> As for speed, one of the factors is a unique key for each record another
> though is how you plan to look stuff up.  Just the potential number of
> records is large (500,000) and almost twice as many comments a drupal.org
> has.  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.  The bottom line is
> it
> will take some tweeking to get things "right" and that will depend on the
> details of the data and how the data is accesed.
>
> Steve

If you're looking up records by a numeric primary key (which is most things in Drupal) or by some other properly indexed value, 500,000 records is nothing.  A good RDBMS can handle millions of records.  The keyspace for the primary key, if it's an integer, is somewhere around 3 million.  Using an unsigned int or bigint will increase that even further.  

Just use the Drupal file API.  It puts the files on disk and the path in the files table, and should scale to hundreds of thousands of records just fine if you're using a recent version of MySQL.  

--Larry Garfield

[Mark Fredrickson-2]

> 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