Indholdsfortegnelse 1 Indledning... 1 1.1 Afhandlingens baggrund... 1 1.2 Målsætning og metode... 1 1.3 Afgrænsning... 2 2 Software - begreb og virkemåde... 3 3 Ophavsret til edb-programmer... 8 3.1 Retsgrundlaget... 8 3.2 Retsbeskyttelsen... 8 3.2.1 Edb-programmer som ophavsretlige værker... 9 3.2.1.1 Retsbeskyttelsens genstand - programbegrebet... 10 3.2.1.2 Originalitetskravet... 13 3.2.1.3 Algoritme = ide?... 19 3.2.1.4 Grænseflader, protokoller og programmeringssprog... 20 3.2.2 Beskyttelsens varighed, indhold og omfang... 22 3.2.2.1 Nærmere om bearbejdelser... 27 3.2.2.2 Parallel til brugskunst en bemærkning... 33 3.2.2.3 Konklusion vedr. beskyttelsens omfang... 34 3.2.3 Edb-programmets forberedende designmateriale... 34 3.2.4 Reverse engineering... 38 3.2.4.1 Reverse engineering -teknikker og deres anvendelse... 38 3.2.4.2 Nærmere om interoperabilitet og konkurrence... 40 3.2.4.3 Hvornår er reverse engineering lovligt?... 42 3.2.4.4 Afgrænsningen mellem OPHL 36, stk. 1, nr. 3 og OPHL 37... 45 3.2.4.5 Konkurrenceretten som sikkerhedsventil... 48 3.2.5 Retsbeskyttelsens subjekt en kort bemærkning... 49 4 Patent på software...50 4.1 Retsgrundlag... 51 4.2 Kort om beskyttelsens indhold og varighed... 52 4.3 Betingelser for opnåelse af patent... 53 4.3.1 Hvornår har software teknisk karakter og hvornår ydes et teknisk bidrag?... 55 4.3.1.1 Nærmere om vurderingen af opfindelseshøjde, herunder teknisk bidrag... 58 4.4 Samfundsøkonomiske overvejelser... 60 5 Software som erhvervshemmelighed...63 5.1 Beskyttelsens indhold og objekt... 63 5.2 Erhvervshemmeligheder og reverse engineering... 66 5.3 Forholdet til ophavsretten og patentretten... 69 6 Konklusion...71 7 Litteraturliste...73 8 English summary...75 Bilag 1: Fremgangsmåde til vurdering af patentansøgninger
1 Indledning 1.1 Afhandlingens baggrund Forskning, udvikling og innovation har afgørende betydning for virksomheders konkurrenceevne og vækst, og dermed for den generelle velstand i samfundet. 1 I den såkaldte nye økonomi er viden det grundstof, der skal sikre den vestlige verden fremtidig vækst og velstand, i takt med at et stigende antal aktiviteter i den traditionelle økonomi, herunder industriproduktion og rutineopgaver, outsources til lavtlønslande. Software er i denne sammenhæng et blandt flere teknologiske og videnstunge produkter, som vesten kan fokusere på i konkurrencen med fremadstormende økonomier som eksempelvis Indien, Brasilien og Kina. I lyset heraf er det essentielt at skabe incitament til innovation. Dette gøres bl.a. ved at stille med et stærkt, internationalt regelsæt, der sikrer innovative virksomheder mod at potentielle og/eller aktuelle konkurrenter, mere eller mindre omkostningsfrit, kan lukrere på de ofte betydelige investeringer i udvikling af nye produkter og løsninger. Dette regelsæt finder man i immaterialretten, der udgør et betydeligt værn imod plagiering af innovative nyskabelser. Ét af immaterialrettens mål er, at sikre et rimeligt afkast af den investering, der foretages i tilegnelsen af ny viden og udviklingen af nye produkter som minimum breakeven. Uden en sådan beskyttelse mod free riders risikeres, at virksomheder mister incitamentet til forskning, udvikling og innovation, med heraf følgende negative konsekvenser for den økonomiske udvikling, forbrugervelfærden og konkurrencen på markedet. I relation til software er særlig den industrielle del af ophavsretten samt patentretten relevant. Dette fordi disse discipliner værner om hhv. software-produkters programkode og den innovative ide/metode der ligger til grund herfor. Udfordringen består i at skabe balance mellem opfinderens/ophavsmandens økonomiske interesse i en stærk retlig beskyttelse, og samfundets interesse i at undgå skabelsen af vidtfavnende og vedvarende retlige monopoler, der, i modstrid med ovennævnte målsætning, bremser teknisk innovation. Hvor balancen ikke nås, har det i visse tilfælde vist sig nødvendigt, at inddrage det konkurrenceretlige regelsæt, som middel til ex post at korrigere eventuelle uhensigtsmæssigheder, som består i at eneretten misbruges. 1.2 Målsætning og metode Målsætningen med nærværende afhandling er at udføre en retsdogmatisk analyse af gældende ret, med henblik på at afdække omfanget af den immaterialretlige beskyttelse, som tilsiges software-udviklere i medfør af ophavsretten og patentretten. I nær tilknytning hertil inddrages endvidere den markedsføringsretlige beskyttelse af erhvervshemmeligheder, da denne i visse tilfælde kan supplere eneretten, eller fungere som alternativ hertil. Denne retsdogmatiske analyse vil endelig blive suppleret af 1 Jf. Ebbe Krogh Graversen & Michael Mark: Forskning og Udviklingsarbejdes påvirkning af produktivitet og beskæftigelse, Dansk Center for Forskningsanalyse, Aarhus Universitet, 2005. 1
retspolitiske overvejelser, med det formål at klarlægge, hvorvidt gældende ret er hensigtsmæssig set i samfundsøkonomisk perspektiv. Afgørende er, hvorvidt retstilstanden er egnet til at underbygge målsætningen om at sikre innovation, eller om der er indikationer på, eller behov for, fremtidige revisioner af regelgrundlaget. Mere konkret behandles følgende overordnede problemstillinger: 1. I hvilket omfang beskyttes software af ophavsretten? 2. Under hvilke betingelser er det, i henhold til EPO s praksis, muligt at opnå patent på computer implementerede opfindelser? 3. Hvordan adskiller den patentretlige beskyttelse sig fra den ophavsretslige? 4. Hvad er forholdet mellem den markedsføringsretlige beskyttelse af erhvervshemmeligheder, og den immaterialretlige beskyttelse, som opnås i medfør af ophavsretten og patentretten? 5. Hvilken form for retlig beskyttelse er mest hensigtsmæssig, når henses til målet om at fremme innovation? Hovedfokus vil være ophavsretten. Perspektiveringen til de øvrige retsområder har til formål, at give et mere fuldendt billede af den retsbeskyttelse, der tilsiges software, samt at skabe et solidt fundament for ovennævnte retspolitiske overvejelser. 1.3 Afgrænsning Software består at flere elementer, herunder indkodede processorinstruktioner, data der tilgås og behandles, samt evt. output i form af skærmbilleder. 2 Ophavsretten favner potentielt samtlige de nævnte elementer, men i denne afhandling fokuseres alene på beskyttelsen af de indkodede processorinstruktioner, dvs. programkoden. Herved rettes fokus mod software-produkters kerne, og der skabes en fælles platform som grundlag for en retspolitisk sammenligning af den ophavsretlige og den patentretlige beskyttelse. Dette fordi der består en klar sammenhæng mellem programkoden, som beskyttes af ophavsretten, og dennes funktionalitet og virkemåde, som henhører under patentretten. Sidstnævnte har som bekendt til formål, at beskytte innovative tekniske løsninger - ikke data og skærmbilleder. Når der henvises til begrebet software i denne afhandling skal begrebet således forstås mere snævert end det traditionelt er tilfældet. Selvom den retlige beskyttelse af de øvrige programelementer har stor praktisk relevans, giver den ikke på samme vis anledning til særegne problemstillinger, som skyldes edb-programmers tekniske karakteristika. 2 For nærmere information henvises til afsnit 2. 2
Generelt må beskyttelsen af billeder, film, databaser, skrifttyper osv. behandles på samme måde uanset om de indgår i digital form i et software-program eller ej. Beskyttelsens subjekt, herunder enerettens overgang til arbejdsgiver, arvtagere mv., gøres endvidere ikke til genstand for nærmere behandling end hvad der må anses for nødvendigt af hensyn til afhandlingens analyser. Samme gør sig gældende for de problemstillinger, der relaterer til håndhævelse og sanktionsmuligheder. Sidst men ikke mindst må nævnes, at afhandlingen alene fokuserer på enerettens omfang i kommerciel kontekst, og at dens betydning i forhold til rent private dispositioner ikke er genstand for behandling. 3 2 Software - begreb og virkemåde Som på andre retsområder er det helt essentielt, at have forståelse for den juridiske kontekst man opererer i, når der skal udarbejdes valide analyser og træffes hensigtsmæssige afgørelser. Software er i sagens natur et meget teknisk præget produkt, og da disse tekniske karakteristika giver anledning til særlige problemstillinger, i forbindelse med den immaterialretlige beskyttelse, vil nærværende afsnit introducere nogle grundlæggende tekniske termer og søge at beskrive softwares virkemåde. Software, computer-programmer eller edb-programmer, som denne produkttype benævnes indenfor ophavsretten, er synonymer som henviser til samme produktkategori. Begreberne anvendes i denne fremstilling således, at der i afsnit vedrørende ophavsretten benyttes betegnelsen edb-programmer, mens der i øvrigt anvendes den mere tidssvarende og internationale betegnelse software. Herved er fremstillingen i relation til ophavsretten tro mod begrebsanvendelsen i ophavsretsloven og direktiv 2009/24/EF om retlig beskyttelse af edb-programmer. Det bemærkes endelig at EPO benytter begrebet computer implementerede opfindelser, om de tekniske nyskabelser hvis funktionalitet implementeres ved brug af software. Som nævnt består software af flere elementer. Disse omfatter foruden selve programkoden (processorinstruktionerne), en række dataelementer (tekst, billeder mv.) og i tilfælde hvor programmet 3 Patentretten omfatter ikke handlinger, der foretages i ikke-erhvervsmæsssigt øjemed, jf. PTL 3, stk. 3, nr. 1 (indført på baggrund af EPC art. 31, litra a). De enerettigheder, der opnås i medfør af ophavsretten favner derimod privat brug af et beskyttet værk. Den såkaldte privatbrugsregel i OPHL 12 tillader dog i visse tilfælde privat eksemplarfremstilling. Reglen gennemgås ikke nærmere i det følgende. Denne forskel regelsættene imellem skyldes at tekniske opfindelser, i modsætning til ophavsretlige værker, typisk ikke kan anvendes rent privat på en måde som vil true opfinderens indtjeningsmuligheder. Anderledes forholder det sig med ophavsretten, hvor private kan kopiere bøger, musik, film, software mv., som alternativ til at købe ophavsmandens produkt. 3
styres af brugerinput, produceres en brugergrænseflade (et antal skærmbilleder) 4, som muliggør interaktion mellem bruger og program. Foruden brugergrænsefladen eksisterer endvidere en softwaregrænseflade - også kaldet en teknisk grænseflade. Denne specificerer de programkomponenter, som kan kontaktes af anden software med henblik på at opnå interaktion, f.eks. i forbindelse med dataudveksling. I figur 1 illustreres programkodens forhold til de øvrige elementer såvel som programmets grænseflader dets kobling til omverdenen. Grænsefladerne er ikke egentlige bestanddele af et program, men skabes som et resultat af koden. 5 Figur 1: Programmets komponenter og grænseflader I software-branchen, og blandt forbrugere, forstås software-begrebet typisk som omfattende samtlige elementer. I ophavsretlig sammenhæng må begrebet imidlertid indsnævres. Det er nødvendigt, når man skal afgrænse edb-programmet som værkstype, jf. OPHL 1, stk. 3, overfor litterære og kunstneriske værker, som omfattes af OPHL 1, stk. 1. Som anført i afsnit 3.2.1, favner programbegrebet i ophavsretten alene selve programkoden og programmets forberedende materiale. Hvad angår patentretten, er der ikke på samme vis behov for at sondre mellem de enkelte bestanddele af software, idet det er programmets tekniske effekt, der er i fokus. Ophavsretten beskytter efter omstændighederne programmets kode, de tilknyttede data og den grafiske brugergrænseflade, samt det forberedende materiale, mens patentretten værner idéen, forstået som de overordnede algoritmer og metoder. 6 4 Denne vil i de fleste tilfælde være grafisk, men kan også være rent tekstbaseret (kommandoprompt). Visse definitioner af begrebet brugergrænseflade er bredere og omfatter foruden selve skærmbilledet, ethvert middel der anvendes i forbindelse med brugerinteraktionen, f.eks. tastatur og mus. I denne afhandling anvendes begrebet om den grafiske brugergrænseflade som ses af brugeren på skærmen. 5 Programmets kode og de øvrige dataelementer lagres i filer på computeren, og udgør programmets binære bestanddele. Når softwaren først er kompileret til objektkode eller bytekode (læs nærmere nedenfor) er der ikke altid en skarp opdeling mellem datafiler og kodefiler. Alt afhængig af programmets opbygning vil både kode og data kunne være indeholdt i samme filer, og være svær at adskille. Herved opstår en særlig problemstilling i forhold til reverse engineering. Spørgsmålet er om der som del af processen må foretages eksemplarfremstilling af data, selvom disse ikke omfattes af det ophavsretlige programbegreb? Svaret er formentlig ja - se hertil nærmere afsnit 3.2.4. 6 I relation til brugergrænsefladen og de anvendte skrifttyper vil designretten endvidere kunne have relevans som supplement til ophavsretten. Også markedsføringslovens 1 vil kunne værne mod meget nærgående efterligninger af brugergrænsefladen. Disse regelsæt omtales ikke nærmere. 4
Programkoden består af et antal instruktioner, som er udarbejdet med henblik på, at få en computer til at udføre en given handling/funktion. Instruktionerne er rettet mod computeren processor og har til formål at aktivere/udføre visse prædefinerede regneoperationer heri. Processoren udfører, med andre ord, de instruktioner som indeholdes i softwaren, og fungerer herved som bindeled mellem programmet og de øvrige hardware-komponenter. Ved hardware forstås samtlige de fysiske komponenter (processor, grafikkort, bundkort, ram, printere mv.) i et computersystem. Computeren kan være integreret i industrielle maskiner, mobiltelefoner, vaskemaskiner mv., eller der kan være tale om personlige computere (PC eller Macintosh computere). Software distribueres både på fysiske medier, via internettet og findes også integreret direkte i computernes interne chips. 7 De instruktioner, som programkoden består af, udarbejdes af en programmør i et såkaldt programmeringssprog, som f.eks. C++, C#, Java mv. Disse sprog, som er baseret på en helt fast, men indbyrdes forskelligartet, semantik, stiller programmøren en overordnet ramme til rådighed, hvori han kan strukturere og udforme de algoritmer, der er nødvendige for at opnå den ønskede funktionalitet. Implementeres samme funktionalitet i forskellige sprog, vil koden rent litterært fremstå forskelligt fra sprog til sprog. Sprog som de nævnte kaldes i faglitteraturen for højniveausprog og er karakteriseret ved at være relativ letforståelige for personer med fagkundskab. Programmøren strukturerer programmet, ved brug af sprogets prædefinerende syntaks, og søger ved hjælp af kommentarer, og logisk navngivning af kodens forskellige elementer (funktioner, variabler, klasser mv.), at gøre den let tilgængelig for fremtidige opdateringer og andre, der skal arbejde videre med koden. Algoritmer udformet i et højniveausprog, benævnes kildekode. Denne kan ikke umiddelbart fortolkes af processoren, hvorfor den må kompileres (omformes) til såkaldt objektkode, førend programmet kan benyttes til sit formål. Ved objektkode, også kaldet binær kode, forstås et antal nul og et-taller, som computerens processor er i stand til at fortolke. Kildekoden ekspanderer rent kvantitativt, når den kompileres, og få kodelinjer kan derfor resultere i hundredvis af processorinstruktioner på objektkode-niveau. Formålet med ovennævnte højniveau-sprog er at skabe et miljø, som gør det lettere og hurtigere for programmøren at udvikle software, ved at isolere den pågældende fra objektkoden. Denne er meget besværlig at arbejde med, idet den er udformet og struktureret i henhold til processorens logik ikke menneskets. Der indsættes på denne vis et mellemled, et abstraktionsniveau om man vil, mellem programmøren og processoren, som skal afvikle koden. Det må bemærkes, at objektkoden er platformspecifik, hvorved forstås at de pågældende programinstrukser er målrettet et givent software- 7 Denne type programmer betegnes typisk firmware. 5
miljø, f.eks. et operativsystem så som Windows, og en specifik hardware-arkitektur. 8 Hvor programmøren ønsker, at programmet kan afvikles på flere forskellige platforme, er det derfor nødvendigt at kompilere og distribuere flere versioner af objektkoden, som tilpasses hertil. Objektkoden i et program, der udvikles og distribueres til Windows, er således forskellig fra den, der ligger til grund for programmet når det distribueres med henblik på afvikling i Linux, selvom programmerne for brugeren fremstår som identiske. Kompileringen fra kildekode til objektkode sker ikke altid i én proces. Visse programmeringssprog er konstrueret så kildekoden, i første ombæring, kompileres til såkaldt byte code. Denne kode, som befinder sig på et mellemstadie mellem kilde- og objektkode, bliver herefter distribueret og ved kørsel fortolket af et andet program, der oversætter til den objektkode, som kan afvikles på brugerens maskine. Det ekstra led, mellem kildekode og objektkode, har blandt andet til formål at give programmøren øget fleksibilitet, og gøre koden uafhængig af platformen, hvorpå det afvikles. 9 Dette er selvsagt essentielt for applikationer, f.eks. netbank og mobilapplikationer, hvor udbyderen ønsker at henvende sig til en bred skare af brugere, uafhængigt af hvilken hardware, og hvilket operativsystem, der benyttes. Både objekt- og byte-kodens udformning afhænger af en lang række faktorer, herunder i hvilket programmeringssprog kildekoden er skrevet og hvilke optimeringer, der foretages ved kompilering af kildekoden. De overordnede rammer for programmets virkemåde er oftest beskrevet i det forberedende arbejde, der ligger til grund for programmeringen. Når dette er fastlagt, består det resterende arbejde i at skrive og strukturere selve programinstruktionerne i henhold til den semantik, og efter den syntaks, der er gældende for det valgte programmeringssprog. Selve programmeringsarbejdet er af ren håndværksmæssig karakter, uden selvstændig innovativ betydning. Innovationen skal findes i den del af udviklingsfasen, der lægger forinden selve implementeringen. På baggrund af ovenstående vises i figur 2 en overordnet illustration over udviklingsprocessen og den tekniske afvikling af software: 8 Som eksempel på en meget udbredt hardware-arkitektur kan nævnes IA32 platformen som er udviklet af den amerikanske IT-virksomhed Intel, og som beskriver en række instruktioner som kompatible processorer er i stand til at fortolke. I dag er arkitekturen implementeret i processorer fra en lang række producenter og understøttes af en lang række styresystemer som eksempelvis Microsoft Windows, Linux, Unix og Apple OS X. 9 Java er et eksempel på et byte-kode baseret programmeringssprog, som er afhængig af at brugeren installerer em fortolker hertil. Det er således fortolkeren, der kompileres til forskellige platforme, mens selve java-applikationen forbliver platforms-uafhængig. 6
Figur 2: Fra ide til teknisk effekt Adskillelsen af de 3 programstadier (kildekode, byte-kode, og objektkode) tjener ikke direkte et formål i relation til den retsdogmatiske analyse, idet hverken ophavsretten eller patentretten sondrer imellem de former som et program måtte antage. Retspolitisk, og i forhold til den praktiske forståelse af software s virkemåde, er sondringen dog relevant. Dette fordi at resultatet af såkaldt reverse engineering, hvis formål er skabe indsigt i programmets kode, afhænger af den kode som ligger til grund for processen. 10 Ved byte-kode kan typisk udledes mere detaljeret information om programkoden og dens algoritmer, hvilket taler for, at tilsige udviklere en retlig beskyttelse mod reverse engineering. Afslutningsvis bemærkes at størstedelen af de kommercielle software-produkter, der forhandles, typisk distribueres i form af den endelige og afviklingsklare objektkode (eller byte-kode). Kildekoden holdes, af konkurrence- og sikkerhedsmæssige hensyn, tæt til kroppen og deles kun med særlig betroede samarbejdspartnere. Konkurrencemæssigt kan formålet være at hindre konkurrenter i at plagiere, men hemmeligholdelsen kan også have til formål at besværliggøre udvikling af produkter, som kan opnå interoperabilitet med rettighedshaverens produkt. Sikkerhedsmæssigt kan formålet være, at forhindre hackere i at få indsigt i produktets sikkerhedsforanstaltninger og eventuelle brister. For så vidt angår skræddersyet programmel indgås derimod ofte licensaftaler mellem virksomheder, hvor kildekoden gøres tilgængelig for implementering i licenstagers egne produkter, eller med det formål at gøre licenstager i stand til at rette fejl og opdatere programmet. Endelig er Open source -programmer, som modstykke til den proprietære (lukkede) software, blevet mere udbredt de seneste år og karakteriseres ved at kildekoden er frit tilgængelig. 10 Processen gøres til genstand for nærmere omtale i afsnit 3.2.4. 7
3 Ophavsret til edb-programmer 3.1 Retsgrundlaget Den ophavsretlige beskyttelse baserer sig, i store dele af verden, på samme grundlæggende principper, hvilket skyldes, at et stort antal lande har ratificeret konventioner, som udstikker rammer for enerettens opnåelse, omfang og håndhævelse. På internationalt plan har navnlig TRIPS-aftalen, WIPO Copyright Treaty (WCT) og, på mere overordnet plan, Berner-Konventionen relevans. 11 Egentlige detailbestemmelser, som specifikt regulerer retsbeskyttelsen, i forhold til edb-programmer, findes dog ikke i disse konventioner. TRIPS-aftalen bestemmer i art. 10, at edb-programmer skal behandles som litterære værker, i henhold til Berner-Konventionen, og samme fremgår af WCT art. 4. Af relevans i forhold til edb-programmer er i øvrigt kun overordnede generelle principper og regler, som vedrører ophavsretlige værker over en bred kam. Disse er i øvrigt udtrykt i ophavsretsloven, og den praksis der har udviklet sig i Danmark. TRIPS-aftalen, WCT og Berner Konvention har derfor begrænset selvstændig værdi i relation til beskrivelse og analyse af den immaterialretlige beskyttelse af edb-programmer i EU, specielt når henses til, at der eksisterer to direktiver, som direkte vedrører emnet. Fokus i det følgende vil på denne baggrund være direktiv 2009/24/EF (edbdirektivet) 12, direktiv 2001/29/EF (Infosoc-direktivet) 13, samt ophavsretsloven (OPHL) 14. Den internationale ratifikation, af de generelle principper og regler i Berner-konventionen, TRIPS-aftalen og WCT, medfører dog at der i vidt omfang kan hentes inspiration fra, og drages paralleller til den praksis, der har udviklet sig i jurisdiktioner udenfor EU. I den forbindelse er særlig USA relevant, da her findes en relativ veludviklet retspraksis på området. Selvom det, indenfor rammerne af denne fremstilling, vil gå for vidt, at foretage en egentlig komparativ analyse, vil amerikansk praksis blive inddraget til, at illustrere den her gældende tilgang. 3.2 Retsbeskyttelsen Den ophavsretlige beskyttelse af edb-programmer er langt fra nogen nyskabelse i dansk ret. Selvom denne værkstype ikke tidligere var eksplicit angivet i ophavsretsloven, må det antages, at edb-programmer længe 11 For nærmere omtale af disse konventioner henvises til Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s. 39-45. Berner-konventionen og WCT administreres af WIPO (World Intellectual Property Organization), mens TRIPSaftalen administreres af WTO (World Trade Organization). 12 Direktiv 2009/24/EF, af 23. april 2009, om retlig beskyttelse af edb-programmer, ophævede direktiv 91/250/EF og kodificerede de efterfølgende ændringer, der havde været siden 1991, hvor dette blev vedtaget. Det nye direktiv medførte ingen materielle ændringer i beskyttelsen af edb-programmer. Som det fremgår af direktivets betragtning nr. 1 blev kodificeringen foretaget af klarheds- og rationaliseringshensyn. 13 Direktiv 2001/29/EF, af 22. maj 2001, om harmonisering af visse aspekter af ophavsret og beslægtede rettigheder i informationssamfundet. 14 LBK nr. 587 af 20. juni 2008. 8
har nydt beskyttelse, som litterære værker ud fra en analogislutning til OPHL 1, stk. 1. 15 Ikke desto mindre mente man fra lovgivers side, at det var nødvendigt at fjerne enhver tvivl, ved direkte at nævne edbprogrammer som et beskyttet værk i ophavsretsloven. Dette skete ved Lov nr. 378 af 7. juni 1989, hvorefter OPHL 1, stk. 2 blev ændret til også at omfatte edb-programmer. Siden er der på tilsvarende vis blevet taget stilling til den ophavsretlige beskyttelse af edb-programmer i både internationale konventioner og i EU, hvor edb-direktivet harmoniserer en række ophavsretlige regler specifikt i relation til edb-programmer, jf. ovenfor. I forbindelse med den danske implementering af direktivet i 1992 blev edb-programmerne flyttet fra OPHL 1, stk. 2 for herefter at fremgå selvstændigt af OPHL 1, stk. 3. 16 Herved var dog ikke tiltænkt nogen realitetsændring - ændringen blev, som udtrykt i lovbemærkningerne, alene foretaget af redaktionelle grunde. 17 Direktivet svarede i store træk til den lovændring, der i Danmark blev gennemført allerede 1989. 18 Reglerne i OPHL 36-37, vedr. bl.a. reverse engineering, og kapitel 6a, vedr. omgåelse af kopispærringer, var dog væsentlige nyskabelser i dansk ret. 19 De grundlæggende betingelser, der skal opfyldes, førend der er tale om et værk i ophavsretslovens forstand, henføres i teorien til værkslæren, mens de kriterier, der inddrages, med henblik på at afgøre om der foreligger en krænkelse, henføres til krænkelseslæren. I afsnit 3.2.1 fokuseres på værkslæren, mens der i afsnit 3.2.2, foretages en analyse af beskyttelsens indhold og omfang, med det formål at fastlægge hvilke handlinger, der potentielt vil være i strid med ophavsmandens eneret. 3.2.1 Edb-programmer som ophavsretlige værker Det fremgår af OPHL 1, stk. 3, at værker i form af edb-programmer henregnes til litterære værker, jf. OPHL 1, stk. 1. Det følger derfor umiddelbart, at der skal være tale om et værk i ophavsretslovens forstand, og at dette som udgangspunkt skal behandles efter de almindelige principper og regler, som gældende for litterære værker. Noget andet er, at værkstypen adskiller sig så væsentligt fra traditionelle litterære værker at der, som nævnt, er indført en række regler, som specifikt relaterer sig til edbprogrammer. Alene undtagelserne vedrørende reverse engineering, i OPHL 36-37, vil dog blive inddraget i denne fremstilling, da de har kommercielt sigte og dermed relevans, når den ophavsretlige beskyttelse skal sammenlignes med den patentretlige. 15 Jf. også bemærkningerne til 89-loven (lovforslag nr. L 132, FT 1988-89, tillæg A, fremsat den 8. december 1988) som indførte edb-programmer som beskyttet værk i OPHL 1, stk. 2. Se hertil også Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s. 66. 16 Direktivet blev implementeret ved lov nr. 1010 af 19. december 1992. 17 Jf. bemærkningerne til lovforslag nr. L 74, FT 1992-93, tillæg A, fremsat den 28. oktober 1992. 18 jf. også Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s. 71-72. 19 jf. også bemærkningerne til lovforslag nr. L 74, FT 1992-93, tillæg A, fremsat den 28. oktober 1992. 9
I modsætning til patentretten er ophavsretten formfri. Dette medfører at eneretten opnås, uden nærmere tiltag, allerede på det tidspunkt hvor der er skabt et værk. Ophavsretten er endvidere ikke nogen prioritetsret, hvor ansøgning, eller tidspunktet for værkets skabelse, er afgørende for hvem, der skal betragtes som ophavsmand. Der stilles alene et subjektivt nyhedskrav, hvorved forstås, at ophavsretten ikke forbyder dobbeltfrembringelser, i det omfang der skabes to identiske værker uafhængigt af hinanden. 3.2.1.1 Retsbeskyttelsens genstand - programbegrebet Begrebet edb-program i edb-direktivet, og OPHL 1, stk. 3, dækker alene over selve programkoden samt det forberedende designmateriale, som lægger til grund for programmets implementering i kode. 20 Sidstnævnte udvidelse af programbegrebet følger af edb-direktivets art. 1, stk. 1, 2. pkt. og af præamplens betragtning 7, hvor det dog indskærpes, at det forberedende arbejde alene beskyttes i det omfang at et edb-program på et senere stadium kan være et resultat heraf. Der stilles derfor visse krav til, hvor konkret og præcist dette designmateriale skal fremstå for at kunne opnå beskyttelse. Retsbeskyttelsen af det forberedende materiale analyseres nærmere i afsnit 3.2.3. Som nævnt, i afsnit 1, kan programmets datamateriale og designet af den grafiske brugerflade være beskyttet på andet retsgrundlag, f.eks. kan den elektroniske brugermanual være beskyttet som litterært værk efter OPHL 1, stk. 1, den anvendte grafik som billedkunst efter samme bestemmelse, programmets databaser efter OPHL 1, stk. 1, 5 eller 71, og dets skrifttyper efter designretten osv. Da sådanne elementer ikke omfattes af særreglerne vedrørende edb-programmer, kan der eksempelvis lovligt foretages privat eksemplarfremstilling, af den grafik og de billeder, der indgår i edb-programmet, jf. OPHL 12, stk. 2, nr. 5. Retsbeskyttelsen af programmets datagrundlag og grafiske brugergrænseflade 21 behandles ikke nærmere. At programmets data og grafiske brugerflade ikke omfattes af programbegrebet, anføres ikke eksplicit i hverken direktivet eller i OPHL, men følger implicit af flere forhold. For det første er det ikke logisk at henføre data i form af film, databaser, billeder mv., eller den grafiske brugerflade, til litterære værker. For det andet anvendes i præamplen til edb-direktivet begrebet kode, hvilket vidner om at sigtet med direktivet, har været retsbeskyttelsen af selve programkoden. 22 20 Dette er fast antaget. Se eksempelvis Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s. 73-74, Mads Bryde Andersen: IT-retten, 2005 s. 357-358; Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 191-195 samt Jon Bing: Vurderering av opphavsrettslig krenkelse av datamaskinprogrammer et praktisk perspektiv, i NIR 2/1999, s. 285. 21 For omtale af retsbeskyttelsen i forhold til den grafiske brugergrænseflade henvises til Mads Bryde Andersen: ITretten, 2005 s. 370-377, Thomas Riis: Immaterialret & IT, 2001 s. 39-43, Hanne Bender: EDB rettigheder, 1998 s. 76-85 samt Hanne Bender: Ophavsret til brugergrænseflader look and feel, i NIR 1/1997, s. 69. 22 Se betragtning nr. 15 i præamplen til direktiv 2009/24/EF, af 23. april 2009, om retlig beskyttelse af edbprogrammer. 10
I ophavsretsloven findes imidlertid ingen definition på et edb-program, og sondringen mellem programkode og data må derfor ske på løsere grundlag. I bemærkningerne til lovforslaget 23, som i 1989 førte til en ændring 24 af ophavsretsloven, var følgende definition på et edb-program angivet: Et edb-program er en række instruktioner eller oplysninger, fikseret i en hvilken som helst form eller på et hvilket som helst medium, som tilsigter direkte eller indirekte at bringe en datamat til at angive, udføre eller opnå en bestemt funktion, opgave eller et bestemt resultat. 25 Definitionen genfindes ikke i nyere love eller forarbejder, og kunne da også fremstå skarpere for herved at indskærpe, at der sigtes til programkode og ikke data. Navnlig brugen af ordene oplysninger og indirekte er egnet til at skabe uklarhed. Med henblik på at udskille programmets data, kunne en bedre definition eksempelvis lyde: Et edb-program er en række instruktioner, fikseret i en hvilken som helst form eller på et hvilket som helst medium, som udviklet med henblik på, at aktivere et antal prædefinerede regneoperationer i en computers processor, med det formål at få en computer til at udføre en bestemt funktion. 26 Data indeholder informationer, og ikke instruktioner, som er udviklet med henblik på at aktivere et antal prædefinerede regneoperationer i en processor. Data tilsigter endvidere ikke at opnå en bestemt funktion. Det er således ikke givet på forhånd, hvordan de pågældende data benyttes. Et billede kan f.eks. udskrives, e-mailes eller vises på skærmen. Programkoden i den applikation, der behandler de pågældende data, f.eks. et billed-behandlingsprogram, udfører derimod en bestemt funktion. Selvom det på baggrund af en sådan definition står klart, at data i form af tekst, billeder, film mv., ikke omfattes af programbegrebet, består stadig visse grænsetilfælde, hvor rubriceringen ikke er oplagt. Kommentarer i kildekoden og integreret tekst, til f.eks. programmets hjælpefunktioner, kan umiddelbart give anledning til tvivl, idet der består en meget nær tilknytning til selve programkoden. Anvendes en definition som ovenfor, forekommer det imidlertid klart, at disse elementer, uanset om de indlejres i koden, ikke omfattes af programbegrebet, da der er tale om data. 27 Spørgsmålet er imidlertid, om det i alle tilfælde er hensigtsmæssigt med en så skarp og formalistisk sondring. Tilgangen kan navnlig være uhensigtsmæssig i forbindelse med reglen i OPHL 59, hvorefter ophavsretten, som deklaratorisk 23 Lovforslag nr. L 74, FT 1992-93, tillæg A, fremsat den 28. oktober 1992. 24 Lov nr. 378 af 7. juni 1989. Loven blev som nævnt ændret ved lov nr. 1010 af 19. december 1992, som implementerede direktiv 91/250/EØF om retlig beskyttelse af edb-programmer. 25 Begrebet datamat er et ældre betegnelse for det moderne udtryk computer. 26 Morten Rosenmeier kritiserer ligeledes definitionen for at være for uklar og fremsætter et andet bud på en definition som, på meget lavteknisk niveau, sondrer mellem instruktioner og data. Se Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 195. 27 Jf. også Mads Bryde Andersen: IT-retten, 2005 s. 359-360. 11
hovedregel, overgår til arbejdsgiver, hvis edb-programmet er udviklet som led i et ansættelsesforhold. Anses eksempelvis kommentarer i koden for almindelige litterære værker, vil ophavsretten hertil ikke overgå automatisk, men afhænge af den ulovhjemlede ophavsretlige regel, hvorefter retten ikke overgår i videre omgang end det er nødvendigt af hensyn til arbejdsgivers sædvanlige virksomhed. Det ophavsretlige programbegreb må derfor formentlig tilpasses konteksten, og fortolkes fleksibelt, så sådanne uhensigtsmæssigheder undgås. 28 Det må endvidere nævnes, at der eksisterer forskellige former for instruktioner, som ikke er oplagte at kvalificere som edb-programmer. I denne gråzone findes eksempelvis HTML-formatering, SQLforespørgsler, JavaScript og makroer. 29 Fælles for disse emner er, at de ikke kompileres til objektkode, som kan fortolkes direkte af computerens processor, men at de afvikles indenfor rammerne af et andet edbprogram, f.eks. en webbrowser (HTML og JavaScript), en databaseserver applikation (SQL) eller et tekstbehandlingsprogram (Makro). Ikke desto mindre har de alle til hensigt, at opnå en bestemt funktion på computeren, og de adskiller sig derfor fra passive data i form af f.eks. billeder. Man kan vælge, at indskrænke programbegrebet, til kun at favne programmer som kan afvikles direkte, og herved udelukke samtlige nævnte emner, eller man kan foretage en individuel vurdering, baseret på de tekniske karakteristika, der kendetegner dem. Sidstnævnte vil være at foretrække, med henblik på at skabe konvergens mellem den tekniske og den juridiske forståelse. Programkoden er central for det ophavsretlige edb-program -begreb, og da sådan kode udarbejdes i et programmeringssprog, vil der, som hjælperedskab, kunne henses til hvad der af programmører betragtes som programmeringssprog. På denne baggrund står det klart, at f.eks. makroer og JavaScript er at betragte som edb-programmer, mens HTML og SQL ikke favnes af begrebet. 30 Denne vurdering underbygges endvidere af de karakteristika, der kendetegner de sidstnævnte sprog. Den funktion som opnås i kraft af ren HTML relaterer sig til struktureringen af en hjemmeside, og omtales da også som et formateringssprog ikke et programmeringssprog og sigtet er ikke at opnå egentlige dynamiske effekter. HTML minder med andre ord mest om de informationer, der, foruden selve teksten, indeholdes i tekstfil, og som har til formål, at fortælle tekstbehandlingsprogrammet hvordan teksten skal præsenteres (understregning, fed tekst, tabeller mv.). Da en tekstfil selvsagt ikke kan betragtes som et edb-program, må samme gælde HTML. 28 Tilsvarende opfattelse ses hos Jon Bing: Ophavsretten og ny informasjonsteknologi: Noen sprete notater, i NIR 4/1995, s. 605-606. Mads Bryde Andersen: IT-retten, 2005 s. 360, synes at være af modsat opfattelse. 29 Der kan tænkes andre tilfælde hvor en teknologi kan give anledning til tvivl, og flere vil komme til i takt med den tekniske udvikling. De nævnte teknologier er dog illustrerende for problemstillingen. 30 Vedrørende makroer og HTML nås samme konklusion af Mads Bryde Andersen: IT-retten, 2005 s. 360-361, som dog baserer sig på anden argumentation. Vedrørende HTML henvises endvidere til Anders Mediaas Wagle & Magnus Ødegaard jr.: Opphavsrett i en digital verden, 1998 s. 80-83. 12
Programbegrebet vil formentlig heller ikke favne SQL, idet der alene er tale om en sprogstandard, for interaktion med elektroniske databaser. SQL-kommandoer findes indlejret i edb-programmer og websider, og opnår ingen selvstændig effekt. Sondringen mellem edb-program og data vil næppe give anledning til større problemer i praksis. En teoretisk dissektion af edb-programmer, som foretaget herover, vil endvidere ikke have større materiel betydning. Dette skyldes, at elementer, som ikke favnes af programbegrebet, efter omstændighederne, vil kunne opnå beskyttelse på andet grundlag navnlig OPHL 1, stk. 1-2. Hertil bemærkes, at de nævnte instruktioner, som befinder sig i en gråzone, er af sådan karakter at specielreglerne vedr. edb-programmer ikke har relevans i forhold hertil. Det giver eksempelvis ikke mening, at tale om reverse engineering af HTML og Javascript, idet koden kan ses direkte i webbrowseren. Kun i forhold til OPHL 59, vedr. ophavsrettens overgang til arbejdsgiver, vil rubriceringen i sjældne tilfælde have materiel betydning. Om programkoden skrives direkte af ophavsmanden, eller om den autogenereres ved brug af grafiske værktøjer (edb-programmer), kan ikke antages af have betydning for rubriceringen som edb-program. Det kan derimod påvirke originalitetsvurderingen, idet der ikke består samme frihed i forbindelse med udformningen af autogeneret programkode. 31 Det må endelig nævnes at programmer, som sammensættes af allerede eksisterende kodemoduler, vil kunne betragtes som samleværker efter OPHL 5, forudsat at de enkelte moduler udgør værker, og at sammenstillingen i øvrigt er original. 32 Et edb-program beskyttes, jf. edb-direktivets art. 1, stk. 2, 1. pkt. og OPHL 2, stk. 2, 1. pkt., uanset udtryksform. Beskyttelsen indtræder derfor, hvad enten programkoden udskrives på papir, implementeres i computersystemers interne chips eller om den lagres på et medie (cd er, dvd er, blue ray disks mv.). Det er desuden uden betydning for beskyttelsen, hvilket stadie (kildekode, bytekode, objektkode) programmets kode befinder sig på, og om det kan anses for færdigt, i den forstand at det har taget sin endelige form. 3.2.1.2 Originalitetskravet For at et edb-program kan opnå ophavsretlig beskyttelse kræves, som med andre værker, at det pågældende produkt er originalt. Dette krav defineres typisk, som et krav om at værket skal være et resultat af ophavsmandens selvstændigt skabende indsats, eller at det skal have værkshøjde, særpræg, individualitet mv. 33 Begreberne dækker over to overordnede betingelser. Værket skal for det 31 Det kan desuden overvejes om den der, skaber et program, ved brug af sådanne værktøjer med rette kan anses for, at være ophavsmanden til koden, eller om koden må anses for skabt af selve værktøjet, med det resultat at der ikke er tale om et værk? Det må vurdere, at den der benytter værktøjet stadig vil være at anse for ophavsmand, men originalitetsvurderingen må skærpes som følge af den begrænsede udtryksfrihed i relation til koden. 32 For nærmere omtale se Mads Bryde Andersen: IT-retten, 2005 s. 412-413 samt s. 300-301. 33 For nærmere omtale af disse begreber henvises til Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 118 ff. 13
første være skabt af ophavsmanden selv og for det andet, skal det være udtryk for en vis kreativitet. Sidstnævnte udelukker retsbeskyttelse af frembringelser, som er resultat af ren håndværksmæssig eller rutinemæssig indsats, uden personligt præg. 34 Ophavsmanden skal, med andre ord, have haft valgfrihed i forbindelse med værkets udformning (valgfrihedslæren). Disse noget abstrakte krav har, i den juridiske teori givet grundlag for en del analyser, men overordnet kan konkluderes, at der ikke er tale om noget strengt originalitetskrav. Som anført i edb-direktivets art. 1, stk. 3 kræves, i relation til edb-programmer, alene, at det pågældende edb-program er udtryk for ophavsmandens egen intellektuelle frembringelse og der gælder ikke andre kriterier for om et edb-program er berettiget til beskyttelse. I præamplens betragtning 8, anføres endvidere at de kriterier, der skal lægges til grund for at afgøre, om et edb-program er et originalt værk eller ej, bør ikke omfatte afprøvning af edb-programmets kvalitetsmæssige eller æstetiske værdi. Det står derfor klart, at der formelt ikke stilles krav om, at programmet er resultat af en væsentlig resursemæssig investering, at det antager et vist kvantitativt omfang (et antal kodelinjer), at det er effektivt og fejlfrit, at det er innovativt og nyskabende 35, eller lignende. Ideer og andre abstrakte fænomener er derimod ikke at anse for værker, hvilket følger af det almindelige ophavsretlige princip om den manglende ide-beskyttelse og tillige af edb-direktivets art. 1, stk. 2, 2. pkt. 36 Ophavsretten favner således alene værkets konkrete udtryk og ikke ideer, principper, metoder, fremgangsmåder og lignende, som befinder sig på et højere abstraktionsniveau. Selvom ophavsretten ikke er en prioritetsret, ville det være stærkt hæmmende, for udvikling og innovation 37, såfremt det var retsstridigt, at lade sig inspirere af sådanne abstrakte fænomener. I forhold til edb-programmer kræver det ikke megen fantasi, at forestille sig den markedsmagt, som en sådan idebeskyttelse ville tilsige ophavsmanden. Eneret på eksempelvis en programmeringsmetode, en teknisk funktion, måden at formatere data på, eller princippet for opbygningen af en grafisk brugergrænseflade, vil kunne strække sig på tværs af brancher og indsnævre det øvrige markeds udfoldelsesmuligheder i urimeligt omfang. Frygten for sådanne de facto monopoler er da også den primære drivkraft bag kritikken af patenter på software. 38 Selvom idegrundsætningen er fornuftig, og velegnet til at udelukke abstrakte og overordnede fænomener fra beskyttelse, forekommer der tilfælde, hvor den er svær at operationalisere. Dette skyldes, at overgangen fra ide til manifestation er glidende, og der lader sig ikke opstille klare kriterier for 34 Jf. Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s. 62. 35 Modsat i patentretten, hvor der stilles krav om at opfindelsen er ny, at den kan udnyttes industrielt og at den adskiller sig væsentligt fra det allerede kendte. Se hertil afsnit 4.3. 36 Se vedr. princippet eksempelvis Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 66-75. 37 I den mere traditionelle ophavsret, som vedrører ikke-industrielle værker, vil det nærmere være kreativitet og ytringsfrihed, der begrænses. 38 Se afsnit 4.4. 14
afgrænsningen. Specifikt i relation til edb-programmer er spørgsmålet særligt, om det forberedende designmateriale kan anses for et eksemplar af programmet på et tidligere stadie, og herved opnå beskyttelse mod implementering, eller om sådan beskyttelse må udelukkes, som følge af materialets overordnede og abstrakte fremtrædelsesform - se hertil afsnit 3.2.3. Når det er afgjort, på hvilket niveau beskyttelsen sætter ind, opstår dernæst spørgsmålet, om hvor bredt beskyttelsen strækker sig. I tilfælde hvor originalværket bearbejdes, kan det være svært at vurdere, om bearbejdelsen er udtryk for en variation af originalværket, eller om der alene er tale om fri benyttelse af overordnede og ubeskyttede ideelementer. Denne problemstilling analyseres i afsnit 3.2.2. Kvantitetskrav? Selvom de fleste moderne edb-programmer i praksis vil blive anset for værker, grundet deres kompleksitet, må det vurderes at meget simple edb-programmer, som ikke antager et vist kvantitativt omfang rent kodemæssigt, ikke vil opfylde kravet om originalitet. Programmeringssprog sætter, som nævnt i afsnit 2, grænser for udtryksfriheden, som følge af den meget faste semantik. Hvor selv relativt korte litterære værker normalt kan opnå retsbeskyttelse, må edb-programmer derfor typisk antage et vist omfang, førend de kan siges at være originale. Forestiller vi os et teoretisk tilfælde, hvor et program er så simpelt, at der kun eksisterer én, eller meget få, effektive metode(r) til opnåelse af dets funktion, udtrykker det således ikke en intellektuel frembringelse, men en rutinepræget indsats. Originalitet kræver at programmøren i forbindelse med udviklingen har haft en vis valgfrihed, og et omfangsrigt program vil, alt andet lige, levne ophavsmanden et større kreativt spillerum. Reelt kræves derfor, at programmet antager et vist kvantitativt omfang. Samme ræsonnement opnås på baggrund af den såkaldte dobbeltfrembringelseslære, hvorefter der som kriterium for originalitet kan henses til sandsynligheden for at andre, uafhængigt af ophavsmanden, ville skrive samme kildekode. 39 Hvor der eksisterer få variationsmuligheder vil dette princip trække i retning af manglende originalitet, og det særpræg, der nødvendigvis vil præge større og mere komplekse programmer, vil gøre det mere sandsynligt, at funktionaliteten kan udformes på alternativ vis. Problemstillingen kan alternativt anskues fra det synspunkt at ide og funktion, i tilfælde som de nævnte, smelter sammen, hvorfor princippet om den manglende idebeskyttelse vil medføre, at edb-programmet ikke udgør et værk. Denne tilgang er udtrykt i amerikansk ret, i form af den såkaldte merger doktrin, der blev skabt på baggrund af sagen Baker v. Selden 40, og kan i dansk ret indeholdes i originalitetsvurderingen, 39 Se hertil Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 132-144. 40 Baker v. Selden, 101 U.S. 99 (1879). 15
herunder dobbeltfrembringelseslæren og valgfrihedslæren. 41 Består et 1:1 forhold mellem ide og funktion, er sandsynligheden for dobbeltfrembringelser 100 %, og der er ikke mulighed for at udøve en kreativ eller intellektuel indsats i forbindelse med implementeringen. Hvis programkode udelukkende er udtryk for en alment kendt best practice (f.eks. en algoritme som beskrevet i faglitteraturen), krav som udformet specifikt i en åben standard, interoperabilitetskrav, lovkrav (f.eks. en metode til at beregne afgiftsbeløb), branchekrav, og andre krav som er fastsat på forhånd, kan koden ej heller anses for original. Dette fordi der, i overensstemmelse med dobbeltfrembringelseslæren og valgfrihedslæren, ikke kan siges, at være tale om en intellektuel indsats, som foreskrevet i direktivet, såfremt der i forbindelse med implementeringen ikke består reelle valgmuligheder. 42 Kvalitetskrav? Omfanget af et program vil ikke i alle tilfælde være afgørende for originalitetsvurderingen. Skyldes omfanget alene, at koden er dårlig skrevet og struktureret, vil originalitetskravet ikke nødvendigvis være opfyldt. I sådanne tilfælde vil koden, trods omfanget, kunne udtrykke en simpel funktion, som det kun er muligt at implementere på et fåtal af effektive måder. Findes der kun ineffektive alternativer til den pågældende programkode, må dette tages som indicium for manglende originalitet. Af samme årsag bør dobbeltfrembringelseslæren ikke anvendes uden omtanke, idet man risikerer at præmiere den dårligt skrevne kode med ophavsretlig beskyttelse, mens velskrevet og effektiv kode, som opnår tilsvarende funktionalitet, ikke kan anses for original. 43 Dette fordi, at risikoen for dobbeltfrembringelser i relation til førstnævnte, som fremstår mere særegen, er minimal, mens det forholder sig modsat i forhold til sidstnævnte. Denne problemstilling vil primært være relevant som del af krænkelseslæren, i tilfælde hvor mindre dele af programkoden er plagieret. Edb-programmet vil som helhed typisk udgøre et værk, uanset om det er velskrevet og velfungerende eller ej. Den praktiske relevans vil endvidere være begrænset, idet de færreste har nogen interesse i at plagiere ineffektiv kode. Der kan argumenteres for, at en sådan anvendelse af dobbeltfrembringelseslæren er direktivstridig, idet den inddrager kvalitetsmomenter i originalitetsvurderingen, i strid med edb-direktivets art. 1, stk. 3. Det må imidlertid vurderes ikke at være tilfældet. Tilgangen udelukker ikke lavkvalitets-programmel fra at opnå beskyttelse, men er blot udtryk for en vurdering af, om den pågældende kode reelt kun kan implementeres 41 Jf. også Hanne Kirk Deichmann: Programkoncepter ophavsret til tv-formater, 2002 s. 202. 42 Typisk vil der imidlertid være tale om så overordnede metoder og specifikationer, at der består stor frihed i forhold til den konkrete implementering i kildekode. 43 Jf. Mads Bryde Andersen: IT-retten, 2005 s. 296-297. 16
på én eller få effektive måder. Dette er fint i tråd med kravet om intellektuel indsats der, som nævnt, kræver valgfrihed. Den praktiske hovedregel Et edb-program vil sjældent være så simpelt, at det som helhed må udelukkes fra beskyttelse, som følge af mangel på originalitet. De fleste moderne edb-programmer består af tusindvis af kodelinjer, hvilket efterlader rigeligt med spillerum, når der skal udvikles konkurrerende programmer med tilsvarende funktionalitet. Originalitetsvurderingen, herunder dobbeltfrembringelseslæren og valgfrihedslæren, vil derfor sjældent have praktisk aktualitet som del af værkslæren. Anderledes aktuelt fremstår disse vurderingsnormer når det skal afgøres, om et givent program udgør en krænkelse af ophavsmandens eneret (krænkelseslæren), og det kun er dele af programmet eller mere abstrakte elementer, som f.eks. programmets overordnede algoritmer, der går igen (se hertil afsnit 3.2.2). Det bemærkes endvidere at kode som udformet på baggrund af specifikke branchekrav, teknologiske standarder eller alment kendte algoritmer sjældent vil udgøre et programs helhed, men alene være et element heri. Sådanne krav vil oftest være af så overordnet karakter, at der i forhold til deres konkrete implementering i kode, vil bestå tilstrækkeligt med variationsmuligheder til, at koden kan betragtes som original. Sammenfattende må konkluderes, at edb-programmer, som ikke udgøres af helt basale og simple algoritmer, har den fornødne originalitet til at opnå ophavsretlig beskyttelse. Thomas Riis maner dog til forsigtighed, og udtaler at den ophavsretlige bedømmelse af en frembringelse indebærer en konkret helhedsvurdering af hvordan værket opfattes, og der kan med dette for øje sættes spørgsmålstegn ved at fortage værksbedømmelsen som en vurdering af et stort antal linier med binær talkode... *min fremhævelse]. 44 Det må hertil bemærkes, at det netop er programkoden, der udgør edb-programmet og at det derfor nødvendigvis er denne, der må vurderes i forhold til originalitetskravet. At foretage vurderingen på baggrund af værkets fremtrædelsesform på et højere abstraktionsniveau som Thomas anbefaler, vil være direktivstridigt. Det fremgår, som nævnt, af edb-direktivet, at programmets kvalitetsmæssige eller æstetiske værdi ikke skal inddrages i originalitetsvurderingen. Der ses derfor intet grundlag for en tilgang til originalitetsvurderingen som den Thomas Riis anbefaler, og selvsamme forfatter gør sig da også, i forlængelse af ovennævnte citater, til fortaler for netop dobbeltfrembringelseslæren. Udgangspunktet om at koden beskyttes, så længe der består tilstrækkeligt med effektive variationsmuligheder, må anses for korrekt, idet dette er afgørende for om der foreligger en intellektuel indsats. At operere med et bredt 44 Jf. Thomas Riis: Immaterialret og IT, 2001 s. 25-26. 17