Sekėjai

Ieškoti šiame dienoraštyje

2022 m. rugsėjo 4 d., sekmadienis

„Open Source Software“: galvos skausmas ir pirkėjui, ir pardavėjui. Ką daryti?

“Šiam tekstui taikoma GPL3 licencija. Nuo 2017 m. pajamos iš atvirojo kodo programinės įrangos (angl. Open Source Software, OSS) paslaugų bemaž patrigubėjo ir 2022 m., planuojama, viršys 32 mlrd. USD. Daug. O augimas dar įspūdingesnis. Bet aš ne apie tai rašysiu.

Aš noriu pasidalinti savo patirtimi apie:

Kas tas OSS?

Ką jis reiškia pardavėjui?

Ką jis reiškia pirkėjui?

Ką daryti, kad būtų gerai?

Pradėkime nuo pradžių. Ar tikrai ta OSS tokia „atvira“?

 

I. Kas yra OSS?

OSS, o lietuviškai atviroji programinė įranga, tai tokios kompiuterių programos (KP), kurių kūrėjai nusprendė jas licencijuoti pagal vadinamąsias atvirąsias licencijas. Nesigilinsim, kodėl jie taip pasirinko, nes nukryptumėme į ezoteriką.

 

Atvirosiomis licencijomis vadinamos tokios, kurios leidžia KP laisvai (tačiau nebūtinai nemokamai) platinti, modifikuoti ir atgaminti (platesnį OSS aprašymą ir apibrėžimą rasite čia: https://opensource.org/docs/osd).

 

Atvirosios licencijos dalijasi į dvi kategorijas: „liberalios“ (angl. permissive) ir „copyleft“ licencijos. Pirmosios nereikalauja, kad savo KP, į kurią įterpėte OSS, licencijuotumėte pagal tą pačia atvirąją licenciją ir leidžia pasirinkti, kaip licencijuosite. Pavyzdžiui, „Apache 2.0“ licencijoje nurodyta, kad prie modifikacijų galite pridėti „savo autorių teisių pareiškimą ir gali būti pateiktos papildomos arba kitokios licencijos sąlygos“.

 

Visai kitaip yra su „copyleft“ tipo atvirosiomis licencijomis – jos reikalauja, kad ir savo KP, į kurią įterpėte OSS (dažnai naudosiu tekste šią formuluotę, tad nuo šiol rašysiu tiesiog „savo KP“, o jūs supraskite, kad kalbu apie tokią jūsų KP, į kurią jūs įterpėte OSS), licencijuotumėte pagal atvirąją licenciją, paprastai tą pačią, kuria buvo licencijuota įterptoji KP.

 

Painu, bet štai pavyzdys: jūs kuriate apps‘ą ir internete suradote puikiai jums tinkantį login‘o modulį, kuris licencijuotas pagal GPL3 licenciją. Jūs nebenorite nuo nulio kurti login‘o modulio ir į savo kuriamą apps‘ą įterpėte rastąjį kodą.

 

Viskas veikia puikiai, džiaugiatės sutaupę nemažai laiko. Tačiau tokiu atveju visą savo sukurtą apps‘ą jūs privalote licencijuoti pagal GPL3. Jūs jau nebegalėsite pasirinkti kitokių licencijavimo sąlygų. Ką tai reiškia jums, paskaitykite žemiau.

 

Taigi, „permissive“ ir „copyleft“ tipo atvirosios licencijos. Apie pirmąsias daug nebekalbėsiu, nes ne jos, o būtent „copyleft‘inės“ kelia teisines ir praktines problemas.

 

Ką gi reiškia, jog savo parašytą super apps‘ą jūs turėsite licencijuoti pagal tą pačią atvirąją GPL3? Svarbiausias dalykas, ką tai reiškia jums, yra tas, jog jūs privalėsite atskleisti apps‘o išeities (angl. source) kodą kiekvienam, kas to pageidaus. Aha, tikrai.

 

 

Nuo to momento, kai pradėsite platinti savo apps‘ą, kiekvienas asmuo galės pareikalauti jam pateikti apps‘o source kodą. Nes taip sako GPL3, kurią jūs privalėsite taikyti, nes jūs panaudojote pagal GPL3 licencijuotą login‘o modulį savo apps‘e.

 

Tai ir yra „copyleft“ spąstai, į kuriuos nei KP gamintojas, nei pirkėjas paprastai nenori patekti. Kodėl nenori? Ogi todėl, kad atskleidus KP source kodą visi sužinos, kaip veikia jūsų KP, kas gali būti labai nepriimtina dėl daugelio priežasčių: saugumo, konkurencinio pranašumo praradimo, kainos nustatymo, etc.

 

Jei jums nebaisu, kad jūsų KP kodas bus viešas, viskas tvarkoje, drąsiai naudokite GPL3 ar kitas panašias „virusines“ sąlygas turinčias „copyleft“ licencijas. Tačiau jei savo paslapčių išduoti nenorėtumėte, su „copyleft‘inėmis“ licencijomis reikia elgtis apdairiai.

 

II. Ką daryti KP gamintojui?

Įsivaizduokite, jūs vadovaujate įmonei, kuri klientų užsakymu specialiai jiems kuria KP. Jūsų komandoje dirba 26 programuotojai, kurie dieną-naktį triūsia, kodina pagal su klientu suderintą specifikaciją.

 

Terminai spaudžia, ir vienas developeris nusprendžia nebeišradinėti dviračio, o įterpti į kuriamą KP iš interneto atsisiųstą modulį, kurio kūrėjas jį licencijuoja pagal GPL3. Jūs galite net nesužinoti, kad toks svetimas kodas buvo įterptas į kuriamą KP.

 

 

Projektą sėkmingai pabaigėte, pridavėte KP klientui, gavote pinigus, išleidote. O neužilgo klientas gauna pretenziją iš Uwe (37 metai, Vokietija), pagal GPL3 licencijuoto modulio kūrėjo, kuris kelia bangas ir reikalauja atskleisti visos kliento naudojamos KP kodą viešai.

 

Klientas grįžta pas jus susijaudinęs ir piktas, nes toks atskleidimas reikštų, jog jo konkurentai sužinotų KP veikimo principus ir kliento konkurencinis pranašumas čiuožtų žemyn. O klientas turėjo prakutusius teisinius patarėjus, kurie į sutartį su jumis įrašė gudrius žodžius, kuriais jūs įsipareigojote, kad jokio OSS klientui kuriamoje KP nebus. Ką darote jūs? Einate su lagaminėliu grynų pas Uwe ir prašote nebekelti bangų...

 

Ši situacija gal kiek ir utriruota, tačiau neišgalvota. Ką gi daryti, kad to lagaminėlio Uwei nešti nereikėtų? Visų pirma, jūs turite žinoti, kaip dirba jūsų komanda, o ji turi žinoti, galima ar negalima naudoti trečiųjų asmenų sukurtą KP. Įskaitant ir OSS. Nesakau, kad reikia drausti, nes tai nepraktiška. Tačiau reikia įmonės viduje nustatyti taisykles:

 

Kokia tvarka tai daroma;

kokios licencijos jums yra priimtinos (pvz. „liberaliosios“);

kaip priimami sprendimai, kokį trečiųjų asmenų kodą įterpti;

kaip ta informacija pasiekia jus.

Minimaliai turi būti užtikrinta, kad jūs bent jau žinotumėte, jog klientui kuriamoje KP yra įterptas vienas ar kitas ne jūsų žmonių kurtas kodas. Žinodami jūs jau galėsite spręsti. Pvz.:

 

Galėsite prie sutarties su klientu pridėti sąrašą trečiųjų asmenų kurtos KP ir parašyti, kad už ją tai jau jūs neatsakote;

Galėsite susisiekti su svetimos KP kūrėju ir nusipirkti iš jo ne-copyleft licenciją;

Galėsite atidėti pinigų į lagaminėlį juodai dienai;

Galėsite užpirkti mišias tam, kad neišaiškėtų jūsų fokusai.

Brandžiose įmonėse paprastai mano aptartos svetimų KP naudojimo taisyklės aprašomos vidaus dokumentuose, su jais supažindinami darbuotojai, jie apmokomi ir tai tampa vidaus darbo tvarkos dalimi.

 

Šimtu procentų tai jūsų neišgelbės nuo to, kad darbuotojas nepaisys nustatytų taisyklių ir vis vien kontrabanda prakiš nesankcionuotą kodą, tačiau tai gera pradžia.

 

Egzistuoja ir techninių įrankių, leidžiančių patikrinti, ar nėra KP kode OSS, tačiau apie juos aš nesiplėsiu, nes tik paviršutiniškai išmanau. Bet patikrinti, kiek žinau, galite.

 

Ką dar galite padaryti?

Dar galite, kaip jau rašiau, su klientu sutartyje susitarti, kad jums leidžiama į kuriamą KP įterpti trečiųjų asmenų kodą, net ir „copyleft‘inėmis“ licencijomis licencijuojamą. Nes gal klientui tai nėra baisu.

 

Nebaisu jam tai gali būti tokiu atveju, jei jis neplatins KP su tuo nelemtu svetimu kodu. Tai privalėjau parašyti anksčiau, tačiau virusinis GPL3 efektas įsijungia tik jei / kai KP su įterptu GPL3 kodu yra platinama. Jei jūs pasirašėte KP, kurios pagrindu veikia SaaS, KP jūs neplatinate, o tik suteikiate prieigą prie jos (plačiau čia: https://www.linkedin.com/pulse/saas-licencija-absurdas-andrius-iskauskas/).

 

Tokiu atveju drąsiai naudokite net ir GPL3 licencija licencijuotą svetimą kodą, nes jūs neprivalote atskleisti savo KP kodo viešai*.

 

* – yra ultra griežtų „copyleft“ licencijų, pvz. „Affero“ GPL, kurios net ir prieigos prie SaaS atveju reikalauja atskleisti kodą.

 

III. Ką daryti pirkėjui?

Tradicinis pirkėjo rizikos mažinimo būdas yra įrašyti į sutartį su KP kūrėju reikalavimą, jog:

 

dėl bet kokių trečiųjų asmenų kompiuterių programų įterpimo į jums kuriamą KP reikia gauti jūsų išankstinį pritarimą;

ir / ar negali būti įterpta jokių „copyleftinių“ kodų.

Jei gamintojas / pardavėjas neužtikrina šių sąlygų, tai jau yra sutarties pažeidimas, kuris gali įjungti įvairius sutartyje numatytus mechanizmus, pvz., jūsų teisę nutraukti sutartį, reikalauti pakeisti „užkrėstą“ kodo dalį švaria, sumažinti kainą, atlyginti nuostolius ir kt. Štai kaip pavyzdys mano neseniai rengtos sutarties sąlyga, kuri atspindi tai, ką rašau:

 

„Vykdytojas patvirtina ir garantuoja Užsakovui, kad Programoje ir darbų rezultatuose nebus panaudota ir (ar) įterpta ar įtraukta jokių intelektinės nuosavybės objektų, taip pat ir kompiuterių programų ar kompiuterių programų kodo, kurios licencijuojamos pagal GPL licencijas ar kurių naudojimo sąlygos ar licencijos (i) draudžia naudoti arba apriboja tokio kodo naudojimą komerciniais tikslais, ar (ii) leidžia naudoti kompiuterių programų kodą su sąlyga, kad naudotojo sukurta kompiuterių programa bus licencijuojama pagal analogišką licenciją, ar (iii) leidžia naudoti kompiuterių programų kodą su sąlyga, kad naudotojo sukurtos kompiuterių programos kodas bus prieinamas tretiesiems asmenims.“

 

***

 

Šiame rašinėlyje aš daugiausia kalbu apie GPL3, nes ji yra populiariausia „copyleft“ licencija. Tačiau egzistuoja nemažai kitų (https://opensource.org/licenses/category) ir jų sąlygos skiriasi: vienos griežtesnės, kitos laisvesnės, kai kurios net leidžia platinti jūsų KP neatskleidžiant kodo, o kitos reikalauja atskleisti net naudojant KP tik SaaS teikti (pvz. „Affero“ GPL).  Kiekvienu konkrečiu atveju reikėtų pasitikrinti, kiek stipriai „užkrėtė“ jūsų KP svetimas kodas.

 

IV. Teisiniai pasamprotavimai

Daug klausimų kelia, ar ir kaip galima reikalauti įvykdyti GPL3 numatytas sąlygas.

 

Žiūrėkite, kai naudotojas (licenciatas) imasi naudoti GPL3 būdu licencijuotą KP, jis sutinka su jos sąlygomis. Tarp licenciato ir gamintojo (licenciaro) yra sudaroma sutartis. Sutartis yra privaloma jos šalims. Sakykime, jūs nesilaikote sutarties ir neatskleidžiate kodo viešai. Ko gali reikalauti kita sutarties šalis (licenciaras)?

 

Nėra abejonių, kad licenciaras gali pareikalauti, kad (a) jūs liautumėtės naudoti jo kodą ir (b) kad atlygintumėte padarytą žalą.

 

Bet ar jis gali reikalauti, kad jūs sutartį įvykdytumėte natūra, t. y. atskleistumėte kodą? Tai, mano galva, priklauso nuo to, ar kodo atskleidimas yra licencijos galiojimo sąlyga, ar jūsų įsipareigojimas licenciarui. Kitaip sakant, ar jums neatskleidus kodo, kaip kad numatė GPL3:

 

jūs būsite tik neįvykdęs sąlygos, leidžiančios jums naudoti licenciaro kodą, ir dėl to toks leidimas bus negaliojantis, kas leis licenciarui reikalauti nutraukti naudojimą ir atlyginti žalą;

greta aukščiau esančio punkto jūs sutartimi būsite prisiėmęs įsipareigojimą atskleisti savo programos kodą ir dėl to licenciaras galės reikalauti tai padaryti?

Žiūrėdamas į GPL3 tekstą aš labiau linkstu prie antrojo varianto, nes jis kodo atskleidimą formuluoja ne kaip licenciato pareigą, tačiau kaip sąlygą naudoti kodą:

 

„Jūs galite perduoti saugomą kūrinį objektinio kodo formoje pagal 4-5 straipsnius, su sąlyga, kad perduosite mašininiu būdu skaitomą susijusį kodą pagal šios licencijos sąlygas...“

 

O gal aš klystu ir jei jau jūs panaudojote svetimą kodą, sąlyga įvyko ir dabar jūs turite pareigą pagal sutartį. Nesu tikras. Rasčiau argumentų ir vienai, ir kitai pozicijai ginti. Jei atsiras norinčių padiskutuoti, kviečiu komentaruose tai ir padaryti.

 

Papildoma teisinė tema yra ar Lietuvos teismai, kurie priverstinio vykdymo natūra, kiek man teko susidurti, nemėgsta, ryžtųsi įpareigoti pirkėją, įsigijusį ir naudojantį KP, kurioje aptikta GPL3 kodo, atskleisti visos savo KP kodą. Lietuvoje man tokių bylų matyti dar neteko, bet būtų labai įdomu ginti vieną ar kitą ginčo pusę. Pasaulyje praktikos taip pat nėra daug ir ji nevienoda.

 

V. Pabaiga

Padarykite viską, kad su OSS susiję reikalai iki teismo nenueitų ir jums nereikėtų formuoti teismų praktikos Lietuvoje. Jei jūs KP gamintojas, sužiūrėkite, kad OSS neatsirastų jūsų kuriamoje KP (be jūsų žinios), o jei esate KP pirkėjas – užsitikrinkite, kad pardavėjas neprikišo OSS į KP, už kurią jūs daug sumokėjote.

Andrius Iškauskas

Advokatų kontoros „Noor“ partneris, technologinės intelektinės nuosavybės advokatas”

Komentarų nėra: