Man­da­to­ry updates? Sta­te of the art for software

The pace of tech­no­lo­gi­cal deve­lo­p­ment con­ti­nues unab­a­ted, due abo­ve all to trend towards digi­tiza­ti­on. For this reason, laws and con­trac­tu­al agree­ments which make refe­rence to tech­ni­cal stan­dards should typi­cal­ly be draf­ted in an open-ended man­ner so as to enable them to keep pace with recent tech­no­lo­gi­cal deve­lo­p­ments (as noted e.g. by the Fede­ral Con­sti­tu­tio­nal Court in its famous Kal­kar Order of 8 August 1978, Case No. 2 BvL 8/77) (only in Ger­man). Ins­tead of requi­ring a spe­ci­fic tech­ni­cal con­di­ti­on, laws and con­tracts will the­r­e­fo­re typi­cal­ly include an abs­tract desi­gna­ti­on of the neces­sa­ry or desi­ra­ble tech­ni­cal condition.

The three tech­ni­cal stan­dards and their legal significance

Three dif­fe­rent stan­dards have emer­ged for the abs­tract desi­gna­ti­on of tech­ni­cal requirements:

  • The first is “gene­ral­ly accept­ed tech­ni­cal rules.” This refers to tech­ni­cal deter­mi­na­ti­ons which are view­ed as a reflec­tion of the sta­te of tech­ni­cal design by a majo­ri­ty of peo­p­le in the field (such as DIN stan­dards or VDI gui­de­lines). If “gene­ral­ly accept­ed tech­ni­cal rules” are the appli­ca­ble stan­dard, the­re is typi­cal­ly an expec­ta­ti­on that the pro­duct meets cer­tain mini­mum requirements.
  • One step hig­her is “sta­te of the art,” which refers to estab­lished fin­dings from sci­ence, engi­nee­ring and expe­ri­ence. If the start of the art is requi­red, it is not neces­sa­ry to use the best available tech­no­lo­gy, only one which has under­go­ne a cer­tain amount of test­ing. But unli­ke “gene­ral­ly accept­ed tech­ni­cal rules,” it is not neces­sa­ry for the solu­ti­on to be accept­ed by a majo­ri­ty of peo­p­le in the field or for it to be spe­ci­fied in tech­ni­cal stan­dards. “Sta­te of the art” is requi­red e.g. in data pro­tec­tion law (cf. Artic­le 32(1) of the GDPR) (only in Ger­man) as well as in medi­cal devices law (cf. MDR, Annex 1, No. 1) und in many other sta­tu­tes. “Sta­te of the art” is also fre­quent­ly reli­ed upon for the iden­ti­fi­ca­ti­on of mate­ri­al defects and it will be the appli­ca­ble stan­dard in con­nec­tion with imple­men­ta­ti­on of the Digi­tal Con­tent Direc­ti­ve.
  • Ano­ther step abo­ve is the “sta­te of sci­ence and engi­nee­ring,” which requi­res the best pos­si­ble tech­ni­cal per­for­mance, and which is used e.g. in pro­duct lia­bi­li­ty law  (cf. Fede­ral Supre­me Court, Judgment of 16 June 2009, Case No. VI ZR 107/08) (only in German).

Sta­te of the art in software

Whe­ther manu­fac­tu­r­ers are requi­red to adhe­re to the “sta­te of the art” or a dif­fe­rent tech­ni­cal stan­dard depends on which laws app­ly as well as the exis­ting con­trac­tu­al agree­ments. For this reason, manu­fac­tu­r­ers of soft­ware and pro­ducts which con­tain soft­ware should careful­ly exami­ne their sta­tu­to­ry and con­trac­tu­al obli­ga­ti­ons in each case. The tech­ni­cal rules descri­bed abo­ve must be fol­lo­wed depen­ding on the appli­ca­ble tech­ni­cal stan­dard. This is gene­ral­ly true for soft­ware in the same way as for phy­si­cal products.

When is the assess­ment made?

Of cour­se, the ques­ti­on as to whe­ther a pro­duct or soft­ware adhe­res to the sta­te of the art depends on when the assess­ment is made. This, in turn, depends on the appli­ca­ble laws and con­trac­tu­al agree­ments. In data pro­tec­tion law, for exam­p­le, sta­te of the art must be ensu­red throug­hout the enti­re pro­ces­sing peri­od, so that the defi­ni­ti­on of sta­te of the art must be con­ti­nu­al­ly adapt­ed based on a risk assessment.

In the law gover­ning con­tracts of sale, the situa­ti­on is dif­fe­rent. In this case, the ques­ti­on as to whe­ther a defect exists is deter­mi­ned at the time of pas­sa­ge of risk. When soft­ware is invol­ved, this rai­ses a fasci­na­ting ques­ti­on, and one which has yet to be ful­ly cla­ri­fied: is soft­ware con­side­red to be defec­ti­ve only when a weak point is dis­co­ver­ed, or is the soft­ware defec­ti­ve if the neces­sa­ry con­di­ti­ons are pre­sent for the emer­gence of a weak point.

Our view is that a defect can only exist upon pas­sa­ge of risk if the software’s weak point was fore­seeable at that time. This should be the case if the weak point is not attri­bu­ta­ble to new attack tech­ni­ques or pre­vious­ly unknown tech­ni­cal methods. Con­trac­tu­al agree­ments fre­quent­ly spe­ci­fy a duty to ensu­re sta­te of the art on a con­ti­nuous basis over the enti­re term of the con­tract or the enti­re useful life of the pro­duct or soft­ware in question.

When are updates necessary?

Manu­fac­tu­r­ers are requi­red to pro­vi­de soft­ware updates when­ever they have a sta­tu­to­ry or con­trac­tu­al duty to do so. Whe­ther or not this is the case depends on the appli­ca­ble laws and con­trac­tu­al agree­ments, like the appli­ca­ble date for deter­mi­ning the sta­te of the art. While the decisi­ve peri­od in data pro­tec­tion law is always the peri­od of pro­ces­sing, the decisi­ve peri­od for iden­ti­fy­ing whe­ther a defect exists in the law gover­ning con­tracts of sale is gene­ral­ly the con­trac­tu­al war­ran­ty peri­od. Howe­ver, war­ran­ty claims in con­tracts of sale do not estab­lish a cla­im against the manu­fac­tu­rer to recei­ve updates, due to the fact that war­ran­ty for defects can gene­ral­ly be pro­vi­ded by other means. Whe­ther the manu­fac­tu­rer has an ancil­la­ry con­trac­tu­al duty to pro­vi­de updates has been a sub­ject of con­stant dis­cus­sion. By Judgment of 16 Octo­ber 1997 (Case No. 83 O 26–97) (only in Ger­man), the Dis­trict Court of Colo­gne ruled that the manu­fac­tu­rer is requi­red to pro­vi­de updates, for a fee, over the enti­re life cycle of the device. But the­se prin­ci­ples will be alte­red by imple­men­ta­ti­on of the Digi­tal Con­tent Direc­ti­ve. For exam­p­le, the Fede­ral Minis­try of Jus­ti­ce is plan­ning to enact a new sta­tu­te, § 327 f(1) of the Civil Code, under which updates for digi­tal pro­ducts would have to be sup­pli­ed for a cer­tain peri­od of time. Under this sta­tu­te, updates would have to be pro­vi­ded by the manu­fac­tu­rer for as long as the con­su­mer “may expect, given the type and pur­po­se of the digi­tal pro­duct and taking into account the cir­cum­s­tances and the natu­re of the con­tract.” Unli­ke in con­trac­tu­al law, a duty to pro­vi­de updates does not exist in pro­duct lia­bi­li­ty law, at least not for now.

Prac­ti­cal recommendation

The ques­ti­on as to which tech­ni­cal stan­dard appli­es for soft­ware is legal­ly com­plex, as is the ques­ti­on as to whe­ther and to what ext­ent updates need to be pro­vi­ded. The­se ques­ti­ons may beco­me even more com­plex in the coming years with the addi­ti­on of new legal requi­re­ments with respect to IT secu­ri­ty. Accor­din­gly, soft­ware manu­fac­tu­r­ers would be well-advised to ful­ly cla­ri­fy at an ear­ly stage which sta­tu­to­ry and con­trac­tu­al requi­re­ments their soft­ware must adhe­re to. It is also neces­sa­ry to estab­lish con­ti­nuous moni­to­ring of the legal requi­re­ments and of their software’s IT secu­ri­ty properties.


Stay up-to-date

We use your email address exclusively for sending our newsletter. You have the right to revoke your consent at any time with effect for the future. For further information, please refer to our privacy policy.