3 ms·
OSS contributions aren't ever explicitly security-critical software: "THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRE
by ISL 4y ago
OSS contributions aren't ever explicitly security-critical software:
"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, ...... "
It is on the user (or a third party certification authority) to accept any liability for the quality of the software.
- throwaway294566 4y agoThat law would override any such disclaimer by the seller (or other kind of "commercial producer") of OSS software. What is "critical" is determined by the catalogue of critical software categories.
- UncleEntity 4y agoWhich would move up the chain to all dependencies of a critical project. Libc, clang/gcc, whatever. Needs to be audited. Perhaps they require the “integrator” to perform the audit or maybe the fact someone provides software which can be useful in critical environments is enough to signal an implied warranty and they are on the hook for compliance. Nobody knows until it all goes through costly legal procedures where everyone is trying to cover their asses and pass the buck. I’m waiting for the day where FLOSS devs are greeted at EU airports by process servers because they released some software while in college and it got used in some critical software.
- throwaway294566 4y agoNo, the draft requires the purpose of a software to be declared. So if you declare Linux to be a terminal emulator, not an operating system, and only sell/import/distribute it as such, you only need to comply with the somewhat easier self-certification requirements for non-critical software. However, that declaration of purpose of course binds all other users/distributors of Linux, if they should dare to use or bundle it as a desktop, server or mobile operating system, they are doing so outside the original certification and need to have the required audit for critical software performed. That, as far as I read it, also means that something like GCC, which is unambiguously a compiler, isn't critical and need not be audited, only self-certified, even if used to compile a critical software component.
- retrac 4y agoYou cannot waive such rights in many jurisdictions, and such clauses are void there. Even where you can generally waive such warranty rights as a buyer in a contract, such waivers may still be curtailed in allowed scope. That includes most US states, too. E.g. if you sell a consumer product that's shoddily made and unfit for purpose and it blows up and injures its user, a signed contract where the buyer fully waives all implied warranties for fitness of purpose and accepts full responsibility -- caveat emptor! -- is probably void, and you are probably on the hook anyway. > Limitation of consequential damages for injury to the person in the case of consumer goods is prima facie unconscionable https://www.law.cornell.edu/ucc/2/2-719 https://www.law.cornell.edu/ucc/2/2-719
- ISL 4y agoAre there instances where OSS contributors were found liable for major losses? (Heartbleed would seem like the kind of thing that could do it.) If so, I'd expect it to summarily obliterate the OSS world.
- retrac 4y agoAs I understand it, at least with contract law in common law jurisdictions, simply writing and freely posting OSS would not fall under this; a warranty is an implied part of a contract, and there is no contract that exists between the authors, and those who receive copies. No contract, no sale, no warranty. (A licence is not a contract, at least in some common law jurisdictions. But licences are contracts in civil law jurisdictions, usually...) This would, however, not remain true if you're actually dealing with your users in a way that establishes mutual obligations (be careful you don't fall into a contract unawares!) Providing support for pay would do it, for example.