cvs: peardoc /en/chapters/faq devs.xml

mj Sat Dec 16 11:40:19 2006 UTC Modified files: /peardoc/en/chapters/faq devs.xml Log: * Added Rasmus' stance with regard to linking PEAR packages into GPL'ed code # Bug #9630 http://cvs.php.net/viewvc.cgi/peardoc/en/chapters/faq/devs.xml?r1=1.2&r2=1.3&diff_format=u Index: peardoc/en/chapters/faq/devs.xml diff -u peardoc/en/chapters/faq/devs.xml:1.2 peardoc/en/chapters/faq/devs.xml:1.3 --- peardoc/en/chapters/faq/devs.xml:1.2 Tue Dec 12 12:39:35 2006 +++ peardoc/en/chapters/faq/devs.xml Sat Dec 16 11:40:19 2006 @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="utf-8"?> -<!-- $Revision: 1.2 $ --> +<!-- $Revision: 1.3 $ --> <sect1 id="faq.devs"> <title>Developer FAQ</title> @@ -294,6 +294,56 @@ requires that all changes to the source code must be licensed under the LGPL to anyone the source is distributed to. </para> + <para> + From time to time people raise concerns of using PEAR packages + licensed under the PHP license in GPL'ed code. In a discussion + about this topic, the creator of PHP, Rasmus Lerdorf, issued the + <ulink url="&url.faq.licenses.rasmus;">following statement</ulink>: + </para> + <blockquote> + <para> + It all comes down to semantics of what linking means. The PHP + license is pretty much identical to the Apache license and you + could indeed make a case for not allowing any GPL'ed software to + be &quot;linked to&quot; from Apache either. + </para> + <para> + See <ulink + url="&url.faq.licenses.apache1;">&url.faq.licenses.apache1;</ulink>. + </para> + <para> + The PHP license was chosen to match the Apache license because + Apache and PHP are tied so closely to each other. + </para> + <para> + This hair splitting over linking, derivation and aggregation has + been going on since the beginning of time. My stance is that you + can indeed ship PHP licensed PEAR components on the same cd or in + the same tarball as GPL'ed code because I see it as an aggregate + work. This changes if you take PEAR code, modify it and + copy-paste it directly into your own work. Then it moves from + aggregate to derived. But the intent of the PEAR components is + to be used in aggregate form. The PHP license allows you to use + it in derived form as well, of course, but then you should be + choosing a license other than the GPL for the derived work. + </para> + <para> + The FSF has a FAQ on aggregation here: <ulink + url="&url.faq.licenses.fsf;">&url.faq.licenses.fsf;</ulink> + </para> + <para> + That text is heavily biased towards compiled software and they + talk about executables and memory spaces which don't really apply + in this case. If you don't consider using a PEAR component as + aggregation then it logically follows that you also cannot have + Apache call your code so you will have to stipulate that nobody + can use your code from Apache. I think this is an extreme + interpretation that pretty much nobody out there shares. + </para> + <para> + In short, I don't see an issue here. Move along. + </para> + </blockquote> <para> For PECL extensions that are linked into PHP, the license must be compatible with the PHP license. That means you can not GPL