Alt styres af software. Det er en stor del af værdien af ethvert produkt.
Softwaren udgør en væsentlig brik i robottens funktionalitet, præcision, stabilitet og brugbarhed for slutbrugeren. Softwaren har typisk afgørende betydning for, om et produkt bliver en succes eller en fiasko; om produktet bliver solgt eller konkurrentens tilsvarende foretrækkes. Der bliver derfor også typisk lagt en betydelig arbejdsindsats og investering i at udvikle softwaren. Ikke overraskende udgør softwaren derfor også typisk en stor del af en virksomheds værdi.

Software er dog desværre ofte et overset emne i forhold til robotter og hardware generelt - i hvert fald juridisk. Der er typisk fokus på teknik - ikke jura. Det kan give nogle ubehagelige overraskelser.

Om software og ophavsret

Software er juridisk beskyttet af ophavsretten på samme måde som en bog eller et stykke musik. Den juridiske beskyttelse stammer således fra kunstens verden mere end teknikkens verden. Det betyder, at der er en betydelig beskyttelse af »kunstneren« (ophavsmanden).

I forhold til software kan det oversættes til udvikleren; den, der har udviklet software, beskyttes overfor den, der køber softwaren, i enhver henseende. Ved tvivl vinder udvikleren derfor typisk over kunden.

Beskyttelsen medfører, at det er kompliceret at overdrage rettigheder til software. Der er forskel på at købe en kopi af softwaren og selve retten bag. Det svarer lidt til, at den, der køber en bog, ikke automatisk får retten til manuskriptet. Der er dog også forskel på at købe alle rettighederne til software eller blot en begrænset del af disse.

Ved overdragelse af rettigheder kræves en høj grad af nøjagtighed. Der overdrages kun det, der aftales. Ved tvivl beholder udvikleren således de uomtalte rettigheder. Eksempelvis giver en ret til at bruge software ikke automatisk også ret til at ændre eller videreudvikle softwaren. Det giver heller ikke nødvendigvis ret til at ændre brugen, for eksempel sammen med anden hardware end oprindeligt tiltænk. Ligeledes giver det heller ikke nødvendigvis ret til at lade andre end lige netop køberen bruge softwaren. I det hele taget tilgodeses udvikleren i enhver henseende, hvor aftalen ikke er eksplicit og præcis.

Hvem har egentlig rettighederne?

Hvis hardwareproducenten selv, med egne medarbejdere, udvikler alt softwaren helt fra bunden, er problemet begrænset. Her bliver hardwareproducenten ene-udvikler. Dermed er beskyttelsen ene og alene
rettet mod hardwareproducenten selv, som herefter frit og alene kan råde over softwaren. Det er dog meget sjældent situationen.

Udvikling af software er i dag en kompliceret og tidskrævende proces. Der anvendes derfor typisk underleverandører. Det kan være i form af outsourcing af udviklingen af dele til eksterne udviklere. Det kan også være brug af konsulenter eller freelancere til at supplere medarbejderne.

I alle situationer er det sjældent, at softwaren udvikles helt fra bunden. Der genbruges typisk softwarekomponenter fra tidligere udviklinger. Ligeledes anvendes open-source komponenter og eventuelt kommercielle komponenter også. Der er med andre ord typisk flere udviklere involveret. Dermed er rettighederne til softwaren også i udgangspunktet fordelt på flere forskellige parter.

Normalen er således, at hardwareproducenten ikke frit og alene selv kan råde over softwaren og rettighederne hertil. Det skal afpasses med hver af udviklerne, der har bidraget hertil. Hvis hardwareproducenten skal kunne give sin slutkunde lov til at bruge hardwaren og den indbyggede software, bliver det derfor afgørende, at der er styr på rettighederne i forhold til hver af disse involverede parter.

Typeproblem - ingen rettigheder

Et typisk problem er, at der ingen aftale er mellem udvikleren og hardwareproducenten. Hvis der er en aftale, er det ikke usædvanligt, at den er for upræcis. Der kan for eksempel blot stå, at kunden får retten til softwaren. Hvilken ret? Retten til at bruge? Retten til at videreudvikle? Retten til selv at bruge eller retten til at lade andre bruge?

Det kan også være, at aftalen - utilsigtet - er for præcis. Der kan eksempelvis stå, at rettighederne forbliver hos udvikleren, men at kunden får en brugsret. Det kunne også være, at der gives en ret i forhold til et konkret hardwareprojekt. Må hardwareleverandøren så videreudvikle softwaren eller genbruge den (helt eller delvist) i et andet hardwareprojekt? Næppe! Der vil som minimum være en uklarhed, som udvikleren vil kunne udnytte.

Typeproblem - open source

Et andet typisk problem er, at der ikke er styr på rettighederne til hver af de komponenter, som softwaren udgøres af - herunder open sourcekomponenter. 

Open source er software som enhver anden software. Dermed gælder ophavsretten også for open sourcekomponenter. De er typisk underlagt forskellige foruddefinerede licenser, for eksempel MIT, Apache, GPL osv.

Licenserne kan have meget forskellige vilkår og behøver ikke være problematiske. MIT-licensen tillader for eksempel eksplicit enhver brug og videreudvikling. De kan dog også være problematiske. Eksempelvis ved at forbyde kommerciel brug uden betaling. Eller ved at kræve, at kildekoden til hele softwaren bliver frigivet offentligt - såkaldte »copy-left« vilkår. Også selv om det kun er en enkelt komponent, der er underlagt en problematisk licens.

Er det overhovedet et reelt problem?

Ja! Det viser sig dog normalt først, når det er for sent. Og meget dyrt. Det kan for eksempel være i forbindelse med et leverandørskifte. Hvis aftalen ikke er præcis, kan en utilfreds udskiftet udvikler lukrere på usikkerheden. Det kunne være ved at kræve ekstrabetaling for at lade en ny udvikler arbejde videre med softwaren. Eller for at tillade genbrug i anden hardware, på andre markeder osv.

Medmindre der er en klar aftale om rettighederne, har udvikleren i udgangspunktet alle kortene på hånden. Konsekvensen kan være, at udvikleren med rettens hjælp kan stoppe brugen af softwaren - og dermed hele produktet - hos såvel hardwareleverandøren selv som hos alle dennes slutkunder. Alene forsøget vil typisk have en negativ kommerciel effekt.

Det kan også være, at ukontrolleret brug af open source-komponenter gør, at hardwareleverandøren bliver nødt til at frigive kildekoden til alle. Uanset den betydelige investering heri. Og uanset dens karakter af forretningshemmeligheder. Et eksempel var den meget populære wi-fi-router i WRT-serien fra Linksys. Den dyre og den billige netværksrouter var samme hardware, men softwaren var forskellig. Problemet var, at der var anvendt open source-software, som krævede, at kildekoden til hele softwaren blev frigivet. Dermed kunne man blot købe den billigste router og selv opgradere den til den dyreste funktionalitet.

Hvis ikke det viser sig før, viser problemet sig normalt ved et virksomhedssalg eller ved større investeringer. Her foretager køber/investor typisk en juridisk due diligence. Hvis softwaren er væsentlig - hvilket den er i robotvirksomheder - vil den blive undersøgt nærmere. Her kommer det frem, om der er styr på rettighederne - og hvordan virksomhedens fokus på rettigheder har været gennem tiden.

Konsekvenserne kan være en lavere værdiansættelse, krav om indgåelse af de rigtige aftaler før handlen gennemføres, krav om udskiftning af komponenter - eller måske at handlen opgives som for
risikabel.

Hvordan sikres robottens hjerte?

Typisk kan problemet håndteres simpelt fra start:

• Sørg for en fornuftig softwarelicensaftale med slutkunden.
• Vær omhyggelig med rettighedsbestemmelserne i alle aftaler om software og udvikling - også i forhold til medarbejdere, konsulenter og freelancere.
• Sørg for regulering af tredjepartskomponenter i aftalen med udvikleren.
• Implementer screening af kritisk software. Der findes værktøjer, som kan hjælpe.
• Tænk software og rettigheder ind i forberedelserne til et salg/investering.
• I det hele taget er fokus på rettighederne til softwaren en god start.

Kontakt DAHL

Vi du vide mere, eller har du spørgsmål, er du velkommen til at kontakte vores advokat og partner Tim Krarup Nielsen, der har indgående viden og erfaring med IT-ret.