Hacker News new | past | comments | ask | show | jobs | submit login

I'm not sure you're envisioning the same thing I am. You would only be liable for something that you sell or otherwise make money from. You would be free to publish software, open source or not, without incurring liability as long as you don't make money from it. Whoever then uses that software for a commercial product would be incurring the full liability, and would not be able to turn around and sue up the chain.

The currently widespread practice of trusting sensitive user data to open source code without an audit (either internally or via a third-party, e.g. Red Hat) is horrifying and incredibly negligent.




> You would only be liable for something that you sell or otherwise make money from

If your business includes software in any meaningful function, you are making money from it. Any competent lawyer would be able to successfully argue that. Charging money for a license is not the only way, otherwise everybody would just switch to charging for "consultancy service", which coincidentally provides free software license, and avoid any liability.

> You would be free to publish software, open source or not, without incurring liability as long as you don't make money from it.

You as a private person would be. That's my point - that would be the only way to do open source, any corporate support of open source projects would imply full liability, which would be impossible for a product the company gets to revenue from. It would be much harder for a business to justify supporting an open source project when liability costs are added to the equation.

> The currently widespread practice of trusting sensitive user data to open source code without an audit (either internally or via a third-party, e.g. Red Hat) is horrifying

Audits cost money. Tons of money. And they don't guarantee anything - bugs in OpenSSL have not been discovered for years despite thousands of people using the code, poring over it and billions depending on it. There's no magic in "audit" that allows code to be bug-free after it - if there was such a magical procedure people would already be using it, but there's no indication anybody has invented "audit" procedure that allows to eliminate all bugs. Existing flawed procedures are already being used - every company that produces software that I ever heard about uses them - and they are not enough. So what would happen is drastically raising the costs (to the point where having a website would no longer be affordable to an average person) while not significantly improving security.


Audits cost money. Tons of money. And they don't guarantee anything - bugs in OpenSSL have not been discovered for years despite thousands of people using the code, poring over it and billions depending on it.

Any reasonable audit of OpenSSL would have said, "Don't use it."


And instead use... what? Let's say you are creating a company that needs website to sell stuff. On that website, you need TLS implementation, to process user data & credit cards. After expensive security audit that consumed most of what your angel investors can give you, you decide that anything based on OpenSSL can't be safely used. Now what?


Forks of OpenSSL. After Heartbleed, dozens of forks were made. One I think is really promising is LibreSSL which is managed by the same people who work on OpenBSD.


So, the premise there is "we couldn't find the bugs by the whole community in twenty years, but if we split the community into a dozen independent projects which do not cooperate, surely then we'll find the bugs that eluded us for two decades". Right.


If the system we're talking about existed, someone would have created a more robust implementation.


How do you know? It's not a magic law of the universe that "someone" always creates things because someone wants them. Sometimes problems are hard and just don't get solved, for a long time, even though everybody wants them solved.


But this isn't some intractable problem. For aerospace and critical infrastructure projects, for example, there is plenty of meticulously written and audited high-quality code developed at higher cost in response to the demand created by legal requirements.



I would roll my own. I'm totally confident I can do it better than the OpenSSL team. Of course, I would see what I could do with GnuTLS, first.

In practice, OpenSSL should not be considered secure. At best it can be considered as a way to stop script kiddies.


So why didn't you do that already? I mean, there are very few problems as important to software world and, frankly, to the major part of world economy, than robust electronic commerce. And encryption pays a vital role in this process. Somebody releasing 100% secure crypto implementation, guaranteed no bugs, would be doing the humanity a huge service. What prevents you from doing it now, today, this minute? Please do it right now!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: