Re: Contributing code
| From: | Stig S. Bakken | Date: | Fri, 29 Nov 2002 08:00:51 +0000 |
| Subject: | Re: Contributing code | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-11244@lists.php.net to get a copy of this message | ||
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.
- Stig