ASL

[Rick Hillegas <Ri...@Sun.COM>]

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). Apache advises us to 
include a short copyright notice in "each source file (code and 
documentation) but excluding the LICENSE and NOTICE files)". The 
definition of source and documentation is a little vague although it 
seems to include LICENSE and NOTICE files which are immediately and 
happily excluded.

So what constitutes source and documentation? A reasonable person might 
suppose these terms to include every file under various subversion roots 
including https://svn.apache.org/repos/asf/db/derby/code/trunk and 
https://svn.apache.org/repos/asf/db/derby/docs/trunk. But a quick glance 
at our source tree indicates that this is not what we intend. We don't 
seem to include copyright notices in:

o Localized message files. These really look like a kind of source code 
to me.

o Other properties files used to control configurations and tests.

o Ant build scripts.

o Documentation on how to build and test Derby.

Where do we state our rules about which files require copyright notices? 
Is this the implicit rule:

o Only files with the extension "java" require copyright notices.

Or should a first-time contributor apply some other implicit rules:

o When creating a new subversion controlled file, first look for an 
existing file with the same extension. If the existing file you picked 
has a copyright notice, then include a copyright notice in your new file.

o If your new file has a completely novel extension and there's no 
corresponding file under source control, then do what seems reasonable 
to you.

Re: ASL boilerplate on source

[Andrew McIntyre <mc...@gmail.com>]

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