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

[jp.stacey]

> I don't want to be rude, but all of these questions have already  
> been answered in this thread.

Sorry about that: you're quite right. I'd got through around half of  
them this morning and the others had been marked as read (almost  
certainly by a slip of my mouse) so I didn't spot that.

J-P

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Thomas Barregren]

Darren Oh skrev:
> 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.

No, it is not as simple as that.

Suppose we develop a module that bridges Drupal with another program. If
that is accomplished by just "using" the program, that is invoking the
program's main function with some options and waiting for it to return,
for instance by using pipes, sockets or command-line, then the module is
not a derived work of the application. But, if the module "know" things
internal to the program, that is the module links to the program,
invokes functions and shares data structures, then the module and the
program, as a whole, is a derived work of the program.

Since the module and Drupal, as a whole, is a derived work of Drupal,
GPL requires that the whole combined program has to be released under
the GPL. That is why I think the license of the other program must be
compatible with GPL if (but only if) the module "know things" internal
to the program.

> I know it's repetitive, but this discussion has been answering the
> wrong question.
The really question, as I see it, is whether d.o. should continue to
expose itself for the risk of being challenged in court for copyright
infringement, or do something about modules that link to third-party
programs with licenses not compatible with GPL. I suggest the latter. We
can either follow J! and cease the distribution of contaminated modules,
or add a FOSS Exception, Linked Under Controlled Interface Exception or
something similar, or both.

I think I have said everything I can in this issue. So I should really
"rest my case" now. Seeing is believing. :-)

Best regards,
Thomas (IANAL)

[ttw+drupal]

On 10.09-00:25, Thomas Barregren wrote:
[ ... ]
> Quoting a book falls under the notion of Fair Use. Creating a derivative
> work doesn't.

correct.  but only relevant because you define calling a defined
interface a derivative work.  you only call it this because it suits
your political ends.

_again_, for the cheap seats, this is pointless.  what is relevant is
the actions being taken to resolving the current licensing issues so
that the community may make decisions to go forward.

[Thomas Barregren]

ttw+drupal@... skrev:

> On 10.09-00:25, Thomas Barregren wrote:
> [ ... ]
>  
>> Quoting a book falls under the notion of Fair Use. Creating a derivative
>> work doesn't.
>>    
>
> correct.  but only relevant because you define calling a defined
> interface a derivative work.  you only call it this because it suits
> your political ends.
>  

Stupidity. I haven't define the term "derivative work" to suite my
"political ends". It is a legal term used in the copyright laws around
the world.

Thomas

[ttw+drupal]

On 10.09-17:01, Thomas Barregren wrote:
[ ... ]
> >correct.  but only relevant because you define calling a defined
> >interface a derivative work.  you only call it this because it suits
> >your political ends.
> >  
>
> Stupidity. I haven't define the term "derivative work" to suite my
> "political ends". It is a legal term used in the copyright laws around
> the world.

you may not intimidate me with abuse.  the term "derivative work" is
not clearly defined within law and is thus open to interpretation.
your interpretation is clearly one that suits your political ends and,
in my opinion, is not only morally wrong but one that is legally
untenable under US and European law.

[Jakob Persson]

ttw+drupal@... wrote:

...the term "derivative work" is
not clearly defined within law and is thus open to interpretation.
your interpretation is clearly one that suits your political ends and,
in my opinion, is not only morally wrong but one that is legally
untenable under US and European law.
  

As for European law I don't know but Wikipedia claims there's such a definition what US law is concerned:
http://en.wikipedia.org/wiki/Derivative_work

..."derivative work" is defined in 17 U.S.C. § 101:

A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”.

There are futher legal references in the same article. Also considering the number of references to "derivative work" in software licenses and contracts, I very much doubt the term is undefined in common legal practice.

The Wikipedia article agrees with you on one point and that is regarding software:

"The definition of derivative works of software is not entirely clear[5]" [1]

However this article is just one of many sources and I'd rather rely on a legal dictionary than Wikipedia to bring some real clarity.

Further, the "rule of thumb" definition re softwate in the Wikipedia article [1] seems to support Thomas point of view since it only allows exception of the "derivative work" rule for applications that serve as plugins and use functions in a library. Since Drupal is not a library and a module is not a plugin the logical outcome is given; a module must be considered "derivative work" and is therefore subject to GPL. You'd have to challenge those two premises to criticize the conclusion Thomas has drawn.

Further discussion can be found here:
http://www.rosenlaw.com/lj19.htm

I think the mud-slinging is regrettable and sad. Please stick to the point and quote sources instead of being inflammatory. We don't need a flamewar. I've never seen a flamewar leading to anything good.

Since the whole discussion apparently boils down to this definition and the challenging of it, and there's no sign of agreement in sight, we'll need an arbitrator and Lawrence Rosen seems to be a candidate.

[1] http://en.wikipedia.org/wiki/Derivative_work#Derivative_work_of_software

On Mon, 10 Sep 2007 18:19:16 +0200, Jakob Persson <jakob@...> wrote:


> Further, the "rule of thumb" definition re softwate in the Wikipedia
> article [1] seems to support Thomas point of view since it only allows
> exception of the "derivative work" rule for applications that serve as
> plugins and use functions in a library. Since Drupal is not a library
> and a module is not a plugin the logical outcome is given; a module must
> be considered "derivative work" and is therefore subject to GPL. You'd
> have to challenge those two premises to criticize the conclusion Thomas
> has drawn.

How exactly is a Drupal module not a plugin?  (Not a troll, a genuine question.)  I don't know of a legal definition of plugin, but from a technical standpoint they fit my understanding of what a plugin is, despite the name.  In the generic sense "module" would mean "somewhat discrete component of a system", while "plugin" would mean "swappable and optional component of a system".  (Again, not legal definitions.)

--Larry Garfield

[ttw+drupal]

On 10.09-18:19, Jakob Persson wrote:
[ ... ]
> As for European law I don't know but Wikipedia claims there's such a
> definition what US law is concerned:
> http://en.wikipedia.org/wiki/Derivative_work
[ ... ]
> There are futher legal references in the same article. Also considering
> the number of references to "derivative work" in software licenses and
> contracts, I very much doubt the term is undefined in common legal practice.

you have to be kidding.  the bickering over semantics is ridiculous.
this is "definition" does not effect the fact that this is open to
interpretation in each specific case; which was the point being made.
the quotation, quite clearly, does not clarify whether using hooks
would be defined as a "derivative work" - which is the case in point.
are you contesting this based upon your reference and suggesting that
it is clearly defined?

i apologise for repeating myself again and again but it makes no
difference what we think the law says.  what is immediately relevant
is the currently licensing issues and the communities stance around
these issues.

[ ... ]
> Since the whole discussion apparently boils down to this definition and
> the challenging of it, and there's no sign of agreement in sight, we'll
> need an arbitrator and Lawrence Rosen seems to be a candidate.

i disagree, as per our peers comments, it requires the collection of
copyright holders and the tidying of current licensing.

then, i suggest, it requires a debate on this specific subject (i.e.
how shall we let module writers use our software), a vote, a resolution
between the copyright holders and _only then_ does it requires a
discussion on the legal enforcement of those issues.

(if the community decides to exclude other incompatible licenses
from using hooks then i expect you will be prove correct, it will
boil down to that issue and we will need legal council to close that
loophole)

[Jakob Persson]

Larry Garfield wrote:

How exactly is a Drupal module not a plugin?  (Not a troll, a genuine question.)  I don't know of a legal definition of plugin, but from a technical standpoint they fit my understanding of what a plugin is, despite the name.  In the generic sense "module" would mean "somewhat discrete component of a system", while "plugin" would mean "swappable and optional component of a system".  (Again, not legal definitions.)

--Larry Garfield

  

Refering to the references I mentioned in my previous email the conclusion I draw is that a Drupal module that utlizes hooks cannot be considered a plugin since Drupal does not provide a defined interface. By defined interface I mean a discrete set of public routines that can be called by an application the same way Drupal uses GD to manipulate bitmap data. A Drupal module uses and can use not only hooks but a wide range of internal functions to Drupal (as well as of other modules) since it has not access to a limited scope but to all the internals of Drupal. The question here is not what a module does but what it is allowed to do. Since Drupal fails to provide a defined interface a Drupal module cannot be considered a plugin. Which may also be of relevance is that that a module is perceptually and behaviorally (from the user's POV) a part of Drupal.

Therefore a module *is* derivative work.

The same argument applies to a module that interfaces with third party non-GPL-compatible software in the same fashion (a so called bridge).

Now this is old news. Jeff started this discussion quoting the FSF's experts reaching the same conclusion as I have. What we need to focus on is the issues that were raised - that is how do we allow Drupal modules to interface with software available under non-GPL-compatible licenses without violating the GPL.

So far many good ideas have been posted and there are others with much more knowledge than I have who I know for certain can provide a viable strategy to bring every contributor's code safely back into the GPL fold.

[ttw+drupal]

On 10.09-20:26, Jakob Persson wrote:
[ ... ]
> Therefore a module *is* derivative work.
[ ... ]
> So far many good ideas have been posted and there are others with
> much more knowledge than I have who I know for certain can provide a
> viable strategy to bring every contributor's code safely back into
> the GPL fold.

the continual propounding of this opinion is not beneficial to closing
this thread and letting people move forward with development.  this
can only be asserted by a court of law in a specific duristiction.

until the stated objective of the Drupal community is sanctioned by
the listed copyright holders (i.e. they agree to sue non-complying
parties), and correct ammendments are made to any incorrect files,
and non-complying modules are removed from the distribution; the
minority should refrain from pressing others with this dictum.

n.b: i would still encourage all developers to release free code
whenever possible and personally believe the GPL is a good license as
it protects your code from 'consumption' by commercial entities

[Anton-34]

On 10/09/2007, J-P Stacey <jp.stacey@...> wrote:
> 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.

No the reason TinyMCE isn't bundled with its bridge module isn't
because of incompatible licenses but Drupal policies on only allowing
GPL code in CVS.

TinyMCE has a GPL compatible license (LGPL), so there is nothing wrong
license wise with bundling up TinyMCE with a Drupal module and
distributing it from your own server as a combined work under the GPL.
The same is true with any other code with a GPL compatible license.

So although distributing a SMF bridge module (which sparked this
debate) appears to violate the GPL, distributing the TinyMCE bridge
module wouldn't.

--
Cheers
Anton

[Kevin Reynen]

The current Drupal CVS policy doesn't differentiate between GPL and non-GPL.  The current policy is no third party code.  As it's been explained to me, if users can get the code somewhere else, it doesn't belong in Drupal's CVS.

Nedjo suggested some revisions to the CVS policy to make it easier for developers to include small javascript libraries back in March (http://drupal.org/node/124978), but AFAIK the policy is still no third party code... GPL compatible or otherwise.

___

Kevin Reynen
Integrated Media Coordinator
Reynolds School of Journalism and
Advanced Media Research
University of Nevada, Reno

On 9/10/07, Anton <anton.list@...> wrote:

On 10/09/2007, J-P Stacey <jp.stacey@...> wrote:
> 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.

No the reason TinyMCE isn't bundled with its bridge module isn't
because of incompatible licenses but Drupal policies on only allowing
GPL code in CVS.

TinyMCE has a GPL compatible license (LGPL), so there is nothing wrong
license wise with bundling up TinyMCE with a Drupal module and
distributing it from your own server as a combined work under the GPL.
The same is true with any other code with a GPL compatible license.

So although distributing a SMF bridge module (which sparked this
debate) appears to violate the GPL, distributing the TinyMCE bridge
module wouldn't.

--
Cheers
Anton

[Anton-34]

On 11/09/2007, Kevin Reynen <kreynen@...> wrote:
>
> The current Drupal CVS policy doesn't differentiate between GPL and non-GPL.
>  The current policy is no third party code.  As it's been explained to me,
> if users can get the code somewhere else, it doesn't belong in Drupal's CVS.
>
> Nedjo suggested some revisions to the CVS policy to make it easier for
> developers to include small javascript libraries back in March
> (http://drupal.org/node/124978), but AFAIK the policy is still no third
> party code... GPL compatible or otherwise.

The CVS handbook is explicit about only hosting GPL code:

http://drupal.org/node/66113
http://drupal.org/node/103704

and nothing in Nedjos forum thread seemed to indicate that was changing.

But that reinforces my point - it is Drupal policies (either no 3rd
party code or GPL only code - take your pick) keeping TinyMCE out of
cvs.drupal.org not any licensing violations. I chose to use the "GPL
only" policy to make my point as jQuery makes the "no 3rd party code"
policy a bit more open to exceptions.

--
Cheers
Anton

[Chris Johnson-21]

Having your web server serve the images as files off the filesystem
disk is almost guaranteed to be faster than serving them out of BLOBs
in a database.  Don't put them in the database, unless you really need
to, is a good general rule.

A database with 500,000 records with a decent primary key will be
plenty fast for everything else.

..chrisxj

On 9/10/07, Glenn Wybo <glennwybo@...> 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

[Chris Johnson-21]

On 9/8/07, Thomas Barregren <thomas@...> wrote:

> Chris Johnson skrev:
> > 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.
>
> You comment only proves that you in fact have not read the license.
> Please do that before you comment.
>
> Hint: § 3 of GPL v2.

No, actually I was well aware of the exception clause.  I've read GPL
v2 dozens of times, and the exception itself was mentioned earlier in
this very thread.  The point is, what sorts of uses constitute valid
exceptions and which do not.  Just what is a "major component?"  What
is an "operating system?"  You might be surprised just how various
courts in various countries might define those terms.

For instance, can a Mac OS X dashboard widget be GPL?  They depend on
more than just OS X -- they depend on an application program, which
many would not consider to be a "major component" of the operating
system.

That is, once again, what is a derivative work?  Paragraphs 2 and 3
are inadequate to define it.  A dozen different courts could interpret
it differently.  Until there is well-established case law, we just
don't know.

So instead the question becomes, at what point does it stop making
sense to split hairs?  Or, how much legal protection can we reasonably
afford to get?  It might be more than adequate to simply require
contrib authors to "sign" something that says they are aware of the
GPL restrictions and that they hold Drupal/Dries harmless.  Even
though such clauses often don't hold up by themselves, it might be
enough evidence to demonstrate that Drupal was making best efforts to
comply at all times with the law, and thus keep us out of serious
trouble.

[Darren Oh-2]

Then are you saying CiviCRM is wrong and that it is a license  
violation to distribute modules that allow Drupal to be combined with  
CiviCRM? A clarification of the claims you are making would be  
helpful. In a previous message I tried to sum them up:

1. You cannot use a GPL-incompatible license for an app designed to  
be used with Drupal or a Drupal module.

2. You cannot use the GPL for code designed to be used with a third-
party app unless a) you are allowed to combine your code with the  
third-party app and distribute the combined work under the GPL or b)  
you add an exception clause giving up claim 1.

Does this summary fairly represent what you are claiming? If not,  
please clarify it for the benefit of the rest of us.

On Sep 10, 2007, at 9:02 PM, Thomas Barregren wrote:

> Darren Oh skrev:
>> 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.
>
> No, it is not as simple as that.
>
> Suppose we develop a module that bridges Drupal with another  
> program. If that is accomplished by just "using" the program, that  
> is invoking the program's main function with some options and  
> waiting for it to return, for instance by using pipes, sockets or  
> command-line, then the module is not a derived work of the  
> application. But, if the module "know" things internal to the  
> program, that is the module links to the program, invokes functions  
> and shares data structures, then the module and the program, as a  
> whole, is a derived work of the program.
>
> Since the module and Drupal, as a whole, is a derived work of  
> Drupal, GPL requires that the whole combined program has to be  
> released under the GPL. That is why I think the license of the  
> other program must be compatible with GPL if (but only if) the  
> module "know things" internal to the program.
>
>> I know it's repetitive, but this discussion has been answering the  
>> wrong question.
> The really question, as I see it, is whether d.o. should continue  
> to expose itself for the risk of being challenged in court for  
> copyright infringement, or do something about modules that link to  
> third-party programs with licenses not compatible with GPL. I  
> suggest the latter. We can either follow J! and cease the  
> distribution of contaminated modules, or add a FOSS Exception,  
> Linked Under Controlled Interface Exception or something similar,  
> or both.
>
> I think I have said everything I can in this issue. So I should  
> really "rest my case" now. Seeing is believing. :-)
>
> Best regards,
> Thomas (IANAL)