Nye bøker


Mer >>
Flere nye bøker

Gå til "bokhandelen"

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


Previous page:

Særlig om spesielt utviklede programmer

Next page:
Previous page: Rettigheter til dokumentasjon Next page: "Reverse engineering"

Rettigheter til særskilt utviklede programmer reiser spesielle problemer, og det kan ligge mye konfliktstoff i spørsmålet om hvem som har rettighetene til det utviklede program dersom dette ikke er avklart i kontrakten. Utgangspunktet er her at rettighetene oppstår hos den som faktisk utvikler programmene, og en eventuell overdragelse må være basert på en avtale mellom partene. Når man skal ta stilling til spørsmålet, må man ta utgangspunkt i avtalen og se om denne kan anses å inneholde en overdragelse av rettigheter til oppdragsgiver.

?ndsverkloven har enkelte bestemmelser som gir visse holdepunkter for tolking av avtaler om overdragelse av opphavsrett. Den viktigste er åvl § 39a, som lyder:

Har opphavsmannen overdratt rett til å bruke verket på en bestemt måte eller ved bestemte midler, har erververen ikke rett til å gjøre det på andre måter eller ved andre midler.

Denne bestemmelsen uttrykker det som gjerne omtales som spesialitetsprinsippet, eller spesialitetsgrunnsetningen. Dette innebærer at slike avtaler tolkes snevert i opphavsmannens favør: Erverver får de rettigheter (beføyelser) som følger direkte av avtalen, mens opphavsmannen beholder øvrige beføyelser.

Hovedregelen blir dermed at oppdragsavtalen kan innebære overdragelse av visse opphavsrettslige beføyelser selv om dette ikke er sagt uttrykkelig, men at det skal mye til for at opphavsretten skal anses for å ha gått over i sin helhet. Man har altså en situasjon hvor opphavsrettslige beføyelser, og endog opphavsretten i sin helhet, kan overdras ved de mest uklare avtaler: De underforståtte og de implisitte avtaler. Samtidig har man et prinsipp om at uklare avtaler tolkes i opphavsmannens (oppdragstagers) favør. Det er derfor liten tvil om at det er oppdragsgiver som særlig har interesse av klare avtaler. Sijthoff Stray uttrykker det treffende: «En part som påberoper seg lovens regel kan vanskelig møtes med at han burde ha uttalt seg tydeligere.»(132)

Oslo byrett anvendte spesialitetsregelen på følgende måte i en sak om oppdragstagers opphavsrett:(133)

«Oppdraget er ikke regulert i annet enn en muntlig avtale med omtvistet innhold og retten kan derfor ikke se at opphavsretten er overdratt til Alcatel STK idet en slik overdragelse krever uttrykkelig avtale.»

Jeg synes at Oslo byrett stilte for strenge krav til avtalen. Det er ikke noe krav om at slike avtaler skal være skriftlige, og omstendighetene rundt avtalen kunne nok tilsi at partene hadde forutsatt en videre disposisjonsrett. Men som det er sagt flere ganger i denne fremstillingen: Dette illustrerer en usikkerhet som bør avklares gjennom avtaleregulering.

Det kan ikke stilles opp noen hovedregel om hvem som har rettighetene utover det utgangspunktet som er nevnt ovenfor. Det kommer an på situasjonen. Det er ikke vanskelig å finne eksempler hvor det må være åpenbart at oppdragsgiver bør ha rettighetene, men det er like lett å finne eksempler hvor et slikt resultat vil fremstå som like rimelig. Den som har betalt for utviklingen av et program, vil som regel ikke bli særlig begeistret om han oppdager at utvikleren senere selger tilsvarende program til den opprinnelige oppdragsgivers konkurrenter. På den annen side vil den som har utviklet programmet med god grunn kunne føle seg snytt om oppdragsgiver tjener gode penger på å selge programmet ?? oppdragsgiver har bare bidratt med penger, mens oppdragstager har bidratt med den kunnskap og den kreative innsats som tross alt representerer verdien i programmet. Utvikleren vil dessuten kunne se at hans eget marked for tilsvarende utviklingsoppdrag blir undergravet fordi en tidligere oppdragsgiver selger et program som i sin tid ble utviklet for denne.

Hvis en programutvikler påtar seg å utvikle en modul til et større program som utvikles og markedsføres av et annet programvarehus, må det være ganske klart at oppdragsgiver får rettighetene. Er det derimot et program som utvikles i samarbeid med en «pilotkunde», hvor kunden ikke betaler de fulle utviklingskostnader nettopp fordi leverandøren håper på å kunne selge systemet til andre, er det like klart at oppdragstager må sitte med alle rettighetene. Men mellom disse ytterpunkter finner man en rekke situasjoner som ikke har noen klar løsning.

Utenfor de tilfellene hvor løsningen så å si ligger i oppdragets natur, vil det som regel ikke være noen god løsning å avtale generelt at den ene eller den annen av partene skal ha rettighetene. Hvis man bare avtaler at den ene av partene skal ha opphavsretten til det som utvikles, kan man likevel få konflikter om omfanget av disposisjonsrett, om eksklusivitet, salg til andre, osv. Man bør derfor konkretisere de mest aktuelle opphavsrettslige beføyelsene.

Hvis oppdragsgiver har betalt alle kostnadene ved utviklingen bør han få rett til å utnytte programmet fritt i egen organisasjon, uansett hvem som etter avtalen skal ha opphavsretten. Jeg mener at dette må være en normalforutsetning i et slikt utviklingsoppdrag. Men Alcatel STK hadde betalt alle utviklingskostnadene i den saken hvor Oslo byrett kom til at de ikke kunne utnytte annet enn ett eksemplar av programmet i den bestemte avdelingen. Så det er i alle fall klart at rettstilstanden her ikke er klar. Hvis man gir rett til fri benyttelse i oppdragsgivers organisasjon, må man avgrense organisasjonen, se ovenfor i avsnitt 18.4.4. I SSA U97(utk) pkt. 13.2.2 gis kunden en slik rett, og i pkt. 13.2.3 gis kunden den nødvendige rett til eksemplarfremstilling.

Oppdragsgiver bør videre ha rett til å foreta alle de endringer han måtte ønske, noe som også forutsetter at han får tilgang til kildekoden. I SSA U97(utk) pkt. 13.2.4 heter det at kunden kan gjøre endringer dersom han har avtalemessig adgang til kildekoden. Til tross for at dette er en kunde-utarbeidet avtale, stiller den her kunden dårligere enn kunden etter min mening bør akseptere.

Hvis avtalen sier at kunden har opphavsretten, er kundens utnyttelse og rett til å foreta endringer uproblematisk, og man trenger ikke å regulere dette. KDL U97 er basert på at kunden får opphavsretten, og reguleringen på dette punkt blir dermed enklere. Da må det også være klart at kunden skal ha programmets kildekode. Samtidig viser KDL U97 pkt. 5.1.2 at man ikke har løst alle spørsmål om hvor langt kundens disposisjonsrett rekker ved å si at kunden har opphavsrett.

Konflikt vil som regel først oppstå dersom det åpner seg et marked for programmet, og en av partene ønsker å overdra disposisjonsrett til andre. Hvis det ikke er noe aktuelt marked og partene i utgangspunktet ikke er enige om hvem som skal ha en slik rett dersom det åpner seg et marked, er min anbefaling at man legger spørsmålet dødt. Det gjør man ved å ta inn i avtalen at ingen av partene har rett til å selge programmet uten den annen parts samtykke. Da slipper man å bruke tid å penger på å forhandle om hypotetiske problemstillinger når avtalen skal inngås. Dersom ingen av partene har særlige grunner til å motsette seg at også andre kan benytte programmet, vil man som regel klare å bli enige. Man vil være i forhandlinger om hvordan en fortjeneste skal deles mellom partene, og det er en fortjeneste som uteblir dersom partene ikke blir enige.

Jeg har hørt enkelte hevde at også kunden som hovedregel vil være best tjent med at leverandøren får rettighetene til programmet. Begrunnelsen for dette er at det da er bedre muligheter for at programmet blir videreutviklet, noe kunden også vil være tjent med. Hvis kunden har sikret seg nødvendig disposisjonsrett og det ikke er et strategisk program for kunden, kan dette være en hensiktsmessig løsning. Men det blir et forhandlingsspørsmål, og det kan også være grunn til å ta hensyn til dette når prisen skal fastsettes. Litt overraskende sier SSA U97(utk) pkt. 13.1 at leverandøren får opphavsretten, mens KDL U97 pkt. 5.1.1 sier at kunden har opphavsretten med mindre annet er særlig angitt. Når den ene er en kontrakt utarbeidet av en kunde, og den andre er utarbeidet av en leverandørorganisasjon, ville jeg ha ventet den motsatte løsning i begge kontraktene.

Noen bøker om IT-kontrakter


More >>
Outsourcing: The Legal Contract
Providing an introduction to outsourcing, this title identifies and discusses the main aspects which should be specified in the contract and indicates the factors which facilitate a successful outsourcing relationship.
RefNr: 1841523607
Bestill fra:
Amazon UK
Amazon US
Bokkilden

More >>
Kontrakter for utvikling av programvare
Boka tar for seg utviklingskontrakter for dataprogramvare.
RefNr: 9788202196912
Bestill fra:
Bokkilden

More >>
The Outsourcing Revolution: Why it Makes Sense to do it Right: Why It
The Outsourcing Revolution" features case studies detailing how specific companies planned, implemented, and are managing BPO. Results from surveys of more than 1,500 companies provide real data on what organizations around the world are doing and why, as well as what does and doesn't work.
RefNr: 0793192145
Bestill fra:
Amazon UK
Amazon US
Bokkilden

More >>
The Managers Guide to Understanding Commonly Used Contract Terms: Comm
RefNr: 0852977581
Bestill fra:
Amazon UK
Amazon US
Bokkilden

Gå hit for full oversikt over bøker om IT-kontrakter.


Previous page: Previous page: Rettigheter til dokumentasjonNext page: "Reverse engineering" Next page:

Next page: "Reverse engineering" Next page:

Previous page: Previous page: Rettigheter til dokumentasjon