UPDATE: In a March 22 press release, the PSF announced that the parties have reached an amicable resolution. According to the PSF, "Veber has withdrawn its trademark filing and has agreed to support the [PSF's] use of the term". Veber will rebrand its Python cloud server and backup services. For its part, Veber stated that its agreement with the PSF will "remove potential confusion between the Python software language and [Veber's] cloud services business".
The PSF's successful and efficient efforts to mobilize the Python community in its support undoubtedly had a significant effect on convincing Veber to settle the matter quickly.
By now, active observers of the open source world will have heard of the trademark dispute between the Python Software Foundation (PSF) and Veber, a small hosting company in the UK. As reported by the PSF, Veber recently decided it wished to use "Python" in certain branding of its products and services. Veber filed an EU community trademark application, claiming the exclusive right to use the "Python" mark for software, servers, and web services throughout the EU. The PSF (which obtained a registered trademark for "Python" in the US in 2004) is opposing Veber's trademark application.
The PSF has made a remarkable effort to mobilize the Python community to aid its opposition, an approach dubbed "Peer-to-Python" by one writer (a reference to the Peer-to-Patent initiative). The PSF has asked for letters from companies doing business in the EU describing their use of Python, "how your company looks for and recognizes 'Python' as only coming from the PSF," and support for the view that it would be confusing for another company to use Python to refer to "services, software, and servers." (Red Hat, which uses Python extensively in many of its products, has provided the PSF with a supporting letter.) The PSF has also sought examples of materials published in the EU that use "Python" to refer to the Python language, such as books and job listings. Subsequent commentary by the PSF suggests the community outreach has been quite successful.
Veber has claimed that it has received threats and denial-of-service attacks in response to this campaign. The PSF has appealed for civility and has stressed to the Python community the imperative of maintaining its reputation for helpfulness and friendliness. In its most recent update on the matter, the PSF reports that it is now engaged in good-faith negotiations with Veber.
The PSF/Veber dispute calls to mind something that is said from time to time, that trademarks can be of great significance to open source project communities yet are often overlooked (or are poorly understood) in a way that copyrights and patents are not. I do not disagree with this, though I believe that within the system, as it were, in the area of project naming, open source usually gets by well enough without trademarks appearing to enter the picture in any interesting sense. I say "naming" rather than "branding" deliberately, as I do not think most project names function as brands per se.
Consider two free software text-mode web browsers, lynx and links: their names are acoustically identical and visually similar. This is inherently confusing (a lynx user from times past, I admit to having wondered what connection there was, if any, between lynx and links when I first learned about the latter). A comparably-confusing graphical web browser pair is Konqueror and Conkeror. Yet such confusion appears to cause no harm in the non-commercial world of upstream open source project activity. Those interested in using or contributing to such projects will quickly learn which is which, and how they differ. (Interestingly, the Conkeror project says, jocularly, that "due to the fact that 'Conkeror' is a homonym with the name of the web browser 'Konqueror', the full name of the browser in spoken English is 'Conkeror (with a C)'", while going on to note that in written communication such disambiguation is unnecessary.) I think of this as a "horizontal" name confusion involving community projects that are similar but not necessarily related in a code provenance sense.
Long ago (before even his historic GNU project announcement) Richard Stallman complained about poor quality "superficial facsimiles" of the original Emacs being called 'Emacs', and urged that any such "imitation" be called an "ersatz Emacs". Yet today users can be expected to know that the Emacs reimplementation he later initiated, GNU Emacs, is the Emacs. The contemplated downstream modification of open source projects is most commonly done without renaming (this is even a key design feature of the popular GitHub service). Usually such "vertical"-relationship name similarity causes little concern because the true origin of the software remains well known to the main developer and user communities.
But this observation does not hold true for all open source projects, because not all are equal. Some reach a level of commercial or ecosystem scope and importance in a way that can make brand confusion have quite adverse consequences. Mozilla's well-known dispute with Debian over the Firefox trademark should be understood in this regard. Another problem arises when two entirely unrelated open source projects use a similar name and at least one such project rises to sufficient prominence. The stakes over "Python" in the PSF/Veber matter are even higher than this case, both because "Python" and the PSF itself are so unusually important in the open source landscape, and because the threat to Python is coming from a commercial entity outside the open source community project ecosystem.
While my sympathies in the PSF/Veber matter lie entirely with the PSF, I conclude by noting that there remain important questions concerning the proper limit of trademark protection in the context of names of programming languages that may have multiple nonauthoritative implementations (as of course is the case for Python), an issue explored further in this article.