[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PHP4BETA] License concerns

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
Reply to: