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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
