1

I'm curious to what extent strict liability could apply to open source software in cases where what is shared isn't really a product, or even something that is intended to be incorporated into a product to be shared with a consumer but rather just a small sort of helpful, useful thing for people who understand the code.

For context, I am a software engineer and I recently created what we commonly call a "script", which is a small bit of code that performs a useful function (perhaps the closest legal analogy would be something like a notebook with paper that has certain language prefilled out for creating specific classes of contract or something of the sort) that I want to share, but the rub is, misused it could be quite damaging to the users computer.

It certainly isn't something that raises to the level of a "feature" "component" or anything close to a product, however I read online recently about strict liability concepts being developed by the EU and potentially applied to open source software. So I'm curious what legal minded people would make of my case, where the software in question is very small in scale, requires technical knowledge to use and is not billed as a "consumer cool thing to use or even to integrate in something you'd deliver to a consumer".

Concern would be John Doe in big company Y downloads my script, sets it up wrong and he loses N months of work, then tried to go after me for giving him the script. Perhaps that's just paranoid and unrealistic though anyways...

Here's the full story if you're interested: https://medium.com/@nwcodex/my-coworkers-unicorned-me-so-i-16af2cc7ee23

I work in cybersecurity so I know people share tools and scripts similar to this all the time. I'd be very surprised if every ad-tool or useful script could endanger the person who shared it legally, although I want to be extra careful in my case.

1 Answer 1

1

To the extent that it is software provided commercially

The proposed EU Directive on liability for defective products is more of a clarification that existing product liability laws apply to intangible products just as they do to physical products. Anyone who supplies a product is strictly liable if it is defective and causes harm.

Article 6

Defectiveness

  1. A product shall be considered defective when it does not provide the safety which the public at large is entitled to expect, taking all circumstances into account, including the following:

(a) the presentation of the product, including the instructions for installation, use and maintenance;

(b) the reasonably foreseeable use and misuse of the product;

(c) the effect on the product of any ability to continue to learn after deployment;

(d) the effect on the product of other products that can reasonably be expected to be used together with the product;

(e) the moment in time when the product was placed on the market or put into service or, where the manufacturer retains control over the product after that moment, the moment in time when the product left the control of the manufacturer;

(f) product safety requirements, including safety-relevant cybersecurity requirements;

(g) any intervention by a regulatory authority or by an economic operator referred to in Article 7 relating to product safety;

(h) the specific expectations of the end-users for whom the product is intended.

  1. A product shall not be considered defective for the sole reason that a better product, including updates or upgrades to a product, is already or subsequently placed on the market or put into service.

Source code is not software if it consists of pure information. However, a script that can be executed without compilation is likely to be captured as it is both software and source code.

A product only attracts liability when it leaves the manufacturer's control —scripts distributed solely within your own organisation are not yet "products."

There is an exemption for non-commercial products; however, there are two issues with relying on this exemption: one practical and the other legal. The practical issue is that commercial is defined so widely that it will capture virtually anything done in the economy other than purely household activities - a script for cyber-security professionals will almost always be "commercial". The legal issue is that the exemption is in the recitals and not the articles, which means it's advisory and not legally binding.

To avoid liability, you should ensure your script is not "defective" (see above). You probably need to build in fail safes, and confirmation stops before letting the script rip. As a secondary measure, your readme and comments should be very clear about the risks. The article you linked is illustrative of why relying on humans not to human is not an adequate safety measure.

If this troubles you, have a look at this. It's possible to make these not defective despite the obvious hazards - how much easier will it be with just a piece of code?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .