<div>Chuck,</div>
<div> </div>
<div>Personally I'm very happy with the way things stand right
now. However - I believe the issue is not that but how to address
the behaviour of people who do not embrace the spirit and the intent
behind open source and instead use the very openness as a tool to
disadvantage those who are playing by the rules.</div>
<div> </div>
<div>This does get us into some sort of area where we expect this to be
self-policing to an extent by the community at large. The
snag is that community to now becoming vastly bigger than the original
geek foundation.</div>
<div> </div>
<div>So often customers are not the ones hanging out in linux chat rooms
reading about how despicable their particular supplier is. Perhaps
the way forward is to establish some kind of grading scheme where those
with gold ratings can get extra marketing kudos from the fact -
compared to competitors who are less than open about what they are
doing or not doing to support the community or the code base they are
hijacking.</div>
<div> </div>
<div>Once again though we come back to who manages and maintains that
and where? Perhaps some kind of eBay rating system is in order -
where people can post for and against and developers can post a link to
their own entry in the rating bank - and you get points for
contributions and such to the source base? Again no metering
system is perfect - but perhaps having some formal recognition for
those toiling in the cause may help establish them as a perferred
source compared to others? This would certainly reduce the need
for the direct attribution system - if there was a place people could
point to for kudos and recognition.</div>
<div> </div>
<div>Ultimately this comes back to the fact that customers see more
business benefit in dealing with these players rather than
others.</div>
<div> </div>
<div>DW<BR><BR>"The way to be is to do" - Confucius (551-472
B.C.)<BR></div>
<DIV id=wmMessageComp name="wmMessageComp"><BR><BR>
<BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT:
blue 2px solid">-------- Original Message --------<BR>Subject: Re:
ZDNet article - why attribution matters<BR>From: Chuck Swiger
<chuck@codefab.com><BR>Date: Tue, November 28, 2006 1:00
pm<BR>To: David RR Webber ((XML)) <david@drrw.info><BR>Cc:
lrosen@rosenlaw.com, "'David Berlind'"
<David.Berlind@cnet.com>,<BR>"'John-Sugar'"
<john@sugarcrm.com>, license-discuss@opensource.org<BR><BR>On Nov
28, 2006, at 8:00 AM, David RR Webber ((XML)) wrote:<BR>> I think
this cuts to the point of - what is the purpose of open <BR>>
source?<BR><BR>The purpose of OSI Open Source is to make better
software available <BR>to everyone.<BR><BR>While there are lots
of ways of writing, publishing, and maintaining <BR>software, the
experience of the BSD community back in the 1970's, and <BR>later
that of the FSF & GNU project starting in the early 80's [1],
<BR>is that by making the source code to software publicly
available and <BR>permitting people to make their own changes to
the code and to be <BR>able to share these changes with everyone
else, results in better <BR>software.<BR><BR>> The person
publishing the source has very clear reasons why they <BR>>
are doing that and how they expect people to use that source.<BR><BR>I
would agree that people who publish their source code usually have
<BR>clear reasons for doing so; I would disagree that most people
writing <BR>Open Source software place expectations as to how
others should use <BR>the software. People who place
restrictions into the software <BR>license on how the software
may be used generally do not comply with <BR>the Open Source
Definition, and such licenses typically are rejected <BR>by the
OSI board.<BR><BR>> Other people then wish to retroactively bend
that into something <BR>> different - usually without the
permission of the author, or <BR>> perhaps as an unintended or
unanticipated action beyond what the <BR>> author original
envisioned! This generates friction, or sometimes <BR>>
pleasant surprises - but not always! ; -)<BR>><BR>> The job
of OSI is to mitigate that and provide clear guidelines and
<BR>> boundaries for people to operate in so that they can
anticipate and <BR>> expect reliable and consistent results
when they release their open <BR>> source in a particular way.
This ultimately fosters a healthy and <BR>> thriving
community of practice.<BR><BR>Do you not find that the Open Source
Definition provides clear <BR>guidelines and boundaries?<BR>Is
there some part of it which you find unclear?<BR><BR>-- <BR>-Chuck
</BLOCKQUOTE></DIV>