5 ms·

It's kind of amazing that 95% of gripes about open source projects and who is supposed to support them to what extent can be solved by open source authors being

It's kind of amazing that 95% of gripes about open source projects and who is supposed to support them to what extent can be solved by open source authors being upfront about those expectations. If you're releasing something and have no intention of supporting it, simply put "NOT INTENTED FOR USE IN PRODUCTION" at the very top of the readme file. It's that easy, imho.

ptboyer 4y ago
Wouldn't a LICENSE file already do this for the most part? MIT: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED ..." and so forth.
- skybrian 4y ago
  This doesn't tell the reader anything because solid open source projects that can be used in production and those that are just experiments will often have the same LICENSE. All open source licenses disclaim liability. So if you really want to discourage usage, you should say something in the README.
  - betwixthewires 4y ago
    Or, abide the license. Asses for yourself if it can be used in production in your business. Be prepared to be wrong about that. If you have a hard time discerning, abide the license, don't use code in production that disclaims liability, ever. If it disclaims liability the onus is on you.
    - Dylan16807 4y ago
      > Asses for yourself if it can be used in production in your business. So waste everyone's time instead of just telling them? > If you have a hard time discerning, abide the license, don't use code in production that disclaims liability, ever. That's basically all code so that's not useful advice.
      - betwixthewires 4y ago
        Since when it is a waste of time to carefully figure out if you should base your important business on someone else's work? You know what's a waste of time? Telling people something you already told them in your license. If we did as you ask, someone would drop a project expecting not to when they started, or someone would maintain one with your warning, and people would say "mean it! This guy duplicated your code expecting you not to maintain it, and you did, so you wasted his time! Put a third warning in!" Adding a warning that's already in the license does not convey useful information, it does not help anyone discern anything. > not useful advice. It's very useful advice. If you can't discern whether something FOSS will be useful to your business or not then don't base your business on FOSS code. Simple.
        Dylan16807 4y ago
        >You know what's a waste of time? Telling people something you already told them in your license. Uh, the whole point of the comment was that license doesn't say how serious the project is. It's not about boilerplate disclaimers... > It's very useful advice. If you can't discern whether something FOSS will be useful to your business or not then don't base your business on FOSS code. Simple. "don't use code in production that disclaims liability" is useless. All code disclaims liability. The "if you can't discern if it's useful" doesn't convert such a pointless phrase into good advice. It's like saying "if you can't determine which foods are healthy, don't eat food that comes in amounts". If someone can determine, the advice doesn't apply, and if they can't determine... you just told them to starve? That advice helps nobody.
        betwixthewires 4y ago
        Food, that analogy doesn't apply because nobody is dying here. And it is about boilerplate disclaimers. That's my entire point. "Add a boilerplate disclaimer reiterating what your license says if you really really mean it" is what your argument boils down to. How do you make it not boilerplate? Require then to write a 200 page report in their own words? If the license disclaimer means nothing, no number of disclaimers will mean anything more. If the advice helps nobody so will an additional disclaimer.
steveklabnik 4y ago
It’s not that easy. https://github.com/reactjs/reactjs.org/issues/3896 https://github.com/reactjs/reactjs.org/issues/3896
- m3047 4y ago
  This sounds like most of web scraping and "integrations" generally, by commercial companies, largely black or grayboxed: they just don't read the README, because they're busy scraping.

ptboyer 4y ago

Wouldn't a LICENSE file already do this for the most part? MIT: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED ..." and so forth.

skybrian 4y ago
This doesn't tell the reader anything because solid open source projects that can be used in production and those that are just experiments will often have the same LICENSE. All open source licenses disclaim liability. So if you really want to discourage usage, you should say something in the README.
- betwixthewires 4y ago
  Or, abide the license. Asses for yourself if it can be used in production in your business. Be prepared to be wrong about that. If you have a hard time discerning, abide the license, don't use code in production that disclaims liability, ever. If it disclaims liability the onus is on you.
  - Dylan16807 4y ago
    > Asses for yourself if it can be used in production in your business. So waste everyone's time instead of just telling them? > If you have a hard time discerning, abide the license, don't use code in production that disclaims liability, ever. That's basically all code so that's not useful advice.
    - betwixthewires 4y ago
      Since when it is a waste of time to carefully figure out if you should base your important business on someone else's work? You know what's a waste of time? Telling people something you already told them in your license. If we did as you ask, someone would drop a project expecting not to when they started, or someone would maintain one with your warning, and people would say "mean it! This guy duplicated your code expecting you not to maintain it, and you did, so you wasted his time! Put a third warning in!" Adding a warning that's already in the license does not convey useful information, it does not help anyone discern anything. > not useful advice. It's very useful advice. If you can't discern whether something FOSS will be useful to your business or not then don't base your business on FOSS code. Simple.
      - Dylan16807 4y ago
        >You know what's a waste of time? Telling people something you already told them in your license. Uh, the whole point of the comment was that license doesn't say how serious the project is. It's not about boilerplate disclaimers... > It's very useful advice. If you can't discern whether something FOSS will be useful to your business or not then don't base your business on FOSS code. Simple. "don't use code in production that disclaims liability" is useless. All code disclaims liability. The "if you can't discern if it's useful" doesn't convert such a pointless phrase into good advice. It's like saying "if you can't determine which foods are healthy, don't eat food that comes in amounts". If someone can determine, the advice doesn't apply, and if they can't determine... you just told them to starve? That advice helps nobody.
        betwixthewires 4y ago
        Food, that analogy doesn't apply because nobody is dying here. And it is about boilerplate disclaimers. That's my entire point. "Add a boilerplate disclaimer reiterating what your license says if you really really mean it" is what your argument boils down to. How do you make it not boilerplate? Require then to write a 200 page report in their own words? If the license disclaimer means nothing, no number of disclaimers will mean anything more. If the advice helps nobody so will an additional disclaimer.

steveklabnik 4y ago

It’s not that easy. https://github.com/reactjs/reactjs.org/issues/3896 https://github.com/reactjs/reactjs.org/issues/3896

m3047 4y ago
This sounds like most of web scraping and "integrations" generally, by commercial companies, largely black or grayboxed: they just don't read the README, because they're busy scraping.