Re: Contributing code

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@bitflux.ch | gnupg-keyid 0x5CE1DECB