hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <m...@michaelmcgrady.com>
Subject RE: @author tags
Date Tue, 16 Mar 2004 16:19:44 GMT
This is a really good idea, Oleg.  I am surprised, frankly, that we allow 
people to use the @author tags without having signed the agreement 
first.  That would be a real problem.

At 06:21 AM 3/16/2004, you wrote:

>In an attempt to reach a conclusion in this seemingly never-ending and 
>fruitless discussion I suggest that as of now we discontinue the use of 
>@author for all contributions submitted by people who have not signed 
>Apache CLA <http://www.apache.org/licenses/#clas>. That should address 
>legal concerns expressed during the discussion regardless how justified or 
>unjustified they are
>
>Mike, probably we should run a vote on this matter and get it over with. 
>What do you think?
>
>Oleg
>
>-----Original Message-----
>From: Michael McGrady [mailto:mike@michaelmcgrady.com]
>Sent: Monday, March 15, 2004 23:29
>To: Commons HttpClient Project
>Subject: Re: @author tags
>
>
>Fuel to this fire, I think, is fine.  Why not talk it out?  Why not share
>
>perspectives and information?  I have some remarks about what you have
>
>said, that I hope are helpful, see infra:
>
>CAN ANYONE ACTUALLY IDENTIFY A SINGLE LEGAL ISSUE WITH USING AUTHOR
>
>TAGS?  Even though I am a lawyer, and a good one, I think, I cannot
>
>identify such an issue.  This is a myth, in my opinion.  See in
>
>At 01:52 PM 3/15/2004, you wrote:
> >At the risk of adding fuel to an unproductive discussion, I thought I'd
>
> >throw in my comments:
> >
> >Legal:
> >
> >    * IANAL, however, it strikes me that there is at least some small
> >      legal exposure in the @author tags.  As a "contributor" of sorts,
> >      but not an official committer, there are certain documents that
> >      I/my company need not sign with respect to my "contributions" to
> >      ASF.  The @author tag, unfortunately, adds some ambiguity back
> >      into the equation, insofar as I *could* appear to be a significant
> >      contributor even though the same level of paperwork may not be
> >      associatiated with my "contributions."
>
>As a lawyer, none of this makes the least sense to me.  However ambiguous
>
>or not these things are is not related to the existence or non-existence of
>
>legal issues.  What "legal exposure" to you see and why?  Nothing said here
>
>relates at all to any legal exposure.
>
> >    * Based on what I've read, it would appear that certain unnamed
> >      three letter companies are creating allegations based on the most
> >      superficial of analyses of code.  May this be ASFs way of
> >      protecting the "innocent" from spurious supeonas?  I'll grant that
> >      it is a very narrow margin of defense, nothing more, although one
> >      that apparently would defeat said unnamed three letter companies.
>
>Would you spell out "what [you've] read" to make you think this?  What kind
>
>of allegations?  What kind of analysis of code?  How does this relate to
>
>ASF?  You are too dark here.  Let us know what you actually are thinking?
>
>
> >Social:
> >
> >    * Some people contribute merely by monitoring the mailing list and
> >      perhaps testing, sending in a wire log that helps to find a
>
> > bug.      Do we want to recognize those people as well?
> >    * Some "contributions" have been in the form of one-line "patches"
> >      that are not in unidiff format, and do not have an associated
> >      Bugzilla entry.  Do we recognize them?
> >    * Since the @author tag is certainly at the moment somewhat
> >      arbitrary in its actual recognition, its continued use may
> >      currently discourage contribution to the extent that people feel
> >      like the community is short-changing their contribution.
>
>The @author tag does not rule out anything.  So, the use of this tag could
>
>hardly be responsible for other things that are not done.  I don't see,
>
>further, what is "arbitrary" about the @author tag.  If used properly, it
>
>does what it is supposed to do.  How is that "arbitrary"?
>
>
> >Having noted some of the "social" issues, I do have to say that this
>
> >mailing list has been very friendly and welcoming, and my compliments to
>
> >everyone for keeping it that way.
> >
> >While not an entirely accurate measure, I have an urge to suggest a
>
> >mathematical and statistical recognition metric, combining:
> >
> >    * # of emails written to developer list
>
>I would suggest that this is not helpful.  Some "idiots" have automatic
>
>emails sent when out of the office, for example.  That hardly deserves 
>"merit".
>
> >    * # of patches submitted
>
>Doesn't this depend on whether the quality is good.  Submissions are one
>
>thing.  Reasonable submissions are another.
>
> >    * # of responses to bugzilla issues, wherein said person is not the
> >      reporter of the particular issue.
>
>Ibid.
>
> >    * # of bugzilla issues reported, wherein reporting does not result
> >      in an INVALID categorization
>
>Ibid.
>
> >    * negative points for each INVALID Bugzilla report (people wasting
> >      time and energy on behalf of the group)
>
>Again, this depends on the quality of the "INVALID[ity]" doesn't it?
>
> >    * Other contributions?
> >
> >My gut instinct is that some of these contributions should be weighted
>
> >more than others, but seeing as this is a quagmire, I'm not sure I'd want
>
> >to suggest what that weighting would be - at least not yet.  The resulting
>
> >number could be used to generate a ranking, and possibly a weighting of
>
> >each contributor.
> >
> >With each release, the tally should be accumulated for some time period
>
> >prior to that release (6 months?), and those people should be recognized
>
> >in the release notes, and perhaps also on the web site.
> >
> >Such a metric would at least be an improvement over what we have now.
> >It would at least recognize people who do "nothing more" than track down
>
> >bugs.  It would also give us some visibility into the size and involvement
>
> >of the HttpClient community.
> >
> >Darts welcome!
>
>This is all a quagmire, I would suggest.  I sure would not want to have to
>
>deal with this in any respect.  It is like looking something up in the
>
>Yellow Pages.  No one likes to do it and it is not good information except
>
>for those that simply have to have it.  Way too detailed.  Way too
>
>complex.  Way too way too!  The @author tags are Valhalla compared to this,
>
>in my opinion.  And, still, there is not an inkling of what actual legal
>
>issues are supposed to exist with the @author tags.
>
>
> >-Eric.
> >
> >Michael Becke wrote:
> >
> >>The ASF has recently recommended that we discontinue use of @author
>
> >>tags.  When first starting out I always enjoyed seeing my name in
>
> >>"lights", though I do agree with the ASF's opinion on this matter.  If we
>
> >>come to a consensus to remove @authors I suggest that we remove them from
>
> >>all existing code, as well as leave them out of new additions.   Any 
> comments?
> >>
> >>Mike
> >>
> >>
> >>Begin forwarded message:  ASF Board Summary for February 18, 2004
> >>
> >><snip>
> >>
> >>>   - author tags are officially discouraged. these create difficulties in
> >>>     establishing the proper ownership and the protection of our
> >>>     committers. there are other social issues dealing with collaborative
> >>>     development, but the Board is concerned about the legal ramifications
> >>>     around the use of author tags
> >>>
> >>>   - it is quite acceptable and encouraged to recognize developers' 
> efforts
> >>>     in a CHANGES file, or some other descriptive file which is associated
> >>>     with the overall PMC or release rather than individual files.
> >>
> >><snip>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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



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