Licensing

Hi, the way I understand PEAR and interpret it's definition in the PEAR manual is that its purpose is to add to what PHP can already do. This obviously requires that the same userbase can make use of these packages and therefore the license of PEAR packages must be atleast "similar" to that of PHP. Licenses that force people to make their code opensource as well if they use a certain package (commercial or non-commercial) therefore don't have a place in PEAR imho. Furthermore the idea is the build upon existing packages and this can result in quite a confusing set of licenses that need to be followed (btw: it might be a good idea to have the installer note which licenses will need to be followed for a certain package). At the same time the idea is to have people contribute to existing classes. From my understanding licenses like the PHP license or LPGL provide the best trade offs. They allow people to use the package in their project without forcing them to open up their code, but at the same time ensure the author that he will see contributions' coming back if anyone extends the packages (this is definitely the case for the LGPL ..dunno exactly about the PHP license). A license such as the BSD license would also be appropriate, although there we must be aware of the danger of people not contributing back. I don’t know the QPL all that well, but if Richy's explanation is correct (the one given in the thread that turned into a jpgraph licensing thread) it looks to me to be even "worse" for PEAR packages than GPL: it’s a GPL in disguise! I am quite sure that most of the PEAR code being contributed is from commercial developers, so its important to not turn these people off from PEAR. Regards, Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de