Protecting the Python Trademarks

Who is the Trademarks Working Group?

The Python Software Foundation Trademarks Working Group was created by the PSF Board of Directors to  monitor and authorize (or prohibit) use of trademarks held by the PSF.  The WG—initially dubbed committee—was created in 2008, and has been co-chaired by me since 2010, adding Marc-André Lemburg in 2013.  We've had a variety of other members over the years, with Iqbal Abdullah being a wonderful and helpful member of the WG for the last couple years.

You can write to us any time at on the Trademarks WG mailing list.  If you ever want to use one of our marks, please do write to us.  Even for those uses that are completely non-contentious, we'd rather quickly approve them and have a record in the mailing list archives than just not know about the use (the archive is not public, however, since legal issues, even potential litigation, are sometimes discussed).

We would welcome participation by more Python community members (being a PSF member is not strictly required, just an interest in helping Python maintain its branding).  Helping with the working group is a pretty small time commitment, but as with many volunteer efforts, folks often drift away from such efforts over the course of years.  By all means contact us if you have an interest in trademarks and an hour or two a week to spend helping us in these discussions.

Our Goals

The PSF holds registered trademarks in a large number of jurisdictions—incrementally increasing in number over the years—and "use trademarks" worldwide.  Obviously, legal regimes around intellectual property, and trademarks specifically, vary somewhat around the world; for the most part trademarks serve a similar purpose everywhere though.

We don't want the brand and reputation of Python to be used in a deceptive manner. However, Python being free and open source software (FOSS), and the PSF being devoted to such freedom, the licensing policy adopted by the PSF is very liberal and serves the purpose of promoting the use and knowledge of Python rather than trying to obtain commercial advantage (as many for-profit product marks are used).

Let's go back to what marks the PSF maintains.  The name "Python" is a wordmark that is registered in many places.  Nominative use of the name is always permitted when it is used to describe the Python programming language. In contexts such as books devoted to the language or about associated libraries, tools, etc. we ask publishers to include a small notice in the front matter that mentions the PSF trademark.  We have an official usage policy and a Frequently Asked Questions that detail permitted usage, with the FAQ having more examples and a less formal tone (probably best to start with the FAQ if you have questions).

Similarly, the names "PyCon" and "PyLadies" are also wordmarks of the PSF. The policies around use of PyCon and of PyLadies are each a little bit different from the Python wordmark, since they serve  different purposes.  Essentially, we want to make sure that when those names are used, they maintain an identity and advance the goals for which the marks were created.  The PyLadies wordmark is monitored and authorized by the PyLadies leadership rather than the Trademarks WG, so email to them is the best place to ask questions of them.

Trademarks are Tricky

The trickiest part of what we do on the Working Group is approve use of the "two-snakes" Python logo.  A great many really wonderful Python-related user groups, conferences, software projects, publications, blogs, and other efforts that do a great job of promoting Python, understandably don't understand the arcana of trademark law. In particular, the rules we need to maintain about derived logos can feel obscure and counter-intuitive in the FOSS world.

The key issue is that trademark is not copyright.  For people familiar with copyleft and software freedom, it feels like the right to create derived products should be as little restricted as possible, perhaps not at all. While I endorse that wholeheartedly for copyright, that's not how trademarks work—nor, I believe, how they should work.  Trademark is instead a kind of consumer protection, it's a way of saying that a particular thing is what it purports to be.  In a way, a trademark is like a signature or a seal (whether a physical or a digital version of such); it's a testament to authenticity of a thing.

Apart from my particular philosophical attitudes about trademarks, the laws around them have a specific concept of dilution wherein merely permitting a use that makes a mark less distinct can remove the protection altogether.  Specifically, it means that if the PSF allows groups to make completely well-meaning, and often even beautiful, changes to the shape of the two-snakes logo, we could wind up losing the ability to stop malicious actors from misbranding their non-Python things with the logo.  To be clear, many derived logos are absolutely permissible, and the FAQ discusses what distinguishes permissible and impermissible derivations (and what can be "inspired by but not derived from").

Happily, all the good actors we've dealt with, in my 15 years working on this, have come to understand the concerns of the PSF, and have modified their customized logos in ways that allow us to authorize them.  It's slightly unfortunate that a few others have slipped through simply because the WG never knew they existed until they were already in use, but we've worked with those groups (largely conferences and user groups, sometimes software projects) to fix things going forward.  It's a little bit of politics, a little bit of professionalism, but mostly it's just reaching out to the truly wonderful people who make up our worldwide Python community.

David Mertz (mertz@gnosis.cx)

The Case for a Second Developer-in-Residence for Python

As the currently serving sole developer in residence, I’m often asked if there will be more people holding the same position in the future. I strongly believe there should be and that it’s crucial to the long term success of this role. The only open matter is finding sustainable sponsorship for the position.

The current developer in residence

My day-to-day work revolves around an array of maintenance tasks for the Python Software Foundation with focus on CPython. Since I started in July 2021, I’ve done among others:

• PR review and merging: 627 merges to CPython that lead to closing of 276 issues on the bug tracker, and many more code reviews on Github;
• release management for the 3.8 and 3.9 branches as well as release notes and announcements for other releases;
• following the Python security response team reports that lead to several security releases of Python;
• following the buildbot fleet status and reacting to failures, including maintenance of the only buildbot that runs big memory tests;
• project management of the transition from our previous custom issue tracker to Github Issues;
• migration from a previous custom CLA management bot to EdgeDB CLA bot;
• co-administering discuss.python.org including responding to moderation requests;
• co-administering core Python Discord;
• co-chairing the Python Language Summit at PyCon US;
• reviewing talk submissions on the Program Committee for PyCon US;
• facilitating cooperation with other significant Python projects: HPy, PyPy, nogil;
• public speaking (5 events in 2021, 4 events in 2022).

The missing big picture

While I find this work fulfilling and there’s always more things for me to do that other contributors suggest, one facet of the work can overshadow another. I cannot be in all places at once. Most importantly, while removing obstacles for other core developers (often volunteers) is indeed where we should put paid effort, I sometimes get asked: what’s your big project?

At this point I cannot say I had any large personal contribution over the past 18 months of work on CPython, which is ironic, given that I spent more time on it than in the preceding 11 years of core development combined. I had a few attempts at larger changes but inevitably the small busywork eats up my attention.

Adding another developer in residence more than doubles the position’s positive impact

It’s worth noting that the codebase of CPython is over a million lines of code now and even working on it full time does not mean a single person groks it all. That means that what you’re getting from Łukasz, the Developer in Residence, is something else than what you’d get from Magdalena, the Developer in Residence.

That alone means it would be worth having another person with a complementing skill set. But I believe there’s more.

Compared to working solo, having a team of two people paid full time to improve the developer experience for the rest of the core contributors, would allow us to take on larger sweeping projects. What we would end up doing would be definitely consulted with the Steering Council and we would take suggestions from the role’s sponsor. But there’s many possibilities!

We could add official build support for a new platform like iOS. We could improve test coverage of CPython tests, including coverage of trickier bits like the platform-specific code paths, C code, or code involved in CPython’s interpreter startup. We could revamp the buildbot master server to be more performant. We could be taking on implementation of accepted PEPs. We could upgrade speed.python.org to be more informative and easy to use. We could move the rest of the custom CPython bots to Github Actions, decreasing needed maintenance, improving performance and reliability. Those are just some ideas.

There is one more reason why I’m rooting for another person to join this position. Having another developer in residence would buffer any turbulence the other person has. Whenever I’m sick, or travel, or I’m stuck with a particularly stubborn problem, there would reliably be somebody else the other core developers could count on. This is important not only for them but also for me personally as it would decrease anxiety that builds up any time I’m unable to help somebody who needs me.

The ability to split work between two people is something I think about often. In theory there’s a whole team of core developers out there but since they’re mostly volunteers, I’m in no position to tell them what to do. Having a peer paid by the PSF would be different. It would be fair game to share the burden of a gnarly boring task, and that sounds like a wonderful improvement to me.

What if there isn’t another developer in residence?

I’m not saying the other person is required for me to stay productive. If we don’t find the budget for it, the situation is still better than having no developer in residence at all, I’d like to believe. So far I haven’t received much feedback on my work but I’m always open to hearing suggestions.