New terms of service for PyPI

On February 25, the Python Software Foundation (PSF), which runs the Python Package Index (PyPI), announced new terms of service (ToS) for the repository. That has led to some questions about the new ToS, and the process of coming up with them. For one thing, the previous terms of use for the service were shorter and simpler, but there are other concerns with specific wording in the new agreement.

According to the announcement, which was posted by PyPI administrator (and PSF director of infrastructure) Ee Durbin, the new terms will go into effect on March 27. Anyone continuing to use PyPI after that date is implicitly agreeing to the terms. Durbin outlined the history of the terms, going back to the initial opening for uploads in 2005; the terms have been updated twice since, in 2009 and in 2016, they said. In the past, the terms were primarily meant to protect PyPI and the PSF; now the organization has worked with its legal team to create the new terms. They are meant to be compatible with the old, "while adding as permissive a set of new terms as possible to ensure that PyPI users and the PSF are protected".

Another reason for the update is to help enable the Organization accounts feature for PyPI. That feature, which was announced almost two years ago during PyCon in 2023, has languished, in part because of staffing difficulties that likely stem from unanticipated demand. Organizations will be able to apply for special status on PyPI, with their own namespace that can house multiple projects; organizations for community projects would be free, while companies would pay a small fee, with the revenue targeted for PyPI operations and maintenance. The feature is currently in a closed beta and is expected to be rolled out more widely soon.

Questions

A few days after the ToS announcement, Franz Király posted some questions in the PSF category of the Python discussion forum. He wondered whether the PSF was moving PyPI "to a paid subscription model" and if it was "looking to abolish package neutrality on pypi". He pointed to the "Paid Services" section of the new ToS and highlighted some of the text from the "PSF May Terminate" clause:

PSF has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. PSF reserves the right to refuse service to anyone for any reason at any time.

To him, those changes might indicate the PSF is fundamentally changing course with PyPI. Beyond that, though, he suggested that there should have been some discussion with the community ahead of making a change of this sort. If that kind of discussion did happen, he asked that the PSF leadership say so and "explain where and how the decision has been taken" with a link to any public minutes.

Durbin was quick to reply, trying to keep the thread from "spiraling from FUD to chaos over the weekend". They said that the new ToS came about "to formalize the relationship and protections for maintainers, the pypi admins, and PSF in order to move forward with paid Organization accounts for corporate users". The Organization accounts will be completely optional and only cost money for "paid corporate users"; community projects will be provided the accounts "at no cost, forever" if they want them. On the question of whether the PSF is looking to abolish package neutrality for PyPI, Durbin had a one-word answer: "No".

Antoine Pitrou noted that the termination wording applies more widely than only to Organization accounts. He wondered why it was needed to move forward on the new feature. Király agreed, saying that instead of formalizing protections for the maintainers of PyPI packages, "the paragraph in fact seems to strip maintainers (as well as users) of any and all protections".

Guillaume Lemaitre also wondered about the termination clause, contrasting it with the clause about when the PSF can remove content. The content clause specifically calls out content "that, in our sole discretion, violates any laws or PSF terms or policies" for removal. Brett Cannon suggested that the likely reason for the broad termination clause is that the lawyers for the PSF, which is a US non-profit, "require it to be this broad to protect the PSF from lawsuits".

Cannon also did not think it made any real change to what the PSF can do under the existing terms. Király strongly disagreed with that interpretation, saying that the absence of a termination clause in the old terms would actually provide some level of protection to users and developers, because it would fall back to the norms and precedents from court cases in the US. Cannon argued that both he and Király were speculating and suggested contacting the email address specified in the new ToS. Király did so on March 2; as of March 8, there had not yet been any reply to the email.

Procedures

Meanwhile, there were some procedural questions that Király and others raised in the thread, which he gathered up with the hope that the PSF board could address them. He wondered when the decision was made to switch to a new ToS, if there were minutes from the meeting where that happened or was discussed, whether the membership of the PSF was consulted, and so on. Pitrou noted that, as a PSF member, he could confirm that there was no consultation of the members on the change to the PyPI terms.

A few others had views similar to Cannon's that the new terms did not really change anything of note. Both William Woodruff and Marc-André Lemburg had that take, with the latter noting that "getting some more community feedback upfront would probably have helped" with the reception of the new terms. Paul Moore agreed as well:

My personal view is that PyPI have always been free to do pretty much what they choose - that's the nature of a free service (you pay nothing, so you can expect nothing). These new T&Cs basically set the expectations for paying customers to be the same, just using legal terms that will make sense to such customers.

[...] Getting that email out of the blue was a bit of a shock. And I'm closely involved with the packaging community, so I would have expected to have had at least some indication that this was on its way.

Frankly, I hope that at least some of the funds PyPI get from the new paid features will be invested in improving their community involvement and consultation. I don't know to what extent the PyPI admins currently expect this to be coming from the PSF, but if they do, then it's not working very well :(

Moore noted that he did have some concerns about the new paid Organization feature for PyPI, mostly around the likelihood of prioritizing features for the "paying customers" over those of the regular, community "customers", but those were not connected to the changes to the terms. In a reply to Woodruff, Király outlined some of the possible conflicts that could come from the new terms:

Terms up until now: PSF can terminate in case of wrongdoing ("policy violation") or for other clearly stated "good reason". E.g., if you upload a virus package, violate someone's trademark, typosquat, etc.

Terms from March: PSF can terminate for any reason, including what most people might consider "bad reasons". E.g., for the purpose of illustration and without implying any intent here: selling a coveted project name on pypi to the highest bidder. Or, resolving name conflicts always in favour of a US entity. Or shutting down projects from a country the US is in a trade war with.

Of those commenting in the discussion, only Pitrou seemed to share some of Király's concerns: "the fact that they are now being bluntly explicit in their 'we do what we want' policy is certainly cause for concern". The other commenters largely agreed that there was no actual change to what the PSF can and cannot do.

Response

PSF Executive Director Deb Nicholson posted answers to some of the questions raised in the thread and perhaps as a response to Király's email; she also agreed that there was no real material change in the powers, just in the wording. "It is an explicit statement of our existing authority, as we understand it and as it has been applied in practice." The actual terms were based on the GitHub Terms of Service and that the "with or without cause" and "for any reason at any time" language are seen as standard for services similar to PyPI. That wording is needed to allow PyPI staff to quickly respond to new types of abuse, she said. The idea to generate revenue for PyPI by offering paid accounts, which is what the Organization feature is, came from the PSF board, with discussions on that stretching back to 2020; the ToS updates were done by PSF staff in conjunction with the foundation's lawyer.

As might be guessed, Király had some follow-up questions with regard to the termination clause. There was more back and forth between Király and others about the specifics, where Király tried to respond to most posts. That hearkened back to a somewhat similar "discussion" from last year, which led to a three-month suspension for Tim Peters. As with that one, the responses are polite and on-topic, but the volume and somewhat repetitive nature of them leads to complaints. The parallels were not lost on Peters, who had some thoughts:

I advise you not to reply to messages from those who cannot answer your specific questions. People overwhelmingly don't want "a discussion" about potentially unpleasant foundational issues. and routinely assume bad faith and ill intent on the part of those who raise them. They can't be dissuaded, and trying only makes it worse.

You'll get forthright answers from those who know, or you won't. Nobody else matters here.

Király was surprised to hear that such discussions are not welcome; he was worried that it implied a kind of "groupthink" within the Python community, though he did not believe that was the case. Moore had a level-headed response that suggested the underlying problem may be that the format of a text-based forum does not lend itself to those kinds of discussions:

I think it's more a case that a lot of people have found that discussions about such potentially unpleasant foundational issues tend to be both unproductive and emotionally draining, and simply aren't worth getting into. The topics themselves are worth discussing, but it doesn't seem that this environment (for whatever reason) is the right way of doing so. You could say that it's because this environment is "unpleasant" and "toxic", but I think that's unfair, and potentially contributes to the sort of atmosphere we'd like to avoid. Rather, it's just that people have divergent views, and a text-based online forum isn't the best place for nuance and expressing willingness to discuss while remaining strongly opposed to another person's views.

That was the final word on the subject, as one of the forum moderators, David Lord, closed the thread due to multiple posts that had been flagged and because, he said, the thread was no longer going in a "productive, on-topic direction". It is unfortunate that discussions of this nature so often meet that fate, but moderation within communities is certainly hard. There are still some unanswered questions at this point—reasonable questions, at least in the eyes of some—and it is unclear if the answers will ever come to light.

Over the decades, PyPI has gone from being the CheeseShop—a whimsical Monty Python reference—in the beginning, to soon becoming a much more serious repository with actual paying customers. It is, however, fundamentally a community resource and it is not surprising that some in the community feel a certain level of ownership based on their contributions. Nearly all of the work that has gone into PyPI has been done by unpaid volunteers; the vast majority of the packages stored there come from unpaid community members as well. It may well feel like something of a slap in the face to be told that they can be denied access for any reason, without any recourse. Maybe that was always true, but seeing it in black-and-white terms can be, not surprisingly, somewhat difficult.

While the PSF clearly holds title to PyPI, it would be not much of a cheese shop without those countless contributions. It behooves the organization to remember that and to try to find ways to communicate changes of this nature so that the community is not surprised by them a month before they go into effect. Better still would be to find ways to include the community in the process, so that those who helped make PyPI what it is today feel that they have a voice.