Indholdsfortegnelse | Forrige kapitel | Næste kapitel

Kapitel 7. Programbeskyttelsen

7.1. Almene spørgsmål

7.1.a. Det retssystematiske valg

Konsekvenser

At man rubricerer programkode som et litterært værk indebærer, at genstanden for den ophavsretlige beskyttelse samt beskyttelsens retsvirkninger (varighed, eneret mv.) dermed er lagt fast. Herom gælder - medmindre andet er bestemt - ophavsretslovens regler om litterære værker. Derimod er det imidlertid ikke givet, at selve retsanvendelsen i enhver henseende skal ske i overensstemmelse med den tradition, ophavsretten har udviklet for andre litterære værker. For det første giver loven en række særregler om edb-programmer, se f.eks. § 12, stk. 2, nr. 3, § 19, stk. 3, §§ 36-37, § 59 og § 78. For det andet fremtræder edb-programmer på talrige punkter markant anderledes end andre litterære værker. Der foreligger med andre ord et beskrivelsesproblem, som den juridiske teori og praksis må søge at løse.

Brugerens synsvinkel

Som anført i den historiske redegørelse har selve indplaceringen af programkoderne som en særlig slags "litteratur" ikke været uproblematisk, eftersom programmer i iøjnefaldende henseender adskiller sig fra andre litterære værker. Programmet "læses" ikke af brugeren, men af processoren, og "læsningen" sker med henblik på rent tekniske funktioner. Selv om man anskuer processoren som brugerens forlængede arm, kan der påpeges forskelle. Hvor læseren af et litterært værk ved, hvad han læser, ved brugeren ikke nødvendigvis, hvilke programmer systemet anvender, og hvordan (et problem, der - som det fremgår af afsnit 6.3.b. - bl.a. volder vanskeligheder for afgørelsen af, hvornår der foreligger eksemplarfremstilling). Dertil kommer, at ét og samme program - uden at være bearbejdet - kan fremtræde på vidt forskellige typer af medier (diskette, CD, halvlederchip, harddisk etc.), primært fordi programmets tilknytning til det digitale medium er langt flygtigere end bogstavets tilknytning til papiret. En mærkbar konsekvens heraf er, at forskellen mellem programmets salgspris og mediets værdi er langt større end forskellen mellem bogens salgspris og papirets værdi.

Skaberens synsvinkel

Også set fra skaberens synsvinkel er der mærkbare forskelle. Hvor forfatteren til en litterær tekst kan "udfordre" sit naturlige sprog inden for forholdsvis frie grænser og ligefrem opfinde nye ord mv., er programmøren bundet af de håndfaste grænser, der gælder for det programmeringssprog, han anvender. Overholder han ikke dets syntaksregler mv., kører programmet ganske enkelt ikke! Omvendt ligger det klart, at formalsproget åbner talrige andre udtryksmuligheder for programmøren. Tids- og pladsmæssige begrænsninger har sjældent samme betydning som i det talte sprog. Hvor forfatteren til en litterær tekst altid må respektere visse rammer for, hvor længe hans publikum holder ud, er der med nutidens teknologi ingen grænser for, hvor mange og detaljerede kommandoer og statements en programmør kan udtrykke sig med. Man antager således, at Windows 2000-pakken har et samlet omfang på mellem 35 og 60 millioner kodelinjer, se herved Bruce Schneier (2000), s. 210.

Fællesnævneren

Selv om der er talrige forskelle mellem edb-programmer og andre litterære værker, består der en afgørende strukturlighed, der gør det velbegrundet, at edb-programmer er rubriceret som litterære værker. Både programmer og klassiske litterære værker betjener sig nemlig af et litterært sprog. Sprogelementet er centralt for begrebet litterært værk, der efter forarbejderne til den tidligere ophavsretslov, defineres som "alle værker, som der er udtrykt ved sprogets hjælp". Se herved FT 1959-60, till. A, sp. 2683, der betoner, at der ikke kan stilles krav til værkets omfang eller med hensyn til det formål, det skal tjene. Den sproglige karakter mærkes først og fremmest i den - kommunikative - proces, hvorunder programmer bliver til: Programmøren koder i et programmeringssprog og frembringer derved det ophavsretlige udtryk.

Begrebet litterært værk defineres ikke i loven. Baseret på dets sproglige sammensætning (littera=bogstav) omfatter det værker, der sammensætter sig af bogstaver eller lignende tegn. I overensstemmelse hermed definerer den amerikanske Copyright Act (se 17 U.S.C. 101) begrebet som "works other than audiovisual works, expressed in words, numbers, or other verbal or numerical symbols or indicia, regardless of the nature of the material objects, such as books, manuscripts, phonorecords, film, tapes, disks, or cards". At edb-programmer skal henregnes til kategorien litterære værker efter Bernerkonventionens regler er i øvrigt lagt til grund i WIPO Copyright Treaty (1996), art. 4.

7.1.b. Programbegrebet

Processorinstruktioner

Når ophl. § 1, stk. 3, taler om edb-programmer, sigter bestemmelsen til de koder ("instruktioner"), der i overensstemmelse med reglerne i et programmeringssprog bringer processoren i stand til at udføre den funktion, programmøren tilsigtede, jf. i det hele den tekniske fremstilling i 3.2.a. Det er altså systemets input, begrebet sigter til. Den effekt, programmet genererer under anvendelsen (output-siden), omfattes ikke af programbeskyttelsen, men kan derimod tænkes beskyttet efter andre regelsystemer, herunder de ophavsretlige regler om litteratur og kunst (herunder brugskunst). Hvis programmøren koder processoren til at spille en melodi, vil dette program - foruden programkoderne - indeholde et eksemplar af det pågældende musikværk, og når programmet afvikles, vil denne afspilning være en fremførelse af denne musik (jf. om dette begreb afsnit 6.3.f.).

Modsat Hanne Bender i NIR 1997.75 f., NIR 1999.17 ff., og generelt i EDB-rettigheder (1998), der f.eks. finder, at et skærmbillede ikke er et "selvstændigt digitalt værk", og at hjemmel for beskyttelse heraf derfor må ligge i ophl. § 1, stk. 3. A.st. s. 78 anerkendes det dog, at skærmbilleder kan beskyttes efter § 1, stk. 1. Som fremhævet af Torvund i Ånd og Rett - festskrift til Birger Stuevold Lassen (1997), s. 1027 ff., er "litteraturmetaforen", altså forestillingen om, at programmets kildekode udgør kommandoer i en tekst svarende til ord i dagligsprogets sætninger, kommet under pres i takt med udviklingen af grafisk orienterede værktøjer, hvor kildeteksten fremtræder i form af kasser og pile, der markerer relationer mellem programmets forskellige objekter. Da værktøjer af denne art alene udgør konverteringer af det, der til syvende og sidst fremtræder som binære kommandoer til processoren, bringer iagttagelsen ikke den grundlæggende ophavsretlige rubricering af edb-programmet i fare. Derimod giver den anledning til overvejelser om, hvilke elementer af kildeteksten der er genstand for programbeskyttelsen, jf. Torvund sst. s. 1031 f., hvor det konkluderes, at retsbeskyttelsen må tilkomme den, hvis indsats har givet programmet dets særpræg. Se i øvrigt om programbegrebet Wagle & Ødegaard (1997), s. 71 ff.

Partitioneringsproblemet

Som begrebet "edb-program" er lagt fast, har det ingen naturlig ramme. Alle "serier" af kodeinstruktioner til en processor falder principielt inden for. Hvor man ofte vil have en forestilling om, hvornår en "menneskelæsbar" tekst har et omfang, der almindeligvis vil rubricere den som et "digt", en "novelle" eller en "videnskabelig tidsskriftsartikel", er det eneste fælles kendetegn for programmet dets evne til at nå processoren og herigennem udføre en funktion. Da der således ingen funktionelle begrænsninger gælder for, hvornår noget er "et program", opstår spørgsmålet om, hvor grænsen skal sættes for, hvad der er et værk, eller blot en del af et værk. Dette spørgsmål betegnes undertiden som partitioneringsproblemet, jf. således Wagle & Ødegaard (1997), s. 173 ff., Se ligeledes Bing i Wege zum japanischen Recht, Festschrift für Zentaro Kitigawa zum 60. Geburtstag am 5. April 1992 (Duncker & Humblot, Berlin, 1992), s. 829 ff. og samme i NIR 1999.291 ff.

Problemet har betydning i to henseender: Hvor meget skal der til, for at et program opnår ophavsretlig beskyttelse? Og hvor stor en del af et program må der kopieres, før man kan sige, at ophavsretten er krænket. Problemet opstår generelt for værker, der ikke har noget afsluttet hele (edb-programmer, samleværker og databaser). Der kan næppe opstilles nogen eksakt formel for et svar, og i konkrete sager er man derfor nødt til at søge tilbage i almene betragtninger: En opdeling, der fører til beskyttelse for så små værkselementer, at der reelt opnås en idé-beskyttelse, kan således ikke tillades. Omvendt vil en opdeling, der gør det muligt for konkurrerende virksomheder at tilegne sig frugterne af væsentlige investeringer, heller ikke tillades.

Sidstnævnte problematik må principielt udskilles fra læren om programcitater, se hertil afsnit 6.4.b. Hvis et uddrag af et programværk ikke i sig selv har programkarakter, befinder det sig i public domain, og enhver kan da frit bruge det. Citatretten er derimod et indgreb i et ophavsretlig beskyttet værk, der kun kan udøves i overensstemmelse med de særlige regler herfor (værket skal være offentliggjort, citatet skal ske i overensstemmelse med "god skik" og kun i det omfang, der betinges af formålet, jf. nærmere ophl. § 22).

Brugerinformation

Af den samlede mængde maskinlæsbar information i et "edb-program" (f.eks. materialiseret på en CD-ROM-skive), er det derfor kun en begrænset del, der kan karakteriseres som edb-programmel, jf. nærmere om denne centrale sondring i afsnit 3.2.f. Den information, der bringes frem på skærmen, når man f.eks. læser filen i et tekstbehandlingsprogram, er ikke et "program", da den ikke er skrevet som instruktioner til en processor: Der er tale om menneskelæsbar information, der skrives med sigte på en læser. At informationen i den valgte tekniske ramme er maskinlæsbar forandrer ikke herved. Det maskinlæsbare er ikke nødvendigvis eksekverbart, dvs. i stand til at udføre en teknisk kommando i overensstemmelse med et programmeringssprog.

7.1.c. Mellemformer

Trods denne principielt skarpe sondring findes der en række frembringelser, som det kan være vanskeligt at placere i grænselandet mellem programbegrebet og databegrebet.

Dokumentation

For det første kan man spørge, hvorledes programmets dokumentation, dvs. de tekster mv., der angiver dets funktionalitet og brugergrænseflader, skal rubriceres. Man sondrer almindeligvis mellem systemdokumentation, der med henblik på fejlrettelse mv. primært retter sig mod programudviklere og systemfejl, og brugerdokumentation, der beskriver, hvordan slutbrugeren anvender programmet, og som i sagens natur derfor primært retter sig mod denne.

Som udgangspunkt ligger det klart, at den sprogligt nedfældede beskrivelse af programmets funktioner mv. må betragtes som et litterært værk, der ikke (også) er et edb-program. Inden for denne kategori er der tale om et litterært værk af beskrivende art, jf. § 1, stk. 1, dvs. en slags faglitteratur. Problemet er, om dette også gælder den maskinlæsbare dokumentation, f.eks. de pop-up menu'er, der aktiveres via programmets "hjælp"-funktioner. Selv om disse dele af programmet meddeler sig til brugeren ved hjælp af programkomponenter, er der ingen tvivl om rubriceringen. Det samme gælder om de kommentarer mv. (statements), som programmøren anfører i selve programkildeteksten for at understøtte programmets opdatering og videreudvikling: De pågældende sætninger mv. retter sig således ikke mod processoren (som netop vil ignorere dem, når programmet oversættes, eller rettere: "kompileres", til objektkode), men mod programmøren. Den i og for sig tilfældige omstændighed, at de optræder i fysisk sammenhæng med programkoden, gør ingen forandring heri. Spørgsmålet har dog næppe større praktisk betydning, da der i alle tilfælde vil være beskyttelse - givet at kravene til originalitet er opfyldte.

I forbindelse med programmets oversættelse fra kildetekst til maskinkode sker der dog den ændring, at en række af programmørens bemærkninger til kildeteksten (til glæde for sig selv og senere udviklere) forsvinder - al den stund de jo ikke retter sig til processoren. Den heraf følgende asymmetri mellem kildetekst og objektkode spiller dog ingen ophavsretlig rolle, eftersom disse bemærkninger netop ikke retter sig til processoren: I det omfang programmøren indlægger den slags kommentarer i kildeteksten må forholdet rettelig betragtes således, at han frembringer et litterært værk, der ikke er et edb-program. Problemet opstår kun, hvis de pågældende bemærkninger optræder i forbindelse med den øvrige programkildetekst. Der er imidlertid sjældent nogen kommerciel eller anden interesse i at kopiere bemærkningerne som sådanne.

Integrerede dataobjekter

Et andet grænseeksempel herpå er de dataobjekter, der integreres i de fleste af nutidens programmer. For at øge brugervenligheden og i den forbindelse ikke mindst den æstetiske oplevelse af at bruge et program, er det almindeligt at forsyne programmet med en række visuelle og lydlige indtryk, der ofte vil komme til udtryk som litterære eller kunstneriske værker. Ved programmets opstart eller under venteperioder vil man kunne høre små musikkompositioner afspillet, og for at bistå brugeren med hjælp under programanvendelsen vil der ofte fremtræde et antal tekstelementer i digitaliseret form (blandt hvilke nogle kan tænkes at være litterære værker) i form af hjælpemenuer mv. Navnlig for programmer inden for underholdningsgenren kan mængden af "klassisk" ophavsretlig information (musik, musikindspilninger, kunst, fotos mv.) være ganske betydelig. Beskyttelsen af disse programelementer følger reglerne om de almindelige litterære og kunstneriske værker samt databaser, jf. nærmere afsnit 6.2.

Anderledes Wagle & Ødegaard (1997), s. 77, der afviser at lægge nogen klar sondring mellem denne form for integreret dokumentation og programmel, selv om dette vil indebære en udvidelse af programbegrebet. Begrundelsen herfor (nemlig at der i så fald vil gælde forskellige regler for de forskellige komponenter af programmet) kan dog næppe være afgørende. Samme problemkreds har man i forvejen ikke blot for programbeskyttelsen, men også inden for talrige andre værkskategorier (f.eks. film).

Opmarkeringer

Et tredje væsentligt grænsetilfælde er de opmarkeringer af tekstmasser, som bl.a. er nødvendige for at forberede et dokument til hypertekst-applikationer, f.eks. elektroniske bøger eller hjemmesider. I det omfang disse opmarkeringer understøtter muligheden for at foretage et "spring" hen til anden tekst, når brugeren aktiverer koden (og dermed forsyner systemet med data), kan man i en vis forstand hævde, at disse koder udgør instruktioner til en processor. Men på den anden side ligger det klart, at disse spring ikke effektueres i en programmæssig ramme: Hypertekst-koden er en integreret bestanddel af et hele, der fremstår som almindelig tekst. At den i kraft af den browser, teksten læses fra, effektuerer et hypertekst-spring, bør ikke kunne forandre tekstens karakter af data. I overensstemmelse med denne sidste betragtning må det antages, at sådanne opmarkeringer, trods deres tilsyneladende lighed med programfrembringelser, ikke skal betragtes som sådanne, se tilsvarende Wagle & Ødegaard (1997), s. 80 ff., Lindberg & Westman (1999), s. 158 f. og Nordell i NIR 1999.489.

Instruktionsfiler

I nær forbindelse hermed kan for det fjerde nævnes sådanne filer, der vel ikke udgør integrerede dele af et edb-program, men som i sig rummer data, der betragtes som instruktioner, når filen kaldes fra en programfil. Et eksempel herpå er de såkaldte systemkonfigureringsfiler (i DOS-styresystemet f.eks. config.sys). I overensstemmelse med det foran antagne er den almindelige opfattelse også her, at sådanne filer ikke skal betragtes som edb-programmel, se tilsvarende Hanne Bender (1998), s. 75 f. Hvis filerne har en vis størrelse og kompleksitet kan det være aktuelt at bringe reglerne om katalogbeskyttelse i anvendelse, jf. ophl. § 71 og nærmere kapitel 8.

Makroer

For det femte kan man spørge, hvorledes programmeringsmakroer bør betragtes. En makro er en sammenfletning af en flerhed af funktioner, som brugeren af et program - f.eks. et tekstbehandlingsprogram - kan frembringe for dermed at undgå gang på gang at skulle udføre de enkelte indtastninger. Problemet er, at de enkelte instruktioner i makroen strengt taget har karakter af "inddata" til det program, der anvendes, hvad enten der er tale om nøgne data (som f.eks. navn og adresse til brug for frembringelse af et brevpapir) eller om aktivering af eksekverbare kommandoer. I henseende til frembringelsesprocessen er lighedspunkterne med programudviklingen så iøjnefaldende, at det forekommer rigtigst at rubricere makroer i kategorier af edb-programmer: For det første samler makroen en " serie af instruktioner", der til syvende og sidst når den processor, der er programmeret til at læse den. For det andet rummer den tekniske ramme, der gælder for makro-indlæsningen, et formalsprog, der i teknisk henseende modsvarer det, der gælder for andre programmeringssprog. At betragte makro-frembringelser som programmer stemmer i øvrigt med teknisk jargon, der ofte taler om "makro-programmering".

Programmeringssprog

Man kan endelig spørge, om programmeringssprog kan beskyttes ophavsretligt. Når spørgsmålet rejses, er det nødvendigt at sondre mellem programmeringssproget som sådant - dvs. i skikkelse af de regler for dets syntaks og semantik mv., der skal anvendes, når man betjener sig af det - henholdsvis det program, der implementerer disse sprogregler, først og fremmest i forbindelse med funktioner til frembringelse og oversættelse (kompilering) af edb-programmer skrevet i det pågældende sprog.

- oversættere

At oversætterprogrammer kan beskyttes ophavsretligt er utvivlsomt. Det eneste spørgsmål, man kan rejse, er om den ophavsretlige beskyttelse, som programmør A (forudsat fornøden originalitet) opnår til sit oversætterprogram til sproget X, forhindrer programmør B i at frembringe et andet (originalt) oversætterprogram til sproget X. Svaret herpå beror på de almindelige regler om ophavsretlig idé-beskyttelse, jf. afsnit 6.2.b., og om beskyttelse af brugergrænseflader, jf. afsnit 7.3. Selve dette at implementere et programmeringssprogs syntaks og grammatik må som udgangspunkt betragtes som implementering af en idé, der ikke kan beskyttes ophavsretligt. Hvis ikke programmør B i sin brugergrænseflade har ladet selvstændigt beskyttede elementer i programmør A's brugergrænseflade indgå, må udgangspunktet være, at programmør B's ophavsret til sit oversætterprogram kan gøres gældende helt uafhængigt af programmør A's.

- i sig selv

At et programmeringssprog i sig selv ikke er et "program" er utvivlsomt: Det indeholder ikke som sådant "instruktioner til processoren". Dets formål er derimod at understøtte muligheden af, at en anden end sprogets skaber formulerer sådanne instruktioner. Ligeså utvivlsomt er det, at et programmeringsværktøj, der baseres på sproget, er et program. Derimod kan man overveje, om programmeringssproget kan beskyttes efter andre ophavsretlige regler, herunder som almindeligt litterært værk eller database. Stillet generelt må dette spørgsmål formentlig også besvares benægtende: En beskyttelse som almindeligt litterært værk vil alene ramme den specifikke beskrivelse af sproget; men da et programmeringssprogs grammatik og syntaks - ligesom det gælder for et naturligt sprog - kan beskrives på mange forskellige måder, vil en sådan beskyttelse ikke ramme selve sproget som innovativ frembringelse.

I overensstemmelse hermed har den australske High Court nægtet et programmeringssprog beskyttelse som edb-program i sagen Data Access Corporation v. Powerflex Services PTY Ltd [1999] HCA 49.

7.2. Programkodens retsbeskyttelse

7.2.a. Kildetekst

Når man taler om ophavsret til edb-programmer sigtes normalt til de enkelte instruktioner i programmet, dvs. programmet i sin kildetekst- eller objektkodeversion. Som tidligere nævnt kunne man overveje at betragte kildeteksten på linje med programdokumentationen, eftersom kildetekstens kommandoer jo først skal oversættes (kompileres) til objektkode, før de kan læses af processoren. At man ikke desto mindre må betragte kildeteksten som et programværk skyldes, at den udtrykker de enkelte kommandoer. Det fremgår således direkte af slutningsordene til ophl. § 1, stk. 1, at beskyttelsen gælder uanset den form, hvori det enkelte værk er kommet til udtryk.

Et af de spørgsmål, der tidligst har givet anledning til tvivl, ikke mindst i amerikansk ophavsretspraksis, er, om selve strukturen i programmets kildetekst, herunder de enkelte sekvenser af programkommandoer, kan beskyttes ophavsretligt. Spørgsmålet har primært betydning i tilfælde, hvor en programmør forlader et projekt (og et ansættelsesforhold) for i konkurrerende øjemed at frembringe et program, som minder om det, han kom fra. Det nye program skrives fra grunden; men med programmørens erfaring fra det tidligere projekt får det grundlæggende strukturelle lighedspunkter med det, programmøren forlod. Spørgsmålet er nu, hvornår det nye program rettighedsmæssigt er frigjort fra det gamle.

Når spørgsmålet vurderes, er det nærliggende at tage udgangspunkt i ophl. § 4, stk. 2. Efter denne bestemmelse er ophavsretten til et nyt og selvstændigt værk, som er frembragt gennem "fri benyttelse" af et andet, ikke afhængigt af ophavsretten til det oprindelige værk. Man er klart uden for denne regel, hvis der medtages ("stjæles") kode fra det oprindelige program. Men hvis ikke det oprindelige programs struktur i sig selv udgør et ophavsretligt beskyttet værk, kan bestemmelsen ikke umiddelbart anvendes, når det netop kun er strukturen - men ikke de enkelte programkommandoer - der går igen. Dermed bliver det et kritisk spørgsmål, om selve strukturen i et program er et beskyttet værkselement.

Spørgsmålet kan også opstå i andre tilfælde end i samarbejdsrelationer, f.eks. når det ved en almindelig afprøvning af programmets idégrundlag, jf. ophl. § 36, stk. 1, nr. 3, er muligt at få indblik i de principper, der er lagt til grund for de enkelte programelementer.

Diskussion

I drøftelsen af dette spørgsmål er det nærliggende at skele til reglerne om samleværker, jf. ophl. § 5, der i visse henseender kan siges at hjemle en beskyttelse af programstrukturen, jf. ligeledes Riis (1998), s. 139 f. Det må således antages, at man kan opnå ophavsretlig samleværksbeskyttelse af den "programredaktionelle" indsats, der består i at sammensætte programobjekter, som andre har skrevet. En sådan form for programmering er en kendt teknik i den form for CASE-programmering, der tillader brugeren - mod licensbetaling - at gøre brug af forskellige "præfabrikerede" programmoduler. Beskyttelsen forudsætter blot, at sammensætningen af disse moduler - i fornødent omfang - bærer præg af originalitet, jf. de almindelige regler herom. Beskyttelsen dækker nemlig kun den originale sammenstilling af moduler og objekter i det færdige program. Men jo mere integreret den redaktionelle indsats er i selve kodningsarbejdet, desto vanskeligere bliver det at hævde en sådan beskyttelse, sml. herved Lindberg & Westman (1999), s. 160, der - med rette - fremhæver, at man normalt heller ikke opnår samleværksbeskyttelse til en film, selv om den tilsvarende består af et antal delværker. Som afgrænsningskriterium foreslår forfatterne, at man lægger vægt på, om delene er "passive og hvilende" eller om de indgår som bestanddele i noget nyt og selvstændigt.

En synsvinkel som den her hævdede ligger forudsætningsvis til grund for § 2, stk. 2, i halvlederloven, der i tilslutning til betingelsen om, at topografien skal være resultatet af frembringerens egen intellektuelle indsats, fastslår, at topografier bestående af elementer, der er almindelige inden for halvlederindustrien, kun beskyttes, "hvis kombinationen af disse elementer" besidder denne kvalitet. Se i samme retning pkt. 2.7 i forslaget til Rådsdirektiv om retlig beskyttelse af programmer (EFT 1989 C 91/6), hvor det fremhæves, at "programmets originalitet kan ligge i udvælgelsen og kompilationen af ... i øvrigt banale elementer".

I det omfang der således kan dokumenteres den fornødne originalitet i den "indholdsfortegnelse", der ligger til grund for en sådan "programantologi", må det antages, at der også kan opnås ophavsret til den heri liggende struktur. Men det er væsentligt at slå fast, at der ingen nødvendig sammenhæng er mellem programmets indre struktur og den opbygning, brugeren oplever gennem menuens punkter: En og samme grænseflade (og programfunktion) kan opnås gennem uendeligt mange forskellige udformninger af en programkildetekst. Derfor dækker denne beskyttelse ikke programmets "idé", f.eks. en særlig form for tekstbehandling. Om beskyttelsen af de funktioner, programmet udfører, f.eks. via sin menustruktur, se nedenfor i afsnit 7.3.c.

Egne delværker

Heri ligger også, at den, der skriver et program fra grunden kan opnå en slags indirekte strukturbeskyttelse ved som led i denne frembringelse at "redigere" den samlede komposition af egne delprogrammer. Dette spørgsmål kan få betydning i tilfælde, hvor programmets delelementer ikke beskyttes, fordi de ikke opfylder originalitetskravene. Problemet kan umiddelbart synes teoretisk; men det har praktisk juridisk betydning, fordi samleværker efter ophavsretsloven betragtes som litterære værker, der ikke er edb-programmer, jf. § 1, stk. 1. Hvis man er i en situation, hvor del-programmerne befinder sig under originalitetsgrænsen (eller anvendes med rettighedshaverens samtykke), må man karakterisere den samlede frembringelse som et samleværk. Dermed gælder de særlige regler, loven opstiller for edb-programmer, ikke (hvorimod reglerne om andre værker i digital form gælder). I praksis betyder dette f.eks., at det således etablerede samleværk kan udlånes i medfør af ophl. § 19, stk. 3.

Styret kodning

Det kan være vanskeligt at udpege ophavsmanden til programmer, der er blevet til under en styret proces, hvor der er lagt ufravigelige tekniske rammer for kodningen. Hvis sådanne rammer udtømmer programmørens muligheder for at være kreativ, vil han være afskåret fra at opnå ophavsret, og ophavsretten vil i stedet opstå hos programredaktøren som den reelt kreative part. Problemet opstår kun, hvis styringen gennemføres så stramt, at programmøren er afskåret fra at tilføje det færdige værk et individuelt præg. Programmøren må da betragtes som "teknisk medhjælp", jf. betænkning 1064/1986, s. 43 og Koktvedgaard (1999), s. 79 f. Talrige værker inden for den klassiske ophavsret (f.eks. avisartikler, ordbogsbidrag mv.) frembringes indenfor præcist fastsatte rammer, f.eks. for LIX-tal, sprogstil eller ordvalg, uden at ophavsretten af denne grund udelukkende placeres hos den styrende kraft (f.eks. redaktøren).

Pseudokode

Problemet kan blive aktuelt, når der anvendes pseudokode under programmeringen, hvilket ofte sker under struktureret programudvikling (SPU). Pseudokode-teknikken indebærer ikke i sig selv, at ophavsretten opstår hos den styrende instans (der ofte vil være helt eller delvis den samme som programmøren), jf. allerede det forhold, at man typisk supplerer ved at gøre brug af såkaldt walk through, hvor den enkelte programmørs delværk gøres til genstand for kritik blandt dennes kolleger. Se i det hele hertil afsnit 3.2.d.

VP-sagen

I en utrykt dom vedrørende Værdipapircentralens edb-programmel (ØLD 22.1.1990) var dette spørgsmål til behandling. Da Værdipapircentralen udviklede VP-systemet, søgte man at opnå en så høj grad af personuafhængighed som muligt. Der var mange personer involveret i udviklingsprocessen, der tog flere år. Derfor var det vigtigt, at den enkelte programmør uden videre kunne erstattes af en anden.

Under sagen gjorde en enkelt programmør gældende, at han havde en del af ophavsretten til det samlede system. Den pågældende havde haft status som "delprojektleder" ved systemets opbygning. Dette indebar, at han havde skrevet kode, været med til at udfærdige de specifikationer, hvorefter koden skulle skrives, og koordineret hele den indsats, medlemmerne i hans delprojektgruppe udførte. Trods vidneforklaringer, der dokumenterede, at programmøren havde skrevet kode på lige fod med hovedparten af de øvrige programmører, der skrev VP-systemet, fandt landsretten det ikke godtgjort, at programmøren havde "udarbejdet eller medvirket ved udarbejdelsen af programmer eller dele deraf, der i en sådan grad er resultatet af en skabende ånds- og eller intellektuel indsats og præget af individualitet, at disse nyder beskyttelse efter loven om ophavsrettigheder". Afgørelsen ville formentlig falde anderledes ud, hvis den skulle bedømmes på grundlag af det senere vedtagne programdirektiv (91/250/EØF), der netop fastslår, at der ikke kan stilles andre krav end, at programmet skal være ophavsmandens "egen intellektuelle frembringelse", og netop i lyset af dette blev sagen forligt for Højesteret, efter at der var indhentet et syn og skøn, der viste, at sagsøgeren i et vist omfang havde haft mulighed for at udvise individualitet i sit programmeringsarbejde.

I en offentliggjort forligstekst mellem parterne dateret den 30. juli 1992, tilslutter de sig skønsmandens vurdering: At den omhandlede medarbejder "principielt har haft mulighed for at udfolde en selvstændigt skabende indsats". Under henvisning til det originalitetskriterium, der er anført i programdirektivet (91/250/EØF) om, at programmet skal være udtryk for programmørens "egen intellektuelle frembringelse", erklærer parterne sig enige om, "at en VP-medarbejder, der har udført funktioner vedrørende systemanalyse og -udformning som de, den i sagen omhandlede medarbejder varetog, vil kunne have status som medophavsmand til VP-systemet". Da dommen på grund af direktivet imidlertid ikke længere har præjudikatværdi, besluttede Finansforbundet sig til at frafalde krav i anledning af salget af VP-systemet. Forbundet afskærer sig dog ikke fra i andre konkrete sager at rejse lignende ophavsretlige krav, ligesom spørgsmålet vil kunne inddrages i fremtidige overenskomstforhandlinger.

7.2.b. Forarbejder

Skriftligt nedfældede forarbejder mv. til et program beskyttes som almindelige litterære værker, der ikke er programmer, sml. den svenske højesteretsdom i NJA 1998.563 (NIR 1999.253) , hvor nogle byggetegninger antoges at have værkshøjde. I henseende til kravene om originalitet (værkshøjde) gælder altså de almindelige krav, man vil stille herom til andre tekstuelle og grafiske fremstillinger, jf. herom afsnit 6.2. For så vidt angår de grafiske værker af beskrivende art - f.eks. flow-charts, diagrammer, skitser mv. - følger beskyttelsen af ophl. § 1, stk. 2. Da ophavsretten til det forberedende designmateriale ikke giver ophavsret til det heri nedfældede idégrundlag, se nærmere herom afsnit 6.2.b., er værdien af denne beskyttelse dog beskeden. Så længe man befinder sig på undfangelsesstadiet i en kreativ proces, hvor der alene er idéer, planer og muligheder på bordet, fratager man ikke andre retten til at fuldføre disse planer i en ny - og fra "plan-værket" adskilt - manifestation. Denne begrænsning i den ophavsretlige beskyttelse kan vel føles som en svaghed navnlig på IT-området, hvor den væsentligste værdiskabelse netop ligger i disse innovative idé-elementer. Svagheden afbødes dog i nogen grad gennem muligheden for at patentere programrelaterede opfindelser, jf. nærmere herom i afsnit 10.1.d.

I Rådsdirektiv 91/250/EØF om retlig beskyttelse af programmer, art. 1, stk. 1, antages udtrykket "program" også at omfatte "forberedende designmateriale" hertil. Bestemmelsen giver anledning til betydelig usikkerhed, jf. nærmere Bing i NIR 1999.284 f. Usikkerheden skyldes, at der jo i en vis forstand ingen grænser er for, hvilke frembringelser der kan siges at udgøre de indledende skridt til det færdige program. En afgrænsning er derfor nødvendig, og den må foretages under hensyntagen til ophavsrettens grundlæggende principper. Det kan således ikke antages, at det idégrundlag, der er nedfældet i det forberedende designmateriale, hermed opnår ophavsretlig beskyttelse, jf. udtrykkeligt samme artikels stk. 2, 2. pkt. Antog man denne konsekvens, ville vejen være åbnet for en bredere idé-beskyttelse. Meningen med at inkorporere designmaterialet i programdefinitionen er formentlig at lægge samme begrænsninger i anvendelsen af dette materiale som i anvendelsen af selve programmet, f.eks. i forbindelse med dekompilering (reverse engineering mv.), se herom nedenfor afsnit 7.4.g. Dette peger i givet fald på en afgrænsning af begrebet til udkast af en mere præcis beskaffenhed, herunder pseudokode mv.

Bearbejdede forarbejder

Et særligt problem foreligger, hvis forarbejdet udgør selve det grundlag, på hvilket den yderligere programmering bygges. Problemet kan skitseres med et eksempel fra litteraturens verden: Hvis en forfatter i en samtale skitserer idéen til et drama, er det almindeligt antaget, at der ikke foreligger nogen ophavsretskrænkelse, hvis en udenforstående tilhører benytter sig af, hvad han har hørt, og gengiver det i et værk, han selv frembringer. Den slags krænkelser kan derimod tænkes omfattet af reglerne om utilbørlig konkurrence eller af personlighedsretten. Men situationen begynder gradvis at forandre sig, hvis forfatteren nedfælder idéen til det pågældende værk på skrift, og tredjemand herefter får fingre i teksten og arbejder videre med den. Man kan da argumentere for, at der ved nedfældelsen manifesteres et litterært værk, og at en videre bearbejdning af dette (f.eks. ved filmatisering af den skitserede historie), rummer en ophavsretlig bearbejdning af værket, jf. ophl. § 4, stk. 1, sml. drøftelsen hos Wagle & Ødegaard (1997), s. 156 f.

Det er imidlertid vigtigt at fastholde, at der på det principielle plan ikke er stor forskel mellem de to eksempler. Det forhold, at en tekst skrives ned, giver den ikke isoleret set nogen stærkere ophavsretlig beskyttelse, end hvis den blot udtrykkes mundtligt. Ifølge ophl. § 1 gælder ophavsretten således uanset hvordan, værket er kommet til udtryk. Men at temaet rent faktisk er manifesteret skriftligt kan gøre det bevismæssigt lettere for en domstol at nå frem til, at der ikke blot er tale om et løsere udtryk for en abstrakt idé. Denne bevisvirkning vil umærkelig få den praktiske betydning, at man lettere vil statuere krænkelse af et ophavsretligt værk, hvis forlægget er nedfældet på tryk, end hvis der blot er tale om en løsere skitseret idé.

I en videreførelse af dette eksempel er det lettere at opnå en idé-lignende ophavsretsbeskyttelse til et programværk, hvis dele af det på et tidligt stadium i forberedelsen er blevet kodet. Navnlig når det færdige program bygger på den kodning, der er udført på et tidligt tidspunkt i forberedelsesprocessen, må man nå til, at det færdige program udgør bearbejdninger af den oprindelige programkode.

7.2.c. Programmanifestationen

Er en moderne vaskemaskine et eksemplar af et edb-program? For enhver praktisk betragtning er svaret på dette spørgsmål naturligvis nej. Men i den ophavsretlige terminologi giver det anledning til at spørge, hvilke manifestationer af et edb-program der med rette kan betragtes som "et programeksemplar". Og her er det en kendsgerning, at alle moderne vaskemaskiner - ligesom megen anden husholdningselektronik - indeholder talrige programkomponenter. Spørgsmålet har først og fremmest betydning i relation til den ophavsretlige eneret til spredning (og ikke mindst reglerne om, hvornår denne eneret er konsumeret), da retten hertil forudsætter, at et eksemplar af programmet udbydes til salg, udlejning eller udlån mv.

Det antages almindeligvis, at svaret på det konkret stillede spørgsmål er nej, se således Bing i NIR 1995.406 og Wagle & Ødegaard (1997), s. 84. At man føler sig sikker herpå skyldes ikke mindst en opfattelse af, hvad der er den typiske forudsætning bag brugen af det pågældende udstyr mv.: Hverken rettighedshaveren eller forbrugeren oplever forholdet som "brug" af et edb-program: Ingen af de beføjelser, som normalt tilkommer en programbruger (f.eks. retten til sikkerhedskopiering og fejlretning, jf. ophl. § 36) har heller praktisk betydning. Men så snart blikket vendes mod transaktioner, hvor disse beføjelser er relevante, må det fastholdes, at også mindre programkomponenter i et digitalt værk af anden karakter gør den samlede manifestation til et eksemplar af det pågældende program.

Denne opfattelse ligger bl.a. til grund for den særlige regel i ophl. § 19, stk. 3, 2. pkt., der giver biblioteker ret til at udlåne "et eksemplar af et edb-program i digitaliseret form", når dette udgør "en del af et litterært værk og udlånes sammen med dette". Der er tale om en undtagelsesbestemmelse, der næppe kan fortolkes udvidende til også at omfatte andre værker end litterære værker, der styres af et edb-program. Styrer edb-programmet et produkt, der omfatter kunstneriske værker (f.eks. inden for multimedia-området), er bestemmelsen uanvendelig.

7.2.d. Opsætninger

I forbindelse med installation af et programsystem vil der ofte skulle foretages en række tilpasninger, som sætter systemet i stand til at fungere optimalt i den pågældende konfiguration, i det følgende kaldet systemets opsætning. Ofte kan disse opsætninger identificeres til særskilte filer eller tabeller, som dermed vil fremtræde som selvstændige frembringelser. Spørgsmålet er nu, hvilken retlig status disse frembringelser skal have.

Som udgangspunkt er det her nærliggende at anvende den almindelige regel i ophl. § 4, stk. 1, om bearbejdelser. Ganske vist tager denne bestemmelse primært sigte på bearbejdelser, der i deres nye skikkelse er integreret med det oprindelige værk, men det bagvedliggende princip bør ligefuldt finde anvendelse. Spørgsmålet om, hvem der har retten til denne bearbejdelse, må herefter løses efter de almindelige regler om ophavsrettens subjekt, jf. herved afsnit 6.4.

Hvis opsætningen foretages hos kunden af programudvikleren på et standardsystem, som sælges til almenheden, kan der dog opstå særlige spørgsmål om, hvorvidt kunden har ret til at overdrage opsætningen til andre brugere af det pågældende system. Som udgangspunkt må det her antages, at det "værk", bearbejdelsen repræsenterer, er "på anden måde overdraget til andre", jf. ophl. § 19. Dette resultat gælder i hvert fald det leverede program i sin opsatte form. Derimod vil det kræve særlig aftalehjemmel at fremtvinge en udlevering af den specifikation, leverandøren (bearbejderen) selv har gjort af sin opsætning. Ofte vil opsætningen repræsentere kompliceret og værdifuld knowhow, som leverandøren vil lide konkurrencemæssige retstab ved at skulle give fra sig. Problemet kan f.eks. opstå, hvis kunden outsourcer sin egen drift for at overgå til en facility management-løsning.

7.3. Beskyttelse af grænseflader

7.3.a. Problemstillingen

Umiddelbart kan det forekomme overraskende at diskutere beskyttelse af et programs grænseflader mod andre programmer (de tekniske grænseflader) eller mod brugerne (brugergrænsefladen) som en del af læren om beskyttelse af edb-programmer. Programmet defineres jo netop med udgangspunkt i de enkelte instruktioner i processoren, og som vi så ovenfor i gennemgangen af denne beskyttelse er det for så vidt underordnet herfor, hvilke resultater disse programinstruktioner udvirker. Imidlertid er drøftelsen om programmets brugergrænseflader traditionelt blevet rubriceret som en del af programbeskyttelsen, selv om den strengt taget drejer sig om reglerne om andre litterære eller kunstneriske værker.

Begreb

Et programs brugergrænseflade er indbegrebet af den information, brugeren må være i besiddelse af for at kunne bruge det. Denne afgrænsning er imidlertid ikke brugbar som grundlag for en afgrænsning af, hvilke elementer af brugergrænsefladen, der kan tænkes beskyttet som ophavsretlige værker eller værksbearbejdninger. Her kan man for det første udsondre de elementer af brugergrænsefladen der kan udskilles i selvstændige værkskategorier. Beskyttelsen er her problemløs: Kan der udpeges et værk i brugergrænsefladen (f.eks. et ikon eller en illustration), gælder de almindelige regler om, hvornår dette værk må gøres til genstand for eksemplarfremstilling og spredning mv. Et anderledes vanskeligt problem opstår, når det overvejes at gøre den mere ubestemmelige følelse af at arbejde med en bestemt brugergrænseflade til genstand for beskyttelse. Dette problem betegnes ofte som beskyttelsen af programmets look and feel, jf. nærmere herom i afsnit 7.3.c.

Begge typer af brugergrænsefladebeskyttelse har stor praktisk betydning, fordi IT-brugere ofte vil vælge applikationer efter en vurdering af, hvor let det er at lære at betjene dem. Problemet om selve brugergrænsefladens udseende spillede en stor rolle for de første generationer af PC-applikationer, men efter udbredelsen af den grafiske brugergrænseflade med "rullemenuer", "vinduer", "dialogbokse", "menubjælker" med faste grupper af kommandoer etc., har der dannet sig visse standarder for, hvordan brugergrænsefladen bygges op, og det individuelle spillerum er derfor blevet noget mindre, jf. nærmere Bing i NIR 1999.285 ff.

Den ophavsretlige beskyttelse af brugergrænseflader har principielt intet at gøre med beskyttelsen af selve edb-programmet. Når et program defineres som et antal instruktioner til en processor, må de værkselementer, der træder frem over for brugeren, som nævnt betragtes som værker af en anden art. At dette må være den korrekte betragtning følger i øvrigt af, at samme brugergrænseflade kan tilvejebringes gennem en ubegrænset flerhed af kildetekstkombinationer. Derfor kan man ikke antage, at den sammenstilling af funktioner, der ligger i en programmenu, udgør et ophavsretligt samleværk. Sammenstillingen har ikke litterær karakter, og anerkendelsen af en sådan beskyttelse ville åbne op for en næsten ubegrænset ophavsbeskyttelse af forskellige funktionssammenstillinger på det industrielle område (betjeningspaneler, tastaturer mv.).

Anden beskyttelse

En beskyttelse af disse aspekter kan her i Norden også støttes på de konkurrenceretlige regler om "god markedsføringsskik", således som disse f.eks. er anvendt i norsk praksis med byretsdommen af 20. juni 1989 fra retten i Strømmen. Afgørelsen, der er truffet med professor Birger Stuevold Lassen som meddommer, er trykt i Lov&Data nr. 19/1989, s. 2-3, og i Bryde Andersen: Edb-ret, lovgivning, retsafgørelser, kontrakter, s. 138 ff. Den er kommenteret af Bing i NIR 1999.287 f. Se ligeledes fra amerikansk praksis dommen i Integrated Cash Management Services, Inc., v. Digital Transactions, Inc. , 920 F.2d 171 (1990). Beskyttelsen har imidlertid begrænset gennemslagskraft, dels fordi den er national (den genfindes f.eks. ikke i amerikansk ret), dels fordi den til stadighed beror på en vurdering af de relevante konkurrencerelationer i det enkelte sagsforhold (man betjener sig altså ikke af systembegreber, som det ophavsretlige værksbegreb med dets veldefinerede retsfølger).

7.3.b. Værkskomponenter i brugergrænsefladen

Grafik og lyd

Foruden koderne til processoren kan en programapplikation indeholde værkselementer, der kommer til udtryk som billede (herunder som grafisk værk eller som computer-genereret film), som lyd (f.eks. gennem sampling eller tone-generering) eller som tekst (f.eks. dokumentation, hjælpe-menuer etc.). Et komplet billede af den ophavsretlige beskyttelse af programmer må også inddrage disse forskelligartede værkstyper.

Enkelte elementer i programmets grafik må som nævnt rubriceres som "tegninger og andre i grafisk eller plastisk form udførte værker af beskrivende art", jf. ophl. § 1, stk. 2 - ganske som et digitalt lagret fotografi må betragtes som henholdsvis et fotografisk værk, jf. de almindelige regler i ophl. § 1, stk. 1, eller som et fotografisk billede (der altså ikke opfylder de ophavsretlige krav til originalitet), jf. ophl. § 70, der hjemler en særlig 50-årig beskyttelse heraf fra udgangen af det år, da billedet blev fremstillet. Ligeledes kan de lydsignaler, programmet genererer - f.eks. en særlig strofe eller den underlægningsmusik, der ledsager indlæsningen af de omfattende mængder af kode under opstart - udgøre et musikværk. Sådanne værkselementer beskyttes efter de almindelige regler, der gælder for de pågældende værkstyper. Enkelte grafiske elementer, som f.eks. ikoner og baggrundsmønstre, kan beskyttes som f.eks. varemærke eller mønster, se f.eks. Apple Computer, Inc. v. Microsoft Corp. , 821 F.Supp. 616 (N.D. Cal. 1993), 35 F.3d 1435 (9th Cir. 1994).

Præstationsbeskyttelse

Lyd spiller en stigende rolle for brugen af nutidens IT-applikationer. Ikke alene afgiver programmerne en stigende mængde information ved lydsekvenser (f.eks. genkendelseslyde ved opstart, fejlmeldinger, "banke på"-signaler mv.); lyden tjener ligeledes til at levendegøre de hændelser, der udspiller sig på skærmen i talrige multimediaapplikationer: En dør lukkes i, der lyder skridt, en motorcykel brøler afsted etc. De ophavsretlige muligheder for at beskytte sådanne lydsekvenser er begrænsede: Selv om det kan kræve megen kyndighed og betydelige omkostninger at frembringe den rigtige " sound", befinder vi os uden for det ophavsretlige værksbegreb. Af samme grund er også reglerne om fremførelse af ophavsretlige værker, jf. ophl. § 65, ude af billedet, da denne beskyttelse drejer sig om en "udøvende kunstners fremførelse af et litterært eller kunstnerisk værk."

Derimod giver ophl. § 66, som hører til blandt de ophavsretlige "naborettigheder", fremstilleren en eneret til eftergørelse eller tilgængeliggørelse til almenheden af "lydoptagelser", jf. nærmere afsnit 8.7.b.

Anden beskyttelse

Gennem de senere år er det blevet praksis ved en række varemærkekontorer at beskytte såkaldte lydmærker, se hertil Wallberg i NIR 1997.1. Denne praksis, der indtil videre primært har haft betydning for fysiske produkter som f.eks. motorcykler, shavere mv., kan imidlertid også få betydning i relation til brugen af et programværk: Gennem værkets markedsføring og offentliggørelse vil man efter reglerne i varemærkelovens § 4 kunne realisere en erhvervsmæssig brug, der kan indebære en krænkelse af varemærkeretten til det pågældende lydmærke, såfremt der ikke foreligger samtykke hertil. En sådan beskyttelse er dog forholdsvis snæver og vil - ikke mindst pga. de involverede omkostninger til erhvervelse af beskyttelsen - formentlig kun være aktuel for de ganske få typer af programmer, hvor sådanne stilistiske detaljer kan formodes at have betydning for efterspørgslen.

7.3.c "Look and feel"

Direktivet

Rådsdirektivet om retlig beskyttelse af programmer synes principielt at åbne mulighed for beskyttelse af brugergrænsefladen, omend direktivteksten er noget uklar på dette punkt. Efter præamblen omfatter begrebet grænseflade også brugergrænseflader, men art. I, stk.2, 2.pkt., fastslår herefter, at (bl.a.) de idéer og principper, der ligger til grund for programmets grænseflader, ikke nyder ophavsretlig beskyttelse efter direktivet. Beskyttelsen er altså mulig, medmindre grænsefladen er udtryk for en "idé", sml. om dette noget uhåndterlige begreb oven for under 6.2.b. Realiteten er nok, at direktivet af politiske grunde har undladt at tage stilling til spørgsmålet, der herefter må løses i retsanvendelsen.

USA

Når spørgsmålet er kontroversielt skyldes det at situationen - som allerede antydet - sikkert er en anden i USA. Gennem 1980'erne har amerikansk retspraksis gradvist udvidet det ophavsretlige værksbegreb til ikke kun at omfatte det litterære værks litterære elementer, men også det, der med et slagord er blevet kladt "the look and feel".

Første skridt blev taget med den pudsige sag om den talende bjørn "Teddy Roxpin", der ved hjælp af kasettebånd programmeredes til at fortælle historier. Se Worlds of Wonder, Inc. v. Vector Intercontinental, Inc., 653 F.Supp. 135 (1986). Den ophavsret, der her blev lagt til grund knyttede sig imidlertid til et audiovisuelt værk (en værkstype, der ikke anderkendes som sådan af dansk ophavsret). Skridtet mod beskyttelse af programmets ikke-litterære elementer blev første gang taget i Whelan Associates v. Jaslow Dental Laboratory, 797 F.d. 1222 (1986), og senere med Broderbund Software, Inc. v. Unison World, 648 F.Supp. 1127 (1986) og Johnson Controls v. Phoenix Control Systems, 886 F.2d 1173 (1989). I sagen Digital Communications v. Softclone Distributing, 659 F.Supp. 449 (1987), der angik et program til asynkron datakommunikation, blev der givet beskyttelse af et skærmbillede som "compilation", dvs. samleværk (s. 463). En god oversigt over den amerikanske udvikling på området findes hos Per Jonas Nordell i NIR 1999.37 f.

7.3.d. Tekniske grænseflader

Karakteristik

Beskyttelsen af programmets tekniske grænseflader (dvs. de elementer af programmet der skaber interoperabilitet med andre programmer eller systemer) må til dels udledes af samme overvejelser som de, der omhandler brugergrænsefladen: Medmindre der er tale om en litterær beskrivelse af den tekniske grænseflade (som f.eks. er nedfældet i en programdokumentation el.lign.), nyder dette aspekt af programmet ikke selvstændig beskyttelse, hverken som edb-program eller som litterært værk af anden art. Den tekniske grænseflade kan sammenlignes med grundlaget for en roman i en føljeton: For at sidste bind i føljetonen skal kunne læses i sin sammenhæng med de andre, må forfatteren anvende de samme personer, steder og grundbegivenheder, ligesom han - alt efter konceptets fasthed - må sørge for, at handlingen indledes, hvor forrige roman sluttede. Men ingen af disse forhold udgør i sig selv noget "værk" eller "delværk": De fremstår nærmest som faktuelle fikspunkter, som - i stil med andre faktiske forhold - kan begrænse det spillerum, som er til rådighed for den, der vil frembringe et selvstændigt værk (være sig romanen i føljetonen eller et program, der skal kommunikere med et eksisterende).

Closed source

De tekniske specifikationer, der - forud for programkodningen - tilsvarende fastslår, hvordan det nye program skal kommunikere med andre programmer mv. (herunder protokoller for kommunikation mv.) vil ikke være offentligt tilgængelige i såkaldt lukkede systemer. For at kunne udvikle et program, der skal kommunikere med et andet, må man erhverve en tilladelse (licens) til denne information, der ellers vil være hemmeligholdt som erhvervshemmelighed og beskyttet efter de regler herom, der i dansk ret findes i markedsføringslovens § 10. Opnår man ikke en sådan tilladelse, kan man i et vist omfang søge at stifte bekendtskab med dem ved at foretage såkaldt reverse engineering af programmer, der i forvejen er forberedt til denne kommunikation. Reglerne herom, der findes i ophl. §§ 36-37, gennemgås i afsnit 7.4.g.

Licensspørgsmål

Fordi tekniske grænseflader ikke er undergivet en selvstændig ophavsretlig beskyttelse, vil licenser til brugen af dem ofte knytte sig til den tekst, hvori de pågældende protokoller mv. er nedfældet. Som før nævnt vil denne optegnelse kunne beskyttes som litterært værk efter de almindelige regler, og når benyttelsen kombineres med en hemmeligholdelsesklausul vil rettighedshaveren både opnå en sikring mod kopiering, jf. ophl. § 2, og en tredjemandssikring mod videregivelse af oplysninger om selve protokollens indhold.

Nærmere om tekniske grænseflader, Riis (1998), s. 141 f.

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.

7.5. Særlige problemstillinger

7.5.a. Kopibeskyttelse

Det er ikke ualmindeligt, at programrettighedshavere søger at understøtte en licensregulering gennem tekniske foranstaltninger, der søger at sikre, at der ikke kan kopieres i et videre omfang end fastsat. Sådanne anordninger kan enten tilsigte at gøre det helt umuligt at foretage en sådan kopiering (ofte kaldet copy protection) eller dog at vanskeliggøre denne kopiering (ofte kaldet copy discouragement). Eksempler herpå er brug af såkaldte dongles (enheder, der skal være placeret på udstyret, når programmet benyttes) eller indbygning af funktioner, hvorved programmet - enkeltstående eller løbende - afkræver brugeren et password, som brugeren kan identificere ved en fremgangsmåde, der sikrer, at den pågældende har den fornødne brugsret (f.eks. verifikation af hvilket ord, der står bestemte steder i programmets manual).

Det har hidtil vist sig muligt for personer med de rette forudsætninger herfor at bryde sådanne kopispærreanordninger og distribuere kendskabet til disse omgåelsesmetoder effektivt (f.eks. via Internet). Motivet hertil kan være båret af ønsket om at kunne profitere af en ulovlig kopiering og omsætning af de pågældende programmer, men i visse kredse er der formentlig gået sport i at være den første, der "cracker" en ny kopibeskyttelse. Der er på det nærmeste tale om en slags våbenkapløb mellem rettighedshavere og crackere.

I dette kapløb har lovgiveren søgt at komme rettighedshaverne til undsætning ved selvstændigt at kriminalisere selve omsætningen af programmer, der gør det muligt at bryde sådanne kopispærreanordninger. Således hjemler ophl. § 78 bødestraf for den, som forsætligt eller groft uagtsomt omsætter eller i kommercielt øjemed besidder midler, hvis eneste formål er at lette ulovlig fjernelse eller omgåelse af tekniske indretninger, som måtte være anvendt for at beskytte et edb-program eller til at beskytte andre værker i digitaliseret form. Bestemmelsen, der har udspring i direktiv 91/250/EØF art. 7, stk. 1, litra c), omtales nærmere i afsnit 17.5.b. Og i den Digital Millennium Copyright Act, der blev vedtaget i USA i 1999, er der sket en lignende kriminalisering.

Det er vigtigt at slå fast, at en kopispærreanordning ikke i sig selv påvirker omfanget af de licensrettigheder, en bruger har. Når man skal fastslå, hvilke beføjelser slutbrugeren har til at benytte et program, må man tage udgangspunkt i, hvad der er aftalt eller, hvad der fremgår af licensregimet i ophl. §§ 36 og 37. Samspillet mellem denne regulering og de de facto-begrænsninger, der sættes af en kopispærreanordning, ligger i, at brugeren har ret til at angribe en kopispærreanordning, der hindrer ham i at kunne benytte programmet på lovlig vis. Nærmere herom i afsnit 17.5.b.

7.5.b. Public domain

For visse programværker gælder det, at de - undertiden i større eller mindre udstrækning - kan udnyttes uden immaterialretlige bånd. Med en amerikansk betegnelse hører programmerne til " the public domain" (almenhedens rådesfære) - enten fordi der af retlige grunde slet ingen ophavsret gælder på det pågældende område, eller fordi rettighedshaveren af forskellige grunde har valgt ikke at gøre sine rettigheder gældende.

Retlige årsager

Det vil høre til sjældenhederne, at et programværk af retstekniske grunde befinder sig i public domain. Med den almindelige globale tilslutning til Bernerkonventionen (der forbyder formkrav som betingelse for at opnå ophavsret) er det den praktiske regel, at alle programværker med den fornødne originalitet også beskyttes ophavsretligt. Men en undtagelse kan netop tænkes, hvis et programværk ikke opfylder kravene til originalitet. Dernæst kan det - teoretisk - forekomme, at et programværk er skabt i et land, som ikke beskytter ophavsretten, og som Danmark derfor ikke har indgået gensidighedsoverenskomst med efter den almindelige regel i ophl. § 88. Med den nugældende beskyttelsestid på 70 år efter ophavsmandens dødsår kommer det derimod til at vare en rum tid, før public domain-programmel vil forekomme pga. udløb af ophavstiden. I relation til disse regler har reglerne om public domain dog stor praktisk betydning for så vidt angår den brug af litterære og kunstneriske værker (f.eks. af billedkunst og musik), som ofte inkorporeres i nutidens programværker.

I det omfang en immaterialret udspringer af en registrering eller offentlig godkendelse, kan det tænkes, at rettigheden overgår til public domain, hvis den nødvendige registrering ikke opretholdes, f.eks. når et patent eller en halvlederret udløber, eller når det formelle grundlag for at opretholde denne ret (afgiftsbetaling mv.) ophører. Disse public domain-tilfælde har primært betydning i relationen mellem professionelle programudviklere - ikke i relation til den enkelte bruger.

Afståelsestilfælde

I det følgende sættes fokus på de mest praktiske tilfælde, hvor der er tale om, at rettighedshaveren helt eller delvis opgiver sin ret til en ophavsretlig retsposition. Situationen kan enten foreligge ved, at rettighedshaveren vælger - nu eller senere - at undlade at opkræve betaling for udnyttelseshandlinger, der ellers falder inden for hans eneret, eller ved at han uden at forbeholde sig betalingskrav stiller krav om, hvorledes programmet skal anvendes.

Udgangspunktet er her, at immaterialrettens regler giver rettighedshaveren fuld frihed til at klausulere sit krav om vederlag, som han vil. I betragtning af dispositionens rækkevidde kræves dog et utvetydigt tilsagn om rettens opgivelse fra den beføjede indehaver af de rettigheder, der er tale om at opgive. Det er ikke tilstrækkeligt rent faktisk at undlade at opkræve licensafgift eller at undlade at forfølge pirateri. Tilsagnet kan f.eks. foreligge ved, at programdele stilles til rådighed fra en hjemmeside med opfordring for almenheden til at hente dem her. Ved at afgive en sådan melding ændrer programmet populært sagt karakter fra at være "payware" (betalingspligtigt) til i en eller anden forstand at være " freeware" (gratis).

Fortolkning

Typisk vil rettighedshaveren ikke opgive samtlige rettigheder til sit program, og selv om han skulle ønske dette, følger det af ophl. § 3, at de personlige rettigheder ikke kan opgives, medmindre det gælder en efter art og omfang afgrænset brug af værket. Ligeledes rummer ophl. § 53 en regel om tilbageholdende fortolkning af ophavsretlige overdragelsesdispositioner.

Praktiske tilfælde

I praksis opgives de ophavsretlige retspositioner i visse typiske tilfældegrupper:

- markedsføring

Den ene er, at programmet foreligger i sin første udgave og endnu ikke er markedsført bredt. Formålet med at give det frit er at skabe almindelig interesse for det. Ved på denne måde at opnå en bred brugerskare håber producenten at berede markedet for næste version af programmet, som så markedsføres mod betaling. Denne praksis ses hyppigt på markedet for Internet-applikationer. Den web-browser, der fik sit første kommercielle gennembrud, fra firmaet Netscape, blev markedsført på denne vis. I denne situation er det åbenbart, at de rettigheder, der opgives, er snævert afgrænsede til denne første version af programmet, og at brugeren f.eks. ikke opnår en almindelig ret til - hvis dette ellers er praktisk muligt - at videreudvikle det til nye versioner.

- idealisme

Det andet yderpunkt foreligger, når afståelsen af retten til et program bæres af idealistiske motiver. Disse motiver kan være af forskellig, mere eller mindre kommerciel, slags. For det første kan det tænkes, at den kommercielle interesse for et program er forsvundet. Rettighedshaverens formål med at lægge det frit er her en kombination af ideel uegennytte og et vist kommercielt ønske om dog at markere overfor offentligheden, hvilken rolle han har spillet - og måske fortsat spiller - på dette område. Men det kan også tænkes, at beslutningen herom er truffet efter mere rendyrkede idealistiske motiver, jf. herom straks nedenfor om open source-bevægelsen. I begge disse situationer vil der være en større sandsynlighed for, at brugeren har frie hænder med hensyn til sin anvendelse af programmet.

- open source

I 1997 etablerede en række deltagere i den amerikansk baserede organisation Free Software Foundation, der var stiftet mange år forinden af dr. Richard Stallman, en organisation kaldet The Open Source Institute, se <www.opensource.org>, der som en af sine første gerninger fastslog de krav, der generelt må være opfyldt for at betegne programmel som open source-programmel. Gennem 9 punkter fastslås de retlige kriterier, som må opfyldes, for at programmel skal kunne betegnes som open source programmel. Reglerne indebærer bl.a., at der ikke må lægges begrænsninger i den frie ret til at distribuere open source programmel - med eller uden ændringer - at programmets kildetekst skal være tilgængelig, og at den, der føjer ændringer til et open source program, må tillade andre at gøre det samme i det således ændrede program.

Som denne definition foreligger, indebærer den ikke, at open source-programmel lægges i public domain. Selv om meningen med at knytte sig til definitionen er at opnå en række af de fordele, som ellers kan opnås gennem public domain-afgivelse, er det klart underforstået, at ophavsretten til den pågældende kode fastholdes. Formålet er netop at udøve denne ophavsret på en måde, der harmonerer med de formål, der ønskes tilgodeset.

Open source-definitionen søger primært at regulere de frihedsgrader, der gælder for programudvikleren. I relation til slutbrugere suppleres den af andre licenser, hvoraf den såkaldte GNU General Public License (GNU-GPL) hører til de hyppigt benyttede, se <www.fsf.org/copyleft/gpl.html>. I denne licens pointeres det i øvrigt, at "free" skal forstås i betydningen "ubundet af retlige bånd", og ikke i betydningen "gratis": Vilkårene giver brugeren ret til fri anvendelse af programmet til selvvalgt formål, fri ret til at undersøge programmet, frihed til at kopiere programmet samt sprede kopier af det til tredjeparter - med eller uden betaling - samt frihed til at forbedre programmet og kopiere og sprede eksemplarer af det forbedrede program. Blandt den software, der hyppigt distribueres under sådanne licenser, er det såkaldte LINUX styresystem. Se nærmere herom Mikael Pawlo i L&D no. 65, marts 2001, s. 13 ff.

Bevisspørgsmål

En af de fordele, der er opstået i konsekvens af den stigende anvendelse af open source-programmel, er en øget klarhed omkring det rettighedsmæssige spillerum for brugen af den slags programmel. Man knytter sig til en rettighedsdefinition, som klart markerer den frihed, der gælder for den enkelte bruger til at bruge, videreudvikle og distribuere programmellet. Uden for sådanne tilfælde kan det imidlertid være risikabelt at anvende public domain-programmel som grundlag for en almindelig programudvikling. Skulle der opstå en konflikt med en påstået rettighedshaver (som ad teknisk vej typisk vil have let ved at identificere de programkomponenter i det nu "nye" programværk, han gør retskrav gældende for), vil det være udvikleren af det nye program, der har bevisbyrden for, at der er meddelt det fornødne samtykke til denne anvendelse. Problemet er her, at udvikleren ikke har noget kontraktsforhold til den part, som påstås at have opgivet sin ophavsret, og at det i øvrigt kan være vanskeligt at bevise, hvad det egentlig var for et samtykke, der blev meddelt. Kan dette bevis ikke føres, vil en dokumenteret rettighedshaver tænkes at kunne nedlægge forbud mod brugen af det færdigudviklede program, jf. den almindelige regel om bearbejdninger i ophl. § 4, stk. 1.

I praksis har der formet sig forskellige variationer af opgivelsesdispositioner, der beror på, hvilke enerettigheder der opgives, se herom Andersen & Græbe (1990), s. 34 ff.

"Freeware"

Man anvender således ofte betegnelsen "freeware", når programmet er gratis at anskaffe og bruge, idet rettighedshaveren dog fastholder sine grundlæggende rettigheder til det. Brugeren er altså fortsat begrænset i sine udfoldelsesmuligheder vedrørende produktet. Han kan f.eks. ikke videredistribuere det, hverken gratis eller mod betaling, medmindre han opnår licens hertil. Ligeledes forbyder rettighedshaveren ofte, at der sker ændringer i programmet.

Shareware

Shareware-programmel kan distribueres frit og uden betaling i umodificeret form, indtil brugeren bestemmer sig for at bruge det, f.eks. inden for en prøveperiode af 90 dage. Når dette sker, skal programmet registreres, og denne registrering vil normalt være forbundet med en betalingspligt. Formålet med den indledende betalingsfrihed er typisk at give brugeren mulighed for en indledende aftestning mv. Udover at rettighedshaveren altså principielt ikke kræver betaling for denne indledende brug, har shareware-konceptet den praktiske side, at rettighedshaveren typisk ikke retsforfølger dem, der - mod intentionerne - undlader at betale for den fortsatte brug.

Betalingskrav

Ved brugen af shareware-programmel opstår spørgsmålet, om brugeren er forpligtet til at erlægge den licensafgift, rettighedshaveren forlanger erlagt, når prøveperioden for programmet er udløbet. Spørgsmålet må besvares med udgangspunkt i den legale programlicens i ophl. § 36, stk. 1, nr. 1, og er for så vidt enkelt: Da det angivne formålskriterium er afgørende, må man se på, hvilke krav brugeren blev præsenteret for ved aftaleindgåelsen. Dette fører utvetydigt til, at der opstår en retlig pligt til enten at ophøre med brugen eller erlægge en betaling som den opkrævede. Den retlige konstruktion, der ligger bag denne pligt, kan rettest beskrives som en kvasiaftale.

Se modsat Wagle & Ødegaard (1997), s. 258 f., der dog tilføjer, at problemet næppe har den store interesse, da rettighedshaveren ofte vil have sikret sit betalingskrav med en kopispærrefunktion, der træder i funktion, hvis ikke der sker betaling (og efter betaling indtastes en kode el.lign., der tillader fortsat brug).

7.5.c. Pligtaflevering

Oversigt

Ved lov nr. 423 af 10. juni 1997 er det bestemt, at der af værker, der udgives her i landet, skal afleveres to eksemplarer til en pligtafleveringsinstitution (i praksis Det Kongelige Bibliotek i København og Statsbiblioteket i Århus), se lovens § 1. Som det gælder for den tidligere lovgivning herom (der går helt tilbage til 1697) er formålet med denne lov at sikre, at den litterære arv kan føres videre til kommende generationer. Loven bygger på forslaget fra Udvalget om bibliotekerne i informationssamfundet i Betænkning om Pligtaflevering (juni 1995). Med den seneste lov søges dette formål sikret også for værker, der udgives på digitale medier mv. Derfor knytter der sig en betydelig interesse til at få fastslået lovens rækkevidde i relation til digitale frembringelser.

Loven suppleres med en bekendtgørelse om pligtaflevering af udgivne værker, nr. 1041 af 17. december 1997. Yderligere vejledning om det ikke helt ukomplicerede regelsæt kan i øvrigt hentes fra <www.pligtaflevering.dk>.

Lovens værksbegreb

Ifølge loven forstås begrebet værk bredt som "en afgrænset mængde af information, som må betragtes som en afsluttet og selvstændig enhed", jf. § 1, stk. 2. Det er uden betydning, hvordan værket er udgivet. Også Internet-hjemmesider eller værker udgivet på medier til lagring af digitale data, som f.eks. cd'er og DVD'er, samt kassettebånd og videofilm er omfattet. Værker i form af edb-programmer skal dog ikke afleveres, medmindre et eksemplar af et edb-program udgør en del af et værk af en anden art (f.eks. en elektronisk ordbog) og udgives sammen med dette, jf. lovens § 1, stk. 7. Computerspil og multimediaværker anses derimod for afleveringspligtige. Edb-manualer er kun afleveringspligtige, hvis de vedrører programmer, der skal afleveres, jf. bekendtgørelsens § 2, stk. 1, andet led.

Udgivelseskriteriet

Afleveringspligten indtræder ved værkets "udgivelse". I overensstemmelse med den ophavsretlige sprogbrug indtræder dette, når eksemplarer af værket med ophavsmandens samtykke er bragt i handelen eller på anden måde spredt blandt almenheden, jf. lovens § 1, stk. 3. Bestemmelsens stk. 4 udvider dog begrebet til også at omfatte de for Internet-anvendelsen så centrale tilfælde, hvor det med ophavsmandens samtykke meddeles almenheden, at eksemplarer af værket fremstilles og distribueres på bestilling, eller at værket er tilgængeligt i en database, hvorfra brugeren kan hjemtage et eksemplar (såkaldte netudgivelser). Som følge heraf indtræder afleveringspligten i det øjeblik, værket lægges på en hjemmeside på en måde, så almenheden kan hente kopier af det, og altså ikke først, når der rent faktisk hentes sådanne kopier.

Netudgivelser giver anledning til særlige problemer, som er søgt reguleret ved bekendtgørelsens § 1, stk. 2, nr. 9. Denne bestemmelse undtager bl.a. en række praktisk vigtige områder fra afleveringspligten. Således skal bl.a. indlæg i nyhedsgrupper, artikler i dynamiske internetaviser og artikler i online-tilgængelige leksika (når leksikonet ikke er udgivet som helhed) ikke pligtafleveres.

Pligtens opfyldelse

Gennemførelsen af afleveringspligten giver ikke anledning til problemer, når værket udgives i klassisk form, f.eks. som bog eller musik-CD. Men hvis tilegnelsen af værkets informationsindhold kræver brug af særligt udstyr, må der tages særlige skridt for at give afleveringspligten reelt indhold. Kan værket således kun gøres tilgængeligt ved brug af teknisk udstyr, skal den nødvendige vejledning hertil ledsage de afleverede eksemplarer, jf. § 2, stk. 2. Denne vejledningspligt omfatter ligeledes teknisk dokumentation, såfremt læsning af de pågældende værker ikke følger "normale standarder".

I relation til rent elektroniske udgivelser opfyldes pligten ved, at udgiveren anmelder de enkelte værker, som er udgivet, og som skal pligtafleveres. Anmeldelse skal ske til den til formålet oprettede hjemmeside og omfatte de oplysninger, som er nødvendige for, at pligtafleveringsbiblioteket er i stand til at hjemtage det pågældende værk i en form, så værket kan benyttes, jf. nærmere bekendtgørelsens § 2, stk. 5. Afleveringspligten opfyldes således ved, at pligtafleveringsinstitutionen har adgang til at rekvirere eller fremstille et eksemplar af værket. Der er etableret et anmeldelsessystem hertil via adressen <www.pligtaflevering.dk>.

Pligtsubjektet

Afleveringspligten påhviler den, som færdiggør værket til udgivelse, jf. lovens § 4. Det betyder for bøgers vedkommende trykkeriet; for CD-produkters vedkommende den tekniske leverandørvirksomhed, der præger CD-mediet. Er værket udgivet i udlandet, påhviler afleveringspligten dog udgiveren eller, hvis denne ikke er bosiddende her i landet, importøren, jf. § 3, stk. 3. Som følge af denne regel har udgiveren pligt til at anføre sit navn, firma eller hjemsted på værket. For så vidt angår værker udgivet i en database definerer bekendtgørelsens § 3, stk. 2, den afleveringspligtige som den, der står for den tekniske færdiggørelse af det digitale eksemplar, der indlægges i databasen.

Supplerende litteratur

Om litteraturens behandling af den ophavsretlige beskyttelse af edb-programmer henvises til litteraturangivelsen i slutningen af kapitel 6.

Reglerne om interoperabilitet i 1991-direktivet om beskyttelse af edb-programmer er bl.a. behandlet af Thomas C. Vinje i NIR 1992.74 ff.

Problemerne omkring public domain-rettigheder påkalder sig først og fremmest interesse i relation til software. På dansk foreligger en god og fyldig gennemgang af dette emne i Poul Andreasen og Peter Græbe: Shareware håndbogen (1990). Se for tysk ret Bernd Schultz: Shareware - Handel, Marktanteile und Rechtsfragen i CuR 1990.296. Emnet behandles kort i slutbetænkningen fra udvalget vedrørende revision af ophavsretslovgivningen (betænkning 1197/1990), s. 159.

Anvendelsen af reglerne om pligtaflevering i relation til netudgivelser mv. er bl.a. berørt i et notat af 14. oktober 1997 fra Kulturministeriet. Se ligeledes om loven og dens forhistorie Peter Blume i Henrik Horstbøll & John T. Lauridsen: Den trykte Kulturarv (1998), s. 265 ff.

Indholdsfortegnelse | Forrige kapitel | Næste kapitel