Hacker News Reader

Comment by paganel | Hacker News Reader

What happens with EU-based developers that work on OSS projects while on a company’s dime? I.e. said company doesn’t have any direct relation with that project, but wants to support it by paying some of its developers to put in the work. Or to developers that receive Patreon money based on their OSS projects? It can get pretty murky pretty fast.

View on HN

Example: I contributed to the Elixir version of faker years ago. My customer allowed me to issue a PR with the Italian translations and it was accepted. This is clearly commercial because my customer was paying me and I was working at a commercial service. With this legislation I think they wouldn't let me send the PR (because maybe they would have had to pay for the certification) and/or it wouldn't be accepted (because the costs could be on the project.)

Then they‘re no longer working for free. That‘s exactly the issues this article is discussing - but that‘s not the point the parent poster was alluding to. They specifically mentioned „for free.“

However, if you build security critical software and get paid to do so it‘s not entirely unreasonable to require some sort of certification. You can‘t just build medical devices for money either without some sort of regulation. Or produce food for money. Or repair cars for money.

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.

You 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

Are 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.

As 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.

That 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.

Which 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.

No, 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.

Reply on news.ycombinator.com