Indholdsfortegnelse. Bilag 1: Fremgangsmåde til vurdering af patentansøgninger

Transkript

1

2 Indholdsfortegnelse 1 Indledning Afhandlingens baggrund Målsætning og metode Afgrænsning Software - begreb og virkemåde Ophavsret til edb-programmer Retsgrundlaget Retsbeskyttelsen Edb-programmer som ophavsretlige værker Retsbeskyttelsens genstand - programbegrebet Originalitetskravet Algoritme = ide? Grænseflader, protokoller og programmeringssprog Beskyttelsens varighed, indhold og omfang Nærmere om bearbejdelser Parallel til brugskunst en bemærkning Konklusion vedr. beskyttelsens omfang Edb-programmets forberedende designmateriale Reverse engineering Reverse engineering -teknikker og deres anvendelse Nærmere om interoperabilitet og konkurrence Hvornår er reverse engineering lovligt? Afgrænsningen mellem OPHL 36, stk. 1, nr. 3 og OPHL Konkurrenceretten som sikkerhedsventil Retsbeskyttelsens subjekt en kort bemærkning Patent på software Retsgrundlag Kort om beskyttelsens indhold og varighed Betingelser for opnåelse af patent Hvornår har software teknisk karakter og hvornår ydes et teknisk bidrag? Nærmere om vurderingen af opfindelseshøjde, herunder teknisk bidrag Samfundsøkonomiske overvejelser Software som erhvervshemmelighed Beskyttelsens indhold og objekt Erhvervshemmeligheder og reverse engineering Forholdet til ophavsretten og patentretten Konklusion Litteraturliste English summary...75 Bilag 1: Fremgangsmåde til vurdering af patentansøgninger

3 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,

4 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

5 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

6 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 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

7 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

8 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

9 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

10 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 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

11 har nydt beskyttelse, som litterære værker ud fra en analogislutning til OPHL 1, stk 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 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 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 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 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 , 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 Direktivet blev implementeret ved lov nr af 19. december Jf. bemærkningerne til lovforslag nr. L 74, FT , tillæg A, fremsat den 28. oktober jf. også Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s jf. også bemærkningerne til lovforslag nr. L 74, FT , tillæg A, fremsat den 28. oktober

12 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 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 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 Dette er fast antaget. Se eksempelvis Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s , Mads Bryde Andersen: IT-retten, 2005 s ; Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s samt Jon Bing: Vurderering av opphavsrettslig krenkelse av datamaskinprogrammer et praktisk perspektiv, i NIR 2/1999, s For omtale af retsbeskyttelsen i forhold til den grafiske brugergrænseflade henvises til Mads Bryde Andersen: ITretten, 2005 s , Thomas Riis: Immaterialret & IT, 2001 s , Hanne Bender: EDB rettigheder, 1998 s samt Hanne Bender: Ophavsret til brugergrænseflader look and feel, i NIR 1/1997, s Se betragtning nr. 15 i præamplen til direktiv 2009/24/EF, af 23. april 2009, om retlig beskyttelse af edbprogrammer. 10

13 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, es 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 , tillæg A, fremsat den 28. oktober Lov nr. 378 af 7. juni Loven blev som nævnt ændret ved lov nr 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 Jf. også Mads Bryde Andersen: IT-retten, 2005 s

14 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 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 , 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

15 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 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 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 samt s For nærmere omtale af disse begreber henvises til Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 118 ff. 13

16 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 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 Se vedr. princippet eksempelvis Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s 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

17 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 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 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 Baker v. Selden, 101 U.S. 99 (1879). 15

18 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 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

19 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

20 værksbegreb er da heller ikke betænkeligt, så længe der, i relation til krænkelser, er mulighed for at indskrænke beskyttelsens omfang. 45 Noget andet er, at en detailvurdering af koden i praksis oftest vil være ganske overflødig med henblik på at fastslå om der består tilstrækkeligt med variationsmuligheder. I tilfælde hvor programmet er nogenlunde komplekst, vil det næsten undtagelsesfrit være udtryk for en original intellektuel frembringelse, og dette vil hurtigt kunne fastslås alene på baggrund af mere overordnede observationer af programmets omfang og funktionalitet. Domspraksis Der findes kun en enkelt dansk dom, vedrørende edb-programmer, som inddrager en vurdering af om originalitetskravet er opfyldt. I U H 46 (tipsdommen) var sagens kerne et antal tipssystemer, som var udviklet af tipsbladet, og som ved aftale med virksomheden erhvervssystemer K/S var implementeret i et edb-program. Sagsøgte havde udviklet et program, som understøttede tipning efter samme systemer som tipsbladets. Spørgsmålet var ikke, om selve koden i tipsbladets edb-program var plagieret, men hvorvidt der kunne opnås ophavsret, til selve det tipssystem som programmerne byggede på. Synsskønsmændene udtalte, at de grundlæggende ideer og metoder ved konstruktion af tipssystemer [er] så enkle, at blot med kendskab til disse vil der være stor sandsynlighed for, at to forskellige konstruktører uafhængigt af hinanden kan fremkomme med det samme system [indsat her]. I overensstemmelse hermed (og som udtryk for anvendelse af dobbeltfrembringelseslæren) fastslog Sø- og Handelsretten, såvel som Højesteret, at de grundlæggende ideer og metoder bag tipssystemet var så enkle, at to konstruktører med kendskab hertil med stor sandsynlighed uafhængigt af hinanden kan nå frem til det samme system. Anvendelsen af dobbeltfrembringelseslæren synes dog ikke at være den mest oplagte begrundelse for at nægte ophavsretlig beskyttelse, idet systemer som de nævnte allerede må udelukkes som følge af grundsætningen om den manglende ide-beskyttelse. Selv komplekse systemer, som kan udformes på adskillige måder, beskyttes først når de har taget en konkret form. I den nævnte sag var det ikke krænkelse af implementeringen, men den bagvedliggende ide der var sagens genstand. 45 Samme tilgang ses indenfor brugskunstens verden, hvor der subsumeres bredt, men hvor beskyttelsens omfang er begrænset, jf. eksempelvis U H (Langelinie). 46 Dommen er afsagt på grundlag af retstilstanden inden edb-direktivets implementering i dansk ret, men det må antages at man ville nå samme vurdering på baggrund af den nuværende lov og direktivet. Thomas Riis: Immaterialret og IT, 2001 s. 26, anser derimod dommen som udtryk for en streng originalitetsvurdering og sår dermed tvivl om hvorvidt dommen vil kunne opretholdes i dag, når henses til direktivtekstens lempelige krav til originalitet. Efter min opfattelse er dommen ingenlunde udtryk for noget strengt originalitetskrav. Sagen vedrørte alene helt overordnede principper som må formodes, også i dag, at blive udelukket fra ophavsretlige beskyttelse. 18

21 Algoritme = ide? I den juridiske litteratur der vedrører den retlige beskyttelse af edb-programmer, er anvendelsen af de tekniske begreber ikke altid ganske klar. I forbindelse med omtale af ophavsrettens manglende idebeskyttelse, sættes der, i relation til edb-programmer, ofte lighedstegn mellem algoritme og ide. 47 Herefter fastslås det at algoritmen, grundet princippet om den manglende idebeskyttelse, ikke favnes af ophavsretten, mens kildekoden derimod er beskyttet som litterært værk, jf. OPHL 1, stk. 3. Denne udlægning er korrekt, i det omfang algoritmen alene defineres som den overordnede fremgangsmåde bag programmet, men en sådan definition er udtryk for en begrebsmæssig forsimpling, som er egnet til at skabe uklarhed i relation til beskyttelsens genstand. En algoritme er udtryk for en fremgangsmåde, en opskrift om man vil, som beskriver hvorledes man kan opnå et givent resultat. Dagligdags eksempler på algoritmer er madopskrifter, samlevejledninger mv., men begrebet benyttes normalt om abstrakte matematiske løsningsmodeller, som anvendes i f.eks. edbprogrammer til at opnå en given effekt. Udføres/implementeres algoritmen i de førstnævnte tilfælde, er resultatet et måltid, et reolsystem osv., og algoritmen har så at sige udspillet sin rolle, idet man står tilbage med den fysiske manifestation som er resultatet heraf. I relation til software implementeres en algoritme, som den er beskrevet i det forberedende arbejde, først i kildekoden og først når programmet kompileres opnår den sin endelige form. Det er korrekt, at en algoritme er udtryk for en ide eller en fremgangsmåde til løsning af et problem, men implementeres ideen, er algoritmen samtidig indeholdt i edb-programmets kildekode, og det må derfor anses for misvisende at sætte lighedstegn mellem det juridiske ide-begreb og algoritmen, for herefter at fastslå at algoritmen ikke beskyttes. Algoritmen som den konkret er udtrykt i edb-programmets kildekode er blot udtryk for at ideen nu har taget en form, som er mindre abstrakt, men der er ikke desto mindre stadig tale om en algoritme. Denne vil efter omstændighederne kunne opnå beskyttelse af ophavsretten, da kildekoden beskyttes, jf. OPHL 1, stk. 3. I overensstemmelse med denne udlægning angives i præamplen til edb-direktivet (betragtning nr. 11) at: for at undgå tvivl skal det præciseres, at det kun er et edb-programs udtryksform, der er beskyttet, og at de ideer og principper som ligger til grund for elementerne i et edb-program, herunder dem, der ligger til grund for grænsefladerne, ikke nyder ophavsretlige beskyttelse i henhold til dette direktiv. I overensstemmelse 47 Se eksempelvis Astrid Friis Jørgensen: Ingen reel ophavsretlig beskyttelse af edb-programmer, i Advokaten, Vol. 2, 2006; Thomas Riis: Immaterialret & IT, 2001 s. 31; Peter Schønning: Ophavsretsloven med kommentarer, 2008 s samt Hanne Kirk Deichmann: Programkoncepter ophavsret til tv-formater, 2002 s Se modsat (og korrekt) Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 196 ff. 19

22 med dette ophavsretsprincip er ideer og principper, i det omfang logik, algoritmer og programmeringssprog omfatter disse idéer og principper, ikke beskyttet i henhold til dette direktiv [Fremhævet her]. 48 Det står her klart, at der sondres mellem logik, algoritmer og programmeringssprog på den ene side og ideer og principper på den anden. Det er alene ideen og princippet, der ligger til grund for algoritmerne mv., der ikke kan opnå retsbeskyttelse. Direktivet udelukker således ikke beskyttelse af algoritmer, i det omfang de konkret har taget form som del af kildekoden eller i det forberedende arbejde. 49 Som nævnt, ville dette heller ikke give mening, idet kildekoden netop består af et antal algoritmer Grænseflader, protokoller og programmeringssprog I edb-direktivets præampel (betragtning 11) og art. 1, stk. 2, 2. pkt., nævnes, i forbindelse med grundsætningen om den manglende ide-beskyttelse, begrebet grænseflader. På dette sted fokuseres ikke på brugergrænsefladen, men alene på den tekniske grænseflade. En sådan grænseflade implementeres i et programmeringssprog, men udgør alene en abstraktion af det øvrige program, som har til formål at muliggøre interaktion (skabe interoperabilitet) mellem programmet og andre systemkomponenter. For at opnå interaktion med ophavsmandens program, er det alene nødvendigt at kende til grænsefladespecifikationerne, og selve den underliggende implementering af programmet kan derfor ændres, uden herved at påvirke måden hvorpå der interageres. Ofte offentliggøres information om grænsefladen, mens den underliggende programkode bibeholdes som forretningshemmelighed. Udvikles eksempelvis et program, som kan udføre visse former for kompleks billedbehandling, vil tredjemand kunne udnytte denne funktionalitet ved at interagere med programmets grænseflade, uden at det i den forbindelse er nødvendigt at have kendskab til den bagvedliggende programkode. I andre tilfælde hemmeligholdes viden om grænsefladen, med det formål, at hindre konkurrenter i at udvikle substituerbare produkter, eller for at forbeholde sig markedet for visse komplementærprodukter. 50 I sådanne tilfælde kan det være aktuelt at fortage reverse engineering af ophavsmandens program se hertil afsnit Ordlyden i den autentiske engelske version af direktivet giver grundlag for samme konklusion. 49 Som anført i afsnit 3.2.3, må det dog antages at algoritmer i praksis meget sjældent vil kunne opnå beskyttelse alene på baggrund af deres beskrivelse i det forberedende materiale, idet sådant designarbejde typisk er af overordnet og abstrakt karakter set i forhold til den endelige implementering i kode. 50 Sag T-201/04 (Microsoft-sagen) udsprang som følge af, at Microsoft nægtede Sun adgang til grænseflader og protokoller som muliggjorde visse former for interaktion med Windows PC-operativsystemet. Informationerne var nødvendige for at Suns server-operativsystem, ved navn Solaris, kunne opnå interoperabilitet med Windows som udgjorde (og udgør) en de facto standard på markedet. Licensnægtelsen skyldtes at Microsoft selve udbød komplementærproduktet Windows Server, og derfor ønskede at forbeholde sig eksklusiv adgang til dette afledte marked. Som følge af sagen blev Microsoft dømt for overtrædelse af EF-traktatens art. 82, vedr. misbrug af dominerende stilling (nu TEUF art. 102), og herved tvunget til at udstede licens på den pågældende information. 20

23 Den tekniske grænseflade udgør med andre ord et koblingspunkt mellem edb-programmet og omverdenen, og er en funktion af det øvrige program. Isoleret set vil grænsefladen, som den implementeres i programmets kildekode, derfor i praksis ikke opfylde kravet om originalitet, da nævnte afhængighedsforhold bevirker, at der er begrænset spillerum for programmøren, når koden skal udformes. 51 Som nævnt opfyldes originalitetskravet alene hvor programkoden er udtryk for en selvstændig intellektuel indsats, hvilket ikke er tilfældet, hvor udformningen er dikteret på forhånd. Det følger desuden af idegrundsætningen, at selve den overordnede tekniske specifikation, der ligger til grund for grænsefladerne, ikke beskyttes af ophavsretten. De protokoller, som benyttes af edb-programmet, er endvidere ikke beskyttet af ophavsretten. Ved en protokol forstås regler for kommunikation mellem edb-programmet og andre systemkomponenter. En protokol har ingen sammenhæng med selve programkoden, men kan f.eks. specificere hvorledes data skal formateres, hvordan der etableres forbindelse over netværket og hvilken respons der gives hvis de pågældende data er formateret forkert mv. Visse protokoller har karakter af offentligt tilgængelige standarder for dataudveksling. Eksempler på sådanne er IMAP, POP3 og SMTP, som vedrører modtagelse/afsendelse af mail, og TCP/IP, som definerer regler for datatransmission på internettet. Andre hemmeligholdes derimod for herved at besværliggøre udviklingen af konkurrerende og/eller komplementære produkter, som kan interagere med det pågældende program. I tilfælde hvor information om grænsefladen/protokollerne licenseres til 3. mand, eller i øvrigt gøres tilgængelig for samarbejdspartnere, vil selve den tekst der beskriver disse derimod typisk være beskyttet som litterært værk i medfør af OPHL 1, stk. 1. Teksten vil herved være beskyttet imod kopiering jf. OPHL 2, men det må bemærkes, at ophavsretten ikke forhindrer spredning af teksten, jf. konsumptionsreglen i OPHL 19, stk. 1. Viden om de grænseflader/protokoller, der muliggør interaktion med ophavsmandens program, vil dog kunne betragtes som en erhvervshemmelighed i medfør af MFL 19, og på denne baggrund vil eksempelvis samarbejdspartnere være forhindret i at videregive betroet viden herom. Se nærmere om beskyttelsen af erhvervshemmeligheder i afsnit 5. Som det fremgår af ovenstående, er viden om et programs grænseflader, og de protokoller der anvendes, essentielt for de, som ønsker at udvikle produkter, som kan opnå interoperabilitet med ophavsmandens program. Hvor den nødvendige information ikke offentliggøres, og hvor programmets kildekode ikke er tilgængelig, vil grænsefladen, og de protokoller som programmet bygger på, skulle udledes ved brug af 51 Jf. også Mads Bryde Andersen: IT-retten, 2005 s samt Thomas Riis: Immaterialret og IT, 2001 s

24 reverse engineering. Denne proces nødvendiggør ofte en eksemplarfremstilling, som kan være i strid med ophavsretten se hertil nærmere afsnit Endelig må nævnes, at selve programmeringssproget, som benyttes til udvikling af edb-programmer, ikke vil være omfattet af værksbegrebet, idet disse alene udtrykker overordnede ideer, herunder principper for semantik og syntaks. Selve udviklingsmiljøet, herunder kompileren 52, er derimod beskyttet Beskyttelsens varighed, indhold og omfang Når det er fastslået, at et edb-program omfattes af OPHL 1, stk. 3 (retsfaktum), og derfor favnes af ophavsretten, opstår dernæst spørgsmålet om enerettens nærmere indhold og omfang (retsfølgen). OPHL 2 omhandler ophavsmandens økonomiske rettigheder og svarer indholdsmæssigt til edb-direktivets art. 4, stk. 1. De økonomiske rettigheder suppleres af OPHL 3, som vedrører de ideelle rettigheder. Den ideelle ret giver ophavsmanden krav på at blive navngivet i overensstemmelse med god skik, jf. OPHL 3, stk. 1 (navngivelsesretten), og foreskriver, at værket ikke må ændres eller gøres tilgængeligt for almenheden på en måde eller i en sammenhæng, der er krænkende for ophavsmandens litterære eller kunstneriske anseelse eller egenart, jf. OPHL 3, stk. 2 (respektretten). Det er svært at se, hvornår den ideelle ret skulle få nogen reel betydning i forbindelse med edb-programmer. Værkstypen har ganske enkelt ikke en sådan karakter, at der vil være grundlag for brug i en krænkende sammenhæng. Reglen i OPHL 59, som foreskriver at ophavsretten overgår til arbejdsgiver, bevirker endvidere, at de ansatte programmører intet krav har på at blive navngivet i forbindelse med udgivelsen af programmet. 53 følgende mod de økonomiske rettigheder. På denne baggrund rettes fokus i det Ophavsretten varer i indtil 70 år efter ophavsmandens død, jf. OPHL 63, stk. 1, og samme er gældende i det øvrige EU som følge af direktiv 2006/116/EF om beskyttelsestiden for ophavsret og visse beslægtede rettigheder. Selvom markedet for teknologi, herunder edb-programmer, er præget af hastig udvikling, ses der ikke nogen nævneværdig grund til at forkorte beskyttelsestiden specifikt for denne værkstype. Ophavsretten giver ikke monopol på programmets funktion eller ide, men beskytter alene det konkrete værk, og hertil kommer, at der ikke er tale om en prioritetsret, som hindrer uafhængige dobbeltfrembringelser. Som det er tilfældet med litterære værker af anden art, indebærer retsbeskyttelsen, for ophavsmanden, en eneret til eksemplarfremstilling, og til at gøre værket tilgængeligt for almenheden i oprindelig eller ændret 52 Det program som oversætter fra højniveausprog (kildekode) som skrevet af programmøren til lavniveausprog (objekt- eller bytekode), som kan fortolkes af computeren. Se hertil afsnit Bemærk, at edb-direktivet alene stiller krav om de økonomiske rettighedernes overgang, jf. art. 2, stk. 3, men det følger af forarbejderne til den danske implementeringslov, at overgangen tillige dækker de ideelle rettigheder. Se bemærkningerne til lovforslag nr. L 74, FT , tillæg A, fremsat den 28. oktober

25 skikkelse, i oversættelse, omarbejdelse i anden litteratur- eller kunstart eller i anden teknik, jf. OPHL 2, stk. 1. Det følger herefter af OPHL 2, stk. 2, at retten til eksemplarfremstilling omfatter såvel hele, som delvise fremstillinger af værket, uanset form, og uanset hvorvidt fremstillingen er permanent eller midlertidig. For så vidt angår retten til tilgængeliggørelse for almenheden, præciseres i OPHL 2, stk. 3, at denne omfatter spredning, visning og fremførelse af værket, og i OPHL 2, stk. 4 fremgår videre hvad der forstås ved fremførelse. 54 Det må bemærkes at ophavsretlige krænkelser af edb-programmer, som oftest forudsætter en form for eksemplarfremstilling, og alt afhængigt af hvorledes dette eksemplar anvendes, vil der tillige kunne ske spredning, visning 55 eller fremførelse. Alene spredningsretten kan have selvstændig betydning, i den forstand at ophavsmanden kan hindre parallelimport af fysiske eksemplarer, dvs. eksemplarer af edb-programmet som lagret på DVD er og lignende, fra lande udenfor EØS. Denne ret hindres ikke af reglen i OPHL 19, stk. 1, som alene medfører regional EØS konsumption. Uanset EØS konsumptionen, som hjemlet i OPHL 19, stk. 1, kan ophavsmanden endvidere hindre udlejning og som hovedregel også udlån jf. OPHL 19, stk Som grundlag for en analyse af beskyttelsens bredde tages udgangspunkt i figur 3. I figuren vises et antal scenarier, som involverer brug af et edb-programs kode eller dets forberedende arbejde, og de enkelte scenarier fremtræder på en skala, fra venstre mod højre, i den rækkefølge hvor krænkelse af ophavsretten anses for mest sandsynlig. Skalaen skal alene tages til udtryk for et vejledende udgangspunkt, for den nærmere analyse som gennemgået herunder, og det er klart at eksempelvis placeringen af oversættelse vil afhænge af, hvor stor en del af koden der oversættes og til hvilket sprog, jf. nærmere nedenfor. Figur 3: Krænkelse af edb-programmer 54 Der henvises for en generel gennemgang af ophavsrettens indhold til Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s Se også Mads Bryde Andersen: IT-retten, 2007 s Visningsretten har begrænset relevans for så vidt angår edb-programmer, da den alene kan benyttes til at hindre visning af selve koden for almenheden ved foredrag og lignende. 23

26 Udgangspunktet for krænkelsesvurderingen er edb-programmets kode, da denne er beskyttelsesobjekt i medfør af OPHL 1, stk. 3. Da ophavsretten ikke hindrer dobbeltfrembringelser, frembragt uden kendskab til originalværket, forudsætter krænkelse for det første, at ophavsmanden kan sandsynliggøre den påståede krænkers kendskab til originalværkets kode, og for det andet, at der som følge af dette kendskab kan identificeres beskyttede elementer, som går igen i det produkt, der formodes at krænke. 56 Ved placeringen af de enkelte scenarier i figur 3 er taget højde for disse betingelser. 57 Da sandsynligheden for dobbeltfrembringelser af den konkrete kode er minimal, vil førstnævnte betingelse primært kunne give anledning til vanskeligheder hvor der foretages bearbejdelser af koden, og hvor der derfor består en løsere forbindelse til originalværket. Det er evident at piratkopiering 58 kan hindres med hjemmel i ophavsretten, og sådan eksemplarfremstilling giver derfor ikke anledning til nærmere overvejelser, om hvorvidt der foreligger en krænkelse. De retlige problemstillinger, der har interesse i denne sammenhæng, vedrører i høj grad bevissikring og sanktion, herunder udmåling af erstatning. Denne form for krænkelse undergives derfor ikke nærmere behandling. Hertil kommer det interessante spørgsmål, om de der på internettet linker til ophavsretligt beskyttet materiale, som ulovligt gøres tilgængeligt af andre, kan blive erkendt skyldige for ophavsretskrænkelser og/eller medvirken hertil. 59 I nær forbindelse hermed opstår endvidere spørgsmålet, om de der stiller en hjemmeside til rådighed, hvor brugerne selvstændigt kan linke til 56 Det må i tilknytning hertil bemærkes, at der er en nær sammenhæng mellem beviset for kendskab hhv. lighed i koden. Stor lighed i koden gør det usandsynligt at den påståede krænker ikke har haft kendskab til originalkoden. Sådan lighed vil derfor medføre, at bevisbyrden vendes, således at den påståede krænker, må bevise at der på intet tidspunkt har været kendskab til koden dette vil ofte være umuligt. Selvom der i ophavsretten alene stilles et subjektivt nyhedskrav, vil krænkelsesvurderingen derfor ofte reelt være objektiv. Hvor det uden videre kan sandsynliggøres at den påståede krænker, har haft kendskab til koden, f.eks. som følge af et samarbejdsforhold, kan det endvidere ikke udelukkes, at domstolene vil slække på kravet til lighed, og at der modsat vil kræves stor lighed hvor sådant kendskab ikke klart kan påvises. Dette fordi manglende kendskab vil tale for, at der er sket en uafhængig dobbeltfrembringelse. 57 Der kan argumenteres for at plagiering af kode bør betragtes på lige fod med piratkopiering, hvilket også vil være tilfældet hvor hele koden kopieres direkte. Hvor der alene foretages delvis plagiering vil der dog være større afstand til originalværket end ved decideret piratkopiering, og det kan ikke udelukkes at den kode der plagieres er at betragte som uoriginal. For at illustrere denne forskel er plagierings-scenariet placeret til højre for piratkopiering. 58 Herved forstås tilfælde hvor der foretages en identisk kopi af hele ophavsmandens produkt. Foruden krænkelse af programkoden indebærer sådan kopiering per definition også en krænkelse af eventuelle dataelementer (grafik mv.) som måtte være ophavsretlig beskyttet i medfør af OPHL 1, stk Se vedr. denne problemstilling Henrik Udsen & Jens Schovsbo: Ophavsrettens missing link?, i NIR 1/2006, s Forfatterne når den, efter min opfattelse, korrekte konklusion, at linking ikke udgør eksemplarfremstilling eller tilgængeliggørelse for almenheden i strid med ophavsretten, men at der vil kunne være tale om medvirkeansvar hvor der linkes til beskyttet materiale. Hertil konkluderes at visse typer links vil kunne være i strid med MFL. Ansvar for medvirken må forudsætte, at der bevidst linkes til ulovligt materiale, eller at der i øvrigt er klare indicer for at hjemmesiden alene har til formål at gøre sådant materiale tilgængeligt for almenheden. I modsat fald ville eksempelvis virksomheden Google (hvis søgemaskine automatisk indeksere hjemmesider) kunne findes ansvarlig for medvirken, idet visse søgeresultater indeholder links til ophavsretligt beskyttet materiale. 24

27 beskyttet materiale, kan anses for at krænke ophavsretten eller medvirke til krænkelser. 60 Det må derimod formodes, at de der udvikler en given fildelingsteknologi (f.eks. peer to peer), eller et edb-program som benytter en sådan teknologi, ikke herved vil kunne dømmes for ophavsretlige krænkelser eller medvirken hertil, da sådanne teknologier har adskillige anvendelsesmuligheder. De nævnte problemstillinger falder udenfor emneområdet for denne afhandling. I tilfælde hvor ophavsretten påstås krænket, og hvor der ikke er tale om decideret piratkopiering eller fuldstændigt plagiat, har originalitetsvurderingen fornyet relevans, og tjener således ikke kun til at afgøre, om edb-programmet som helhed er ophavsretligt beskyttet. Hvor der kun sker delvis eksemplarfremstilling, må det vurderes, om de kodesegmenter der kopieres har en sådan karakter, at de selvstændigt kan anses for originale i ophavsretlig forstand. Er dette ikke tilfældet, vil der være adgang til fri benyttelse. Hvor et beskyttet værk bearbejdes, må det endvidere afgøres, om bearbejdelsen har en sådan sammenhæng med originalværket, at den strider mod eneretten til tilgængeliggørelse i ændret skikkelse, jf. OPHL 2, stk. 1, eller om ligheden alene beror på brugen af ubeskyttede ideer. Det er klart, at direkte plagiering af ophavsmandens kode vil udgøre en krænkelse, såfremt den kode der efterlignes i øvrigt er ophavsretlig beskyttet. Med udgangspunkt i figur 3 samler interessen sig således om at fastlægge beskyttelsens bredde, i de tilfælde hvor der ikke kan genfindes kode, som er kopieret direkte fra ophavsmandens program, men hvor programmet bearbejdes i kraft af oversættelse til et andet programmeringssprog eller anden bearbejdelse, hvor der skabes et selvstændigt program med inspiration fra strukturen og algoritmerne i ophavsmandens program. I afsnit rettes fokus derfor mod bearbejdelserne, men forinden må påpeges nogle forhold af generel betydning. Er koden implementeret, i eksempelvis konkurrerende produkter, kan det være svært for ophavsmanden at identificere (opdage) krænkelsen, såfremt det krænkende produkt udgives som closed source. Det vil derfor ofte være lighed i den grafiske brugergrænseflade, eller programmets funktion og virkemåde, der henleder ophavsmandens opmærksomhed på en mulig krænkelse. Sådan identitet mellem edbprogrammer er dog ikke tilstrækkelig til at statuere krænkelse af koden. To programmer som fremstår 60 At internetudbyderen ikke ifalder ansvar følger af e-handelsdirektivets (2000/31/EF) hvor det, i art. 12 og 13, fastslås at automatisk, mellemliggende og kortvarig oplagring af transmitteret information ikke er ansvarspådragende. Internetudbyderen er dog ikke på denne baggrund immun overfor fogedforbud, idet der ikke desto mindre sker en eksemplarfremstilling, som ikke favnes af undtagelsen i OPHL 11, grundet reglen om lovligt forlæg i OPHL 11, stk. 3. I den danske sag vedr. hjemmesiden thepiratebay.org afsagde fogedretten således en kendelse (senere stadfæstet af Sø- og Handelsretten og Højesteret), der pålagde teleudbyderen Telenor, at lukke for adgangen til hjemmesiden, idet det var påvist at siden medvirkede til deling af ulovligt materiale. Det kan diskuteres om en retstilstand hvorefter internetudbyderen, som alene agerer mellemmand, kan tvinges til at lukke for adgangen til en hjemmeside, er hensigtsmæssig. Som Telenors juridiske chef har udtalt i pressen har teleselskaberne ikke noget incitament til at bruge ressourcer på en sag, der står mellem rettighedshavere og folk, som anklage s for at krænke ophavsretten, og det kan derfor frygtes at retssikkerheden vil lide skade. Selve blokeringen af hjemmesiden har endvidere kun symbolsk betydning, idet der alene kræves DNS-spærring en teknik som kan omgås ved meget simple tiltag. 25

28 identisk, både grafisk og funktionsmæssigt, kan således godt bygge på vidt forskellige implementeringer i kode. Lighed i brugergrænsefladen vil derimod, efter omstændighederne, kunne danne selvstændigt grundlag for en overtrædelse af ophavsretten (hvor beskyttede grafikelementer og billeder går igen) eller MFL 1 (hvor der er stor lighed mellem skærmbilledernes opbygning, struktur, farvebrug mv.). Ønskes større sikkerhed for om der reelt er tale om en krænkelse af programkoden, kan ophavsmanden forsøge at udsætte det program, der formodes at krænke, for reverse engineering. Herved risikerer han imidlertid selv at, krænke ophavsretten, såfremt programmet viser sig at indeholde kode der opfylder originalitetskravet. Det må derfor generelt anbefales, at ophavsmanden afholder sig fra sådan analyse. Retstvister, om hvorvidt et edb-program involverer ulovlig brug af kode, vil typisk blive aktualiseret hvor den påståede krænker, har adgang til kildekoden fra et tidligere ansættelsesforhold, som følge af et samarbejde med ophavsmanden, eller fordi koden udgives som open source, og på denne baggrund udnytter muligheden for, at videreudvikle programmet, eller implementere dele heraf i egne produkter. 61 Man vil derimod kun undtagelsesvist kunne forestille sig tilfælde hvor parter, som ikke har adgang til kildekoden, vil ty til reverse enginerering for at opnå viden om koden, idet der som nævnt i afsnit , ikke er økonomisk incitament hertil. Hertil må bemærkes, at den viden der opnås ved brug af reverse engineering kun sjældent vil give så detaljeret information, at brugen heraf vil give grundlag for at identificere en ophavsretlig krænkelse, som følge af lighed programmerne imellem. Noget andet er, at selve reverse engineering -processen kan være i strid med ophavsretten, jf. nærmere afsnit Ønsker en udvikler at sikre sig negativt bevis for, at der som følge af reverse engineering, foretaget med hjemmel i OPHL 36, stk. 1, nr. 3 eller 37, ikke er sket plagiering af ophavsretligt beskyttet materiale, kan det anbefales at benytte en såkaldt clean room -procedure. Kort fortalt går denne ud på, at isolere de personer, der analyserer et edb-program fra holdet af udviklere, og få en uafhængig person til at attestere, at ophavsmandens program ikke er at finde på computere i udviklingsområdet. De der foretager selve analysen udarbejder herefter en specifikation med de informationer, der skal benyttes til at implementere f.eks. interoperabilitets-funktionalitet i et selvstændigt udviklet program. En uafhængig tredjepart, eksempelvis en advokat, gennemser endelig specifikationen for at sikre, at der ikke udleveres information til udviklerne, som kan tænkes at krænke ophavsretten. Herved vil der i en eventuel retssag kunne bevises, 61 Benyttes eller spredes viden, opnået via et ansættelses- eller samarbejdsforhold, vil forholdet tillige kunne omfattes af markedsføringslovens regler om beskyttelse af erhvervshemmeligheder, jf. afsnit 5. 26

29 at kravet om subjektiv nyhed er opfyldt, idet udviklerne ikke kendte til implementeringsdetaljer i ophavsmandens program Nærmere om bearbejdelser Som det fremgår af OPHL 2, stk. 1 favner eneretten, foruden den slaviske kopiering, også værket i ændret skikkelse, i oversættelse, omarbejdelse i anden litteratur- eller kunstart eller i anden teknik. Der kan derfor ikke være tvivl om at edb-programmer, som andre værker, er beskyttet mod andet og mere end slavisk kopiering, og retspraksis i udlandet (se nedenfor) antyder, at denne beskyttelse ikke alene er teoretisk. 63 Edb-programmer er typisk så komplekse, at originalitet kan genfindes på mere overordnet niveau i kraft af udvælgelsen/sammensætningen af en flerhed af elementer, jf. nærmere nedenfor. 64 Afgørende er derfor, at trække grænsen mellem tilfælde, hvor den ændrede skikkelse adskiller sig så markant fra originalværket, at brugen heraf må karakteriseres som fri benyttelse, jf. OPHL 4, stk. 2, og de tilfælde hvor der er tale om en bearbejdelse af originalværket, som bevirker at forholdet favnes af OPHL 4, stk. 1, og derfor kræver ophavsmandens samtykke. Hvornår der sker overgang fra fri benyttelse, jf. OPHL 4, stk. 2, til bearbejdelse vil generelt bero på en konkret sagkyndig vurdering af identitetsoplevelsen mellem ophavsmandens værk og den påståede krænkers produkt. 65 Denne vurdering kan være svær at foretage ved andre ophavsretlige værker, og kompliceres yderligere hvor der er tale om edb-programmer. Dette skyldes edb-programmers omfang og kompleksitet, men også at det ikke, som ved traditionelle litterære, er muligt at foretage en krænkelsesvurdering baseret på sammenfald i overfladiske fænomener så som den sproglige betydning, plottet, moralen mv. Hertil kommer, at programmeringssprogs semantik og syntaks kan være så afvigende, at det kan være svært at identificere originalværket, når det først er bearbejdet i et andet sprog. Det er heller ikke muligt, som i forbindelse med eksempelvis brugskunst, at påvise æstetisk lighed i relation til koden. Udstrækkes den retlige beskyttelse til at gælde andet og mere end den konkrete programkode - programmets litterære udtryk vil beskyttelsen derfor nødvendigvis favne kodens struktur eller dens 62 Se nærmere om proceduren i Jon Bing: Vurderering av opphavsrettslig krenkelse av datamaskinprogrammer et praktisk perspektiv, i NIR 2/1999, s Se modsat Astrid Friis Jørgensen: Ingen reel ophavsretlige beskyttelse af edb-programmer, i Advokaten, nr. 2, 2006., hvor det udtales at ophavsretten reelt alene beskytter mod slavisk kopiering. Dette kan ikke tiltrædes, idet det, som anført nedenfor, vil være muligt, at identificere krænkelser baseret på ikke-litterær lighed. Samme udtrykkes af Peter Lind Nielsen i en kommentar til nævnte artikel, se Peter Lind Nielsen: Ingen reel beskyttelse af edbprogrammer?, i Advokaten, nr. 4, Se også Thomas Riis: Immaterialret & IT, 2001 s ; Mads Bryde Andersen: IT-retten, 2005 s. 364; Anders Mediaas Wagle & Magnus Ødegaard jr.: Opphavsrett i en digital verden, 1997 s ; Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 199 og s. 214, samt Peter Lind Nielsen: Ingen reel beskyttelse af edbprogrammer?, i Advokaten, nr. 4, At strukturen i et værk kan opnå beskyttelse anføres endvidere af Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s Jf. også Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s

30 algoritmer på mere overordnet niveau. Spørgsmålet er derfor om ophavsretten opstiller et værn på dette abstraktionsniveau, eller om sådanne fænomener altid må anses for ubeskyttede ideer? Henset til edb-programmers kompleksitet må dette spørgsmål besvares bekræftende. Et edb-program, skrevet i et objektorienteret programmeringssprog, vil være opbygget af et antal klasser, hvor imellem der består en funktionel forbindelse. De enkelte klasser vil hver især indeholde et antal metoder, hvorimellem der ligeledes består funktionelle bånd, som kan aktiveres for at udføre en given funktion. Her ud over vil disse klasser og metoder typisk være inddelt i et eller flere såkaldte namespaces (kategorier), og et antal binære filer. Nævnte struktur, såvel som den trinvise fremgangsmåde til løsning af et problem (algoritmen), udarbejdes af programmøren ud fra blandt andet overvejelser om effektivitet, vedligeholdelse og fleksibilitet, og grundet det kvantitative omfang af moderne edb-programmer, må det vurderes, at selve sammenstillingen af instruktioner og programmets struktur, efter omstændighederne vil kunne betragtes som original. På samme vis som rækkefølgen af ord, formuleringer, og den mening/handling der udtrykkes i en bog, tilsiges beskyttelse, i kraft af ophavsmandens ret til at hindre oversættelser og andre bearbejdelser (f.eks. filmatisering), vil bearbejdelse af et edb-program derfor kunne hindres, såfremt der ud fra en helhedsvurdering kan genfindes tilstrækkelig lighed i rækkefølgen af instruktioner og programmets struktur. På den ene side står det klart, at en helt overordnet algoritme, eksempelvis hent tekst fra database -> formater tekst så den er udskriftsvenlig -> krypter og , er udtryk for en ubeskyttet ide, men det er uomtvisteligt at selvsamme algoritme, som oftest vil være beskyttet, som den konkret er implementeret i kode. Imellem disse yderpoler, det meget abstrakte og det meget konkrete, findes et antal abstraktionsniveauer, og på et givent niveau vil der være tale om en beskyttet manifestation af ideer. Generelt gælder at desto højere abstraktionsniveau, desto færre effektive variationsmuligheder vil der bestå i forhold til løsningen af et givent problem. Det er ligeledes klart, at den måde hvorpå et edbprograms kode er organiseret/struktureret, som udgangspunkt ikke er beskyttet isoleret set, men genfindes identisk struktur taget fra et komplekst program, vil dette kunne underbygge, at der er sket en krænkelse. Dobbeltfrembringelseslæren er her yderst relevant som rettesnor, når det skal afgøres om strukturen og sammenstillingen af algoritmer er beskyttet, idet afgørende må være en vurdering af sandsynligheden for uafhængige dobbeltfrembringelser. Hvad angår oversættelser, må bemærkes, at sandsynligheden for identifikation af krænkelser i høj grad vil bero på, om det sprog der oversættes til, baserer sig på samme principper, semantik og syntaks, som det sprog ophavsmandens program er skrevet i. Som nævnt er det ikke muligt at genfinde lighed i den sproglige 28

31 mening og handling på samme vis som i et rigtigt sprog, og oversættes et edb-program til et fundamentalt anderledes sprog vil dette dårligt kunne betragtes som en bearbejdelse. Oversættelser er kendetegnet ved, at ophavsmandens kode går igen instruktion for instruktion, og at hele programstrukturen kan genfindes. Hentes alene inspiration fra visse dele af strukturen og visse algoritmer, og foretages der tilmed ændringer med henblik på at optimere, fejlrette mv., vil den resulterende kode, som illustreret i figur 3, selvsagt adskille sig mere fra originalværket end det er tilfældet ved en direkte oversættelse, og sandsynligheden for at genfinde beskyttede elementer, der krænker ophavsretten, være tilsvarende mindre. Den retspraksis, der har udviklet sig i relation til brugskunst er egnet til at illustrere, at sammensætningen af en flerhed af, isoleret set ubeskyttede, enkeltelementer kan være original, jf. eksempelvis U H (Langelinie) samt U SH (Eva Trio). Samme gør sig gældende i relation til de litterære værker omfattet af OPHL 1, stk. 1. Skrives en bog baseret på tilsvarende historie, men med anden tekst, vil dette som udgangspunkt ikke udgøre en krænkelse af eneretten efter OPHL 2, men derimod være fri benyttelse efter OPHL 4, stk. 2. Den overordnede handling, plottet, bogens morale, personkarakteristikker, tidsepoke mv. er ikke, isoleret set, at anse for ophavsretlige værker, men derimod for ideer som er public domain, jf. idegrundsætningen. En flerhed af sådanne, isoleret set ubeskyttede enkeltelementer, kan dog formentlig udgøre en original sammenstilling, og overtages denne sammenstilling, vil det kunne betragtes som en ulovlig bearbejdelse, selv i tilfælde hvor den litterære udformning, teksten, adskiller sig totalt. 66 Der findes ingen danske sager hvor en sådan bearbejdelse af litterære værker er fundet ulovlig, men i en tysk sag 67, som vedrørte romanen dr. Zhivago, blev en forsættelse af værket anset for værende en ulovlig bearbejdelse. Også TV-programkoncepter må formodes at kunne opnå beskyttelse, såfremt der er tale om en kompleks sammenstilling af eksempelvis regler for quiz, værtens påklædning, publikums rolle, måden at stille spørgsmål på, studiets udseende, brug af lys og lyd mv. 68 Selvom en enkelt algoritme eller en lille del af strukturen ikke er beskyttet, kan det således ikke udelukkes at den konkrete sammenstilling af et stort antal algoritmer og instruktioner, samt kodens struktur, ud fra en helhedsvurdering, vil kunne betragtes som original. Af samme årsag vil der kunne forelægge en krænkelse selvom der ikke kan genfindes lighed i kodens konkrete udtryk. Denne vurdering underbygges af retspraksis i udlandet, jf. umiddelbart nedenfor. Man må dog være påpasselig med ikke at beskytte i et omfang, som 66 Jf. Hanne Kirk Deichmann: Variationsværker, i NIR 2/2004, s Afgørelse fra Bundesgerichtshof af , sag nr. I ZR 65/96 (OLG Karlsrhue). 68 Se hertil den omfattende analyse i Hanne Kirk Deichmann: Programkoncepter - ophavsret til tv-formater, I U /2 Ø (Millionærsagen) blev det fastslået at et programkoncept er en samling idéer og principper, som isoleret set ikke ydes ophavsretlig beskyttelse, men herved udelukkes ikke at der potentielt vil kunne opnås beskyttelse af et stort antal ideer og principper hvis sammenstilling er tilstrækkelig original. 29

32 får konkurrence- og innovationsskadelige effekter til følge. Derfor bør kræves stærke indicier for, at den påståede krænker reelt har benyttet ophavsmandens værk, som grundlag for sit eget program. Anvendelse af idegrundsætningen og kravet om intellektuel indsats, herunder dobbeltfrembringelseslæren, må her danne grundlag for alene at tilsige en snæver efterligningsbeskyttelse på højere abstraktionsniveau. Kan der i den påståede krænkers programkode findes adskillige tilfælde, hvor elementer (variabler, metoder, klasser mv.) i koden er navngivet, som i ophavsmandens program, vil dette være en stærk indikation på, at der ikke er sket fri benyttelse i medfør af OPHL 4, stk. 2, da et sådan sammenfald må forudsætte kendskab til ophavsmandens kode. Sådan lighed er dog hverken en nødvendig eller en tilstrækkelig betingelse for at påvise en krænkelse. Den blotte omstændighed at elementer som de nævnte rokeres rundt og omdøbes, kan ikke frafriste den påståede krænkers produkt sin karakter af bearbejdelse, idet lighed vil kunne identificeres på baggrund af kodens struktur, og de anvendte algoritmer. Var dette tilfældet ville beskyttelsen mod bearbejdelser være uden reel betydning. Det er endvidere essentielt at bemærke, at sådanne elementer typisk ikke vil være selvstændigt beskyttet i medfør af ophavsretten, og identifikation heraf kan derfor ikke danne tilstrækkeligt bevis for, at der er sket en krænkelse. Hertil må, som nævnt, kunne identificeres stor lighed i struktur og algoritmer. I tilknytning hertil må imidlertid nævnes en særlig bivirkning af forbuddet mod midlertidig eksemplarfremstilling i OPHL 2, som bevirker, at der potentielt vil kunne bevises en krænkelse, selvom der ikke kan genfindes beskyttede elementer i den påståede krænkers program. Er ophavsmandes program udgivet som closed-source, og har den påståede krænker ikke haft lovlig adgang til kildekoden, vil stor lighed i navngivningen af programelementer indikere, at der er foretaget reverse engineering 69 af ophavsmandens program. Er sådan analyse ikke foretaget ved hjælp af teknikker, som omfattes af undtagelsen i OPHL 36, stk. 1, nr. 3, og opfyldes betingelserne i OPHL 37 ikke, vil der være tale om en ulovlig eksemplarfremstilling. Det er således reelt tilstrækkeligt at påvise, at den påståede krænker, har haft kendskab til koden, uagtet at dette kendskab ikke er benyttet til at efterligne. Principielt må dette anses for betænkeligt, idet ophavsretten netop er en efterligningsbeskyttelse. Det er derfor værd at overveje, om det nuværende regelsæt er hensigtsmæssigt eller om det bør revideres. Man kunne eventuelt lade edb-programmer omfatte af en regel i stil med OPHL 11a. Hvor der foretages dekompilering eller anden reverse engineering, som nødvendiggør en midlertidig og teknisk betinget eksemplarfremstilling, vil dette herefter være lovligt, uanset om formålet er at opnå interoperabilitet eller ej, men benyttes den opnåede viden til at plagiere ophavsmandens produkt, vil der hermed ske en permanent eksemplarfremstilling i strid med OPHL 2, stk Hermed sidestilles edb-programmer med andre teknologiske produkter, hvor det ikke er ulovligt at opnå 69 Se hertil nærmere afsnit

33 viden ved at skille produktet ad og analysere det, men hvor anvendelsen af den opnåede viden, til f.eks. at udvikle konkurrerende produkter, vil kunne hindres, såfremt produktet er omfattet af et eller flere patenter. Ulempen ved en sådan tilgang er, at ophavsmanden vil have sværere ved, at håndhæve ophavsretten i forhold til bearbejdelser. Da strukturen og algoritmerne i et edb-program potentielt vil kunne opnå beskyttelse, såfremt der fokuseres på et tilstrækkeligt stort udsnit af koden, kan det endvidere ikke udelukkes at forberedende arbejde af meget konkret karakter vil være beskyttet mod realisering. Sådant forberedende arbejde vil dog i praksis udgøre en meget abstrakt og forsimplet repræsentation af den endelige kode, og vil som hovedregel ikke være beskyttet mod realisering. 70 Denne problemstilling behandles særskilt i afsnit Retspraksis vedr. bearbejdelse af edb-programmer Der foreligger i Danmark ingen retspraksis i relation til bearbejdelse af edb-programmer, men fra norsk ret kan nævnes MOCS-dommen 71, hvor retten gjorde klart at også meningsindholdet, forstået som programmets algoritmer, uanset syntaktiske forskelle, kunne være beskyttet. Retten anførte at: Leksikalsk analyse av programmer etablerer programmets symboler, men leksikalsk likhet kan ikke være en forutsetning for å avgjøre plagiat. Rene substitueringer av tegn med andre tegn kan ikke hindre at et program blir ansett som plagiat av et annet. Heller ikke uvesentlige endringer av datatyper og lignende. Det avgjørende må være en syntaktisk-semantisk likhet mellom de to programmer som sammenlignes. Er imidlertid meningsinnholdet tilstrekkelig likt, vurdert setning for setning, må plagiat kunne konstateres, selv med store syntaktiske forskjeller. [min fremhævelse] Retten nåede herefter den konklusion at lighed i navngivningen af kodens elementer, lighed i kodens struktur og lighed i algoritmerne ikke alene kunne bero på en tilfældighed, og at der var tale om en ulovlig bearbejdelse af ophavsmandens program. Selvom denne retstilstand ikke uden videre kan overføres til Danmark, ses der, som nævnt ovenfor, intet grundlag for at dansk ret skulle adskille sig på dette punkt ved alene at beskytte mod direkte plagiering. Traditionelt tillægges retstilstanden i andre nordiske lande da også særlig vægt, grundet store ligheder i de nordiske landes lovgivning. 72 Også i amerikansk ret har ikke-litterær kopiering været genstand for en række sager. Den ofte refererede sag, Computer Associates. v. Altai 73, har i den forbindelse skabt præcedens for de sager, som indtil nu har 70 Se modsat Michael Plogell: Immaterialrättsliga aspekter på datorprogram, Juristförlaget, 1996 s Borgarting lagmannsretts (landsret) dom af , RG MOCS-dommen er refereret i NIR 2/1999, s Jf. Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s Sag 982 F.2d 693 (2d Cir. 1992). 31

34 beskæftiget sig med problemstillingen. 74 Retten udviklede i sagen en test, som skulle benyttes til at afgøre om der forelå en ophavsretskrænkelse. Den såkaldte abstraction-filtration-comparison -test indebærer en analyse i 3 faser. For det første skal det program, der påstås krænket, opdeles i forskellige abstraktionsniveauer. Laveste niveau er programmets kildekode, og retten må herfra gradvist bevæge sig op på mere abstrakt plan, indtil der nås et niveau, hvor der ikke længere er tale om konkret form, men alene ubeskyttede ideer. For det andet skal der, på hvert af de beskyttede niveauer, foretages en analyse med henblik på at filtrere ubeskyttede elementer fra, som er dikteret af effektivitet, eksterne faktorer eller som er udtryk for public domain. Elementer som dikteres af tekniske specifikationer, interoperabilitetskrav, lovkrav, tekniske standarder, kundekrav, almene programmeringsmetoder mv. levner ikke programmørerne et kreativt spillerum, og kan derfor ikke betragtes som originale. Sådanne elementer, hvor ophavsmanden ikke har haft reelle valgmuligheder i forhold til implementeringen, er som nævnt også undtaget fra den ophavsretlige beskyttelsessfære i Danmark, idet de ikke er udtryk for en selvstændig intellektuel indsats som påkrævet ifølge edb-direktivet. Det er i den forbindelse essentielt at bemærke, at elementer som de nævnte oftest vil blive filtreret fra på et højt abstraktionsniveau, idet der sjældent ses tilfælde hvor sådanne krav dikteres på kodeniveau. 75 For det tredje indebærer testen, at de strukturelle elementer, der står tilbage efter endt filtrering, må betragtes som originale, og derfor skal disse sammenlignes med koden i det program, der påstås at krænke. Metoden kan alene betragtes som en overordnet fremgangsmåde, der gør det klart, at et programs struktur og algoritmer potentielt kan være beskyttet. Metoden er derfor illustrativ for amerikansk opfattelse af beskyttelsen mod bearbejdelser, men den levner i praksis betydelige vanskeligheder med rent faktisk at sætte grænsen mellem blotte ideer og beskyttede elementer. Hvilke udsnit af koden skal der fokuseres på i sammenligningen? Hvor mange effektive variationsmuligheder skal der bestå, for at koden på et givent abstraktionsniveau kan betragtes som original? Hvordan skal man reelt identificere de elementer i koden, der er dikteret af eksterne faktorer? Disse spørgsmål kan ikke besvares med nogenlunde sikkerhed, og der kan ikke opstilles en konkret fremgangsmåde som kan benyttes. Efter min opfattelse kan testen ikke betragtes som et reelt redskab til, at løse de problemer, der opstår ved sammenligning af edbprogrammer, og følges fremgangsmåden slavisk kan det give uhensigtsmæssige resultater. Testen har 74 Jf. også Stanley Ley: The Copyright Protection of Computer Software in the United Kingdom, 2000 s. 30 og Thomas Riis: Immaterialret & IT, 2001 s. 36. Sagen vedrørte et tilfælde hvor alene et programs funktionalitet og grænseflader var efterlignet uden at der kunne genfindes kode som direkte var kopieret fra ophavsmandens program. Retten kom frem til at dette ikke indebar en krænkelse, og samme resultat vil uomtvisteligt blive nået i dansk ret som følge af idegrundsætningen. 75 Se nærmere afsnit , og Mads Bryde Andersen: IT-retten, 2005 s

35 således været skarpt kritiseret i USA for, at indsnævre beskyttelsen for vidt. 76 Den primære kritik skyldes, at man ved at opdele et program og fjerne individuelle elementer, som ikke er beskyttet, før man foretager sammenligningen, potentielt vil overse eller mindske muligheden for at identificere ligheder i programmets struktur og algoritmer, som efter omstændighederne vil kunne være original. Som anført ovenfor må det forventes, at der i dansk ret vil kunne statueres krænkelse, hvis det ud fra en helhedsvurdering må konkluderes, at der er tale om en bearbejdelse, dvs. et eksemplar af originalværket blot i anden form Parallel til brugskunst en bemærkning Der er til tider blevet trukket paralleller til brugskunst i den overbevisning, at der herved kunne opnås pejlemærker for omfanget af den retsbeskyttelse, der tilsiges edb-programmer. 77 Der har således været argumenteret for, at edb-programmer minder om brugskunst, idet programmeringssprog opsætter rammer for udtryksfriheden, der bevirker at det konkrete udtryk i høj grad er dikteret af den ønskede funktion og eksterne faktorer. Samspillet mellem funktion og udtryk skulle derfor tale for alene, at beskytte snævert af hensyn til konkurrencen på markedet. Denne sammenligning må dog anses for misvisende. Det er rigtigt, at der består en sammenhæng mellem funktion og udtryk, men denne giver først anledning til at indsnævre beskyttelsen, i relation til bearbejdelser, hvor lighed kan identificeres på et højt abstraktionsniveau, i form af overordnede algoritmer og struktur. For så vidt angår edb-programmer, er der ikke samme nære sammenhæng mellem funktion og udtryk, som det er tilfældet for brugskunsten. 78 Den funktion, som brugsgenstande skal opfylde, dikterer ofte visse dele af selve den konkrete udformning, ligesom der kan være forbrugerkrav og trends, som stiller specifikke krav til det æstetiske udtryk. En stol skal eksempelvis have 4 ben, og valget af materialer afhænger af den aktuelle mode, og de trends der er gældende i samfundet. I modsætning til brugskunst kan et edbprograms funktion typisk opnås på baggrund af et, næsten ubegrænset, antal forskellige implementeringer. De krav, der skal honoreres som følge af standarder, så som protokoller for dataudveksling, retter sig endvidere mod selve funktionen og ikke den specifikke implementering i kode, ligesom forbrugerkrav mv. vil rette sig mod den grafiske brugergrænseflade og programmets funktion. Edb-programmer har derfor større lighedstræk med de traditionelle litterære værker, om end det er klart, at der på et fåtal af linjer kan udtrykkes større individualitet i et normalt sprog. Det vil derfor være problematisk at beskytte små udsnit 76 Jf. Stanley Ley: The Copyright Protection of Computer Software in the United Kingdom, 2000 s Se eksempelvis Anders Mediaas Wagle & Magnus Ødegaard jr.: Opphavsrett i en digital verden, 1997 s og Per Håkon Schmidt: Teknologi og Immaterialret, 1989 s. 209 ff. 78 Jf. også Mads Bryde Andersen: IT-retten, 2007 s

36 af koden, men et edb-program består typisk af mange tusinder linjer kode og en kompleks struktur, og anskues et større udsnit af programmet, vil der være rig mulighed for at identificere en intellektuel indsats Konklusion vedr. beskyttelsens omfang Sammenfattende må vurderes at ophavsretten har sin primære relevans som værn mod decideret piratkopiering. I de øvrige scenarier, som skitseret i figur 3, vil de problemer, der er forbundet med at identificere krænkelser, og føre bevis herfor, medføre, at beskyttelsens reelle betydning aftager som vi bevæger os fra venstre mod højre. Selv i tilfælde hvor der foretages slavisk plagiering af kode, vil det, som nævnt ovenfor, ofte være svært at identificere krænkelsen, idet edb-programmer typisk udgives som closed source. Er der tale om en bearbejdelse af ophavsmandens kode, vil det faktum at ophavsretten ikke hindrer dobbeltfrembringelser, som er fremkommet uafhængigt af ophavsmandens værk, sammenholdt med den meget snævre beskyttelse mod bearbejdelser (som følge af idegrundsætningen), medføre at bearbejdelsen ofte må betragtes som fri benyttelse i medfør af OPHL 4, stk. 2. Dette med undtagelse af de tilfælde, hvor koden oversættes direkte til et andet programmeringssprog, og hvor der derfor kan genfindes identisk struktur og tilsvarende sekvenser af instruktioner og metodekald, som tilsammen udgør en original sammenstilling Edb-programmets forberedende designmateriale Edb-programmer udvikles oftest på baggrund af forberedende materiale, som nærmere fastlægger rammerne for programmørernes arbejde. Sådant materiale kan bestå af beskrivelser og grafiske illustrationer over programmets dataflow, kodens struktur, forholdet til andre systemkomponenter (hardware såvel som software) samt kravspecifikationer og overordnede beskrivelser af visse algoritmer (psedukode) mv. 79 Hertil kommer designmateriale i relation til den grafiske brugergrænseflade. Retsbeskyttelsen af det forberedende materiale vil primært have betydning, i tilfælde hvor materialet gøres tilgængeligt for samarbejdspartnere, hvortil dele af udviklingsarbejdet er outsourcet, eller i forhold til virksomhedens ansatte. Materialet vil i øvrigt sjældent forlade virksomheden. Retsbeskyttelsen af det forberedende designmateriale giver anledning til to spørgsmål. For det første fremstår det ikke klart, hvornår sådant materiale favnes af OPHL 1, stk. 1-2 hhv. OPHL 1, stk. 3 og for det 79 Hanne Bender udtrykker, at materialet kan bestå af programmets kildekode, jf. Hanne Bender: EDB-rettigheder, 1998 s. 86. At betragte kildekode som forberedende arbejde må imidlertid anses for forkert. Selvom kildekoden er udtryk for programmets manifestation, på et tidligere stadie end objektkoden, er der ikke tale om forarbejde. Kildekoden udgør selve programmet og der er nær sammenhæng mellem denne og objektkoden, idet kompileringen til objektkode sker automatisk. Når direktivet benytter udtrykket forberedende designmateriale sigtes der til materiale i stil med ingeniør og arkitekttegninger som danner grundlag for selve arbejdet med implementering af det beskrevne. Hanne Bender sammenligninger da også efterfølgende det forberedende materiale med netop sådanne værker. 34

37 andet kan der sættes spørgsmålstegn ved, om materialet kan anses for et eksemplar af edb-programmet, på et tidligere stadie, således at det beskyttes mod realisering. Førstnævnte spørgsmål har alene teoretisk betydning, idet særreglerne vedr. edb-programmer ikke har nogen praktisk relevans i forhold til det forberedende materiale end ikke reglen i OPHL Sidstnævnte har derimod stor betydning for beskyttelsens omfang i krænkelsessituationer. Se modsat Thomas Riis, der anfører at den retlige kvalifikation, som edb-program, potentielt vil have betydning for overdragelser, der sker i ansættelsesforhold i medfør af OPHL Det er dog svært at forestille sig en arbejdsgiver, der beslutter at udnytte det forberedende materiale på nye måder og derfor, ifølge den ulovhjemlede regel om rettens overgang, ændrer sin sædvanlige virksomhed, med det resultat at retten til designmaterialet må forhandles særskilt. Se også Mads Bryde Andersen, der giver udtryk for, at reglerne om f.eks. dekompilering kan have relevans. 82 Dette kan ikke tiltrædes, idet de selvsagt ikke giver mening at tale om dekompilering af det forberedende materiale. Hanne Bender mener, at spørgsmålet om hvorvidt designmaterialet kan anses for et eksemplar af edb-programmet, foruden krænkelsessituationer, tillige har betydning i overdragelsessituationer hvor det er relevant at fastslå, hvorvidt en overdragelse af rettighederne til et edb-program også giver rettigheder til designmaterialet. 83 Den ophavsretlige kvalifikation af programbegrebet kan imidlertid ikke antages, at have betydning i denne sammenhæng. Det kan derimod en fortolkning af den aftale, der ligger grund for overdragelsen. 84 Som tidligere nævnt omfatter begrebet edb-program tillige forberedende designmateriale, jf. edbdirektivets art. 1, stk. 1, 2. pkt. og præamplens betragtning 7. Afgørende for om materialet omfattes af direktivet, og dermed af OPHL 1, stk. 3, er ifølge nævnte betragtning, hvorvidt et edb-program på et senere stadium kan være resultat heraf. Har det forberedende materiale ikke en sådan konkret karakter, vil det efter omstændighederne være omfattet af ophavsretslovens almindelige regler, som indeholdt i OPHL 1, stk En mere præcis angivelse af hvor konkret en karakter materialet skal antage, for at være omfattet af programbegrebet, giver direktivet intet svar på. Afgørende må være om materialet har en sådan karakter, at det er egnet til at danne grundlag for selve programmeringen og opbygningen af kildekoden. Det må antages, at der sigtes til forberedende materiale af teknisk, og ikke æstetisk karakter, idet programbegrebet omfatter programkoden og ikke æstetiske elementer. 85 Designarbejde, som relaterer sig til den grafiske brugergrænseflade vil derfor ikke være omfattet af OPHL 1, stk. 3. Baggrunden for at udvide programbegrebet, til at omfatte visse former for forberedende arbejde, forekommer ikke indlysende, og direktivet er ligeledes tavst i denne henseende. Det havde været 80 Jf. også Jon Bing: Ophavsretten og ny informasjonsteknologi - Noen sprete notater, i NIR 4/1995, s Jf. Thomas Riis: Immaterialret og IT, 2001, s Jf. Mads Bryde Andersen: IT-retten, 2005 s Jf. Hanne Bender: EDB-rettigheder, 1998 s Jf. også Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s Jf. også Thomas Riis: Immaterialret & IT, 2001 s. 22; Jon Bing: Ophavsretten og ny informasjonsteknologi - Noen sprete notater, i NIR 4/1995, s. 604 samt Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s

38 nærliggende, blot at lade det forberedende materiale omfatte af OPHL 1, stk. 1-2, uanset hvor konkret en karakter det måtte antage. Eksempelvis ville kravspecifikationen kunne betragtes som et litterært værk, jf. OPHL 1, stk. 1, og beskrivende elementer af mere teknisk karakter, f.eks. diagrammer over programmets struktur og dataflow, som beskrivende værker, jf. OPHL 1, stk. 2. Det kan tænkes, at lovgivers intention har været, at indskærpe, at visse former for forberedende materiale bør behandles som et eksemplar af edb-programmet på et tidligere stadie. Dette vil have den konsekvens at realisering af det forberedende materiale, uden ophavsmandens tilladelse, vil være retsstridigt, idet det endelige program vil være at betragte som en bearbejdelse heraf, jf. OPHL 4, stk. 1. Dette står i stærk kontrast til andre værker af beskrivende art, som omfattet af OPHL 1, stk. 2, da disse alene tilsiges en snæver beskyttelse mod efterligning, som ikke omfatter implementering af det beskrevne. 86 Der vil imidlertid sjældent være en så snæver sammenhæng mellem det forberedende arbejde og edbprogrammets kode, at det vil være relevant at betragte materialet som et eksemplar af programmet. Forberedende arbejde, så som arkitekttegninger, tv-programformater og filmmanuskripter, vil kunne beskrives på en sådan måde, at spændet mellem forarbejde og endelig manifestation er begrænset. Edbprogrammers forberedende arbejde er derimod mere abstrakt og overordnet, og selve implementeringen er i høj grad en såkaldt trial and error -process hvor programmørerne, med dette materiale som overordnet ramme, løbende arbejder på værkets endelige form. Formen er derfor ikke fastlagt på forhånd og gives det samme materiale til to uafhængige programmørhold er chancen for dobbeltfrembringelser i praksis lig nul, hvis programmet antager et vist omfang. En retsbeskyttelse af det forberedende materiale, der favner selve realiseringen heraf, vil derfor de facto medføre en ide-beskyttelse af programmets tekniske egenskaber dets funktion og opbygning. En sådan eneret til realisering af det forberedende materiale vil, som nævnt, primært have betydning i forhold til ansatte og samarbejdspartnere, og vil derfor ikke hindre den tekniske udvikling på markedet som helhed. Ikke desto mindre hører en sådan idebeskyttelse principielt hjemme i patentretten, hvor der skal ansøges om eneretten og hvor sagkyndige vurderer om opfindelsen kvalificerer sig til beskyttelse, idet der er tale om en objektiv nyhed, som er industriel anvendelig og som adskiller sig væsentlig fra det allerede kendte. Det må derfor vurderes at formålet med, 86 Jf. Morten Rosenmeier: Immaterialret, 2008 s samt s Beskyttes tekniske tegninger mod realisering opnås en indirekte beskyttelse af selve det produkt, der implementeres på baggrund af de tekniske specifikationer, og en sådan beskyttelse hører hjemme i patentretten. Bemærk, at der uden for de nordiske lande ikke eksisterer en selvstændig værkskategori for såkaldte beskrivende værker. Princippet om ikke at beskytte tekniske tegninger mod implementering er dog et generelt ophavsretligt princip i Europa. 36

39 at henføre det forberedende materiale til værkstypen edb-programmer alene har været, at behandle det forberedende materiale efter samme regler som selve edb-programmet. 87 Henset til direktivets ordlyd må det sammenfattende konkluderes, at forberedende designmateriale skal behandles efter OPHL 1, stk. 3 og reglerne vedr. edb-programmer, men at selve programmet og det forberedende materiale, i praksis, vil være at betragte som to selvstændige værker efter nævnte bestemmelse. 88 Dette fordi at materiale, som det nævnte, alene vil udgøre en så abstrakt repræsentation af det edb-program, der udarbejdes på baggrund heraf, at der ikke er grundlag for, at anse det for et eksemplar af selve programmet. Af samme årsag vil materialet ikke være beskyttet mod realisering. Dette er i øvrigt i overensstemmelse med direktivets art. 1, stk. 2, 2. pkt., hvor det klart fremgår, at ideer og principper ikke beskyttes. Reelt opnås derfor en beskyttelse, som den der tilsiges tekniske tegninger, herunder ingeniør-tegninger, som ej heller er beskyttet mod realisering. Implementeres et program på baggrund af betroet materiale, uden tilladelse, vil dette imidlertid kunne være i strid med MFL 19, som opstiller et værn mod uberettiget brug af erhvervshemmeligheder - se hertil afsnit 5. Afslutningsvis må nævnes, at visse teoretikere har udtrykt den opfattelse, at det forberedende materiale kan være så detaljeret, at selve implementeringen i kode ikke vil være udtryk for en intellektuel indsats, hvorfor det resulterende program ikke udgør et værk. 89 Det følger heraf, at der i tilfælde, hvor der ikke er personsammenfald, mellem de der udarbejder det forberedende materiale, og de der implementere edbprogrammet i kildekode, og i mangel af aftale, må afgøres konkret hvem, der må betragtes som ophavsmænd. Selvom dette teoretiske udgangspunkt virker rigtigt, må vurderes at denne problemstilling, rent praktisk, sjældent vil opstå. Selve det forberedende arbejde adskiller sig væsentligt fra selve koden, jf. ovenfor. Designet, som det anføres i dette materiale, vil derfor kunne implementeres på et næsten ubegrænset antal måder i kildekoden, og programmørens udviklingsarbejde vil derfor altid kræve en form for intellektuel indsats som foreskrevet i edb-direktivet. 87 Jf. også Hanne Bender: EDB-rettigheder, 1998 s. 89 samt Mads Bryde Andersen: IT-retten, 2005 s Samme opfattelse har Hanne Bender: EDB-rettigheder, 1998 s Mads Bryde Andersen: IT-retten, 2005 s , er heller ikke af den opfattelse, at det forberedende materiale vil kunne anses for et eksemplar af edbprogrammet, men mener imidlertid, at hjemlen til beskyttelse heraf er OPHL 1, stk Jon Bing og Morten Rosenmeier mener at hjemlen til beskyttelse er OPHL 1, stk. 3, men er modsat af den opfattelse, at designmateriale efter omstændighederne vil kunne anses for et eksemplar af edb-programmet. Som nævnt, må dette formodes aldrig at være tilfældet i praksis. Jon Bing når da også den konklusion, at der som hovedregel vil være tale om to uafhængige værker. Se Jon Bing: Ophavsretten og ny informasjonsteknologi - Noen sprete notater, i NIR 4/1995, s og Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s Se eksempelvis Morten Rosenmeier: Værkslæren i ophavsretten, 2001 s. 210 (med henvisninger). 37

40 3.2.4 Reverse engineering Som navnet antyder, dækker begrebet reverse engineering over fremgangsmåder og processer, som har til formål at afsløre produkters virkemåde. I forhold til mekanik udføres processen ved fysisk at skille den pågældende frembringelse ad, og samme gør sig gældende for moderne elektronik, som dog ofte er så avanceret, at det kræver særlige redskaber og en stor indsats, at opnå brugbar viden. I langt de fleste tilfælde er sådan elektronik desuden afhængig af integrerede edb-programmer, som styrer de fysiske komponenter, og de der foretager reverse engineering kan derfor tillige have en interesse i at afsløre disse programmers virkemåde. For så vidt angår edb-programmer kompliceres reverse engineering -processen derved, at sådanne produkter oftest distribueres som closed source, dvs. i en form hvor kildekoden ikke er tilgængelig. Med undtagelse af open source -programmer er det således alene den maskinlæsbare objektkode, eller såkaldte byte-kode, der er tilgængelig for analyse. Disse typer af kode adskiller sig væsentligt fra den oprindelige kildekode, idet de ved kompileringen er oversat til en mere simpel og effektiv form, som computerens processor (objektkode) eller en fortolker (byte-kode) er i stand til at bearbejde. 90 Kompileringsprocessen medfører således, at en lang række informationer, så som kodens oprindelige struktur og den anvendte syntaks, såvel som programmørens kommentarer og logiske navngivning af forskellige kodelementer (variabler, metoder mv.), ikke længere er direkte tilgængelig ved blot at åbne filen i et tekstbehandlingsprogram. Dette betyder at det, i modsætning til andre tekniske frembringelser, ikke umiddelbart er muligt at skille produktet ad, for herved at få indsigt i dets interne design og virkemåde. En sådan indsigt i edb-programmet kræver anvendelse af særlige reverse engineering -teknikker. Disse omtales i det følgende afsnit Reverse engineering -teknikker og deres anvendelse Der findes en række metoder, som kan anvendes til at få indblik i et edb-programs virkemåde, og da den tekniske proces varierer, påvirker dette vurderingen af, om en given fremgangsmåde er lovlig. På denne baggrund skal kort nævnes nogle af de mest anvendte metoder. Metoderne vil herefter danne grundlag for en juridisk analyse, hvis konklusioner vil kunne benyttes, som redskab til at vurdere andre teknikker med tilsvarende karakteristika. Sniffing: Denne metode anvendes typisk, hvor målet er at opnå viden om de protokoller (regler for dataudveksling), som et edb-program anvender, når data udveksles over et netværk. Edbprogrammets kode er i denne henseende uinteressant, og al information opnås ved at analysere de data, der sendes over netværket. Kendskab til den anvendte protokol giver herefter grundlag for at 90 Se nærmere afsnit 2. 38

41 udvikle et edb-program, som efterligner den gældende adfærd og derfor kan indgå i netværket. Formålet er med andre ord at opnå interoperabilitet med ophavsmandens produkt. Disassembly: Ved disassembly anvendes programmer, der er udviklet med henblik på, at udlede de binære instruktioner som, ved kørsel af et edb-program, transmitteres til computerens processor. Disse omformes herefter til såkaldt assembly -sprog, der udgør en tekstuel repræsentation af instruktionerne. Det bemærkes, at det ikke er den oprindelige kildekode, som udarbejdet af edb-programmets udviklere, der udledes. Detaljer vedrørende kildekodens oprindelige struktur og logik, såvel som programmørernes kommentarer, er ikke længere tilgængelig og den information, der opnås ved disassembly, er således svært tilgængelig. Det fremstår på denne baggrund klart, at metoden ikke benyttes med henblik på at plagiere ophavsmandens kode. Processen er derimod effektiv til, at give brugeren indblik i edbprogrammets algoritmer og/eller tekniske grænseflader. 91 Dekompilering: I modsætning til førnævnte metoder er formålet med dekompilering at udlede den oprindelige kildekode eller noget der ligner, og processen er derfor bedre egnet til at producere resultater, der kan anvendes i strid med OPHL nemlig plagiering af kode. Resultatet varierer, alt afhængig af om processen foretages på objektkode eller byte-kode. Hvor dekompilering af objektkode typisk ikke er muligt, idet langt den meste højniveau -information er gået tabt ved kompileringen, forholder det sig anderledes med byte-kode. Denne form for kode indeholder typisk langt flere informationer om den oprindelige kildekode, og at udlede kildekoden på baggrund heraf er derfor relativt enkelt, idet der er udviklet en række programmer som automatiserer processen. Ofte benytter programudviklere sig imidlertid af teknikker, f.eks. kryptering og anden sløring, som vanskeliggør denne proces. Selv hvor grundlaget for dekompileringsprocessen er byte-kode er det således ikke givet, at der opnås brugbare resultater. 92 Som det fremgår, vil ovennævnte teknikker sjældent være effektive til at afsløre den oprindelige kildekode, men de vil kunne anvendes til at danne sig indblik i programmets overordnede algoritmer, dets grænseflader og de protokoller, der anvendes. Reverse engineering vil da også sjældent blive foretaget med henblik på, at plagiere rettighedshaverens kode. Den tid og de omkostninger der er forbundet med at tolke koden, og tilpasse den til egne programmer, står ganske enkelt ikke mål med gevinsten herved. I de 91 For nærmere information om disassembly henvises til Eldad Eilam: Reversing secrets of reverse engineering, Wiley, 2005 s Der henvises for nærmere omtale til Eldad Eilam: Reversing secrets of reverse engineering, 2005 s. 424ff. 39

42 fleste praktisk forekommende tilfælde vil det således være fordelagtigt at skrive koden selvstændigt, medmindre der undtagelsesvis er tale om komplekse, unikke og isolerede algoritmer, som direkte kan genanvendes. 93 Formålet med reverse engineering er derimod typisk en analyse af edb-programmets sikkerhed, at omgå eller fjerne beskyttelsesmekanismer (cracking), eller at opnå den viden der er nødvendig for at skabe interoperabilitet. 94 I juridisk sammenhæng kan formålet endvidere være at skaffe sig den indsigt, der er nødvendig for at afgøre, om et givent produkt indeholder kode, som krænker ophavsretten, eller ideer som krænker patentretten. 95 Visse reverse engineering -teknikker kan alene anvendes lovligt, såfremt formålet er opnå interoperabilitet. I forbindelse med edb-direktivets vedtagelse blev således indgået et kompromis, hvorefter ophavsmændene fik indført en særregel i OPHL 37, der begrænsede den frie adgang til analyse i OPHL 36, stk. 1, nr At man trods alt valgte, at tillade enhver form for reverse engineering, foretaget i interoperabilitetsøjemed, skyldes konkurrencemæssige betænkeligheder Nærmere om interoperabilitet og konkurrence Set i forhold til konkurrenter, der ønsker at plagiere ophavsmandens produkt, er et forbud mod reverse engineering ikke betænkeligt, men som anført er det sjældent, at reverse engineering af edbprogrammer foretages med dette formål for øje. Oftest er formålet det mere legitime, at skaffe den viden om programmets grænseflader og/eller dets protokoller, som er nødvendig for, at skabe interoperabilitet mellem selvstændigt udviklede produkter og ophavsmandens produkt. 98 Da edb-programmer i dag findes integreret i al moderne elektronik, opstår behovet for interoperabilitet ikke udelukkende i relationen mellem selvstændige edb-programmer, men også mellem forskellige hardware-komponenter, og mellem edb-programmer og hardware. Specielt i tilfælde hvor ophavsmandens produkt nyder stor udbredelse på markedet, er interoperabilitet helt afgørende for udviklere af komplementære og substituerbare produkter, idet det ofte vil være et succeskriterium, at disse fungerer i samspil med markedsstandarden. Dette skyldes at markedet for teknologiske produkter, herunder edb-programmer, er præget af såkaldte netværkseksternaliteter. Hvor ophavsmandens produkt ikke fungerer i isolation, men hvor det er designet 93 Eldad Eilam: Reversing secrets of reverse engineering, 2005 s. 4 og s Jf. også Eldad Eilam: Reversing secrets of reverse engineering, 2005 s Ophavsretligt er det nødvendigt, at føre bevis for krænkelser på kodeniveau, idet selve koden som nævnt er beskyttelsens genstand. Patentretligt er det derimod ikke den specifikke kodemæssige implementering der beskyttes, men ideer, forstået som overordnede algoritmer og metoder. Analyse af koden kan dog underbygge en vurdering af om funktionaliteten opnås på baggrund af en patenteret algoritme/metode, der krænker patentet. 96 For nærmere omtale af de drøftelser, der ledte til vedtagelse af edb-direktivets art. 6, vedr. dekompilering, henvises til Thomas C. Vinje: The EC Software Directive and the Question of Interoperability, i NIR 1/1992, s Jf. også Mads Bryde Andersen: IT-retten, 2005 s Definition af begreberne grænseflader og protokoller såvel som spørgsmålet om deres ophavsretlige beskyttelse drøftes i

43 med henblik på, at interagere med andre produkter af samme type, vil produktets værdi stige i takt med dets udbredelse. Der er altså tale om en selvforstærkende effekt, hvor et produkts nytteværdi er relateret til antallet af brugere, og hvor antallet af brugere derfor øges i takt med nytteværdien. I sådanne tilfælde tales i økonomisk henseende om en direkte netværkseksternalitet. Det klassiske eksempel er telefonen, hvis værdi stiger i takt med dens udbredelse, og indenfor edb-programmernes verden kan nævnes telefonens elektroniske pendant - programmet Skype - som gør det muligt, at ringe gratis til andre Skype-brugere over internettet. Opnår et produkt først stor udbredelse på et marked præget af sådanne effekter, har forbrugerne et stærkt incitament til at holde sig til standarden. Den nytteværdi, som forbrugerne oplever, udgør derfor en adgangsbarriere. Disse adgangsbarrierer forstærkes yderligere, hvor der i tilknytning til en standard, eksisterer afledte markeder for komplementærprodukter. Standardens udbredelse bevirker, at der i tilknytning hertil findes et stort forbrugersegment, hvis behov der er mulighed for at tilfredsstille, og ved at fokusere på standarden er det muligt, for producenterne af komplementær-produkter, at mindske deres omkostninger og øge deres profit. En markedsstandard agerer derfor katalysator for udvikling af en bred vifte af komplementærprodukter. Dette forøger standardens nytteværdi yderligere, og mindsker incitamentet til at vælge konkurrerende løsninger. Dette kaldes en indirekte netværkseksternalitet. Såfremt eneretten, i sådanne tilfælde, var til hinder for, at den pågældende information lovligt kunne udledes ved brug af reverse engineering, ville den potentielt virke som en stærk hæmsko for konkurrencen på markedet. Ovennævnte effekter medfører at markeder, som er karakteriseret ved stærke netværkseksternaliteter, har en tendens til at tippe til fordel for et enkelt produkt. Selvom denne tendens til standardisering, som udgangspunkt er gavnlig, set i et samfundsøkonomisk perspektiv, kan der opstå tilfælde hvor ophavsmanden opnår et længerevarende monopol på markedet med heraf følgende negative konsekvenser for innovation, pris og udbud. Når et produkt først har opnået status som en de facto standard på markedet, består endvidere den risiko, at ophavsmanden indstiller offentliggørelsen af de grænsefladespecifikationer, som er nødvendige for at udvikle visse komplementære produkter. Herved er det muligt at forbeholde sig eksklusiv adgang til markedet herfor, og effektivt udvide dominansen på det primære marked, til også at omfatte dele af det sekundære såkaldt løftestangs-adfærd. Disse negative konsekvenser kan, i et vist omfang, afbødes ved at sikre konkurrenter mulighed for, at opnå interoperabilitet ved brug af reverse engineering For nærmere omtale af disse effekter og deres konkurrencemæssige implikationer i relation til software og anden teknologi henvises til David Telyas, Jacob Gebauer Jochimsen & Lars Thorvald Kiær: Grænsefladespørgsmål mellem immaterial- og konkurrenceret et teknologisk perspektiv med fokus på Microsoft-sagen, bachelorafhandling, 2008, afsnit (med henvisninger). 41

44 Reglerne i OPHL 36, stk. 1, nr. 3 og OPHK 37 skal ses på denne baggrund. 100 Førstnævnte bestemmelse giver hjemmel til, at analysere edb-programmer på mere overfladisk niveau, mens sidstnævnte knytter sig til analysemetoder, der har til formål at udlede selve programmets kode. 101 Bestemmelserne skaber således det retlige grundlag, der er nødvendigt, for at opnå interoperabilitet, i tilfælde hvor de nødvendige informationer ikke offentliggøres eller licenseres. Grundet teknikkernes kompleksitet, og det faktum at ophavsmanden ville kunne ændre protokoller og grænseflader uden varsel, er undtagelserne dog ikke altid tilstrækkelige til at sikre et effektivt marked. Den heraf følgende problemstilling må løses i medfør af konkurrenceretten. 102 Det må imidlertid bemærkes, at de nødvendige interoperabilitets-specifikationer ofte vil være tilgængelige, evt. mod betaling, idet ophavsmanden typisk har interesse, i at lette udviklingen af komplementærprodukter. Et rigt marked for komplementærprodukter vil, som nævnt, øge værdien af ophavsmandens produkt, som følge af større forbrugernytte, og skabe større forbrugerloyalitet. Som eksempel kan nævnes Microsoft Windows (PC-styresystem), Google Android (styresystem til mobiltelefoner) og styresystemet på Apple Iphone, hvor information om grænsefladerne i de fleste tilfælde er tilgængelig. Dette har medført et væld af komplementære edb-programmer, der udvider produkternes funktionalitet og herved bidrager til deres succes på markedet Hvornår er reverse engineering lovligt? Hvor reverse engineering af fysiske produkter er lovligt, selv hvor det pågældende produkt er omfattet af et eller flere patenter 103, forholder det sig anderledes med edb-programmer, hvor processen forudsætter en eksemplarfremstilling der, som udgangspunkt, er i strid med ophavsretten. Foruden den midlertidige og teknisk betingede eksemplarfremstilling, som sker ved almindelig kørsel af et edb-program, medfører både dekompilering og disassembly et yderligere eksemplar af programkoden, idet brugeren præsenteres for hhv. kildekode eller en tekstuel repræsentation af maskininstruktionerne (dvs. den binære kode i anden form). Sniffing -teknikken anvendes derimod ikke med henblik på at udlede detailviden om selve programmets implementering, men angår alene de data, der sendes til/fra programmet, og derfor sker 100 Det må bemærkes at der, foruden nævnte netværkseksternaliteter, ofte eksisterer adgangsbarrierer til markedet som følge af de væsentlige omkostninger, der er forbundet med at skifte til konkurrerende produkter ( switching costs ) og lære disse at bruge ( learning costs ). Der kan være tale om tids- eller pengemæssige omkostninger forbundet med markedsundersøgelse, oplæring, integration med eksisterende forretningsgange og systemer, installation af det nye produkt osv. Disse adgangsbarrierer kan selvsagt ikke mindskes som følge af undtagelserne i OPHL 36, stk. 1, nr. 3 og OPHL Den nærmere afgrænsning af de to bestemmelser gennemgås nærmere nedenfor. 102 Se hertil afsnit Dette følger af PTL 3, stk. 3, nr. 3, som er indført på baggrund af EPC art. 31, litra b. Af reglen fremgår, at eneretten ikke omfatter handlinger, som udføres i forsøgsøjemed i forbindelse med genstanden for den patenterede opfindelse. 42

45 alene den midlertidige og teknisk betingede eksemplarfremstilling, der er nødvendig for at kunne afvikle edb-programmet. Denne forskel metoderne imellem bevirker, at lovhjemlen skal søges i forskellige bestemmelser, jf. nedenfor. Som det vil fremgå er de reverse engineering -teknikker, hvor der foruden den teknisk betingede eksemplarfremstilling, som sker ved almindelig kørsel af et program, tillige fremstilles eksemplarer af koden med henblik på præsentation for brugeren, som udgangspunkt i strid med ophavsretten. Undtagelse gøres alene hvor formålet er at opnå interoperabilitet. Det fremgår af OPHL 2, stk. 1 sml. 2, stk. 2, at ophavsmanden har eneret til enhver form for eksemplarfremstilling, være sig hel eller delvis, midlertidig eller permanent, direkte eller indirekte. Udgangspunktet er på denne baggrund, at enhver brug af et edb-program er i strid med eneretten til eksemplarfremstilling, idet der i forbindelse med installation og kørsel af programmet vil blive skabt permanente kopier på computerens harddisk, såvel som midlertidige kopier i dens RAM og cache. Dette udgangspunkt er selvsagt ikke holdbart. Der er derfor indført en særregel, i OPHL 36, stk. 1, nr. 1, som tillader den, der har ret 104 til at benytte et edb-program, at fremstille de eksemplarer, der er nødvendige for at benytte programmet efter sit formål. 105 Som anført finder reglen kun anvendelse, hvor edb-programmet anvendes efter sit formål, og da ophavsmanden typisk ikke udsteder licens, med henblik på at brugeren skal få indsigt i selve programmets virkemåde, skabes ikke herved hjemmel til eksemplarfremstilling i forbindelse med reverse engineering. 106 Hjemlen må derfor søges i OPHL 36, stk. 1, nr. 3 og 37, som analyseres nedenfor. Hertil bemærkes, at reglen i OPHL 11a ( browser -reglen), som undtager visse former for teknisk betinget, tilfældig/flygtig og lovlig eksemplarfremstilling, som sker i forbindelse med en mellemmands transmission af et værk, eller lovlig brug i øvrigt (f.eks. afspilning af digital musik og film samt browsing på internettet 107 ), ikke omfatter edb-programmer, jf. OPHL 11a, stk OPHL 37, som indfører edb-direktivets art. 6, tillader, under nærmere angivne betingelser, reverse engineering foretaget i interoperabilitetsøjemed. 109 På trods af at bestemmelsen, i både edb-direktivet og i ophavsretsloven, er indsat med titlen dekompilering, må antages, at der tillige opnås adgang til at fortage 104 Retten kan opnås ved at købe et eksemplar af edb-programmet eller ved i øvrigt at indgå aftale med ophavsmanden. Det må bemærkes at licensaftalen ofte kun giver brugeren ret til at benytte programmet på én PC, og ønsker den pågældende, at installere programmet på flere computere må der derfor indhentes yderligere licenser. 105 Indført på baggrund af edb-direktivets art. 5, stk Jf. også Mads Bryde Andersen: IT-retten, 2005 s Når der f.eks. tilgås internetsider fra en browser sker der som led i denne proces en teknisk betinget eksemplarfremstilling (i computerens ram og cache, såvel som på harddisken hvor der ofte lagres midlertidige filer, så som billeder, der herved hurtigt kan vises næste gang siden besøges) af de data, som sendes fra web-serveren. 108 OPHL 11a blev indført på baggrund af Infosoc-direktivets art. 5, stk Som følge af de sidemæssige begrænsninger denne afhandling er underlagt, henvises for nærmere analyse af betingelserne til Mads Bryde Andersen: IT-retten, 2005 s

46 eksemplarfremstilling i forbindelse med disassembly. 110 I modsat fald ville formålet med bestemmelsen blive undermineret af de praktiske realiteter, da det sjældent er muligt at udlede den nødvendige information ved dekompilering. Der er ikke grundlag for at konkludere, at disassembly skulle være omfattet af den mindre strenge regel i OPHL 36, stk. 1, nr. 3. Sniffing og såkaldte black box -test 111, omfattes derimod af OPHL 36, stk. 1, nr. 3. Se nærmere om afgrænsningen mellem de to bestemmelser i afsnit Af OPHL 37, stk. 1, nr. 1-3 følger at de omfattede handlinger kun må udføres såfremt: 1) handlingerne udføres af licenshaveren eller af en anden person, der har ret til at benytte et eksemplar af et edb-program, eller på disses vegne af en person, der har tilladelse hertil, 2) de oplysninger, der er nødvendige for at tilvejebringe interoperabilitet, ikke tidligere har været let og hurtigt tilgængelige for de i nr. 1 nævnte personer, og 3) handlingerne er begrænset til de dele af det oprindelige edb-program, der er nødvendige for at opnå interoperabilitet. Det følger endvidere, af OPHL 37, stk. 2, nr. 1, at den opnåede viden ikke må benyttes til andre formål, end at gøre et, selvstændigt udviklet, edb-program interoperabelt, og af OPHL 37, stk. 2, nr. 3 er nævnt den naturlige følge, at der ikke må ske plagiering af ophavsmandens kode. Endelig fremgår af OPHL 37, stk. 2, nr. 2, at den viden, som opnås, ikke må spredes til tredjemand, medmindre dette er nødvendigt for at opnå interoperabilitet. Bestemmelsen medfører ingen øvrige begrænsninger i forhold til brugen af den opnåede viden. Så længe den benyttes i interoperabilitetsøjemed, er det således underordnet, om konkurrerende eller komplementære produkter opnår gavn heraf. 112 Det må desuden bemærkes, at handlingen kan foretages med det formål, at opnå interoperabilitet med et andet program, end det der rent faktisk udsættes for reverse engineering, jf. formuleringen andre edb-programmer i OPHL 37, stk Som nævnt ovenfor, afsnit , er dekompilering blot en af flere reverse engineering -teknikker. Dekompilering er karakteriseret ved, at have til formål, at udlede den oprindelige kildekode eller noget der minder herom. 111 Formålet er typisk at afsløre funktionalitetsfejl, mangler eller effektivitetsproblemer ved at udsætte programmet for forskellige input, og herefter registrere om der returneres det forventede output. Der er således ikke tale om egentlig reverse engineering hvor formålet er at opnå forståelse for programmets implementering. Udgangspunktet for en black box -test er et kendskab til edb-programmets grænseflader, og en række testscenarier udarbejdet på baggrund heraf. Selve programkoden kendes ikke - heraf navnet blackbox. 112 Jf. også Mads Bryde Andersen: IT-retten, 2005 s. 396 samt Thomas Riis: Immaterialret & IT, 2001 s

47 Den amerikanske sag Sony Computer Entertainment, Inc v. Connectix Corp er illustrerende for sådan brug af reverse engineering. 113 Med hjemmel i den amerikanske fair use -regel, fandt retten, at Connectix lovligt kunne foretage reverse engineering, af BIOS en 114 i Sony s playstation spillekonsollen, med henblik på at udvikle en emulator, der kunne afvikle Playstation spil på Apple s Mac computere. Handlingen rettede sig således ikke mod, at opnå interoperabilitet med det program (BIOS en), der blev udsat for reverse engineering, men med en bred vifte af aktuelle og fremtidige spil. Da adgangen til reverse engineering er begrænset til de dele af programmet, som er nødvendige for at opnå interoperabilitet, jf. OPHL 37, stk. 1, nr. 3, kan det være fordelagtigt for udviklere, at lade grænsefladerne være let identificerbare. Herved undgår ophavsmanden, at der på lovlig vis opnås indsigt i den øvrige programkode, når dette er en forudsætning for at tilegne sig den viden der muliggør interoperabilitet. 115 Selvom OPHL 37 alene gælder reverse engineering af edb-programmer (programkoden) må det antages, at reglerne også giver adgang til eksemplarfremstilling af dataelementer (billeder, tekst, databaser mv.) i det omfang disse ikke kan udskilles fra objekt- eller byte-koden. I modsat fald ville bestemmelsen reelt være illusorisk, idet programudvikleren, ved at sammensmelte den eksekverbare kode med dataelementer, effektivt vil kunne hindre bestemmelsen, i at opnå den tilsigtede virkning Afgrænsningen mellem OPHL 36, stk. 1, nr. 3 og OPHL 37 Reglen i OPHL 37 giver anledning til visse afgrænsningsvanskeligheder i forhold til OPHL 36, stk. 1, nr. 3, som giver ret til at besigtige, undersøge og afprøve edb-programmet. Spørgsmålet er hvilke former for eksemplarfremstilling, der skal henføres til de respektive bestemmelser. Der er ikke i teorien enighed om, hvordan de to bestemmelser bør afgrænses overfor hinanden, og der er intet bidrag at hente i retspraksis. Opfattelsen hos et udvalg af forfattere er præsenteret i petit skrift herunder. Thomas Riis: Immaterialret & IT, 2001 s. 52, mener at OPHL 36, stk. 1, nr. 3 må opfattes som en præcisering af OPHL 36, stk. 1, nr. 1, uden selvstændig substans. Dette kan ikke tiltrædes. Bestemmelsen i OPHL 36, stk. 1, nr. 1 kan ikke antages at favne unormal brug af programmet i forbindelse med analyser, jf. forrige afsnit. OPHL 36, stk. 1, nr. 3 må derfor antages, at være en nødvendig hjemmel til mere overfladisk analyse, som ikke kræver opfyldelse af de strenge betingelser i OPHL 37. Forfatteren synes i øvrigt at være af den opfattelse, af kun dekompilering, forstået som den proces, der har til formål at udlede 113 Sag 203 F.3d 596 (9th Cir. 2000) 114 BIOS er en forkortelse for basic input output system, og er et mindre edb-program, der er integreret i de fleste computere, herunder Sony Playstation spillekonsollen. Programmets formål er, at facilitere interaktion mellem hardware og operativsystem på computeren. 115 Jf. også Mads Bryde Andersen: IT-retten, 2005 s Jf. også Jon Bing: Vurderering av opphavsrettslig krenkelse av datamaskinprogrammer et praktisk perspektiv, i NIR 2/1999, s. 285 samt Anders Mediaas Wagle & Magnus Ødegaard jr.: Opphavsrett i en digital verden, 1998 s. 85. Bemærk i den forbindelse at reglen i OPHL 11a, ikke kan danne grundlag for en sådan eksemplarfremstilling af programmets data, allerede fordi den ikke er flygtig eller tilfældig. 45

48 programmets kildekode, er omfattet af OPHL 37 (s. 55). Heraf må modsætningsvis sluttes, at samtlige de øvrige reverse engineering -teknikker skulle være omfattet af OPHL 36, stk. 1, nr. 3. Michael Plogell: Immaterialrättsliga aspekter på datorprogram, 1996 s. 45ff, er derimod af den opfattelse, at det, med hjemmel i OPHL 36, stk. 1, nr. 3, ikke er tilladt at anvende hjælpemidler underforstået andre edb-programmer, der oversætter kodens form så den er lettere forståelig mens dette er tilladt med hjemmel i 37. Hermed vil f.eks. analyse af den rå maskinkode i en såkaldt hex editor 117 være tilladt efter OPHL 36, stk. 1, nr. 3, mens disassembly vil være omfattet af OPHL 37. Thomas C. Vinje: The EC Software Directive and the Question of Interoperability, NIR 1/1992 s , mener endelig at OPHL 36, stk. 1, nr. 3 omfatter alle former for analyse med undtagelse af dekompilering, som favnes af OPHL 37. Dette støttes på den betragtning, at de to bestemmelser skal ses som udslag af et kompromis, hvor rettighedshaverne fik indført en særregel vedr. netop dekompilering. Forfatteren definerer imidlertid dekompilering bredere end det er tilfældet i teknisk fagsprog, idet det anføres, at begrebet omfatter samtlige teknikker som har til formål at oversætte kodens form, herunder disassembly. Resultatet af sondringen bliver herefter det samme som Michael Plogell foreslår. Mads Bryde Andersen: IT-retten, 2005 s. 392, mener, at alle analysehandlinger, der indebærer kopiering eller transformering af selve programmet, ud over den som programmet er beregnet til selv at foretage ved kørsel, må favnes af OPHL 37. I modsætning til Michael Plogell og Thomas C. Vinje er forfatteren således af den opfattelse, at analyse ved brug af en hex editor, ikke må udføres med hjemmel i OPHL 36, stk. 1, nr. 3. Afgrænsningen mellem de to bestemmelser har materiel betydning. Dette fordi der til OPHL 37 er knyttet en række betingelser, som ikke er gældende i henhold til OPHL 36. Eksempelvis opstiller OPHL 36 ingen restriktioner i relation til viderespredning af den information, der opnås ved analyse. Den praktiske betydning må endvidere vurderes at være stor, da udviklere dagligt beskæftiger sig med sådanne teknikker, og derfor har behov for at kunne vurdere lovligheden heraf. Det kan derfor undre, at lovgiver ikke har gjort sig større anstrengelser, for nærmere at præcisere indholdet af de to bestemmelser. Der kan argumenteres for at OPHL 37, som titlen antyder, alene omfatter den type reverse engineering der benævnes dekompilering, og at begrebet skal fortolkes så snævert, at beslægtede metoder ikke omfattes af begrebet. En så snæver fortolkning kan imidlertid ikke være i tråd med bestemmelsens formål. I praksis vil det ofte være disassembly, der benyttes til at opnå den viden, der er nødvendig for at skabe interoperabilitet. 118 Udelukkes disassembly, fra anvendelsesområdet i OPHL 37, vil teknikken blive forvist til et juridisk tomrum, idet OPHL 36, stk. 1, nr. 3 må vurderes ikke at skabe hjemmel hertil. Ifølge ordlyden giver OPHL 36, stk. 1, nr. 3 alene hjemmel til at besigtige, undersøge eller afprøve edbprogrammet for at fastslå, hvilke ideer og principper der ligger til grund for de enkelte elementer i 117 En hex editor et er edb-program som giver brugeren mulighed for at redigere direkte i de binære oplysninger, som indeholdt i en hvilken som helst fil være sig et edb-program eller en datafil. I modsætning til et almindeligt tekstbehandlingsprogram søger en hex-editor ikke at tolke indholdet af filen, men viser de rå maskindata i et hexadecimal talsystem. Formålet er ikke, at give indsigt i programmets kildekode eller at udlede dets algoritmer, men at give mulighed for mindre ændringer i et program eller at få indblik i hvordan data i et givent filformat, f.eks. PDF, er struktureret. Denne viden kan herefter benyttes til at eksempelvis, at udvikle et program der kan læse og redigere de pågældende data. 118 Det må endvidere erindres, at problemstillingen i givet fald skal løses ved EU-Domstolen, der er kendt for at anlægge pragmatiske og formålsbestemte fortolkninger. 46

49 programmet *fremhævet her+. Da brugeren, som resultat af dekompilering og disassembly, præsenteres for et eksemplar af programkoden, udledes ikke alene sådanne ideer og principper. Det må således vurderes, at OPHL 36, stk. 1, nr. 3 alene giver hjemmel til, at afvikle et program med henblik på mere overfladisk undersøgelse af f.eks. netværkstrafik, funktionalitet og brugergrænsefladens opbygning med videre. OPHL 37, hvortil der er knyttet en række yderligere betingelser, omfatter derimod eksemplarfremstilling med henblik på at få indsigt i programmets indre dets kode. Af de, i afsnit , nævnte former for reverse engineering er det derfor kun sniffing, der kan foretages med hjemmel i OPHL 36, stk. 1, nr. 3, mens dekompilering og disassembly alene er lovligt, såfremt betingelserne i 37 opfyldes. Den forskel, som består i, at dekompilering har til formål at udlede den oprindelige kildekode, mens disassembly har til formål, at udlede en tekstuel repræsentation af objektkoden, kan ikke anses for afgørende. Rent teknisk sker i begge tilfælde en transformering af koden med henblik på præsentation for brugeren, og det er nærliggende at konkludere, at anvendelse af teknikker, der er karakteriseret ved samme tekniske resultat som dekompilering, må søge hjemmel i OPHL 37. Heraf følger, at redigering af den rå objektkode ved brug af en hex-editor, uagtet at brugeren præsenteres for den binære programkode, må antages at være omfattet af OPHL 36, stk. 1, nr. 3, idet en sådan transformation af koden ikke finder sted. Denne sondring underbygges, ved at slutte modsætningsvis til ordlyden i OPHL 37, hvor der tales om oversættelse af kodens form. En sådan oversættelse finder ikke sted ved brug af en hex-editor. 119 Grundet den begrænsede værdi, som den rå programkode bidrager med i analysemæssig henseende, benyttes en hex-editor, oftest til at få indblik i filformater (eksempelvis PDF, DOCX mv.), og ikke edbprogrammer, hvorfor rubriceringen ikke har større praktisk betydning. Brugen af hex-editor, til at ændre edb-programmer, er alene lovligt, såfremt disse ændringer er nødvendige for at kunne benytte programmet efter sit formål, herunder foretage rettelse af fejl, jf. OPHL 36, stk. 1, nr. 1. Da ændringer af denne type typisk vil kræve indsigt i selve programkodens virkemåde, vil brug af en hex-editor endvidere forsætte anvendelse af teknikker, som favnes af OPHL 37. Teknikken har derfor i alle henseender begrænset selvstændig betydning i forhold til edb-programmer. På baggrund af ovenstående må konkluderes, at bestemmelsen i OPHL 36, stk. 1, nr. 3 giver adgang til overfladiske analyser og testkørsler af et edb-program, som ikke involverer oversættelse af programkoden. Dette betyder at teknikker så som sniffing, black box -tests, og brug af hex editor, tillades med hjemmel i denne bestemmelse. Dekompilering og disassembly, som benyttes med henblik på at præsentere brugeren for et eksemplar af programkoden i ændret form, må derimod antages at være 119 Ved brug af disassembly oversættes koden til assembly sprog og ved brug af dekompilering oversættes programkoden (objekt eller bytekode) til det højniveausprog som koden oprindelig blev skrevet i. Ved brug af en Hexeditor ændres kodens form ikke. 47

50 omfattet af OPHL 37. Denne opfattelse er i tråd med Thomas C. Vinje s og Michael Plogell s. 120 Sidstnævnte forfatter mener tillige, at det i relation til reglen i OPHL 36, stk. 1, nr. 1 (den legale programlicens), teoretisk set er tilladt at anvende dekompilering og disassembly. 121 Dette med henblik på at opnå den indsigt, som gør det muligt, at foretage de ændringer i programmet, der tillades ifølge nævnte bestemmelse. Dette kan ikke tiltrædes. 122 Der ses ikke grundlag for at det, i modsætning til OPHL 36, stk. 1, nr. 3, skulle være tilladeligt, at anvende sådanne teknikker med hjemmel i OPHL 36, stk. 1, nr. 1, hvortil der ikke er knyttet samme strenge betingelser som i OPHL 37 bl.a. forbud mod viderespredning af den opnåede viden til tredjemand. Som nævnt må hjemlen hertil søges i OPHL 37, som netop regulerer sådan brug af programmet. Undtagelserne, i OPHL 37 og OPHL 36, stk. 1, nr. 3, er begge præceptive, jf. OPHL 37, stk. 3 hhv. OPHL 36, stk. 4, og det er derfor ikke muligt i forbindelse med licensaftaler, at afskære licenstager fra at analysere edb-programmet. 123 For fuldstændigheden skyld skal endvidere nævnes, den selvfølge, at enhver handling foretaget med hjemmel i OPHL 36-37, som det er tilfældet med de øvrige undtagelsesbestemmelser i OPHL kap. 2, kræver lovligt forlæg, jf. OPHL 11, stk. 3. Dette præciseres i OPHL 36, stk. 1 og OPHL 37, stk.1, nr. 1, hvoraf fremgår, at handlingerne kan foretages af de, som har ret til at benytte et edb-program. I OPHL 37, stk. 1, nr. 1, åbnes imidlertid op for at retten til reverse engineering, kan uddelegeres til andre end licenshaveren, jf. udtrykket eller på disses vegne af en person, der har tilladelse hertil. 124 Dette er ikke muligt i medfør af OPHL 36, stk. 1, nr Konkurrenceretten som sikkerhedsventil Hvor reverse engineering viser sig nytteløst med henblik på at opnå interoperabilitet, og hvor ophavsmandens besidder et økonomisk monopol, som vurderes at være til skade for konkurrencen, herunder innovationen, udgør konkurrenceretten en vigtig sikkerhedsventil, som supplerer de ophavsretlige undtagelser i OPHL I tilfælde hvor en dominerende stilling misbruges, er der med hjemmel i TEUF art. 102, mulighed for ex post at indskrænke eneretten ved udstedelse af tvangslicens. 125 Som følge af sag T-204/04: Microsoft mod Kommissionen, af 17. september 2007, stilles i praksis krav om, at følgende kumulative betingelser er opfyldt, førend en licensnægtelse kan karakteriseres som misbrug: Jf. Michael Plogell: Immaterialrättsliga aspekter på datorprogram, 1996 s. 45ff samt Thomas C. Vinje: The EC Software Directive and the Question of Interoperability, NIR 1/1992, s Se hertil Michael Plogell: Immaterialrättsliga aspekter på datorprogram, 1996 s Jf. også Mads Bryde Andersen: IT-retten, 2005 s Se hertil også diskussionen i afsnit 5.2, hvor der redegøres for forholdet mellem denne præceptive ret og den markedsføringsretlige beskyttelse af erhvervshemmeligheder. 124 Jf. også Mads Bryde Andersen: IT-retten, 2005 s I national dansk ret findes en tilsvarende regel i konkurrencelovens Jf. T-204/04: Microsoft mod Kommissionen, præmis sammenholdt med præmis

51 1. Licensnægtelsen vedrører et produkt eller en service, som er essentiel for at kunne udføre en given aktivitet på et afledt marked 2. Licensnægtelsen medfører, at al effektiv konkurrence, på det afledte marked, udelukkes. 3. Licensnægtelsen hindrer fremkomsten af et nyt produkt, som potentielt efterspørges af forbrugerne, eller den hindrer den tekniske udvikling til skade for forbrugerne. 4. Licensnægtelsen kan ikke begrundes objektivt. I nævnte sag vurderede Retten i Første Instans (nu Retten), at den amerikanske virksomhed, Sun Microsystems, som udviklede server-operativsystemer (det afledte marked), og som ønskede at disse kunne interagere med Microsofts desktop-operativsystem, Windows (primære marked), ikke havde praktisk mulighed for, at sikre sig den nødvendige interoperabilitets-information - hverken ved licensering eller reverse engineering. Microsoft som besad (og besidder) en dominerende stilling, på markedet for PC-operativsystemer, blev derfor dømt til at udstede licens, da ovennævnte betingelser alle var opfyldt. Licensnægtelsen blev vurderet, at hindre den tekniske udvikling på det afledte marked for serveroperativsystemer til skade for forbrugerne. 127 Microsoft s argument om at virksomhedens incitament til innovation ville blive mindsket, som følge af tvangslicensen, kunne ikke tages til følge, og udgjorde således ikke en objektiv begrundelse. 128 Sagen er et eksempel på, at de ophavsretlige undtagelser ikke altid er tilstrækkelige, til at sikre et effektivt marked, hvor der opnås balance mellem rettighedshavernes behov, for en effektiv retlig beskyttelse af investeringer i udvikling og innovation, og samfundets interesser Retsbeskyttelsens subjekt en kort bemærkning For komplekse værker, herunder edb-programmer, som er resultatet af en team-baseret udviklingsindsats, kan der opstå tvivl om, hvem der skal betragtes som ophavsmænd. Da fastlæggelsen heraf kan have stor praktisk relevans, og da der netop er afsagt en Højesteretsdom, som berører problemstillingen, knyttes, på trods af afgrænsningen i afsnit 1, en kort kommentar hertil. Ophavsmanden til et edb-program er den fysiske person, eller den gruppe af fysiske personer, der har udviklet edb-programmet, jf. edb-direktivets art. 2, stk. 1 og OPHL 1, stk Det er derimod ikke på 127 Jf. T-204/04: Microsoft mod Kommissionen, præmis Jf. T-204/04: Microsoft mod Kommissionen, præmis For en generel analyse af grænsefladen mellem immaterialret og konkurrenceret, henvises til Valentine Korah: Intellectual Property Rights and the EC Competition Rules, 2006; Richard Whish: Competition Law, 2009 s ; Dan Eklöf: Upphovsrätt i konkurrens - särskilt om artikel 82 och tvångslicensiering, 2005 og D.C Jonathan Turner: Intellectual Property Law and EU Competition Law, Edb-direktivet udelukker imidlertid ikke at ophavsmanden kan være en juridisk person såfremt medlemsstatens lovgivning tillader det, jf. art. 2, stk. 1. I Danmark er det dog fast antaget af alene fysiske personer kan betragtes som 49

52 baggrund af hverken direktivet eller loven indlysende, hvem der skal betragtes som ophavsmænd, i tilfælde hvor edb-programmet er udviklet i samarbejde mellem flere parter, hvis indsats er af forskellig karakter. Svaret på dette spørgsmål følger imidlertid af U H. Sagen vedrørte blandt andet spørgsmålet om hvorvidt ophavsretten, til edb-programmet MediBOX, tilkom fonden, Tidsskrift for Praktisk Lægegerning, eller Steen Poss (indehaver af virksomheden Poss Design). Ideen til programmet, såvel som artiklerne og det øvrige indhold, der indgik i programmet, var leveret af fonden, ligesom fonden i vidt omfang havde fremsat forslag og krav til programmets funktioner. Højesteret konkluderede, at Disse omstændigheder kan imidlertid ikke føre til, at Fonden, som ubestridt ikke har deltaget i selve programmeringsarbejdet, kan anses for ejer eller medejer af ophavsretten til edb-programmet. På denne baggrund kan nu fastslås, at alene de, der bidrager til produktion af selve kildekoden kan anses for ophavsmænd. 4 Patent på software Som nævnt, afsnit , er ophavsretten primært egnet til at beskytte mod piratkopiering, og direkte plagiering, og ikke tilfælde hvor der selvstændigt udvikles programmer baseret på samme algoritmer eller ide. Medmindre der på kodeniveau kan identificeres meget stor lighed i kodens struktur og algoritmer, vil en sådan brug, mangle den fornødne sammenhæng med originalværket til, at den kan betragtes som en ulovlig bearbejdelse. Spørgsmålet er om programudviklerne har en legitim interesse i at opnå beskyttelse af andet og mere end programkoden nemlig de ideer og metoder som udtrykker den egentlige innovation. Dette er muligt i medfør af patentretten. Ophavsretten og patentretten, er komplementære i den forstand, at ophavsretten beskytter selve programmanifestet, dvs. programkoden, der sendes som input til computerens processor, mens patentretten beskytter den program-ide, der ligger til grund for løsningen af et teknisk problem. Selvom det kræver stor dygtighed at udvikle fejlfrie, velfungerende og brugervenlige edb-programmer, er selve programkoden ikke er udtryk for innovation. Programmeringssproget udstikker nogle rammer for hvorledes maskininstruktionerne kan udformes, og når ideen først er udviklet og forarbejdet gjort, står tilbage alene en tidskrævende håndværksmæssig indsats i forbindelse med selve implementeringen. Det kan derfor synes rimeligt og velbegrundet, at programudviklerne, i tillæg til den ophavsretlige beskyttelse, har mulighed for at opnå en retsbeskyttelse, der favner edb-programmets egentlige innovation. Henset til formålet med de immaterialretlige discipliner er det afgørende om en sådan beskyttelse er nødvendig for at sikre programudviklernes incitament til forskning, udvikling og innovation, eller om den ophavsretlige beskyttelse må vurderes at levere et tilstrækkeligt værn mod free riders. ophavsmænd, jf. også ordlyden i OPHL 1, stk. 1 hvorefter Den, som frembringer et litterært eller kunstnerisk værk, har ophavsret til værket *min fremhævelse+. 50

53 4.1 Retsgrundlag Patenter har som udgangspunkt national karakter, forstået således, at både deres udstedelse (den formelle patentret), og deres virkning (den materielle patentret) er underlagt national ret i de respektive europæiske lande. I relation til den formelle patentret har patentansøger dog, som følge af den Europæiske Patent Konvention (EPC), som vedtaget i 1973, mulighed for at få udstedt patenter, af det Europæiske Patent Kontor (EPO), med gyldighed i flere lande, på baggrund af én enkelt ansøgning. 131 Det er vigtigt at bemærke, at der ikke herved opnås et supranationalt EU-patent, men et antal nationale patenter. Patentets retsvirkning, og enhver krænkelse heraf, er derfor underlagt de enkelte nationalstaters lovgivning, jf. EPC art. 64. Trods bestræbelser på at etablere et egentligt EU-patent og en fælles domstol 132, er dette endnu ikke en realitet. 133 Kritikere af software-patenter har, i relation til planerne om at etablere en patentdomstol tilknyttet EPO, udtrykt stor modstand., idet det frygtes at EPO s praksis, som anses for uhensigtsmæssig, vil blive styrket derved, at de nationale stater fratages kompetence til at tilsidesætte abstrakte og vidtrækkende patenter på software. 134 De øvrige internationale konventioner, navnlig pariserkonvention 135, den såkaldte patent cooperation treaty (PCT) 136, og TRIPS, indeholder generelle regler, som ikke specifikt har relevans i relation til spørgsmålet om hvorvidt, og under hvilke betingelser, det er muligt i Europa at opnå patent på software. De nationale regler i de enkelte europæiske lande er endvidere i overensstemmelse med EPC, og det danske forbud mod patenter på computer programmer, i PTL 1, stk. 2, nr. 3, blev da også indført med baggrund i denne konvention. Hovedfokus i det følgende vil derfor være de formelle regler for patentudstedelse, som opstilles af EPC og den praksis, der, i relation hertil, er udviklet af EPO. Selvom de nationale patentmyndigheder i princippet ikke er forpligtet til at følge samme praksis for patentudstedelse som EPO, vil denne reelt være retningsgivende for hvorledes kravene til opfindelseshøjde, nyhed og patenterbarhed bliver fortolket. Såfremt nationale patentmyndigheder afveg fra denne praksis, ville 131 EPO er en EU-uafhængig organisation som er etableret ved aftale mellem de kontraherende stater. 132 Mens der blev arbejdet på at etablere en domstol (EEUPC) tilknyttet Retten (tidligere Retten i Første Instans, men ændret som følge af Lissabon-traktaten), og med kompetence til at håndhævede kommende EU-patenter, blev der sideløbende arbejdet på et fælles judicielt system tilknyttet EPO (EPLA). Fokus synes nu at være rettet mod førstnævnte, jf. også Kommissionens kommunikation af hvor det foreslås at integrere EPLA og EEUPC. Tilgængelig på: Se nærmere herom Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s Den seneste udvikling på området kan følges på EPO s hjemmeside: samt på Kommissionens hjemmeside: Se f.eks. hjemmesiden for Foundation for a Free Information Infrastructure på: Konventionen administreres af WIPO og tæller i dag 173 lande. 136 Konventionen administreres af WIPO og tæller i dag 143 lande. For nærmere omtale af PCT-proceduren henvises endvidere til Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s. 223ff. 51

54 patentansøger blot kunne ansøge om patent direkte via EPO, for herved at blive underlagt de her gældende retningslinjer Kort om beskyttelsens indhold og varighed Såfremt betingelserne for patentering er opfyldt, udstedes en tidsbegrænset eneret til udnyttelsen af det patenterede. Et patent er gyldigt i 20 år, under forudsætning af at patenthaver betaler et årsgebyr, jf. EPC art. 63 sml. art. 86. Når eneretten ophører, kan opfindelsen frit benyttes af det øvrige samfund. Som nævnt reguleres selve retsvirkningen nationalt, jf. EPC art. 64, men der er i vidt omfang sket en harmonisering som følge af Fællesskabets Patentkonvention (FPK). 138 Indholdet af FPK art svarer til indholdet af den danske patentlovs (PTL) 3, som afgrænser enerettens indhold. Af indskrænkninger i eneretten må særligt fremhæves ikke-erhvervsmæssig brug, jf. PTL 3, stk. 3, nr. 1, samt handlinger, som udføres i forsøgsøjemed, jf. PTL 3, stk. 3, nr. 3, herunder reverse engineering. Der gælder desuden en række undtagelser vedrørende forbenyttelsesret, tvangslicens og konsumption, af begrænset relevans specifikt i relation til software. 139 Disse regler behandles ikke nærmere. I modsætning til den ophavsretlige efterligningsbeskyttelse er den patentretlige krænkelsesvurdering objektiv og enhver brug af det patenterede, i strid med eneretten, vil derfor udgøre en krænkelse, uanset kendskab til patentet. På trods af at patentretten beskytter software-programmets funktion, og ikke den specifikke implementering heraf i kildekoden, er beskyttelsesvidden normalt ikke ubegrænset. Selvom der tales om patentretten som en idebeskyttelse stilles således formelt krav om et vist detaljeniveau i relation til patentbeskrivelse og patentkrav, jf. afsnit 4.3. Det øvrige marked hindres derfor, som udgangspunkt, ikke i at opnå samme tekniske funktion, såfremt implementeringen adskiller sig tilstrækkeligt. Et patent på en given algoritme til kryptering af data favner eksempelvis ikke enhver tænkelig algoritme med tilsvarende formål. Af samme årsag vil kildekoden kunne indgå som ét blandt flere momenter i en krænkelsesvurdering. Patentretten er en prioritetsret som i det meste af verden, inkl. Europa, tilsiges den som først ansøger ( first to file ) om patent, jf. EPC art. 87. Anderledes i USA hvor patent udstedes til den, der først har gjort opfindelsen ( first to invent ), men også her arbejdes på at indføre et first to file princip, jf. et lovforslag fra 2009 om reformering af patentsystemet i USA Jf. også Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s. 212 og Mads Bryde Andersen: IT-retten, 2005 s. 477 og s /76/EEC: Convention for the European patent for the common market. 139 Det bemærkes endvidere, at der i relation til tvangslicens og forbenyttelsesret ikke er sket international harmonisering foruden de generelle retningslinjer og procedurer der fremgår af TRIPS art S. 515: patent reform act 2009, med ændringsforslag af

55 4.3 Betingelser for opnåelse af patent I modsætning til ophavsretten, som er formfri og som opstår uden videre tiltag, er patentretten bundet til en række formelle og materielle krav, som skal opfyldes førend et patent kan opnås. Herudover kræves at der betales et engangsbeløb, i forbindelse med ansøgningen, samt et årligt gebyr, såfremt patentet ønskes fornyet. Patentkontoret påser betingelserne opfyldt. Formelt stilles krav om indlevering af en ansøgning indeholdende et resume, en patentbeskrivelse, et antal patentkrav samt eventuelt tekniske tegninger, som kan bidrage til forståelsen af opfindelsen, jf. EPC art. 78. Det er patentkravene, der er afgørende for beskyttelsens omfang 141, og eventuelle krænkelser skal derfor vurderes i lyset af disse, jf. EPC art. 69, stk Af samme årsag er det patentkravene, der skal opfylde de materielle betingelser som nævnt nedenfor. Patentbeskrivelsen, og eventuelle tekniske tegninger, tjener i den forbindelse som fortolkningsbidrag. Opfindelsen skal i patentansøgningen beskrives tilstrækkeligt klart, til at en fagmand, inden for det respektive tekniske område, vil kunne udøve den, jf. EPC art. 83. Dette er nødvendigt når EPO skal vurdere om opfindelsen opfylder de materielle betingelser. Kravet skal endvidere ses i lyset af, at patentansøgningen efterfølgende offentliggøres således, at den brede offentlighed vil kunne lade sig inspirere af den innovative viden, og udnytte opfindelsen når patentet udløber. Det bemærkes, at der ikke herved sker offentliggørelse af software-programmets kildekode, da denne hverken er nødvendig, eller tilstrækkelig, til at beskrive opfindelsen ifølge EPO s retningslinjer. Det anføres således i retningslinjerne at patentbeskrivelsen skal skrives i almindeligt sprog, og således at the invention may be understood by a person skilled in the art who is deemed not to be a specialist in any specific programming language, but does have general programming skills Patentretten stiller således ikke krav om offentliggørelse af et eksemplar af opfindelsen, men blot en tilstrækkelig klar beskrivelse heraf. 144 Beskrivelse af implementeringsdetaljer på kodeniveau ville da heller ikke bidrage med hverken vidensspredning, bedre databaser over det allerede kendte, eller øge patentbeskrivelsens værdi som fortolkningsbidrag i forhold til patentkravene. Som nævnt har koden ikke isoleret set opfindelseshøjde, og det vil endvidere være svært at udskille de dele af koden, der resulterer i den effekt, som udgør 141 Det bemærkes at ækvivalenslæren medfører at ubetydelige afvigelser fra patentkravene ikke bringer forholdet uden for beskyttelsen. Se nærmere Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s Generelt vil ansøgeren derfor søge at formulere så brede krav så muligt. Det bemærkes at patentkravene ikke knytter sig til nogen specifik kode, men mod den mere overordnede løsning på et teknisk problem. Softwaren udgør en implementering af opfindelsen, og det er opfindelsen som patentkravene retter sig mod. En ændring af patentsystemet med henblik på at begrænse beskyttelsen til den specifikke implementering i kode vil være meningsløst, idet koden jo allerede er beskyttet af ophavsretten. 143 Jf. EPO: Guidelines for Examination in the European Patent Office, 2010, Part C, Chapter 2, Section Et af formålene med at tillade patentering før den endelige implementering har fundet sted er at sikre andre tidlig indsigt i opfindelsen, og modvirke at flere uafhængigt af hinanden investerer resurser i udviklingen af samme opfindelsen. Som nævnt i afsnit 4.4 kan der imidlertid sættes spørgsmålstegn ved værdien af den offentliggørelse der finder sted i relation til software-opfindelser. 53

56 opfindelsen. Når blot virkemåden er beskrevet er den specifikke kode hverken nødvendig for at udøve opfindelsen eller for at forstå dennes funktion. 145 Det faktum at software-produkters effekt, som nævnt, kan opnås på baggrund af et næsten ubegrænset antal implementeringer i kode, bevirker desuden at koden ikke er egnet til at indgå i en søgbar database over det allerede kendte. Materielt stilles krav om at opfindelsen er ny, at den har opfindelseshøjde ( inventive step ), og at den er industriel anvendelig, jf. EPC art. 52, stk. 1. I modsætning til ophavsretten, hvor der alene stilles et subjektivt nyhedskrav, opererer patentretten med et objektivt globalt nyhedskrav, jf. EPC art. 54, stk Ved vurderingen af om opfindelsen er ny, skal tages hensyn til alt, hvad der er offentligt tilgængeligt på ansøgningstidspunktet. Viden som tilgængeliggøres, som følge af mundtlige eller skriftlige beskrivelser 146, ved brug, eller på anden måde, og uanset hvor i verden denne tilgængeliggørelse finder sted, vil derfor potentielt være nyhedsskadelig. Offentliggøres opfindelsen som følge af et oplagt misbrug i forhold til patentansøgeren, f.eks. som følge af brud på reglerne om erhvervshemmeligheder, anses denne tilgængeliggørelse dog ikke for nyhedsskadelig, jf. EPC art. 55, stk. 1, litra a. 147 Ønsker en opfinder ikke at udtage patent, men blot at hindre andre heri, kan den pågældende, som naturlig konsekvens af nyhedskravet, vælge at offentliggøre en beskrivelse af opfindelsen for herved at fratage denne sin nyhedsværdi - såkaldt patentprofylakse. Kravet om opfindelseshøjde har nær sammenhæng med nyhedsvurderingen, da det afgørende er en vurdering af om opfindelsen, set i lyset af det allerede kendte, er indlysende for en fagmand, jf. EPC art er dette tilfældet udstedes ikke patent. Der kræves med andre ord at opfindelsen adskiller sig væsentligt fra det allerede kendte. Se hertil nærmere afsnit Kravet om at patentet skal være industrielt anvendeligt vil kun sjældent give anledning til overvejelser når henses til den brede definition i EPC art Ifølge bestemmelsen kræves blot at opfindelsen can be made or used in any kind of industry, og for så vidt angår software relaterede opfindelser vil det næsten 145 Jf. også Kenneth Canfield: The disclosure of source code in software patents should software patents be open source, i The Columbia Science and Technology Law Review, Vol. 7, 2006 s (særligt s. 3-5 samt s. 9). Det kan dog undre at forfatteren på trods heraf når den konklusion (s. 18ff), at offentliggørelse af kildekode kan være gavnligt, idet markedet for software er præget af sekventiel innovation, og fordi adgang til koden gør det lettere at opnå interoperabilitet. Det foreslås desuden, at man til gengæld for patentbeskyttelsen bør opgive sin ophavsret så andre frit kan anvende koden. Dette kan ikke tiltrædes allerede fordi ophavsretten har et ganske andet fokus, nemlig den konkrete manifestation af ideen. 146 Herunder hører også allerede offentliggjorte patentansøgninger og europæiske patentansøgninger som er indleveret forinden det pågældende patent, og som offentliggøres samtidig eller efterfølgende, jf. EPC art. 54, stk. 3. For nærmere information om prioritetskonflikter mellem flere ansøgninger henvises til EPO: Guidelines for Examination in the European Patent Office, 2010, Part C, Chapter Hertil kræves, ifølge en afgørelse fra EPO s appelkammer i T 585/92, OJ 3/1996, 129, at den som offentliggør opfindelsen havde til hensigt, eller burde have indset, at offentliggørelsen ville skade patentansøgeren. 148 Jf. også EPO: Guidelines for Examination in the European Patent Office, 2010, Part C, Chapter 2, Section

57 undtagelsesvist følge implicit, af selve opfindelsens karakter, at dette krav om praktisk anvendelighed er opfyldt. 149 Det bemærkes hertil, at begrebet industri skal fortolkes bredt, som omfattende alle former for erhvervsaktivitet, jf. også ordene any kind. Kravet begrænser derfor ikke opfindere i at få patent på opfindelser, hvis anvendelse knytter sig til andet end den traditionelle industrisektor. Foruden ovennævnte betingelser, som fremgår eksplicit af EPC, følger det af EPO s praksis, at udstedelse af patent, forudsætter at nyskabelsen har teknisk karakter og udgør et teknisk bidrag til det allerede kendte, jf. eksempelvis T931/95 (PBS) 150, hvor visse krav havde teknisk karakter, men hvor patent på en forretningsmetode blev afvist under henvisning til at patentkravene ikke medførte et teknisk bidrag. 151 I det følgende afsnit analyseres praksis med henblik på nærmere, at fastlægge begrebernes indhold Hvornår har software teknisk karakter og hvornår ydes et teknisk bidrag? I relation til software har særlig spørgsmålet om hvornår der foreligger en opfindelse, jf. EPC art. 52, stk. 1, og kravet om dennes tekniske karakter, givet anledning til spørgsmål. Det fremgår af den ikke udtømmende liste i EPC art. 52, stk. 2, blandt andet, at matematiske metoder (litra a), forretningsmetoder og software (litra c), ikke er at betragte som opfindelser. 152 EPC art. 52, stk. 2 skal imidlertid læses i sammenhæng med EPC art. 52, stk. 3, hvoraf fremgår at de nævnte fænomener alene er undtaget fra patentering, såfremt patentansøgningen relates to such subject-matter or activities as such [min fremhævelse]. Netop udtrykket as such har dannet grundlag for EPO s nuværende tilgang hvorefter software, ikke per se er udelukket fra patentering, såfremt patentkravene har teknisk karakter. 153 Et software-program vil, når det afvikles, nødvendigvis medføre en teknisk effekt, eksempelvis ved, at der vises skærmbilleder eller gemmes data i hukommelsen. Såfremt bestemmelsen i EPC art. 52, stk. 2 skal give mening, må derfor indføres en sondring, der er egnet til at adskille software som har den påkrævede tekniske karakter, og som derfor er patenterbar i medfør af EPC art. 52, stk. 1, fra software as such, der ikke kan patenteres, jf. EPC art. 52, stk Som eksempel på tilfælde hvor det kan være nødvendigt eksplicit at angive opfindelsens industrielle anvendelighed nævnes i EPO s retsningslinjer visse bioteknologiske opfindelser, som f.eks. sekvensering af gener, og opfindelser der relaterer sig til testmetoder, hvor opfindelsens industrielle anvendelighed ikke fremgår umiddelbart. Se EPO: Guidelines for Examination in the European Patent Office, 2010, Part C, Chapter 2, Section T 931/95, Pension Benefit Systems (OJ 2001, 441). 151 Kravet om at teknisk karakter og teknisk bidrag støttes på en fortolkning af begrebet opfindelse i art. 52, stk Det bemærkes at skillelinjen mellem egentlige software opfindelser, matematiske algoritmer og forretningsmetoder ikke er skarp. Dette skyldes, at forretningsmetoder og matematiske algoritmer ofte implementeres i software, og derfor udgør en del af software-produktet. 153 Fortolkningen underbygges ifølge EPO af EPC art. 52, stk. 2, hvoraf fremgår at: European patents shall be granted for any inventions, in all fields of technology og TRIPS art. 27: patents shall be available for any inventions, whether products or processes, in all fields of technology. 55

58 Det bemærkes at EPO benytter udtrykket computer implemented invention (CII) og ikke software. Begrebet CII dækker, ifølge EPO s retningslinjer, claims which involve computers, computer networks or other programmable apparatus whereby prima facie one or more of the features of the claimed invention are realised by means of a program or programs. 154 Da det herved står klart, at nyhed og opfindelseshøjde opnås som følge af software, ses der ikke grundlag for at indføre en sondring mellem de to begreber. Det må blot erindres, at begrebet CII ikke alene dækker patenter på selve software-produktet (ofte betegnet pure software ), men tillige patenter på en software-styret proces, eller selve maskinen der udfører processen. 155 Hvilken type 156 krav patentet involverer, har stor betydning, idet patentkrav, rettet mod en proces eller et system, ikke kan benyttes til at hindre produktion og distribution af selve softwaren, der udfører processen. 157 Først når softwaren afvikles (så den patenterede proces udføres) eller installeres på en computer (så systemet opnår egenskaber som angivet i patentkravene), vil sådanne krav kunne føre til en patentretlig krænkelse. Patenteres derimod selve software-programmet som et produkt, vil beskyttelsen række videre derved, at enhver produktion/distribution af et program, med tilsvarende egenskaber, vil kunne hindres. Det har længe været muligt, at få godkendt patentkrav rettet mod en software-styret proces, eller det system, der udfører processen, jf. f.eks. T208/84 (VICOM) samt T26/86 (Koch & Sterzel). 158 Sådanne tekniske processer og systemer blev betragtet som opfindelser omfattet af EPC art. 52, stk. 1, såfremt deres tekniske bidrag til det allerede kendte ikke befandt sig indenfor et område som nævnt i art. 52, stk. 2. I sag T208/84 (VICOM) blev anført, at sådanne opfindelser should not be excluded from protection by the mere fact that for its implementation modern technical means in the form of a computer program are used, og Decisive is what technical contribution the invention makes to the known art.. Denne vurderingsnorm blev kendt som the technical contribution approach. Sagerne T1173/97 (IBM) og mere specifikt, T931/95 (PBS) og T258/03 (Hitachi), medførte dog at denne tilgang blev forladt, jf. nærmere nedenfor. Herved blev dog ikke ændret på, at sådanne processer og systemer stadig er patenterbare i samme omfang som tidligere. 154 Jf. EPO: Guidelines for Examination in the European Patent Office, 2010, Part C, Chapter 4, Section Ofte ses en kombination af nævnte typer af patentkrav, f.eks. en maskine bestående af *egenskaber+ til udførelse af en proces bestående af *egenskaber Overordnet sondres mellem krav på en fysisk enhed (produkt, apparat) og krav på en aktivitet (proces, brug), jf. EPO: Guidelines for Examination in the European Patent Office, 2010, Part C, Chapter 3, Section Jf. også Holm Schwarze: Computer-Implemented inventions in Denmark and Europe, i NIR 6/2008, s T208/84, Vicom (OJ 1987, 14) samt T208/84, Koch & Sterzel (OJ 1988, 19). 56

59 Muligheden for at patentere selve softwaren, som et produkt, blev først muligt senere. De skelsættende afgørelser i den henseende er sagerne T1173/97 (IBM) og T935/97 (IBM). 159 EPO s appelkammer (BOA) anførte i T1173/97 (IBM), at et computer-program ikke var undtaget fra patentering i medfør af EPC. art. 52, stk. 2, såfremt det havde teknisk karakter, og at dette var tilfældet if, when it is run on a computer, it produces a further technical effect which goes beyond the "normal" physical interactions between program (software) and computer (hardware) *min fremhævelse Det var herefter muligt at opnå patent på selve programmet, og ikke alene processen, der blev udført når programmet blev afviklet - afgørende var programmets potentiale til at udvirke en further technical effect. En sådan teknisk effekt kan være ekstern i forhold til selve computeren, f.eks. bedre kontrol af en robotarm, eller intern, f.eks. en mere effektiv anvendelse af en computers resurser. 161 Som det fremgår af T928/03 (Konami), se afsnit , er simple praktiske konsekvenser, som f.eks. en bedre brugeroplevelse, endvidere tilstrækkeligt. Begrebet må derfor vurderes at være uden egentligt indhold, idet det blot fastslås, at den blotte afvikling af et program ikke er tilstrækkeligt til at opnå patent. Foruden at udvide opfindelsesbegrebet, blev med IBM-sagerne taget første skridt væk fra ovennævnte technical contribution -tilgang. Afgørende, for om der var tale om en opfindelse, jf. art. 52, stk. 1, var nu en vurdering af dennes tekniske karakter - uden skelen til dens tekniske bidrag. 162 BOA fremhævede således i T1173/97 (IBM) at determining the technical contribution an invention achieves with respect to the prior art is more appropriate for the purpose of examining novelty and inventive step than for deciding on possible exclusion under article 52(2) and (3). Med baggrund i sagerne T931/95 (PBS) og T258/03 (Hitachi) skete imidlertid endnu en udvikling. 163 I overensstemmelse med T1173/97 (IBM) blev anført, at der ikke var grundlag for at sondre mellem opfindelsens nye egenskaber, og allerede kendte egenskaber, ved vurderingen af opfindelsers patenterbarhed, jf. EPC art. 52, stk. 2-3 denne sondring henhørte ifølge BOA til vurderingen af opfindelseshøjde. Videre blev anført at krav, som retter sig mod et apparat, eller en proces/metode som involverer brug af technical means, f.eks. en computer, per definition må anses for en opfindelse i medfør af art. 52, stk. 1. I relation til krav, der retter sig direkte mod software, som et 159 Sag T1173/97, IBM (OJ 1999, 609) samt sag T935/97, IBM (ikke publiceret). Sagerne førte til en ændring af EPO s retningslinjer hvor det, indtil 1998, fremgik at a computer program claimed by itself or as a record on a carrier [f.eks. en DVD], is not patentable irrespective of its contents *min tilføjelse+. Som nævnt var det tidligere kun mulighed for at patentere en proces eller et system, og ikke programmet som sådan. 160 Begrebet further technical effect blev forsøgt kodificeret i forslag til direktiv om patentering af software implementede opfindelser, COM(2002) 92 final. Direktivet blev afvist af Europa-Parlamentet i Jf. EPO: Guidelines for Examination in the European Patent Office, 2010, Part C, Chapter 4, Section Jf. også udtalelse af 12. maj 2010, fra EPO s udvidede appelkammer, i sag G3/08, pkt T931/95, Pension Benefit Systems (OJ 2001, 441) samt 258/03, Hitachi (OJ 2004, 575). Afgørelserne gennemgås nærmere af Holm Schwarze: Computer-Implemented inventions in Denmark and Europe, i NIR 6/2008, s

60 produkt, blev endelig fastslået i sag T424/03 (Microsoft) 164, at det blotte faktum, at der i patentkravene nævnes en computer eller et fysisk lagringsmedie (DVD er, CD er, Harddiske mv.), er tilstrækkeligt til at anse opfindelsen som helhed for værende af teknisk karakter. Det er således ikke længere nødvendigt (men stadig tilstrækkeligt), at identificere en further technical effect for at software er omfattet af EPC art. 51, stk. 1. En sådan effekt indgår derimod ved vurderingen af opfindelseshøjde, herunder teknisk bidrag, idet kun egenskaber med teknisk karakter kan indgå i denne vurdering, jf. afsnit Det må på baggrund af ovenstående konkluderes, at 1) det er muligt at opnå patent på software i Europa 2) og at kravet om teknisk karakter næsten undtagelsesvist vil være opfyldt, idet enhver eksplicit benævnelse af en teknisk frembringelse i patentkravene rækker til. 165 Software implementerede opfindelser, uanset typen af patentkrav, vil således kunne omfattes af art. 52, stk. 1. Betydningen heraf er, at vurderingen af opfindelsens tekniske bidrag nu foretages særskilt, og at udelukkelse, af de i art. 52, stk. 2 nævnte emner, må ske i den forbindelse Nærmere om vurderingen af opfindelseshøjde, herunder teknisk bidrag Som følge af de lempelige krav til opfindelsers tekniske karakter, vil patentkrav, hvor flertallet af de nævnte egenskaber er ikke-tekniske, kunne betragtes som en opfindelse i medfør af art. 52, stk. 1. Disse ikketekniske egenskaber kan dog som udgangspunkt ikke indgå i vurderingen af nyhed og opfindelseshøjde, jf. f.eks. T154/04 (Duns licensing) 166, idet de ikke medfører et teknisk bidrag. 167 Denne tilgang støttes på en fortolkning af EPC art. 52, stk. 2, som er karakteriseret ved at opliste ikke tekniske egenskaber, og som derfor menes at udelukke disse fra, at indgå i vurderingen af opfindelsens tekniske bidrag. Som tekniske egenskaber betragtes de, der bidrager til opfindelsens tekniske karakter. 168 Disse kan f.eks. relatere sig til kontrol af en fysisk enhed eller proces, en metode til udvælgelse/komprimering/kryptering af data, til sikker login, til bedre udnyttelse af resurser i en computer, til streaming af video mv. 169 Som udgangspunkt vurderes patentansøgninger, på denne baggrund, ved brug af den såkaldte problem and solution -tilgang. Denne indebærer kort fortalt 1) identifikation af det allerede kendte som har flest egenskaber til fælles med opfindelsen, 2) formulering af et objektivt teknisk problem som søges løst, 164 T424/03, Microsoft (ikke publiceret). 165 Jf. også udtalelse af 12. maj 2010, fra EPO s udvidede appelkammer, i sag G3/08, pkt samt pkt T154/04, Duns Licensing (OJ 2004, 575), pkt Sagen er velegnet til at illustrere gældende ret, idet den opsummerer tidligere retspraksis, og udtrykker en tilgang som er i overensstemmelse med EPO s nuværende retningslinjer. Sagen tages endvidere til udtryk for gældende ret af EPO s udvidede appelkammer se udtalelse af 12. maj 2010, fra EPO s udvidede appelkammer, i sag G3/08, pkt T154/04, Duns Licensing (OJ 2004, 575), pkt. 5(E). 169 I relation til patentkrav, der retter sig mod software, kan som tidligere nævnt kun indgå de egenskaber der indebærer en further technical effect, hvorved forstås at den tekniske effekt, der resulterer som følge af den blotte afvikling af programmet, ikke indgår i vurderingen af opfindelseshøjde. 58

61 baseret på forskelle til det allerede kendte, og 3) en vurdering af om opfindelsens tekniske bidrag (dvs. løsningen på det tekniske problem) er indlysende for en fagmand, indenfor det tekniske område som opfindelsen vedrører. 170 Implementeres eksempelvis en ny forretningsmetode ved brug af kendt teknik, vil den sagkyndige computerspecialist derfor i teorien nå den konklusion, at opfindelsen ikke udgør et teknisk bidrag til det allerede kendte, allerede fordi der ikke kan formuleres et teknisk problem som søges løst. 171 Undtagelsesvist kan dog inddrages ikke-tekniske egenskaber i vurderingen af opfindelseshøjde, såfremt disse bidrager til opfindelsens tekniske effekt, og herved løsningen af et teknisk problem. I sagen T154/04 (Duns licensing) fremgår således, at: a non-technical feature may interact with technical elements so as to produce a technical effect, e.g. by its application for the technical solution of a technical problem If this is true then to the extent it contributes to the technical effect it must count as a contribution to the technical character. 172 Som eksempel hvor dette var relevant kan nævnes T928/03 (Konami) 173. Sagen vedrørte en visuel indikator i et computerspil (fodboldspil), som havde til formål, at gøre brugeren opmærksom på boldens placering. BOA betragtede selve indikatoren, og nåede den konklusion, at der ved brug af denne blev opnået en bedre interaktion mellem bruger og maskine, hvorfor der var tale om en egenskab der bidragede til opfindelsens tekniske karakter. Indikatoren kunne derfor indgå i vurderingen af opfindelseshøjde. Hermed indikeres en meget liberal tilgang, hvor selv opfindelser, der i traditionel forstand ikke er tekniske, kan patenteres afgørende er alene, at der kan identificeres en praktisk effekt, som følge af bedre interaktion med hardwaren. Hermed vil kunne argumenteres for at grafiske faneblade, menusystemer mv., udgør tekniske bidrag, da sådanne elementer i visse tilfælde forbedrer interaktionen mellem maskine og menneske. 174 På denne baggrund må vurderes, at der ikke resterer meget af undtagelsen i art. 52, stk. 2, litra c, når bortses fra computerimplementerede forretningsmetoder, som implementeres ved brug af kendt teknik. 175 Såfremt patentkravene er formuleret så de øjensynliggør en teknisk effekt, der har til formål at løse et 170 Se nærmere EPO: Guidelines for Examination in the European Patent Office, 2010, Part C, Chapter 4, Section Som praktisk eksempel på denne fremgangsmåde kan henvises til T154/04, Duns Licensing (OJ 2004, 575), hvor patentkravene ikke vedrørte løsningen på et teknisk problem, men en forretningsmetode. Samme var tilfældet i T931/95, Pension Benefit Systems (OJ 2001, 441). I 258/03, Hitachi (OJ 2004, 575), blev derimod identificeret et teknisk problem (implementering af forretningsmetode), men løsningen udgjorde ikke noget teknisk bidrag. 172 T154/04, Duns Licensing (OJ 2004, 575), pkt T928/03, Konami (ikke publiceret). 174 Se også sag T 49/04,Text processor/walker (ikke publiceret), hvor en metode til visning af tekst på skærmen blev anset for at udgøre et teknisk bidrag. 175 I bilag 1 vises en grafisk illustration over fremgangsmåden som gennemgået i afsnit samt Der henvises endvidere til T154/04, Duns Licensing (OJ 2004, 575), pkt. 5, hvor den aktuelle retstilstand opsummeres. Den fremgangsmåde, der her beskrives, er i overensstemmelse med EPO s nuværende retningslinjer, og anses endvidere for gældende ret af EPO s udvidede appelkammer se udtalelse af 12. maj 2010, fra EPO s udvidede appelkammer, i sag G3/08, pkt

62 teknisk problem, på en nyskabende, mere effektiv eller mere brugervenlig måde, er der reelt adgang til patentering af software as such. Matematiske algoritmer, som indgår i programmet, og medvirker til løsningen, vil ligeledes kunne patenteres, i kraft af deres konkrete implementering, og på trods undtagelsen i EPC art. 52, stk. 2, litra a). Hidtil har man antaget 176, at amerikansk praksis er væsentlig mere liberal end den europæiske, hvilket skyldes den amerikanske afgørelse i state street -sagen, som i 1998 fjernede enhver reel begrænsning i relation til patentering af software og forretningsmetoder. 177 Med den nyligt afsagte afgørelse i Bilskysagen er amerikansk praksis dog formentlig skærpet. 178 Sagens konsekvenser står endnu ikke klar, men Højesteret synes at indikere, at den såkaldte machine and transformation -test 179 som udgangspunkt bør benyttes til at afgøre om en fremgangsmåde er patenterbar. 180 Herved kunne noget tyde på at amerikansk og europæisk praksis er ved at nærme sig hinanden. 4.4 Samfundsøkonomiske overvejelser Selvom det innovative element, i nye produkter og processer, ofte vil hidrøre fra software, evt. i kombination med ny hardware, må det vurderes at udstedelse af patenter, i mange tilfælde, ikke vil fremme innovation tværtimod. mere idebunden og abstrakt. 181 Software adskiller sig væsentlig fra anden teknik, idet innovationen er Som allerede nævnt er kendskab til selve implementeringen, dvs. kildekoden, ikke nødvendig for at udøve opfindelsen, og patentkravene vil derfor nødvendigvis specificere den overordnede virkemåde og effekt. Software knytter sig ikke til nogen fysisk manifestation af ideen, som kan medvirke til at begrænse beskyttelsens omfang. Ofte vil det øvrige marked derfor være afskåret fra at løse sammen problem ved brug af anden løsning (implementering). Det høje abstraktionsniveau medfører desuden, at patentets værdi, som middel til vidensspredning, typisk vil være begrænset. 176 Se f.eks. Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s State Street Bank & Trust CO. v Signature Financial Group, INC 149 F.3d 1368 (Fed. Cir. 1998). Afgørende for patentering var alene om en algoritme medførte a useful, concrete and tangible result. 178 Bilski v. Kappos (No ) afsagt 28. juni 2010 af den amerikanske Højesteret. 179 Testen indebærer en vurdering af om den fremgangsmåde, hvorpå der søges patent, knytter sig til specifik maskine eller omformer et element into a different state or thing. Er dette tilfælde er der tale om en patenterbar opfindelse. 180 Sagen vedrørte et afvist patent på en forretningsmetode, men vil tillige kunne have indflydelse på patenteringen af software, idet machine and transformation -testen er generelt anvendelig. Da sagen vedrørte patent på en fremgangsmåde kan dog ifølge iagttagere ikke siges med sikkerhed om afgørelsen tillige berører patentering af software som produkt. 181 Jf. også Bessen & Michael J. Meuer: Patent failure How Judges, Bureaucrats, and Lawyers Put Innovators at Risk, 2008, s Se også Jan. A Bergstra et al.: About trivial software patents The ISNot case, i Science of Computer Programming, 2007 s. 275, hvor det udtrykkes at: In the case of software, the logical structures described by the source code are the end point of human invention: the step to their physical realization is fully automated. 60

63 Softwares abstrakte og komplekse natur besværliggør endvidere patentkontorernes arbejde med at vurdere det reelle indhold af patentkravene, og herved om kravet om nyhed/opfindelseshøjde er opfyldt. Det faktum, at samme opfindelse kan beskrives på adskillige måder, bevirker desuden at tidligere patentansøgninger, indenfor samme område, ikke let lader sig anvende som sammenligningsgrundlag, når nævnte krav skal vurderes. Det er med andre ord svært at etablere søgbare databaser over det allerede kendte. Hertil kommer at vurderingen af nyhed og opfindelseshøjde besværliggøres af, at software- opfindelser ikke publiceres i videnskabelige tidsskrifter ol. Da software ofte udgives som closed source, skabes endelig den risiko at patentansøgningen dækker allerede kendt viden, som blot ikke er offentlig tilgængelig, og af samme årsag vil sådan viden ikke kunne danne grundlag for en sag om administrativ omprøvning, jf. EPC art Disse problemer vil uundgåeligt resultere i udstedelse af trivielle patenter, som dækker allerede kendt viden. 182 De problemer, og den usikkerhed, der er forbundet med at identificere patenter, dækkende en specifik teknologi, og vurdere deres reelle indhold, påvirker ikke kun patentkontorerne. Det høje abstraktionsniveau gør det tillige svært for de øvrige markedsaktører, at vurdere om de krænker et givent patent. 183 Da et software-produkt potentielt kan krænke adskillige patenter, kræver det desuden betydelige resurser alene at identificere de patenter, der skal tages højde for. 184 Specielt for mindre virksomheder vil de betydelige omkostninger, der er forbundet med en sådan forundersøgelse, samt udsigten til retssager, kunne mindske incitamentet til at investere i R&D. Antallet af patenter, der potentielt kan favne et enkelt software-produkt bevirker desuden, at det kan være meget omkostningstungt, at erhverve de nødvendige licenser (såkaldt royalty stacking ). 185 Endelig må nævnes, at det for mindre virksomheder sjældent vil være aktuelt at udnytte patentsystemet, idet udtagelse af patenter, og den efterfølgende håndhævelse, kræver mange ressourcer. 186 Problemet med abstrakte patenter forværres af, at markedet for teknologi, herunder software, er kendetegnet ved sekventiel innovation. 187 Anvendelsen af en given funktionalitet kan være nødvendig for en helt række software produkter beslægtede som ubeslægtede og ofte bygges således videre på 182 Disse problemer fremhæves også af Jan. A Bergstra et al.: About trivial software patents The ISNot case, i Science of Computer Programming, 2007 s samt s Jf. også Andreas Groche: Software Patents Boon or Bane for Europe?, 2006 s Det estimeres at EPO i 2008 havde udsted ca patenter på computer implementerede opfindelser, jf. Jens Schovsbo & Morten Rosenmeier: Immaterialret, 2008 s Jf. EPO: Scenarios for the future, 2007 s Om problemerne i relation til mindre virksomheder, se EPO: Scenarios for the future, 2007 s Jf. også James Bessen & Eric Maskin: Sequential Innovation, Patents, and Imitation, i RAND Journal of Economics, 2009 s (særligt s. 612), samt Kenneth Canfield: The disclosure of source code in software patents should software patents be open source, i The Columbia Science and Technology Law Review, 2006, s

64 tidligere ideer. I modsætning til f.eks. en papirklips, eller en isterningepose, er software ikke på samme vis afgrænset i sin anvendelse. Foruden at udvide beskyttelsens omfang bevirker dette, at patentkontorernes mulighed for at vurdere patentansøgninger, såvel som virksomheders mulighed for, at danne sig et overblik over hvilke patenter, der potentielt krænkes, vanskeliggøres yderligere. Ovenstående giver grund til eftertanke for så vidt angår effekten på innovation og konkurrence på markedet. Såfremt muligheden for at patentere software implementerede opfindelser skal bevares, bør man forlade det one size fits all system, som patentretten bygger på, og tilpasse beskyttelsens varighed til markedet for teknologi og software - 20 år er lang tid på et marked, som er præget af sekventiel innovation og hastig udvikling. Man bør endvidere overveje, at erstatte forbudsretten med en vederlagsret, således at patenthaver ikke kan hindre selvstændig innovation, men alene kræve et rimeligt vederlag for udnyttelsen af det patenterede. 188 Selvom det ikke kan udelukkes, at patentretten i visse tilfælde kan tilskynde til software-innovation, og virke som instrument til opnåelse af venture kapital 189, må det vurderes at ulemper ved det nuværende system overstiger fordelene, og at samfundet som helhed ikke har gavn heraf. 190 Empiriske undersøgelser peger da også på, at patentsystemet virker bedst inden for kemikalie- og lægemiddel-industrien, hvor det er muligt præcist at definere beskyttelsens grænser (f.eks. en bestemt molekyle-sammensætning). 191 I modsætning hertil er der særligt problemer i forbindelse med bioteknologi, software og forretningsmetoder, hvor patenterne i mange tilfælde er abstrakte og vidtfavnende. Ophavsretten, beskyttelsen af erhvervshemmeligheder samt den fordel, der består i at komme først på markedet ( first mover advantage ), må vurderes i de fleste tilfælde, at tilbyde tilstrækkeligt med incitament til udvikling af nye software-produkter. 188 Samme foreslås som et muligt scenarie i EPO: Scenarios for the future, 2007 s. 23 og s Jf. Browyn H. Hall: The Use and Value of IP Rights, Prepared for the UK IP Ministerial Forum on the Economic Value of Intellectual Property, 2009 s samt John R. Allison et al.: Software Patents, Incumbents and Entry, i Texas Law Review, 2007 s Patenter benyttes i dag ikke alene som middel til at beskytte investeringer i R&D. Ofte udtages patent alene for at opstille markedsbarrierer for konkurrenter, som forhandlings/pressions-middel, som middel til at forebygge retssager om patentkrænkelser eller for at tiltrække kapital. Se EPO: Scenarios for the future, 2007 s.35 samt Browyn H. Hall: The Use and Value of IP Rights, Prepared for the UK IP Ministerial Forum on the Economic Value of Intellectual Property, 2009 s Se James Bessen & Michael J. Meuer: Patent failure How Judges, Bureaucrats, and Lawyers Put Innovators at Risk, 2008, s. 152 ff. 62

65 5 Software som erhvervshemmelighed 5.1 Beskyttelsens indhold og objekt Den retlige beskyttelse af erhvervshemmeligheder er ikke en egentlig immaterialretlig disciplin, men den er et vigtigt alternativ/supplement til ophavsretten og patentretten. Beskyttelsen af sådanne hemmeligheder har stor betydning, idet den omfatter informationer som ikke beskyttes af ophavsretten, ligesom den kan udgøre et alternativ til patentbeskyttelse. Dette samspil mellem ophavsretten, patentretten og beskyttelsen af erhvervshemmelighed giver derfor anledning til at analysere de tilfælde, hvor regelsættene overlapper eller supplerer hinanden. Af forretningsmæssige hensyn holdes en lang række informationer ofte hemmelige for offentligheden. Både det forberedende arbejde som ligger til grund for udviklingen af software og selve kildekoden 192, udgør typisk erhvervshemmeligheder, der foruden den ophavsretlige beskyttelse, tillige opnår beskyttelse efter markedsføringslovens (MFL) 19. Hertil kommer at informationer om et programs grænseflader, protokoller, algoritmer, fremtidige udviklingsplaner, sikkerhedsbrister mv., som udgangspunkt vil være beskyttet som erhvervshemmelighed. Beskyttelsen opnås alene i de tilfælde hvor den pågældende information kan siges at udgøre en erhvervshemmelighed - se dog MFL 19, stk. 4 som omtalt nedenfor. Loven definerer ikke begrebet erhvervshemmelighed, men med baggrund i praksis kan det udledes, at udtrykket dækker over information om en virksomheds interne forhold, som er egnet til potentielt at påvirke dens markedsmæssige position, såfremt den kommer til offentlighedens kundskab. 193 Heri ligger, at der fra virksomhedens side skal være foretaget visse bestræbelser på at holde den pågældende information hemmelig for den brede omverden, f.eks. ved indgåelse af hemmeligholdelsesklausuler, men det kan tillige følge implicit af oplysningernes karakter at de er hemmelige. 194 Der stilles ikke krav om, at informationerne er eksklusive, nye eller at de er afstedkommet som følge af en væsentlig investering. Afgørende er alene, at de ikke er alment kendte/tilgængelige og at de er følsomme i den forstand, at de vil kunne benyttes af eksempelvis konkurrenter til skade for virksomheden. Elementer, der er offentliggjorte, og/eller som ikke har en sådan informativ karakter, at de kan anses for følsomme i den ovenfor nævnte forstand, beskyttes selvsagt ikke som erhvervshemmeligheder. 192 Modsat dog ved open source -udgivelser hvor kildekoden gøres tilgængelig for almenheden, dog typisk ved accept af visse licensbetingelser som indeholdt i eksempelvis den meget udbredte General Public License (GPL). 193 Jf. også Erling Borcher & Frank Bøggild: Markedsføringsloven, 2006 s Jf. også Erling Borcher & Frank Bøggild: Markedsføringsloven, 2006 s. 427, og Mads Bryde Andersen: IT-retten, 2005 s

66 MFL 19, stk. 1-2 omfatter personer der er i tjeneste eller samarbejdsforhold til en virksomhed eller udfører et hverv for denne. 195 MFL 19, stk. 3 udvider herefter denne personkreds til også at omfatte andre personer, der har lovlig adgang til virksomheden så som sælgere, besøgende eller personer der på vegne af det offentlige, f.eks. SKAT, er på kontrolbesøg. Ved adgang forstås ikke alene tilfælde hvor den pågældende har adgang til virksomhedens fysiske lokalitet, men også tilfælde hvor der, ved brug af kodeord, opnås fjernadgang til virksomhedens IT-systemer gennem internettet. 196 Bestemmelsen finder, som det fremgår, kun anvendelse såfremt der er tale om personer, der har lovlig adgang til virksomheden. I tilfælde hvor tredjemand, f.eks. konkurrenter, ved uretmæssig adgang til virksomheden søger at skaffe sig adgang til hemmeligholdt viden om software, eksempelvis ved indbrud i virksomhedens lokaler eller hacking af virksomhedens computersystemer, omfattes forholdet ikke af MFL 19, men derimod af straffelovens bestemmelser om industrispionage (STRFL 264, stk. 2 eller 263, stk. 3) og, efter omstændighederne, tyveri (STRFL 276). MFL 19 medfører et civil- (MFL 20, stk. 2-4) og strafferetligt (MFL 30, stk. 4) sanktioneret forbud mod at den omfattede personkreds på utilbørlig vis skaffer, eller forsøger at skaffe sig, kendskab til eller rådighed over erhvervshemmeligheder så som et programs kildekode, dokumentation, forberedende materiale mv., jf. MFL 19, stk. 1. Som det fremgår, er selve udnyttelsen af den hemmelige information, til eksempelvis at udvikle konkurrerende produkter, ikke afgørende. Det blotte forsøg på at skaffe sig adgang til erhvervshemmeligheder er tilstrækkeligt. Reglerne bevirker tillige, at ansatte, konsulenter, eksterne licenstagere, og andre, der kan tænkes at have opnået lovlig viden om disse forretningshemmeligheder, ikke uden samtykke, må benytte eller sprede den pågældende viden, jf. MFL 19, stk. 2. Forbuddet består i 3 år efter tjeneste-/samarbejdsforholdets eller hvervets ophør, men det fremgår af forarbejderne til bestemmelsen, at civilretligt ansvar vil kunne gøres gældende selv efter fristens udløb. 197 Endelig er der indført et forbud mod at erhvervsdrivende, som erhverver viden i strid med de nævnte bestemmelser, må benytte den pågældende viden, jf. MFL 19, stk. 5. I tilknytning til ovenstående må nævnes MFL 19, stk. 4, der supplerer stk. 2, og som henvender sig til personer, der har relationer til virksomheden i anledning af udførelsen af arbejde eller i øvrigt i erhvervsøjemed. Denne bestemmelse udvider hermed personkredsen, som nævnt i stk. 1-3, til også at omfatte personer, der ikke står i et decideret tjeneste- eller samarbejdsforhold med virksomheden, men 195 Det følger dog af U H at MFL 19 tillige finder anvendelse hvor et sådan arbejds-/samarbejdsforhold er ophørt, men hvor adgang til erhvervshemmeligheder efterfølgende opnås som følge af den tidligere forbindelse til virksomheden. 196 Jf. Erling Borcher & Frank Bøggild: Markedsføringsloven, 2006 s Jf. forarbejderne til Lov nr. 89 af hvor det anføres at: "Det antages dog, at civilretligt ansvar kan gøres gældende også efter udløbet af denne frist". 64

67 hvor kendskabet til den omhandlede information beror på en løsere forbindelse, som det eksempelvis er tilfældet, hvor materiale gøres tilgængeligt i forbindelse med licitationer o.l. 198 Foruden at udvide de omfattede subjekter, udvider bestemmelsen tillige beskyttelsesobjektet til at omfatte tekniske tegninger, beskrivelser, opskrifter, modeller el. lign informationer som betros den pågældende, uanset om elementer af den nævnte art udgør en erhvervshemmelighed, eller om de er beregnet til forvisning for en bredere kreds. 199 I relation til software vil bestemmelsen eksempelvis kunne omfatte dokumentation og/eller det forberedende arbejde. Disse elementer vil typisk tillige være omfattet af ophavsretten, og de markedsføringsretlige beskyttelse udgør derfor et supplement hertil. Ofte vil der i ansættelses-, licens- og øvrige samarbejdsforhold, som involverer kildekode og andet følsomt materiale, være indgået en kontrakt som specifikt angiver hvad der må anses for hemmeligt. 200 MFL 19 stiller dog intet krav herom, og er der tale om informationer, der henhører under erhvervshemmelighedsbegrebet, forpligtes den omfattede personkreds umiddelbart til hemmeligholdelse. Erhvervshemmeligheder vil typisk blive delt med en kreds af samarbejds- og handelspartnere, og MFL 19 vil i disse tilfælde kunne fungere som deklaratorisk udfyldende i tilfælde, hvor der eksempelvis indgås kontrakter med eksterne konsulenter, som ikke specifikt forholder sig til, hvad de pågældende må benytte den opnåede viden til. Beskyttelsen af erhvervshemmeligheder medfører, at sådanne samarbejdspartnere, foruden de aftalte rettigheder, ikke i øvrigt må benytte eller videresprede den viden, der i kraft af samarbejdet, er opnået om virksomhedens interne procedurer, produktkrav, kundekontakter, tekniske informationer mv. til skade for virksomheden. Kendskab til en algoritme som effektivt løser et bestemt problem, planer om at udvide et givent program med yderligere funktionalitet, sikkerhedsbrister, osv. må således som udgangspunkt ikke benyttes/spredes uden særskilt aftale, såfremt den pågældende information ikke er alment kendt. 198 Jf. også implicit Erling Borcher & Frank Bøggild: Markedsføringsloven, 2006 s Forfatterne synes dog ikke at bemærke denne udvidelse af personkredsen, idet de angiver at MFL 19, stk. 1-4 forudsætter et tjeneste- /samarbejdsforhold eller lovlig adgang til virksomheden, jf. samme fremstillings s Som nævnt må stk. 4 dog forstås som en udvidelse af denne personkreds, jf. også forfatternes egen bemærkning vedrørende anvendelsesområdet for MFL 19, stk. 4, hvor arkitektkonkurrencer og licitationer nævnes som eksempler. Disse eksterne kontakter er karakteriseret ved endnu ikke at have udviklet sig til et egentligt samarbejde. 199 Jf. også Erling Borcher & Frank Bøggild: Markedsføringsloven, 2006 s Hermed undgås at der senere opstår tvivl herom derved, at de relationer som virksomheden deler sin viden med har en anden opfattelse af hvad der udgør hemmeligheder. Skulle der alligevel opstå retstvister vil klare definitioner endvidere kunne mindske den usikkerhed, der er forbundet med sagens udfald. 65

68 Endelig må nævnes MFL 1, vedrørende god markedsføringsskik, som uanset anden beskyttelse udgør et effektivt værn mod produktefterligning. Bestemmelsen omtales ikke nærmere her Erhvervshemmeligheder og reverse engineering Selvom software udgives i objektkodeform, og det derfor ikke er muligt umiddelbart at få indsigt i programmets virkemåde, er det i praksis statueret at spredning af et produkt til almenheden fratager det sin status som erhvervshemmelighed. Dette uanset om særlige tiltag er påkrævet for at opnå viden om dets sammensætning og/eller virkemåde. 202 I U H udtalte Sø- og Handelsretten således at: ved markedsføringen blev den ide, der lå i at fremstille en hvergangsgødning til husholdningsbrug, gjort tilgængelig for andre, og det samme gjaldt recepten, idet produktets sammensætning kunne konstateres ved analyse; da disse ting ikke var beskyttet af eneretslovgivningen, var der herefter intet til hinder for, at andre kunne producere og markedsføre et lignende produkt. 203 Specifikt relateret til software betyder dette at et programmets indre, dvs. de maskininstruktioner der kan udledes ved analyse 204, ikke udgør en erhvervshemmelighed når produktet først er spredt til en ubestemt kreds af købere i den almindelige handel. 205 Hvor den omfattede personkreds fortager reverse engineering, er dette derfor ikke at betragte som forsøg på at skaffe sig utilbørlig adgang til erhvervshemmeligheder i strid med MFL 19, stk. 1. Som tidligere nævnt kan handlingen dog være i strid med OPHL 2, såfremt den ikke favnes af undtagelserne i OPHL 36, stk. 1, nr. 3 og 37. For så vidt angår samarbejdspartnere, og andre der forinden offentliggørelsen besad eksklusiv viden om kildekode, dokumentation mv., og derfor omfattes af MFL 19, stk. 2, opstår spørgsmålet om i hvilket omfang disse stadig er forpligtede til ikke at benytte og sprede den pågældende viden. I disse tilfælde må beskyttelsen, som antydet i U H, udstrækkes til også at gælde i en vis periode efter, at produktet gøres tilgængeligt for almenheden. 206 Herved sikres at forhåndskendskabet ikke medfører en konkurrencemæssig fordel, som ikke ville være opnået ved reverse engineering alene. Ved den nærmere 201 Der henvises for nærmere omtale til Bent Ole Gram Mortensen & Michael Steinicke: Dansk markedsret, 2006 s Jf. også Erling Borcher & Frank Bøggild: Markedsføringsloven, 2006 s Producenten anerkendte overfor Højesteret at ideen og recepten ikke var beskyttet som erhvervshemmelighed efter at produktet var gjort tilgængeligt for almenheden. Højesteret tog derfor ikke stilling til problemstillingen. 204 Se vedrørende dekompilering og disassembly i afsnit Anderledes hvor programmet alene licenseres til en afgrænset kreds af købere og samarbejdspartnere, jf. umiddelbart nedenfor. 206 Domstolen udtalte således, at der ikke var noget til hinder for at andre kunne producere og markedsføre et lignende produkt. Dette måtte i hvert fald efter en vis rimelig tid, efter at produktet var kommet på markedet, også gælde personer og firmaer, der havde været ansat hos eller været i samarbejde med sagsøgeren... *min fremhævelse]. 66

69 fastlæggelse af denne periode bør der tages højde for det tidsforbrug og de begrænsninger der er forbundet med reverse engineering. I modsætning til genstanden i den netop refererede dom gødningsmidlet Blomin hvor det var muligt at analysere sig frem til den kemiske sammensætning, kan et programs kildekode sjældent udledes i sin oprindelige form ved reverse engineering, jf. afsnit Det må derfor antages, at detaljer om den oprindelige kildekodes specifikke struktur, dens litterære form, vedbliver at være en erhvervshemmelighed i de tilfælde, hvor det ikke er muligt at dekompilere koden. Afgrænsningen af hvad der i disse tilfælde vedbliver at være beskyttet som erhvervshemmelighed, og hvad der må anses for almen tilgængelig information, er dog vanskelig at fortage. Det skyldes, at det resultat som kan opnås ved reverse engineering afhænger af en lang række faktorer, herunder hvilket programmeringssprog koden er skrevet i, hvilke tiltag der fra programmørernes side er taget med henblik på at besværliggøre processen, og hvor dygtig/erfaren en person, der skal tages som målestok som engineer. På denne baggrund må det forventes, at domstolene vil indskrænke beskyttelsen til kun at gælde brug af kildekodens litterære udtryk, som med relativ sikkerhed ikke kan genskabes ved dekompilering. I modsat fald ville aktuelle eller tidligere samarbejdspartnere blive stillet ringere end det øvrige marked. Udarbejder personer, med tidligere kendskab til koden, software baseret på lignende ideer og tilsvarende algoritmer, men med afvigelser i selve implementeringen, vil dette formentlig ikke være i strid med MFL 19, hvor produktet er alment tilgængeligt. Beskyttelse må her søges i ophavsretten eller patentretten. I de tilfælde hvor softwaren ikke spredes til en mere ubestemt gruppe af aftagere i den almindelige handel, men alene licenseres til specifikt udvalgte kunder (i forhold til hvem der består et samarbejdsforhold i MFL 19, stk. 1 forstand) opstår en særlig problemstilling. Udgangspunktet er at erhvervshemmeligheder som defineret i en licensaftale, eller som følger implicit af kontraktforholdets natur, ikke må benyttes eller spredes til tredjemand, jf. MFL 19, stk. 2. Spørgsmålet er herefter om bestemmelsen i OPHL 37, stk. 1, som tillader reverse engineering foretaget i interoperabilitets øjemed, og bestemmelsens stk. 2, nr. 2, som giver ret til at sprede den herved opnåede information til tredjemand, når dette er nødvendigt for at gøre et selvstændigt udviklet edb-program interoperabelt, går forud for forbuddet mod benyttelse og spredning af erhvervshemmeligheder i MFL 19. Svaret på dette spørgsmål er ikke givet. På den ene side fremgår det udtrykkeligt af art. 9, stk. 1, i edbdirektivet, og OPHL 37, stk. 3, at reglerne vedr. reverse engineering er præceptive. På den anden side foreskriver samme bestemmelse i direktivet at Bestemmelserne i dette direktiv berører ikke anvendelsen af andre retsforskrifter vedrørende f.eks. forretningshemmeligheder. Mads Bryde Andersen mener, at aftaler, der alene har til formål at forhindre reverse engineering er ugyldige, mens et aftalemæssigt 67

70 arrangement som reelt sigter til at bevare de hemmeligheder, programmet indeholder, og som også søges håndhævet med dette formål er gyldige. 207 Som begrundelse anføres at beskyttelsen af erhvervshemmeligheder principielt er ligeværdigt med andre industrielle rettighedsformer, herunder patenter. Direktivet giver ikke grundlag for en sådan fortolkning, og i praksis ville den medføre betydelige afgrænsningsvanskeligheder. Det er korrekt, at retsværnet i MFL 19 er ligeværdigt med øvrige industrielle rettighedsformer, men der er væsensforskelle på hvordan de forskellige rettighedsformer etableres. Patentretten beror som bekendt ikke på aftaleindgåelse, men på godkendelse af en formel ansøgning. Henset til at direktivet specifikt fastslår, at der ikke kan gøres aftalemæssige indskrænkninger i retten til reverse engineering forekommer nævnte fortolkning derfor ikke at være i overensstemmelse med direktivteksten. De afgrænsningsproblemer, og den usikkerhed, der vil opstå i relation til at afgøre om en given fortrolighedsklausul reelt sigter til at bevare erhvervshemmeligheder vil endvidere være betydelige. Enhver fortrolighedsklausul, uanset om denne specifikt forbyder reverse engineering, eller om den formuleres mere bredt, vil således dække over et ønske om at bevare, hvad der anses for erhvervshemmeligheder. En sondring som den foreslåede skaber således risiko for at retten til reverse engineering, som foreskrevet i direktivets art. 6 og OPHL 37, reelt vil blive illusorisk som følge af udbredt brug af hemmeligholdelsesklausuler. Det må på baggrund af disse betragtninger konkluderes, at præceptiviteten i OPHL 37, stk. 3 er absolut, og at hemmeligholdelsesklausuler, der forbyder analyse af edb-programmet, må tilsidesættes uanset form og formål. I tilfælde hvor der indgås fortrolighedsaftaler med andre end den omfattede persongruppe, f.eks. ved brug af såkaldte shrink wrap -klausuler 208, eller hvor der i øvrigt indgås sådanne aftaler efter at produktet spredes til den almindelige handel, og derfor ophører med at være en erhvervshemmelighed, jf. ovenfor, må forholdet løses uafhængigt af MFL 19. Også her vil præceptiviteten i OPHL 37, stk. 3 medføre, at retten til reverse engineering ikke fortabes. 207 Jf. Mads Bryde Andersen: IT-retten, 2005 s Forfatteren hævder endvidere at såkaldte shrink wrap -klausuler (standardklausuler som de der følger med programmel købt i den almindelige handel) aldrig vil opfylde disse betingelser, idet rettighedshaveren end ikke kender sin licenstager. En sådan ubestemt gruppe af licenstagere er imidlertid slet ikke omfattet af MFL 19. En licensgiver vil derfor aldrig kunne forhindre denne gruppe i at foretage reverse engineering med hjemmel i MFL 19. Tilbage står alene et aftaleretligt spørgsmål. Som anført vil en aftale ikke kunne tilsidesætte OPHL 37, og argumentet om at direktivteksten viger for bl.a. reglerne om erhvervshemmeligheder har intet for sig i tilfælde, hvor MFL 19 end ikke finder anvendelse. 208 Shrink wrap -kontrakter er licensaftaler eller vilkår for brug af software-programmet, som først kan læses og accepteres af brugeren når produktets emballage brydes. Heraf det engelske tilnavn shrink wrap som hentyder til den plastfolie (shrinkwrap plastic), som edb-programmers emballage typisk dækkes af, når de distribueres i den almindelige handel. 68

71 Selvom informationer, der kan udledes ved reverse engineering, ikke længere beskyttes som erhvervshemmelighed efter, at der er sket spredning til almenheden, vil det endvidere kunne få retlige konsekvenser, såfremt betroede kilder røber den pågældende information til omverdenen, eller anvender denne til skade for virksomheden. Ansatte, samarbejdspartnere mv., vil således kunne ifalde erstatningssvar, som følge af brud på den almindelige loyalitetspligt, der består i et aftaleforhold. Anvendelse af den pågældende viden til produktion af konkurrerende produkter, efter at et ansættelsesforhold er ophørt, vil endvidere kunne hindres, såfremt der er indgået konkurrenceklausuler og uanset om denne pågældende information har karakter af erhvervshemmelighed. Endelig kan nævnes generalklausulen i MFL 1. Denne kan bringes i anvendelse i tilfælde, hvor der udenom en virksomheds ledelse, rettes henvendelse til interne kilder i virksomheden med henblik på at erhverve viden om produkter mv., som ikke er umiddelbart er tilgængelig., jf. eksempelvis U H Forholdet til ophavsretten og patentretten I modsætning til ophavsretten og patentretten har MFL 19 ikke karakter af en eneretsbeskyttelse, og formålet er alene at hindre den omfattede personkreds i at misbruge information ikke at beskytte værker og opfindelser som sådan. Ikke desto mindre har reglerne en vigtig funktion både under udviklingsfasen og efterfølgende. Ophavsretten For så vidt angår selve edb-programmet har MFL 19 praktisk relevans som supplement til ophavsretten, idet visse dele af programmet ikke beskyttes heraf. Det forberedende udviklingsarbejde og programkoden er allerede i vist omfang beskyttet i medfør af ophavsretten, men beskyttelsens omfang indskrænkes som nævnt af originalitetskravet, herunder særligt princippet om den manglende idebeskyttelse. Programmets grænseflader, dets overordnede algoritmer og de protokoller der anvendes, favnes således ikke af ophavsretten, men vil kunne opnå beskyttelse som erhvervshemmelighed, jf. MFL 19. Forberedende arbejde af beskrivende karakter, f.eks. tegninger og beskrivelser af edb-programmets forhold til andre systemkomponenter og kodens struktur mv., beskyttes endvidere ikke mod realisering i medfør af ophavsretten, men sådan brug af betroet information vil potentielt kunne hindres som følge af forbuddet mod brug af erhvervshemmeligheder. Hertil kommer at mere perifere informationer om virksomhedens produktudviklingsstrategi, programmets mangler ( bugs ) og sikkerhedsbrister mv. beskyttes i medfør af MFL 19, men ikke af ophavsretten. Det må dog erindres at beskyttelsen aftager i effektivitet når edb- 209 I sagen blev statueret overtrædelse af den daværende konkurrencelovs 15, som forbyder uredelig forretningsførelse, idet sagsøgte havde henvendt sig til sagsøgers medarbejdere for at indhente oplysninger som forinden markedsføringen at produktet var at betragte som en erhvervshemmelighed. Reglen svarer i sin substans til den nuværende MFL 1. 69

72 programmet først er spredt til almenheden, i det omfang oplysninger som de nævnte kan udledes ved analyse af programmet. I praksis vil beskyttelsen derfor primært have relevans i produktudviklingsfasen eller i tilfælde hvor edb-programmet alene licenseres til en nærmere bestemt kreds af samarbejdspartnere. Patentretten Vælger en virksomhed at ansøge om patent på et edb-programs algoritmer/metoder fraskriver den sig samtidig beskyttelsen af disse som erhvervshemmelig, idet patentretten kræver offentliggørelse af opfindelsen. Udviklere af edb-programmer må derfor nøje overveje om det er fordelagtigt at søge patent. I den forbindelse må ske en afvejning af fordele og ulemper ved den principielt tidsubegrænsede, formfri og gratis beskyttelse som erhvervshemmelighed, overfor den 20 årige eneretsbeskyttelse der, mod betaling, kan opnås i medfør af patentretten. Som nævnt, i afsnit 4, tilsiger patentet opfinderen en eneret på selve den patenterede opfindelse, f.eks. en algoritme eller en funktion, mod at opfinderen igennem registreringsproceduren indvilliger i at afgive implementeringsdetaljer til omverden. Forventes konkurrenter mv. relativt hurtigt at kunne gennemskue opfindelsen for herefter at plagiere den innovative frembringelse, således at opfinderens indtjeningsmuligheder begrænses, vil afvejningen, alt andet lige, typisk føre til at der søges patent. Modsat vil forventninger om en first mover advantage der tidsmæssigt strækker sig så langt at opfinderen som minimum opnår break-even, dvs. en indtjening svarende til den kapital der er investeret i forskning, udvikling og innovation, tale for at bibeholde opfindelsen som en erhvervshemmelighed. Herved spares de ofte betydelige omkostninger der er forbundet med at udtage patent i flere lande. I tillæg hertil vil opfinderen endvidere, udfra en cost/benefit betragtning, skulle vurdere hvorvidt de omkostninger der er forbundet med håndhævelse af et eventuelt patent, vil stå mål med den profit der forventes at tilflyde virksomheden som følge af eneretten. Det er endeligt essentielt at bemærke at patenter ofte udtages af strategiske årsager som ikke alene knytter sig til et ønske om at værne om investeringer i forskning og udvikling eksempelvis som forhandlings- og/eller pressionsmiddel. En sådan effekt kan ikke opnås ved alene at holde sig til beskyttelsen af erhvervshemmeligheder og ophavsretten. Grundet den hastige udvikling og det besvær der er forbundet med at genskabe avancerede højteknologiske produkter vil den heraf følgende first mover advantage i mange tilfælde udgøre tilstrækkelig beskyttelse for de virksomheder der agerer på sådanne markeder. Henset til den strategiske værdi af patenter i software-industrien, samt den ofte abstrakte patentbeskrivelse som lægger til grund for patentudstedelsen på edb-programmer, må det dog vurderes at patenter ofte vil være attraktive på dette marked specielt for de større virksomheder der har midlerne til at identificere krænkelserne og håndhæve eneretten. 70

73 Afslutningsvis må endelig bemærkes at beskyttelsen af erhvervshemmeligheder supplerer patentretten derved, at der, jf. EPC art. 55, stk. 1, litra a (og PTL 2, stk. 6, nr. 1) kan meddeles patent på en opfindelse selvom opfindelsen inden for de sidste 6 måneder er blevet almindelig tilgængelig (og derfor ikke kan anses for ny), såfremt dette skyldes et åbenbart misbrug i forhold til ansøgeren eller nogen, fra hvem hans ret hidrører. Et sådant misbrug kan eksempelvis skyldes brud på en hemmeligholdelsesaftale. 6 Konklusion Ophavsretten har sin primære relevans som værn mod piratkopiering. Selvom den tillige favner plagiering af kildekoden og visse former for bearbejdelser, navnlig oversættelse til andet programmeringssprog, vil det besvær, der er forbundet med at identificere sådanne krænkelser, og føre bevis herfor, i disse tilfælde, mindske retsbeskyttelsens praktiske relevans. Dette skyldes 1) at ophavsretten ikke er til hinder for uafhængige dobbeltfrembringelser, 2) at programmer, som indeholder krænkende kode, ofte udgives som closed source og 3) at software har en sådan karakter at koden, når den først er bearbejdet, vil adskille sig markant fra originalværket. Af samme årsag vil bearbejdelser i mange tilfælde mangle den fornødne sammenhæng med originalværket, til at udgøre en krænkelse. Endelig må konkluderes at det forberedende materiale, der ligger til grund for udarbejdelsen af et edb-program, i praksis ikke vil være beskyttet mod realisering. Set med konkurrenters øjne vil det sjældent være aktuelt at foretage reverse engineering med henblik på efterligning af ophavsmandens kode, idet sådanne teknikker er ineffektive i forhold til at udlede kildekoden. Generelt vil det desuden ikke være økonomisk rentabelt at tilpasse ophavsmandens kode til egne produkter, set i forhold til at skrive koden selv. Innovationen befinder sig på ideniveau, ikke på kodeniveau. Når bortses fra decideret piratkopiering, må derfor vurderes, at ophavsretlige krænkelser hovedsageligt vil komme på tale, i tilfælde hvor krænkeren har haft adgang til den originale kildekode, og hvor dele heraf kan implementeres i egne produkter uden større tilpasninger. Ophavsretten værner alene den konkrete manifestation af de ideer og principper som ligger til grund for programkoden. Den bagvedliggende ide, herunder de overordnede algoritmer og metoder, er derfor ikke ophavsretten relevant. Dette levner plads til den patentretlige beskyttelse, som ikke er bundet til programkodens udtryk, men derimod til mere abstrakte beskrivelser af programmers virkemåde. Set i forhold til ophavsretten, styrker patentretten programudviklernes stilling i krænkelsessager, idet der er tale om en prioritetsbeskyttelse, hvor krænkelser påvises på objektivt grundlag. Det faktum at beskyttelsen ikke knytter sig til programkoden, men til mere overordnede emner, gør det endvidere lettere at identificere og bevise krænkelser. Selvom EPC art. 52, stk. 2, litra c, indskærper at særligt programs for computers ikke 71

74 skal betragtes som opfindelser i medfør af art. 52, stk. 1, følger af EPO s praksis, at det i vidt omfang er muligt at opnå patenter på netop sådanne programmer, såfremt der ydes et teknisk bidrag til det allerede kendte. Dette skyldes en kreativ fortolkning af begrebet as such i EPC art. 52, stk. 3. Det kan ikke udelukkes at patenter i visse tilfælde kan tilskynde til udvikling af nye innovative løsninger på tekniske problemer. For innovative løsninger af meget simpel teknisk beskaffenhed kan tænkes, at disse ikke vil blive kommercialiseret uden en beskyttelse som den patentretlige, idet konkurrenter hurtigt vil kunne efterligne ideen og indfinde sig på markedet. Ligeledes kan tænkes at produkter, som bygger på meget komplekse løsninger, f.eks. matematiske algoritmer til kryptering af data, kan have behov for beskyttelse, såfremt disse udgør selve kernen i det produkt der markedsføres. Det må dog vurderes at ulemperne ved den langvarige, abstrakte og vidtfavnende beskyttelse, som opnås i medfør af patentretten, overstiger fordelene. Dette skyldes særligt at markedet for software er kendetegnet ved sekventiel innovation, og at et enkelt produkt potentielt favnes af adskillige patenter. Den ophavsretlige beskyttelse vil i de fleste tilfælde være tilstrækkelig til at sikre incitamentet til innovation. På et marked præget af hastig udvikling vil værdien i at komme først på markedet, såkaldt first mover advantage, være af stor betydning. Hertil kommer at software-produkters værdi knytter sig til andet og mere end ideen, herunder stabiliteten af de server som produktet afvikles på, kvaliteten/designet af det produkt som softwaren implementeres i, brugervenlig dokumentation, god support, intuitiv brugergrænseflade, gode kunderelationer osv. Foruden ideen er der således en lang række faktorer som innovative virksomheder kan differentiere sig på, for herved at skabe merværdi for kunderne. Nævnte first mover advantage vil i den forbindelse give virksomheden tid til at opbygge denne merværdi, forinden den mødes af konkurrence, og opstille effektive barrierer til markedet. Beskyttelsen af erhvervshemmeligheder i MFL 19 fungerer som supplement til ophavsretten, idet den værner elementer så som grænsefladespecifikationer og protokoller, som er undtaget den ophavsretlige beskyttelsessfære, som følge af idegrundsætningen. Det må imidlertid bemærkes at MFL 19 retter sig mod en begrænset persongruppe, i forhold til hvem der består et ansættelses/samarbejdsforhold, og at retsbeskyttelsen aftager når produktet indfinder sig i den almindelige handel. Information, der kan udledes ved analyse, herunder reverse engineering, er således ikke at betragte som en erhvervshemmelighed. Vælger en virksomhed at ansøge om patent på et programs algoritmer/metoder fraskriver den sig samtidig beskyttelsen af disse som erhvervshemmelighed, da patentretten kræver offentliggørelse af opfindelsen. I den forbindelse udgør MFL 19 derfor et alternativ til patentretten. 72

75 7 Litteraturliste Bøger Bender, Hanne: EDB-rettigheder, Jurist- og Økonomforbundets Forlag, 1998 Bessen, James & Meuer, Michael J.: Patent failure How Judges, Bureaucrats, and Lawyers Put Innovators at Risk, Princeton University Press, 2008 Borcher, Erling & Bøglund, Frank: Markedsføringsloven, 2. udg, Thomson, 2006 Deichmann, Hanne Kirk: Programkoncepter ophavsret til tv-formater, Thomson, 2002 Eilam, Eldad: Reversing secrets of reverse engineering, Wiley, 2005 Eklöf, Dan: Upphovsrätt i konkurrens - särskilt om artikel 82 och tvångslicensiering, Justus, 2005 Korah, Valentine: Intellectual Property Rights and the EC Competition Rules, Hart Publishing, 2006 Ley, Stanley: The Copyright Protection of Computer Software in the United Kingdom, Hart Publishing, 2000 Mads Bryde Andersen: IT-retten, 2. udg, Gjellerup, 2005 Mortensen, Bent Ole Gram & Steinicke, Michael: Dansk markedsret, 2. udg., Jurist- og Økonomforbundets Forlag, 2006 Plogell, Michael: Immaterialrättsliga aspekter på datorprogram, Juristförlaget, 1996 Riis, Thomas: Immaterialret IT, Jurist- og Økonomforbundets Forlag, 2001 Rosenmeier, Morten: Værkslæren i ophavsretten, Jurist- og Økonomforbundets Forlag, 2001 Schmidt, Per Håkon: Teknologi og Immaterialret, GAD, 1989 Schovsbo, Jens & Rosenmeier, Morten: Immaterialret, Jurist- og Økonomforbundets Forlag, 2008 Schønning, Peter: Ophavsretsloven med kommentarer, 4. udg., Thomson, 2008 Telyas, David; Jochimsen, Jacob Gebauer & Kiær, Lars Thorvald: Grænsefladespørgsmål mellem immaterialog konkurrenceret et teknologisk perspektiv med fokus på Microsoft-sagen, bachelorafhandling, Handelshøjskolen, Aarhus Universitet, Turner D.C Jonathan: Intellectual Property Law and EU Competition Law, Oxford University Press, 2010 Wagle, Anders Mediaas & Jr, Magnus Ødegaard.: Opphavsrett i en digital verden, Cappelen Akademisk Forlag, 1997 Whish, Richard: Competition Law, 6 udg., Oxford University Press, 2009 Artikler Allison, John R. et al.: Software Patents, Incumbents and Entry, i Texas Law Review, Vol. 85(7), 2007 s Bender, Hanne: Ophavsret til brugergrænseflader Look and Feel, i NIR 1/1997, s

76 Bergstra, Jan. A et al.: About trivial software patents The ISNot case, i Science of Computer Programming, Vol. 64, 2007 s Bessen, James & Maskin, Eric: Sequential Innovation, Patents, and Imitation, i RAND Journal of Economics, Vol. 40(4), 2009 s Bing, Jon: Ophavsretten og ny informasjonsteknologi - Noen sprete notater, i NIR 4/1995, s Bing, Jon: Vurderering av opphavsrettslig krenkelse av datamaskinprogrammer et praktisk perspektiv, i NIR 2/1999, s Canfield, Kenneth: The disclosure of source code in software patents should software patents be open source, i The Columbia Science and Technology Law Review, Vol. 7, 2006 s Deichmann, Hanne Kirk: Variationsværker, i NIR 2/2004, s Groche, Andreas: Software Patents Boon or Bane for Europe?, i International Journal of Law and Information technology, Vol. 14(3), 2006 s Jørgensen, Astrid Friis: Ingen reel ophavsretlig beskyttelse af edb-programmer, i Advokaten, Vol. 85(2), 2006, Nielsen, Peter Lind: Ingen reel beskyttelse af edb-programmer?, i Advokaten, Vol. 85(4), 2006, Schwarze, Holm: Computer-Implemented inventions in Denmark and Europe, i NIR 2008/6, s Udsen, Henrik & Schovsbo, Jens: Ophavsrettens missing link?, i NIR 1/2006, s Vinje, Thomas C.: The EC Software Directive and the Question of Interoperability, i NIR 1/1992, s Andre publikationer EPO: Guidelines for Examination in the European Patent Office, Tilgængelig på: EPO: Scenarios for the future, Tilgængelig på: Graversen, Ebbe Krogh & Mark, Michael: Forskning og Udviklingsarbejdes påvirkning af produktivitet og beskæftigelse, Dansk Center for Forskningsanalyse, Aarhus Universitet, Tilgængelig på: Hall, Browyn H.: The Use and Value of IP Rights, Prepared for the UK IP Ministerial Forum on the Economic Value of Intellectual Property, 2009 s Tilgængelig på: 74

77 8 English summary The software industry is one of the most important business sectors in modern time. On one hand it is therefore important that software developers are provided with sufficient legal protection to allow them to recoup their investments in development and innovation, while on the other hand, it is crucial for society that these legal rights are not stretched to an extent where they might have detrimental effects on the market as a whole. This would be the case if law provided developers with intellectual property rights that allowed them, not only to recoup their investments, but to hinder competition and thus innovation as a result of strategic considerations. Competition law provides a means to correct such conduct ex post, cf. TEUF art. 102, but this is to be viewed as a last resort it is preferred to achieve a balance, between the strength of intellectual property rights and incentives, ex ante, before problems arise. Against this background the primary aim of this thesis is to subject European copyright law, comprising the EC directive on the legal protection of computer programs (2009/24/EC), to an analysis in order to determine the extent to which software products are protected against imitation. The conclusion reached with regard to the extent and limitations posed by copyright law, is then used to compare this legal regime to patent law and trade secrecy law. This thesis does not include an analysis of legal problems related to graphical user interfaces or data elements forming part of software products. Focus is solely on the actual code forming the internal building blocks of software products, and its algorithms. With regard to patents focus is on the practice of EPO as this is of primary importance in Europe and has a strong influence on the practice of national patent offices. It is concluded that copyright law is primarily efficient in hindering software piracy and to prohibit imitation by former trading partners and employees who have had legal access to the products source code. In other cases the products code will seldom be the subject of imitation as there is simple no economic incentive to perform reverse engineering with the aim of copying code, and in addition such an procedure rarely gives access to the source code. As copyright is concerned with the specific code implementation, it does not safeguard against cases where the products methods or abstract algorithms are imitated. Due to this limitation in protection it is open to discussion whether or not stronger protection is needed, in the form of patents, as these protect ideas, compromising algorithms, on an objective basis. I Europe the EPO already grant software patents on CII (computer implemented inventions). In this authors opinion patents on software, cannot be recommended. Relying on patents for protecting ideas and algorithms will potentially halt innovation, due to the broad and abstract protection nature of such patents. Although innovation in the software industry is bound to ideas and algorithms which are not protected by 75

78 copyright law, and not the specific implementation in source code, it is therefore argued that copyright protection and rules on trade secrecy are sufficient to ensure software developers a chance to recoup their investments. 76