Litsentsimise kitsaskohtade juhtumipõhine uurimine

Avatud lähtekoodiga tarkvara litsentsid

Avatud lähtekoodiga litsentsid tekkisid vajadusest anda luba kasutajale koodi näha ja muuta, samal ajal vabastades koodi autorit erinevatest kohustustest ning andes edasi kohustuse koodi autorit tunnustada tuletistes. Esimesed suurimad avatud lähtekoodi litsentsi tüübid olid ja siiani on MIT, BSD ja Apache. Need litsentsid on vähepiiravad ning annavad võimaluse koodi muuta, edastada ning isegi omandada ja litsentseerida tuletist erineva litsentsiga, jälgides algse litsentsi nõudeid. See loob soodasd tingimused ärimaastikule, kus erinevaid komponente ühendades saab luua tervikliku süsteemi, selle omandvaraks muuta ning selle eest raha küsida. Sellise käitumise vastu võitleb Vaba Tarkvara Fond ehk FSF, millest juttu allpool. Eelnevalt veetleme lubavaid tarkvara litsentse Apache, MIT ja BSD.

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 kluasliga 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. 2005 aastal loodi täiesti uus BSD litsentsist erinev Apache litsents 2.0, mis on kasutusel aktiivselt siiani ning on üks populaarsemaid avatud lähtekloodi litsentse maailmas.^[1]

MIT litsents

TBA

BSD litsents

TBA

Vaba tarkvara litsentsid

GPL 2 vs GPL 3

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. Lisaks, kõigile kasutajatele kasutusvõimaluste põhiõigused säilitada.

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. ^[2] 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." ^[3] 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.^[4]^[5]

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“. ^[6]^[7]^[8]

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. ^[9] 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. ^[10] 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. ^[11] 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. ^[12] 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. ^[13]

4. Mitteühilduvus / Apache’i 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’i 2.0 tarkvaralitsents) ^[14] viidi GPL 3 tingimustesse muudatusi, kuid probleemid ühilduvusega jätkusid ka GPL 3 puhul (vt täpsemalt edasi).^[15]

GPL 3 litsentsi puudused

1. Ühepoolne ühilduvus / Apache’i litsents 2.0

Apache 2.0 litsents, mis GPL 2ga ei ühildunud üldse, GPL 3ga küll ühildub, kuid ühepoolselt. Nimelt kuna GPL 3 on piiravam litsents kui Apache 2.0, siis Apache’iga litsentsitud tarkvara saab kasutada üleüldiselt GPL 3 litsentsi all oleva tarkvara osana, vastupidi aga mitte. Probleem tekib nimelt juhul, kui muidu Apache’i 2.0 all olev projekt tahab kasutada GPL 3ga litsentsitud tarkvara, sest ASF (Apache’i Tarkvara Fond) näeb ette, et Apache’i 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’i 2.0 all olevale koodijupile Apache’i litsents kehtib endiselt, kuna GPL 3 nõuetega konflikti ei teki). ^[16] ^[17]

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

Kui tahta GPL 2ga 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. ^[18] 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. ^[19] ^[20] 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. ^[21]

Asko osa: Oracle

Mingi alapealkiri

PEAAEGU VALMIS ... alustama sellega!

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 telefoni rakendus ja FOSS (free and open source software). Järgnevalt vaatleme, mil moel on internetiga kaasnenud uudsed tarkvaralahendused litsentsimise maailma muutnud. ^[22]

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 leitus, 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). ^[23]

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). ^[24]

Ü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 siinohal tulebki mängu AGPL-i tarvilikkus. ^[25]

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.

Viited

[1] ttps://resources.whitesourcesoftware.com/blog-whitesource/top-10-apache-license-questions-answered

[2] ttps://www.infoworld.com/article/2634150/microsoft-novell-deal-violates-gpl-.html

[3] ttps://www.theregister.co.uk/2007/05/18/gpl_microsoft_novell/

[4] ttps://www.crn.com/news/applications-os/198700743/new-gpl-3-draft-takes-aim-at-microsoft-novell-pact.htm

[5] ttps://timreview.ca/article/106

[6] ttps://timreview.ca/article/106

[7] ttps://www.gnu.org/licenses/gpl-3.0.html

[8] ttp://gplv3.fsf.org/rms-why.html

[9] ttps://santaclaralawtechlawforum.wordpress.com/2015/10/12/gpl-3-overview/

[10] ttps://www.theregister.co.uk/2018/06/18/red_hat_gpl_violation/

[11] ttps://www.theregister.co.uk/2017/10/18/linux_kernel_community_enforcement_statement/

[12] ttps://www.zdnet.com/article/linux-beats-internal-legal-threat/

[13] ttps://www.gnu.org/licenses/gpl-3.0.html

[14] ttps://www.ifross.org/en/what-difference-between-gplv2-and-gplv3

[15] ttps://www.fsf.org/news/gpl3dd4-released

[16] ttps://www.apache.org/licenses/GPL-compatibility.html

[17] ttps://www.zdnet.com/article/gplv3-myth2-you-cant-mix-gpl-software-with-other-software

[18] ttps://savannah.gnu.org/projects/libredwg/

[19] ttps://web.archive.org/web/20161109103037/http://libregraphicsworld.org/blog/entry/whats-up-with-dwg-adoption-in-free-software

[20] ttp://libregraphicsworld.org/blog/entry/libredwg-controversy-2-months-later

[21] ttp://libregraphicsworld.org/blog/entry/libredwg-revived-starts-getting-regular-releases

[22] ttps://link.springer.com/content/pdf/10.1007/s13174-011-0019-x.pdf

[23] ttps://openlm.com/blog/how-the-internet-of-things-has-changed-software-licensing/

[24] ttps://www.europarl.europa.eu/document/activities/cont/201307/20130708ATT69346/20130708ATT69346EN.pdf

[25] ttps://resources.whitesourcesoftware.com/blog-whitesource/the-saas-loophole-in-gpl-open-source-licenses

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]