1.Innledning
Vi har i den senere tid sett en kraftig vekst i utbredelsen av datamaskinprogrammer som gjøres tilgjengelig som såkalt åpen- eller fri programvare. Selv om det er visse nyanser i begrepsbruken her vil vi bruke betegnelsen "åpen programvare" i denne artikkelen.
Åpen programvare representerer på mange måter en annerledes tenking omkring utvikling, vedlikehold og lisensiering av datamaskinprogrammer.
Slik programvare utvikles ofte i åpne og uorganiserte "prosjekter" , hvor datamaskinprogrammet og dets kildekode gjøres tilgjengelig på Internett under en lisens som gir brukerne en nokså fri adgang til å disponere over programvaren, dog med visse betydningsfulle begrensninger. Programvaren vil dermed kunne endres og videreutvikles gjennom bidrag fra en lang rekke bidragsytere, uten at disse nødvendigvis står i noe organisert forhold til hverandre.
Dette innebærer imidlertid ikke at åpen programvare er fullstendig fri slik at programvaren kan utnyttes helt uavhengig av opphavsmannens rettigheter. Åpen programvare er opphavsrettslig beskyttet på linje med andre datamaskinprogrammer, slik at opphavsmannen i utgangspunktet har en lovbestemt enerett til utnyttelsen av programvaren. Karakteristisk for åpen programvare er at man utnytter sin opphavsrett "motsatt" av hva man normalt ser: I stedet for å bruke opphavsretten som et direkte middel til å ivareta opphavsmannens enerett til enhver utnyttelse av datamaskinprogrammet, brukes den som et middel til å gi og opprettholde friheter for andre til bruk, endringer, videre distribusjon m.v.
Åpen programvare karakteriseres altså ikke først og fremst ved at den er gratis, men av at brukeren får en annen og utvidet grad av frihet mht bruk av programvaren.
Hensikten med denne artikkelen er å gi en introduksjon til begrepsbruken og se litt nærmere på innholdet i noen av de vanligste lisensbetingelsene som er knyttet til åpen programvare. Vi vil også komme nærmere inn på noen viktige begrensninger som brukeren er underlagt.
2. Hva er åpen programvare?
Åpen programvare spenner over alt fra komplekse operativsystemer til små brukerprogrammer. Et velkjent eksempel på åpen programvare er de ulike operativsystemer som distribueres under betegnelsen "Linux". Det hersker imidlertid en del begrepsforvirring og uenighet rundt hva som kjennetegner slik åpen programvare.
Free Software Foundation (FSF) og GNU-prosjektet, som har gitt opphav til betegnelsen "free software" utviklet på midten av 80-tallet sin definisjon av åpen programvare/fri programvare
I 1998 lanserte Open Source Initative (OSI) på sin side begrepet " Open Source" for å markere avstand fra begrepet "free software " . Med "Open Source" ønsket man fokus på åpenhet og utvidede brukerrettigheter, og ikke nødvendigvis på om brukeren måtte betale vederlag for sin disposisjonsrett til programvaren.
Vi vil her ikke søke å gi noen allmenngyldig definisjon av begrepet åpen programvare, men nøyer oss med en overordnet oversikt over noen av de sentrale kjennetegnene ved slik programvare.
Lisensvilkårene som benyttes ved distribusjon av åpen programvare vil naturligvis variere noe, men de kjennetegnes først og fremst ved at brukeren får frihet til å
- benytte programmet til ethvert formål og på så mange datamaskiner som ønskelig
- studere programmet og foreta endringer, feilrettinger, forbedringer og utvidelser av programmet slik at det passer brukerens behov
- redistribuere programmet med eller uten endringer til andre brukere som igjen kan tilpasse programmet til eget bruk.
For øvrig inneholder de også ofte en del bestemmelser som ivaretar opphavsmannens ideelle rettigheter (rett til å bli navngitt m.v.), uten at dette blir nærmere behandlet her.
3.Åpen programvarelisenser - noen utvalgte problemstillinger
3.1Generelt - presentasjon av problemstillingene
En tradisjonell programvarelisens har som overordnet formål å sikre opphavsmannen lovbestemte rettigheter gjennom å begrense- og for øvrig stille vilkår til bruken av programvaren. Begrensningene kan typisk være at rettighetene til bruk er betinget av at det betales et bestemt vederlag, at den bare kan brukes på visse maskiner, av et visst antall brukere m.v.
De lisensvilkår som brukes i forhold til åpen programvare utnytter på mange måter opphavsretten til det motsatte, nemlig til å minimere- eller eliminere begrensninger på brukerens rett til utnyttelse av programvaren.
Grunnstammen i de aller fleste lisensvilkår som knyttes til åpen programvare er bestemmelser som ivaretar de friheter som er beskrevet ovenfor under punkt 2. De ulike lisensavtalene som benyttes fremstår derfor langt på vei som nokså likeartede.
Det er imidlertid nokså vesentlige forskjeller mellom de ulike lisensenes tilnærming til følgende spørsmålsstilling: Hvordan sikrer man at det som en gang var åpen programvare, forblir åpen?
Dette reguleres gjennom at brukeren pålegges visse plikter mht videre distribusjon av sine egne endringer, tillegg og modifikasjoner til programvaren. I tillegg inneholder vilkårene nokså ulikeartede regler for hvordan åpen programvare kan inkorporeres i- og distribueres sammen med utviklerens egne proprietære løsninger.
Dette vil i det følgende bli drøftet med utgangspunkt i tre sett av lisensvilkår som etter vårt syn er illustrerende for løsningen av disse problemstillingene :
- GNU General Public License
- BSD lisenser
- Mozilla Public License
3.2 GNU General Public License
Stamfaren til alle lisenser som knyttes til åpen programvare, GPL General Public License (GPL), har også stor utbredelse i praktisk bruk.
GPL går svært langt i å sikre at åpen programvare forblir åpen, gjennom å pålegge lisenstakeren vidtgående plikter til å benytte GPL-vilkårene ved videre distribusjon av sine egne forbedringer og tillegg som er basert på den åpne programvaren.
GPL lisensen tillater i utgangspunktet ikke at bearbeidelser av åpen programvare eller inkorporering av åpen programvare i ens egen programvare, lisensieres videre under proprietære lisenser. Dette følger direkte av GPL § 2:
"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the [original] Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this license)".
Dette betyr altså at GPL har en direkte "smitteeffekt" over på brukerens egenutviklede programvare, dersom denne inneholder hele eller deler av et program som brukeren har fått tilgang til under GPL-lisensen. Det fremgår av vilkårene at det tilsvarende gjelder dersom man utvikler programvare som må anses som avledet ("derived work") av den åpne programvaren.
Dersom en benytter GPL-lisensiert programvare som en integrert del av sin egen kode, er man altså forpliktet til også å distribuere sine egenutviklede elementer på de samme vilkår. Dette innebærer for eksempel at det er utelukket å ta seg betalt for selve tilgangen til programvaren, dersom denne distribueres videre.
Det kan derfor ha store konsekvenser for utvikleren å inkorporere - eller utvikle avledede verk av programvare som er underlagt vilkårene i GPL. Det er derfor sentralt å se nærmere på rekkevidden av disse bestemmelsene.
Det er etter vårt syn på det rene at man fritt kan benytte ideer og prinsipper som ligger til grunn for åpen programvare i sine egne proprietære løsninger. Dette er en del av opphavsrettens vesen, hvor det i utgangspunktet er selve koden - og ikke de bakenforliggende prinsipper - som er vernet for opphavsmannen.
Dersom man kopierer inn deler av selve koden - eventuelt etter å ha foretatt endringer i denne - direkte i sin egenutviklede løsning er vilkårene tilsvarende klare: Man er da forpliktet til å benytte GPL ved eventuelle videre distribusjon av den samlede løsningen.
I mellom disse to ytterlighetene oppstår det imidlertid en del tvilsomme grensespørsmål, og disse refererer seg kanskje først og fremst til de tilfeller hvor det etableres linker mellom ens egenutviklede programvare, og programvarekomponenter/biblioteker som er underlagt GPL. Det oppstår da spørsmål om slike forbindelser innebærer det oppstår et avledet verk i lisensvilkårenes forstand.
Det ser ut til at man her må trekke et grunnleggende skille mellom s.k statisk- og dynamisk linking. Selve sondringen fremkommer ikke direkte av lisensvilkårene, men har utviklet seg i tolkingspraksis rundt bestemmelsene i GPL.
Den rådende oppfatning ser ut til å være at statisk linking til et program/programbibliotek som er underlagt GPL, innebærer at man har å gjøre med en bearbeidelse/avledet verk i vilkårenes forstand. Statisk linking innebærer at man kopierer programmet/bibliotekets objektkode/maskininstruksjoner inn i sitt eget program. Programmet/biblioteket blir med dette en del av det linkede programmet, og det blir på samme måte som resten av programmet lastet inn i RAM når programmet blir kjørt.
Lang mer tvil knytter det seg til bruk av dynamisk linking mellom et proprietært program og et program/programbibliotek underlagt vilkårene i GPL. Da kopierer man ikke programmets/bibliotekets maskininstruksjoner inn i den eksekverbare filen til sitt eget program. Den eksekverbare filen inneholder her kun kode for å hente inn programmet/biblioteksrutinene under kjøretid.
Åpen programvaremiljøet er delt i spørsmålet om dynamisk linking kan sies å innebære at det oppstår et avledet verk i vilkårenes forstand.
FSF, som har forfattet vilkårene for GPL-lisensen hevder at slik linking er en bearbeidelse/avledet verk av programvaren, mens andre har tatt sterkt til orde for den motsatte fortolkingen av GPL-vilkårene. Noen endelig avklaring foreligger så langt ikke, til tross for den store praktiske betydningen av denne problemstillingen. Det må derfor påregnes at det vil foreligge en avklaring i den neste revisjonen av GPL.
Etter vår oppfatning er det vanskelig å finne holdepunkter for at slik dynamisk linking kan omfattes av begrepet "derived work", og det er tilsvarende vanskelig å se at man dermed vil komme i konflikt med lisensvilkårene ved å etablere en slik link fra et proprietært program. Løsningen er imidlertid på ingen måte opplagt.
Vi vil samtidig få påpeke at det i art. 3 i GPL-lisensen følger at linking med programbiblioteker som er en del av operativsystemet, anses som normal bruk av operativsystemet. Dette innebærer at bruk av operativsystemets biblioteker ikke er å anse som bearbeidelser/avledete verk av operativsystemet, selv om dette måtte være distribuert under GPL.
Etter vår oppfatning innebærer heller ikke kommunikasjonsmekanismer mellom to separate programmer, slik som piper, sockets og command-line arguments, at programmene som kommuniserer kan sies å være en bearbeidelser/avledete verk av hverandre.
3.3 BSD lisenser
Vi bruker her betegnelsen "BSD lisenser" for en kategori av lisenser som har sitt utspring i en lisens som ble benyttet til distribusjon av Universitetet i Berkeley's endrete versjon av operativsystemet UNIX. Distribusjonen ble kalt "The Berkeley Software Distribution" (BSD). Denne lisensen har senere tjent som forbilde for en rekke andre lisenser, slik som MIT X, Xfree86 mv.
For de fleste utviklere av åpen programvare er BSD lisensene det mest populære alternativet til GPL, særlig blant mer kommersielle utviklere.
BSD lisensene tillater nemlig lisenstageren å viderelisensiere bearbeidelser av åpen programvare eller inkorporering av åpen programvare, under egne proprietære lisenser. I det store og hele inneholder BSD baserte lisenser få begrensninger i lisenstagerens disposisjonsrett til programvaren, så lenge lisenstageren overholder bestemmelsene om at programvaren skal inneholde opphavsrettsnotiser m.v.
Det er imidlertid verdt å merke seg at eldre versjoner av BSD-lisensene ofte inneholder nokså "tungvinte" bestemmelser om navngivelse av opphavsmannen. Dersom man anvender åpen programvare som er distribuert under eldre versjoner av BSD baserte lisenser bør man derfor være ekstra påpasselig at bestemmelsene overholdes. I nyere versjoner er disse kravene lempet.
3.4Mozilla Public License (MPL)
I forbindelse med Netscapes beslutning om å distribuere sin nettleser (Mozilla) som åpen programvare, utarbeidet Netscape lisensen Mozilla Public License (MPL). MPL kan sees på som et forsøk på å kombinere det beste av GPL lisensen med det beste av BSD lisensene.
Det følger av MPL at lisenstageren kan distribuere det lisensierte programmet eller bearbeidelser av det, i objektkode versjon under en proprietær lisens, så lenge kildekoden, og endringer til denne er gjort tilgjengelig i medhold av MPL.
MPL tar imidlertid sikte i at bearbeidelser av kildekoden forblir fri og ikke kan lisensieres under en proprietær lisens.
4.Avslutning
Åpen programvare gir altså brukerne langt flere rettigheter enn hva man vanligvis møter i lisensavtaler for mer tradisjonelle programmer. Lisensvilkårene for slike programmer inneholder imidlertid ofte betydningsfulle nyanser i vilkårene som må vurderes før man velger å ta åpen programvare i bruk.
De som ønsker å distribuere sitt/sine program som åpen programvare, må naturligvis også undersøke hvilken hvilke type lisens som passer ham/henne best. Sentralt her vil være i hvilken grad man ønsker å gi brukerne frihet til å kunne lage en proprietær versjon av programmet.
De som tar i bruk programvare som ledd i sin programutvikling eller virksomhet, bør etablere rutiner for dette, slik at man forsikrer seg om at alle er inneforstått med hvilke vilkår som gjelder for slik bruk. I motsatt fall kan man lett komme i skade for å opptre i strid med vilkårene, med de negative konsekvenser dette kan få i form av søksmål m.v.
