Advokaten 4 Ingen reel beskyttelse af edb-programmer?

Print Print
22-05-2006

Af advokat Peter Lind Nielsen, Advokatfirmaet Bender von Haller Dragsted
Hvis vi skal beskytte de bagvedliggende ideer og funktionaliteten i edb-programmer for at sikre retsstillingen for opfinderen, risikerer vi at dræbe al udvikling og innovation.

Advokatfuldmægtig Astrid Friis Jørgensens artikel ”Ingen reel ophavsretlig beskyttelse af edb-programmer” i Advokaten, nr. 2, 2006 giver anledning til refleksioner, hvilket navnlig gælder forfatterens opfattelse af, hvad et edb-program er, og hvad der skal beskyttes af lovgivningsmagten.

Den danske ophavsretslov beskytter – i lighed med andre landes tilsvarende lovgivning – ikke selve den bagvedliggende ide eller ønske om funktionalitet bag et værk. Det gælder for alle værker – såvel for edb-programmer som for musik, litteratur, billedkunst, brugskunst osv. Baggrunden er en filosofi om, at en beskyttelse af den bagvedliggende ide og funktionalitet vil bremse udvikling og innovation.

Det skal erindres, at udgangspunktet faktisk er, at alle ideer, koncepter og værker må kopieres og ændres frit. Ophavsretsloven er en indskrænkning af denne ret, hvor man har valgt at tildele ophavsmanden en særlig beskyttelse imod at andre kan plagiere hans værker. Beskyttelsen er imidlertid begrænset således, at ophavsmanden ikke kan forhindre andre i at udnytte den samme ide, og på baggrund heraf lave et selvstændigt værk.

Hvad beskyttes?
Når vi taler om et edb-program, vil såvel forstadierne som f.eks. detaljerede kravspecifikationer og algoritmer ofte være beskyttet, kildekoden vil være beskyttet, og edb-programmets look & feel i form af brugergrænseflade vil også kunne være beskyttet.

Det kræver naturligvis, at de enkelte dele opfylder kravene for beskyttelsen, altså at de skal være udtryk for en selvstændigt skabende og intellektuel indsats. Skal kravspecifikationer og algoritmer beskyttes som en del af et edb-program, kræver det tillige, at de senere kan anvendes til at programmere netop det konkrete færdige program. Der vil være tale om et værk men i forskellige former, og beskyttelsen vil på nogle områder være snæver, hvilket bl.a. gælder brugergrænsefladen, idet en meget bred beskyttelse netop vil betyde beskyttelse af den bagvedliggende ide eller forretningsmodel om man vil.

Forestiller man sig en e-handelsløsning på et website, vil en ophavsmand ikke opnå beskyttelse af de bagvedliggende ideer og ønske om funktionalitet, som f.eks. at brugeren kan se et varekatalog i alfabetisk orden med billeder og beskrivelser af varen, at brugeren kan ”trykke” på de enkelte varer for at bestille eller at brugeren kan ”gå til kassen” og betale for varen med kreditkort.

Krænkelsesvurderingen
Da et edb-program altså ofte består af flere former af det samme værk, vil en krænkelsesvurdering ikke ske ved en kildekodesammenligning alene, og det er ikke kun en påviselig slavisk kopiering af kildekoden der udgør en krænkelse.

Kildekoden vil indgå som et element i vurderingen, men man vil også skulle vurdere bl.a. designmateriale, algoritme og brugergrænseflade. Da kildekoden ofte er skjult for omverdenen, er det da også ofte en sammenligning af brugergrænsefladen der vækker den første mistanke om en krænkelse.

Hvis der benyttes forskellige programmeringssprog vil kildekoden ikke se ens ud, men det alene kan ikke føre til, at der ikke foreligger en krænkelse Det svarer til at antage, at hvis man oversætter en fransk roman til dansk, så er den danske oversættelse ikke en krænkelse af den franske udgave. En oversættelse af en kildekode fra et sprog til et andet vil sagtens kunne være en krænkelse.

I artiklen har Astrid Friis Jørgensen (AFJ) et eksempel med en konkurrent, der ”stjæler” algoritmen til et program og får 90 kinesere til at udvikle et program ud fra algoritmen, men i et andet programmeringssprog. Programmerne har i eksemplet den samme funktionalitet og samme brugergrænseflade, men da kildekoderne er forskellige, er der efter AFJ's opfattelse ikke tale om en krænkelse.

Som beskrevet ovenfor vil en plagiering af brugergrænsefladen sagtens kunne være en krænkelse, forudsat at brugergrænsefladen kan anses som et værk – evt. flere værker. Dernæst vil der kunne være tale om en plagiering af selve programmet og programmets kildekode og bagvedliggende algoritme.

AFJ slår fast, at en algoritme ikke beskyttes efter ophavsretsloven. Man kan da også udlede af artiklen, at hun alene betragter algoritmen som en idébeskrivelse eller udtryk for generelle principper, og i så fald er det korrekt. De enkelte algoritmer som enkelte instruktioner er ikke beskyttet. Men at lave en detaljeret algoritme til et edb-program vil ofte være en kreativ og intellektuel proces, og ved netop den konkrete sammenstilling af et meget stort antal instruktioner eller algoritmer opnår ophavsmanden en beskyttelse af den samlede algoritme. Det program, der herefter programmeres på baggrund af en sådan detaljeret algoritme er så samme værk blot i en anden form.

En algoritme som sådan vil endvidere ofte være næsten umulig at anvende til brug for en programmering, hvis der ikke samtidig er adgang til anden dokumentation f.eks. kildekode, kravspecifikation, designmateriale m.v. Foretagelse af ”reverse engineering” for at nå frem til kildekoden med henblik på at udvikle et konkurrerende produkt er endvidere slet ikke tilladt jf. ophavsretsloven.

I AFJ's eksempel må algoritmen være en meget detaljeret beskrivelse/opskrift på programmet, da de 90 kinesere ved at bruge algoritmen kan lave et fuldstændig identisk program. Der vil derfor være tale om en krænkelse af ophavsmandens algoritme, idet en domstol efter al sandsynlighed må nå frem til, at kinesernes program ikke er en lovlig dobbeltfrembringelse, fordi det er lavet på baggrund af en detaljeret beskrivelse/opskrift, der alt andet end lige må betragtes som et beskyttet værk.

Edb-programmer i de forskellige former har således en reel beskyttelse efter ophavsretsloven i lighed med andre værker, hvor såvel arkitekttegninger som det færdige hus kan være beskyttet, mens den bagvedliggende ide eller de generelle principper for byggeriet ikke beskyttes.

At det navnlig for edb-programmer er vanskeligt at føre krænkelsessager, og at det undertiden kan være vanskeligt at bevise en plagiering, er jeg enig i, men derfra til at slutte at beskyttelsen ikke er eksisterende eller reel, mener jeg der er ganske langt. Hvis løsningen er, at vi skal beskytte de bagvedliggende ideer og funktionaliteten i edb-programmer for at sikre retsstillingen for ophavsmanden/opfinderen, giver dette helt andre uoverskuelige problemer og en så bred beskyttelse, at vi dræber al udvikling og innovation.

Beskyttelse af ideer og principper
Spørgsmålet er, om software-patentering er løsningen. Det er umuligt kort at redegøre for alle aspekter ved EU's forslag om software-patenter. Man kan dog udlede, at det ikke i de tidligere forslag var meningen, at der skulle åbnes op for, at ethvert program skulle kunne patenteres, og derfor vil der fortsat være mange programmer, der ikke kan patenteres.

Netop den uklare grænse mellem patentbeskyttelsen og beskyttelsen af den rene idé eller generelle funktionalitet og for programmer ofte også den bagvedliggende forretningsmodel, var et af de forhold, som bragte forslaget til fald.

Ser man på amerikansk patentpraksis udstedes der meget brede patenter på software, hvor helt abstrakte ideer og funktioner samt generelle forretningsmodeller patenteres ved f.eks. patent på ”one-click” funktioner, ”indkøbskurven” på e-handelssites og ”e-handel” sådan helt generelt. Det seneste eksempel er et patent på at kunne vise levende billeder (film, animationer m.v.) på et website.

Har man blot en gang for en klient forsøgt at opnå vished for at klientens program, som han selv har udviklet fra grunden, ikke på nogen måde krænker et patent i USA, eller hvis man har oplevet en klient, der bliver anklaget for en patentkrænkelse i USA, kan man se, hvad en uhæmmet og ukritisk patentering kan betyde. Mange mindre udviklingsfirmaer må derfor ofte give op og krydse fingre for, at der ikke i forvejen er et patent på deres ”ide”. Overtrædelse af ophavsretsloven kræver derimod ”ond tro” og er derfor nemmere at overskue og overholde, selvom en konkret krænkelsesvurdering kan være vanskelig at afgøre.

Gennemførelse af en lovgivning på software-patenter må således fordre en sikkerhed for, at det ikke er enhver idé, funktionalitet eller bagvedliggende forretningsmodel i et program, der kan beskyttes. En generel beskyttelse af ideer, funktionalitet og forretningsmodeller vil ikke fremme den  fremtidige udvikling og innovation i samfundet, som bør være hovedformålet med loven, men derimod bremse den. Og det kan næppe være i it-branchens interesse.