Võimatu nõuab natuke rohkem aega

 Sellenädalane ITSPEA teema vaatleb, kuidas kasutavad tänapäevast tehnikat inimesed, kes ei tee seda "traditsioonilisel" teel. Ehk nad valdavalt kas ei näe või ei saa oma liigutusi tehnika juhtimiseks kontrollida. Võin olla siiralt õnnelik, et mind ja teravat ekraanipilti lahutavad ainult kontaktläätsed ning kõigest paaril korral elus olen lühiajaliselt tundnud "hiirekätt". Seetõttu koban ma ligipääsetavusega tegelevas valdkonnas üsna pimeduses. Loomulikult olen meedia kaudu näinud näiteks "digiluupi" või seda, kuidas mõni inimene kasutab arvutit näiteks jalgade või suuga. Lisaks kuulnud EKI kõnesüntesaatorist, mis on praeguseks juba väga hea arengu läbi teinud ja meenutab üha enam inimkõne.

Huvitav oli aga uurida, millise arengu on läbiteinud tehnika viimased sõnad ligipääsetavuse parandamiseks. Springwise on ligi aasta eest teinud ülevaate seitsmest uuest või arendamisjärgus olevast abivahendist. Ühe väga põneva ideena jäi mulle silma Iisraeli disaineri Oren Geva 2C3D kaamera. Mäletate seda mänguasja, kus on nupukesed, mida ühelt poolt surudes tekib teisele poole kolmemõõtmeline kujutis surutavast esemest, näiteks käest? Samal põhimõttel peaks töötama ka nimetatud kaamera. Suunad kaamera huvipakkuvale objektile, tekib 3D kujutis, mida pime saab kombata.

Lisaks saab 3D pilte salvestada ja hiljem neid uuesti käte abil vaadata. Kahjuks viimaseid arenguid selle lahenduse osas ei suutnud leida. Projekti koduleht ei avanenud, ent loodan, et see hea mõte jõuab ikka laiemale ringkonnale kasutamiseks. Üsna hea ülevaate 2C3D kaamerast on leitav siit.

Teine mõte, mis mind köitis on tuntud innovaatori Elon Musk'i Neuralink. Selle puhul paigaldataks inimesele seade, mis registreerib, analüüsib ja kannab edasi tema ajus toimuvaid närvisignaale. Peale seadmele oma mõtete lugemise õpetamist, ehk kindlate harjutuste sooritamist, on võimalik mõttejõul käsklusi edastada.

F. Nansen on öelnud: "Raske on see, mis nõuab natuke aega; võimatu see, mis nõuab natuke rohkem aega". Sama kehtib ka tehnika ligipääsetavusega - erinevate puuete puhul võib tehnika kasutamine tunduda pea võimatu, ent üha reaalsemaks saab see, et see nõuab kõigest natuke rohkem aega. Lisaks nõuab ka uute ja järjest suuremate võimalustega kontrollseadmete (nt Neuralink) väljatöötamine kõigest häid ideid ja aega.

Võimalused vs kasutusmugavus

Peaaegu normiks on saanud, et ettevõttel on lisaks füüsilisele aadressile veebiaadress. See, mida ettevõte oma kodulehele panna otsustab, on laias laastus aga ta enda teha. Kliendina ootan müügiga tegelevate ettevõtete lehtedelt kindlasti infot, mida müüakse ja seda, kuidas kontakti saada. Kasutusmugavust tõstab info kaupade/teenuste hinna kohta infot, veel parem, kui on lisatud otsingu- ja sorteerimisvõimalusi.

Lihtsa näitena Meie toidukaupade ja Selveri lehtedel on olemas info nii asukoha kui teatud määral ka saadaolevate toodete ja hindade kohta, aga muus osas on need üpris erinevad. Kui Meie toidukaubad paistab rõhuvat minimalistlikkusele ja valmiskomponentide (issuu) kasutamisele, siis Selver on lehte sisseehitanud e-poe, Selveri köögist tellimise võimalused, retseptinurga jne. Ehk siis kasutajale on nende lehtede välimus (user interface) ja kasutusvõimalused väga erinevad.

Välimusega on tihedalt läbipõimunud kasutajakogemus (user experience) ehk see, kuidas kasutaja talle pakutud funktsionaalsust saab kasutada. Kasutatavuse osas on Jakob Nielsen toonud välja 5 kriteeriumi: õpitavus, tõhusus, meeldejäävus, vead ja rahulolu. Kui Meie toidukaupade leht on õpitavuse seisukohast väga kiire, siis tõhususes soodustoodete otsimisel jääb ta Selverile selgelt alla. Nimelt on Selveril Eesti e-poodidest üks põhjalikumaid filtreerimissüsteeme. Meeldejäävuse poolest on neid kaht lehte keeruline võrrelda - Meie toidukaupade leht on niivõrd minimalistlik, et seal on keeruline unustada, kust mida leida, Selveri lehel jällegi läheb pisut aega, et meenutada, kus miski asus. Vigu võib Selveri lehel kasutajal kindlasti tunduvalt rohkem tekkida. Eriti näiteks lehte puutetundliku ekraaniga kasutades, kus ostukorvi võib ootamatult sattuda tooteid rohkem kui plaanitud. Täielikku rahulolu mul neid lehti kasutades ei teki - Meie toidukaupade funktsionaalsus on liiga madal, Selver on jälle üsna palju funktsioone väiksele alale püüdnud mahutada.

Kasutajakogemuse seisukohast on paljudel hambus olnud eesti.ee leht. Mitmeti pean sellega nõustuma - intuitiivselt õppimine võtab seal aega, tõhusus pole eriti kõrge, sest soovitava teemani jõudmine on samuti mitme menüüpunkti taga peidus. Kui lehte mõnda aega ei kasuta, siis läheb meeldetuletamisega jällegi aega ning mitmel korral olen avastanud end otsimast mõnd teemat valest alapunktist. Samas sisukuselt on see leht võrratu, koondades kokku kogu väga palju infot. Lisaks võib lehele väikese pai teha, kuna see on ajapikku muutunud siiski veidi intuitiivsemaks. 

Lõpetuseks on veebilehtede välimuses toimunud viimase 15 aasta jooksul märkimisväärne areng. Staatilised lehed on muutunud dünaamilisteks ja kõvasti kasutajasõbralikemaks. Lehe tegemiseks ei pea enam ise programmeerima õppima või oskajat palkama, vaid saadaval on erinevad keskkonnad (nt WordPress, Weebly, Joomla! jne). Isegi kasutatavuse parandamiseks saab pöörduda ekspertide poole, näiteks Trinidad Wiseman, kelle leht on esmapilgul äärmiselt intuitiivne. 

Mudelid-mudelid-mudelid

 Igale ülesandele saab läheneda mitmeti - nii ka tarkvara arendamisele ja hiljem loodud tarkvaralt tulu teenimisele. Samas on oht, et väga uudset lähenemist kasutades kolistad enne mitmed ämbrid läbi, kui toimiva lahenduseni jõuad. Selleks, et õppida teiste vigadest ja ennekõike kogemusest, on tarkvaraarenduses kirjeldatud mitmeid arendus- ja ärimudeleid.

Arendusmudelid võivad olla oma olemuselt 

• jäigad, liikudes ülesande püstitusest ja analüüsist toote disainimisele, arendamisele ja testimisele ning seejärel juba valmistoote hooldamisele (kosemudel)
• evolutsioneeruvad, kus liigutakse järjest läbi samu etappe, jõudes üha täiustatuma tooteni (spiraal-, sammsammuline ja iteratiivne mudel)
• vahetu tagasisidestamisega, kus käib pidev koostöö tellija ja teostajate vahel (agiilne mudel).

Oma töös olen seni kokku puutunud kombineeritud mudelitega. Üldjuhul on ülesanded püstitatud 1-2 kuu jaoks ning seotud olemasoleva toote täiendamisega. Samas on kasutusel agiilsetest mudelitest tuttav kanban tahvel (Jiras). Mõnevõrra keerulisem on nuputada, millist arendusmudelit ühe või teise tarkvara puhul kasutatakse, mille arendamise juures ise ei viibi. Üheks tõenäoliseks indikaatoriks on rakenduse töökindlus ja välimus. Näiteks on suure tõenäosusega kosemudeli või mõne evolutsioneeruva mudeliga valminud https://www.riigiteataja.ee/. Selle rakenduse välimus ja funktsionaalsus on olnud aastaid üsna samasugune. Teisalt on sealgi kindlasti tehtud mõningaid pisiparandusi või täiendusi ning ootel on kasutajasõbralikum Riigiteataja versioon: https://ert-proto.rik.ee/. Vastupidise väga agiilse mudeli näide on Facebook, kus funktsionaalsused lisanduvad ja muutuvad pidevalt. 2016. aastal tehtud ülevaates [1] tuuakse välja, et Facebook'i funktsionaalsust uuendatakse iganädalaselt. Kiirest arendustsüklist tulenevalt satub sageli sisse ka vigu - üks hiljutistest, mis meenus, oli näiteks selline, kus vestlustest kadusid kõik pildid 

Ärimudelitel esineb tavakaupadele sarnase traditsioonilise omandvara kõrval ka terviklahendusi, tarkvararenti, viimasele sarnast tarkvara teenusena müümist ning freemium lahendusi. Tavakasutajale suunatud rakendustes kohtabki üpris sageli seda viimast - freemiumi. Kuigi sõnana esmapilgul võõras, on olemus tuttav: free + premium ehk tasuta ja tasulise versiooni võimalus. Nii tundub toimivat suur osa mobiilirakendustest, vähemalt nendest, mis minu nutiseadmetesse on jõudnud. 

Ärimudel on iseenesest üsna nutikas - tasuta kasutajal on sageli piiratud funktsionaalsuse kasutusõigused, lisaks pakutakse kasutajale sageli reklaami, mis võib kasutajakogemust korralikult rikkuda, ent võimaldab reklaamimüügi kaudu tulu teenida. Selleks, et saada juurdepääs kogu funktsionaalsusele ning pääseda tüütutest ja pealesurutud reklaamidest, on kasutajal võimalus mõne rakenduse puhul teha ühekordne makse, teisel oodatakse perioodilisi makseid. 

Lõpptarbijana olen siiani enamasti reklaamidega rahu teinud, ent olen teinud ka üksikuid erandeid. Näiteks Spotify, mis kasutab samuti freemium mudelit, võimaldab tasuta kasutajal teha küll lugude otsingut, aga aeg-ajalt pole võimalik oma soovitud lugu kohe kuulata. Enne tuleb ära kuulata Spotify poolt soovitatud laulud. Lisaks avaneb võimalus iga mõne aja tagant reklaami kuulata. Liikudes tasulisele versioonile, kaovad eeltoodud ebamugavused, kusjuures tehtud on näiteks tudengisoodustus. Suure tõenäosusega küll selleks, et tekitada tarbimisharjumus, millest tudengipõlve lõppedes enam loobuda ei tahaks... Arvestades, et Spotify tasulise versiooni kasutajad moodustavad ligi poole nende igakuistest kasutajatest [2], on nende ärimudel väga hästi tööle hakanud.

[1] https://research.fb.com/wp-content/uploads/2016/11/development-and-deployment-at-facebook.pdf
[2] https://newsroom.spotify.com/company-info/

Arvustus: Eric Steven Raymond, How To Become A Hacker

Eric Steven Raymond, kellele sageli viidatakse kui ESR, on kauaaegne häkker. 

Siin ja edaspidi on häkker tähenduses tipp-programmeerija, keda iseloomustab oma töös uuendusmeelsus - ta püüab probleemidele luua uusi ja põnevaid lahendusi. EI tähenda "kräkkerit" ehk inimest, kes püüab süsteemides esinevate turvaaukude kaudu või muudel meetoditel nendesse sisse saada eesmärgiga neid lõhkuda.

ESR on internetikultuuris olnud aktiivne selle algusaegadest saati ning on 90ndate teisest poolest kujunenud üheks tuntuimaks ja mõjukaimaks vaba tarkvara liikumise figuuriks, kes esindab avatud lähtekoodi koolkonda. Tema tegemistest võib lähemalt lugeda siit. Eessõnas esseele How To Become A Hacker (eestikeelne tõlge: Kuidas saada häkkeriks, tõlkinud Kaido Kikkas) räägib autor, kuidas ta sellise "juhendmaterjalini" on jõudnud. Nimelt märkas ta 1996. aastal, et temalt küsitakse sageli, kuidas saada/õppida tipphäkkeriks, aga sarnasel teemal KKK vastustega ei leidunud.

Essees annab autor ülevaate 

häkkerlikust suhtumisest  

1. Maailm on täis imelisi probleeme, mis ootavad lahendamist
2. Ühtegi probleemi ei tuleks lahendada kaks korda
3. Igavus ja nüridus on kurjast
4. Vabadus on hea
5. Suhtumine ei asenda kompetentsi

häkkeri põhioskustest

1. Õpi programmeerima
2. Hangi üks avatud lähtekoodiga Unixitest ja õpi seda kasutama
3. Õpi kasutama veebi ja kirjutama HTMLi
4. Kui sa ei oska piisaval määral inglise keelt, õpi see ära

staatuse saavutamisest häkkerikultuuris

1. Kirjuta avatud lähtekoodiga tarkvara
2. Aita avatud lähtekoodiga tarkvara testida ja siluda
3. Avalda kasulikku teavet
4. Aita hooldada infrastruktuuri
5. Teeni häkkerikultuuri

ning avab mõned terminid, nagu häkkerid, nende võrdlus nohikutega räägib avatud lähtekoodi ajaloost ja vastab enamlevinud küsimustele. Eriliseks muudab essee selle pidev uuenemises olemine - ESR on tänase seisuga viimase versiooniuuenduse 1.52 teinud jaanuaris 2020.

Essee on kirjutatud kaasahaaravalt, seda lugedes tabasin päris palju end analüüsimast, kas mõni punkt on mulle iseloomulik. Lisaks, kui mõni eesmärkidest pole veel saavutatud, siis kui tõenäoline on, et ma tulevikus tahaksin nendeni jõuda. Juba essee algusjärgus valdas mind äratundmisrõõm - just suhtumine, et maailmas on nii palju huvitavaid probleeme, mis ootavad lahendamist, on mind üsna kaua saatnud. Pisut jääb samas arusaamatuks, kas autor peab silmas teiste defineeritud probleeme, nende probleemide ise tuvastamist või mõlemat. Ka ülejäänud suhtumist puudutavad punktid on hästi põhjendatud ning ei jää kahtlust, et need peaksid häkkerit iseloomustama.

Nagu autor essees mitmel korral rõhutab, siis ainuüksi suhtumisest häkkeriks saamisel ikkagi ei piisa. Vaja on lisaks kompetentse, mida autor loetleb. Python esimese programmeerimiskeele soovitusena on hästi kooskõlas Eesti praktikaga - Tartu Ülikooli MOOCid on Pythonile ülesehitatud ning nüüd alustatakse ka Tallinna Tehnikaülikoolis programmeerimise algkursust just Pythoniga. Olles ise samuti pigem Pythonist alustanud ja seejärel Vali-ITs intensiivselt Javat õppinud, pean autoriga nõustuma, aga teistel põhjustel. Mõlemad keeled on väga võimekad, ent Java objektidele orienteeritus, mida saab Pythonis küll kasutada, aga ei pea, oli esimesel hetkel raskesti hoomatav. Ülejäänud essees soovitatud programmeerimiskeeled on saanud hea põhjenduse ning ootavad ToBeLearned nimekirjas. Autor annab häid soovitusi Unixi valimiseks ja erinevate võimaluste kohta, mis aitavad algajal hästi selles maailmas esimesi samme seada. Soovitused HTMLi ja inglise keele õppimise kohta on asjakohased.

Autor on välja toonud essees praktilised näpunäited, kuidas pälvida häkkerite seas positiivset tähelepanu ja austust. Selle kesksel kohal on ootuspäraselt avatud lähtekoodiga tarkvara - nii selle loomine kui teiste loodu testimine ja silumine. Lisaks on hea märkus, et oma teadmisi võiks jagada KKK stiilis ka ülejäänud kogukonnaga. Nii jääb ära ka rattaleiutamise faas.

Kokkuvõttes on tegemist väga meeldiva lugemisega ja kindlasti soovitusliku lugemisvaraga tarkvaraarenduses esimesi samme tegevale inimesele mõttemaailma kujundamiseks.

IT juhtimine

 Sellenädalaseks teemaks on IT juhtimine. Nagu mitmetel teistel elualadel, on IT-töö peamiselt projektipõhine. Kuigi IT juhtimise all võiks vaadelda seda, millised on projektijuhtimise viisid, keskendun täna aste kõrgemale. Nimelt IT-firmade juhtimisele. 

Tüpaažilt on juhte erinevaid - mõnel on selge visioon ja veab seetõttu organisatsiooni vedurina (juht), teine on oma juhtimise üles ehitanud sidemete loomisele ja info vahetamisele (suhtleja). Mõni juht on väga tugev eriala spetsialist, mistõttu suudab ta alluvate arengut hästi suunata (juhendaja), teine on oma olekuga inspiratsiooniks (mentor). Lisaks on olemas visionääre, kes tajuvad hästi uusi trende (arengumootor) ning on jäiga ja autoritaarse stiiliga juhte (ülemus). Nagu elus on musta ja valge tooni vahel suur hulk halle varjundeid, ei esinda ükski juht tavaliselt üht kitsast rolli. Samas on võrdlemisi keeruline hinnata, millise stiiliga mõni juht on, kui puudub temaga isiklik kogemus. Seetõttu valisin juhtimisstiili analüüsimiseks juhid, kellega on mul olnud kas otsene kokkupuude või kelle kohta olen saanud arvamuse kujundada talle lähedaste isikute kaudu.

Esimeseks valituks on Nortali asutaja ja tegevjuht Priit Alamäe. Temaga pole olnud mul küll otsest kokkupuudet, aga varasema töö käigus olen temast pisut kuulnud oma eelmiselt ülemuselt, kes on juhtumisi Priit Alamäe tädi. Jutukatkete põhjal on Priit Alamäe jätnud mulle väga aruka ja sihikindla mulje. Kuuldes erinevatest innovaatilistest vahel üsna eksootiliselt kõlavatest projektidest, mida ta on käima vedanud, usun, et tegemist on enim "juhi" rollis oleva juhiga. Arvamust toetab ka kolme aasta taguses Äripäeva artiklis kajastatud Taavi Kotka kirjeldus Priit Alamäest kui väga ambitsioonikast ja eesmärgile pühendunud juhist, kellele sihid võivad suhetest olulisemaks osutuda. Selle põhjal võib arvata, et lisaks juhirollile on ta oma juhtimisstiili põiminud ka "ülemuse" rolli.

Teiseks näiteks on üldsusele mõnevõrra vähem tuntud Industry62 kaasasutaja ja tegevjuht Andrus Altrov, kes andis hiljuti ülevaate ühest ettevõtte suurest tegevusvaldkonnast - e-tervisest. Andrus Altrovi valik analüüsimiseks tuli mõnevõrra loomulikumalt, kuna töötan kolmandat aastat Industry62-s. Juhirollilt on Andrus Altrov peamiselt "teavitaja/suhtleja" - lisaks iganädalastele tiimijuhtide koosolekutele käiakse sama sageli infotundides üle möödunud nädala sündmused nii ettevõtte kui tiimide kaupa. Selline formaat aitab hästi ettevõtte käekäiguga kursis olla. Lisaks on ta visionäär, kellele on eriti hingelähedased tervisega seotud teemad ja nende võimalikud lahendused. Mõnevõrra on Andrus Altrovi juhirollid kindlasti mõjutatud Industry62 formaadist - tegemist on ettevõttega, kus suur osa töötajatest on osanikud ja seega ka otseselt huvitatud organisatsiooni tulevikuplaanidest. Seetõttu on klassikaline juhiroll pigem jaotunud tiimijuhtide ja muude töötajate vahel. 

"Proff" vs "käsitööline"

Uut oskust hakkavad kõik omandama puhtalt lehelt. Muidugi on inimeste õppimisvõime ja -kiirus erinevad ja nii jõutaksegi sarnaste oskusteni erineval ajal. See, kas jäädakse teatud taseme juures pidama või püütakse teadmisi laiemas kontekstis kasutada, sõltub jällegi indiviidist. Sel nädalal mõtisklengi pisut teemal, mis teeb mingis valdkonnas profist profi. Et vähendada mitmeti mõistmist, olgu toodud, millises kontekstis "käsitööline" ja "proff" järgnevas tekstis on.

käsitööline - valdkonna (tipp-)spetsialist, kes on alal väga kompetentne, ent lahendab probleeme peamiselt õpitud teadmiste varal või olemasolevaid "tükke" kasutades

proff - lisaks kõrgele kompetentsusele suudab luua seoseid teiste valdkondadega ning seeläbi tuua valdkonda arengut

Erinevate erialade puhul on käsitöölise ja profi määratlus kindlasti pisut erinev sõltuvalt sellest, mida lugeda valdkonna arenguks. Kuna olen kümmekond aastat olnud tegev teaduslaborites, siis sealt on analoogia leidmine lihtne. Käsitöölised on tehnikud või teadurid, kes teostavad rutiinseid analüüse ning valdavalt teostavad projekti täitmiseks vajalikke ülesandeid. Profid on need, kes on kokku pannud eduka granditaotluse ja seeläbi oma ideedele saanud rahastuse. Viimased panustavad otseselt valdkonna arengusse ehk uute teadmiste saamisse. Tulles IT juurde, siis pole ma endale veel päris lahti mõtestanud, kas IT-s on arenguks mõne uue raamistiku väljatöötamine või piisab ka olemasolevate lahenduste uutmoodi ja optimaalsemast kombineerimisest? Pigem kaldun viimase poole.

Kui püüda leida omadusi, mis käsitöölist ja proffi võiksid eristada, siis need on peamiselt uudishimu ja silmaring. Nimelt käsitööline võib probleeme suurepäraselt lahendada ka nii, et ta ei lasku süvitsi detailidesse, miks just sellist lahendust kasutada. Internetist on võimalik leida hulganisti erinevate lahenduste näiteid, mida oma probleemi lahendamiseks kasutada. Profid samas kipuvad minema uudishimust probleemi olemusse sisse ning omandavad seeläbi uusi teadmisi ja laiendavad oma silmaringi. Lisaks võivad nad seeläbi ka olemasolevaid lahendusi optimeerida. Tänu laiemale silmaringile on proffidel ka paremad teadmised, milliseid lahendusi üleüldse eksisteerib, mistõttu võivad nad probleemide lahendamisel olla ka kiiremad kui harilikud käsitöölised.

Lõpetuseks, uudishimu on edasiviiv jõud ja sellega on võimalik saada käsitöölisest profiks. Samas ollakse proff üldjuhul ainult kitsas valdkonnas, ülejäänud lähedastel aladel jäädakse tavaliselt käsitöölise tasemele.

Avavara kaitsmisest

Suure tõenäosusega tuleb iga tarkvaraarendaja elus kord päev, kus ta loob avavara (open-source software). Vähemalt on tarkvaraarendajal tõenäosus avavara luua kõvasti suurem kui inimesel, kes pole koodi kirjutanud. Igal juhul, kui ühel päeval soovid oma saavutust ülejäänud maailmaga avavarana jagada, tasub pisut mõtiskleda, kuidas loodut kaitsta. Süvenedes avavara litsentside maailma, selgub, et see mõtisklus võib isegi kujuneda pikemaks. Nimelt - Open Source Initiative'i lehel on loetletud üle 100 avavarale heakskiidetud litsentsi. Populaarseimad ja laialdasemalt kasutatavad või tugeva kogukonnaga on: 

• Apache License 2.0 (Apache-2.0)
• 3-clause BSD license (BSD-3-Clause)
• 2-clause BSD license (BSD-2-Clause)
• GNU General Public License (GPL)
• GNU Lesser General Public License (LGPL)
• MIT license (MIT)
• Mozilla Public License 2.0 (MPL-2.0)
• Common Development and Distribution License 1.0 (CDDL-1.0)
• Eclipse Public License 2.0 (EPL-2.0)

Kuigi litsentsinimekirja süvenemise asemel võib tunduda lihtsam jätta oma tööle litsents lisamata, on see pisut libe jää. Autoriõigused laienevad tööle automaatselt ja kui litsentsiga mitte täpsustada, siis ei tohi keegi teine tööd kopeerida, jagada või muuta, riskimata näiteks kohtuvaidlustega. Kurioosne on, et kui tööl on mitu autorit, siis kaasnevad ka sulle endale samad riskid, kui soovid hiljem töösse muudatusi teha [1]. 

Seega, et tagada piiramatu ligipääs oma tööle, kasutatakse avavara puhul:

• copyleft-tüüpi litsentse, mis läbi õigusraamistiku tagavad jätkuva vaba ligipääsu tarkvarale ja selle lähtekoodile. Kaitsevad autoriõigusi ja neid võib kasutada kommertsiaalsetes rakendustes. Peamine nõue on, et tuletatud loomingut tuleb jagada samadel litsentsitingimustel, ehk õigused on "piiratud";
• nn akadeemilisi ehk mitte-copyleft litsentse, millele on olnud alusepanijaks ülikoolid. Erinevalt copyleft litsentsidest ei pea akadeemiliste litsentside kasutamisel lähtekoodile viitama, seega on antud litsentsid "lubavad". Sinna alla kuuluvad näiteks:
• Apache (näiterakendused Android, ASP.NET, Docker, Kubernetes)
• MIT (näiterakendused Angular, GitLab, Jenkins, Node.js, Vue.js)
• BSD (näiterakendused Django, NumPy, Ruby)[2]
  Laias laastus on need litsentsid üsna sarnased, erisused tulevad nüanssides, mida saab vaadata siit. Näiteid on ka mitte-copyleft'iga litsentside vahetamisest, näiteks React'i kaitses varem BSD litsents, aga nüüd MIT. Selline vangerdus tehti, et React'i ja React Native'i kasutajad ei peaks kartma, et Facebook neid kohtusse kaebab või nad oma patendid kaotaks [3].

Copyleft litsentsid jagunevad omakorda veel kolmeks:

• GPL - tugeva copyleft'iga - tuntuim, kuna see on ühtlasi vanim ja seetõttu enim mainitud (näiterakendused Git, Linux kernel, MySQL, Notepad++, WordPress)
• LGPL - nõrga copyleft'iga, väga sarnane eelnevaga, aga teatud tingimustel võib projekti osi kasutada ärivara loomisel (näiterakendused 7-zip, VLC media player)
• AGPL - väga tugeva copyleft'iga, esimesega peaaegu identne, aga võimaldab veebirakenduste puhul küsida lähtekoodi. Seetõttu pole online'is kasutuseks mõeldud ärivara loomisel kõige mõistlikum taolise litsentsiga kaetud avavara kasutada (näiterakendused RStudio, Zotero)

Copyleft litsentsid on saanud kriitikat, et need on liiga piiravad. Teisalt võimaldab nende kasutamine tagada, et avavara ei kasutaks kommertsiaalsed ettevõtted, mis ei anna konkreetse avavara kasutamisel ühiskonnale midagi tagasi. Lisaks hoiab copyleft litsentside kasutamine ära seda, et projekti osi kasutatakse konkureerivate projektide loomisel [4].

Varasemalt on olnud copyleft'iga litsentsid populaarsemad kui mitte-copyleft'iga litsentsid, näiteks 2012. aastal vastavalt 59% ja 41%. Viimastel aastatel on mitte-copyleft'iga litsentsid oma populaarsust märgatavalt kasvatanud ja suhe oli mullu (2020. aastal) 76%:24% mitte-copyleft'iga litsentside kasuks. Neist omakorda kaks - Apache 2.0 ja MIT on kasutusel üle pooltes (vastavalt 28% ja 26%) avavarades ning neile järgnevad copyleft'iga litsentsid GPLv3 ja GPLv2 (mõlemad kasutusel ca 10% avavarades) [5].

[1] https://choosealicense.com/no-permission/

[2] https://moqod.com/understanding-open-source-and-free-software-licensing/

[3] https://www.asapdevelopers.com/react-native-update-to-mit-license/

[4] https://resources.whitesourcesoftware.com/blog-whitesource/open-source-copyleft-licenses

[5] https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-trends-and-predictions