2 ms·

No one has an ethical responsibility to provide free security auditing to trillion dollar companies.

hnlmorg 6mo ago
That’s a strawman argument because we aren’t talking about security auditing for trillion dollar companies. We are talking about developers having ethical ownership for communicating their project responsibly. That means being honest about when a pet project is just a pet project rather than talking about every POC as if it’s production ready. And it’s disingenuous to spin this as “only trillion dollar companies use open source” because we all know that isn’t even remotely true.
- ForHackernews 6mo ago
  Anyone who is making money off my open source work can PAY ME if they want signed, reproducible builds. Anyone who is not paying me can use what I generously give away for free without THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Concerned about security? Good for you, build it yourself.
  - hnlmorg 6mo ago
    You’re missing the point again, but let’s just agree to disagree because it sounds like your more concerned about money than the topic being discussed. Which is fine. It’s an opinion. I just don’t agree that it’s relevant
- jjav 6mo ago
  > That means being honest about when a pet project is just a pet project rather than talking about every POC as if it’s production ready. And who isn't honest about it? Read the contract you have with the provider. There is a way to legitimately expect production-ready libraries: You sign a purchase order for the right to use that code for a year (typically, or multi-year) and pay a quite substantial amount of money for that. Then you have purchased the right to expect a certain level of quality (details can be in the contract and reflected in the price). If you're using something for free without having agreed to such a contract and paid the vendor accordingly, then you can expect exactly as much as you paid for it.
  - hnlmorg 6mo ago
    You’re twisting my argument. I’m not saying maintainers are obligated to make their code production ready. I said their READMEs should accurately represent the state of the project. If you, or anyone else, thinks that is an unfair assessment or that I should have to pay for a README not to claim to be production ready when it’s a POC, then you had a very weird view on how much effort it takes to write the line “this is an untested beta”
    - jjav 6mo ago
      > I said their READMEs should accurately represent the state of the project. The state of expectations is usually in the LICENSE file, not in the README. But it's there in the repository, in most cases. I do agree that some maintainers forget to include the LICENSE file (or equivalent), which is a mistake. The terms of use are quite important.
      - hnlmorg 6mo ago
        > The state of expectations is usually in the LICENSE file, not in the README. No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code. Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is. It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it. All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is. All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.
        jjav 6mo ago
        It is interesting how every time this topic comes up it ends up with people for the most part in one of two camps: either the license is meant to be taken literally, or those who believe otherwise. Of all the files in a repo, the LICENSE file is the one most important to take literally since it is a legal document. So when it says something like (this from MIT license): THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. That is actually exactly what it means. There is specifically not even an implied suggestion that the software is suitable for your use. If you want any kind of guarantee of the code being of any use to you, sign a contract and pay for it. Unless you pay for that contract, nobody owes you any kind of hint as to whether the code is useful for anything. It very clearly says so in the LICENSE file.

That’s a strawman argument because we aren’t talking about security auditing for trillion dollar companies. We are talking about developers having ethical ownership for communicating their project responsibly. That means being honest about when a pet project is just a pet project rather than talking about every POC as if it’s production ready. And it’s disingenuous to spin this as “only trillion dollar companies use open source” because we all know that isn’t even remotely true.

ForHackernews 6mo ago
Anyone who is making money off my open source work can PAY ME if they want signed, reproducible builds. Anyone who is not paying me can use what I generously give away for free without THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Concerned about security? Good for you, build it yourself.
- hnlmorg 6mo ago
  You’re missing the point again, but let’s just agree to disagree because it sounds like your more concerned about money than the topic being discussed. Which is fine. It’s an opinion. I just don’t agree that it’s relevant
jjav 6mo ago
> That means being honest about when a pet project is just a pet project rather than talking about every POC as if it’s production ready. And who isn't honest about it? Read the contract you have with the provider. There is a way to legitimately expect production-ready libraries: You sign a purchase order for the right to use that code for a year (typically, or multi-year) and pay a quite substantial amount of money for that. Then you have purchased the right to expect a certain level of quality (details can be in the contract and reflected in the price). If you're using something for free without having agreed to such a contract and paid the vendor accordingly, then you can expect exactly as much as you paid for it.
- hnlmorg 6mo ago
  You’re twisting my argument. I’m not saying maintainers are obligated to make their code production ready. I said their READMEs should accurately represent the state of the project. If you, or anyone else, thinks that is an unfair assessment or that I should have to pay for a README not to claim to be production ready when it’s a POC, then you had a very weird view on how much effort it takes to write the line “this is an untested beta”
  - jjav 6mo ago
    > I said their READMEs should accurately represent the state of the project. The state of expectations is usually in the LICENSE file, not in the README. But it's there in the repository, in most cases. I do agree that some maintainers forget to include the LICENSE file (or equivalent), which is a mistake. The terms of use are quite important.
    - hnlmorg 6mo ago
      > The state of expectations is usually in the LICENSE file, not in the README. No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code. Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is. It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it. All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is. All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.
      - jjav 6mo ago
        It is interesting how every time this topic comes up it ends up with people for the most part in one of two camps: either the license is meant to be taken literally, or those who believe otherwise. Of all the files in a repo, the LICENSE file is the one most important to take literally since it is a legal document. So when it says something like (this from MIT license): THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. That is actually exactly what it means. There is specifically not even an implied suggestion that the software is suitable for your use. If you want any kind of guarantee of the code being of any use to you, sign a contract and pay for it. Unless you pay for that contract, nobody owes you any kind of hint as to whether the code is useful for anything. It very clearly says so in the LICENSE file.