Litsentsimise kitsaskohtade juhtumipõhine uurimine

shorturl.at/cpqw0

Eellugu

Tarkvara algusaegadel, 1950ndatel ja 1960ndatel, toimus tarkvara arendus enamasti ülikoolide ja ettevõtete teadurite koostöös. Tavaliselt oli see avalikuks kasutuseks (public-domain software). Tarkvara ennast ei peetud tooteks ning lähtekoodi jagamine koos masinkoodiga oli pigem hea tava. Sellest perioodist on alguse saanud ka vaba tarkvara pooldavate häkkerite kultuur, kes vajadusel ja võimalusel omapoolseid täiendusi koodi lisavad.
Kuuekümnendate lõpul hakkas võrreldes riistvara hinnaga tarkvara tootmise hind kiiresti kasvama. Palju lisati arvutitesse tarkvara, mis kergitas niigi kõrget riistvara hinda. 1969. aastal toimus ka kohtuvaidlus Ameerika Ühendriikide valitsuse ja IBMi vahel, kus leiti selline tegevus konkurentsivastane olevat.
Pikka aega ei peetud tarkvara lähtekoodi autoriõigustega kaitstavaks. Aastal 1974 otsustati, et kuna tarkvara lähtekood kehastab autori algset loomingut, kuulub see ka autoriõigustega kaitstuks. Selle tõttu ei nähtud ka vajadust litsentsidel ning tarkvara jagati avalikuks kasutamiseks koos lähtekoodiga. Peale 1974. aasta otsust ja hilisemaid kohtuvaidlusi (nt Apple vs Franklin 1983) sai tarkvara samasugused autorikaitse tingimused nagu kirjanduslik teosel.

Apple Computers Inc. - Franklin Computer Corp.

Esmakordselt tekkis küsimus tarkvara lähtekoodi autoriõiguste üle 1982. aastal, kui Apple Computer Inc. alustas kohtuteed Franklin Computer Corp. vastu. Viimane oli tulnud turule Franklin Ace 1000 mudeliga, mis oli põhimõtteliselt Apple II kloon. Apple tuvastas kiirelt, et suur osa Franklini kasutatavast ROMist ja operatsioonisüsteemist oli kopeeritud nende versioonist.
Franklin tunnistas, et kopeeris Apple'i koodi, kuid nende arvates oleks ebapraktiline olnud uue koodi kirjutamine ning keeruline seejuures säilitada ühilduvust nii riistvara kui ka ülejäänud tarkvaraga. Franklini argumendiks oli veel autoriõiguste kehtimine ainult trükitud kujul koodile ning autoriõiguste mittekehtimine masinkoodile. Piirkonnakohus andis õiguse Franklinile. Apple kaebas otsuse edasi apellatsioonikohtusse ning juba kolm päeva hiljem tuli otsus, mis kinnitas nii inimesele loetava koodi kui ROM-ile paigaldatud masinkoodi autoriõigustega kaitstuks. Selle tulemusena oli Franklin sunnitud aastaks 1988 tagasi kutsuma kõik kloonid.
Peale Apple'i võitu Franklini üle hakkasid ka teised võitlema kopeerijate vastu, näiteks IBM oma BIOS kloonijate vastu.

EULA

Peale Apple-Franklin juhtumit said suurema hoo sisse shrink-wrap litsentsiga tarkvaratooted. Põhimõtteliselt on tegemist lõppkasutajale suunatud lepinguga, millega kasutaja nõustub pakendi avamisel. Hiljem hakati kasutama ka click-wrapped litsentse, mille puhul tingimusi kuvati alles tarkvara paigaldamisel ning siis oli vaja tingimustega nõustumiseks anda oma kinnitus ekraanil. Selliseid lõppkasutaja litsentse nimetatakse üldnimetusega EULA (End-user license agreement).
Erinevalt vaba tarkvara litsentsidest, mis on pigem autorikaitse seaduse laiendused, on EULA siduv leping.

EULA jõustumist on USA kohtud tõlgendanud erinevalt. Näiteks Klocek vs Gateway ja Brower vs Gateway juhtumite puhul. Mõlemal juhul osteti arvutikomplekt veebipoest ilma litsentsitingimustega tutvumata. Need lisati paberkandjal koos tootega. Tootega kaasa pakitud tingimustes oli toodud, et nendega mitte nõustumisel tuleb toode tagastada piiratud aja jooksul.
Broweri juhtumi puhul New York’i kohus otsustas, et litsentsitingimuste rakendumine oli ilmne, kuna klient ei tagastanud toodet 30 päeva jooksul. Kloceki puhul aga Kansase kohus otsustas, et kuna ostu toimumise hetkel tingimusi ei esitatud, siis kauba kättesaamise hetkeks oli tehing juba toimunud ning hilisemaid tingimusi peeti õigustühiseks.

Litsentside võidukäik

Seitsmekümnendatel ja kaheksakümnendatel hakkasid ettevõtted tarkvara eest pidevalt litsentsitasusid küsima, kasutades selleks siis järjest uusi vahendeid – autoriõigused, kaubamärgid, rendilepingud jne. Müügi kasvatamise eesmärgil ei lisatud toodetele kaasa ka lähtekoodi. Richard Stallman oli üks nendest inimestest, keda ettevõtete selline käitumine pahandas. Ta oli veendunud, et selliselt ei ole võimalik teiste kirjutatud programmidest õppida ja neid edasi arendada. Vastuseks korporatsioonidele lõi ta GNU projekti, mis lubaks inimestel tasuta tarkvara levitada. Stallmani töö tulemusena valmis ka GNU General Public License, mille põhjal omakorda on arenenud välja teised vaba tarkvara litsentsid.

Puuduva copyleftiga vaba tarkvara litsentsid

Vaba tarkvara on Free Software Foundationi (Vaba Tarkvara Sihtasutus, FSF) määratluse kohaselt tarkvara, mida saab ilma piiranguteta kasutada, kopeerida, uurida, muuta ja levitada. Järsult ja jõuliselt populaarsust koguval liikumisel ja selle läbi tekkinud arendustel muutus elutähtsaks võimalus ja kohustus neid õigusi säilitada ning nende levitamist ja levitamise õiguseid kindlustada. Suurimad avatud lähtekoodga ja puuduva copyleftiga ehk tuletistele mittenakkuvad litsentsid olid ja on siiani MIT, BSD ja Apache. Need litsentsid on vähepiiravad ning annavad võimaluse koodi muuta, edastada ning isegi omandada ja litsentseerida tuletist erineva litsentsiga. See loob soodsad tingimused ärimaastikule, kus erinevaid komponente ühendades saab luua tervikliku süsteemi, selle omandvaraks muuta ning selle eest raha küsida.

MIT litsents

Massachusettsi Tehnoloogiainstituudi (MIT) loodud litsents varajastel 80-ndatel tarkvara vabaks levitamiseks. Piirangud on väga minimaalsed ning nõue on vaid lisada litsentsi teatis projektiga kaasa. Tegemist on väga lühikese ja konkreetse tekstiga, mis on kergesti loetav ja arusaadav. Kitsaskoht on ilmnenud juhustel, kus koodis on kasutatud patenteeritud tehnoloogiat või koodi ning seda mainimata on siis arendust litsentseeritud. MIT ja BSD litsentsid loodi ajal kui tarkvara patendid polnud väga populaarsed ning selle vastu ei osatud end kaitsta. Selline olukord tekkis GraphQL puhul, kuna selle loomiseks kasutati GraphQL.js teeki, mis oli Facebooki poolt patenteeritud ja MIT litsentsiga litsentseeritud, jättes avatuks võimaluse Facebookil hiljem patendi üle kohtuvaidlust pidada. Sel viisil jätab MIT litsents oma kasutajad haavatavaks. Õnneks see olukord lahenes kiirelt, kui Facebook litsentseeris projekti ümber OWFa (Open Web Foundation Agreement) alla, mis vabastab igasugustest autoriõiguste või patentide piirangutest ja kohustustest.

BSD litsents

BSD litsents, sarnaselt MITile on väga väikeste piirangutega ning lubab uurimist, muutmist, levitamist, müümist ja muid tegevusi. Esimesest nelja klausliga BSD litsentsist eemaldati reklaamtekstide kasutamise kohustus. Mõni projekt on täpsustanud MIT ja BSD litsentse selgesõnalise patenditoetusega. Facebooki React oli aastatel 2014 kuni 2017 BSD litsentsi + eraldi patendilitsentsi all. Selle patenditoetuse tingimused soosisid ebaproportsionaalselt Facebooki ja muutsid kombineeritud litsentsi kokkusobimatuks paljude teiste avatud lähtekoodiga litsentsidega. Pärast mõnda aega kestnud survestamist kasutajate poolt litsentseeriti React ümber MIT alla, et neil poleks selget patendiõigust.

Apache litsents

Esimese Apache litsentsi 1.0 lõi Apache tarkvara fond 1995. aastal välja antud kuulsa Apache HTTP serveri jaoks. Litsents ise oli väga sarnane BSD 4 klausliga litsentsile, ainukeseks erinevuseks oli nõue, et tuletis ei kannaks Apache nime. 2000. aastal avalikustati Apache litsents 1.1, mille erinevus oli sarnaselt uuele BSD 3 klausliga litsentsile reklaamtekstide kasutamise kohustuse puudumine. 2004. aastal loodi täiesti uus BSD litsentsist erinev Apache litsents 2.0, mis on siiani aktiivselt kasutusel ning on üks populaarsemaid avatud lähtekoodiga litsentse maailmas.

Lubavad litsentsid nagu Apache koguvad viimastel aastatel tugevalt hoogu. Korraga kitsaskohana tunduv aspekt muutub samal ajal ka litsentsi tugevaks küljeks. Kui eesmärk on hoida koodi vaba ja kättesaadavana, on loomulikult õige tee GNU GPL, kuid sellega kaasnevad puudused. Inimesed ei pruugi tahta kasutada copyleft stiilis litsentsi, kuna see piirab mõnevõrra ärimudeleid. Kui tegemist on pisikese koodijupiga, mida soovid kasutada oma muidu suletud lähtekoodiga (ärilises) projektis, oled kohustatud jagama kogu oma koodi ja oled justkui nurka surutud. Apache aga lubabki kasutada koodi vabalt ning kasutada seda ärilistel eesmärkidel ning muuta vajadusel suletud lähtekoodiks. See kutsub rohkem inimesi seda kasutama, kasvatab populaarsust ning usaldusväärsust algse koodi looja suunas. Kitsaskoht ongi just nende arendajate suhtes, kes soovivad oma koodi võimalikult paljudele kättesaadavaks teha ning jäävad ilma tähelepanust, mida pärsib ärilisi eesmärke limiteeriv litsents.

Copyleft tüüpi vaba tarkvara litsentsid

GPL 2 vs GPL 3

GPL on vanim ja tõenäoliselt tuntuim vaba tarkvara litsents, mille algne versioon loodi juba 1989. aastal Richard Stallmani ja Vaba Tarkvara Fondi (FSF) poolt. GPLi teine pikalt turgu valitsenud versioon nimega GPL 2 tuli välja aastal 1991. Kuigi GPL litsentside üldine idee on anda kasutajale vabad käed GPL litsentsi all oleva tarkvara kopeerimiseks, uurimiseks, täiendamiseks ning levitamiseks, seejuures nakkuva copyleft tüüpi litsentsina laiendades need õigused ka kõikidele tuletistele, ilmnes GPL 2 litsentsi kasutamisel aastate jooksul erinevaid kitsaskohti, mille parandamiseks tuli 2007. aastal välja GPL 3.

GPL 2 litsentsi puudused

1. Patendidega seonduv / Novelli-Microsofti kokkulepe

2006. aastal teatasid Microsoft ja tarkvarafirma Novell omavahelisest koostööleppest, mis hõlmas muuhulgas kokkulepet, et Microsoft ei rakenda oma patente Novelli SUSE Linuxi kasutajatele, kuniks need kasutajad programmi edasi ei levita. Täpsemalt lubati üksteist patentidega seoses mitte kohtusse kaevata ning ka üksteise tooteid promoda. SUSE Linux kasutas GPL 2 litsentsi, mis nagu kõik GPL litsentside versioonid sätestas, et litsentsi all oleva tarkvara levitamisel laienevad tarkvara saajale samad õigused ehk muuhulgas ka õigus tarkvara edasi levitada. Kuna Microsoft lubas „kohtusse mitte kaevata“ üksnes Novelli kliente, siis nemad omakorda tarkvara tegelikkuses vabalt levitada ei saanud - sellega lootis Microsoft nn kaudset patendimaksu koguda. GPL 3 üks kaasautoritest, FSFi jurist Eben Moglen ütles: "If you make deals with a party having patents, to pay tribute to that party, in return for protecting some but not all of your customers... you are violating the license, and you must stop distributing altogether." Just Novelli-Microsofti kokkulepe oli peamiseks tõukeks, miks GPL 3 litsentsitingimustesse lisati klauslid, mis keelavad GPL 3 all leviva tarkvara kasutajal tegemast selliseid patentidega seotud kokkuleppeid, mis piiravad (osade) teiste tarkvara kasutajate vabadusi - selle vastu eksija kaotab ise tarkvara kasutusõigused.

2. DRM / TiVo juhtum

Tivo Inc, USA firma, mille number 1 toode oli TiVo digitaalne meediamängija, kasutas oma süsteemis GPL 2 litsentsi all olnud Linuxit. Näiliselt järgis TiVo küll GPLi nõudeid, andes kasutajatele ligipääsu lähtekoodile ning võimaluse tarkvara muuta, kuid seda muudetud tarkvara DRM piirangute tõttu TiVo riistvaral jooksutada ei õnnestunud. Olukorda, kus GPLi all leviva tarkvara muudetud vorme ei ole võimalik DRMi või mingite riistvara piirangute tõttu esialgses süsteemis kasutada, hakati kutsuma tivoiseerimiseks. Tivoiseerimise vältimiseks tulevikus lisas FSF GPLi kolmandasse versiooni klausli, mis sätestab nn installeerimise informatsiooni (autoriseerimisvõtmed jms info, mis on vajalik muudetud GPLi all oleva tarkvara käivitamiseks ja kasutamiseks) andmise nõude tulevastele „tivodele“.

3. Tingimused on hägusad ja teist võimalust ei anta / Patrick McHardy alusetult rikastumas

GPL 2 litsentsi tingimusi on peetud kohati mitmetimõistetavaks ja ebaselgeks (nt dünaamiliselt vs staatiliselt lingitud teekide kuuluvus GPLi alla jpm), mistõttu rikkumise olemasolu või selle puudumine võib olla vaataja/lugeja/kohtumõistja silmades. Kuigi GPL 3 püüdis võrreldes GPL 2 litsentsiga oma tingimusi ühetimõistetavamalt kirja panna, võrdles Van Lindeberg veel oma 2008. aastal ilmunud raamatus “Intellectual Property and Open Source: A Practical Guide to Protecting Code” inimeste suhtumist GPL litsentsidesse suhtumisega AIDSi 1980. aastatel - kuna oli ebaselge, kuidas suhtutav nakkub, levis palju desinformatsiooni ja liialdusi.

Teisalt aga sätestab GPL 2 üheseltmõistetavalt, et tarkvara kasutaja kaotab litsentsi tingimuste rikkumisel automaatselt tarkvara kasutamise õigused. Säärane teise võimaluse mitteandmine GPL 2 puhul andis võimaluse karistada teadmatusest rikkujaid liiga karmilt ega mõjunud soodustavalt inimeste soovile GPL 2 all olevat tarkvara kasutada või selle all olevat koodi omalt poolt edasi arendada. Samuti ei teeninud teise võimaluse mitteandmine eesmärki panna inimesi litsentsitingimusi järgima, vaid hoopis andis isikliku põhjendamatu finantsilise kasu saamise võimaluse näiteks arendaja Patrick McHardyle, kes aastate jooksul kümneid rikkujaid kohtusse kaebas ja sellega miljoneid eurosid võitis. Nimelt oli McHardy seotud väikese osa GPL 2 all oleva Linuxi tuuma koodi loomisega, mis andis talle võimaluse GPL 2 litsentsitingimuste rikkujad otse oma nime alt kohtusse kaevata ja neilt raha nõuda (selle asemel, et pöörduda FSF vms organisatsiooni pole, kes väidetavat rikkujat noomiks ja õigele teele püüaks suunata). Muuhulgas esitas McHardy mitmeid tegelikkuses põhjendamata kohtunõudeid ka GPL 2 mitmetimõistatavatele kohtadele toetudes. Linux kaebas McHardy lõpuks ise kohtusse, saamata lubada, et firmad loobuvad oma toodetes Linuxi koodi kasutamisest suvalise programmeerija kohtunõuete kartuses. GPL 3 litsentsile lisati aga nn ümberkasvatamisklausel, mis annab esmakordsele litsentsitingimuste rikkujale võimaluse patud olenevalt olukorrast 30 või 60 päeva jooksul heastada.

4. Mitteühilduvus / Apache litsents 2.0

GPL 2 probleemiks oli muuhulgas ka mitteühilduvus paljude teiste vaba tarkvara litsentsidega (Apache 2.0 litsents, algne Mozilla Avalik Litsents (MPL) jt), mis välistas GPLi all oleva tarkvara miksimise mitmete muude litsentside all oleva tarkvaraga. Ühilduvuse parandamiseks teiste vaba tarkvara litsentsidega (millest ühe peamisena toodi välja Apache 2.0 tarkvaralitsents) viidi GPL 3 tingimustesse muudatusi, kuid probleemid ühilduvusega jätkusid ka GPL 3 puhul (vt täpsemalt edasi).

GPL 3 litsentsi puudused

1. Ühepoolne ühilduvus / Apache litsents 2.0

Apache 2.0 litsents, mis GPL 2-ga ei ühildunud üldse, GPL 3-ga küll justkui ühildub, kuid ühepoolselt. Nimelt kuna GPL 3 on piiravam litsents kui Apache 2.0, siis Apache litsentsi all olevat tarkvara saab kasutada üleüldiselt GPL 3 litsentsi all oleva tarkvara osana, vastupidi aga mitte. Probleem tekib nimelt juhul, kui muidu Apache 2.0 all olev projekt tahab kasutada GPL 3-ga litsentsitud tarkvara, sest ASF (Apache Tarkvara Fond) näeb ette, et Apache tarkvara peab olema Apache 2.0 litsentsi all, GPL 3 nakkuva litsentsina nõuab aga, et kogu projekt, kus kasvõi tükike GPL 3 sees on, oleks GPL 3 all. Ühilduvus toimib ainult siis, kui muidu GPL 3 litsentsi kasutav tarkvara tahab oma alamosana kasutada mingit Apache 2.0 litsensi all olevat tarkvara - siis saab kogu kombineeritud tarkvara kenasti levitada GPL 3 all (samas Apache 2.0 all olevale koodijupile Apache litsents kehtib endiselt, kuna GPL 3 nõuetega konflikti ei teki).

2. GPL 2 ja GPL 3 omavaheline ühilduvus / LibreDWG, LibreCAD ja FreeCAD hädas

Kui tahta GPL 2-ga litsentsitud koodi kombineerida GPL 3 litsentsi all oleva koodiga, on seda võimalik teha ainult juhul, kui antud GPL 2 versioon sisaldab klauslit, et seda tarkvara on võimalik kasutada GPL 2 või hilisema GPL litsentsi tingimustel (mis juhul saab kogu kombineeritud tarkvara kasutada hilisema litsentsi ehk GPL 3 tingimustel). Kui GPL 2 all olevat tarkvara saab aga litsentsiklausli järgi kasutada ainult GPL 2 litsentsi tingimustel (nt Linuxi tuum), siis seda tarkvara GPL 3 all oleva tarkvaraga ühildada ei saa. Üks enam kõneainet saanud juhtusid siinkohal on olnud GPL 2 litsentsi kasutanud GNU LibDWG teegil põhinev DWG failide lugemiseks mõeldud LibreDWG teek, mis GPL 3 litsentsi alla minnes ei ühildunud enam GPL 2 litsentsi all olnud LibreCADi ja FreeCADiga. Kuna nii LibreDWG, LibreCAD kui ka FreeCAD olid oma litsentsivalikul seotud teiste projektidega, ei olnud neil niisama lihtsalt võimalik ka litsentsitüüpi muuta, kuigi vastav palve LibreDWG viimiseks GPL 2 alla FSFile tehti. Kuna FSF keeldus LibreDWG litsentsi downgrade’imisest, siis DWG failide lugemise võimaluse taastamiseks arendas LibreCAD lõpuks enda libdxfrw teegi, FreeCAD aga hakkas vaba tarkvara asemel esialgu kasutama omandvara (sic!), aastaid hiljem sai ta aga üle minna LGPL litsentsile.

Oracle juhtumid

Väga mitmekülgseid õpetlikke tahke pakub ORACLE litsentsimisega seotud teemade uurimine.

ZFS ja Linux

Esmalt vaatame mitteühilduvust ZFS ja Linuxi näitel. ZFS on failisüsteem , mida väga soovitakse koos Linuxiga levitada. Ent Linux on GPLv2 litsentsi all ja ZFS on levitatud CDDLv1 (nõrk copyleft) litsentsi all. Mõlemad litsentsid nõuavad, et vastav kombinatsioon oleks levitatav sama litsentsiga, mille alla varem komponent kuulus (Linuxi puhul GPLv2 ja ZFS puhul CDDLv1). See mitteühilduvus oleks lahendatav, kui Oracle tuleks vastu nagu Facebook ja muudaks ZFS litsentsitüüpi nt GLPv2ks. Ent Oracle ei ole siiani vastutulelikuks muutunud. See-eest otsustasid osad arendused asja oma kätesse võtta: 2016. aastal lubas Canonical Ubuntu 16.04 LTS kasutajatel installeerida OpenZFS paketi otse Ubuntu repositooriumi alt . See on nii GPL kui ka CDDLv1 litsentsi rikkumine. Ka mitmed Linuxi poolel asuvad (nt software freedom conservancy) kommuuni liikmed arvavad, et nii ei ole legaalne teha . Siiani aga ei ole neid selle eest kohtusse kaevatud.

OpenOffice ja LibreOffice

Teiseks vaatleme litsentide ühesuunalise ühilduvuse näidet OpenOffice.org näitel. Open Office sai alguse 2000. aastal avatud lähtekoodiga LGPL litsentsiga konkurendiks Microsofti kontoritarkvarale. 2010. aastal sai Oracle Suni ära ostes Open Office'i endale. Olles pettunud ja umbusaldades Oracle plaani Open Office'it edasi arendada, otsustasid selle arendajad 2011. aastal hargneva arenduse teha, mille ristisid LibreOffice'iks. Oracle lahja huvi tõenduseks on ettevõtte OpenOffice'i annetamine Apache Software Foundationile 2011. aastal, misjärel seda levitatakse Apache litsentsi all. Enamik vabatahtlikke kommuuniliikmeid läks LibreOffice'i alla kaasa, mistõttu on oodata, et OpenOffice'i arendus on aeglasem kui LibreOffice'i oma, kuigi hetkel on nad veel üsna samaväärsed.

Huvitav on aga lugu litsentsidega. OpenOffice'i Apache litsents võimaldab LibreOffice'il võtta paremaid osi OpenOffice'ist ja need seaduslikult LibreOffice'isse kaasata. Ent LibreOffice'i levitatakse topeltlitsentsiga LGPLv3 / MPL all , mis ei luba OpenOffice'il võtta LibreOffice'i komponente. Tulemuseks on naljakas olukord, kus LibreOffice saab kõike head OpenOffice'ist võtta ja seda veelgi paremaks teha ning omab seetõttu märkimsväärset eelist arendusel.

MySQL topeltlitsents

Rääkides topeltlitsentsidest on huvitavaks edukaks näiteks MySQL . See arendati 1995. aastal MySQLABi poolt (David Axmark, Allan Larsson ja Michael "Monty" Widenius poolt) ning anti avalikkusele kasutamiseks avatud lähtekoodiga vabavara litsentsiga. MySQL omandati Sun'i poolt ning lõpetas lõpuks Oracle all. Ent MySQLi ei pandud kommertsiaalse litsentsi luku taha, vaid Oracle otsustas ära kasutada arendajate kommuuni tuge, pakkudes MySQLi edasi GPLv2 litsentsi all, mis lubab kasutada oma litsentsi kommertsarenduses, ent ei luba muuta ja edasi levitada , sel juhul peab teise ärilise tasulise litsentsi muretsema. Selle jaoks pakub Oracle MySQLi ka erinevate kommertsiaalsete litsentside all, millega kaasnevad ettevõte tugiteenused, suurem usaldusväärsus ja mitmed väga kasulikud MySQLi peale ehitatud lisateenused, nagu andmebaasi toimimise jälgitavus, turvalisus jne . Kuid kui MySQL näitel selline topeltlitsents tundub hästi toimivat, siis alati ei pruugi asjad nii lihtsad olla. Topeltlitsentsi puhul on vajalik litsentsi muretsejal endale hästi selgeks teha, mida tohib ja ei tohi vastavate litsentide all teha. Kui see ei ole selge, siis on jama majas. Omamoodi märgiline näitaja on ka MySQLi ühe asutaja Wideniuse samm samal päeval kui Oracle MySQLi omandas: luua eraldiseisev MySQLi GPL litsentsiga arendusharu, mille ta ristis MariaDB-ks , et "päästa MySQL".

Oracle kurikuulus auditeerimine

Oracle näitel on kurikuulsad Oracle audiitorite külaskäigud, mis justkui pakuvad abi ettevõttete litsentsikäitumise kontrollimisel ja parandamisel, kuid tunduvad tihti lõppevat jõupositsioonilt enda kasuks sobilike lisateenuste pähemäärimisega, eriti alatu näide on Oracle vs AFPA and Sopra Steria Group. Oracle Prantsusmaa selge solgiga üritati ettevõtetele pähe määrida litsentsi mittevastavus. Ent see lõppes Oracle poolt 2 x 100000 EUR kahjutasuga . Nt tõlgendab Oracle oma toote kasutamist väga oma nime vääriliselt, justkui oraakel, kes tulevikku ette näeb. Kui kasutajad kasutavad virtualiseerimist või mitmeid servereid oma äritegevuses, siis Oracle võib vabalt nõuda, et tuleb litsents muretseda iga üksiku tuuma ja protsessori peale, kuhu virtuaalne server „võib potentsiaalselt sattuda“ . Samuti peaks muretsema selle pärast, millised kasutajad võivad Oracle tootele ligi pääseda, isegi kui neid ei kasuta, ning muretsema ka nendele juhtumitele litsentsid.

Väga ilmekas on Oracle vs. Mars juhtum , kus Mars otsustas Oracle sellise käitumise vastu kohtusse astuda. Umbes aasta jagu kestnud vaidlus lahenes ühtäkki väga kiirelt paari nädalaga, justkui oleks Oraclel olnud hirm testida oma litsentsirikkumise tõlgendamise õigsust seadusliku kohtupraktika poolt.

Oracle vs Google

Oracle vs Google (https://tinyurl.com/ycuxc6wy)

Siin on hea õppetund, et litsentside puhul tuleb juba ennetavalt osata õigeid küsimusi küsida. Üks keerukamaid lugusid on aga juhtum, kui küsimust küll küsitakse, kuid keegi vastust ei tea. Google soovis 2005. aastal Androidi arendusel Java APIsid kasutada, mille litsentsi tal polnud . Google väidab, et lõppkokkuvõttes polnudki tal litsentsi vaja, Oracle väidab, et sama API ümberkirjutamine on nende õiguste rikkumine, kuna Google ei omanud litsentsi. Väga lihtsustatult on küsimus selles, et Java on avatud lähtekoodiga programmeerimiskeel. Ent Java APIde intellektuaalsed õigused kuuluvad Oraclele. Google ei omanud litsentsi nende komponentide ümberkirjutamiseks Androidi arendamisel.

Kui Oracle omandas Suni, kaebas ta Google koheselt selle rikkumise eest kohtusse. Ent küsimusele pole olnud ühest vastust. Ühed kohtuastmed leidsid, et API litsentseerimine on jabur ning oluliselt mõjutaks tarkvara kirjutamise vabadust, teised leiavad, et koodi kindel struktuur ja funktsioneerimine on litsentseeritav samamoodi nagu ilukirjandus. Suuresti tuleb see häda sellest, et USA autoriõiguse seadus on väga hästi arendatud justnimelt selliste ilukirjanduslike teoste kaitseks, kuid tarkvarale see seadus hästi ei kohaldu. Ent seadust väga huupi muuta ei saa. Nüüd, 2020. aastaks, on juhtum jõudnud Ameerika Ühendriikide Ülemkohtusse , mis oleks pidanud tuleval suvel antud küsimuses otsusele jõudma. Ent aasta alguses tabas maailma suuremat sorti eriolukord COVID19 levikuga seoses, mistõttu antud juhtumi lahenemine lükkub edasi 2021. aastasse.

Interneti mõju tarkvaralitsentsidele

Interneti tulek 90ndate alguses ning selle edasine kiire areng on tarkvaramaailma tugevalt mõjutanud. Veebirakenduste arhitektuur ning platvormid erinevad olulisel määral desktop ning tavapärase kliendi-serveri rakenduste omast. Enne interneti ajaarvamist pidi tarkvara kasutajani jõudma füüsilise andmekandja näol, oli selleks siis diskett, CD vms. Tänu internetile on firmadel võimalik oma tooteid lihtsamini turundada ning toetada, lisaks on paljuski muutunud tarkvaratoode kui selline. Enam ei ole sageli vajalik tarkvara installeerimine, vaid seda saab kasutada pilveteenusena (SaaS - Software as a Service). Lisaks on internet endaga kaasa toonud mõisted telefonirakendus ja FOSS (free and open source software). Järgnevalt vaatleme, mil moel on internetiga kaasnenud uudsed tarkvaralahendused litsentsimise maailma muutnud.

IoT ehk Internet of Things

Internet of Things (https://semielectronics.com/wp-content/uploads/2017/08/Sensors-for-IoT.jpg)

Oleme harjunud olukorraga, et tarkvara litsents on seotud kasutajaga, see tähendab, et makstakse litsentsitasu tarkvara kasutamise eest. Litsents võib olla seotud ka seadmega, mida kasutaja kasutab. Siia alla kuuluvad näiteks juba seadme sees olevad litsentsid (embedded licenses), näiteks arvuti operatsioonisüsteemiga Microsoft Windows. Kuigi selline litsentsitüüp ei ole viimase aja leiutis, muutub see asjade maailmas (IoT) üldlevinuks.

IoT tähendab internetivõrku, milles omavahel seotud seadmed suudavad sensorite abil andmeid koguda ning seda infot omavahel vahetada. Andmete liigutamiseks vajavad seadmed tarkvara, seega tulevad mängu litsentsid.

Kõige paremini kasutatav litsentsitüüp on siin varem nimetatud seadme sees olev litsents. Selliselt on võimalik omada ülevaadet seadmel parasjagu olevast tarkvara versioonist, mis teeb tarkvara uuendamise protsessi kasutaja jaoks võimalikult valutuks. Taoliste litsentside kasutamine nõuab firmadelt investeeringuid litsentside jagamise haldussüsteemidesse (LAM - License Allocation Management) selleks, et mitte kaotada potentsiaalset sissetulekut. Nimelt võib juhtuda, et kasutajal on ligipääs litsentsi võimalustele, mille eest ta tegelikult tasunud ei ole. Taolist olukorda nimetatakse litsentsi kooskõla lekkeks (breach of compliance).

FOSS - free and open source software

Antud pealkirja alla koonduvad näiteks MIT, GPL, Apache ja BSD litsentsid.

Tavaliselt sisaldavad FOSS litsentsid väga tugevaid lahtiütlemise klausleid vabastades nii autori igasugustest kohustustest ja vastutusest. Selle põhjuseks on sageli üpris proosaline asjaolu - vaba tarkvara antakse tasuta kasutamiseks, mistõttu tarkvara autor ei pruugi omada piisavat sissetulekut maksmaks kinni võimalikke vastutusega ning õiguslikkusega seotud kulusid. On väga keeruline põhjendada lepingujärgset kohustust tuginedes ainult FOSS litsentsile. Tüüpilised seda tüüpi litsentsid ei kohusta tarkvara nii öelda kätte toimetama, vaid annavad pelgalt tingimused selle kasutamiseks. Tasulise tarkvara litsentsid seevastu sätestavad teatud seaduslikud nõuded tarkvara kvaliteedile. Võib olla, et tarkvara tootja ja selle kasutaja vahel on tehtud lisaks eraldi kokkuleppeid (näiteks võimalike vigade kohta tootes).

Üldistatult võib seega öelda, et ühest küljest annavad FOSS litsentsid kasutajatele omajagu vabadust, kuid teisalt ei paku mingit kasutajatuge. Kogu vastutus antakse edasi.

SaaS ja GPL

SaaS ehk Software as a Service näol on tegemist tarkvaraga, mida pakutakse teenusena interneti kaudu. See tähendab, et tarbija ei pea rakendust oma arvutisse installeerima, vaid rendib seda pakkujalt. Üheks plussiks säärase tarkvara puhul on selle hooldus. Mõned tuntumad nimed siin valdkonnas on Google Apps, Salesforce, Dropbox, MailChimp, Slack, Hubspot.

Vaba tarkvara litsentsis GPL on oluliseks märksõnaks tarkvara levitamine. See tegevus on kõikide litsentsipiirangute aluseks. See tähendab, kui mingi tarkvara on loodud GPL litsentsiga kaetud tarkvara põhjale, siis selle levitamine on samuti koheselt GPL-iga kaetud. Seega peab tarkvara lähtekood olema automaatselt avatud ning seda võib edaspidigi muuta ja edasi jagada. Vaba tarkvara kogukond märkas koheselt, et GPL litsentsis on kitsaskoht, mis lubab SaaS firmadel kasutada GPL litsentsiga kaetud tarkvara, kuid seejärel saavad litsentsi nõuetest ise kõrvale hiilida. Kuna Saas tüüpi tarkvara ei levitata, vaid kasutajad lihtsalt kasutavad seda, siis ei rakendu antud tarkvarale GPL litsents ning koodi ei pea seetõttu avalikustama.

Nimetatud kitsaskoha õmbles kinni litsents nimega AGPL (Affero General Public License), mis on aastal 2002 loodud ning litsentsil GPL2 põhinev vaba tarkvara litsents. Teine versioon AGPL-ist avaldati aastal 2007. AGPL kohustab lähtekoodi avalikustama ja teistele kasutamiseks lubama juhul, kui selles kasutatakse AGPL litsentsiga komponente ning tarkvara kasutatakse serveris, mis on võrguga ühendatud. Seega oluline erinevus GPL-i ja AGPL-i vahel on litsentsi rakendumiseks vajalik eeldus - esimesel juhul on selleks tarkvara levitamine, teisel juhul juba pelgalt koodi muutmine, mis katabki ära ka SaaS tüüpi tarkvara kitsaskoha.

Palju segadust ning ilmselt juriidilisi vaidlusi saab siinkohal tekitada mõiste "levitamine" tõttu. Mis üldse on tarkvara levitamine? Juhul, kui tarkvara ei levitata, siis ei pea seda ka vastavalt GPL-iga litsentsima. GPL loeb koodi levitamiseks näiteks javascripti saatmist brauserisse. Leida sellist SaaS projekti, mis oleks täielikult javascripti vaba, on üsna keeruline. Sellegipoolest võib seda juhtuda ning siinkohal tulebki mängu AGPL-i tarvilikkus.

Kokkuvõtteks

Litsentside maailm on väga lai. Tegemist on seadustega ning terav silm leiab alati seadustes auke. See on võimaldanud algatada tarkvaraga seonduvaid omandivaidlusi minevikus ning küllap tuleb neid ka tulevikus.