On 4/2/06, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > > > Gary Gregory wrote: > > > > Based on the February 18, 2004, Apache Software Foundation Board > > > > of Directors Meeting Minutes, author tags are "discouraged". > > <snip> > > > > Sandy McArthur wrote: > > > >I have searched some and the arguments don't hold water with me. > > > :-) Many things from lawyers and the board don't make sense ;-) > > here's the only convincing argument i know of: > > what worries the board (and other open source folks) is the effective > destruction of open source projects by targeting (with individual > lawsuits) the limited number of critical contributors who do crucial > things such as cutting releases. if these individuals are acting on > their own behalf, as a non-profit the ASF cannot help them. if they are > acting for the ASF then the ASF can defend them in court. > > so, the trick is setting up a structure which imposes as little friction > on development as possible but which allows developers to develop for > the ASF rather than on their own behalf. PMC'ers are part of the ASF > organisation by their membership of an ASF committee and can bind the > ASF to a particular course of action. they should therefore be protected > from disruptive litigation by the ASF legal umbrella. committers are > not. so, it's important for PMC's so recognise those who make important > contributions to the ASF in a reasonably prompt fashion. > > the question of the policy on author tags is related to this. it was > felt that PMC'ers may be weakening the legal argument (that they acting > on behalf on the ASF) if they added author tags to the code. might look > to a lawyer as if they were working for themselves. that's why > recognition elsewhere is fine.
For me that falls apart in two places: 1. authorship != ownership, this is made clear by the file's header. 2. subversion contains enough information to target critical contributors. In my mind that is like worrying about a second story window that may be unlocked when your front door is off the hinges. > note that this argument is only valid for PMC'ers and is not relevant > for author tags for other developers. when committing patches from > developers who are not committers, it is important that the source of > the patch is noted in the commit (so that it can be tracked). > > > > >I'm proud of the code I've contributed and I think an @author tag is > > > >proper recognition. > > > I suppose that five years ago when I joined, I felt something similar. > > > At that time author tags were allowed, so it wasn't a problem. Over > > > time, that desire for such 'base' recognition has gone. > > > > You're probably right eventually. When I'm married and have kids I > > probably won't even remember this but until then I do care with > > respect to my own contributions. > > the maven generated team list and commit emails are better indexed (and > analysed) than the source. so, as a form of recognition, these generally > work better. author tags also seem to attract the wrong kind of > recognition: spam from uneducated users (who should be posting their > questions to the user list). we've also had arguments in the past about > authors who no longer wished to be associated with particular classes. > life is usually easier without them. > > > I think the best "policy" is to stay true to yourself and be tolerant > > of people with different policies. In my mind that will work today, > > tomorrow, and up until the earth is swallowed by the sun. > > that's pretty much my approach. i generally leave author tags alone. for > new classes, i add apache as the author. but my opinion is in the > minority and i can understand why components with classes with long > author lists prefer to insist on the maven team list. Well, IDEs with code folding make that irrelevant and those list of @author tags not need be so long as the @author can can be either one name per tag (common) or many comma separated names per tag (seemingly unknown). -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
