The PHP license states the following:
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"
As the author of something released under the PHP license, can I, as I
see fit, just grant permission to an application using PHP in its name?
Alternatively, could I maybe have two different versions of the
package in question - one licensed under the PHP license and one
licensed under the GPL license?
Also, say I were wanting to make a certain package a part of PEAR and I
wanted it to be released under the GPL license and not the PHP license.
How would I need to update the header comment block to reflect this?
The sample header block given reads like this:
* LICENSE: This source file is subject to version 3.0 of the PHP
license
* that is available through the world-wide-web at the following URI:
* http://www.php.net/license/3_0.txt. If you did not receive a copy of
* the PHP License and are unable to obtain it through the web, please
* send a note to license@php.net so we can mail you a copy immediately.
Further, one of the required lines in the PEAR header is as follows:
* @author Original Author <author@example .com>
Do email addresses have to be included?
Also, say I have a PEAR account. How do I start submitting new
packages?
Regarding the naming conventions of functions... the PEAR manual says
that they ought to use the "studly caps" convention. What about for
something like base256_lshift or bytes2int, though? For those function
names, using the "studly caps" convention seems like it'd almost hinder
readability...
Regarding constants... the sample file suggests that comments ought to
be done like this:
// {{{ constants
/**
* Methods return this if they succeed
*/
define('NET_SAM PLE_OK', 1);
What if, however, there are multiple constants? Does each one need to
be preceeded by a comment or can they sorta be grouped together?
Further, what if the constants are chiefly intended to be used by
"private" functions (as indicated by their being preceeded with a _)?
Are comments still needed? Or should "private" functions not even use
constants? Personally, I think they ought to as using constants can
help one follow through the code. What's the PEAR Groups stance on
this?
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"
As the author of something released under the PHP license, can I, as I
see fit, just grant permission to an application using PHP in its name?
Alternatively, could I maybe have two different versions of the
package in question - one licensed under the PHP license and one
licensed under the GPL license?
Also, say I were wanting to make a certain package a part of PEAR and I
wanted it to be released under the GPL license and not the PHP license.
How would I need to update the header comment block to reflect this?
The sample header block given reads like this:
* LICENSE: This source file is subject to version 3.0 of the PHP
license
* that is available through the world-wide-web at the following URI:
* http://www.php.net/license/3_0.txt. If you did not receive a copy of
* the PHP License and are unable to obtain it through the web, please
* send a note to license@php.net so we can mail you a copy immediately.
Further, one of the required lines in the PEAR header is as follows:
* @author Original Author <author@example .com>
Do email addresses have to be included?
Also, say I have a PEAR account. How do I start submitting new
packages?
Regarding the naming conventions of functions... the PEAR manual says
that they ought to use the "studly caps" convention. What about for
something like base256_lshift or bytes2int, though? For those function
names, using the "studly caps" convention seems like it'd almost hinder
readability...
Regarding constants... the sample file suggests that comments ought to
be done like this:
// {{{ constants
/**
* Methods return this if they succeed
*/
define('NET_SAM PLE_OK', 1);
What if, however, there are multiple constants? Does each one need to
be preceeded by a comment or can they sorta be grouped together?
Further, what if the constants are chiefly intended to be used by
"private" functions (as indicated by their being preceeded with a _)?
Are comments still needed? Or should "private" functions not even use
constants? Personally, I think they ought to as using constants can
help one follow through the code. What's the PEAR Groups stance on
this?
Comment