7. GPL, BSD või suletud? Kuidas valida oma tarkvaraprojektile litsents
GPL, BSD või suletud? Kuidas valida oma tarkvaraprojektile litsents
Kui oled loonud uue tarkvaraprojekti, tuleb sul varem või hiljem otsustada, millise litsentsiga seda levitada. Tarkvaralitsents määrab, mida teised tohib või ei tohi sinu koodiga teha, see on arendaja jaoks oluline otsus, mis mõjutab projekti tulevikku. Selles postituses vaatleme kolme peamist litsentsitüüpi arendaja vaatepunktist: ärivaraline litsents (suletud lähtekoodiga, tavaliselt EULA vormis), GNU GPL (tugev copyleft) ning BSD litsents (nõrk või puuduv copyleft, st permissiivne litsents). Arutleme iga litsentsi eeliste ja puuduste üle ning toome näiteid, millistes olukordades võiks üks või teine valik olla sobivaim.
Ärivaraline litsents (EULA, suletud lähtekood)
Ärivaraline ehk suletud lähtekoodiga litsents tähendab, et tarkvara autor (või ettevõte) säilitab endale kõik intellektuaalomandi õigused (näiteks autoriõiguse lähtekoodile) ning annab kasutajale vaid piiratud õiguse tarkvara kasutada. Kasutaja nõustub tavaliselt lõppkasutaja litsentsilepingu (EULA) tingimustega, mis keelavad tarkvara edasi levitamise või muutmise. Koodi enda avalikustamist ei toimu kasutajad saavad ainult kompileeritud programmi ning ei pääse lähtekoodile ligi Eelised: Ärivaralise litsentsiga projekti autorina on sul täielik kontroll oma tarkvara üle. Sa võid tarkvara kommertsialiseerida, näiteks müüa litsentse või tellimuspõhist kasutusõigust, lma, et peaksid oma koodi avaldama. Kuna arendaja (või firma) on ainus, kes tohib koodi muuta, on võimalik hoida tarkvara visiooni ühtsena ning tagada kasutajatele kindel kvaliteeditase ja tugi. Sageli on ärirakendused kasutajatele väga mugavad ja põhjalikult testitud lahendused. Samuti tähendab suletud lähtekood, et konkurendid või avalikkus ei näe su tarkvara unikaalset tehnilist lahendust, see võib aidata säilitada konkurentsieelist või kaitsta tarkvara kui ärisaladust.
Puudused: Suletud litsents piirab kogukonna kaasatust. Välised arendajad ei saa koodi üle vaadata, seda parandada ega täiustada, mistõttu jääd ilma vabatahtlike panusest. See võib tähendada, et innovatsioon on aeglasem, sest kogu arenduskoormus lasub ainult sul või su tiimil. Samuti võib suletud lähtekoodiga projektil olla raskem võita kasutajate usaldust, paljud eelistavad avatud lähtekoodiga tarkvara läbipaistvuse ja kohandatavuse tõttu. Ärilitsentsiga tarkvara levitamine tähendab tavaliselt, et kasutajatele kaasnevad kõrged kulud (litsentsitasud, tellimused), mis võib piirata kasutajaskonda. Lõppkokkuvõttes pead arendajana arvestama, et suletud mudel nõuab sinult endalt rohkem ressursse: sa vastutad ainuisikuliselt vigade parandamise, uuenduste ja toe pakkumise eest, kuna laiem arendajate kogukond ei saa kaasa aidata.
Millal valida suletud litsents? Kui sinu prioriteediks on tulu teenimine tarkvara müügist või sa soovid hoida lähtekoodi saladuses (näiteks sisaldab see ärikriitilist know-how’d), võib ärivaraline litsents olla loomulik valik. Suletud litsents sobib hästi ka siis, kui pakud tarkvara koos täieliku tugiteenuse ja garantiidega, näiteks ettevõtetele suunatud lahendused, kus kliendid ootavad ametlikku tuge ja kindlat vastutajat. Pea aga meeles, et suletud litsentsiga valid teadlikult ära jagada tarkvaravabaduse eelised: see on trade-off kontrolli ja koostöökogukonna vahel.
GNU GPL (tugev copyleft, avatud lähtekood)
GNU General Public License (GPL) on kõige levinum tugeva copyleft-efektiga avatud lähtekoodilitsents. GPL lubab kõigil tarkvara vabalt kasutada, muuta ja levitada, kuid nõuab, et kui keegi sinu GPL-litsentsiga koodi baasil midagi edasi arendab või seda oma programmis kasutab ning levitab, peab ka see edasiarendus jagama lähtekoodi sama GPL litsentsi all. Teisisõnu, GPL tagab, et tarkvara ja selle tuletatud tööd jäävad alati vabalt kättesaadavaks “vabadus levib edasi” kogu ökosüsteemis.
Eelised: GPL on arendajale hea valik, kui sa tahad garanteerida, et sinu töö püsib vabana ja kõigile kättesaadavana ka tulevikus. Tugev copyleft tähendab, et ükski kolmas osapool ei saa võtta sinu koodi ja teha sellest suletud konkureerivat toodet ilma lähtekoodi tagasi andmata. See aitab vältida olukorda, kus peaksid omaenda koodiga hiljem “võistlema”. Paljud arendajad hindavad GPL-i ideoloogilist põhimõte, see edendab vaba tarkvara liikumist, sundides ka teisi panustama tagasi kogukonda. Kui keegi teeb su projektis paranduse või uue funktsionaalsuse ja soovib seda levitada, on ta kohustatud selle ka avaldama; nii saavad kõik kasutajad ja ka sina ise nendest täiustustest osa. Nagu öeldakse, GPL “tagab kasutajate vabaduse” ja hoiab tarkvara avatuna. See võib kasvatada aktiivset kogukonda su projekti ümber – arendajad, kes hindavad vaba tarkvara, eelistavad tihti just GPL-projekte ning panustavad neisse meelsasti.
Puudused: GPL-i tugevad nõuded võivad samas piirata projekti levikut teatud ringkondades. Näiteks kommertsettevõtted on tihti GPL-koodiga ettevaatlikud, sest nad ei taha riskida olukorraga, kus nende enda toote kood tuleks avalikustada. Pole haruldane, et mõnel ettevõttel on lausa poliitika “GPL-i mitte kasutada” just juriidiliste riskide tõttu. See tähendab, et kui litsentseerid oma teegi või raamistikku GPL-iga, võivad mitmed potentsiaalsed kasutajad (nt suletud tarkvara arendajad) sellest eemale hoiduda, vähendades su projekti laiemat adopteerimist. GPL võib tekitada ka litsentsiühilduvuse probleeme GPL-koodiga ei tohi lihtsalt suvalist mittesobiva litsentsiga koodi kombineerida. Näiteks kui sinu GPL-koodi integreeritakse mõnda teise projekti, muutub see projekt automaatselt GPL-i tingimustega seotuks. See vähendab paindlikkust: arendajad, kes tahaksid su koodi kasutada koos mõne teise litsentsiga lahendusega, võivad sattuda juriidilisele keerukale maale. Samuti on GPL juriidiliselt suhteliselt kompleksne litsents; kuigi see pole tavakasutajale tavaliselt probleem, peab arendajana arvestama, et reeglite järgimine (nt korrektne lähtekoodi kättesaadavaks tegemine binaari levitamisel) on kohustuslik. Kokkuvõttes võib GPL projekti sobida vähem, kui sinu eesmärk on maksimaalne levisõbralikkus või äriline koostöö suletud lähtekoodiga firmadega.
Millal valida GPL? GPL on parim valik juhul, kui sinu jaoks on oluline hoida tarkvara vabana ja avatud igal juhul. Näiteks kui oled veendunud vabavara pooldaja või su projekt on mõeldud kogukondlikuks arenduseks, kus kõik jagavad kõigiga. Kui tahad, et ka järgmised arendajad, kes su koodi kasutavad, panustaksid tagasi (ehk avaldaksid oma parandused), siis GPL täidab selle eesmärgi. GPL sobib hästi rakendustele, kus konkurents ei käi mitte niivõrd kasutajate arvu, vaid kogukonna kvaliteedi ja ühise arenduse üle – näiteks operatsioonisüsteemid (Linuxi kerneli litsents on GPLv2), suured raamistiktarkvarad jms. Samas, kui sul on plaanis ka äriline litsentsimine (nt pakkuda projekti dual-license mudelina, kus GPL-versioon on olemas, kuid ettevõtted võivad osta kommertslitsentsi), on GPL sageli osa sellisest strateegiast. Mõtle GPL-i peale siis, kui “avatud lähtekood on eesmärk omaette” ning sa oled valmis loobuma mõningastest kasutusvõimalustest selle nimel, et kaitsta tarkvara vabadust.
BSD litsents (nõrk/puuduv copyleft, permissiivne)
BSD litsents on näide permissiivsest litsentsist, mida kutsutakse ka nõrga või puuduva copyleft’iga litsentsiks. See tähendab, et BSD litsentsiga avaldatud tarkvara on samuti avatud lähtekoodiga, kuid ei sea peaaegu mingeid piiranguid sellele, kuidas keegi võib seda koodi tulevikus kasutada, muuta või levitada. Peamine nõue on tavaliselt see, et tarkvara edasijagamisel tuleb säilitada algse autori copyright-teavitus ja litsentsi tekst. BSD (nagu ka MIT litsents) ei kohusta tuletatud teoseid sama litsentsi all avaldama, järelikult tohib keegi võtta BSD-litsentsiga koodi ja kasutada seda ka suletud lähtekoodiga projektis. BSD litsentsi variatsioone on mitu (nt 2-tingimusega ja 3-tingimusega BSD), kuid kõigile on omane väga väheste piirangute filosoofia.
Eelised: BSD või mõne teise permissiivse litsentsi valikul annab arendaja sisuliselt teistele maksimaalse vabaduse tema koodi kasutada. See võib olla strateemiline eelis, kui soovid, et su tehnoloogia leviks võimalikult laialt. Kuna BSD litsents lubab ka ärilisel tarkvaral su koodi kasutada, ilma et peaks oma lähtekoodi avama, on see atraktiivne paljudele ettevõtetele ja projektidele, kes muidu avatud koodi vältida võiksid. See tähendab potentsiaalselt laiemat kasutajaskonda ja integratsioone, sinu kood võib jõuda nii vabavaraliste projektide kui ka kommertstoodete sisse. Paljude populaarsete avatud lähtekoodiga teekide edu on tulnud just tänu permissiivsele litsentsile, mis eemaldab kasutusbarjäärid. Ühtlasi on BSD litsents lihtne ja juriidiliselt “odav”, minimaalsed nõuded tähendavad, et harva on vaja kallist juriidilist analüüsi või keerukat litsentsihaldust, et seda koodi kasutada. Arendajana võib sulle oluline olla ka koostalitlusvõime: BSD-litsentsiga kood on ühilduv peaaegu kõige kõigega. Näiteks saab seda vabalt kombineerida MIT, Apache või ka suletud litsentsidega, ilma et tekiks litsentsikonflikte. Just seetõttu öeldakse, et BSD/MIT on hea valik, kui sa hindad laialdast kasutuselevõttu, need litsentsid on populaarsed arendajate seas, kes tahavad oma tarkvara levikut maksimeerida ilma copyleft’i piiranguteta. Puudused: BSD litsentsi suurimaks miinuseks arendaja seisukohast on see, et sa loobud kontrollist, mis saab su koodist edasi. Kuna keegi pole kohustatud oma muudatusi avaldama, võib juhtuda, et teised võtavad su koodi, ehitavad selle peale midagi paremat või kohandatumat, kuid sina (ja üldsus) neid täiustusi kunagi ei näe. Teisisõnu, puudub garantii, et “andmine toob ka tagasi”. Kui mõne projekti puhul on oluline, et kogukond panustaks muudatused ühisprojekti tagasi, siis permissiivne litsents seda ei taga – kõik sõltub osalejate heast tahtest. Mõni ettevõte võib näiteks võtta BSD-litsentsiga teegi, integreerida selle oma suletud tootesse ja saavutada ärilise edu, panustamata midagi algsesse projekti. Selline stsenaarium võib arendajale, kes ootas avatud koostööd, olla frustreeriv. Tehnilisest vaatepunktist on BSD litsentsiga koodil ka mõned riskid: näiteks patendikaitse puudumine. Erinevalt mõnest muust litsentsist (näiteks Apache 2.0) ei sisalda BSD litsents klauslit, mis annaks kasutajatele automaatse patendiõiguste loa. See tähendab, et kui keegi omab patenti mõne koodiosa kohta, võib ta teoreetiliselt hiljem nõuda litsentsitasu või esitada nõudeid, see on küll spetsiifiline juhtum, kuid siiski potentsiaalne juriidiline risk BSD-projektide puhul. Praktikas on sellised juhtumid harvad, kuid suuremates ettevõtetes võib seetõttu permissiivse litsentsi kasutamisel vaja olla taustakontrolli. Kokkuvõttes taanduvad BSD stiilis litsentsi puudused sellele, et arendaja annab teistele vabad käed, lootes (aga mitte kohustades) koostööle. See on filosoofiline valik: kas eelistad laiemat levikut isegi siis, kui see ei pruugi sulle otsest tagasisidet tuua?
Millal valida BSD või muu permissiivne litsents? Kui sinu eesmärk on, et su projekt oleks võimalikult laialt kasutatav, olgu see siis teek, raamistik või mõni standardiseeriv tehnoloogia, siis on BSD/MIT tüüpi litsents tihti kõige praktilisem valik. See sobib suurepäraselt näiteks juhul, kui arendad teegid või platvormi, mida võiksid kasutada nii hobiarendajad kui ka suured firmad oma toodetes. Permissiivne litsents ütleb sisuliselt: “Kasuta mu koodi, kuidas iganes tahad” ja see võib tulemuseks tuua nii integratsioonid suurtes kommertssüsteemides kui ka laia turuosa. Arendajana võiksid valida BSD litsentsi ka siis, kui sa ei soovi tegeleda juriidiliste detailidega või soovid vältida võimalikke vaidlusi, BSD on oma selguse ja lihtsuse tõttu riskivaba valik enamikele kasutajatele.
Kui sul ei ole probleemi sellega, et keegi teine võib su koodist ka äriliselt kasu saada (isegi kui sina otseselt sellest tulu ei saa), ja sa väärtustad tarkvara ideede laia levikut rohkem kui ranget vabaduse kaitset, siis on permissiivne litsents mõistlik. Paljud ettevõtted avavad oma mitte-strateegilise koodi BSD/MIT litsentsiga just selleks, et teised saaksid seda vabalt omaks võtta, see võib olla ka sinu strateegia, kui soovid endale nime teha või seada mingit tehnoloogilist standardit.
Kasutatud allikad:
Kommentaarid
Postita kommentaar