"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 3:54 UTC (Thu) by milesrout (subscriber, #126894)
Parent article: "Critical" projects and volunteer maintainers

The only acceptable starting point for any discussion about this, if you want to get these maintainers on side, is to make it very clear that you understand that they are under no responsibility whatsoever. If you publish some code on the internet, especially with a gigantic ALL CAPS warning saying "THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.", anyone that treats you as having taken responsibility for the effect of defects in that code on others is a bad faith actor, in my opinion.

The starting point has to be along the lines of "Hi, I use your software. Is there some way I can help you to ensure that what shows up on PyPI is actually from you? Can I provide you with a USB security key and help you set up 2FA and cryptographic signing of packages? Is there some way I can help you to ensure that you respond to bug reports? I am willing to pay you money for your services. If you are or are not interested, please let me know." Until you are engaged in a contract for work, there are no obligations whatsoever on you for the quality of things you put out there for free on the internet covered in GIGANTIC disclaimers, nor any obligations to maintain the software, or respond to bug reports. Nor are there any obligations on you to keep a clean "supply chain" or to ensure that your account is difficult for others to access. If you want to publish your password openly on the internet, or use "hunter2" as your password, that is your prerogative, no matter how popular your code has become, until and unless you sign a contract providing otherwise.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 10:51 UTC (Thu) by willy (subscriber, #9762) [Link] (2 responses)

There's a transitivity problem with this solution. I send an email like this to the maintainer of libfoo which I use. But libfoo depends on twenty other libraries. So now the owner of libfoo has to get libbar01 to libbar20 to agree too. And their libquux001 to libquux197. And ...

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 12:45 UTC (Thu) by farnz (subscriber, #17727) [Link]

That assumes that the maintainer of libfoo bothers to do that - you may well find that you have to do the same work tracking down all of their transitive dependencies, because they're only certifying their own code, and not the code they depend upon.

Without careful communication, you can end up in two "bad" places:

You contacted the maintainer of libfoo, and got agreement, but they didn't bother getting the same agreement from their dependencies. You're still exposed by libfoo's dependencies, you just don't know it.
You contacted the maintainers of the transitive closure of your dependencies, including the maintainer of libfoo. They take it upon themselves to contact their transitive closure of dependencies, upsetting people who've been contacted 2 (or more) times because you're taking a critical dep on their software.

Supply chain security is not a trivial problem when you have a commercial relationship with your suppliers - it's even harder when they're volunteers.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 23:18 UTC (Thu) by jafd (subscriber, #129642) [Link]

No. It's all on you. You are a person who cares, so the problem is ALL yours now.

"Critical" projects and volunteer maintainers

Posted Jul 21, 2022 5:45 UTC (Thu) by brunowolff (guest, #71160) [Link]

I think people got to remember here, who's doing who a favor. There are important projects where there is effectively one maintainer who isn't paid and requests come off a bit like demands. This isn't a good way to treat people. More please, thank you and patience could be used by people asking for work to be done.