interpreted language specific open source license ?

[Herko Coomans]

If a program released under the GPL uses plug-ins, what are the 
requirements for the licenses of a plug-in.
     It depends on how the program invokes its plug-ins. If the program 
uses fork and exec to invoke plug-ins, then the plug-ins are separate 
programs, so the license for the main program makes no requirements for 
them.

     If the program dynamically links plug-ins, and they make function 
calls to each other and share data structures, we believe they form a 
single program, which must be treated as an extension of both the main 
program and the plug-ins. This means the plug-ins must be released under 
the GPL or a GPL-compatible free software license, and that the terms of 
the GPL must be followed when those plug-ins are distributed.

     If the program dynamically links plug-ins, but the communication 
between them is limited to invoking the `main' function of the plug-in 
with some options and waiting for it to return, that is a borderline case.

(source: http://www.gnu.org/licenses/gpl-faq.html#TOCGPLAndPlugins)

XOOPS' PHP modules could be considered plugins. This FAQ entry explains 
some of the possibilities, but does not address the interpreted laguage 
use of 'plugins'. This is where GNU.org mentions the dynamic linking.

Herko Coomans
XOOPS.org Project Manager
Chairman of the XOOPS Foundation

[e] herko at xoops.org
[w] http://www.xoops.org
[a] P.O.Box 75, 7400 AB, Deventer, The Netherlands
[t] +31 64 833 64 34
[f] +31 84 747 05 50

XOOPS: Open Source dynamic web Content Management System

The information sent by means of this e-mail message is intended only 
for the use of the addressee. Publication, duplication, distribution 
and/or forwarding to third parties of this message, as well as use of 
the information by other persons than the intended recipient, is 
strictly prohibited. If you have received this communication in error, 
please notify the sender immediately by returning it.

Matthew Garrett wrote:
> On Fri, 2005-03-04 at 13:11 +0100, Herko Coomans wrote:
> 
> 
>>The problem we have is this: XOOPS is released under the GNU GPL 2.0 
>>license. XOOPS is object oriented and modular, meaning the core provides 
>>many methods for modules to use (membership management, ACL, rendering, 
>>caching etc.). Recently we've had some discussion on when a module is to 
>>be considered 'part of the whole program', and therefore licensed under 
>>the GPL as well. Some people say that as long as it doesn't include any 
>>of the GPL code *in the release*, it's ok. We say that this is not true, 
>>and that our interpretation is that if the module *depends* on the GPL 
>>code to function as intended, then it cannot be run standalone without 
>>the GPL code, and should be considered as part of the whole program. The 
>>GPL itself talks about dynamic library linking or something like that 
>>(I'm not a developer), but this is geared towards compiled languages, 
>>where the availability of the source code is not as default as it is 
>>with interpreted languages like PHP.
> 
> 
> The GPL doesn't mention dependencies or dynamic linking or anything like
> that - it mentions derived works. If you want to know whether a module
> is a derived work of the core code or not, you're likely to need to
> consult a lawyer (though the FSF will give you their opinion if you ask
> them).
> 
> 
>>Does anyone know of a good open source license geared towards 
>>interpreted languages like php scripts? Or is the GPL clear enough on 
>>this issue and have I missed something completely?
> 
> 
> That depends entirely on what you want the license to cover. It's
> difficult for you to produce something that will cover things that
> aren't derived works and still have it considered an open source
> license. OSD 9 could be argued to prohibit it.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: herko.vcf
Type: text/x-vcard
Size: 339 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20050304/6be5e377/attachment.vcf>