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
Nettside hos snl.no
Nettside hos snl.no