Hacker News Reader

Comment by ryandrake | Hacker News Reader

Say goodbye to open source, then, unless he proposes a special carve-out for it.

I've actually had discussions with several people, separately and at a legal summit that specifically discussed the topic of software liability, that proposed a good solution to this:

Make the liability proportional to the degree to which you've given them the degree to find and fix any issues that might arise. If you give someone FOSS software to solve some particular problem, even a potentially-high-liability problem, you've given them everything they need to both analyze the software for potential issues, and fix them themselves. (Auto manufacturers like FOSS because it means they can always support it themselves if the vendor won't, and they have far longer support lifetimes than many other products.) So disclaiming all liability there seems reasonable, for anything short of intentional malice (e.g. backdoors).

On the other hand, if you give someone a piece of opaque proprietary software, then you're selling them a solution to a problem, and it'd better work because they can't do anything but go to you if it doesn't. They also can't introspect it, and black-box testing only goes so far. So this should increase liability. Even more so if you supply it in an obfuscated form that's difficult to reverse-engineer or test, or if you lock it down to make it irreplaceable.

The same thing would go for changing software yourself, on a high-liability device. If you don't change it, it's not your fault; if you change it, it might be your fault.

New Zealand consumer law has a requirement that goods must be 'fit for purpose'. This means that if a company sells you a clothes washer for example it must clean clothes, but if you try to wash your shoes and it breaks it's not the manufacturer's fault (unless they said it could of course).

I think something like this could apply very well to software. If someone uploads source code to github they haven't sold it to you with any purpose in mind, but commercial sales have functionality promises so they could be held to them.

warranty of merchantability and fitness for a particular purpose exist in the US. Whether it can be disclaimed is per-state though.

(Some states allow disclaiming implied warranties, some do not).

Ansible has disclaimed theirs[0]:

> #!/usr/bin/env python

# This file is part of Ansible

# Ansible is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

# Ansible is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. # You should have received a copy of the GNU General Public License # along with Ansible. If not, see <http://www.gnu.org/licenses/>.

###############################

[0]https://github.com/ansible/ansible/blob/devel/bin/ansible

That's a standard part of the disclaimer for the GPL and other licenses.

I think you misunderstand.

What i'm saying is, if sold by ansible to a consumer, these disclaimers are completely ineffective in a bunch of states.

The UCC (which is what governs these transactions) is model legislation, and provides for a few options that states can choose in various parts. One option allows disclaimer of implied warranty in all transactions. One option allows disclaimer of implied warranty in all transactions except those with consumers. One option disallows disclaimers of implied warranties.

Depending on which option a given state chose, the language you are citing would have different effectiveness.

Why hasn't the open source community figured this out? Seems like a bad idea to ever distribute source code at below the cost of liability insurance. Or should we be geo-restricting open source software? "Sorry, Linux is not available in your state."

Thanks for pointing this out. I imagine most people who publish open source software aren't aware of this risk, and will stop when they learn about it.

1. If you aren't selling it, the UCC doesn't apply. Most people don't sell their open source software.

2. Most folks are aware of this risk when they start companies to sell open source software.

3. Most do not sell the software directly to consumers, and outside of the few states that don't allow disclaiming at all, most states are fine with disclaiming warranties in b2b transactions, just not b2c.

Most don't sell the software directly at all, and those that do are often selling support anyway :)

He has some commentary on this well: https://www.schneier.com/blog/archives/2008/07/software_liab...

In summary, there wouldn't be liability for open source developers because there is no business contract. But if you run a website with open source software, you of course would still be liable for anything that happens to your customers' data. So you would probably want to buy that same open source software from someone (e.g. Red Hat), who would also be liable.

Which means, hosting/supporting open source would quickly become not worth it for any major company representing a large target for opportunistic lawyers. When you make millions from a product, you can afford a team of lawyers setting up contacts just right and fighting liability trolls. When you make zero profit, you cut the losses. Such law would spell very quick end to any corporate support of free and open source software, for liability reasons. There's a reason why all such software is accompanied with "NO WARRANTY" texts, and enforcing liability will make the corporate world to run from it. Nobody wants to be sued because they use OpenSSL and there was a vulnerability there, and that's exactly what would happen with any commercial vendor using OpenSSL if liability laws would be introduced. It doesn't matter the company didn't write OpenSSL - as soon as they use it, they are on the hook. IBM was sued not because they made Linux, but because they used it and had tons of money. And I do not see any business model that could allow companies to charge enough to cover such liabilities. Maybe for established powerhouses like Linux or for corporate foundational projects like Chrome and Darwin, but not for any lesser projects and surely not for any starting up open source with unclear revenue potential. It won't kill all open source, but it would severely hurt the ecosystem and turn it into two worlds - pure hobbyist geekery which nobody with money would touch, and formally open-source projects with strict corporate governance that has no ecosystem beyond the founding corporation.

One of the worst ideas I've heard lately, and I am genuinely baffled how a person as smart and experienced as Schneier could support it.

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.

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?

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.

https://www.wired.com/2015/05/possible-passengers-hack-comme...

http://www.cnn.com/2015/05/17/us/fbi-hacker-flight-computer-...

https://arstechnica.com/information-technology/2015/06/airbu...

https://en.wikipedia.org/wiki/Therac-25

https://en.wikipedia.org/wiki/Accidents_and_incidents_involv...

https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_...

Did I make my point clear or do I need to google for another 2 minutes to find a dozen more examples of "aerospace and critical infrastructure projects" with software problems?

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.

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!

>>But if you run a website with open source software, you of course would still be liable for anything that happens to your customers' data. So you would probably want to buy that same open source software from someone (e.g. Red Hat), who would also be liable.

As others have said, this idea is really bad.

Red Hat will start charging obscene amounts to support the legal side of the license, especially if it is used in eCommerce platforms. What about the wife and husband who want to sell hand-knitted socks online, or small businesses who do less than $250k/year online? Will they be able to afford an alternative to the LAMP stack and fully shield themselves from legal liability and the horde of lawyers who will gladly step into any loophole?

Like many, my servers were affected by Heartbleed. So if I ran OpenSSL and someone found out before I patched it (took me 24h to do so), I could be sued in that window if I hadn't bought the license to Red Hat - oh, and how about all the licenses to all the open source software that depends on it underneath, OpenSSL being one of about a hundred of those projects? Do we license GNU toolchain? What if there are buffer overflow exploits found in various tools?

> What about the wife and husband who want to sell hand-knitted socks online, or small businesses who do less than $250k/year online? Will they be able to afford an alternative to the LAMP stack and fully shield themselves from legal liability and the horde of lawyers who will gladly step into any loophole?

If mom and pop want to sell hand-knitted socks on the internet I usually recommend them to use a hosted shop solution such as shopify and its ilk. They want to sell socks, not become an expert in hosting a LAMP stack. This is how liability works for brick and mortar stores as well: They're liable if a customer electrocutes himself because some dork attached the wrong wire to the wrong metal part. That's why mom and pop stores in the brick and mortar part of the world usually don't do the electrical installation or any parts that's covered under a builder code. They hire people supposed to be experts in that field to do that work and in in turn, they get to discharge the liability to them. It's about time we treat software the same. If you want to host something, either own up to it or hire someone to do it.

Reply on news.ycombinator.com