Re: Contributing code

From: Date: Fri, 29 Nov 2002 10:06:32 +0000
Subject: Re: Contributing code
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-11248@lists.php.net to get a copy of this message
On Fri, 2002-11-29 at 09:54, Christian Stocker wrote: > 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. Perl's licenses are GPL-compatible, while the PHP License is not. Therein lies the problem. If you load GPL'ed code into PHP, you are, as far as I can understand from the quote above, violating the GPL. I'll send RMS a mail about it to try clarifying. - Stig

« previous php.pear.dev (#11248) next »