5 ms·

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

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.
        Dylan16807 4y ago
        > Food, that analogy doesn't apply because nobody is dying here. A typical business is going to die if it can't get software. > 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. No, please read what people are saying. The request is for a basic description of how serious the project is. Whether it's a super slapdash proof of concept, or a basic implementation with half the features stubbed out, or a mostly complete but unstable project that, or something battle-tested and heavily documented and maintained full-time, or other places in between or outside those lines. Whether they even want bug reports; whether they even want patch submissions. All of those very different projects could have the exact same license. The exact same disclaimers. The request is for information that does not belong in a license, and is not put into a license. Nobody is asking for a restatement or rewrite of the license.

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.
        Dylan16807 4y ago
        > Food, that analogy doesn't apply because nobody is dying here. A typical business is going to die if it can't get software. > 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. No, please read what people are saying. The request is for a basic description of how serious the project is. Whether it's a super slapdash proof of concept, or a basic implementation with half the features stubbed out, or a mostly complete but unstable project that, or something battle-tested and heavily documented and maintained full-time, or other places in between or outside those lines. Whether they even want bug reports; whether they even want patch submissions. All of those very different projects could have the exact same license. The exact same disclaimers. The request is for information that does not belong in a license, and is not put into a license. Nobody is asking for a restatement or rewrite of the license.