On Oct 31, 2005, at 1:06 PM, Rick Hillegas wrote:
I think that a reasonable first-time contributor could be confused
by Apache's rules for including copyright notices (http://
www.apache.org/dev/apply-license.html#new).
Agreed. This is perhaps intentionally vague? I guess it's best to err
on the side of caution and include it if there doubt. Coincidentally,
I thought about this the other day as well. But instead of launching
into an analysis of the different kinds of non-java source files in
the tree, I thought I would instead examine how other Apache projects
handle this.
So what constitutes source and documentation? We don't seem to
include copyright notices in:
o Localized message files. These really look like a kind of source
code to me.
I had a hard time finding examples with which to compare. I found one
places where properties files were used and these did not have the
boilerplate. Another used ResourceBundles for localized messages,
which, being .java files, had the boilerplate.
o Other properties files used to control configurations and tests.
In almost every .properties file I looked at while searching, the ASL
boilerplate was absent. There were a few exceptions, notably lenya
and geronimo.
o Ant build scripts.
For build files, the boilerplate was always absent, and this applies
to maven-related files as well, and configure.in for C-based projects.
o Documentation on how to build and test Derby.
While this obviously qualifies as documentation, not a single project
I checked included the boilerplate in build or test related
documentation.
Where do we state our rules about which files require copyright
notices?
We don't. We follow the Apache guidelines you linked in your original
mail. ;-)
Is this the implicit rule:
o Only files with the extension "java" require copyright notices.
Despite the fact that this excludes certain files which should
probably be considered source code (e.g. metadata.properties) and
files that are generated but without which the Derby will not
function (e.g. DBMS.properties), this seems to be the rule currently
in use.
So, my suggestion is to continue doing what we've been doing: attach
the boilerplate to .java files and leave it off of other files. If
there is a problem with that course of action, someone will
(hopefully sooner, rather than later) let us know.
andrew
