Indholdsfortegnelse | Forrige afsnit | Næste afsnit

7.4. Licensspørgsmål

7.4.a. Licensbegrebet

Problemstilling

Den ydelse, der består i at "sælge" information, der beskyttes af en immaterialret, præsteres ofte i form af licens til under nærmere angivne vilkår at benytte denne information ved at foretage sig handlinger, der ellers ville falde inden for rettighedshaverens eneret i henhold til en bestående immaterialret. Typisk vil licensen blive meddelt i form af en tilladelse, som rettighedshaveren eller en af denne udpeget mellemmand meddeler brugeren på en nærmere angiven måde og mod en nærmere fastsat betaling. Tilladelsen giver dermed brugeren ret til at gøre noget, som ellers ville være afskåret som følge af den pågældende eneret. Almindelige regler herom findes i ophl. § 36, stk. 1, nr. 1, der som fastsat i samme bestemmelses stk. 3, også finder anvendelse på rent digitale produkter (elektroniske bøger uden søgeprogrammel, clip-art samlinger, tabeller mv.).

Det ophavsretlige licensbegreb udspringer først og fremmest af rettighedshaverens eneret til at fremstille eksemplarer af programmet. Som en nærmest undtagelsesfri regel gælder det, at sådanne eksemplarer er en teknisk forudsætning for at kunne udføre de funktioner, programmet er konstrueret til at udføre: Når en programpakke købes, er første skridt brugerens kopiering af de nødvendige programfiler til systemets faste datalager (harddisk), hvor disse filer ligger klar til den løbende brug. Når dette er sket - eller hvis programmet er præ-installeret - sker næste serie af eksemplarfremstillinger, når programmet kaldes og enkelte moduler og dele bliver til eksemplarer i RAM-hukommelsen, jf. denne begrebsafgrænsning ovenfor i afsnit 3.1.c.

Retlig karakteristik

I en retlig karakteristik er licensen altså et løfte. Men løftet indgår i et tæt samspil med den eneret, der fremkalder behovet for den pågældende tilladelse. Derfor opstår de relevante licensspørgsmål i relation til hver enkelt eneret. I det følgende omtales alene de ophavsretlige licensspørgsmål, der gør sig gældende på programområdet. En tilsvarende gennemgang følger senere for så vidt angår de licenser, der knytter sig til databaseværnet og andre immaterialretlige eneretspositioner.

Sondringer

I en ophavsretlig sammenhæng må man skelne mellem to typer af licensspørgsmål:

- aftalt licens

Den ene type opstår i tilfælde, hvor brugerens ret til at benytte et edb-program udledes af en udtrykkelig (licens-)aftale med rettighedshaveren, hvori denne udnyttelsesadgang er normeret. Sådanne aftaler er hyppigere, jo "større" (og kostbare) programmer der er tale om, men forekommer sjældnere, jo "mindre" (og billige) programmer der er tale om. Foreligger en aftale gælder den, medmindre aftalen rammes af en ugyldighedsregel eller støder an mod en præceptiv barriere. Disse licensspørgsmål behandles i afsnit 7.4.d.

Begrebet licensaftale rummer dog andet og mere end sådanne overdragelsesspørgsmål. Ønsker erhververen f.eks. en mere eksklusiv ret til at benytte den pågældende immaterialret, f.eks. med sigte på distribution, tager aftalen skikkelse af en distributionsaftale, jf. herom PA s. 656 og generelt om sådanne aftaler sst. s. 590 ff. I nær forbindelse hermed står de aftaler, der tildeler erhververen en fuldstændig ret til hele den ophavsret (eller anden immaterialret), der knytter sig til programmet, således at erhververen indtræder i samtlige overdragelige rettigheder. Disse aftaleforhold omtales ikke nærmere i det følgende. Sådanne aftaler indgås f.eks. i forbindelse med overdragelse af IT-virksomheder eller som led i programudgivelsesaftaler.

- legal licens

Den anden type licensspørgsmål opstår, når der ingen (udtrykkelig) aftale foreligger mellem rettighedshaveren og brugeren. Hvis ikke lovgivningen træder til med regulering i sådanne tilfælde, må man søge at præcisere en retsstilling gennem fortolkning af de tilkendegivelser, parterne har udvekslet, eller ved inddragelse af de typeforudsætninger og sædvaner, der er gældende på området. I dansk ophavsret findes en sådan hjemmel imidlertid på programområdet med reglerne i ophl. § 36, der etablerer, hvad man kan kalde en legal programlicens.

7.4.b. Den legale programlicens

Ifølge ophl. § 36, stk. 1, nr. 1, har den, der har ret til at benytte et edb-program (i modsætning til den, der råder over en ulovlig kopi), ret til at fremstille sådanne eksemplarer af programmet og foretage sådanne ændringer i programmet, "som er nødvendige for, at erhververen kan benytte det efter dets formål, herunder foretage rettelse af fejl". Denne ret kan udvides og indskrænkes ved aftale, jf. stk. 4 modsætningsvis. Han må desuden fremstille et sikkerhedseksemplar af programmet, for så vidt det er nødvendigt for benyttelsen af det. Dette gælder uanset, hvad der er aftalt, jf. stk. 4. Bestemmelsen indfører en særlig afgrænsning af brugerens licensret. Retten til at bruge programmet ved at fremstille eksemplarer af det (jf. om denne sondring straks nedenfor) er nemlig en funktion af brugerens formål. Benytter brugeren programmet "efter dets formål", må han kopiere det, så frit han vil, jf. bestemmelsens stk. 1.

Det er en ganske særegen retstilstand, loven hermed indfører. Den indebærer nemlig, at den blotte tanke i sig selv kan gøre en handling mere eller mindre lovlig. Fremkalder jeg en kopi af et edb-program for at bruge det i overensstemmelse med manualens anvisninger, er jeg inden for den legale licens: Jeg benytter programmet efter dets formål. Men får jeg undervejs i processen den tanke, at jeg egentlig kunne eftergøre programmet, hvorefter jeg fortsætter min brug for at planlægge denne eftergørelse, bliver selvsamme kopi pludselig ulovlig, sml. dog stk. 1, nr. 3, og i det hele § 37, der under visse omstændigheder gør sådanne - i sig selv formålsstridige - eksemplarfremstillinger lovlige.

Forklaringen på denne regel ligger i bestemmelsens udspring i 1991-direktivet om retlig beskyttelse af edb-programmer. Under behandlingen af dette direktivforslag opstod en intens diskussion om reverse engineering. Reverse engineering forudsætter kopiering, men vidner til gengæld om en tydelig subjektiv hensigt. Ved at formulere loven som sket, giver man den rettighedshaver, der ønsker at modsætte sig reverse engineering, mulighed for at forfølge denne handling.

Eksemplarbegrebet

Som nævnt i afsnit 6.3.b. er grænsen mellem brug og kopiering af et program vanskelig at drage. Set fra et rent ophavsretligt synspunkt er den dog klar. Eksemplarfremstilling foreligger, hvis brugeren som led i sin anvendelse af programmet helt eller delvis knytter programmets informationsindhold til et medium (f.eks. i RAM eller på disk), hvorpå det ikke befandt sig før. Brug foreligger derimod, hvis programanvendelsen sker uden en sådan ny eksemplarfremstilling, f.eks. ved at brugeren blot foretager et kald til programmet, der rettes mod et eksemplar af det, der i forvejen er udført i systemets RAM eller i en ROM-kreds. Kan tredjemand udføre den handling, der giver programmet værdi (f.eks. konvertere indtastede data eller finde data i en database) ved en sådan brug, der ikke fører til frembringelse af nye eksemplarer af programmet, vil en sådan fremgangsmåde være uangribelig, hvis ellers det således anvendte eksemplar er dækket af en licens. I så fald er vi uden for anvendelsesområdet for §§ 36 og 37. Sådanne handlinger kan derimod være omfattet af særlige aftaler, der begrænser brugen i forskellige situationer, ligesom en aftale om hemmeligholdelse af informationer vedrørende det pågældende program almindeligvis lægger begrænsninger i adgangen til sådanne former for ikke-eksemplarfremstillende "brug".

Det lovlige formål

Hvad der nærmere ligger i det lovlige "formål" med at bruge et edb-program, er ikke fastlagt i forarbejderne til bestemmelsen. Af bestemmelsens forgænger (§ 11a, gældende fra juni 1989 og frem til december 1992, hvor § 36 fik sin nuværende affattelse), fremgik det udtrykkeligt, at den retmæssige bruger mistede sin ret til at udnytte sine kopier, når han videresolgte eksemplaret.

Forarbejderne til § 11a berører licensproblemerne i FT 1988/89, till. A. sp. 3219, hvor det præciseres, at bestemmelsen er udformet med sigte på, at det ikke skal være lovligt under nogen form at videresprede de med hjemmel i § 11a fremstillede eksemplarer. Videre siges det, at "adgangen for ejeren til at fremstille eksemplarer efter § 11a bør være nøje begrænset til de formål, der angives i bestemmelsen. Der er således ikke ved § 11a åbnet mulighed for, at en person eller virksomhed fx kan fremstille kopier med henblik på samtidig kørsel af det erhvervede program på flere datamater. Dette har ikke mindst betydning for virksomhedsrelaterede programmer, som sælges gennem detailhandelen, fx til bogføring, lagerstyring og tekstbehandling."

Diskussion

Da der i øvrigt ikke foreligger domspraksis på området, giver formålskriteriet anledning til betydelig fortolkningstvivl - en tvivl, der må siges at udspringe af, at hverken baggrundsretten (§ 36) eller aftaleforholdet mellem parterne (sml. neden for afsnit 21.3.c. om de såkaldte shrink wrap-aftaler) tager udtrykkeligt stilling. I sådanne tilfælde følger det af danske fortolkningsprincipper, at man bør lægge vægt på de typeforudsætninger, der almindeligvis vil være gældende på markedet for edb-programmel af den pågældende art. Problemet ved at anvende dette kriterium er imidlertid her - som på andre områder af IT-retten - at vi har at gøre med en branche, der ikke alene ændrer sig hastigt, men som tilmed henvender sig til et ubestemt, mangfoldigt og ofte konvergerende marked bestående af markedssegmenter med vidt forskellige forudsætninger og forventninger.

Alligevel lader det sig gøre at opstille visse nogenlunde faste udgangspunkter:

Enkeltbrugerlicenser

På det almindelige marked for standardprogrammel synes kontraktspraksis at have lagt sig fast på den betragtning, at anvendelsen af en programpakke betragtes som en "licens", hvorefter kopiering og brug enten tillades for en fysisk person (personlig licens) eller - navnlig for større installationer - en given virksomhed (site-licens), afgrænset efter geografiske (f.eks. en given lokalitet) eller tekniske (en given centralenhed) kriterier. Dette indebærer, at samme program aldrig må anvendes af flere brugere (henholdsvis på flere centralenheder) på samme tid. Licensbetragtningen knytter altså ikke an til, hvornår originaleksemplaret holder op med at eksistere, men til om det bliver anvendt (og dermed gjort til genstand for yderligere eksemplarfremstilling) i forbindelse med en brugskopiering. Den tidligere ophavsretslovs § 11a fastslog udtrykkeligt, at retten til at "udnytte" sikkerhedskopier mv. bortfalder, hvis originaleksemplaret spredes videre (§ 36).

Tankegangen er rammende formuleret i den såkaldte "No-Nonsense Licence Statement", som programproducenten Borland på et tidspunkt benyttede. Det hed bl.a. her, at "... you may treat this software just like a book ...". Videre hedder det: "By saying 'just like a book,' Borland means, for example, that this software may be used for any number of people and may be freely moved from one computer location to another, so long as there is no possibility of it's being used at one location while it's being used at another. Just like a book that can't be read by two different people in two different places at the same time, neither can the software be used by two different people in two different places at the same time". En tilsvarende holdning kan måske udledes af IT-Brancheforeningens pjece: "Undgå ulovlig kopiering - kend reglerne". Det hedder her: "Hvis ikke der er truffet speciel aftale, er et PC-program ... kun beregnet til én person på én PC. Det er ikke lovligt at bruge det på flere PC'er samtidig - hverken enkeltstående eller i et netværk."

Den legale programlicens giver derfor en bruger, der af praktiske grunde vælger at have det samme program liggende to forskellige steder på sin harddisk, adgang hertil. Det samme gælder, hvis et og samme program anvendes såvel på en bærbar PC som på en stationær, blot begge systemer ikke anvendes samtidig af to forskellige brugere. At skulle afkræve en bruger dobbelt betaling i disse tilfælde ville repræsentere en uforholdsmæssig fordyrelse af licensomkostningerne for programmel og indebære en berigelse af programindustrien med tvivlsomt realt grundlag.

Torvund (1997), s. 157, antager som utvivlsomt, at der ikke er ret til at fremstille eksemplarer af et program på flere maskiner. Udtalelsen, der ikke sondrer mellem selve fremstillingen af eksemplarer, henholdsvis anvendelsen af disse eksemplarer i en brugssituation, er efter min opfattelse diskutabel, og der kan ikke siges at have fæstnet sig nogen klar praksis i branchen om, hvad der er sædvanlig på dette område, jf. bemærkningerne herom ovenfor.

Tredjemandsbrug

§ 36 tager ikke stilling til, om tredjemand har ret til at benytte et program, som er licenseret til licenstagerens brug i dennes virksomhed. Som bestemmelsen er formuleret, retter den sig mod den, der har ret til at "benytte" et eksemplar af et edb-program. I mangel af særlig angivelse må dette begreb antages at knytte sig til den enkeltperson eller den type af brugere, der almindeligvis må forventes at benytte den eller de terminaler eller klienter, som programmet anvendes på. Hvilken personkreds, dette nærmere er, beror på det førnævnte formålskriterium, og der er ikke megen støtte for fortolkningen at hente i andre ophavsretlige regler. At ophl. § 19, stk. 3, forbyder "udlån" spiller i den forbindelse en mindre rolle, eftersom begrebet udlån her anvendes som et eksempel på spredning: Når programmet er udlånt, ophører "udlånerens" ret til at benytte det, ganske som hvis programmet var spredt videre ved salg.

Sikkerhedskopiering

Foruden den form for eksemplarfremstilling, der er nødvendig af hensyn til programmets anvendelse (brug), tillader § 36 tillige fremstilling af "reserve- og sikkerhedseksemplarer". Denne præceptive (jf. stk. 4) regel giver en person, der har ret til at benytte et program, ret til at udføre "en" sikkerhedskopi, for så vidt det er nødvendigt for denne benyttelse. Bestemmelsen skal næppe forstås bogstaveligt. I den engelske tekst bruges præpositionen "a", og ikke tallet "one". Bortset fra dens præceptive indhold vil adgangen til denne nødvendige kopiering derfor svare til, hvad der allerede følger af ophl. § 36.

I sin redegørelse af 10. april 2000 (COM(00) 199 final) til Rådet, Parlamentet, og det Økonomiske & Sociale Udvalg om virkningerne af direktiv 91/250/EØF om retlig beskyttelse af edb-programmer, har Kommissionen angivet en anden holdning til dette spørgsmål. I afsnit VII vedrørende direktivets art. 5, stk. 2, slår Kommissionen fast som sin opfattelse, at retten til at frembringe "et" sikkerhedseksemplar skal forstås bogstaveligt, omend opfattelsen herom tilsyneladende er delt. Kommissionen har ingen særlig fortolkningskompetence, og dens opfattelse på dette punkt nyder ikke almen anerkendelse. Spørgsmålet må betragtes som uafklaret, indtil EF-domstolen har udtalt sig om det.

I reglen om, at brugeren alene må foretage de eksemplarfremstillinger, der er nødvendige for hans brug af programmet, ligger modsætningsvis, at en kopiering, der alene bæres af ønsket om at undersøge programmets tekniske struktur - såkaldt reverse analysis - med henblik på at fremstille et ligeartet produkt med samme basale tekniske funktioner, ikke er tilladt efter bestemmelsen. Se dog nedenfor i afsnit 7.4.f.

Rettens ophør

Ophl. § 36 giver ingen regler for, hvor længe det kopierede eksemplar må bestå. Hvis ejeren af eksemplaret spreder dette videre, mister han alene retten til at udnytte det. Ophavsretsloven forbyder ham ikke at beholde sine gamle sikkerhedskopier - blot må disse kopier ikke anvendes uden rettighedshaverens tilladelse, cf. Wagle & Ødegaard (1997), s. 314, der på ophavsretligt grundlag når til, at der gælder en egentlig sletningspligt. Resultatet kan ikke tiltrædes. At søge en sådan pligt gennemført mod en programbruger, der måske slet ingen forudsætninger har for at vide, hvor på hans system det nu bortsolgte program har frembragt ophavsretligt beskyttede eksemplarer af sig selv, må forekomme særdeles problematisk. I særlige tilfælde vil en sådan forpligtelse dernæst kunne gå ud over brugerens mulighed for - lovligt - at anvende den information, der er frembragt ved hjælp af det nu bortsolgte program. De bevishensyn, der kan tale for en sletningspligt, gør sig gældende i begge tilfælde: Det forekommer ligeså vanskeligt for rettighedshaveren at skulle bevise, at der fortsat befinder sig programkomponenter på brugerens udstyr, som det er at bevise, at han rent faktisk bruger dem.

Dermed har lovgiveren viselig undgået at tage stilling til, hvornår en programkopi kan siges at være ophørt med at eksistere. Dette problem dukker imidlertid op med modsat fortegn, nemlig ved overdragelser af (typisk brugte) medier. Hvis man "kun" har slettet programelementerne ved hjælp af de sædvanlige kommandoer hertil, og det ved brug af alment benyttede utilities er muligt at genskabe de slettede filer, må det pågældende medium fortsat betragtes som bærer af et eksemplar, sml. dommen om advokatkontoret i U 1996.1538 ØLK. De fleste styresystemer giver brugeren let mulighed for at genskabe filer, som den uheldige bruger uforvarende har slettet. Man må derfor nå til, at der eksisterer et eksemplar, indtil det fysisk er slettet, f.eks. ved, at mediet reformateres eller overskrives, og at lagermedier med eksemplarer, der kan genskabes med de rette værktøjer, (fortsat) må betragtes som eksemplarer af de pågældende programmer.

Denne antagelse fører bl.a. til en regel om, at overdrageren af et edb-medium, hvorpå der har været indlæst kopier af et beskyttet program, har en ophavsretlig pligt til at reformatere eller overskrive mediet, således at eksemplaret ikke uden videre kan bringes tilveje igen. Bryder han den, overdrager han et eksemplar af det pågældende værk og udsætter sig for de ophavsretlige sanktioner (herunder forbud, erstatning og straf), som dette implicerer.

Password-licenser

Undertiden leveres programmer eller data på lagermedier, som brugeren alene tillades adgang til efter betaling og efter udlevering af password. Dette gælder f.eks. for visse demo-disketter, der med eksemplets magt søger at overbevise kommende brugere om programmets kvaliteter, eller om visse CD-ROM-applikationer, hvor brugerne alene forventes at skulle råde over en del af de indlæste tekster. Den bruger, der ved hjælp af særlige teknikker skaffer sig adgang til sådanne filer, vil enten udføre en uautoriseret eksemplarfremstilling eller hidføre en uautoriseret fremførelse af programmet, jf. nærmere 6.3.f. Det forhold, at brugeren lovligt har mediet i sin rådighed, legitimerer med andre ord ikke sådanne handlinger.

7.4.c. Retten til fejlretning

Som nævnt ovenfor giver ophl. § 36, stk. 1, nr. 1, bl.a. brugeren ret til at rette fejl i programmet. En fejlretning vil altid indebære, at der sker en eksemplarfremstilling af det pågældende program, allerede fordi programmet må befinde sig i RAM, når fejlretningen udføres. Men udover denne nødvendige eksemplarfremstilling vil en fejlretning efter omstændighederne kunne indebære, at værket gøres tilgængeligt for almenheden i en ændret skikkelse, jf. bemærkningerne herom i afsnit 6.2.d. Af hensyn til denne særlige situation er der givet udtrykkelig hjemmel til brugerens fejlretning.

Den tidligere ophl. § 42a fastslog udtrykkeligt, at en aftale om ret til at udnytte et program medfører ret til at foretage sådanne ændringer i programmet, som er nødvendige for den aftalte udnyttelse. Denne adgang fremgår nu forudsætningsvis af ophl. § 36. Adgangen til at foretage ændringer kan fraviges ved aftale, sml. § 36, stk. 4.

Bestemmelsen tager ikke stilling til, hvilken karakter den fejl, der giver ret til at ændre programmet, skal have. I vurderingen af dette spørgsmål må der på den ene side lægges vægt på fejlens mere eller mindre graverende karakter og på den anden side på omfanget af den ændring, der kræves for at rette fejlen. Er der tale om en forholdsvis bagatelagtig fejl, der til gengæld kan rettes gennem en simpel fejlrettelse, må en sådan rettelse være berettiget. Kræves derimod mere omfattende indgreb må man formentlig kræve, at der er tale om mere gennemgribende fejl. Også kontrakts- og forudsætningssynspunkter må spille ind. Fejl, som brugeren har - eller burde have - kendt til inden erhvervelsen kan således ikke begrunde en fejlrettelse.

7.4.d. Aftalelicens

Begrebet "aftalelicens", som det benyttes i ophavsretsloven, dækker over den ordning, loven etablerer, når en repræsentativ organisation af rettighedshavere kan indgå aftale om ophavsretlig udnyttelse af visse værker på rettighedshavernes vegne efter nærmere fastsatte regler. Det særlige ved ordningen består i, at ophl. giver den pågældende organisation eksklusiv kompetence til at indgå sådanne licensaftaler. En enkelt rettighedshaver, der falder inden for den pågældende aftalelicensbestemmelse, kan altså ikke modsætte sig tilladelsen og kræve op på egne vegne. Da aftalelicensreglen for så vidt udgør et indgreb i den enkelte rettighedshavers ret til at disponere over egne værker, kræver regler herom udtrykkelig lovhjemmel. Af samme grund fortolkes de regler, der hjemler en aftalelicens, almindeligvis snævert. Er der hjemmel for aftalelicens til eksemplarfremstilling ved "fotokopiering", kan denne hjemmel ikke anvendes til at fremstille eksemplarer i digital form, selv om den funktionelle forskel kan fortone sig.

En sådan findes i lovens §§ 13-14 (om eksemplarfremstilling af værker inden for henholdsvis undervisnings- og erhvervsvirksomhed mv.), § 17, stk. 5 (om eksemplarfremstilling af værker udsendt i radio eller fjernsyn til syns- og hørehandicappede), § 23, stk. 2 (om gengivelse af kunstværker i visse antologier), § 30 (brug af værker i radio og tv) og § 35 (om kabelspredning).

Det har ved forskellige lejligheder været diskuteret, om der burde tilvejebringes aftalelicens for brug af visse værker i digital form. Ved den lovændring, der fandt sted i 1998, blev ophl. § 13 ændret således, at den aftalelicens, der i forvejen gjaldt efter denne bestemmelse til brug i undervisningsvirksomhed, nu også omfatter eksemplarfremstilling i digital form, herunder via Internet mv. En række forfatterorganisationer havde ellers, med støtte fra bl.a. Forskningsministeriet, lagt pres på Kulturministeriet for at opnå en tilsvarende digital aftalelicens på det erhvervsmæssige område. Men efter stærk modstand fra udgiverside blev denne adgang ikke givet. Derfor er der fortsat kun hjemmel til aftalelicens til eksemplarfremstilling på det erhvervsmæssige område, når det gælder eksemplarer frembragt ved fotokopiering "eller lignende", jf. ophl. § 14. Hvor denne regel på det erhvervsmæssige område vel afgiver hjemmel for aftalelicens til digitalt baseret fotokopieringsudstyr, er der altså ikke hjemmel til at give aftalelicens til digital eksemplarfremstilling i lokale datanet (LAN) eller på Internet. Ønsker brugeren en sådan anvendelse, må de nødvendige aftaler derfor indgås med rettighedshaverne selv.

7.4.e. Særligt klausulerede licenser

Overdragelse af mere kostbare programprodukter, hvad enten disse er standardiserede, tilpassede eller resultatet af en individuel programudvikling, ledsages ofte af licensklausuler, der på forskellig måde begrænser den ret, brugeren ellers ville have i henhold til ophl. § 36. Hvordan denne nærmere afgrænsning skal finde sted - og om dette tema overhovedet skal gøres til genstand for særskilt aftaleregulering - beror på en vanskelig forretningsmæssig afvejning. I denne afvejning indgår navnlig muligheden for at give kunden mest mulig nytte af produktet gennem en udstrakt frihed til at benytte som et hensyn, der står overfor risikoen for, at denne frihed underminerer det økonomiske udkomme af produktet.

Det er ikke ualmindeligt, at programleverandører sætter sig ud over denne afvejning ved at ændre licenspolitik ved næste opdatering af programproduktet. Kunden "lokkes" til at erhverve det pågældende program pga. de frihedsgrader, der gælder for dets første version; men når en senere version skal installeres, er frihedsgraderne snævret ind og betalingen sat i vejret. I denne situation vil en udskiftning koste dyrt i nyanskaffelse, implementering og uddannelse, og mange kunder vil derfor vælge at acceptere denne skærpelse, selv om den for så vidt var uforudset og måske - i bagklogskabens lys - ville have afholdt ham fra at have anskaffet førsteversionen. Risikoen for sådanne forretningsformer kan imødegås, hvis en programlicens er genstand for en forretningsmæssig forhandling, der resulterer i en aftaleregulering af licensvilkårene også for senere versioner.

Som udgangspunkt har parterne fri adgang til at klausulere en ophavsretlig licens. Også her kræver det særlig hjemmel at fravige det almindelige princip om aftalefrihed. En sådan hjemmel findes i de præceptive regler i ophl. § 36, stk. 1, nr. 2, om retten til fremstilling af et sikkerhedseksemplar og § 36, stk. 1, nr. 3, om retten til at besigtige med henblik på at opnå kendskab til bagvedliggende idéer og principper. Herudover kan licensvilkår tænkes at kollidere med den ugyldighedssanktionerede forbudsregel i konkurrencelovens § 6, stk. 2, nr. 5, der - blandt andre vilkår - forbyder sådanne, som stiller som betingelse for indgåelse af en aftale, "at medkontrahenten godkender tillægsydelser, som efter deres natur eller ifølge handelssædvane ikke har forbindelse med aftalens genstand."

Der har endnu ikke været afgørelser om den konkurrenceretlige gyldighed af sådanne klausuler herhjemme, selvom der i aftalepraksis utvivlsomt forekommer mange eksempler på vidtgående bindinger af denne art. Problemstillingen har givet anledning til en vis praksis i USA, jf. i det hele Thomas Riis i Julebog fra Juridisk Institut 1999, s. 33 ff. Kapitel 5 (s. 133-171) i Konkurrencestyrelsens Konkurrenceredegørelse 2000 indeholder en oversigt over nogle af de konkurrenceretlige problemer, der gør sig gældende på det danske marked for softwarelicenser.

Enkeltbrugerlicenser

Ved overdragelse af standardprogrammer til enkelte brugere klausuleres den medfølgende licens ofte således, at brugeren opnår en tilladelse til at fremstille et enkelt eksemplar af programmet og med en begrænsning, der indebærer, at kun licenshaveren selv og dennes ansatte må bruge det pågældende produkt. Bestemmelser af sidstnævnte slags suppleres ofte med klausuler, der forpligter licenshaveren til at hemmeligholde de oplysninger, der opnås gennem denne brug. En sådan aftale rammes ikke af forbudet i ophl. § 36, stk. 4, der alene knytter sig til brugerens ret til selv at opnå den pågældende viden. Det bemærkes i den forbindelse, at § 36 ikke har indbygget en bestemmelse svarende til § 37, stk. 2, nr. 2, om ret til videregivelse af oplysninger til tredjemand.

Flerbrugerlicens

I det omfang, vilkår af den førnævnte art klausuleres således, at flere end brugeren selv opnår ret til at betjene sig af programmet, taler man om en flerbrugerlicens. Sådanne licenser kan udformes på vidt forskellige måder, afhængigt af hvilken type program der er tale om (herunder hvor specielt, henholdsvis standardiseret, dette er), og hvilken licensafgift der forudsættes erlagt (som et engangsbeløb eller løbende).

Site-licens

En ofte anvendt variant er som nævnt den såkaldte site-licens (også kaldet virksomhedslicens eller company license), hvorefter programmer må anvendes på en hel virksomhed, uanset hvor mange medarbejdere eller IT-arbejdspladser, der befinder sig på denne. I sådanne aftaler bør der tages stilling til, hvilken ret medarbejdere har til at anvende programmer på bærbare terminaler, ligesom der bør tages stilling til licensforholdene ved opkobling til systemet udefra. For at sikre sig imod, at konkurrerende leverandører får kendskab til systemet, og måske ligefrem anvender dette kendskab til skade for rettighedshaveren (f.eks. ved at tilbyde programvedligeholdelse), vil rettighedshaveren ofte afskære brug af programmet, der ikke udvirkes af medarbejdere hos brugervirksomheden.

Platforms-licens

En anden type flerbrugerlicens er den såkaldte platformslicens, hvor der gives tilladelse til, at programmet anvendes på en CPU på en bestemt maskinkonfiguration, der f.eks. er præciseret i henseende til mærke, kapacitet og brugerantal mv. (jf. herom nedenfor). Sådanne licensvilkår indgås ofte vedrørende større operativsystemer til mainframe computere.

Brugerbegrænsning

Uanset licensstrukturen vil flerbrugerlicensen skulle tage stilling til, hvilke - og hvor mange - brugere, der må anvende programmet. En variant er den numeriske begrænsning, hvorefter kun et bestemt antal brugere må anvende programmet. Dette antal kan da enten beregnes som antallet af samtidige brugere (hvilket alt andet lige vil føre til en højere licensafgift pr. bruger) eller som et antal mulige brugere (hvorved licensbetalingen pr. bruger vil være lavere, men brugerintensiteten til gengæld også lavere). En række tekniske og økonomiske forhold vil være afgørende for valget mellem disse forskellige typer af udformninger.

- antal mulige brugere

For et program, som erfaringsmæssigt bruges fra morgen til aften (f.eks. styresystemer eller applikationsprogrammer til f.eks. regneark eller tekstbehandling), har leverandøren interesse i at knytte brugsretten til antallet af mulige brugere. En sådan klausulering er ligeledes lettere at håndtere for brugeren, idet risikoen for flaskehalsproblemer reduceres.

- samtidige brugere

Derimod vil programmer, der typisk anvendes under mere enkeltstående funktioner (f.eks. visse databaseprogrammer mv.), oftere være klausuleret ud fra, hvor mange samtidige brugere der kan kobles op på denne applikation. I sådanne tilfælde vil leverandøren typisk forsyne programmet med en anordning, der registrerer, hvor mange samtidige brugere der er koblet på, og lukker ned, når grænsen er nået. Sådanne anordninger har til gengæld den for brugeren besværlige - men jo altså tilsigtede - virkning, at programmet ikke er tilgængeligt, når grænsen er nået.

Udfyldning

Typeforudsætningslæren har dog også gyldighed ved forståelsen af flerbrugerlicensens rækkevidde, for så vidt disse licenser ikke tager klart stilling til, om en bestemt udnyttelsesform (f.eks. ved aftaler om facility management eller outsourcing) er tilladt. Ifølge de i afsnit 7.4.b. citerede bemærkninger til 1989-lovforslaget ligger det således klart, at "nødvendig brug" ikke indebærer en ret til at kopiere programmet på en måde, så flere brugere (uden at have særskilt tilladelse) samtidigt kan betjene systemet fra flere arbejdspladser hos brugeren. Er der f.eks. givet en licens til to brugere, må dette betyde "to samtidige brugere", der betjener systemet fra hver sin terminal, jf. mine bemærkninger a.st.

Betaling

Aftaler om flerbrugerlicenser rejser et vanskeligt problem om, hvad der skal betales: Hvor det er forholdsvis enkelt for leverandøren at føre en fast prispolitik mht. enkeltbrugerlicenser, kan det volde større vanskelighed at fastslå betalingspligten for et program, som alle i en virksomhed i princippet gerne skulle kunne have adgang til, selvom det ligger klart, at de færreste medarbejdere vil få reelt brug for den i det daglige. Forhandlingerne om disse spørgsmål baseres undertiden på et princip om, at der skal erlægges et beløb, der giver rettighedshaveren en passende kompensation, f.eks. ud fra en vurdering af, hvor mange brugere der gennemsnitligt kan forventes at bruge programmet. En anden kilde til tvivl opstår for brugere, der driver virksomhed på tværs af landeskel, og som ønsker at installere programmet i flere lande samtidigt.

Andre licensformer

Udover de førnævnte typer af licenser, støder man på særlige licensklausuler i forbindelse med softwareudvikling. Et praktisk eksempel herpå er den såkaldte run time-licens, som giver brugeren ret til at indbygge et program i et andet program, som herefter under ét gives i licens til slutbrugeren.

7.4.f. Reverse analysis

Problemstillingen

Læser man ophl. § 36, stk. 1, nr. 1, isoleret, forbyder den brug af et program, der ikke tilsigter anvendelse af dets funktioner (tekstbehandling, regneark, e-post mv.), men som kun har til hensigt at aflure dets tekniske egenskaber med henblik på plagiering. Dette følger af, at § 36, stk. 1, nr. 1, henviser til brugerens subjektive formål. Og leverandørens tanke med at give brugeren licens til et program er jo så åbenbart ikke at gøre brugeren til sin konkurrent!

Analyse

For at muliggøre den udveksling af almindelige oplysninger om programmers funktionalitet mv., der er nødvendig for at understøtte den teknologiske udvikling, kan det være nødvendigt at benytte programmet på en måde, der ikke er nødvendigt af hensyn til den praktiske brug, jf. ophl. § 36, stk. 1, nr. 1. Ifølge samme bestemmelses stk. 1, nr. 3, er det imidlertid tilladt den lovlige bruger af et program - uden rettighedshaverens tilladelse - at besigtige, undersøge eller afprøve programmet for at fastslå, hvilke idéer og principper der ligger til grund for de enkelte elementer af det. Det kræves blot, at disse undersøgelseshandlinger finder sted i forbindelse med en indlæsning, visning, kørsel, overførelse eller lagring af programmet, som licenstageren i øvrigt er berettiget til at foretage.

Black box-analyse

Med denne regel er der skabt grundlag for gennemførelse af en såkaldt black box-analyse af edb-programmer. Hermed sigtes til undersøgelseshandlinger, der udelukkende retter sig mod de data, programmet modtager og afgiver, men som ikke indebærer nogen kopiering eller transformering af selve programmet udover den, programmet er beregnet til selv at foretage. Sådanne former for analyse kendetegnes ved at kunne ske på grundlag af en kopiering svarende til den, en "almindelig" bruger vil være nødt til at udvirke.

Grænsen mellem de kopieringshandlinger, der har denne karakter, og den egentlige dekompilering, jf. herom nedenfor, kan være vanskelig at drage. I NIR 1992.79 antager Thomas Vinje, at brugeren f.eks. har ret til at udvirke hexadecimale skærmbilleder af objektkoden på skærmen. Dette resultat kan kun tiltrædes i det omfang, en "sædvanlig" bruger vil have anvendelse for den således frembragte kopi af objektkoden, hvilket nok vil høre til undtagelsen. Plogell (1996), s. 43, antager, at den ret, brugeren har til at ændre programmet i medfør af den legale programlicens, "teoretiskt sett" også giver ret til at dekompilere, f.eks. ved brug af såkaldte linetracers eller disassemblers, altså værktøjer, der giver indblik i, hvorledes bestemte elementer i programmet fungerer. Heller ikke denne antagelse kan tiltrædes. Var denne mulighed åben i medfør af ophl. § 36, stk. 1, nr. 3, ville den ganske opsluge anvendelsesområdet for § 37 og gøre denne bestemmelses enkelte betingelser overflødige.

Informationstilegnelse

§ 36, stk. 1, 3. pkt., indebærer f.eks., at det er tilladt at anvende et program for at tilegne sig information om dets brugergrænseflade, også selv om dette sker med henblik på frembringelse af et andet program, der dækker samme marked. Betingelsen er blot, at brugeren af det pågældende program har "ret til at benytte" det, og at de eksemplarfremstillinger mv., der udføres med henblik på at tilegne sig den pågældende information, i øvrigt ligger indenfor den gældende licens (sådan indlæsning, visning på skærm, kørsel, overførsel, lagring eller lign. af programmet, som vedkommende er berettiget til at udføre). I modsætning til lovens § 37 gælder der ingen begrænsninger i, hvorledes den pågældende information kan anvendes. Der er således intet til hinder for, at informationen spredes videre til almenheden, f.eks. i forbindelse med et offentligt udbud, jf. om disse regler afsnit 21.2.d.

7.4.g. Reverse engineering

Udtrykket reverse engineering stammer fra læren om erhvervshemmeligheder. Her er det almindeligt antaget, at almenheden (og konkurrenterne) har en ret til at trække tekniske oplysninger ud af produkter, der findes i den almindelige handel, ved at skille dem ad mv. En sådan ret gælder principielt også for edb-produkter. Problemet ved at udføre reverse engineering på edb-programmel er imidlertid, at det typisk kun er muligt at se "indmaden" i et program ved at frembringe eksemplarer af det, enten som forskellige stadier af arbejdskopier i en proces, der fører til en dekompilering af koden, eller som de teknisk nødvendige maskin-kopier, der nødvendigvis skal ske til RAM, når processen udføres. Der er tale om en arbejdskrævende proces, der bl.a. indebærer en analyse af hver af de processor-instruktioner, programmets objektkode genererer. Opgaven består altså ikke i, populært sagt, at sætte program-oversætteren (compileren) i bakgear. En sådan mulighed findes ikke ved generering af objektkode, ligeså lidt som det lader sig gøre at frembringe det oprindelige stykke kød ved at køre kødhakkemaskinen baglæns.

Ophl. § 37, der har rod i art. 6 i direktiv 91/250/EØF, regulerer kun en del af den proces, der almindeligvis betegnes som reverse engineering. Bestemmelsen tillader visse former for kopiering - udført i forbindelse med såkaldt dekompilering - når denne sker med henblik på at skabe interoperabilitet mellem det kopierede program og et selvstændigt udviklet edb-program. Begrebet interoperabilitet beskriver det forhold, at to programmer kan fungere sammen, på samme måde som en CD kan afspilles på en CD-maskine og to Lego-klodser kan sættes sammen. Reglerne hviler på et udgangspunkt om, at dekompilering som hovedregel er forbudt. Men hvis den sker med henblik på interoperabilitet kan den være beføjet inden for de rammer, bestemmelsen sætter.

Bestemmelsen er meget vanskelig at læse. Vanskelighederne skyldes ikke alene det komplicerede tekniske problem, der ligger bag, men også den intense politiske kontrovers, der førte til dens indførelse. Denne kontrovers udspringer af et skisma mellem på den ene side hensynet til rettighedshaverens eneret, og på den anden side en konkurrenceretlig interesse i at undgå, at eneretten til et enkelt værk de facto forvandler sig til en eneret også til forskellige typer af omkringliggende værker i form af tilbehør mv. Se hertil Jens Schovsbo i NIR 1997.29 f.

"Dekompilering"

Selv om ordet "dekompilering" sprogligt udgør en modsætning til "kompilering", er der tale om to principielt forskellige begreber. Hvor kompilering (eller oversættelse) sker i en automatiseret proces, der styres af en compiler, og som kun kan udføres på én måde, er dekompilering en principielt anderledes proces. Udgangspunktet er et kendskab til de funktioner, programmet udfører under anvendelsen, f.eks. en måde at kommunikere med en hardware-enhed på. Med dette udgangspunkt udføres en arbejdskrævende proces, der ved at udsætte programmet for en række påvirkninger søger at rekonstruere centrale dele af den bagvedliggende kildetekst. Opgaven består så at sige i at arbejde sig baglæns fra den digitale objektkode til det instruktionssæt, der ligger bag. Kompleksiteten af denne proces beror på det anvendte programmeringssprog: Ganske få linjer kildekode kan i kompileret stand resultere i et antal programlinjer, der er hundrede eller tusinde gange større. Se generelt til problemstillingen Bjerke i Complex 9/1994.

Hvor vanskeligt det er at gennemføre en dekompilering beror på programmets karakter. Java-programmer er f.eks. følsomme overfor dekompilering, fordi programmet kompileres til et mellemkodestadium, inden det omdannes til maskinkode. Fra dette stadium er det forholdsvis enkelt at gennemføre dekompileringen: De enkelte instruktioner er relativt enkle at identificere, omend programmørens bemærkninger og kommentarer ikke er. Trods den lethed, hvormed man kan nå dette mellemkodestadium, gælder de almindelige regler om dekompilering. Reglerne må i den forbindelse ses i sammenhæng med den almindelige legale programlicens med dens formålsbeskrivelse - ikke som et udtryk for, at den, der dekompilerer et program, må belønnes for sin indsats herved.

Hvem må dekompilere?

Ifølge ophl. § 37, stk. 1, nr. 1, må dekompilering for det første kun 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. Dette sidste led i bestemmelsen synes at forudsætte, at retten til at dekompilere kan delegeres til andre end licenshaveren. Denne situation vil da også være den praktisk forekommende, eftersom de færreste edb-brugere vil have ekspertise til selv at forestå disse handlinger.

Hemmeligholdelse

Bestemmelsen har ikke taget stilling til, om reverse engineering er tilladt, hvis licensaftalen indeholder en hemmeligholdelsesaftale. På den ene side kan man argumentere for, at en sådan aftale ikke kan være bindende, da retten til reverse engineering er præceptiv, jf. ophl. § 37, stk. 3. Heroverfor står det synspunkt, at en hemmeligholdelsesaftale etablerer et særskilt immaterialretligt retsværn, jf. mfl. § 10, der går på tværs af reglerne i ophavsretsloven, jf. nærmere afsnit 10.5.b., og som principielt er ligeværdigt med andre industrielle rettighedsformer (som f.eks. patentretten og brugsmodelbeskyttelsen).

Efter min opfattelse har det sidstnævnte synspunkt mest for sig. Ifølge art. 9, stk. 1, i direktiv 91/250/EØF viger direktivet for andre retsforskrifter, herunder vedrørende patenter og forretningshemmeligheder. Den begrænsning i adgangen til at udføre reverse engineering, der følger af at anerkende aftaler om hemmeligholdelse, adskiller sig ikke mærkbart fra den, der følger af at skulle anerkende patentretlige begrænsninger. Hemmeligholdelsesvilkår er almindeligt forekommende i licensaftaler om mere kostbare standardprogrammer, hvor de også søges håndhævet efter deres indhold.

Denne antagelse fører dog ikke til, at man blot ved at indbygge en "hemmeligholdelsesaftale" i en licensaftale - f.eks. i en shrink wrap-licens - kan bringe sig uden om det præceptive forbud i ophl. § 37, stk. 3. Der skal være tale om et aftalemæssigt arrangement, som reelt sigter til at bevare de hemmeligheder, programmet indeholder, og som også søges håndhævet med dette formål. Har aftalen alene til formål at undgå brugerens ret til reverse engineering, rammes den af præceptiviteten. Dette vil i praksis altid ske for shrink wrap-aftaler, der jo kendetegnes ved, at rettighedshaveren end ikke kender sin licenstager og derfor heller ikke ved, hvem han deler sin "hemmelighed" med.

Tredjemandsbistand

Man kan diskutere, under hvilke rammer tredjemand kan udøve reverse engineering på programmet. Af det førnævnte følger, at en licenstager - hvor der ikke er aftalt hemmeligholdelse - kan lade tredjemand udføre reverse engineering på licenstagerens egen installation og under anvendelse af den licens, der er erhvervet for den pågældende installation, se § 37, stk. 1, nr. 1, in fine. Disse spørgsmål må løses på grundlag af en fortolkning af ophl. § 36. Som tidligere anført kan § 36 næppe give grundlag for en regel om, at der kun må sidde en enkelt person ved den terminal, hvorfra programmet afvikles. Brugeren må som udgangspunkt godt lade en rådgiver eller kollega "sidde med" ved skærmen. Lægges dette resultat til grund, må det også antages, at brugeren kan lade en rådgiver betjene sig af programmet, hvis blot brugeren ikke gør det. Licensen genbruges jo i så fald ikke. Denne frihed kan dog være afskåret i kontrakten, jf. ophl. § 36, stk. 4, modsætningsvis. Af denne regel følger, at reglerne om den legale programlicens netop ikke er præceptive.

Derimod kan licenstageren ikke overdrage et eksemplar af programmet til tredjemand med henblik på, at denne på eget udstyr skal foretage de nødvendige analyser for derefter at levere programmet tilbage til den egentlige bruger. En sådan handling vil blive betragtet som "udlån" uden for den private sfære, der må anses for afskåret gennem reglen i ophl. § 19, stk. 3. Derimod er det tvivlsomt, om en udefra kommende rådgiver har ret til at benytte en enkelt brugers licens til programmet gennem en opkobling udefra, der foretages på brugerens vegne (således at denne ikke samtidig gør brug af programmet). Spørgsmålet bør løses med udgangspunkt i en fortolkning af den pågældende licensaftale.

Plagiering

Ifølge ophl. § 37 er der ikke ret til at udføre reverse engineering, hvis formålet er at frembringe et program, der plagierer det oprindelige program, se herved § 37, stk. 2, nr. 1) - 2). Det fremgår heraf, at formålet med handlingen skal være at gøre et selvstændigt udviklet edb-program interoperabelt. At det program, reverse-ingeniøren forbereder, vil konkurrere med det eksisterende program, er ikke til hinder for reverse engineering, uanset om konkurrencen retter sig mod givne IT-funktioner. Netop denne konkurrencemæssige problemstilling var en af hovedårsagerne til den så intense debat, der gik forud for reglernes vedtagelse i 1991. Indenfor de ovennævnte rammer er der imidlertid intet til hinder for, at licenstageren lader en potentiel budgiver udføre den dekompilering, der er nødvendig for at kunne specificere grænsefladen. Betingelserne for at overlade en sådan opgave til tredjemand er de samme, hvad enten tredjemand opererer som konsulent eller som potentiel leverandør til licenstageren.

Offentliggørelse

Ifølge § 37, stk. 1, nr. 2, er dekompilering ikke tilladt, såfremt de oplysninger, der er nødvendige for at tilvejebringe interoperabilitet, tidligere har været og er let og hurtigt tilgængelige for den personkreds, der har ret til at udføre dekompileringshandlingerne. Denne regel, der har historisk udspring i de konkurrenceregulerende vilkår, Kommissionen havde pålagt en større IT-virksomhed (IBM), indebærer, at rettighedshaveren har mulighed for helt at afskære dekompileringshandlingen ved blot at offentliggøre de pågældende grænseflade-specifikationer. Bestemmelsen tager ikke stilling til, om rettighedshaveren kan forlange nogen betaling for at stille disse oplysninger til rådighed. I det omfang, rettighedshaveren kan siges at have egentlige udgifter i forbindelse hermed, må det formentlig være berettiget at opkræve en betaling, der nogenlunde modsvarer disse udgifter. I den forbindelse kan man skele til den praksis, der er fastlagt ved visse standardiserings-organisationer (herunder ETSI), og som tillader en ikke-diskriminerende betalingsopkrævning, såfremt en standard er omfattet af immaterielle rettigheder, jf. herom afsnit 5.3.g.

Afgrænsning

§ 37, stk. 1, nr. 3, fastslår for det tredje, at dekompileringshandlingerne skal være begrænsede til "de dele af det oprindelige edb-program, der er nødvendige for at opnå interoperabilitet". På grund af denne bestemmelse vil det være i rettighedshaverens interesse at strukturere et program således, at de dele af det, der rummer grænseflade-specifikationerne, findes i klart afgrænsede elementer af programmet. Er der, som det ofte forekommer i dag, tale om objektorienteret programmering, hvor de forskellige dele af programmets funktioner er henlagt til forskellige moduler, vil det være muligt at lægge oplysningerne om interoperabilitet i en "object class", som i så fald kan dekompileres efter de i øvrigt gældende regler herfor.

Erhvervshemmeligheder

Ifølge § 37, stk. 2, gælder der særlige begrænsninger i, hvorledes den dekompilerende part kan råde over den herved indvundne information. For det første må vedkommende ikke benytte de indhentede oplysninger til andre formål end at gøre det selvstændigt udviklede edb-program interoperabelt. Oplysningerne må med andre ord betragtes på samme måde som erhvervshemmeligheder, jf. mfl. § 10, altså uden ret til at videregive oplysningerne til andre. Dette forbud gælder formentlig uanset, om modtageren af de pågældende oplysninger underkaster sig en erhvervshemmeligholdelsespligt, for hvor skulle grænsen i givet fald gå? En åbning for muligheden af at indføre sådanne forpligtelser ville dernæst skabe usikkerhed om, hvilke formål der kunne begrunde en overførsel til tredjemand. Visse formål ville f.eks. falde lige for (herunder konsulentpræget bistand ved programudviklingen) hvorimod andre ville falde klart uden for (f.eks. visse handlinger, der kunne forberede frembringelsen af et plagiatprodukt).

I USA er spørgsmålet om reverse engineering ikke reguleret af Copyright Act; men i praksis tegner der sig gradvis en retsopfattelse, der harmonerer med europæisk ret efter 1991-direktivet, baseret på principperne om "fair use". I sagen Atari Games Corp. v. Nintendo of America Inc. , 975 F.2d 832 (1992) antog CAFC, at midlertidig kopiering med henblik på reverse engineering indebar "fair use", der som sådan ikke kolliderede med den ophavsretlige eneret. Et tilsvarende resultat nåede appelretten for 9. circuit til i et tilfælde, hvor reverse engineering var den eneste måde at skabe et konkurrerende værk, se Sega Enterprises, Ltd. v. Accolade, Inc. , 977 F.2d 1510 (1992) og Sony Computer Entertainment v. Connectix Corp, 203 F.3d 596 (9th Cir., 2000). Afgørelsen i Aymes v. Bonnelli, 47 F.3d 23 (1995) antog tilsvarende, at den lovlige bruger af et eksemplar af et program havde ret til at ændre det med henblik på at opdatere dets funktioner til det forudsatte formål.

Clean room-teknik

For at imødegå indsigelser om, at det udviklede program plagierer kildetekst fra det program, der har været genstand for reverse engineering fra udviklerens side, anvender man ofte såkaldte clean room-teknikker. Teknikken går i korthed ud på, at de programudviklere, der skal frembringe det nye program, afsondres fuldstændigt fra de medarbejdere, der forestod arbejdet med at dekompilere. Teknikken er kort omtalt hos Schmidt (1989), s. 238 f. og af Bing NIR 1999.290 f.

7.4.h. Programdistribution

Karakteristik

En aftale om distribution af programmel involverer to typer af transaktioner. Dels rummer aftalen et licenselement, idet rettighedshaveren giver tilladelse til, at det distribuerede program gøres til genstand for en eksemplarfremstilling og spredning, som ellers ville falde inden for hans eneret, jf. ophl. § 2, stk. 1 og 3. Dels - og i logisk forlængelse heraf - rummer aftalen et element af distribution, idet den tilladelse (licens), som rettighedshaveren giver hertil, tilsigter at nå et marked, der normalt vil være afgrænset som ved anden distribution, jf. herom i det hele PA s. 590 ff.

Øjemeddet tilsiger ikke, at der på dette sted gives en mere udtømmende gennemgang af de reguleringstemaer, der bør indgå i en sådan distributionsaftale. I overskriftsform kan det dog fremhæves, at parterne i det mindste bør aftale, hvad det nærmere er for produkter, der er omfattet af distributionsretten, vederlaget herfor, om distributionsretten er eksklusiv eller ikke (samt i givet fald, hvilket territorium distributionsretten gælder for), prissætningen i slutbrugerleddet, samt hvilken rollefordeling parterne ønsker i henseende til praktiske anliggender som f.eks. retshåndhævelse mv.

Distributionsformer

IT-retten kender mange eksempler på programdistribution, der er formet efter de særlige behov på IT-området.

- OEM/VAR

En hyppigt forekommende distributionsform er den såkaldte OEM-aftale (OEM = Original Equipment Manufacturer), der indebærer, at distributøren får ret til at distribuere det nævnte produkt, som om det var hans eget. Sådanne aftaler benævnes ofte også som Value Added Reseller Agreements (eller blot VAR-aftaler), fordi distributøren ofte forædler produktet med yderligere funktionalitet mv. eller ved at levere det i samspil med andre produkter. Producenten vil som regel kun have interesse i at indgå en sådan aftale, hvis han ikke selv planlægger at konkurrere inden for det nævnte område. Dette spørgsmål kan dog give anledning til særlig regulering (grænsedragning) af den art, der er velkendt inden for læren om distribution.

Som nævnt i PA s. 613 rejser aftalen bl.a. spørgsmål om, hvorledes distributøren skal forholde sig overfor krav, som han ifølge produktansvarslovens § 4, stk. 1, hæfter for, men som må tilskrives producentens forhold. Andre problemer opstår omkring retten til de forbedringer, OEM-forhandleren indbygger i produktet.

- Tredjepartsprogrammel

Som led i nutidens IT-implementering er det den praktiske regel, at der indgår et større eller mindre element af såkaldt tredjepartsprogrammel. Herved forstås programmel, som leverandøren leverer på licens fra en underleverandør (tredjepartsleverandøren) med henblik på indbygning som ingrediens i leverandørens endelige produkt. Indbygningen kan enten ske i fuldt integreret form, hvor slutbrugeren ikke ser, at det leverede system er opbygget gennem komponenter fra forskellige tredjepartsleverandører, eller som en kombineret komponentleverance, hvorved der leveres en flerhed af applikationer (f.eks. en Windows-baseret kontorpakke med Wordperfect-tekstbehandlingsprogrammel) i en samlet leverance.

Det definitoriske krav om, at produktet - for at blive betragtet som tredjepartsprogrammel - skal indgå som ingrediens i det færdige produkt indebærer bl.a., at et oversætter-program ikke betragtes som sådant: Når et program oversættes fra kildetekst til objektkode ved hjælp af et oversætterprogram, får man en ny version (objektkodeversionen) af det gamle program, men oversætterprogrammet har dermed udtømt sin rolle og følger ikke med som ingrediens. En omfattende undersøgelse af de juridiske, tekniske og kommercielle problemstillinger ved indkøb og brug af programmel fra underleverandører foreligger med Jan Villumsen & Mads Bryde Andersen: Indkøb og brug af programmel fra underleverandører (november 1993). Rapporten er udgivet af DELTA - Dansk Elektronik, Lys & Akustik for Datateknisk Forum.

Aftaler om integreret tredjepartsprogrammel giver anledning til vanskeligheder ved fastlæggelsen af de driftsmæssige krav til programmet: Hvad kan slutbrugeren forvente, og hvem hæfter for, at disse krav ikke er opfyldte? Man vil ofte stå overfor den velkendte problemstilling, at systemet ikke fungerer, men at ingen med sikkerhed kan sige, hvorfor. De spørgsmål, der her opstår i relation til slutbrugeren, drøftes nærmere i kapitel 22. Problemstillingen giver ofte anledning til vanskelige forhandlinger med slutbrugeren under aftaleforhandlingen. Brugeren vil ofte forvente, at leverandøren hæfter for tredjepartsprogrammets funktionalitet på samme måde som han hæfter for egne ydelsers funktionalitet, men leverandøren vil ofte værge sig herimod, da hans muligheder for at påvirke denne funktionalitet - uden rådighed over kildeteksten - vil være begrænsede.

Gennemgående temaer

Blandt de spørgsmål, der ofte indgår i aftaler vedrørende tredjepartsprogrammel, kan peges på følgende:

- rettigheder

Et af de mest centrale reguleringstemaer drejer sig om karakteren af de immaterielle retspositioner, der går over fra tredjepartsleverandøren til leverandøren (og derfra til slutbrugeren): Er meningen, at tredjepartsprogrammet integreres i den færdige løsning, vil aftalen mellem parterne almindeligvis forme sig som en almindelig licensaftale, der må fortolkes i overensstemmelse med det almindelige ophavsretlige specialitetsprincip, jf. ophl. § 53, stk. 3: Retten til at forhandle tredjepartsprogrammet vil f.eks. være begrænset til en bestemt type af applikationer, med virkning for et bestemt territorium og med bestemte mængdemæssige begrænsninger mv. - sidstnævnte bl.a. for at imødegå risikoen for immaterialretlig ekstinktion, jf. nærmere herom afsnit 12.3. Leveres tredjepartsprogrammet derimod som en komponentleverance (f.eks. som et tekstbehandlingssystem, der leveres sammen med et system til drift af lokalnet) er reguleringsbehovet begrænset: Slutbrugerens ret til at benytte programmet vil her skulle udledes af ophl. § 36 på ganske samme måde, som hvis programmet var erhvervet i den almindelige handel. Af samme grund tager de følgende bemærkninger primært sigte på ingredienstilfælde.

- slutbrugerrelationen

Visse leverandører stiller krav om, at der skal indgås særskilte licensaftaler med slutbrugerne, eventuelt effektueret i et direkte aftaleforhold mellem tredjepartsleverandøren og slutbrugeren. En sådan ordning anses dog generelt for at være upraktisk, da den ofte - konsekvent udført - vil resultere i ganske komplekse aftalerelationer mellem slutbrugeren og de ofte mange tredjepartsleverandører, der har leveret software-ingredienser til den endelige løsning. Det praktiske udgangspunkt er derfor, at aftaleforholdet med tredjepartsleverandøren reguleres i aftalen mellem slutbrugeren og leverandøren gennem en inkorporering af de licensvilkår, tredjepartsleverandøren har fastsat.

- kontrolforanstaltninger

For at styre leverandørens eksemplarfremstillinger vil tredjepartsleverandøren ofte indbygge anordninger, der indbygger et serienummer i hvert kopieret program eller udstyre dette med en nøgle, som skal tilvejebringes ad anden vej. Sådanne ordninger følges ofte op med procedurer, hvorefter leverandøren skal udarbejde produktionslister med serienumre for de produkter, tredjeparts-programmet indgår i. Kontrollen med disse lister kan variere, jf. generelt herom PA s. 231 ff.

- hemmeligholdelse

Som i andre distributionsaftaler vil det ofte forekomme, at producenten (leverandøren af tredjepartsprogrammet) i tillæg til selve licensen til programmet yder distributøren nogle tjenester, som udspringer af den knowhow, producenten har opbygget til sit program. Denne knowhow kan bl.a. dreje sig om, hvorledes programmet implementeres under forskellige tekniske eller driftsmæssige omstændigheder, eller om hvordan forskellige typer af kundeproblemer løses. Da information af denne art ofte vil have stor kommerciel værdi for producenten (bl.a. fordi den vil muliggøre en intens konkurrence med dennes produkter), vil producenten typisk ønske at belægge den med en pligt til hemmeligholdelse.

- kildetekstlicens

Hemmeligholdelsesforpligtelser vil i sagens natur også være aktuelle, hvis aftalen indebærer, at distributøren får rådighed over kildetekst. En adgang hertil kan f.eks. tænkes, når leverandøren har påtaget sig en pligt til at vedligeholde, tilpasse eller videreudvikle programmet. På grund af kildetekstens ekstremt følsomme karakter vil sådanne forpligtelser ofte være tæt klausuleret, f.eks. således at licensen alene gælder for særligt udpegede personer og under en løbende kontrol fra tredjepartsleverandørens side.

Support

Som nævnt vil leverandøren ofte påtage sig at supportere det samlede system, der leveres til slutbrugeren, dvs. også den del, der indeholder tredjepartsprogrammel. Uanset om en sådan vedligeholdelsespligt sker på grundlag af en kildetekstlicens eller ikke, vil mulighederne for at løse konkrete problemstillinger typisk lettes, hvis man har adgang til "intern" viden om systemet og dets opbygning. For at gøre denne viden tilgængelig, indbygger man ofte en forpligtelse for tredjepartsleverandøren til at yde særlige tjenesteydelser herom, både med sigte på den praktiske implementering i den enkelte transaktion og til brug for den efterfølgende vedligeholdelse.

- særlige spørgsmål

Foruden de førnævnte mere almene spørgsmål vil aftaler om programdistribution efter omstændighederne berøre en række specifikke spørgsmål. Et eksempel herpå er den aftaleretlige håndtering af de begrænsninger, der kan være forbundet med eksport af software, der kan indeholde komponenter af militærstrategisk betydning, til præsumptivt fjendtlige tredjelande, jf. nærmere herom afsnit 21.2.e.

Retsgrundlag

Aftaler om distribution af edb-programmel er som udgangspunkt ikke undergivet særlig lovregulering. Med handelsagentloven, lov nr. lov nr. 272 af 2. maj 1990 (herefter HAL) er der imidlertid indført særlige regler om distribution gennem handelsagentur, der efter omstændighederne kan få betydning også for programdistribution. Loven bygger på rådsdirektivet af 18. december 1986 om samordning af medlemsstaternes lovgivning om selvstændige handelsagenter (86/653/EØF), EFT 1986 L382/17, og er således EU-harmoniseret lovgivning. Da en del af lovens regler er præceptive (herunder navnlig reglerne i §§ 25-29, der hjemler handelsagenten ret til godtgørelse ved ophør), knytter der sig en betydelig interesse til at få fastslået lovens rækkevidde.

I U1995B.169 ff. har jeg gjort dette spørgsmål til genstand for en mere dybtgående analyse. De følgende bemærkninger bygger delvis herpå.

HAL regulerer visse typer af aftaler mellem en producent og en distributør, nemlig, jf. lovens § 2, aftaler, der involverer, at handelsagenten for agenturgiverens regning påtager sig "selvstændigt og vedvarende at virke for salg eller køb af varer ved at indhente tilbud (ordre) til agenturgiveren eller ved i dennes navn at indgå aftale herom". Enkeltstående dispositioner eller dispositioner, der indebærer, at distributøren indgår i et ansættelsesforhold for agenturgiveren, er ikke omfattet af loven.

Lovens varebegreb

Det springende punkt for, om HAL regulerer en softwaredistribution, er afgrænsningen af begrebet "varer". Anvendelsen af dette begreb skyldes, at loven oprindelig tog sigte på den egentlige varedistribution. Der er i den forbindelse enighed om, at fast ejendom, skibe, immaterialrettigheder, værdipapirer samt egentlige tjenesteydelser falder uden for begrebet. I grænsetilfælde - hvor der såvel formidles salg af varer som tjenesteydelser - er det ifølge lovens forarbejder afgørende, om varesalget er et dominerende element i aftalen. Således vil salg af fotokopieringsmaskiner med tilhørende service være omfattet af loven, hvorimod leverandører af rengøringssystemer, hvori også indgår salg af rengøringssystemer og -produkter, næppe vil være det.

Standardprogrammel

Om edb-programmel udtaler betænkningen om handelsagenter, nr. 1151/1988, s. 43: "Standard-edb-programmel, som markedsføres i mange eksemplarer, må anses som »varer«, hvorimod individuelt udviklede programmer snarere må opfattes som tjenesteydelser, hvis aftalen i overvejende grad vedrører levering heraf". Sædvanligvis defineres standardprogrammel som programmer, der er udviklet med henblik på massedistribution til vidt forskellige brugere med samme databehandlingsbehov. Denne begrebsafgrænsning peger på et velkendt marked af programmer, der typisk overdrages i »pakker« og under velkendte varemærker (»WordPerfect«, »Lotus 1-2-3«, »Windows« osv.). Det må antages, at hyldevareprogrammel, der ikke distribueres med tillægsydelser i form af implementering og tilpasning, falder uden for HAL, jf. mine bemærkninger i U1995B.172 f. Dette har f.eks. betydning i relation til de såkaldte standardramme-systemer. Sådanne systemer vil være omfattet af HAL, hvis de distribueres i ubearbejdet form. Ledsages distributionen derimod af et væsentligt element af tilpasning, vil transaktionen falde uden for. I denne afgrænsning spiller det også ind, hvilke ophavsretlige beføjelser, brugeren indtræder i. Opnår brugeren alene de ophavsretlige beføjelser, der er nødvendige for sin brug, taler dette for en vareanalogi. Udstyres han derimod med beføjelser til f.eks. at videresælge programmet taler dette for, at man er uden for loven. Grænsedragningen kan volde vanskeligheder i tilfælde, hvor brugeren udstyres med en licens til at foretage forandringer eller videreudviklinger af programmet.

Mellemformer

Grænsen kan også volde tvivl på markedet for de lidt mere kostbare systemer, hvor det indgår som en indarbejdet del af leverandørens ydelse at foretage den nødvendige tilpasning af programvaren, eller hvor overdragelsen kun kan ske, hvis leverandøren forinden har foretaget en teknisk afklaring af brugerens driftsmæssige forudsætninger mv. Her må formodningen være for, at HAL ikke gælder, hvorved udgangspunktet om aftalefrihed slår igennem fuldt ud.

Indholdsfortegnelse | Forrige afsnit | Næste afsnit