On Fri, 2002-11-29 at 09:00, Stig S. Bakken wrote:
> On Thu, 2002-11-28 at 14:56, Edin Kadribasic wrote:
> > >As I mentioned in my other mail, I'm against banning GPL code. It
> > would
> > >be a very very bad sign to the Open Source Community if PEAR says
> > "GPL
> > >code is not allowed in here" (I can already hear the outcry, even
> > if most
> > >(99.9% :) ) of the packages will not be GPL or be changed to LGPL
> > if we
> > >ask the author gently).
> >
> > FSF sends a bad signal to opensource community by saying that Apache
> > and PHP licenses are non-GPL compatible, meaning linking against
> > them is not allowed. This means that PHP cannot use samba libraries
> > for instance.
>
> Taken from the GPL FAQ (http://www.gnu.org/copyleft/gpl-faq.html):
>
> If a programming language interpreter is released under the GPL, does
> that mean programs written to be interpreted by it must be under
> GPL-compatible licenses?
>
> When the interpreter just interprets a language, the answer is
> no. The interpreted program, to the interpreter, is just data; a
> free software license like the GPL, based on copyright law,
> cannot limit what data you use the interpreter on. You can run
> it on any data (interpreted program), any way you like, and
> there are no requirements about licensing that data to anyone.
>
> However, when the interpreter is extended to provide "bindings"
> to other facilities (often, but not necessarily, libraries), the
> interpreted program is effectively linked to the facilities it
> uses through these bindings. So if these facilities are released
> under the GPL, the interpreted program that uses them must be
> released in a GPL-compatible way. The JNI or Java Native
> Interface is an example of such a facility; libraries that are
> accessed in this way are linked dynamically with the Java
> programs that call them.
>
> Another similar and very common case is to provide libraries
> with the interpreter which are themselves interpreted. For
> instance, Perl comes with many Perl modules, and a Java
> implementation comes with many Java classes. These libraries and
> the programs that call them are always dynamically linked
> together.
>
> A consequence is that if you choose to use GPL'd Perl modules or
> Java classes in your program, you must release the program in a
> GPL-compatible way, regardless of the license used in the Perl
> or Java interpreter that the combined Perl or Java program will
> run on.
>
> This does not describe the scenario of a non-GPL-compatible program using
> GPL'ed
> libraries, but what I can read from this is that having GPL'ed modules in PEAR
> is asking for trouble.
>
> We can point fingers as much as we like to, but we can not have GPL'ed code
> in PEAR
> as long as the PHP license is not GPL-compatible.
Mmmh, CPAN has a lot of GPL modules, how do they handle this? Perl is
not GPL either, IIRC :)
What above scenario describes is (IMO), that if I write a PHP-program
and I use GPL PHP libraries, then my whole PHP-program has to be GPL, as
well, but not PHP itself. This seems quite logical to me.
The other problem I can see, what happens if I use the PEAR core modules
together with GPL modules.. I don't have a real answer to this, but this
looks lika a general problem, since there are a lot GPL
libraries/programs (written in PHP) out there.
What's certainly not possible is to link GPL libraries in
PHP-extensions, since this violates the GPL quite clearly, therefore in
PECL we can't have GPL stuff.
Anyway, I don't see a real problem and I still think, that we can
persuade every contributer, which looks to put something into PEAR, to
use a less problematic licence than GPL.
chregu
--
christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@xxxxxxxxxx | gnupg-keyid 0x5CE1DECB
--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
|
