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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [EMAIL PROTECTED] 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 > -- http://mail.python.org/mailman/listinfo/python-list
