Newbie question on code vetting
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? 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? Also, is the same or a different standard of IP assurance practiced for the Cheese Shop? I work for a risk-averse company, and I want to compile a solid case for obtaining and using Python at work. Thanks in advance, Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question on code vetting
Edward, I agree with your point, which is why I asked the question. Risk cannot be eliminated, but it can be understood and managed so that useful work can still be done. If there is any way I can find out what the commiters do prior to reaching a decision to accept or reject a particular submission, I would like to know about it. Thanks in advance, Bill "Edward Elliott" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Dennis Lee Bieber wrote: > >> I work for a risk-averse company, and I want to compile a solid case for > >> obtaining and using Python at work. > >> > > Given the nature of the US Patent Office... You might as well lock > > the doors now... > > > > The Patent Office could issue a patent next week that makes all > > bytecode interpreted languages subject to some royalty... > > Risk isn't just what could happen, it's how likely it is and what effects it > would have. A patent affecting millions of installed interpreters is > pretty unlikely and would have many challengers. Even if it were upheld, > how many larger companies with deeper pockets would they go after before > his? And everyone stuck in the same boat would quickly work towards a > non-infringing solution. Cases like MS-EOLAS and RIM-NTP aren't exactly a > daily occurence. They also demonstrate why there really is safety in > numbers. > > Plus all the potential negatives have to weighed against the increased > productivity his company gains from using a scripting language. The gains > may more than offset any potential patent settlement. > > Risk-averse doesn't mean head-in-the-sand. > -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question on code vetting
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
Re: Newbie question on code vetting
Edward, thanks for the thoughtful comments. I would like to offer a couple of links to the kind of stuff I am talking about w.r.t. the "transparency" issue. First, some from Eclipse: http://www.eclipse.org/org/documents/Eclipse%20IP%20Policy2006_03_20.pdf http://www.eclipse.org/legal/ See especially the "committer resources" stuff at the bottom. Here are a couple more from the Apache software foundation. My understanding is that these methods/principles are applied across all projects within the ASF. http://www.apache.org/foundation/how-it-works.html http://www.apache.org/licenses/#clas My thinking is that if that kind of documentation were more widely available, the process of doing appropriate diligence on the part of the consuming organizations would be easier and more repeatable. As it is now, one is pretty much left to rummage around on project web sites trying to get a gut feel for what is going on. Asking the higher-ups at work to reach technology management decisions based on my gut feel is an uphill climb. It is difficult to erase "FUD" among managers, but if it can be done not just at my company, but widely, more people can use and examine the code, report bugs, suggest improvements, etc. Availability of documentation like the Eclipse Project and the ASF are a big step in the right direction, I think. The overall goal is to remove a barrier to more widespread use of Open Source - growing the mindshare dedicated to it and potentially shrinking the mindshare dedicated to commercially-produced software. A couple of responders to my earlier notes wrote something like "do you ask the same thing of closed source vendors?" The answer is "no, not at present", but if the Open Source movement can cause Bill Gates to show his code to the Chinese government, who knows what else it can do? I think the Open Source movement is leading, not following, commercial code producers. If there is a better way to do business, I would like to see Open Source get there first. Regards, Bill -- http://mail.python.org/mailman/listinfo/python-list
