On Oct 8, 8:43 am, Dave <[EMAIL PROTECTED]> wrote: > With the open source licenses that allow redistribution of modified > code, how do you keep someone unaffiliated with the Python community > from creating his or her own version of python, and declaring it to be > Python 2.6, or maybe Python 2.7 without any approval of anyone at the > PSF? Maybe their code is terrible, and not even compatible with the > rest of Python! How can the PSF, for example, maintain the quality and > coheren of new code contributed to be part of Python, or derivative > works that claim to be some future version of Python? If licensees can > redisribute as they like, isn't this a huge problem? Is this dealt > with be restricting use of the Python trademarks? Just curious..
Most trademark violations have occurred, to the best of my recollection, by commercial entities trying to usurp the popularity of an open-source endeavor for their own commercial gain. It is very rare that another in the open-source community will commandeer the good name of another project for his own purposes. This gives strong credence to the idea that the highly participatory nature of the open-source community serves as a strong, self-enforcing deterrent to negative acts of this nature. As far as quality assurance itself goes, independent, third-party unit test suites are easily engineered. Parties who do manage to succeed in releasing their own "Python 2.7" can do so only by either making their product compatible with this third-party verification suite, or by not doing so. This leads to two situations: (1) If compatible, then the name "Python 2.7" may well be accepted by the community, even if only in an allegorical sense (e.g., "If PSF released Python 2.7, this product is how I envision it'd be like."). Alternatively, people will recognize the product as being Python- compatible, but otherwise an independent line of development -- e.g., a fork. The PSF can then release under a new set of version numbers (where everyone understands that 2.7 is an independent fork not endorsed by PSF), persue negotiations (ultimately terminating in legal action) to arrive at an acceptable product name, etc. If the PSF were feeling particularly benevolent, they could even accept some ideas from the 2.7 release into their own branch of development. (2) If incompatible, the product will gather a reputation of inferiority rapidly, and those clearly interested in Python will neither want nor have anything to do with this misbranded malfeasance. Again, independent verification is an example of the participatory nature of the community at large, and is a prime example of how concerned citizens can act collectively in their own interest, independently, to help ensure the quality of a socially-accepted product. -- http://mail.python.org/mailman/listinfo/python-list
