hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: @author tags
Date Fri, 12 Mar 2004 15:44:03 GMT

> We all love Roland. 

I am glad we are in agreement here.

> However, I really cannot see how the
> @author tag hides any contributions.  Maybe on that issue I am lost?

It does not. However, I strongly believe that @author tags have many deficiencies in representing
individual contributions and, what is more importantly, their value. One time one liner patch
may earn you a @author tag if you are lucky. At the same there are people who contribute on
a day to day basis by helping the committers to make more elegant and efficient design decisions.
Such contributions representing enormous value may, however, never be reflected in the source
code if other guys had done all the coding.

I do agree with you (which does not mean much as I am no lawyer) that presence of the @author
tags in the source code may necessarily mean legal risks. And I do agree that absence of @author
tags may not deter a determined, litigation happy party from pursuing legal actions against
ASF. What I am trying to say is that I see a great need in a better attribution system, which
may render the whole @author tag controversy obsolete. I want the @author tag to stay, but
I can well imagine that only people who have signed the Apache CLA may be mentioned as such,
even if sounds silly from the legal perspective. All those who have not signed the Apache
CLA need to be credited for their contributions in some other way.

Oleg


-----Original Message-----
From: Michael McGrady [mailto:mike@michaelmcgrady.com]
Sent: Friday, March 12, 2004 16:15
To: Commons HttpClient Project
Subject: RE: @author tags


We all love Roland.  No issue there.  However, I really cannot see how the
@author tag hides any contributions.  Maybe on that issue I am lost?  That
is another matter altogether.  I was discussing the legal ramifications solely.

At 05:19 AM 3/12/2004, you wrote:

> > Love yah, Roland, but this is not your shining hour.
>
>Actually Roland shines when it comes to giving feedback to proposed
>changes, patches, answering questions, and helping people on the mailing.
>He is precisely the reason I (as a HttpClient project committer) would
>like to have a better attribution structure that goes beyond @author tag.
>The @author may be a very misleading indicator of one's contribution and
>its value. Roland contribution is currently MASSIVELY understated within
>the existing attribution structure. As much as I would regret to see
>@author go, at the same time I would whole-heartedly welcome a better
>system of giving due credits to the regular contributors like Roland. If
>the board comes up with viable substitution to the @author tag, so be it
>
>Oleg
>
>
>-----Original Message-----
>From: Michael McGrady [mailto:mike@michaelmcgrady.com]
>Sent: Friday, March 12, 2004 13:38
>To: Commons HttpClient Project
>Subject: Re: @author tags
>
>
>Roland Weber wrote:
>
> >I don't see that either. But if some of the top Apache guys
> >feel, believe or know otherwise, that's good enough for me.
>
>Know what?  This has become a recreation of illusions and delusions.  This
>
>is like Franz Kafka's book The Trial.  There are vague and unsubstantiated
>
>reasons for changing the entire attribution structure of the open source
>
>community.  This is not good thinking.
>
> >If the only purpose of the tags is to feature contributor names
> >in a prominent place - namely the source code - then the
> >real question becomes whether we can achieve this goal
> >in some other way with reasonable effort.
>
>This is NOT the only goal.  That is not even close to accurate.
>
>
>
> >Concerning the CVS log, you have to be aware that the
> >committer is not always the contributor. A contributor
> >may put a patch in bugzilla, which is then comitted by
> >someone else.
>
>Well, in the paranoid sort of talk we are having, then the "committer"
>
>becomes subject to these imagined but unreal legal assaults.  Indeed, where
>
>an "author" is hidden, the Foundation would become liable for a
>
>"conspiracy" of hiding the real culprits.  This is all silly from a legal
>
>standpoint.
>
>
> >In general, I don't believe that the removal of author tags
> >is to disguise from where the code came. Rather, some
> >people may be afraid to find their name in the author tag
> >of code which has no longer anything to do with what
> >they actually contributed long ago.
>
>This is yet another reason?  This is also not right.  The @author tags keep
>
>track of rather than obscure people's relation to existing code.  The
>
>destruction of this useful device will create rather than solve anything
>
>akin to this imagined problem.
>
> >Then it would become
> >their problem to dig through the CVS logs, bugzilla, and
> >the mailing list archives to prove that they are *not* the
> >author.
>
>To whom?  This is just imaginary.  This is Alice in Wonderland thinking.
>
>Love yah, Roland, but this is not your shining hour.  Really, there is no
>
>legal difficulty, but this recommendation might create one.  Microsoft
>
>could not have come up with a better way to screw up the code.
>
>
>***************************************************************************************************
>The information in this email is confidential and may be legally
>privileged.  Access to this email by anyone other than the intended
>addressee is unauthorized.  If you are not the intended recipient of this
>message, any review, disclosure, copying, distribution, retention, or any
>action taken or omitted to be taken in reliance on it is prohibited and
>may be unlawful.  If you are not the intended recipient, please reply to
>or forward a copy of this message to the sender and delete the message,
>any attachments, and any copies thereof from your system.
>***************************************************************************************************
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail:
>commons-httpclient-dev-help@jakarta.apache.org



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


***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this
email by anyone other than the intended addressee is unauthorized.  If you are not the intended
recipient of this message, any review, disclosure, copying, distribution, retention, or any
action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. 
If you are not the intended recipient, please reply to or forward a copy of this message to
the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************

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


Mime
View raw message