ofo押金是否可以起诉_是否可以因应用程序中的错误而被起诉？

ofo押金是否可以起诉

An article which recently appeared on TechRepublic will strike fear into the heart of all developers and software manufacturers: Should developers be sued for security holes?

最近在TechRepublic上发表的一篇文章将使所有开发人员和软件制造商的内心深感恐惧： 是否应因安全漏洞而起诉开发人员？

The question was posed by University of Cambridge security researcher Dr Richard Clayton. Software security losses cost billions per year and he wants vendors to accept responsibility for damage resulting from avoidable flaws in their applications. He argues that companies should not be able to rely on End-User License Agreements which waive liability.

这个问题是由剑桥大学安全研究员理查德·克莱顿博士提出的。 软件安全损失每年造成数十亿美元的损失，他希望供应商对因其应用中可避免的缺陷而造成的损坏承担责任。 他认为，公司不应依赖于免除责任的最终用户许可协议。

While no legislation has been passed, committees in the UK and Europe have been considering the requirement for several years. Clayton wants applications to be assessed to consider whether the developer has been negligent. He argues that the threat of court action would provide an incentive to minimize security holes:

尽管尚未通过任何立法，但英国和欧洲的委员会已经在考虑该要求了几年了。 Clayton希望对应用程序进行评估，以考虑开发人员是否过失。 他认为，法院诉讼的威胁将提供一种动机，可以最大程度地减少安全漏洞：

If you went down to the corner of your street and started selling hamburgers to passers-by they can sue you [in the case of food poisoning].

如果您走到街角，开始向路人出售汉堡包，他们可以起诉您(在食物中毒的情况下)。

It’s not going to be easy. There’s going to be a lot of moaning from everybody inside [the industry] and we’re going to have to do it on a global basis and over many years.

这并不容易。 [行业]内部的每个人都会抱怨很多，我们将不得不在全球范围内并且在很多年内做到这一点。

Understandably, the software industry has fought back with several points:

可以理解，软件行业进行了以下几点反击：

• No one purposely makes insecure software, but the complexity of code can introduce unforeseen errors.
  没有人故意制造不安全的软件，但是代码的复杂性会引入无法预料的错误。
• When a home is burgled, the victim doesn’t usually ask the maker of the door or window to compensate them.
  当房屋被盗时，受害人通常不会要求门窗制造商赔偿他们。
• Legislation would stifle innovation and manufacturers would prevent application interoperability to guard against undesirable results.
  立法将扼杀创新，制造商将阻止应用程序的互操作性以防止不良后果。
• Who would be liable for open source software?
  谁将对开源软件负责？

诉讼失误 (Litigious Lapses)

Clayton’s primary concern is security holes, but what does that mean? Bugs. It doesn’t matter whether they are caused by the coder’s inexperience, lack of testing or unforeseen circumstances owing to a combination of factors.

克莱顿的主要担忧是安全漏洞，但这意味着什么？ 虫子。 不管是由于编码人员的经验不足，缺乏测试还是由于多种因素导致的不可预见的情况所致。

However the legislation is worded, if someone can sue for security issues, they can sue for any bug. Did an application crash before you saved 20 hours of data entry? Did an email or Twitter message reach an unintended recipient? Did Angry Birds cause distress by failing to update your high score?

但是，法律的措辞是这样的，如果有人可以针对安全问题提起诉讼，那么他们可以就任何错误提起诉讼。 在保存20个小时的数据输入之前，应用程序是否崩溃了？ 电子邮件或Twitter消息是否到达了意外收件人？ 愤怒的小鸟是否因未能更新您的高分而引起困扰？

汉堡vs浏览器 (Burgers vs Browsers)

Let’s use Clayton’s burger analogy. Preparing a burger involves sourcing good-quality (OK — acceptable quality) meat and throwing any which is past its best. You won’t have problems if the ingredients are kept cool until required then cooked at a high enough temperature for a long enough time.

让我们用克莱顿的汉堡类比。 准备汉堡需要采购优质(可以接受的质量)肉，并扔出任何最好的肉。 如果将食材保持凉爽直到需要，然后在足够高的温度下烹饪足够长的时间，您就不会有问题。

I don’t want to berate the fast food industry but there are a dozen variables and you only deal with two or three at a time. Nearly all are common sense — if the meat smells bad or looks green, it won’t be fit for human consumption. A burger costs a couple of dollars but, eat a bad one, and it will kill you.

我不想谴责快餐业，但是有十二个变量，您一次只能处理两个或三个。 几乎所有的东西都是常识-如果肉味难闻或看上去绿色，就不适合人类食用。 一个汉堡要花几美元，但是吃一个不好的汉堡，会杀死你的。

Let’s compare it to a web browser. Conservatively, a browsing application could have 10,000 variables. There’s no linear path and each variable could be used at a different time in a different way depending on the situation. The browser is running on an operating system which could have one million lines of code and another 100 thousand variables. It could also be interacting with other software and running on a processor with its own instruction sets. It’s complex.

让我们将其与网络浏览器进行比较。 保守地，浏览应用程序可以具有10,000个变量。 没有线性路径，每个变量可以根据情况在不同的时间以不同的方式使用。 该浏览器运行在一个可能具有一百万行代码和另外十万个变量的操作系统上。 它还可能与其他软件进行交互，并在具有自己指令集的处理器上运行。 这很复杂。

However, a browser is completely free at the point of use. It may be the worst application ever written. You may lose time, money and hair. But no one will die. There are risks, but are they more than outweighed by the commercial benefits?

但是，浏览器在使用时完全免费。 这可能是有史以来最糟糕的应用程序。 您可能会浪费时间，金钱和头发。 但是没有人会死 。 存在风险，但是商业收益是否超过风险？

终端软件 (Terminal Software)

It is possible to limit programming flaws. Consider avionic software: a bug which caused a plane to fall out of the sky will lead to death. Failure is unacceptable.

可以限制编程缺陷。 考虑一下航空电子软件：导致飞机从天上掉下来的错误会导致死亡。 失败是不可接受的。

Aircraft software development is rigid, fully documented, optimized for safety, thoroughly tested, reviewed by other teams and governed by legislation. It takes considerable time, effort and focus. Airbus won’t demand a cool new feature mid-way through coding. Boeing won’t rearrange interface controls one week before deployment.

飞机软件开发是严格的，完整的文档记录，针对安全性进行了优化，经过全面测试，由其他团队审查并受法律约束。 这需要花费大量时间，精力和精力。 空中客车公司不会在编码过程中要求任何酷功能。 波音不会在部署前一周重新安排界面控制。

The software is incredibly complex, but it’s one large application running on a closed system. The development cost is astronomical — yet failures still occur. They’re rare, but it’s impossible to test an infinite variety of situations in a finite period.

该软件非常复杂，但是它是一个在封闭系统上运行的大型应用程序。 开发成本是天文数字，但仍然会失败。 它们很少见，但不可能在有限的时间内测试无数种情况。

评估开发人员的疏忽 (Assessing Developer Negligence)

There’s only one way to learn programming: do it. Learning from your mistakes is a fundamental part of that process. You never stop learning. And you still make mistakes. I cringe when I examine code I wrote last week … applications written ten years ago scare the hell out of me.

学习编程只有一种方法：做到这一点。 从错误中学习是该过程的基本部分。 您永远都不会停止学习。 而且你仍然会犯错误。 当我检查上周编写的代码时，我感到畏缩……十年前编写的应用程序使我不寒而栗。

While education is a start, it takes time, patience, and real-world problem solving to become a great developer. How could you gain that experience if you weren’t being paid? If you’re being paid, it stands to reason someone is using your software.

虽然教育是一个开始，但要成为一名出色的开发人员，需要时间，耐心和解决实际问题的能力。 如果您没有得到报酬，您如何获得该经验？ 如果您获得付款，则可以认为有人正在使用您的软件。

Anyone who thinks applications can be flaw-free has never written a program. Even if your code is perfect, the framework you’re using won’t be. Nor is the compiler/interpreter. What about the database, web server, operating system or internal processor instruction set?

任何认为应用程序可以无缺陷的人都从未编写过程序。 即使您的代码是完美的，您使用的框架也不会。 编译器/解释器也没有。 数据库，Web服务器，操作系统或内部处理器指令集又如何？

But let’s assume lawyers found a way to legally assess developer negligence. Who in their right mind would want to become a programmer? Fewer people would enter the profession and daily rates would increase. Those developers prepared to accept the risk would have to adhere to avionic-like standards and pay hefty insurance premiums. Software costs would rise exponentially and become an expensive luxury for the privileged few.

但是，让我们假设律师找到了一种合法评估开发商过失的方法。 谁在他们的头脑中想成为一名程序员？ 进入该行业的人数会减少，并且日费率会增加。 那些准备接受风险的开发商将必须遵守航空电子标准并支付高额保险费。 软件成本将成倍增加，并成为少数特权人士的昂贵奢侈品。

Clayton’s proposal may be well-meaning but it doesn’t consider the consequences. His suggested legislation would kill the software industry. Ironically, that would solve all security flaws — perhaps that would make him happy?

克莱顿的提议可能是善意的，但并未考虑后果。 他建议的立法将杀死软件业。 具有讽刺意味的是，这将解决所有安全漏洞- 也许会让他高兴？

翻译自: https://www.sitepoint.com/developers-sued-for-application-bugs/

ofo押金是否可以起诉