Newbie question on code vetting

[william.boquist at gte.net]

All,

I hope the following message will not result in scorn being heaped upon me.
I know this is not a particularly fascinating topic for developers, but I
believe it is worth pursuing.

It seems to me that Open Source generally would be more pervasive if there
was more transparency with respect to the practices observed within the
projects. What possible harm could there be in letting the world know how
decisions to incorporate code are reached? The goal of collaborative
development is to build a body of code with many minds that is better than
the body of code that could be built by any subset of them. The same
principle could be applied to identification of best practices for
committers across projects. Just as the code must be available so that it
can be inspected, improved and extended, so should the practices, for
essentially the same reason. To me, being unable to reach an understanding
of the practices is analogous to being unable to see and run the JUnit
suites on a bunch of classes - being in the position of assuming that there
is coverage, but not being able to understand how much or how thorough.

I think it is obvious that if every consumer of the code who has an interest
in controlling risk has to reinvent the wheel, there will be a lot of effort
wasted on redundant work. Why not have the project publish a document that
says "here are the practices by which we manage our code base - take it or
leave it". Just as most licenses are variations on a few (GPL, LGPL, CPL,
etc.), it seems to me that very quickly, a set of common management
practices would evolve if most projects published, perhaps with a few
variations.

With regard to the issue of trust, how can I either trust or decide not to
trust in an information vacuum? I may be splitting hairs, but my
understanding is that belief despite absence of evidence is faith, not
trust. Trust is the result of observation, and I want to be able to observe.

Thanks for the info on the Cheese Shop. That helps.

If there is any interest in learning about it within this group, I can
supply some related info from the Eclipse project.

Regards,
Bill

"Robert Kern" <robert.kern at gmail.com> wrote in message
news:mailman.5299.1146719004.27775.python-list at python.org...
> william.boquist at gte.net wrote:
> > Hi.
> >
> > I have visited the Python web site and read some information on who the
> > commiters are and how to go about submitting code to them, but I have
not
> > been able to locate any information regarding the process for vetting
the
> > code to identify any possible IP infringement before it is committed.
How do
> > the committers ascertain the originality of the code before it becomes
part
> > of the base?
>
> They tell themselves very sternly not to commit code that isn't
appropriately
> licensed.
>
> > Is there any use of tools like BlackDuck ProtexIP or the
> > competing Palamida product to scan for matches to code that is already
> > licensed elsewhere?
>
> No.
>
> > Also, is the same or a different standard of IP assurance practiced for
the
> > Cheese Shop?
>
> There is no vetting for the Cheese Shop. Anyone can post packages there.
If some
> illegal-to-redistribute code is discovered, it will probably be removed by
the
> administrators. This hasn't come up, yet, I don't think.
>
> If you want the code to be vetted, you have to do it yourself. Besides, if
you
> don't trust the commiters and the package authors not to infringe on other
> peoples' IP, why do you trust them to report infringement?
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
enigma
>  that is made terrible by our own mad attempt to interpret it as though it
had
>  an underlying truth."
>   -- Umberto Eco
>