logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Provided-as-is-without-warranty.md (3868B)


  1. ---
  2. title: Provided "as is", without warranty of any kind
  3. date: 2021-06-14
  4. ---
  5. The MIT license contains the following text, in all uppercase no less:
  6. > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  7. > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  8. > FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
  9. The BSD licenses, GPL family of licenses, Apache 2.0, Mozilla Public License,
  10. and likely any other license you'd care to name, have similar clauses of their
  11. own. It's worth taking a moment to consider the implications of this statement
  12. and what it says about the social aspects of free and open source software.
  13. Many people who rely on free and open source software feel entitled to some
  14. degree of workitude or support from the developers, or think that the developers
  15. have a responsibility to provide good maintenance, or any maintenance at all,
  16. for their work. This is simply not true. All free and open source software
  17. disclaims all responsibility for your use of them for any purpose, often in all
  18. capital letters.
  19. Some maintainers will allow you to negotiate additional terms with them, for
  20. example through the sale of a support contract, for which you may receive such
  21. a guarantee. If you have not made such an agreement with your maintainers, they
  22. have no responsibility to provide you with any support or assurance of quality.
  23. That means that they do not have to solve your bug reports or answer your
  24. questions. They do not have to review and apply your patch. They do not have to
  25. write documentation. They do not have to port it to your favorite platform. You
  26. are not entitled to the blood, sweat, and tears of the maintainers of the free &
  27. open source software you use.
  28. It is *nice* when a maintainer offers you their time, but by no means are they
  29. required to. FOSS is what **you** make of it. You have the right to make the
  30. changes you need from the software yourself, and you are the only person that
  31. you can reliably expect to do it. You aren't entitled to the maintainer's time,
  32. but you are, per the [open source definition](https://opensource.org/osd) and
  33. [free software definition](https://www.gnu.org/philosophy/free-sw.en.html),
  34. entitled to change the software, distribute your changes to others, and to sell
  35. the software with or without those changes.
  36. Though this idea is important for users of free software to understand, it's
  37. equally important that maintainers understand this as well. We have a problem
  38. with burn-out in the free software community, wherein a maintainer, feeling
  39. pressured into accepting greater responsibility over their work from a community
  40. that increasingly depends on them, will work themselves half to death for little
  41. or no compensation. You should not do this! That wasn't part of the deal!
  42. As a maintainer, you need to be prepared to say "no". Working on your project
  43. should never feel like a curse. You started it for a reason — remember
  44. that reason. Was it to lose your sanity? Or was it to have fun? Was it to solve
  45. a specific problem you had? Or was it to solve problems for someone you've never
  46. met? Remember these goals, and stay true to them. If you're getting stressed
  47. out, stop. You can always walk away. You don't owe anything to anyone.
  48. If you enjoy the work, and you enjoy helping others, that's great! Of course,
  49. you are allowed to help your users out if you so choose. However, I recommend
  50. that you manage their expectations, and make sure you're spending time
  51. cultivating a healthy relationship between you, your colleagues, and your users.
  52. FOSS projects are made out of people, and maintaining that social graph is as
  53. important as maintaining the code. Make sure everyone understands the rules and
  54. talk about your frustrations with each other. Having an active dialogue can
  55. prevent problems before they happen in the first place.