Re: Re-Releasing PEAR packages under the BSD license
| From: | Sylvain Beucler | Date: | Thu, 14 Dec 2006 20:32:35 +0000 |
| Subject: | Re: Re-Releasing PEAR packages under the BSD license | ||
| References: | 1 2 3 4 5 6 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-45234@lists.php.net to get a copy of this message | ||
On Thu, Dec 14, 2006 at 11:39:28AM -0800, Justin Patrin wrote:
> On 12/14/06, Sylvain Beucler <beuc@beuc.net> 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
licensing@fsf.org 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.
--
Sylvain