Tegu on 7. nädala mõtisklusega ITSPEA kursuses, mille üldteemaks on Arvutid ja paragrahvid IIː litsentsid ja autoriõigus. Õppejõud on küsinud:
Mismoodi mõjutab vabade litsentside juures edasikandumisklausel (copyleft) litsentsivalikut? Analüüsi seda ajaveebiartiklis ning too iga variandi kohta mõni näide.
– Kaido Kikkas
GPL – mida see Copyleft tähendab?
10 aastat tagasi hakkasin püsti panema esimesi WordPressil põhinevaid lihtsaid CMS-e. Kui neid lego-taoliste komponentidena ühte sai siduda siis jõudsin ühel hetkel tõdemuseni, et enamik kaasa käivaid pluginaid tulid mingi kummalise täheühendiga “GNU-GPL”. Tegemist oli litsentsiga, millega tuli kaasa juriidiline juhis:
- Kasuta tasuta,
- Muuda,
- Viita allikale
- ja anna samadel tingimustel teistele edasi
Pisut süvenemist viis ehmatava tõdemuseni, et nii mõnigi nendest juppidest nõuavad sisuliselt seda, et kui ma midagi nendega ise edasi teen, siis peaksin ma kogu selle kupatuse andma ka teistele tasuta kasutada!? Et mis mõttes?
Gnu – õilis eesmärk, soovimatud tulemused?
Copyleft liikumist hakati rekursiivse lühendi GNU (“GNU’s Not Unix!”) põhjal kutsuma Unixi-laadset tasuta tarkvarade kogumit, mis pandi püsti Richard Stallmani eestvedamisel. Esialgse GNU manifesti eesmärk oli idealistlik: luua raamistik tarkvara loomiseks, mis lõppkasutaja jaoks oleks tasuta. Selleks, et seda laadi tarkvara hakkaks viiruse laadselt levima, siis pandi ühtlasi paika paar aluspõhimõtet:
- Kasutajal peab olema täielik kontroll oma süsteemi üle
- Kasutaja jaoks peab tarkvara olema vabalt ja tasuta kättesaadav
- Ka sellele tarkvarale ehitatavad derivatiivid peavad olema tasuta
- Tarkvaraarendajad saavad raha teenida mitte oma valmistatud toodet skaleerides vaid nad pääsevad näljast jätkuvalt seeläbi kui nad teevad unikaalset loomingut.
Iseenesest ju vahva mõte, aga alltoodult kirjedan siiski olukorda, kus GNU copyleft kombinatsioonis teist liiki litsentsidega on mõned viinud suboptimaalsete lahendusteni. Mingi tasuta asja kasutamiseks tuleb üles ehitada süsteeme, mis lõpuks muutub kasutajale kallimaks kui asja nullist ehitamine.
Koodikunstniku sulest valmib meistriteos?
Koodikirjutajast kunstniku unistus võiks olla alljärgnev. Iga rakendust võib hakata ehitama nullist kuni see võtab sellise vormi, mis ideaalile vastab.
Mõtle, kavanda, visanda, võta koodiredaktor ette, testi, ehita, pühenda ja pane püsti. Voila! – lihtsalt võtab veidi aega ja koodikunstniku sulest valmib meistriteos.
Praktikas see aga tihti nii ei toimu. Kui süsteeme luuakse ajasurve all, ajumaterjalist on vajaka ja progejate kamp on kitsuke ning tarvis kiirelt mingite lahendustega valmis saada, siis tundub tõhusamaks lahenduseks võtta mõni olemasolev raamistik või komponent ning hakata asju ehitama olemasolevate tükkide abiga.
Ja nii võibki juhtuda, et nädalavahetuse häkatonil hakatakse veebirakenduse loomiseks häkkima teiste poolt valmis saanud moodulite abil, kus on tarvis püsti panna mõnda kättesaadavasse serverisse lihtne andmebaas, luua toimiv tagatoa ja äriloogika kiht, lisada väljapoole paistev vaateaken ning palistada see mõne kättesaadava andmeanalüütika lahendusega, mis hakkab MVP kohta usaldusväärset infot koguma, et asja järk-järgult paremaks saaks timmima hakata.
Litsentsimajandus nõuab eraldi tähelepanu
Kuna tegemist ei ole antud juhul rätseplahendusega, siis suure tõenäosusega võib sellise rakenduse püsti panemisel kokku puutuda juriidilise müriaadiga, mis tavapäraselt tarkvaraarendaja igapäevaeluga isegi kokku ei käi. Niisiis võib olla tegemist olukorraga, kus litsentside valik saab olema umbes alljärgnev:
- Server istub kas kusagil pilves või veebiteenuse pakkuja juures ja on sõltuvalt versioonist kas tasuline, GPLv3 või copyleft klauslile vastav;
- Andmebaas on püsti pandud kas kohaliku masina laiendusena või sealsamas serveris ja tugineb kas MIT, GPLv2 või tasulise litsentsipakkuja tingimustel;
- Backend ja äriloogika töövahendid võivad olla kas GNU, MIT või tasulise litsentsi baasil;
- Front-end on vist kõige lihtsam. Kuna seal kasutatakse enamasti mingeid Javascripti derivatiive, siis valdavalt on nende raamistikud kõige vabamalt kättesaadavad ja tuginevad tasuta MIT litsentsitingimustel;
- Veel mõned moodulid, mis mistahes rakenduse nõudeid täidavad. Selles valdkonnas on vist valikute hulk kõige kirjum, sest litsentse ja lahendusi on täiesti servast serva – GPLv2, LGPLv3, palju tasulisi ja väga palju on ka copylefte;
- Andmeanalüütikat on palju tasulist, üksjagu freemiumi ja mõni ka MIT põhine tasuta variandina saadaval.
Juba lihtsamat laadi veebirakenduse valmistamisel tuginedes täielikult olemasolevate komponentide alusele võib lõppeda olukorraga, kus tuleks läbi lugeda ca 20 erineva komponendi litsentsilepingud ja mõelda, et kas kõikide nende kasutamine on antud rakenduse puhul mõistlik.
Markantne pilt – kuidas litsentsihaldust üle komplitseerida?
Antud teemasse tungides jõudsin huvitava näiteni, mille oli kokku pannud Euroopa Komisjoni JRC direktoraadi esindaja Stefano Gentile. Ta kirjeldas oma PowerPoint esitluses pealkirjaga “The Copyleft Paradox: Open Source Compatibility Issues and Legal Risks” situatsiooni, kui üritada kahe erineva toote litsentse omavahel kombineerida.
Juba ainuüksi kahe erineva litsentsi puhul on võimalik tuvastada hulk kattuvusi ja ühtesobivusi. Samuti hulk keelualasid, mis litsentsid üksteise kasutamise ilmselgelt välistavad. Lisaks hulk kombinatsioone, mis kahe litsentsi ühte liitmisel moodustavad loogiliselt hoopis kolmanda litsentsitüübi ja kõige lõpuks veel terve rea defineerimata alasid, mille kombinatsioon jääb lahtiseks.
Üritaks siis ette kujutada siia kõrvale 20×20 dimensiooniga maatriksit, kus need erinevad aspektid peaksid ühte sobima. Komplekssus kasvab mühinal.
Licensing-as-a-Service (LaaS) – Litsentsihaldurite unistus?
Ilmselt see ongi põhjus, miks on tekkinud sisuliselt terve “tööstusharu”, mille olulisemaks rolliks on hallata just suuremates ettevõtetes tarkvara litsentse. Suur hulk “licence management” töö- ja tegevusvallast tugineb mitte arenduses kasutavate litsentside omavahelise sobivuse analüüsil, vaid pigem:
- Riiulitoodete litsentside halduses oma suure organisatsiooni sees – ehk et saada ülevaadet, et millal järgmised Microsofti tooted on meil aegumas või millal tuleks teha järgmine ülekanne Oracle litsentside eest;
- Erinevate kopeerimiskaitsega süsteemide turvalisuse või tehnoloogia halduses – juhul kui mingi süsteemi jaoks on välja mõeldud kas USB võtmed või võrgust kontrollimised.
Aga samas on tõepoolest sündimas ka omamoodi uus seltskond firmasid, kes lubavadki tarkvara arendustegevust pakkuvatele organisatsioonidele, et nad pakuvad Licensing-as-a-service teenust.
Sisuliselt tähendab antud teenus, et litsentside kasutaja jaoks tekib üks “one-stop-shop”, mille kaudu kogu litsentsidega seonduv nende jaoks ära saab lahendatud.
Nii et jah – GNU pidi ju kõik tasuta kättesaadavaks tegema. Paradoksaalselt oleme aga jõudnud hoopis olukorda, kus GNU derivatiive on palju. Lisaks teisi litsentsitüüpe, mis üksteist välistavad. Asi on läinud nii keeruliseks, et tavapärane infohalduse võimekus ei vii enam tulemuseni. Peavalu missugune!
Niisiis – lõpuks jõuame olukorda, kus litsentsimise haldamise teenusest on kasvanud globaalselt tööstusharu, mille suuruseks aastal 2022.ennustatakse 1141 miljardit USD. Kellegi jaoks peavalu on kellegi teise jaoks teenistus. 🙂