Bing Hodneland logo

Fra 1. august 2012 vil jeg være advokat på heltid som partner i Bing Hodneland.

For mer om opphavsrett, les min bok Opphavsrett for begynnere.

Bokomslag

Se mer om boken her.

Nye bøker


Mer >>
Flere nye bøker

Gå til "bokhandelen"

Geocaching i Norge
Amazon US
In Association with Amazon.co.uk


Previous page:

Opphavsrett til dataprogrammer utviklet i vertikalt samarbeid

Next page:
Previous page: Høyesteretts dom i napster.no saken: ¾ seier for internet Next page: ?ndsverkloven § 54 første ledd, bokstav e:
Et monument over en dyktig lobbyist og en naiv politiker

Opphavsrett til dataprogrammer utviklet i vertikalt samarbeid.

Olav Torvund

1Innledning

Dataprogrammer av noe størrelse utvikles ofte i det som kalles en vertikal samarbeidsprosess.(1) Deltagerne bidrar da på ulike stadier i utviklingsprosessen.

Et typisk utviklingsforløp kan være slik: En har en idé. En annen, gjerne en konsulent, spesifiserer hvilke oppgaver som skal løses for å realisere ideen (kravspesifikasjon). En tredje spesifiserer hvordan et dataprogram kan utformes for å løse disse oppgavene (systembeskrivelse). En fjerde utformer så det ferdige produktet på bakgrunn av systembeskrivelsen.

Utgangspunktet er her som for andre verk at den som skaper verket har opphavsretten. Men når mange bidrar i prosessen, kan det være vanskelig å avgjøre hvem som bidrar på en slik måte at det kvalifiserer til (med)opphavsrett i det ferdige programmet som utvikles.

Hvis alle som deltar er ansatt hos samme arbeidsgiver går rettighetene over til arbeidsgiver i medhold av åvl § 39g. Men det kan være ulike konsulent- og programmeringsselskaper som deltar på ulike stadier, og da får vi ingen hjelp av åvl § 39g.

Et første spørsmål er hvem som bidrar med skapende innsats av en slik art at den i seg selv kvalifiserer til opphavsrett for det man selv har frembragt. Dette er et nødvendig minstevilkår for at man skal kunne kreve opphavsrett til noe som helst. Idéer er f.eks. ikke opphavsrettsbeskyttet, så den som har idéen får ikke i kraft av dette noen opphavsrett.

Deretter må man se på forholdet mellom de ulike opphavsmenn. Det kan tenkes tre ulike løsninger:

  1. · De som kommer inn i prosessen utnytter de foreliggende verk på en slik måte at et nytt og selvstendig verk oppstår. De som har bidratt på tidligere stadier i prosessen vil da etter åvl § 4, annet ledd ikke få noen (med)opphavsrett til verket.
  2. · De som kommer inn sent i prosessen bearbeider verk som andre har skapt. De som står for bearbeidelsen får da en uselvstendig opphavsrett i verket i bearbeide skikkelse, men har ingen rettigheter i det verk som har vært gjenstand for bearbeidelse. Opphavsmennene til det opprinnelige verket får ingen direkte medopphavsrett til den bearbeidede versjonen.(2)
  3. · Verket er et fellesverk utviklet i samarbeid, slik at opphavsretten blir liggende i sameie mellom de som har deltatt.(3)

At ens innsats i seg selv kvalifiserer til opphavsrett, betyr ikke nødvendigvis at man får noen opphavsrett til det program som blir resultatet. Et ganske praktisk eksempel er at det utarbeides en rapport fra et forprosjekt med kravspesifikasjon. Rapporten kan i seg selv være et åndsverk, uten at et program som utvikles med utgangspunkt i rapporten vil være en bearbeiding av denne.

Den foreløpige konklusjon er at den som utarbeider kravspesifikasjonen ikke har opphavsrett til det ferdige programmet. Opphavsretten ligger hos den som spesifiserer hvordan programmet skal utformes for å løse oppgavene, og/eller hos den som lager det ferdige programmet i henhold til en slik spesifikasjon.

For å kunne drøfte dette videre er det nødvendig å se nærmere på dataprogrammet som verk og på hvordan dette utvikles.

2Kildekode

En datamaskin arbeider med binære verdier: 0 og 1. Alle programmer må skrives som kombinasjoner av et-tall og nuller for at maskinen skal kunne utføre programmet. Opprinnelig programmerte man datamaskinene ved å sette brytere av og på.

I dag skrives programmene i egne programmeringsspråk. Eksempler på slike språk er Basic, Java, C og C++. Disse språkene er sett av definerte kommandoer. Det som skrives på i slike språk kalles programmets kildekode. Nedenfor er et eksempel på kildekoden til et enkelt program som regner ut karakter for en kandidat etter eksamensordningen av 1984. Programmet er skrevet i programmeringsspråket C++:

// karakter.cpp
// regner ut snittkarakter
#include
void main(void)
\{

double Kar1;
double Kar2;
double Kar3;
cout << "Beregning av samlet karakter" << endl << endl;
cout << "Skriv karakter 1 ";
cin >> Kar1;
cout << "Skriv karakter 2 ";
cin >> Kar2;
cout << "Skriv karakter 3 ";
cin >> Kar3;
double Total;
Total = Kar1 + Kar2 + Kar3;
Total = Total/3.0;
double Strykgrense;
Strykgrense = 3.15 ;
if (Kar1>3.15 || Kar2>3.15 || Kar3 > 3.15)
\{
Total = Total + 0.1;
Strykgrense = 2.95;
}
if (Kar1>3.20 || Kar2>3.20 || Kar3 > 3.20) \{
Total = Total + 0.15;
Strykgrense = 2.95;
}
if (Kar1>3.25 || Kar2>3.25 || Kar3 > 3.25) \{
Strykgrense = 0;
}
if (Total>Strykgrense)
cout << "Ikke bestått." <else
cout << "Totalkarakteren blir " << Total;
}

// main

 

En datamaskin kan ikke utføre et program i kildekode. Programmet må overføres til binær maskinkode før instruksjonene kan utføres. Til dette brukes et program som «oversetter» kildekoden til maskinkode. Vanligvis oversettes hele programmet, slik at brukeren bare har programmet i maskinkode. Oversettelsen kalles i edb-terminologi for kompilering, og programmet som benyttes kalles en kompilator. Kommandoordene i kildekoden er instrukser til oversettelsesprogrammet om hvilken kode som skal genereres.

Da diskusjonen om opphavsrettslig vern av dataprogrammer begynte, var litteraturmetaforen den mest nærliggende. Kildekodens språk er stivt og formuleringene lite spennende. Men det ligner i alle fall på en tekst. Programmet i denne form kan med litt velvilje kalles et stykke litteratur, i alle fall hvis man med litteratur mener «skrifter av alle slag»,(4) som det heter i åvl § 1, annet ledd, nr. 1.

Denne argumentasjonen har vunnet fram, og i dag er det ingen tvil om at dataprogrammer er beskyttet som litterært verk, forutsatt at det har den nødvendige verkshøyde. Dette sies klart både i EFs direktiv om vern av dataprogrammer art. 1, og de nylig vedtatte tilleggene til Bern-konvensjonen.(5) I den norske lovgivningen sies ikke dette uttrykkelig, men det er i forarbeidene klart forutsatt at dataprogrammene også etter norsk rett skal anses som litterære verk.(6)

I dag vil man ikke nødvendigvis skriv programmet som tekst. Følgende to figurer gir en annen form for kildekode. Dette blir til sammen en enkel kalkulator med de fire regneartene og «papirstrimmel»:

Også dette er basert på programmeringsspråket C++, men her benyttes et programmeringsverktøy med et grafisk brukergrensesnitt. De enkelte elementene er ferdig definerte funksjoner som kan hentes inn fra et funksjonsbibliotek.

Pilene mellom elementene definerer relasjoner og hvilke handlinger som skal utføre når man f.eks. «trykker» på en knapp. Disse definisjonene er ikke synlige i bildet, men kan hentes fram ved å klikke på pilen eller elementet.

Også tradisjonell kildekode benytter funksjonsbiblioteker. I karakterprogrammet sier programsetningen #include at kodebiblioteket iostream.h skal inkluderes, og kildekoden til disse programrutinene er i seg selv større en den koden jeg har skrevet.

Dette programmeringsverktøyet genererer kildekode, som igjen kan kompileres til et utførbart program. Kildekoden til mitt programeksempel vil for utgjøre ca 3.000 programlinjer, eller ca 60 sider om den skrives ut.

Likheten mellom dataprogrammer og tradisjonelle litterære verk er overfladisk. Har man litteratur som utgangspunkt for vurdering av hvem som har rettighetene, fanges man lett av den litterære metafor, og det kan lede feil. Litteratur henvender seg direkte til leseren og skal gi denne en leseropplevelse og/eller kunnskap. Litt unøyaktig kan man si at teksten er verket. Dataprogrammets kildekode er ikke skrevet for å leses. Målet er å gi styringsinstrukser til maskinen, ikke å utforme en tekst. Teksten er her et blant flere mulig hjelpemidler for å beskrive verket.

Man må gå til andre verkskategorier for å finne noe som tilsvarer kildekode. Følgende har funksjonelt langt mer til felles med dataprogrammene kildekoden enn hva f.eks. teksten i denne artikkelen har:

De fleste vil nok kjenne igjen «programmeringsspråket», men man skal være trenet i å lese slik kode for å kjenne igjen verket. Og akkurat som for dataprogrammer, kunne jeg ha valgt flere andre «programmeringsspråk» for å beskrive dette verket.(7) Hvis «programmet» utføres enten av kompetente musikere eller av en dertil egnet datamaskin, vil nok alle kjenne igjen dette musikkstykket. Det er en del av den franske komponisten Marc-Antoine Charpentiers preludium fra hans Te Deum, og dette utdraget har vært Eurovisjonens kjenningsmelodi siden 1959.

Et dataprogram er instruksjonene og ikke den tekst som uttrykker dem, akkurat som et musikkverk er musikken og ikke notebildet. Et banalt musikkstykke med et likegyldig arrangement kan godt gi et komplisert notebilde, akkurat som et enkelt program kan bestå av mye kode. Men et enkelt kalkulatorprogram får ikke verkshøyde selv om kildekoden kan virke komplisert og utgjør 60 tekstsider.

De to tegningene til kalkulatorprogrammet kunne ha vært tegnet på et papir sammen med en beskrivelse av hvilken dataflyt pilene representerer, behandlingen i boksene og hvilke data som skal presenteres. Dette ville utgjøre en tradisjonell systemspesifikasjon. Hvis vi later som om et slikt program har verkshøyde, og setter bort oppdraget med å skrive programmet i henhold til disse spesifikasjonene, hvem vil da ha opphavsrett til programmet?

Det har til nå vært vanlig å hevde at den som utformer programmet i henhold til spesifikasjonene som hovedregel får opphavsretten. Som grunnlag for dette har vært anført at systemerernes anvisninger ikke alltid er «så spesifikke at de bestemmer den konkrete utformingen av programmet».(8)

Et nøkkelord i argumentasjonen er variasjonsbredde. Hvis mange valg står åpne for programmereren, trekker dette i retning av at denne får opphavsrett.(9) Resonnementet hopper over et viktig moment: Programmererens innsats må være skapende. Det å treffe valg blant flere omtrent likeverdige alternativer er ikke nødvendigvis skapende. At det krever en viss faglig innsikt, og at noen vil være flinkere til å treffe gode valg enn andre, endrer ikke dette utgangspunktet. Noen håndverkere er dyktigere enn andre, men godt håndverk er ikke tilstrekkelig til å få opphavsrett.

Hvis programmereren ikke kan foreta selvstendige valg, vil det utelukke opphavsrett. Men at det foretas valg er ikke avgjørende for at resultatet har verkshøyde. Variasjonsbredde er en nødvendig, men ikke tilstrekkelig betingelse for å oppnå opphavsrett. At man må treffe mange valg, slik at antall mulige kombinasjoner kan bli veldig stort, kan heller ikke være avgjørende. ? legge avgjørende vekt på antallet valg og valgmuligheter, vil innebære at man gir opphavsrett basert på mengden arbeid og ikke på arbeidets art.

I mitt lille karakterprogram kunne jeg f.eks. ha valgt å kalle karaktervariablene Praktikum, Teori1 og Teori2, i stedet for Kar1, Kar2 og Kar3. Kanskje kunne jeg også satt karakterer som hele tall (245 i stedet for 2,45), og basert programmet på heltallsberegning i stedet for flyttall. Beregning av «straffetillegg» og strykgrenser ved stryk på enkeltbesvarelser kunne også vært satt opp på andre, og kanskje bedre måter. Men denne type valg representerer ikke noen skapende innsats.

For litterære verk kan man vanskelig tenke seg en situasjon hvor en person kan utforme verkets struktur og hovedelementer, og så overlate den endelige utformingen til andre, og likevel beholde opphavsretten. Ut fra en litteraturmetafor blir det dermed vanskelig å tenke seg en situasjon hvor den som gir verket dets endelige utforming ikke har opphavsrett.

I arkitektur og musikk er dette mer vanlig. Det kan ikke være tvil om at den danske arkitekten Jørn Utzon er opphavsmann til operahuset i Sidney, selv om andre arkitekter overtok ansvaret før huset sto ferdig. Andre kan muligens ha en medopphavsrett. Men det er først og fremst Jørn Utzons arkitektoniske uttrykk som gir verket dets identitet, ikke alle «detaljer» som andre måtte finne en løsning på.

I musikkens verden trenger vi ikke gå lenger enn til mitt lille utdrag fra Charpentiers Te Deum. Jeg har bare gjengitt melodien, ikke harmonier og understemmer. Men selv om mye er utelatt, så er det en gjengivelse og ikke en beskrivelse av verket. Det er først og fremst melodilinjen som gir denne del av verket dets identitet, ikke de elementene som jeg har utelatt. (Men Charpentier døde i 1704, så verket er uansett fritt i dag.)

Populærkomponister presenterer ofte sitt verk i en enkel og ganske ubearbeidet form, gjerne som en melodilinje med besifring. Om en annen så utarbeider et arrangement og skriver ut instrument- og vokalstemmer til de musikerne som skal delta, så får denne kanskje opphavsrett til sin bearbeidelse. Men komponisten taper ikke sin opphavsrett selv om en annen skriver ut detaljene.

Vender vi tilbake til edb-systemer, må den som har bidratt med det som gir programmet det særpreg (hvis det har noe), være opphavsmann til programmet. Min påstand er at programmets særpreg ligger i dets logiske struktur og oppbygging, ikke den detaljerte utforming av de enkelte rutiner i programmet. Min konklusjon er at den som utarbeider systembeskrivelsen er opphavsmann til det programmet som utvikles. Den som koder programmet i henhold til systembeskrivelsen kan ikke få mer enn en medopphavsrett eller opphavsrett til eventuelle bearbeidelser som måtte ha verkshøyde.(10)

Hvis både systemutviklerens og programmererens innsats har verkshøyde, møter vi spørsmålet om det ferdige program må anses som et fellesverk, eller om programmereren bearbeider systemutviklerens verk. Utgangspunktet må etter min vurdering være at dersom arbeidet er organisert slik at man i praksis kan skille mellom systemutvikling og programmering, bør programmeringen regnes som en bearbeidelse av systembeskrivelsen.

Dette utgangspunktet er ikke til hinder for at partene kan avtale en annen løsning. En slik avtale trenger ikke være uttrykkelig, og kan f.eks. anses for å følge av måten hele utviklingsprosjektet er organisert på.(11)

Endelig kan det tenkes at arbeidet er organisert slik at det faktisk er et samarbeid som gjør det hele til et fellesverk. Det er ikke uvanlig med en iterativ utviklingsprosess, hvor systembeskrivelsen revideres med utgangspunkt i programmeringsarbeidet. Det er som når disposisjonen til en bok eller artikkel må omarbeides etter at man har forsøkt å skrive etter den. Men da har man ikke lenger et vertikalt utviklingssamarbeid.

Noter

(1) Jon Bing Opphavsrett og edb, s. 53, Tarjei Stensaasen Rettslig vern av edb-programmer og databaser, s. 100-101 og s. 103.

(2) Lassen TfR 1983 s. 329

(3) For en generell drøftelse av sameie i opphavsrett, se Lassen TfR s. 324??428.

(4) Se Jon Bing: Opphavsrett og edb, CompLex 2/85, s. 23-24. Opphavsrettsutvalget er noe mer forbeholdent, og mener at det for de fleste ikke ville være naturlig å se datamaskinprogrammer som eksempel på «skrifter av alle slag», se NOU 1986:18 s. 28. Se også drøftelse i Tarjei Stensaasen Rettslig vern av edb-programmer og databaser, Oslo 1987, s. 42-48.

(5) WIPO Copyright treaty, WIPO-dokument CRNR/DC/89, 20. desember 1996, Art. 4.

(6) Ot.prp. nr. 33 (1989-90) s. 14.

(7) Man kan bruke tekstkode tilsvarende vanlig kildekode til dataprogram; «pianorull», som er vanlige når man skal programmere en datamaskin til å spille musikk ved hjelp av et sequenzer program, instrumenttilpasset tabulatur, osv.

(8) Bing, l.c. s. 53. Tilsvarende SOU 1985:51 s. 91.

(9) Bing l.c. s. 31-32.

(10) Se en annen oppfatning i Bing l.c. s. 53.

(11) Lassen TfR 1983 s. 331.


Opphavsrett


More >>
Forfatter: Ole Andreas Rognstad
Boken gir en fremstilling av opphavsretten i vid forstand, det vil si vernet for åndsverk og nærstående prestasjoner. I tillegg behandles tilgrensende områder som vederlagsordninger og vernet for private håndteringssystemer.

Det redegjøres for opphavsrettens historikk og begrunnelse, og hovedtrekkene i åndsverklovens regler fremstilles i lys av den internasjonale utviklingen på opphavsrettsområdet. Boken er beregnet på jusstudenter, jurister og andre som i sitt virke berøres av opphavsrettslige problemstillinger. Med litteraturliste og stikkordregister.

Bestill fra:
Bokkilden
Level: , 459 pages RefNr: 9788215007298
Format: Method Medium: Book (hardcover)
Series: Publisher: Universitetsforlaget