4 ms·

> But I would suggest to developers that if their contribution becomes "critical" and they don't want to bear that burden anymore, they should lose the rights t

> But I would suggest to developers that if their contribution becomes "critical" and they don't want to bear that burden anymore, they should lose the rights to make any further updates, which is, I believe, also the line that PyPI itself takes. That seems worse to me for quite a few cases that go towards actual burden beyond 2FA. That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. There is a reason why I have a "No Warrenty" clause in the licenses of my Open Source work. I have created it for others to enjoy it, but I reserve the rights to not be burdened by my users for the unpaid labor.

giaour 4y ago
> That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. The creation here is the package, not the distribution channel. You can use an alternative Pypi-compatible index (there's one built into Github, and enterprisey ones can be purchased from Azure or AWS) or you can put instructions for a local build & install on your blog. The maintainers of PyPI should be able to enforce some amount of quality control over their creation, after all.
Tainnor 4y ago
No, they simply take away your rights to publish your creation to their index. You can always publish your creation on your website or wherever.
- jka 4y ago
  > You can always publish your creation on your website or wherever. What you're suggesting wouldn't solve the problem for critical packages, though; the effect would be similar to yesterday's package unpublish issue[1] (all users of the package would have to update their dependency references despite no change in the content of the code). [1] - https://news.ycombinator.com/item?id=32026624 https://news.ycombinator.com/item?id=32026624
  - staticassertion 4y ago
    So what? Users can do that if the maintainer chooses to move hosting.
    - jka 4y ago
      Sure, accepted. That'd be a disruptive change, though, and I think that a better approach is possible. The suggestion regarding separation of (immutable) packages and policy in the article could provide some hints in that direction.
  - Tainnor 4y ago
    No, the issue yesterday is that people had to go in manually to fix their CI builds, etc. That's simply not necessary if you don't update the version and yanking is disallowed (which it should be). After that, if people want to at some point update to a newer version of the package, yes, they will have to adjust.
    - jka 4y ago
      Hrm, fair point. Although migrating 'backwards-compatibly' like that could leave a lot of people in the cold if-and-when a security update for the package is released (and we're talking about critical packages here, at least for now).
  - phlakaton 4y ago
    How about you 1) leave old versions in place on the package index, 2) declare that you will not be providing further updates to the package through the index because of this issue, 3) go publish your stuff on your website or an alternate package index?
hiphacker123 4y ago
Caveat: Not everyone in FOSS is American, but… Here in the US folks tend to have some amount of burden on their creations, tools they use, etc. Just because you put out a sign that says “Not My Problem” doesn’t make it so. Great example is these big gravel trucks hauling rocks to job sites, they’ll rain stones on the roadway and the cars and sometimes pedestrians because the workers are sometimes too careless to pull down the tarp to secure their load. They’ll put up a sign saying “DRIVER NOT RESPONSIBLE FOR DAMAGE” but the problem is they 100% are both legally and morally responsible. We also have some rules around nuisance, enticement, etc. For instance, if I have a pool and a kid jumps my meager fence and drowns I might we’ll still be responsible, at least legally, because I put up an enticing thing but failed to consider how idiots might misuse it. To me, the pool one starts to get at or near “South of Sanity” but that’s from where this mentality applies. Often you’ll get some Node project some cool tech person shits out, pimps out to social media , then abandons when the real work comes out. Folks will pick it up early on as traction builds, then be stuck with abandonware when the author gets a new job or chases a different shiny ball. I would argue you at least owe a caveat in the README about your level of commitment to the project, a bit beyond a mere “not my problem” license line.
- massysett 4y ago
  Wow. This attitude is exactly why I don’t post software anymore. I’m not delusional; I know that the world might be better off without my creations littering it. But if I were an attorney advising $Bigcorp, messages just like this one are why I would advise against posting any free software unless there is a business case for how the benefit outweighs the risk. And a disclaimer does not eliminate risk, not even the heightened disclaimer you suggest (why isn’t the disclaimer in the license enough?) The instant I have to defend a lawsuit, I’ve lost. It doesn’t matter if the suit is meritless and I “win.” Then instant someone sues me, the only winner is my lawyer. I guess this was all inevitable when people started relying on free software. They somehow think people who have given them something for free owe them something. I guess this works fine when the giver is $Bigcorp doing it for profit-seeking reasons. But this attitude is going to strangle the old small-time hobbyists who really were just scratching an itch. Now I know why some software is posted under pseudonyms.
- 4y ago
frenet 4y ago
Sure, but then who does the work? No one is an answer but not much of a solution since the problem still exists. Index or package maintainers could do the work but would often also be unpaid and burdened even more. An organization could do the work but most packages don't reach the level where they would get adopted. If being unpaid is the problem then the most obvious solution is to charge for the index, possibly only for commercial use, like a streaming service. Use some for the index and give the rest to the projects who does the work. As far as I know it wouldn't be against open source as people think non-commercial licenses are. But it would still be hard to do for various reasons. Some legitimate and some not.

giaour 4y ago

> That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. The creation here is the package, not the distribution channel. You can use an alternative Pypi-compatible index (there's one built into Github, and enterprisey ones can be purchased from Azure or AWS) or you can put instructions for a local build & install on your blog. The maintainers of PyPI should be able to enforce some amount of quality control over their creation, after all.

Tainnor 4y ago

No, they simply take away your rights to publish your creation to their index. You can always publish your creation on your website or wherever.

jka 4y ago
> You can always publish your creation on your website or wherever. What you're suggesting wouldn't solve the problem for critical packages, though; the effect would be similar to yesterday's package unpublish issue[1] (all users of the package would have to update their dependency references despite no change in the content of the code). [1] - https://news.ycombinator.com/item?id=32026624 https://news.ycombinator.com/item?id=32026624
- staticassertion 4y ago
  So what? Users can do that if the maintainer chooses to move hosting.
  - jka 4y ago
    Sure, accepted. That'd be a disruptive change, though, and I think that a better approach is possible. The suggestion regarding separation of (immutable) packages and policy in the article could provide some hints in that direction.
- Tainnor 4y ago
  No, the issue yesterday is that people had to go in manually to fix their CI builds, etc. That's simply not necessary if you don't update the version and yanking is disallowed (which it should be). After that, if people want to at some point update to a newer version of the package, yes, they will have to adjust.
  - jka 4y ago
    Hrm, fair point. Although migrating 'backwards-compatibly' like that could leave a lot of people in the cold if-and-when a security update for the package is released (and we're talking about critical packages here, at least for now).
- phlakaton 4y ago
  How about you 1) leave old versions in place on the package index, 2) declare that you will not be providing further updates to the package through the index because of this issue, 3) go publish your stuff on your website or an alternate package index?

hiphacker123 4y ago

Caveat: Not everyone in FOSS is American, but… Here in the US folks tend to have some amount of burden on their creations, tools they use, etc. Just because you put out a sign that says “Not My Problem” doesn’t make it so. Great example is these big gravel trucks hauling rocks to job sites, they’ll rain stones on the roadway and the cars and sometimes pedestrians because the workers are sometimes too careless to pull down the tarp to secure their load. They’ll put up a sign saying “DRIVER NOT RESPONSIBLE FOR DAMAGE” but the problem is they 100% are both legally and morally responsible. We also have some rules around nuisance, enticement, etc. For instance, if I have a pool and a kid jumps my meager fence and drowns I might we’ll still be responsible, at least legally, because I put up an enticing thing but failed to consider how idiots might misuse it. To me, the pool one starts to get at or near “South of Sanity” but that’s from where this mentality applies. Often you’ll get some Node project some cool tech person shits out, pimps out to social media , then abandons when the real work comes out. Folks will pick it up early on as traction builds, then be stuck with abandonware when the author gets a new job or chases a different shiny ball. I would argue you at least owe a caveat in the README about your level of commitment to the project, a bit beyond a mere “not my problem” license line.

massysett 4y ago
Wow. This attitude is exactly why I don’t post software anymore. I’m not delusional; I know that the world might be better off without my creations littering it. But if I were an attorney advising $Bigcorp, messages just like this one are why I would advise against posting any free software unless there is a business case for how the benefit outweighs the risk. And a disclaimer does not eliminate risk, not even the heightened disclaimer you suggest (why isn’t the disclaimer in the license enough?) The instant I have to defend a lawsuit, I’ve lost. It doesn’t matter if the suit is meritless and I “win.” Then instant someone sues me, the only winner is my lawyer. I guess this was all inevitable when people started relying on free software. They somehow think people who have given them something for free owe them something. I guess this works fine when the giver is $Bigcorp doing it for profit-seeking reasons. But this attitude is going to strangle the old small-time hobbyists who really were just scratching an itch. Now I know why some software is posted under pseudonyms.
4y ago

frenet 4y ago

Sure, but then who does the work? No one is an answer but not much of a solution since the problem still exists. Index or package maintainers could do the work but would often also be unpaid and burdened even more. An organization could do the work but most packages don't reach the level where they would get adopted. If being unpaid is the problem then the most obvious solution is to charge for the index, possibly only for commercial use, like a streaming service. Use some for the index and give the rest to the projects who does the work. As far as I know it wouldn't be against open source as people think non-commercial licenses are. But it would still be hard to do for various reasons. Some legitimate and some not.