[Videó] Open Source licensing: Friend or enemy? - Mihályfalvi Zsófia (Accenture, Kolozsvár)

Címkék

A nyílt forrású licencelés az összetett szerzői jogi törvények és szabályozások hálójában sokszor átláthatatlannak tűnhet a fejlesztők számára - emiatt pedig saját projektjeiknél is könnyen előfordulhat, hogy akár akaratlanul, de az érvényes szabályozásokkal szembemenve használnak fel bizonyos nyílt forrású kódokat. Az előadás az OSS Compliance, azaz a nyílt forrású licenceknek való megfelelés témakörét járja körbe, annak bevált gyakorlatait és buktatóit is megvizsgálva.

(A videó a 2018. november 21-i HWSW mobile! termékfejlesztési konferencián készült.)

Hozzászólások

Jó kezdés, csak hallgattam volna még a részleteket, pl. hogy egy zárt forráskódú programban meghivatkozhatom-e pl. az LGPL license-es .js library-t? Amit persze átadok nyílt forrással, csak az általam hozzáírtakat nem. Ezt kell majd mostanában kikutatnom, hogy milyen kapcsolásokon nem terjed már az opensource "pestise". Vagy ugyan ebben az esetben, ha az ügyfélnek át is adom a forrást, megtilthatom-e neki, hogy továbbadja a programot, amit vett?

Ha nem válaszolnék kommentben, hát küldj privátot!

Nem jogi tanács, de:

- AGPL-t messzire kerüld el

- GPL-es licencű könyvtárakat kerül el ha lehet, akár statikusan, akár dinamikusan fordítva használod, "viszi" a kódod

- LGPL-t lehet, viszont a licenc leírást plusz a használt könyvtár forráskódját át kell adni, és ha belenyúltál a könyvtárba, akkor azt a változtatást is.

- GPL + classpath exception is szokott lenni főleg java-nál, azt olvasd el, de egyébként használható

- Apache, BSD és társait bátran használd

Köszi, ez alapján indulok el.

MIT az jól sejtem, hogy BSD-Apache vonalhoz tartozik?

Van pár rész szolgáltatásunk, pl. dokumentum generálás, amiben van GPL kód jelenleg a fejlesztés alatt levő verzióban, php-ben, pl. mpdf, ott pl. megoldás az, ha egy külön szolgáltatásként adom ezt a szervert, aminek a forráskódja elérhető az ügyfélnek? Vagy ha jól értem, még csak elérhetőnek se kell lennie a forráskódnak, az csak egy szolgáltatás, amit x díjért adok?

Ha nem válaszolnék kommentben, hát küldj privátot!

Ami leírtál az egyrészt hiányos, másrész egyáltalán nem áll meg. 

Először forráskódot csak az ügyfélnek kell odaadni amennyiben azt kérik. Ha például A-Developer Zrt. fejleszt egy GPL licencű szoftvert B-Banking NyRT-nek, attól még Pistike nem nyújthatja be az igényét a forráskódokra, mert semmi köze a szofver-terjesztéshez aminek a módját a licenc szabályozza. 

Másodszor egyáltalán nem mindegy, hogy saját nulláról írt szoftverről van szó vagy már meglevő kódot használunk fel. Amennyiben saját fejlesztést teszünk nyílt forráskódúvá annak nyilván nyomós oka van. Ilyen esetben az üzleti érdek pont fordított licencsorrendet állít fel, mint amit írtál. 

Saját opensource szoftver esetén legjobb AGPL vagy GPL licencet választani. Amennyiben szoftverszabadalmakat is bejegyeztünk, amikből pénz is akarunk, akkor nem érdemes GPL v3 és Apache v2 licenceket használni. Ezekkel a licencekkel ugyanis szoftverszabadalmainkat _mindenkinek_ még Pistikének is ingyenesen licenceljük. Bár a szabadalmi licencet meg is vonhatjuk bizonyos esetekben, erre később még visszatérek. Itt most csak szoftverszabadalmak licenceléséről van szó. Nem jellemző, hogy tisztes szoftverfejlesztő cég szoftverlicencekből szeretne megélni. A szoftverszabadalmi portfólió zsarolási fegyvernek kell általában, más szoftverszabadalmakkal támadó felek ellen. Aki a matekot jobban szereti a programozásnál lehet szabadalmak környékén pénzt keresni, de akkor érdemes csak erre kihegyezni a vállalkozást. 

Ha szoftverszabadalmak bejegyzésével nem védjük a szoftverünket, akkor nyugodtan lehet AGPL és GPL licencekből is 3-as verziót választani. AGPL licencnek csak akkor van értelme, amennyiben a fejlesztett szoftver vagy egy része online szolgáltatásként működik. Hagyományos, számítógépen futó alkalmazásnál megfelelő a GPL licenc is. Így biztosan elkerüljük azt a nem túl szerencsés szituációt, hogy a mi fejlesztésünkkel egy tőlünk teljesen független vállalkozás keresi betegre magát. Ha egy tőlünk független fél olyan ügyfélkapcsolatokkal rendelkezik, ahol nagyobb pénzt tud csinálni az általunk fejlesztett szoftverből mint mi magunk fejlesztőként, és kereskedelmi verziót akar a mi szoftverünkből GPL és AGPL licenc esetén kénytelen lesz leülni tárgyalni velünk. Mi, fejlesztőként természetesen bármikor újra-licencelhetjük a saját kódunkat attól függetlenül, hogy azt GPL vagy AGPL licenc alatt is odaadtuk már valakinek, vagy simán kitettük az internetre. A kereskedelmi licences verzióba jellemzően belekerülnek extra fejlesztések, nem ritkán a fizetős ügyfelek saját igényei szerint. A GPL licencelés soha nem jár a szerzői jogokról való lemondással!

Apache vagy bármelyik BSD vagy MIT licencet választva fizetés nélkül le tudja nyúlni egy tőlünk független fél a saját fejlesztésű szoftverünket. Saját termékneve alatt tud zárt kereskedelmi szoftvert készíteni belőle, további kiegészítésekkel vagy azok nélkül is. Úgy tudja az ügyfélkörének jó pénzért eladni a mi szoftverünket, hogy abból egy huncut garast sem látunk a végén. A szerzői jogunk MIT és BSD licenccel is megmarad, de pénzt nem tudunk keresni vele automatikusan ha más jó üzletet csinál a mi munkánkkal.

Ha úgy döntünk, hogy nulláról fejlesztett szoftverünket nyílt forráskódúvá tesszük annak több oka lehet. A leggyakoribb, hogy külsős fejlesztők bekapcsolódását várjuk a projektünkbe. A legszofisztikáltabb hr-es fogásoknál, állásinterjúknál is hatékonyabban tudunk új és megfelelő munkaerőt találni az nyílt forrákódú fejlesztésünkbe érdemben bekapcsolódó külsős fejlesztők között. Szokás GPL licencű projekteknél copyright átadást kérni a külsős fejlesztőktől. Ebben az esetben a teljes programkód, külsősök fejlesztéseit is beleérve újralicencelhető zárt szoftverként. Szerintem a mai időkben érdemes ebben az esetben pénz felajánlani a legjobb külsős fejlesztőknek munkájukért, amennyiben állást nem akarunk kínálni nekik, vagy ők nem akarnak új állást maguknak. 

Természetesen BSD, MIT és Apache licencek alkalmazásának is van értelme. Például akkor ha nagyon nagy halak vagyunk, mondjuk Google méretben, és egy új codeket akarunk elterjeszteni, hogy letörjük a licencdíjas konkurenciát. Ebben az esetben a BSD vagy MIT licenc a megfelelő. Ezeket a kódokat mindenféle szoftverbe be tudják építeni tőlünk független fejlesztők anélkül, hogy egyesével kapcsolatba kellene lépniük velünk kereskedelmi újralicencelés miatt. Chatelős - telefonálós alkalmazásoktól, amelyek értékének tekintélyes részét fogja kitenni a mi munkánk egészen például játékokig használhatják a nyílt forráskódú codec kódunkat, ahol csak egy kis része a mi kódunk a teljes játéknak, és például a multiban egymással játszó gamerek hang alapú kommunikációjára használják. Vagy a játék átvezető videóihoz. Fizetni nem fognak a fejlesztésbe fektetett munkánkért, de hát ha Google méretűek vagyunk ez nem is akkora probléma. Viszont ha jól elterjed a saját codecünk, akkor idővel nem kell licencelnünk az MPEG-LA-tól drága új generációs cocekjeit, mert az ingyen nyílt forrással osztogatott codecünkkel dominanciát szereztünk. 

Amennyiben már meglevő fejlesztésre építünk, akkor azt jellemzően azért tesszük, hogy fejlesztési időt és ezzel sok pénzt spóroljunk. Itt az elsődleges szempont nem a licenc hanem az, azok a nyílt forráskódú projektek amikre építeni kívánjuk a saját fejlesztésünket. Ha kis számú ügyfelünknek fejlesztünk teljesen mindegy, hogy GPL vagy MIT vagy Apache licenccel adjuk a szoftverünket. Különösen ha folyamatos frissítésekkel kell ellátnunk az ügyfeleinket. A mai világban szinte lehetetlen esemény, hogy egy jellemzően laikus, más területen tevékenykedő ügyfél fogja egy számára fejlesztett szoftver forráskódjait, majd elmenjen velük másik fejlesztőt keresni. Megjegyzem például .NET fejlesztéseknél a teljes forráskód olvasható a kész .exe és .dll fájlokból. Java esetén kell némi tool hozzá de ott is könnyen visszanyerhető a forráskód. A szellemi tulajdonunk védelme érdekében például .NET C# fejlesztéseknél szokás code obfuscatort használni, ami többek között minden metódust ugyanarra névre nevez át, és szignatúra dönt arról végül melyikről is van szó. A változók neveit is generált olvashatatlan nevűekre változtatja át. A forráskód továbbra is olvasható de érdemben nem sokat lehet kezdeni vele. Ugyanez egy GPL licencű programkód általunk írott részével is megtehető. 

A Linux kernel blob-okról is hallott már minden hup olvasó valószínűleg. Ezek ugyanúgy GPL licencű kódok, mint a Linux kernel egyébként normálisan olvasható részei. 

Szóval ha azzal kívánjuk fejlesztésünknek időt és pénzt spórolni, hogy már meglevő nyílt forráskódú szoftverekre alapozunk, annál nagyobb butaságot nem is csinálhatunk, minthogy jobb és számunkra megfelelőbb GPL licencű kód helyett csak a licenc miatt egy számunkra kevésbé optimális de BSD licencű szoftvert választunk a fejlesztésünk alapjának. 

LGPL licencű libekre úgy építhetünk saját zárt forráskódot mintha BSD vagy MIT licencűek lennének. A különbség annyi, hogy az LGPL libek forráskódját ki kell adni az ügyfelünknek amennyiben kéri. Ha semmit nem módosítottunk rajta, csak felhasználjuk a saját szoftverünkhöz, akkor csak azokat a forráskódokat kell odaadnunk amit egyébként is le tudna tölteni más forrásból. 

Már szó esett a szolgáltatásokról. Internetes szolgáltatások esetében GPL licencű kódok tetszőleges felhasználása esetén sem kell odaadnunk a GPL -es kódokat módosító, továbbfejlesztő saját munkánkat. Google, Facebook, Amazon és még sok mára óriássá nőtt vállalkozás profitált ebből milliárdokat. Egyedüli kivétel ez alól az AGPL licenc, amiről már korábban írtam. Mellesleg az AGPL sem zárja ki, hogy pénzt keressünk így licencelt szoftverünkkel. Szép példa erre a Mailvelope. AGPL licencű webes szolgáltatás, amihez azért tartozik fizetős modell is: https://www.mailvelope.com/en/products
A már említett szoftverszabadalmak teljesen más megközelítést igényelnek. Röviden AGPL v3, GPL v3, LGPL v3, Apache v2 licenceket választva automatikusan ingyen adjuk a szoftverszabadalmainkat is. De ezzel nem veszítjük el őket. Sőt ellenséges, támadó célú per esetén meg is lehet vonni az ingyenes szoftverszabadalmi licencet a felperes féltől még akkor is ha nem vagyunk a per résztvevői. GPL v2, BSD, MIT, licenceket választva nem adunk ingyenes szabadalmi licencet senkinek. Ez nem jelenti azonban azt sem, hogy automatikusan pénz járna egy harmadik féltől amennyiben olyan szoftvert forgalmaz, amely általunk szabadalmaztatott eljárást alkalmaz. Sokba kerülnek a szabadalmak, mert megszakítás nélkül minden olyan országban fenn kell tartanunk ahonnan pénzt remélünk utána. Nem is túl szerencsések a szoftverszabadalmak, de ez már egy új téma lenne. Ezért csak érintőlegesen írtam róla. 

Az alapvetés, hogy már született egy döntés az open source fejlesztésről és a licenc a kérdés. Az open source választásának nyilván megvannak már az okai. Továbbá abból indultam ki, hogy  egy közepes vagy nagyobb magyar fejlesztőcégről van szó, ami nagyon messze áll a Google (Alphabet), Microsoft, Amazon mérettől. Ebben az esetben fontosnak tartom, hogy open source mellett is a lehető legtöbb bevételt hozza fejlesztés a cégnek. Ebben az esetben a GPL vagy webes szolgáltatásnál AGPL licencek azok, amelyek alkupozícióba hozzák a céget. 

Amennyiben a fejlesztés sikeres, valóban használni kezdik a célcsoportban vagy azon túl is, akkor fel szokott merülni az igény egy zárt és kereskedelmi verzióra. Ha senkit nem érdekel a fejlesztésünk vagy úgysem fizetnének érte teljesen mindegy milyen licencet választottunk. 
Szóval amennyiben felmerült az igény egy kereskedelmi változatra, akkor azt kizárólag tőlünk, a szerzői jogok birtokosától lehet megkapni. A GPL licenc más fejlesztők számára nem teszi lehetővé, hogy zárt kereskedelmi szoftvert csináljon a mi munkánkból. Ez nagyon fontos! 

Gyakori eset, hogy egy konkurens vagy más területen tevékenykedő fél sokkal jobb ügyfélbázissal, ügyfél-kapcsolatokkal rendelkezik mint a mi fejlesztőcégünk. Sajnos üzletben nem szokás, különösen Magyarországon pénzbe kerülő gesztusokat tenni. Ha az a másik cég (vagy akár állami hivatal) úgy látja, hogy van pénz a fejlesztésünkben, kell belőle zárt kereskedelmi változat, bizony ő maga fogja azt megcsinálni ha megteheti. Ha BSD, MIT, Apache licenc alatt adtuk oda a munkánkat, akkor sajnos megteheti. Ha GPL licencel akkor viszont csak tőlünk kaphat kereskedelmi változatot, így már alkupozícióban vagyunk és mi kapjuk a pénzt a szoftverünkért. 
(Nem véletlen, hogy a IT óriások, Google, Apple, Microsoft és többiek, annyira propagálják a laza BSD, MIT, Apache licenceket. Nekik az a jó, ha nem kell fizetniük más munkájáért. Ha jófejségből adnak pénzt ők határozzák meg mennyit, mint egy adománynál. Széleskörű tevékenységi körük miatt az óriások egyre inkább rászorulnak a külsős open source szoftverek használatára. A fejlesztés nekik is nagyon drága. A Microsoft sokáig más állásponton volt, de volt egy éles váltás náluk, már ők is elkerülhetetlennek tartják open source külsősök szoftvereinek használatát)

Ez egy olyan tipikus, idilli marketinges kép, hogy csak na. Épp csak értelme nincs. Ott ül csávókám a rendes asztali monitor előtt, ahol használhatna rendes billentyűzetet is, erre inkább a szubnotija zsebkendőméretű, visszatükröződő képernyőjében virítja a fejét, valami traveler helytakarékos billentyűzetet használva. Ez is szabadbölcsész volt, aki ezt a képet lőtte, dizájnolta. Na, mindegy, ne bántsuk, a képen megérdemelt boldogság és életérzés látható, mivel black lives matter. Főleg, hogy az IT szakma is tele van színesbőrűekkel és nőkkel is, ezt mindenki tudja, aki mást most, az nem polkorrekt meg hazudik.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nem vagyok licencfetisiszta, így most a cikk érdemével valóban nem foglalkoztam, csak első blikkre a stock fotó ütötte meg a szemem, meg hogy minek bele ilyen baromságot beletenni, mikor köze nincs ráadásul a videó témájához sem. De egy ponton megnézem majd a videót is, mivel nem hosszú, ha érdekesnek találom, a téma érdemére is reagálok, ígérem. Addig nyugodtan röhögj körbe.

Kicsit tényleg arra emlékeztet ez a fotó, mint mikor ilyen női forrasztómunkásokról készül munkahelyi egyenlőségi fotó, ahogy a forrasztóvasat a több száz fokos üzemi hőmérsékletre tervezett fém végénél markolnak. Azt elég gyorsan eldobnák egy valós munkafolyamat során, amikor nem műképhez pózolnak. Tényleg nem kéne az ilyen szabadbölcsész dolgokat erőltetni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Azért tolom tovább, mert emberek úgy gondolkodnak, ahogy te, meg észre sem veszik, hogy hülyeséggel vannak etetve. Betesznek valami bullshitet, hogy legyen valami cover. Arra elég lett volna jelen videónál annak a rendezvénynek a logója, amin az előadás megtörtént. Esetleg egy screenshot az előadásból, nem kell cifrázni stock fotóval.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

A homályos fókuszon kívüliség ellenére én látom rajta, hogy bóvli, süllyesztett gombos bill, valószínű nem jobb, mint ami az előtte lévő szubnotin van. Ráadásul látszik, hogy a faszinak jó nagy kezei vannak, alig fér el egymás mellett a két marka gépelés közben, neki pont egy normál méretű, tisztességes billentyűzet lenne kényelmesebb, ez már elsőre látszik. Csak most ez a trendi, valami minél vékonyabb, minél törékenyebb, minél hajlékonyabb, minél kisebb, minél kevesebb port van rajta, minél jobban forrasztott, minél jobban nem javítható, minél jobban nem upgrade-elhető, minél jobban nem hűthető, annál menőbb, mert az Apple életérzést adja vissza, meg sikkes a kinézete. És ez egy szintig még szempont is lenne, csak nem a használhatóság rovására.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ez van. Ha valamivel nem értesz egyet, akkor a téma lényegére reagálj, ne azt fejtegesd, hogy mit hány sorban írok. Értem, hogy nem tetszik, amit írok, de az eddig a szintig maximum egyéni szocproblémád, ha elkezdesz emiatt személyeskedni, az senkin nem fog segíteni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧