Re: Re: LGPL License on Net_LDAP

On 8 Mar 2004 at 10:41, Alex Borges wrote: > Geeze, i almost feel sorry for bringing the problem forth. No > developer has fun having this discussion. > > Okay, here is the thing. The only interpretation of the php license I > CAN adhere to is the FSF one (doesnt matter if i agree with it or > not). And it says: > > > http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses > > > Its not compatible with pure GPL projects. It doesnt say why though, > but i guess its an BSD type advertising clause in it: > > " 6. Redistributions of any form whatsoever must retain the following > acknowledgment: > "This product includes PHP, freely available from > <http://www.php.net/>"" This is one point where I think the PHP license doesn't fit PEAR packages at all. We don't "include PHP". It's not a derived project like an "optimized php-compiler" or whatever. We're distributing source and do not *include* PHP. Well the language - but I really hope they do not claim posession of the language ... > and > " 4. Products derived from this software may not be called "PHP", > nor > may "PHP" appear in their name, without prior written permission > from group@php.net. You may indicate that your software works in > conjunction with PHP by saying "Foo for PHP" instead of calling > it "PHP Foo" or "phpfoo" " So we actually have a problem with e.g. "phpDocumentor"? That can't be true. For binary extensions I can understand that - or for something like "PHP-ng" that would be a real derived work from php. But there are so many sources out there which have php in their name. I've already discussed a similar topic with the people from phpMyAdmin a long time ago, phpDocumentor is a candidate for this clause, phpOpenTracker etc. as well ... So since this sentence is in the license and if it has to be taken as it is, then I'd personally strictly *not* use the PHP License for *any* PEAR packages. Does somebody know if these two points will be improved in the new license? Is there already a draft and a timeline maybe available? [...] > - Derivative works of the L/GPLD code (actually opening and > modifying it) are 'infected' L/GPL, but no files that include() or > require(), and indeed "extend" the NETLdap lib are have to be of > any other license than what their copyright holder wants (they can > be fully proprietary). That's how I'd also like the LGPL to be meant, yeah. But as long as people like Stallman interpret the license differently I guess we can't be sure about using GPL/LGPL for PEAR. What if some day "extending" a PEAR-class ("class a extends somePEARclass") inside a is commercial tool violates the licenses? Then we're all sued and sent to jail? This definitely has to be worked out further imho. > - Modifying the lib to include() or require() another, intended > proprietary lib, voids your right to use the LGPL'd library (as youd > have to put in the include() or require() to link it to non LGPL code, > thus modifying it). This does not happen with BSD or PHP licensed > code. An option for that case would be to modify the LGPL-lib in a general way so that you can e.g. supply it the name of a class it is supposed to work with (even your proprietary class) and offer (for free) that slightly modifed version of the lib again under the LGPL, right? Couldn't you also distribute the full source of that modified version under the LGPL together with your app? Then you wouldn't have a problem to "donate the the LGPL" your slightly modified version, and your proprietary extension could still remain under a different license. Just my thoughts. Please comment and keep this thread going! Regards, Stefan