Re: Newbie question on code vetting
[EMAIL PROTECTED] wrote: > 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. So what you need is a document that more or less formalises what you already know from rummaging around. The place for such a document would be the meta-PEP section at http://python.org/peps/. If the information you seek is in none of the existing meta-PEPs, that's probably because noone has yet felt the need for such a document bad enough to make the effort and write one. Until you came along, that is. So why don't you write a new PEP (or suggest changes to an existing PEP) with the information you need? You may not have all the answers, but if you have good questions that's a pretty good start. From an earlier post: > 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? If you have access to such tools, why don't you just scan the CPython sources yourself? And make the results available to the community, of course. - Anders -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question on code vetting
I'm replying to Ben because William's post is no longer on my news server. <[EMAIL PROTECTED]> wrote: > 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/legal/ See especially the "committer resources" > > Here are a couple more from the Apache software foundation. > http://www.apache.org/foundation/how-it-works.html Interesting, those links have nothing to do with checking the source of code and everything to do with the projects covering their asses. Which is perfectly reasonable behavior on their part, but it gives you, the end user, almost no protection. Suppose company X proves that project Foo incorporated some of their unlicensed code. Copyright infringement is a strict liability action. X can obtain an injunction against distributing Foo and impoundment/destruction of all infringing copies. Waivers like those above may indemnify Foo against monetary damages and legal fees, but end users are in the same position as without the waivers: their software Foo can be seized and destroyed. How exactly are you better off trusting Foo? Now maybe you could claim that merely using the waivers forces everyone to think long and hard about IP, avoiding potential issues, but that strikes me as more than a little dubious. People often don't even read what they sign, much less think about the implications. I am not a lawyer (yet), but I have studied US copyright law. > 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. Looking for boilerplate waivers sounds more like CYA than diligence to me. > Asking the higher-ups at > work to reach technology management decisions based on my gut feel is an > uphill climb. And foolish. If you can't make a convincing case based on everything said in this thread, you may as well give up because your higher-ups aren't listening. > 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. Ben already mentioned the false dichotomy here. Let me just say I think both your goal and his (spreading free software at the expense of non-free) are counterproductive. Organizations (and people) should look for the software that best fits their needs. Sometimes that means highest technical quality. Sometimes it means open standards or open source. Sometimes it means features X, Y, and Z. Sometimes it means vendor support. Often it's a combination. A successful project should focus on discovering and meeting its users' needs. Spreading open source for its own sake helps no one. > 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? Really, open source did that? Here I thought it was the the Chinese govt strongarming Microsoft over the promise of 1.3 billion potential consumers. > 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. "We must move forward, not backward, upward, not forward, and always twirling, twirling, twirling towards freedom!" Seriously, I think you're kidding yourself. Community-based, volunteer-driven open source projects handle some things very well. Closed, commercial projects excel at others. In between there's a lot of overlap with mixed attributes of each (not to imply these are merely two ends along a single spectrum, there are more dimensions involved). I think the market success of communal software shows that some software is becoming commoditized. Because software is a nonrivalous good (making copies is essentially free), it's usually more economically efficient for users to pool development costs and only pay for support than to pay for profits on each copy produced. Where it makes sense, the market is moving towards software as a public good rather than software as a product. Instead of digging out a huge canyon and charging for access to it (Microsoft/Oracle model), it's hiring out a river guide just to those who want one (Linux/MySQL model). Each has its place and neither is going away. Also note the public good approach doesn't require open source -- it works just as well with freely available binaries, a la Sun's Java VM. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question on code vetting
<[EMAIL PROTECTED]> writes: > 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. While I don't agree with the dichotomy you present -- much of the free software available, especially among the mature and popular projects, is commercially produced, so the two evidently aren't opposed -- I laud your goal of attempting to spread the use of free software at the expense of non-free 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" The obvious thing to note at that point, then, is that an organisation which applies such a double standard to its vendors -- existing software vendors can continue to have appallingly obscure processes and not be held accountable, but free software's outstandingly open processes need to spend volunteer effort to become even *more* open to become worthy of attention -- needs to evolve or die. A less obvious thing to note is that the free software model allows anyone to get involved and do the work they perceive needs doing, or to sponsor it to make it happen. If an organisation needs a whole lot of work put in to create or improve the types of documents it likes to see, what is stopping that organisation from doing so, or offering compensation for others to do so? -- \ "For mad scientists who keep brains in jars, here's a tip: why | `\not add a slice of lemon to each jar, for freshness?" -- Jack | _o__) Handey | Ben Finney -- 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
Re: Newbie question on code vetting
I have no deep connections to any open source projects. I do however know quite a few engineers. Bear that in mind. [EMAIL PROTECTED] wrote: > 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? I don't think it's a question of transparency but effort. Documenting the processes takes time which many probably feel is better spent on functional aspects of the project. And for what benefit? Are open source projects more concerned about approval or quality? Besdies, most commercial products have zero transparency in their development processes and it doesn't hinder their market acceptance. > 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. If those practices are identifiable and repeatable, then sure, maybe projects could be more productive following a "best practices" approach. OTOH if successful projects function more as little fiefdoms run by benevolent dictators, the reasons for success may be too idiosyncratic and happenstance to translate to other projects. Note I said more productive, as in allow the code to improve quicker. My impression is most engineers don't want to invest time on IP rules and hate when legal shenanigans impinge on their development. They're generally good at providing attribution and avoiding intentional misuses, but won't go out of their way to check sources. Nor should they, as 1) that's not their job and 2) it's a very difficult task (unless you know of some master database containing all the world's code). Hence IP verification "best practices" are likely to be summarily ignored as a foolish waste of time. Closed commercial projects fare no better, indeed they may be even worse since the risk of getting caught is lower. Google for the number of times unlicensed GPLed code turned up in some commercial product. > 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. Transparency can be valuable to an outsider, but I don't see how most projects would have the time, resources, or inclination to provide it. > 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. Sure, but this task is better handled by vendors like Red Hat than by individual projects. IP verification is no easy matter to handle, and vendors have a financial incentive to perform the checks. Vendors can also offer indemnity, which individual projects can't. > 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. I suspect part of the reason you have trouble finding answers about IP issues is that there are none to give. I doubt most projects follow anything resembling a formal process for verifying sources. It's more likely left up to individual contributors, and probably runs along the lines of "if it doesn't look obviously ripped-off, then it's ok". > With regard to the issue of trust, how can I either trust or decide not to > trust in an information vacuum? By looking at indirect sources of evidence. How much trust do others put in this project? (Google for one uses python heavily.) How do most open source projects function? How do most engineers handle IP issues? Can I hire an auditor to sample a representative portion of the code base for IP issues? Has anyone else already done so? How often are open source projects accused of IP violations? How serious are they and what are the outcomes? Do closed projects handle things any differently? What assurances do they really provide? Risk analysis means there's risk. Unknowns are inherent. Work around them the best you can. > 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. Faith is a belief that something is true without evidence. Trust is relying on something/someone to perform a certain way. Blindly believing a project to be free of IP issues is faith. Expecting the committers to take the sam
Re: Newbie question on code vetting
<[EMAIL PROTECTED]> writes: > I hope the following message will not result in scorn being heaped > upon me. We try to heap scorn not upon individuals, but upon scorn-worthy ideas. Also, we heap scorn upon people who heap their responses on top of the quoted material. Please don't top-post. > 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. You mean like publicly-accessible and archived developer discussion forums? Bug tracking systems which anyone can submit to? Source code with copyright statements and license grants directly in the files for anyone to examine? Who is it that needs to improve their transparency, again? I would love for all software vendors to be held to this standard. Are you suggesting your organisation expects some higher level of transparency from free software, when it happily accepts a far lower level of transparency from proprietary vendors? (good sigmonster, have a biscuit) -- \"The right to search for truth implies also a duty; one must | `\ not conceal any part of what one has recognized to be true." | _o__) -- Albert Einstein | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
RE: Newbie question on code vetting
[EMAIL PROTECTED] wrote: > 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. You mean something like: http://www.python.org/dev/ Tim Delaney -- 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
[EMAIL PROTECTED] wrote: > 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. If committers make no checks on submitted code, that doesn't have to be an automatic showstopper, even for a risk-averse company. How many of the alternatives perform more stringent checks on their code? How much misappropriated code is floating around in closed commercial products, where the privacy of the source may encourage more liberal borrowing? Anyone can say they check their IP, but how many organizations put their money where their mouth is and provide indemnity? How visible will your company and your Python projects be? You can always try to make the case that even without ip checks python makes your company 1) no more vulnerable than the other software they already rely on, and 2) unlikely to be targetted for their use anyway. And if you can show the financial gains from using it are highger than the potential liability, you're golden. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question on code vetting
[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, 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
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
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
