At 07:38 PM 7/20/99 +0200, Gergely Madarasz wrote:
On Tue, 20 Jul 1999, Zeev Suraski wrote:
> At 05:37 PM 7/20/99 +0200, Sascha Schumann wrote:
> >There are some concerns expressed in the slashdot discussion
> >forum about the new license scheme.
> >
> >One AC writes
> >
> >---------------------------------------------------------------
> >I'm using PHP3 (and liking it very much), and some of the new
> >PHP4 OO features sound very nice and really useful. But unless
> >PHP4 may also be used under the terms of the traditional GNU GPL,
> >I can no longer use GDBM with PHP (which I also do a lot).
> >---------------------------------------------------------------
> >
> >GDBM is licensed under GPL, so it might be the case that linking
> >with non-GPL code (such as PHP4) is prohibited (that's what the
> >LGPL license is for).
> >
> >Which other extensions libraries are licensed under GPL?
>
> Hmm, I think that's completely baseless. Cygnus's GNU stuff doesn't link
> at runtime with KERNEL32.DLL? KERNEL32.DLL isn't opensource and
definitely
> isn't GPL'd.
GPL makes exception for system libraries.
That's not the issue at all.
We're not, and never have distributed GDBM. We have distributed other GNU
software with PHP 3.0, and we no longer do it with PHP 4.0, but instead
point people at separate packages.
What you're saying is that you may not use GPL'd software in conjunction
with non GPL software, from a user's standpoint. That's completely absurd
in my opinion. The user may not link GPL'd software with non GPL'd
software at his own discretion?
I can think of many examples that prove you're wrong here. For example,
MySQL, that isn't GPL'd, makes use of the readline library which is
GPL'd. It's not a system library either. I'm sure you can find plenty of
other examples; The key issue with GPLd software is that you may not embed
it within non GPL'd software you're distributing; It doesn't mean your
software can't be compatible with it and optionally support it.
> That post made no sense at all to me. I'm not blaming that guy, since
> understanding OS licenses is really difficult, but all the same, I'm
pretty
> sure he's wrong.
>
> He can link GDBM with PHP just as he can link the BC math library and any
> other GPL'd software just fine; The only thing *we* can't do is
distribute
> PHP with those packages bundled. That has nothing to do with Zend's
QPL by
> the way, it's like that because PHP itself is no longer GPL'd.
That means that it won't be possible to include PHP4 in linux
distributions, like Debian. Or at least, not linked against gdbm. Actually
that isn't that bad, I wanted to get rid of this gdbm dependency in the
.debs for quite a while since it is deprecated :) But this doesn't make it
a non-issue.
The QPL is Debian and opensource.org compliant. The PHP license is roughly
as non-restrictive as you can get, thus, I see no reason for any of the
Linux vendors to raise any concerns about it.
The clause that allows the PHP Group to change the license as long as it
stays open source is necessary, and no, it's not retroactive (it can't be,
really). It's necessary because otherwise, it would mean that we would
have to go and ask every single person who've contributed a single line of
code to the PHP repository every time we want to make even the slightest
modification. Essentially, what this clause means is that the power to
control license changes is centralized at the PHP Group, instead of being
spread across dozens of developers.
Zeev
