Re: Contributing code
| From: | Roman Neuhauser | Date: | Tue, 03 Dec 2002 19:20:20 +0000 |
| Subject: | Re: Contributing code | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-11330@lists.php.net to get a copy of this message | ||
# ssb@fast.no / 2002-11-29 09:00:51 +0100:
> 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.
> 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.
As I read this, nothing new is said.
As long as you GPL all your programs that use (hypothetical) GPL'd
classes from PEAR, you're ok. You must either stay away from GPL'd
code, or let it plague your code. You can use code released under
BSD-style licenses in GPL'd programs without restrictions, the
opposite is not true.
Obviously, keeping PEAR free of GPL makes it clear that the code is
free (pun intended); the user doesn't have to comb through the
available classes.
Conclusion: GPL'd code (in PEAR) is/would be a PITA, but that's it.
--
If you cc me or remove the list(s) completely I'll most likely ignore
your message. see http://www.eyrie.org./~eagle/faqs/questions.html