Justin Patrin wrote:
> On 12/14/06, Sylvain Beucler <[email protected]> wrote:
>> On Thu, Dec 14, 2006 at 01:05:57PM -0800, Justin Patrin wrote:
>> > On 12/14/06, Sylvain Beucler <[email protected]> wrote:
>> > >On Thu, Dec 14, 2006 at 12:40:05PM -0800, Justin Patrin wrote:
>> > >> On 12/14/06, Sylvain Beucler <[email protected]> wrote:
>> > >> >On Thu, Dec 14, 2006 at 11:39:28AM -0800, Justin Patrin wrote:
>> > >> >> On 12/14/06, Sylvain Beucler <[email protected]> wrote:
>> > >> >> >On Thu, Dec 14, 2006 at 11:54:48AM +0100, Christian Weiske
>> wrote:
>> > >> >> >> Sylvain,
>> > >> >> >>
>> > >> >> >> > Currently I'm a bit unsure about whether I can or
>> > >> >> >> > cannot use
>> > >> >packages
>> > >> >> >> > under the PHP license in my application.
>> > >> >> >>
>> > >> >> >> You can use the packages without problems in your
>> > >> >> >> application,
>> > >since
>> > >> >GPL
>> > >> >> >> is more strict than the PHP license is. The other way round
>> would
>> > >not
>> > >> >> >work.
>> > >> >> >
>> > >> >> >Hi,
>> > >> >> >
>> > >> >> >I don't think so.
>> > >> >> >
>> > >> >> >I think both licenses have requirements, but the PHP License
>> > >> >> >requirements are not a subset of the requirements of the GPL.
>> This is
>> > >> >> >independant to whether the GPL has more or less requirements
>> than the
>> > >> >> >PHP License.
>> > >> >> >
>> > >> >> >This extra requirements of the PHP License are related to the
>> use of
>> > >> >> >the name 'PHP'. This is not in the GPL, so licenses
>> > >> >> >are
>> incompatible
>> > >> >> >IMHO.
>> > >> >> >
>> > >> >>
>> > >> >> So? I honestly don't see what the problem here is. Just
>> > >> >> don't
>> use the
>> > >> >> name "PHP" in the name of your project. That clause
>> > >> >> doesn't
>> kick in
>> > >> >> and you have no problems.
>> > >> >
>> > >> >IMO this requirement will nonetheless still apply to the
>> combined work
>> > >> >(my proj + pear package). Since I cannot add additional
>> requirements
>> > >> >to a GPL'd app, then I'm violating the GPL.
>> > >> >
>> > >> >I didn't invent that, you can check the links I mentioned - among
>> > >> >others this one:
>> > >> >http://gplv3.fsf.org/wiki/index.php/PHP_license%2C_version_3.01
>> > >> >
>> > >> >
>> > >> >> >The modified BSD's requirements are a subset of the GPL, so
>> > >> >> >both
>> > >> >> >licenses are compatible.
>> > >> >> >
>> > >> >> >
>> > >> >> >Incompatible means I cannot combine the two kinds of work.
>> > >> >> >You can use GPL'd code with (compatible) mBSD'd code -
>> > >> >> >the
>> resulting
>> > >> >> >work will be under the GPL, be it in one way or another.
>> > >> >> >But you cannot legally combine GPL'd code with incompatible
>> > >> >> >code
>> > >> >> >(hence why incompatible licenses are referenced at
>> > >> >>
>> >
>> >>http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses).
>> > >> >> >
>> > >> >> >This link has some more information about it:
>> > >> >> >http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible
>> > >> >> >
>> > >> >> >
>> > >> >> >All in all, I don't think I can't legally use
>> > >> >> >HTML_QuickForm in
>> > >Savane
>> > >> >> >:/
>> > >> >> >
>> > >> >>
>> > >> >> I think you're confusing 2 issues here. The licenses have 2
>> different
>> > >> >> use-cases.
>> > >> >> 1) You link/use some code from something in your application.
>> > >> >> 2) You modify or directly incorporate some code from something
>> in your
>> > >> >> application.
>> > >> >>
>> > >> >> If you do 2) with incompatible licenses you're SOL. You
>> > >> >> can't
>> do that.
>> > >> >>
>> > >> >> However, if you do 1) with "so-called" incompatible
>> > >> >> licenses
>> you're
>> > >> >> ok. For example, all PEAR libraries are licensed with licenses
>> such
>> > >> >> that you can "link" them to closed source applications
>> > >> >> without
>> > >> >> licensing your application under the same license. This is
>> exactly
>> > >> >> what the LGPL is for and this is why we don't accept GPL or
>> > >> >> other
>> > >> >> licenses than what we have listed.
>> > >> >>
>> > >> >> Summary:
>> > >> >> require_once 'HTML/QuickForm.php';
>> > >> >> is perfectly valid in your application, whatever license you
>> put to
>> > >> >> your code, be it GPL, LGPL, PHP, closed/commercial, or
>> OpenSSL. This
>> > >> >> constitutes linking another package's code into yours, not
>> modifying
>> > >> >> it.
>> > >> >
>> > >> >I don't think so. When I combine 2 pieces of code, even if I
>> just link
>> > >> >them (or include()) them, this is still a derived work, and license
>> > >> >compatibility still apply.
>> > >> >
>> > >> >If I could combine incompatible license just because I don't modify
>> > >> >the 'inside' of the code, then I could use a GPL'd library
>> > >> >even in
>> > >> >proprietary software. The LGPL is specially written to allow such
>> > >> >external linking - that would not be necessary if linking were
>> legally
>> > >> >possible without explicit permission.
>> > >> >
>> > >> >Linking = derived version
>> > >> >
>> > >> >
>> > >> >I don't know why the FSF would write an OpenSSL replacement
>> > >> >(http://www.gnu.org/software/gnutls/), and why Debian would deem
>> > >> >GPL+OpenSSL not legally distributable
>> > >> >(http://ftp-master.debian.org/REJECT-FAQ.html) if I could freely
>> link
>> > >> >with OpenSSL.
>> > >> >
>> > >> >This pages explains the problem pretty well:
>> > >> >http://www.gnome.org/~markmc/openssl-and-the-gpl.html
>> > >> >
>> > >> >The series of questions about GPL'd plug-ins offers some
>> explanations
>> > >> >on the distinction between linking and fork+exec (which is not
>> > >> >affected by license compatibilities):
>> > >> >http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
>> > >> >
>> > >> >
>> > >> >Therefore I cannot use PEAR packages under the PHP license in a
>> GPL'd
>> > >> >app because the two licenses are incompatible due to details (not
>> > >> >major differences), and currently this prevents me from using these
>> > >> >packages. I do think that using the modified BSD instead, which
>> is not
>> > >> >hard and changes nothing from PEAR developers' point of view, would
>> > >> >make the situation cleaner.
>> > >> >
>> > >> >
>> > >> >I'll add a bit of background about me: I'm doing basic legal
>> checks on
>> > >> >a regular basis for a couple years now, for new projects that are
>> > >> >submitted at Savannah.gnu.org. Every incoming project is checked
>> for
>> > >> >such issues. I think that I had to cope with license
>> incompatibilies
>> > >> >often enough to grasp the basics, and I had to discuss with
>> > >> >[email protected] several times to make decisions in corner
>> cases. I'm
>> > >> >still not a lawyer, but if I take the time to bug you about it,
>> this
>> > >> >means I am pretty sure there's an issue.
>> > >> >
>> > >> >This was already discussed following such a project submission
>> review:
>> > >> >http://www.zend.com/lists/pear-dev/200410/msg00039.html
>> > >> >
>> > >> >It was acknowledged that there was an issue, and the proposed
>> solution
>> > >> >was to add an exception to the GPL'd code - which I can't in
>> > >> >this
>> > >> >case, because I'm not the copyright holder, and also because that
>> > >> >would make my code incompatible with other GPL'd libs (that
>> > >> >doesn't
>> > >> >come with such an exception).
>> > >> >
>> > >> >
>> > >> >I don't think I'm proposing something radically different than
>> what is
>> > >> >currently done, so please take a bit of time to consider it.
>> > >> >
>> > >>
>> > >> Please see http://pear.php.net/manual/en/faq.licenses.php.
>> > >> If the
>> > >> statements here are false then there is a problem.
>> > >
>> > >
>> > >Hi,
>> > >
>> > >I had read it. I don't see statements related to compatibility with
>> > >the GPL.
>> > >
>> > >There's one false statement: "The only limitation is that the original
>> > >credits must stay in the sources". This is more or less true for mBSD,
>> > >but not for the PHP license which adds other limitations as discussed.
>> > >
>> >
>> > If this is the only false statement then PHP licensed packages should
>> > be linkable from any open or closed source product, as the page says.
>> >
>> > >Can you return the favor and read my statements as well?
>> > >
>> >
>> > I of course read your statements but I think we're working under
>> > different assumptions here. I am assuming that the PHP license allows
>> > linking. You are assuming either that it does not or that the
>> > "compatibility" somehow negates this allowance for linking.
>>
>> The PHP License allows linking, but to link 2 pieces of software, both
>> need to allow linking. To make it short, the GPL doesn't allow linking
>> with incompatible code. Therefore I cannot link PHPL'd and GPL'd code.
>>
>
> Would someone in the PEAR group or that helped to choose the PHP
> License as an ok license care to weigh in on this? If this, indeed,
> true, then we should probably remove the PHP License as an ok license
> and have any package that is PHP Licensed re-licensed with something
> else.
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.
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. 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. 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.
In short, I don't see an issue here. Move along.
-Rasmus
