New T&C: Is PyPI moving towards a paid subscription model and/or abandoning package neutrality?

PSF
45

I see people have some questions for us and we hope this will help.

Re: this text in the new PyPI ToS, “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.”

Q: Is this an expansion of the PSF’s existing powers as PyPi’s administrative and fiscal steward?

A: It is an explicit statement of our existing authority, as we understand it and as it has been applied in practice. We already work to reduce spam, malware, confusion, fraud and other unwanted behavior on the site but there are always new ways to try to attack or otherwise disrupt a public site. The reason for the change is to make sure we can respond to security issues and unforeseen ways of abusing/misusing PyPI in a timely fashion. This language gives us the flexibility to respond swiftly, and it is also in line with the terms offered by other services that can be compared to PyPI. It does not change our non-profit mission, which is to provide CPython and the packages on PyPI to everyone forever, at no cost. We accept packages from everyone as long as it doesn’t clash with our mission and the Terms of Service.

More specifically the thought process behind this particular language went like this:

  1. We based our terms off of GitHub’s Creative Commons licensed Terms, and focused mainly on where we know that our needs and our communities’ needs differ.

  2. The clause in GitHubs Terms around user suspension is “boiler plate” and wasn’t considered beyond “looks pretty normal to me for a ToS”, so we incorporated it in our Terms without changing it

  3. We are probably correct to keep it as it reserves that right for circumstances we can’t foresee that may require such suspension, without needing to update our ToS just to perform that action.

Q: What’s the deal with PyPI Orgs?

A: These have been a long requested feature. Projects with lots of coders want to more easily do the administration to manage editing permissions inside a defined work group. Companies that fall into this category can opt in to pay for this feature. Community projects and nonprofit projects can opt in to access this feature for free. The subscription fees paid by companies to use the Orgs feature will help us support PyPI, which is a massive and constantly growing service, always requiring more bandwidth and staff attention.

Q: Who was involved in these decisions?

A: Generating revenue through PyPI features for companies has been discussed at the PSF Board level since at least 2020. The plan took a while to refine but was eventually solidified and communicated to the community in April of 2023 here (the link was also shared on this forum.) Then an update about why it was taking longer than expected was provided to the community in September of 2023, here. We were able to hire a PyPI Support person to address the backlog in July, 2024 and were just recently able to make the Orgs functionality available due to dedicated PSF staff work on our PyPI support backlog.

The recent updates to the Terms of Service were carried out by PSF staff in conjunction with our lawyer for these topics (legal issues associated with running a massive open source code-hosting site) to finalize the work around the PyPI orgs.

28 Likes
46

Dear @deb, thanks for the explanations!

Some follow-up questions.

The clause in GitHubs Terms around user suspension is “boiler plate”

Have you considered alternatives to “may terminate for any reason”?

While it does seem common in Microsoft adjacent projects (such as GitHub which is a subsidiary of Microsoft), it does not seem to be general industry standard boilerplate to me. Compare, for instance, the similar terms in GitLab (a main competitor of GitHub, and not Microsoft owned):

“4.4 GitLab may suspend Customer’s access to the Software or Supplemental Services due to a Suspension Event. As applicable, GitLab will give Customer prior notice and a reasonable opportunity to resolve or otherwise cure the issue and avoid suspension. GitLab is not required to give prior notice in exigent circumstances, or for suspension of access to avoid material harm or violation of legal or regulatory requirements. Upon resolution of a Suspension Event, GitLab will promptly restore Customer’s access to the Software or Supplemental Services as applicable.”

See GitLab Subscription Agreement | The GitLab Handbook

To me, this reads much nicer!

At least I personally would prefer that one above the currently proposed termination clause, as it gives a normal user/maintainer like me:

(a) a mandatory explanation what the problem is and/or what they are accused of, together with an explanation of “what will happen”
(b) time and opportunity to remedy any issues
(c) most importantly, a much stronger guarantee that no unreasonable or unfair use will be made of the paragraph

What do you think, @deb - also, have alternatives like this been discussed?

47

For convenience of readers of this thread, and since I am not a legal professional, I am providing a prompt that can be handed to a legal professional or a reliable AI model.

"Compare the following two termination clauses. Which one would you prefer if you were a user of the respective service, and why?

  1. “Company may suspend Customer’s access to the Software or Supplemental Services due to a Suspension Event. As applicable, Company will give Customer prior notice and a reasonable opportunity to resolve or otherwise cure the issue and avoid suspension. Company is not required to give prior notice in exigent circumstances, or for suspension of access to avoid material harm or violation of legal or regulatory requirements. Upon resolution of a Suspension Event, Company will promptly restore Customer’s access to the Software or Supplemental Services as applicable.”

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

48

So I’ve read this entire thread, the new Terms of Service, the old Terms of Use, the PyPI Acceptable Use Policy, and the blog post linked to by Ee.

I don’t see anything about the ToS that concerns me.

Well, yeah. It’s utterly impossible for the PSF to enumerate every possible case where PyPI would need to remove a package or terminate an account. This is a standard catch-all for harmful content not predicted by the Acceptable Use Policy.

Otherwise you get tiring, protracted arguments or lawsuits from people who will claim, “My package is technically not malware because it doesn’t come from the Malware region of France and therefore PyPI must continue to provide me with free hosting.”

This… metaphor… stretches my ability to take this argument in good faith: This decision hasn’t been “sudden”! Nothing is being “demolished”! Efforts have been made to announce the change!

Sorry, but what exactly is a case that we’re worried about here? Specifically? And is it a justified concern? And why do you use such an uncharitable framing for what is a fairly standard ToS?

Because it seems to me this list of questions is assigning a lot of work for someone at the PyPI or PSF to address, with the predictable reward for this work being more uncharitable interpretation.

The fact that you think there can be a “reliable AI model” to advise the PSF’s legal decisions has exhausted my patience. Getting ChatGPT’s take on this is a ridiculous suggestion. This is not a serious discussion, and I regret initially giving it the benefit of doubt.

27 Likes
49

It doesn’t really seem like the author of this thread is open to the answers they’re getting. Instead, they keep reinterpreting and moving the goal posts. At some point, you have to be willing to either say “thank you for the answers” or decide you’re not happy with the answers and stop using PyPI because of it. At some point, “What about this” or “I would be happy with this” isn’t a good use of people’s time. Based on the responses in this thread from others, the PSF has put due diligence and consideration into the changes, and the community seems supportive of their explanations.

26 Likes
50

Honestly, I’d rather the limited pool of mostly volunteer PyPI admins could react immediately to and don’t have to waste any more time than necessary on spam/malicious users. Having to mindlessly fill out “no, you can’t use PyPI as a free mass storage service” emails then waiting a prolonged courtesy period before being allowed to undo any damage sounds like a pretty big loss for everyone else using the service.

I’d also be particularly uncomfortable with the time constraint clauses in the former since they insinuate a breach of contract if admins do not prioritise these miscreant users over the very long queue of genuine users needing admin support.

19 Likes
51

This is the GitLab Subscription Agreement, i.e. the agreement between GitLab and their paying customers. It’s not a blanket AUP or T&C for all users/visitors to GitLab, which is what it would need to be to be the equivalent of PyPI’s terms. In other words, this is an apples-to-oranges comparison.

If you visit GitLab’s AUP, you’ll see that they have a virtually identical clause to GitHub:

We reserve the right to take any action we feel is appropriate to enforce this policy. We may take action to prevent use of our services which goes against the spirit of this policy, even if that use is not expressly forbidden.

Source: GitLab Acceptable Use Policy | The GitLab Handbook

Can we not take the conversation down this track? As above demonstrates, context matters; you can’t produce whole conclusions from fragmentary statements.

(I suspect a legal expert would tell you this; the AI on the other hand would say something confidently incorrect.)

15 Likes
52

@davidism, I strongly contest your statement. Is this made in good faith?

The goal posts have not moved. I had a list of questions, and others added a few as well.

These are simple questions, so it also feels strange to talk about “goals”, especially when people try to follow up with clarifications.

As a reminder, the list:

  1. when was this change of T&C decided and by whom?
  2. are there minutes or other documents of the decision?
  3. what is the key rationale behind the paragraph “… PSF reserves the right to refuse service to anyone for any reason at any time.”?
  4. is there a clear legal assessment on whether moving to a paid service model jeopardizes the 501(c) US non-profit status?
  5. does or did the aforementioned decision require a vote by the meeting of members?
  6. on the confirmed paid services or products, are there planned collaborations with one or more corporations, possibly hyperscalers?
  7. Your response above seems to imply (though does not state explicitly) that the “paid organization” featured linked above is the only paid feature or product planned over the next years. Is this true or false, to the best of your knowledge?

Current state is, there has been no direct reply to these, but some indirect replies. So please assume good faith in that I am trying to get direct answers.

Summary from my perspective on where we are:

  1. when was this change of T&C decided and by whom?
  2. are there minutes or other documents of the decision?

Not answered by @deb above. It is said the plans were “communicated” and “discussed”, but there was no clear statement on who (which person, body, etc) decided when.

  1. what is the key rationale behind the paragraph “… PSF reserves the right to refuse service to anyone for any reason at any time.”?

@deb replied that this was copied from GitHub T&C, and there were no further considerations.

I followed up on this on the options considered, to clarify whether options were considered and if yes which.

  1. is there a clear legal assessment on whether moving to a paid service model jeopardizes the 501(c) US non-profit status?
  2. does or did the aforementioned decision require a vote by the meeting of members?
  3. on the confirmed paid services or products, are there planned collaborations with one or more corporations, possibly hyperscalers?
  4. Your response above seems to imply (though does not state explicitly) that the “paid organization” featured linked above is the only paid feature or product planned over the next years. Is this true or false, to the best of your knowledge?

These were not commented upon by @deb or anyone else, as far as I can see.

In summary, I think the above are reasonable questions and it would be great if we hear in response from PSF leadership.

2 Likes
53

Small follow-up on the legalese:

a. @woodruffw’s comment that “GitLab T&C are basically the same”
b. @AlSweigart’s “It’s utterly impossible for the PSF to enumerate every possible case where PyPI would need to remove”

There are two connected replies here.

b. - @AlSweigart relies on incorrect premise, implicitly a false dichotomy, that either you give PSF blanket power to do anything, or you have to enumerate every single case where PSF can act (which is of course impossible).

This implied dichotomy is not true - you can outline a policy, and then tie the empowerment to act to that policy.

An example of this are the GitLab T&C.

a. @woodruffw, even if we look at the AUP, the pattern is the same - no unrestricted power. This is not a blanket empowerment, but tied to the usage policy that is explicitly mentioned. The verbatim sentence is

We reserve the right to take any action we feel is appropriate to enforce this policy.

So, this has actions tied to a concrete policy, so in court both sides would be forced to argue within the boundaries of the policy as a context.

The Microsoft/GitHub version, in comparison, removes this restriction on the powers of PSF.

54

It may be worth putting this up as the start of a FAQ page alongside the new terms.

8 Likes
55

I am not a reliable AI model, but as a real human I would definitely prefer the second version. It is short, to the point, and reasonable for an unpaid service. The first version is legalese gibberish.

2 Likes
56

No. I don’t know whether this is intentional or not, but you’ve excluded the second sentence, which I intentionally included in the previous post. Here it is again:

We reserve the right to take any action we feel is appropriate to enforce this policy. We may take action to prevent use of our services which goes against the spirit of this policy, even if that use is not expressly forbidden.

(Emphasis mine.)

This sentence ensures that GitLab reserves its rights beyond the language of the policy, which is what I suspect every AUP that passes legal review for an online service does.

Finally, if this doesn’t satisfy you, please see GitLab’s website terms of use:

7.1. GitLab may terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately.

Source: GitLab Website Terms of Use | The GitLab Handbook

8 Likes
57

@fkiraly Members elect a board to make these decisions. All the PSF Board minutes are available online. Please feel free to do your own research instead of demanding work from other people.

PSF Meeting Minutes | Python.org

8 Likes
58

@bryevdv, I merely ask, I do not demand.

Regarding your suggestion to “do your own research” first: there are about 10 board meetings per year, with 10 pages of minutes each. Over the last 5 years, that would be approx 500 pages of minutes. Decisions are not explicitly listed in an index, so the best approch to satisfy your suggestion may be to read 100s of pages of dense material.

Were you suggesting I need to do that before I can ask here? What would your approach to the minutes be?

Plus, let’s say I have done that and have not found a relevant line in the minutes. What would the next step be?

Further, just to clarify, I am not demanding anything, I am merely hoping to eventuelly get answers to some questions which do seem sensible. I would understand if someone else would say, answers can be demanded since leadership has certain standards of transparency to adhere to, but I am not trying to imply that, to be clear.

1 Like
59

We are suggesting you do that before you ask someone at the PSF or PyPI to do it for you.

60

I believe this topic has run its course, and continuing is not going to do anybody any good.

If the terms of use are not to your liking, don’t use the service.

17 Likes
61

I have done that and have not found a relevant line in the minutes.

1 Like
62

In the meantime, 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. Including me (I don’t know the answers to your questions, but do not assume bad faith or ill intent on your part - I agree they’re “reasonable questions”).

10 Likes
63

@tim.one, thanks for the advice, though I am somewhat shocked to hear this.

I am really trying to give people the benefit of the doubt.

Your “people don’t want” and following seems to imply, to me, at best, an unpleasant toxic atmosphere with cult-like groupthink, at worst an environment that organizes harrassment against those raising topics that “must not be talked about”, similar to the state controlled mobs targeting intellectuals and artists in the Soviet Union, where any attempts at defense are used to further condemn the victim.

This seems to be quite harsh, and I do not share this assessment! At least, I try to be charitable and assume best intentions. And apologies in advance, if I misinterpreted what you were implying.

For instance, @brettcannon has, in the first response even, directed me helpfully to the legal team of PSF, the e-mail address legal-at-psf!

There has been no response yet, but it has been only a week. I am sure they will eventually respond, and clear up all the questions that the communtiy might have.

For convenience after a couple small detours, the list of questions again:

  1. when was this change of T&C decided and by whom?
  2. are there minutes or other documents of the decision?
  3. what is the key rationale behind the paragraph “… PSF reserves the right to refuse service to anyone for any reason at any time.”?
  4. is there a clear legal assessment on whether moving to a paid service model jeopardizes the 501(c) US non-profit status?
  5. does or did the aforementioned decision require a vote by the meeting of members?
  6. on the confirmed paid services or products, are there planned collaborations with one or more corporations, possibly hyperscalers?
  7. Deb’s response above seems to imply (though does not state explicitly) that the “paid organization” featured linked above is the only paid feature or product planned over the next years. Is this true or false, to the best of your knowledge?
2 Likes
64

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.

Furthermore, in my experience (and I’ll repeat, this is only my experience) the times when this tendency is at its worst is when people try to represent an uncomfortable or controversial topic as “neutral” or “just about the facts”. People’s feelings are always involved, because pretty much everyone is a volunteer and has invested a certain level of their own identity in the community. Trying to keep to the facts in that situation just makes people with an emotional investment feel shut out.

To give a specific example, I’m heavily involved in the packaging community, and have seen it grow from small beginnings to the point it’s at now, where it’s struggling under the weight of its own popularity. As a result, I’m painfully aware of all the good work being done, and how the individuals involved are doing their best under what are frankly near-impossible conditions[1]. And remember - these are volunteers, there’s nothing but their own interest and integrity stopping them from just walking away. The questions you ask are not unreasonable, and the concerns you imply are also fair. However, you also imply[2], in those same questions, a potential “hidden agenda”. Given how long I’ve worked with the PyPI staff[3], it’s hard for me not to respond to your questions personally, in defense of my colleagues.

The only solution that I can see is to back away from offering opinions, and let the people who have volunteered to act as a formal voice here comment. It’s hard to do that when the formal responses are criticised for being insufficient, or unacceptable, but that just pushes us back into the same loop. At some point, the answer genuinely is just “sorry, but that’s all there is”.

Maybe all of this means that the Python community needs some sort of fundamental change to survive in what is an increasingly corporate and contractually dominated world. Python is essential to so many businesses nowadays that maybe a purely volunteer basis simply can’t work any more. I hope that’s not true - I feel that the volunteer nature of the Python community is a key part of what makes it what it is - but regardless, that’s a huge question that we’re unlikely to be able to answer here.

  1. I would have burned out a long time ago ↩︎

  2. whether intentionally or not ↩︎

  3. and one reason I tend to distinguish between the PyPI staff and the PSF is because I haven’t worked closely with any of the PSF staff ↩︎

19 Likes