Re: Re-Releasing PEAR packages under the BSD license

Hi, > 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 "linked to" from > Apache either. Components released under the Apache license are also incompatible with the GNU GPLv2 :/ > See http://www.apache.org/licenses/LICENSE-1.1 > > The PHP license was chosen to match the Apache license because Apache > and PHP are tied so closely to each other. > > 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. "Mere aggregation" means putting 2 apps side-by-side on a medium - i.e. one doesn't rely on the other. When one application use a library, then this is derivation. I am pretty sure that using a package in a PHP application, PEAR or not, is just not a "mere aggregation". > 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. > > The FSF has a FAQ on aggregation here: > > > http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation > > That text is heavily biased towards compiled software and they talk > about executables and memory spaces which don't really apply in this > case. The FAQ is indeed pretty clear about it: "Combining two modules means connecting them together so that they form a single larger program." - i.e. include('mypackage.php'). In the case of PHP we're in the case described as "If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program." The rest of the FAQ explains why, by contrast, fork&exec is not considered derivative, and this certainly does not apply to using a PEAR package. > 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. It _is_ true, but the GPL explicitely grants an exception so it doesn't extend to the underlying OS or programming language ("anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs"). This permits writing GPL'd code running under MS Windows only, e.g. Incidentally, this is a clause OpenSSL claims to fall under: http://www.openssl.org/support/faq.html#LEGAL2 "2. Can I use OpenSSL with GPL software? On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution)." (although the fact OpenSSL is "normally" included in distributions is subject to controversy) > In short, I don't see an issue here. Move along. I think that there is an issue, admittedly not obvious, but that, using PHP professionally, I care about. Whether you agree or not, in any case, I still think it would clarify the situation to re-release PHPL'd packages under the modified BSD. -- Sylvain