Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, 19 Nov 2023 at 00:21, Sam Hartman <hartmans@suchdamage.org> wrote:
>
> >>>>> "Bart" == Bart Martens <bartm@debian.org> writes:
> >>
> >> * A commercial company writes free-software that for all
> >> practical purposes can be used only for access to their
> >> proprietary web service. I'd rather not allow arguments about
> >> whether a flaw is on the web service side or the client API side
> >> to be used to help the company get out of liability to their
> >> customers/users.
>
> Bart> I guess "awscli" is an example of this situation.
>
> Sure, let's say it is.
> One could quibble about whether there are alternate implementations of
> AWS's API, but for most uses, I'd agree with awscli being an example of
> what I'm talking about.
>
> Bart> https://packages.debian.org/sid/awscli
> Bart> https://metadata.ftp-master.debian.org/changelogs//main/a/awscli/awscli_2.12.0-1_copyright
> Bart> So the EU would hold Amazon liable for damages caused by using
> Bart> "awscli", overruling the "without warranties" clause in the
> Bart> license. Well, then next time Amazon might choose to only
> Bart> provide documentation of the API, without publishing an open
> Bart> source example implementation like "awscli". That's a loss for
> Bart> foss. It illustrates the value of DFSG 6.
>
> Ah, because the regulations specifically exclude SAAS and so Amazon
> doesn't have liability for the API unless they publish software to use
> the API?
>
> If that's your point, I certainly understand you better.
>
> If in practice we end up with less open-source software because of
> things like that, I agree it would be a negative.
The software license makes no difference, if there's a commercial
activity involved then the vendor is responsible to its customers.
Amazon didn't build awscli because it's a hobby activity or as a favor
to the open source ecosystem, they built it because their cloud
customers demand it and use it (same for Microsoft for azcli, and for
Google for the gcloud cli). So it would not make any difference one
way or the other, these softwares will still exist, and will still be
open source because there's nothing to gain from doing otherwise. It's
a good thing that cloud vendors are held accountable for the security
of the software they ship on users' machines, even if their services
fall under different regulatory regimes. A certain vendor that I won't
name regularly bundles an outdated set of python interpreter, standard
library, ancillary modules _and_ OpenSSL as cherry on top with their
CLI tool - maybe once these regulations are in place, they'll finally
get their act together and start doing proper security maintenance of
said product.
Reply to: