Re: [all] Author tags [was Line width and such minutiae]

[robert burrell donkin <ro...@blueyonder.co.uk>]

> > 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.

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.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [all] Author tags [was Line width and such minutiae]

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Tue, 2006-04-04 at 09:16 -0700, Henri Yandell wrote:
> On 4/2/06, Martin Cooper <ma...@apache.org> wrote:
> > On 4/2/06, Sandy McArthur <sa...@apache.org> wrote:
> > >
> > > 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.
> >
> >
> > Subversion does indeed contain plenty of information. However, lawyers don't
> > understand source control systems, but they do understand plain text. A
> > technical perspective isn't what's important here; what lawyers understand,
> > and what is supported by legal precedent, is. That's where the board is
> > coming from, backed by legal advice.
> 
> There's also a difference between push and pull, I believe. We are
> publishing/distributing the author names in the javadoc/source - we
> don't publish the subversion data.

AIUI copyright is not the key issue here and (so) not ownership or
authorship. the ASF tries to ensure that there is a public record of the
entire process so that this should be clear and transparent. so,
ownership and authorship should not be in doubt. however, the intent may
be. use of the author tag was thought to increase the chance of a court
ruling that when the source was created, the contributor intended to
work for themselves rather than on the ASF's behalf. not sure how strong
this argument would be but (since it was only a recommendation) quite
possibly not very.

but if you're interested in the legal side of this issue, it might be
worth raising this on legal discuss when things are a little quieter
than now...

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [all] Author tags [was Line width and such minutiae]

[Henri Yandell <fl...@gmail.com>]

On 4/2/06, Martin Cooper <ma...@apache.org> wrote:
> On 4/2/06, Sandy McArthur <sa...@apache.org> wrote:
> >
> > 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.
>
>
> Subversion does indeed contain plenty of information. However, lawyers don't
> understand source control systems, but they do understand plain text. A
> technical perspective isn't what's important here; what lawyers understand,
> and what is supported by legal precedent, is. That's where the board is
> coming from, backed by legal advice.

There's also a difference between push and pull, I believe. We are
publishing/distributing the author names in the javadoc/source - we
don't publish the subversion data.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [all] Author tags [was Line width and such minutiae]

[Martin Cooper <ma...@apache.org>]

On 4/2/06, Sandy McArthur <sa...@apache.org> wrote:
>
> On 4/2/06, robert burrell donkin <ro...@blueyonder.co.uk>
> 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.


Subversion does indeed contain plenty of information. However, lawyers don't
understand source control systems, but they do understand plain text. A
technical perspective isn't what's important here; what lawyers understand,
and what is supported by legal precedent, is. That's where the board is
coming from, backed by legal advice.

> 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).


Not everyone uses an IDE, and we shouldn't be basing decisions on the
assumption that everyone is. Many of us prefer to work with the same tools
we've been using for years, and we're just as productive with those tools as
others might be with an IDE.

--
Martin Cooper


--
> Sandy McArthur
>
> "He who dares not offend cannot be honest."
> - Thomas Paine
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Re: [all] Author tags [was Line width and such minutiae]

[Sandy McArthur <sa...@apache.org>]

On 4/2/06, robert burrell donkin <ro...@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org