On Nov 18, 2009, at 4:44 PM, Christian Hammers wrote:
Hello Curt
Am Tue, 17 Nov 2009 22:42:45 -0600
schrieb Curt Arnold <[email protected]>:
Running "mvn rat:check" generates a RAT (release audit tool) report
in target/rat.txt. The check fails since all the .php files in src/
examples/php and src/examples/resources do not have ASF Source
Header. src/examples/README.LICENSE explains a rationale, however
unless there has already been some determination on this, I would
raise this as an issue on the IPMC vote and think there is likely
that the IPMC would push back on the issue.
There is some thing relevant on this page:
http://www.apache.org/legal/src-headers.html
What files in an Apache release do not require a license
header?
A file without any degree of creativity in either its literal
elements or its structure is not protected by copyright law;
therefore, such a file does not require a license header. If in
doubt about the extent of the file's creativity, add the
license header to the file.
I mean, thinking about it, we should "claim rights" on a php script
that
does not do more than logging "hello world".
Maybe some of the 1-3 lines of code snippets could be argued to have
no degree of creativity, but src/examples/simplesocketserver.php is 55
lines of non-trivial code.
(And if it need that level of creativity for even the simplest usage
of
our library we should certainly rethink our API *g*)
Not only that, by using it as an example, we encourage the user to
incorporate this snippet in his own source code which legally means
that we were then partially owner of the copyright of *his* source
code!
(And not only copyright owner of a separated library as we are now)
Ah, but we offer it under a very generous license. The header just
makes that license explicit. I don't think it makes makes the source
code either more or less "copyrighted" than the implied copyright of
the original author who licensed it to the ASF either under a CLA or
the contribution clause of the ASL. However, any significant
discussion on these points should happen either on [email protected]
or [email protected].
The examples are used with the @example phpdoc directive, so any ASF
header in the example body would be incorporated literally into the
generated documentation (as far as I can tell). So pointing the
phpdoc at the .php snippets with ASF license headers would not
generate pretty output. You could however point phpdoc at a
directory (target/examples) that was generated from the source
removing the ASF license using xslt or other processor. I can take a
shot at that.
Maybe we can just rename them from .php to .snippet to make RAT happy?
Actually, I don't think that RAT would be affected by that.
Else, if you have the time for it, that would indeed be great. If
not I
would risk bringing this issue up on the IPMC and if it gets rejected
just cut & paste into the phpdoc as well as into the .apt files.
The API is rock solid and with the low development on log4j will
probably stay that way anytime soon and if we have 1-2 bugs in the
examples than let it be that way and users can file a bug for it.
Did you intend to say "log4j"? If so, how is that relevant.
Since the generated docs could depend on the version of phpdoc
installed, I think it would be good to disclose the environment that
is used to build the release packages. Ideally a clean fresh
installed OS on an VM with just the minimum installed packages.
I'm not sure how you mean that (writing the version numbers to a
README or Wiki or somehow specifying it in maven?) but Christian G.
seems already to have a plan :)
bye,
-christian-
A log4j distribution has a lot more binary artifacts than I'd expect
log4php to have, so it is more beneficial to know the build
environment in case you want to check that it can be reproduced or to
create a bug release version that is as close as possible to the
original. https://svn.apache.org/repos/asf/logging/log4j/trunk/BUILD-INFO.txt
is a little dated example from log4j. Since log4php has fewer and
less critical generated artifacts, just having some disclosure on the
next release candidate email that it was built on Example OS 17.3
using Maven 2.x and PHPDoc x.x would be enough to allow someone else
to reproduce it nearly identically except for pesky timestamps and the
like.
