Dieter Wimberger wrote:
Richard, Felix:
I think that the ICLA I signed and sent to the Apache Foundation
Secretary cleary states the legal terms of the contribution.
Given paragraph 2. Grant of Copyright License, I am granting the
Apache Foundation and all recipients of the software distributed by
the Foundation an irrevocable right to reproduce, prepare derivative
works of, publicly display, publicly perform, sublicense, and
distribute the contribution.
In legal terms, to my understanding, I will still be owner of my
original contribution and can do as I please with it (e.g. grant
another license).
Now, given that the contribution is mainly code, I would simply
suggest that my @author tag in the javadoc of the corresponding files
and derivatives is retained. The code and especially derivatives
should actually be placed under Apache License and ASF copyright; I
guess this is also what you do with the committers code contributions,
or?
I was told that at Apache we don't keep @author tags in the code, since
the code belongs to the community. There are also pragmatic issues with
this, since there are often lots of authors and over time the original
code can be removed and/or replaced, so it is somewhat difficult to
maintain.
From a maintenance standpoint alone, I would like to avoid @author tags.
Beside the code, I think a list of contributors and committers seems
to be the best way to give credits; this is also the way it has been
done in other Apache projects I have contributed to.
To give an example, the commons-collections project seems to keep
their developers (= comitters) and contributors in the POM file, using
a section like:
<developers>
...
<developer>
<id>fmeschbe</id>
<name>Felix Meschberger</name>
</developer>
...
</developers>
<contributors>
...
<contributor>
<name>Dieter Wimberger</name>
</contributor>
...
</contributors>
Probably this is the best way to handle this in the right place and be
able to generate something from it (opposed to an unstructured NOTICE
text file).
I agree that something like this would be a preferred approach.
-> richard
Regards,
Dieter
On 20 Aug 2008, at 09:21, Richard S. Hall wrote:
Felix Meschberger wrote:
Hi,
Richard S. Hall schrieb:
Regarding the NOTICE file, I don't think we want the "originally
developed" stuff in there. That was the whole point of the IP
clearance, so that this can be claimed to be Apache software. To
acknowledge Deiter, we should use one of the other approaches that
I mentioned in my other email message.
In other projects we also have this "originally developed" signature
in the NOTICE files for code we imported into the respective
project. Of course the official part is done by the IP clearance,
but I think we should still state that the original code came from
the outside.
I disagree here, because it potentially gives reason for concern
about who actually "owns" the code. Since Dieter contributed the code
to Apache, it is now Apache code so it should be listed as such. The
NOTICE file, in my view, is not the place to try to give credit to
contributors since there are lot of potential contributors to all
code contained in a release. We have certainly not done this in any
other NOTICE file. Perhaps we can get some more opinions.
The other approaches are listing Dieter on the contributors page
(something I should have anyway) and listing the original code
authors on the sub project documentation page. I will do this.
The NOTICE file also says that it includes OSGi software, but I
don't think it does.
Right. Removed that section on including OSGi software.
I notice here that we also list the copyright year for the OSGi
software, do we really need to do that? It is a maintenance pain if
we do because we will need to change it every time we update the
OSGi software, like we are going to do now that we are using R4.1
API. (This comment is for all subprojects, not just the remote shell.)
The discussion on putting years or not is almost as long as the
naming discussions ;-) If I remember correctly one common consensus
is, that is not strictly required to put copyright years but having
them is still worth it ;-)
As this issue also touches all our other projects, I would say, I
keep the years here and we will fix all projects once we reach
consensus.
For simplicity, I say remove it. What do others think?
-> richard
Regards
Felix