Hopp til innhald
Fagartikkel

Programvarelisensar

Programvare er åndsverk og verna av opphavsrett. Som skapar av programvara bestemmer du kva vilkår, altså kva lisens, som skal gjelde for korleis andre bruker koden eller programvara di.

Lisensiering av programvare

Åndsverklova gir einerett til programvare vi utviklar. Når vi ønskjer å gjere programvara tilgjengeleg for andre (uavhengig om vi tek betalt for ho eller ikkje), må vi definere kva lisensvilkår (reglar for bruk) vi ønskjer skal gjelde for åndsverket vårt.

Åndsverklova definerer grunnreglane som gjeld for alle åndsverk. Dette fundamentet kan vi så tilpasse ved hjelp av lisensar og sluttbrukarlisens (EULA).

Lisensar kan vere meir opne eller meir lukka. Nokre lisensar gir berre ein avgrensa tilgang til å bruke programvara. Slike restriktive lisensar blir ofte brukte på proprietær programvare, der målet er å tene pengar på programvara for å få eit forsprang på konkurrentar ved å halde kjeldekoden hemmeleg. Andre lisensar kan vere meir opne og tillate at andre gjer forandringar, lagar kopiar, lagar sine eigne variantar og bruker koden i sine eigne prosjekt. Det er òg mogleg å gi bort alle rettane sine slik at koden i praksis blir allemannseige og fritt kan brukast av kven som helst og til kva som helst.

Ofte bruker vi ande sin kode i prosjekta våre. Då er det viktig å kunne vilkåra som gjeld for gjenbruk av koden. Kanskje er det ikkje lov å bruke det igjen i det heile, eller kanskje er det avgrensingar som påverkar kva lisensiering du kan bruke på prosjektet ditt viss det inneheld kode frå andre. Det er òg god skikk, og som oftast eit krav, om å vidareformidle den originale lisensinformasjonen og kjelda.

Aspekt ved lisensieringa

Når vi skal bestemme lisenstype, er det nokre sentrale spørsmål vi må svare på.

Kommersialisering?

Skal du tene pengar på programvara? Viss ja, skal du tene pengar direkte ved sal av programvara gjennom brukarstøttetenester eller gjere utviklinga basert på donasjonar?

Mange utviklar programvare utan mål om å tene pengar på dette. Dette er sjølvsagt heilt legitimt og noko vi alle nyt godt av kvar dag, men viss programmering skal vere meir enn ein hobby, er det behov for å finne ut korleis ein kan tene pengar på arbeidet.

Vanlege måtar å tene pengar på programvare på

1. Sal av brukarlisens til enkeltperson eller gruppelisens til bedrifter

Mot førehandsbetaling gir du ein varig rett til bruk av programvare, som oftast ein bestemd hovudversjon. Vegas 19 er eit døme på dette.

2. Abonnement av tilgang til programvare

Mot jamleg leige gir du mellombels rett til bruk av programvare, som oftast den nyaste versjonen. Eit døme på dette er Adobes produkt.

Det er òg mogleg å gjere hovuddelen av programmet gratis, men krevje abonnement for tilgang til avansert funksjonalitet.

3. Hybrid med både sal og abonnement

Innan spelverda har det vorte vanleg både at det kostar noko for spelet, og at utvidingar (DLC) eller nettkomponenten av spelet krev ei abonnementsløysing. Dei fleste MMO bruker ei slik løysing.

4. Abonnement på brukarstøtte

Du kan lage og gi bort bruksrett på programvare og så ta betalt for brukarstøtteabonnement. Dette er vanleg for mange opne kjeldekodeprosjekt som til dømes Red Hat Linux.

5. Utvikling basert på donasjonar

Du kan lage og gi bort bruksrett på programvare og spørje brukarar eller bedrifter om støtte gjennom donasjonar for vidare utvikling og drift. Firefox nettlesar er eit døme på eit slikt program.

6. Programvare finansiert av reklame

Reklame kan blandast med alle kommersialiseringsvariantane, men er mest vanleg i programvare som er gratis.

7. Sal av brukardata

Dessverre er det ein vanleg praksis hos mange å samle inn og selje brukardata ut til reklameaktørar. Dette kan òg kombinerast med dei fleste kommersialiseringsvariantane sjølv om kjøpte lisensar og abonnementslisensar ofte har mindre av slikt. Du kan lære meir om dette i podkasten Dine data er til salgs.

Tilgjengeliggjering av kjeldekoden?

Kjeldekoden til dataprogrammet er som oftast kompilert til maskinkode før han blir gjord tilgjengeleg for brukarane. Maskinkoden til eit program er vanskeleg å analysere og reversere til format som menneske kan lese og arbeide med.

Vi må derfor tenkje gjennom følgjande: Ønskjer vi at andre skal få innsikt i programvara ved å gjere kjeldekode tilgjengeleg, eller ønskjer vi å halde ho hemmeleg? På bakgrunn av dette kan vi avgjere om vi ønskjer å gjere kjeldekoden til koden eller programmet tilgjengeleg for andre eller ikkje.

Halde kjeldekode hemmeleg

Mange produsentar av programvare vel å halde kjeldekoden hemmeleg. Dei sel eller gjer tilgjengeleg berre maskinkode som er vanskeleg å reversere.

Hemmeleghald av kjelde gir eit lag av sikkerheit mot piratkopiering, analyse og tjuveri av kode og at sikkerheitssvakheiter i koden blir funnen av utanforståande trusselaktørar.

Hemmeleghald gir noko sikkerheit, men fører òg med seg risiko. Sjølv om det er vanskeleg, kan maskinkode reverserast, og trusselaktørar har mange måtar dei kan finne svakheiter på. Viss få har lese og analysert kjeldekoden, er det òg få som har hatt moglegheit til å oppdage eventuelle svakheiter og få dei forbetra.

Mange produsentar leiger inn ekstern ekspertise innan hacking og kodeanalyse for å gå gjennom kjeldekode i søk etter svakheiter.

Gjere kjeldekode tilgjengeleg

Mange produsentar vel å gjere kjeldekoden til programma sine tilgjengelege. Då kan kjøparen av programvare gjere forandringar som er nødvendige for å få programvara til å fungere betre med anna programvare som er i bruk. (Slike forandringar er ofte tillatne under åndsverklova.) Openheit gjer det òg lettare for brukarane å vurdere sikkerheita til programvara og finne og varsle om svakheiter i koden.

Når kjeldekoden er tilgjengeleg, har òg trusselaktørane tilgang. Dette vil seie at dei mykje lettare kan finne svakheiter dei kan utnytte. Piratkopiering og produksjon av programvare-patchar som fjernar kopisperre, blir enklare.

At kjeldekoden er tilgjengeleg, betyr ikkje at andre har lov til å kopiere og bruke delar eller heile koden til andre prosjekt, men det kan vere veldig vanskeleg å bevise at tjuveri av kode har skjedd.

Skal lisens og kjeldekode vere open eller lukka?

Når vi snakkar om open eller lukka lisens og kjeldekode, snakkar vi om typen lisens som skal gjelde for koden eller programmet, ikkje om kjeldekoden i seg sjølv er tilgjengeleg for allmenta eller ikkje.

Utgangspunktet for lisens er åndsverklova, og denne gir einerett til opphavaren. Dette kallar vi lukka eller proprietær lisens eller kjeldekode. Det er sterkt avgrensa kva andre kan gjere med koden.

Innan dataverda er det ein sterk kultur for å gi åndsverk ein meir open lisens. Kor open lisensen blir gjord, varierer frå lisenstype til lisenstype. I artikkelen Opne lisensar for programmering (ndla.no) kan du lese meir om dei vanlegaste lisenstypane innan IT.

I tabellen under kan du sjå ytterkantane mellom heilt lukka og heilt open lisens og kjeldekode.

Rett

Lukka lisens og kjeldekode

Open lisens og kjeldekode

Rett til å bruke programvara

Ja, viss ho er kjøpt eller lovleg skaffa.

Ja

Rett til å lage private kopiar

Kopiering er berre tillaten for eigen sikkerheitskopi og regulert av lovverket.

Ja

Rett til distribuere kopiar av programmet eller kode

Nei

Ja

Rett til å forandre koden til programmet

Tilpassing av kode er berre tillaten for eige nødvendig bruk og regulert av lovverket.

Ja

Rett til å distribuere kopiar av forandra programvare

Nei

Ja

Løyve til å bruke kode i eigne prosjekt

Nei

Ja

Rett til å forandre lisensvilkår

Nei

Varierer mellom dei opne lisensane

Krav om anerkjenning av opphavet til programvara eller koden

Ja

Som oftast ja


Relatert innhald