Re: LGPL License on Net_LDAP

On 8 Mar 2004 at 22:04, Alan Knowles wrote: > Jan Wagner wrote: > > in mid february Lukas Smith contacted the developers of Net_LDAP > > about a license mismatch. On the PEAR website it was listed as GPL > > while the files contained the php license. This started a discussion > > about which license we should use for Net_LDAP. The php license > > seemed to be the one to go, but Alex Borges stated that this would > > break GPL programs which he develops. > > I'm not sure how that is the case.. - the linux kernel contains some > BSD licenced code (which is AFAIK pretty much the same as the PHP > licence. We've talked about some problems that exist with the current PHP- license lately ... it doesn't really fit the current needs of source- code-packages like the ones in PEAR fully unfortunately. But as I see it BSD or PHP-license are "quite open" for any way of using the code. If you're writing a tool that directly compiles against a (totally) open library this might, in my eyes, possibly be a problem. But since PHP is plain source and interpreted / compiled at runtime isn't this a similar case like executing an external program / shell-script / whatever from your GPL-program? You don't compile directly against it, just use it. Please note that I'm no right-expert either :-( > > As I use Net_LDAP in a closed source project we could not > > make it GPL. So all of us concluded on using the LGPL as it would > > fit all of us. Today I changed the headers in all files to state > > that new license and got contacted by Stefan Neufeind noticing that > > there are "quite criticical interpretations of LGPL around". As we > > are all not much into licenses maybe this could get discussed here? > > The 'intention' of the LGPL is to issolate libraries so thay may be > used without the infection clauses of GPL.. - but force additions and > modifications to be passed back to the author.. > > This tends to indicate an application using the methods and object > instances would tend to be OK.. however If you where being strict > about it, extending the class might be considered a derivative > work.... But afaik according to the interpretation of FSF, Richard Stallman LGPL is not really "free". Can't find a document on the internet about it at the moment, but I heared somewhere that he interpreted it like also libs released under the LGPL may in some cases not be used within propietary software - e.g. if you statically link against them or ship them with your package. However, this is not the basic intention of the LGPL - I agree. But it might result in problems using LGPL-code in propietary/commercial programs/tools. Since the PHP-license does not really seem to fit to PEAR packages at all at the moment I also thought about moving to LGPL. However on the list we've been told to "please wait for the next PHP license, that will come soon". I must admit that I'm a bit confused: Should we hold still and wait for something to happen? Or react and choose an appropriate, correct license? I'd appreciate to have a clearing, official and well-explained recommendation about licensing from pear- group or similar. Is here nobody who actually knows for sure about licenses? Regards, Stefan