1.3 Lecke 1
Tanúsítvány: |
Linux Essentials |
---|---|
Verzió: |
1.6 |
Témakör: |
1 A Linux Közössége és Pályafutása a Nyílt Forráskódban |
Fejezet: |
1.3 Nyílt Forráskódú Alkalmazások és A Licencek |
Lecke: |
1/1 |
Bevezetés
Noha a szabad szoftver és a nyílt forráskódú szoftver kifejezéseket széles körben használják, még mindig vannak félreértések a jelentésükkel kapcsolatban. Különösen a “szabadság” fogalmát kell közelebbről megvizsgálnunk. Kezdjük a két kifejezés meghatározásával!
A Szabad és A Nyílt Forráskódú Szoftver Definíciója
A Szabad Szoftver Kritériumai
Mindenekelőtt, a “szabad” kifejezés nincs összefüggésben azzal, hogy “ingyenes”-e a szoftver, ahogy azt a Free Software Foundation (FSF) alapítója, Richard Stallman tömören megfogalmazza:
To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.
What is free software?
Függetlenül attól, hogy kell-e fizetni a szoftverért vagy sem, négy kritérium jellemzi a szabad szoftvert. Richard Stallman ezeket a kritériumokat úgy írja le, mint “a négy alapvető szabadság”, amelyek számozását nulláról indítja:
-
“Szabadság a program bármilyen célú futtatásához (0. szabadság).”
A szoftver használatának helyét, módját és célját nem írhatják elő és nem is korlátozhatják.
-
“A program tanulmányozásának és megváltoztatásának szabadsága, hogy a felhasználó igényének megfelelően működjön (1. szabadság). Ennek előfeltétele a forráskódhoz való hozzáférés.”
Mindenki az ötletei és az igényei szerint változtathatja meg a szoftvert. Ehhez feltétel, hogy az úgynevezett forráskód, azaz az összes fájl, amiből a szoftver áll, elérhető legyen programozók által olvasható formában. Ez a jog vonatkozik arra a felhasználóra is, aki esetleg egy funkciót szeretne hozzáadni, valamint olyan szoftvercégekre, amelyek összetett rendszereket hoznak létre, például okostelefonok operációs rendszereit vagy router firmwareket.
-
“A másolatok terjesztésének szabadsága, hogy segíthessünk másokon (2. szabadság).”
Ez kifejezetten arra ösztönzi a felhasználókat, hogy osszák meg a szoftvert másokkal. Ezzel a lehető legszélesebb körű terjesztésről, illetve felhasználói és fejlesztői közösségről lehet szó, akik ezen szabadságok alapján fejlesztik tovább és javítják a szoftvert mindenki javára.
-
“A módosított verziók másolatainak terjesztéséhez való szabadság (3. szabadság). Ezzel megadhatjuk az esélyt az egész közösségnek, hogy részesüljön a változások előnyeiből. Ennek előfeltétele a forráskódhoz való hozzáférés.”
Ez nemcsak a szabad szoftver terjesztéséről szól, hanem a módosított szabad szoftver terjesztéséről is. Bárki, aki módosíthatja a programot, jogosult a változtatásait mások számára is elérhetővé tenni. Ha valaki ezt megteszi, köteles ezt szabadon elérhetővé tenni, tehát a terjesztés során nem korlátozhatják az eredeti szabadságokat még akkor sem, ha módosították vagy kibővítették a szoftvert. Például, ha a fejlesztők egy csoportja más véleménnyel van a szoftver irányáról, mint a tulajdonosok, akkor leválaszhatják azt a saját fejlesztési branchükre — ezt forknak nevezik — , és új projektként folytathatják a munkát. Természetesen a szabadságokkal kapcsolatos összes kötelezettség megmarad.
A szabadság gondolatának hangsúlyozása abban is következetesnek számít, hogy minden szabadságmozgalom valami ellen irányul, nevezetesen egy olyan ellenfél ellen, aki elnyomja a feltételezett szabadságjogokat, aki a szoftvert tulajdonának tekinti és hét lakat alatt akarja tartani. A szabad szoftverekkel ellentétben, ezeket zárt forráskódú szoftvereknek nevezzük.
Nyílt Forráskódú Szoftver vs. Szabad Szoftver
Sokak számára a szabad szoftver és a nyílt forráskódú szoftver szinonimák. A gyakran használt FOSS rövidítés, úgymint Free and Open Source Software hangsúlyozza ezt az egységességet. A FLOSS, azaz Free/Libre and Open Source Software egy másik népszerű kifejezés, amely félreérthetetlenül jelöli a szabadság gondolatát az angolon kívül más nyelveken is. Ha figyelembe vesszük, mindkét kifejezés eredetét és fejlődését, érdemes különbséget tenni.
A szabad szoftver kifejezés a fentebb definiált négy szabadság meghatározásával Richard Stallmanig és az általa 1985-ben alapított GNU projektig vezethető vissza — közel 10 évvel a Linux megjelenése előtt. A “GNU is not Unix” név egy szempillantás alatt leírja a törekvést: a GNU egy olyan kezdeményezésként indult, hogy egészen az alapoktól fejlesszen egy technikailag meggyőző megoldást — nevezetesen a Unix operációs rendszert --, amelyet elérhetővé tesz a nyilvánosság számára és velük együtt folyamatosan tökéletesíti azt. A forráskód nyitottság ehhez csupán technikai és szervezeti szükséglet volt, de önmagában a szabad szoftver társadalmi és politikai — sokak szerint ideológiai — mozgalom.
A Linux sikerével az internet nyújtotta együttműködési lehetőségek, valamint az ezen új szoftverkozmoszban megjelenő projektek és cégek ezrei miatt a társadalmi szempontok egyre inkább a háttérbe szorultak. A forráskód nyitottsága technikai paraméterből funkció lett: ha a forráskód látható volt, a szoftvert “nyílt forrásúnak” tekintették. A társadalmi motívumok teret engedtek a szoftverfejlesztés gyakorlatiasabb megközelítésének.
A szabad és a nyílt forráskódú szoftverek ugyanúgy, ugyanazokkal a módszerekkel működnek, az egyének, a projektek és a vállalatok világméretű közösségében. De mivel különböző irányokból jönnek — egy társadalmi és egy gyakorlati-technikai --, néha konfliktusok merülnek fel. Ez akkor történik meg, amikor a közös munka eredményei nem felelnek meg mindkét mozgalom eredeti céljainak. Ez akkor fordul elő, ha a szoftver forráskódja látható, de nem tartja tiszteletben a szabad szoftver négy szabadságát, például korlátozások vannak a nyilvánosságra hozatalra, a változtatásokra, vagy a más komponensekkel való kapcsolódásra.
Az a licenc, ami alatt a szoftver elérhető, meghatározza, hogy a szoftver milyen feltételekkel használható, terjeszthető és módosítható. Mivel a követelmények és az okok nagyon különbözőek lehetnek, számtalan különféle licenc jött létre a FOSS területén. A szabad szoftver mozgalom sokkal fundamentalistább megközelítése miatt nem meglepő módon számos nyílt forráskódú licencet nem fogad el “szabadként” és emiatt elutasítja őket. Fordított esetben ez a helyzet nem nagyon fordul elő a nyílt forráskód sokkal gyakorlatiasabb megközelítése miatt.
Az alábbiakban vessünk egy rövid pillantást a licencek rendkívül összetett világára.
Licencek
Szemben egy hűtőszekrénnyel vagy egy autóval a szoftver nem egy fizikai termék, hanem digitális. Így egy cég nem ruházhatja át a tulajdonjogot azzal, hogy fizikailag átadja az eladott terméket a vevőnek, hanem inkább átruházza a használati jogokat és ezeket a felhasználó szerződésesen elfogadja. Hogy melyek ezek a használati jogok és az, hogy ezek nincsenek rögzítve a szoftverlicencben, teszi érthetővé, hogy mennyire fontosak az abban foglalt előírások.
Míg a zárt forráskódú szoftverek nagy gyártói, például a Microsoft vagy az SAP, saját, termékekhez szabott licencekkel rendelkeznek, addig a szabad és nyílt forráskódú szoftverek támogatói már a kezdetektől fogva a licenceik egyértelműségére és általános érvényességére törekedtek, hiszen minden felhasználónak meg kell érteni őket és ha szükséges, maguknak is felhasználni a saját fejlesztéseikhez.
Nem szabad elfelejteni, hogy ez a kigondolt egyszerűség nehezen érhető el a valóságban, mivel túl sok specifikus követelmény és nemzetközileg nem mindig összeegyeztethető jogi értelmezések akadályozzák ezt. Például a német és az amerikai szerzői jog alapvetően különbözik egymástól. A német törvények szerint a szerző az egy személy (még pontosabban: Urheber), akinek a munkája a szellemi tulajdona. Noha a szerző engedélyt adhat művének felhasználásra, nem adhatja át vagy nem mondhat le szerzői jogáról. Ez utóbbi az amerikai jog számára teljesen idegen. Itt is van egy szerző (aki lehet cég vagy intézmény is), de csak értékesítési jogokkal rendelkezik, melyeket részben vagy egészben átruházhat és így teljesen különválasztható a munkájától. A nemzetközileg érvényes licencet a különböző jogszabályok figyelembevételével kell értelmezni.
Ennek következménye a számos, időnként nagyon különböző FOSS licenc. Még rosszabb, hogy a különböző verziójú licencek vagy a licencek vegyítése (egy projekten belül, vagy akár több különböző projekt összekapcsolásakor) zavart, vagy akár jogi vitákat is okozhatnak.
Mind a szabad szoftver képviselői, mind a gazdaságilag orientált nyílt forráskódú mozgalom támogatói saját szervezeteket hoztak létre, amelyek ma döntő felelősséggel tartoznak a szoftverlicencek alapelveinek megfogalmazásáért és támogatják tagjaikat azok alkalmazásában.
Copyleft
A már említett Free Software Foundation (FSF) megfogalmazta a GNU General Public License-t (GPL), mint az ingyenes szoftverek egyik legfontosabb licencét, amelyet számos projekt használ, például a Linux kernel. Ezenfelül esetspecifikus licenceket is kiadtak, mint például a GNU Lesser General Public License-t (LGPL), ami a szabad szoftver és a kód módosításainak kombinációját szabályozza, ahol ezen módosítások forráskódját nem kell nyilvánosságra hozni, illetve a GNU Affero General Public License-t (AGPL), amely a hosztolt szoftverek értékesítését fedi le, vagy pedig a GNU Free Documentation License-t (FDL), amely a szabadságelveket kiterjeszti a szoftverek dokumentációjára is. Ezeken felül az FSF ajánlásokat tesz harmadik felek licenceivel szemben vagy ellen és az olyan kapcsolódó projektek, mint a GPL-Violations.org kivizsgálják a szabad licencek feltételezett megsértését.
Az FSF felveti azt az elvet, miszerint a szabad licenc copyleft szoftverek módosított változataira is vonatkozik — szemben a copyrighttal, ami ezt elutasítja. Az ötlet tehát az, hogy a szoftverlicenc liberális alapelveit korlátlanul átvigyük a szoftver jövőbeni változataira a korlátozások elkerülése érdekében.
Amennyire egyszerűnek és egyértelműnek hangzik, a gyakorlatban jelentős bonyodalmakhoz vezet, ezért a kritikusok gyakran a copyleft elvet “virálisnak” hívják, mivel az átkerül a következő verziókra.
A fentiekből következik, hogy két különféle copyleft licenccel engedélyezett szoftverkomponens nem feltétlenül kombinálható egymással, mivel mindkét licenc nem adható át a következő termékre. Ez vonatkozhat ugyanazon licenc különböző verzióra is!
Emiatt az újabb licencek vagy licenc-verziók gyakran már nem olyan szigorúak a copylefttel. A már említett GNU Lesser General Public License (LGPL) ebben az értelemben egy engedmény, mert szabad szoftvereket összekapcsolhatunk “nem-szabad” komponensekkel, amit gyakran úgynevezett mappákkal végeznek. A mappák rutinokat vagy szubrutinokat tartalmaznak, amelyeket számos más program használ. Ez egy olyan gyakori helyzethez vezet, amikor zárt forráskódú szoftverek egy ilyen alprogramot használnak egy ingyenes mappából.
A konfliktusok elkerülésének egy másik módja a kettős licenc, amikor egy szoftver különféle licencek alatt jelenik meg, például egy nyílt és egy zárt licenc. Egy tipikus felhasználási eset, ha egy szoftver szabad verzióját akkor lehet használni, ha betartják a copyleft korlátozásait és egy alternatív ajánlatot tesznek a szoftver megszerzésére egy másik licenc alapján, amely megszabadítja a licenct bizonyos korlátozásoktól olyan díj ellenében, amely felhasználható a szoftver fejlesztésének finanszírozására.
Ezért világossá kell válnia, hogy a szoftverprojektekre vonatkozó licencet nagyon óvatosan kell megválasztani, mivel a más projektekkel való együttműködés, a más komponensekkel való kombináció és a termék jövőbeni kialakítása is ezen múlik. A copyleft e tekintetben különleges kihívások elé állítja a fejlesztőket.
A Nyílt Forráskód Definíciója és a Megengedő Licencek
Az Open Source Initiative (OSI), amelyet 1998-ban alapított Eric S. Raymond és Bruce Perens, elsősorban licencelési kérdésekkel foglalkozik. Kidolgozott egy szabványosított eljárást annak ellenőrzésére, hogy a szoftverlicenc megfelel-e a Open Source Definition-nek. Jelenleg több, mint 80 elismert nyílt forráskódú licenc található az OSI webhelyén.
Itt felsorolják az OSI által jóváhagyott (“OSI-approved”) licenceket, amelyek kifejezetten ellentmondanak a copyleft alapelvének, különösen a BSD licencek. A Berkeley Egyetemen fejlesztett Berkeley Software Distribution (BSD) a Unix egy variánsa, amely később olyan ingyenes projekteket eredményezett, mint a NetBSD, a FreeBSD és az OpenBSD. Az ezen projektek licenceit gyakran permisszívnek (megengedőnek) nevezik. A copyleft licencekkel ellentétben ezeknek nem célja a módosított változatok használati feltételeinek meghatározása. Ezzel szemben a maximális szabadságnak segítenie kell a szoftver lehető legszélesebb körű terjedését, azzal, hogy engedi a szoftver szerkesztőinek, hogy eldöntsék, miként folytatják a szerkesztést — akár kiadják azt, akár zárt forráskódúként kezelik és forgalmazzák őket.
A 2-Záradékos BSD Licenc, amelyet Simplified BSD License-nek vagy FreeBSD License-nek neveznek, meghatározza, hogy mennyire lehet egyszerűsíteni egy megengedő licencet. A szabványos felelősségi záradékon kívül, amely megvédi a fejlesztőket a szoftver által okozott károkból eredő követelésektől, a licenc csak a következő szabályból áll:
A forrás és bináris formában való újraterjesztés és használat, módosításokkal vagy anélkül is engedélyezett, feltéve, hogy a következő feltételek teljesülnek:
A forráskód újraterjesztésénél kötelező alkalmazni a fenti copyright felhívást, az itt található feltételeket és a következőkben olvasható korlátozott felelősségi nyilatkozatot.
A bináris formában való újraterjesztés esetén a binárishoz adott dokumentációban és/vagy egyéb anyagban kötelező idézni a fenti copyright felhívást, az itt található feltételeket és a következőkben olvasható korlátozott felelősségi nyilatkozatot.
Creative Commons
A FLOSS sikeres fejlesztési koncepciója és az ahhoz kapcsolódó technológiai fejlődés vezetett a nyílt forráskód elv más, nem műszaki területeken való megjelenéséhez. Az ismeretek előkészítését és szolgáltatását, valamint az összetett feladatok megoldásában játszott kreatív együttműködést most a kibővített, tartalommal kapcsolatos nyílt forráskód elvének bizonyítékának tekintik.
Ez vezetett ahhoz, hogy ezeken a területeken is olyan megbízható alapokat kellett létrehozni, amelyek alapján a munka eredményei megoszthatók és feldolgozhatók. Mivel a rendelkezésre álló szoftverlicencek nem igazán voltak erre alkalmasak, számos kísérlet történt konkrét követelmények tudományos munkákból digitalizált műalkotásokká való konvertálásra a “nyílt forráskód szellemében”.
Ma messze a legfontosabb ilyen jellegű kezdeményezés a Creative Commons (CC), amelyet így foglalhatunk össze:
A Creative Commons egy globális nonprofit szervezet, amely ingyenes jogi eszközök biztosítása révén lehetővé teszi a kreativitás és a tudás megosztását és újrafelhasználását.
A Creative Commons esetében a jogok átruházása a forgalmazótól a szerzőhöz tér vissza. Például: hagyományos kiadás során a szerző általában minden publikálási jogot (nyomtatás, fordítás, stb.), átad egy kiadónak, aki biztosítja a mű lehető legjobb terjesztését. Az internet jelentősen megváltozott terjesztési csatornái most már lehetőséget adnak a szerzőknek, hogy maguk gyakorolják e közzétételi jogokat és maguk döntsék el, hogyan lehet felhasználni műveiket. A Creative Commons lehetőséget ad ennek egyszerű és jogilag megbízható meghatározására, de a Creative Commons ennél többet akar: a szerzőket arra ösztönzik, hogy műveiket tegyék elérhetővé az általános csere és együttműködési folyamathoz való hozzájárulásként. A hagyományos szerzői jogokkal ellentétben, amelyek a szerzőnek minden jogot biztosítanak, melyeket szükség esetén átruházhatnak másokra, míg a Creative Commons ellentétes megközelítést alkalmaz: a szerző a műveit a közösség számára elérhetővé teszi, de választhat olyan tulajdonságokat, amelyeket figyelembe kell venni a mű használatakor — minél többet választ, annál inkább korlátozóbb a licenc.
Így tehát a “Válasszon Licencet” alapelv lépésről-lépésre végigvezeti a szerzőt az egyes tulajdonságokon és legenerálja az ajánlott licencet, amelyet a szerző hozzá tud rendelni a műhöz szövegként és ikonként.
A jobb megértés érdekében itt olvasható a hat lehetséges kombináció és licenc, amit a CC kínálni tud:
- CC BY (“Nevezd meg!”)
-
A szabad licenc, ami lehetővé teszi bárki számára a mű szerkesztését és terjesztését, feltéve, hogy megnevezi a szerzőt.
- CC BY-SA (“Nevezd meg!-Így add tovább!”)
-
Olyan, mint a CC BY, annyi kivétellel, hogy a módosított mű csak ugyanazon licenc alapján terjeszthető. Az elv a copyleftre emlékeztet, mert a licenc itt is “öröklődik”.
- CC BY-ND (“Nevezd meg!-Ne változtasd!”)
-
Olyan, mint a CC BY, de csak módosítás nélkül adható tovább.
- CC BY-NC (“Nevezd meg!-Ne add el!”)
-
A mű a szerző nevének megadásával szerkeszthető és terjeszthető, de csak nem kereskedelmi feltételek mellett.
- CC BY-NC-SA (“Nevezd meg!-Ne add el!-Így add tovább!”)
-
Olyan, mint a BY-NC, azzal a különbséggel, hogy a művet csak azonos feltételek mellett lehet továbbadni. (Copyleft-szerű licenc).
- CC BY-NC-ND (“Nevezd meg!-Ne add el!-Ne változtasd!”)
-
A legkorlátozóbb licenc: a terjesztés megengedett a szerző megnevezésével, de csak módosítás nélkül és nem kereskedelmi forgalomban.
Üzleti Modellek a Nyílt Forráskódban
Visszatekintve láthatjuk, hogy a FLOSS győzelme úgy alakult ki, hogy a technofil idealisták alulról szerveztek egy mozgalmat és munkájukat gazdasági korlátoktól függetlenül és monetáris függőségektől mentesen a nagyközönség szolgálatába helyezik. Ugyanakkor milliárdokban mérhető azon cégek értéke, amiket a FLOSS környezetben hoztak létre; hogy csak egyet nevesítsünk: az 1993-ban alapított, amerikai Red Hat céget az IT-óriás IBM 2018-ban vette át és az éves forgalma meghaladja a 3 milliárd USD-t (2018).
Vessünk egy pillantást a magas minőségű szoftverek ingyenes és a nagyjából ingyenesen történő terjesztése és az alkotók számára készített üzleti modellek közötti feszültségre, mert egy dolognak egyértelműnek kell lennie: A szabad szoftverek számtalan magasan képzett fejlesztőjének pénzt kell keresnie és az eredetileg tisztán nem kereskedelmi FLOSS környezetnek fenntartható üzleti modelleket kell kidolgoznia saját univerzumának megőrzése érdekében.
Gyakorlattá válik, különösen a kezdeti szakaszban lévő nagyobb projektek esetében az úgynevezett crowdfunding (közösségi finanszírozás), azaz az adományok gyűjtése egy olyan platformon keresztül, mint a Kickstarter. Cserébe az adományozók a sikeres gyűjtés esetén egy előre meghatározott bónuszt kapnak, ez lehet akár korlátlan hozzáférés a termékhez, vagy valamilyen speciális szolgáltatás.
Egy másik megközelítés a kettős licenc: ingyenes szoftvert kínálnak párhuzamosan szigorúbb vagy akár zárt licenc alapján, ami garantálja az ügyfelek számára a szélesebb körű szolgáltatásokat (válasz hiba esetén, frissítések, verziók különböző platformokra, stb.). Egy példa a sok közül az ownCloud, amelyet GPL szerint fejlesztenek, és az üzleti ügyfelek számára egy “Business Editiont” kínál zárt licenc alatt.
Vegyük az ownCloud példáját egy másik elterjedt FLOSS üzleti modellre: professzionális szolgáltatások. Sok vállalatnak nincs meg a szükséges belső tudása egy komplex és kritikusan fontos szoftver megbízható és legfőképp biztonságos telepítéséhez és működtetéséhez. Ezért közvetlenül a gyártótól vesznek igénybe, például professzionális szolgáltatásokat, konzultációt, karbantartást vagy ügyfélszolgálatot. A felelősség kérdése szintén fontos szerepet játszik ebben a döntésben, mivel a vállalat így átadja a működtetés kockázatait a gyártónak.
Ha egy szoftvernek sikerül sikeressé és népszerűbbé válnia a területén, perifériás bevételszerzési lehetőség is megjelennek, például merchandising vagy olyan tanúsítványok, amelyeket az ügyfelek megszerezhetnek, és ezzel rámutatnak annak különleges státusára, hogy ők az adott szoftvert használják. A Moodle oktatási platform oktatókat tanúsít/képez, akik dokumetálják a tudásukat a potenciális ügyfelek számára, és ez csak egy példa a számtalan többi közül.
A Software as a Service (szolgáltatott szoftver - SaaS) egy másik üzleti modell, különösen webtechnológiák esetén. Itt a felhőszolgáltató a szerveren egy olyan szoftvert futtat, mint például Ügyfélkapcsolat-kezelő (Customer Relationship Management - CRM), vagy Tartalomkezelő Rendszer (Content Management System - CMS) és hozzáférést biztosít az ügyfelek számára az alkalmazáshoz. Ezzel az ügyfélnek nem kell telepítenie és karbantartania a szoftvert. Cserébe az ügyfél különböző paraméterek, például a felhasználók száma alapján fizet a szoftver használatáért. Az elérhetőség és a biztonság nagyon fontos és kritikus szerepet játszik ebben az esetben.
Végül, de nem utolsósorban, kisebb projektek esetén jellemző modell az ügyfél által igényelt kiterjesztések fejlesztése egy ingyenes szoftverhez. Ezután az ügyfél dönti el, hogy hogyan járjon el ezekkel a kiterjesztésekkel, azaz kiadja vagy zárolja őket a saját üzleti modellje részeként.
Egy dolognak világossá kell válnia: noha a szabad szoftverek általában ingyenesek is, számos üzleti modell van a környezetükben, amelyeket rendkívül kreatív módon számtalan szabadúszó és vállalkozás folyamatosan módosít és bővít világszerte, végső soron ezzel biztosítva a teljes FLOSS mozgalom fennmaradását.
Gyakorló Feladatok
-
Mi — röviden — a Richard Stallman és a Free Software Foundation által meghatározott “négy szabadság”?
0. szabadság
1. szabadság
2. szabadság
3. szabadság
-
Mit jelent a FLOSS rövidítés?
-
Szabad szoftvert fejlesztünk és szeretnénk, hogy nemcsak a szoftver, hanem az arra épülő összes jövőbeni munka szintén szabad maradjon. Melyik licencet kell választanunk?
CC BY
GPL 3-as verzió
2-Záradékos BSD Licenc
LGPL
-
Az alábbi licencek közül melyiket hívhatjuk megengedőnek és melyiket copyleftnek?
Simplified BSD Licenc
GPL 3-as verzió
CC BY
CC BY-SA
-
Fejlesztettünk egy webes alkalmazást és szabad licenc alatt tettük közzé. Hogyan kereshetünk pénzt a termékkel? Nevezzünk meg három lehetőséget!
Gondolkodtató Feladatok
-
Melyik licenc melyik verziója alatt érhetőek el a következő alkalmazások?
Apache HTTP Server
MySQL Community Server
Wikipedia szócikkek
Mozilla Firefox
GIMP
-
Szeretnénk a szoftverünket GNU GPL v3 licenc alatt kiadni. Milyen lépéseket kell követnünk?
-
Egy zárt forráskódú szoftvert írtunk és ingyenes szoftverrel szeretnénk kombinálni a GPL v3 alatt. Van-e erre lehetősége, figyelembe kell-e venni valamit? (Ha igen, mit?)
-
Miért adta ki a Free Software Foundation a GNU Affero General Public Licenset (GNU AGPL) a GNU GPL kiegészítéseként?
-
Nevezzünk meg három olyan szabad szoftvert, amely "`Business Edition`” változatban is elérhető, azaz díjkötelesként!
Összefoglalás
Ebben a leckében megtanultuk:
-
Hasonlóságok és különbségek a szabad és a nyílt forráskódú (FLOSS) szoftverek között
-
A FLOSS licenceket, fontosságukat és a problémáikat
-
Coplyeft vs. megengedő licencek
-
FLOSS üzleti modellek
Válaszok a Gyakorló Feladatokra
-
Mi — röviden — a Richard Stallman és a Free Software Foundation által meghatározott “négy szabadság”?
0. szabadság
a szoftver futtatása
1. szabadság
a szoftver tanulmányozása és módosítása (forráskód)
2. szabadság
a szoftver terjesztése
3. szabadság
a módosított szoftver terjesztése
-
Mit jelent a FLOSS rövidítés?
Free/Libre Open Source Software
-
Szabad szoftvert fejlesztettünk és szeretnénk, hogy nemcsak a szoftver, hanem az arra épülő összes jövőbeni munka szintén szabad maradjon. Melyik licencet kell választanunk?
CC BY
GPL 3-as verzió
X
2-Záradékos BSD Licenc
LGPL
-
Az alábbi licencek közül melyiket hívhatjuk megengedőnek és melyiket copyleftnek?
Simplified BSD Licenc
megengedő
GPL 3-as verzió
copyleft
CC BY
megengedő
CC BY-SA
copyleft
-
Fejlesztettünk egy webes alkalmazást és szabad licenc alatt tettük közzé. Hogyan kereshetünk pénzt a termékkel? Nevezzünk meg három lehetőséget!
-
Kettős licenc, például egy fizetős “Business Edition” felajánlása
-
Hoszting, szolgáltatás és támogatás kínálása
-
Zárt forráskódú kiegészítők fejlesztése a vásárlóknak
-
Válaszok a Gondolkodtató Feladatokra
-
Melyik licenc melyik verziója alatt érhetőek el a következő alkalmazások?
Apache HTTP Server
Apache License 2.0
MySQL Community Server
GPL 2.0
Wikipedia szócikkek (Angol)
Creative Commons Nevezd meg!-Így add tovább! licenc (CC-BY-SA)
Mozilla Firefox
Mozilla Public License 2.0
GIMP
LGPL 3
-
Szeretnénk a szoftverünket GNU GPL v3 licenc alatt kiadni. Milyen lépéseket kell követnünk?
-
Ha szükséges, biztosítsuk magunkat a munkáltatóval szemben, például szerzői jogi mentességgel, hogy meg tudja határozni az engedélyt.
-
Minden fájlhoz adjunk copyright figyelmeztetést
-
Adjunk hozzá
COPYING
nevű fájlt a teljes licenc szövegével. -
Adjunk hivatkozást a licenchez minden fájlban.
-
-
Egy zárt forráskódú szoftvert írtunk és ingyenes szoftverrel szeretnénk kombinálni a GPL v3 alatt. Van-e erre lehetősége, figyelembe kell-e venni valamit? (Ha igen, mit?)
A Szabad Szoftver Alapítvány GYIK információt nyújt erről: Amennyiben a saját és a szabad szoftver külön-külön marad, megoldható a kombináció. Gondoskodnunk kell arról, hogy ez az elválasztás technikailag garantált és felismerhető legyen minden felhasználó számára. Ha az ingyenes szoftvert úgy integráljuk, hogy az a termék részévé válik, akkor a terméket a copyleft elve szerint GPL-ben is közzé kell tenni.
-
Miért adta ki a Free Software Foundation a GNU Affero General Public Licenset (GNU AGPL) a GNU GPL kiegészítéseként?
A GNU AGPL lezárja a licenchiányt, amely a kiszolgálón tárolt ingyenes szoftverekkel jár: Ha egy fejlesztő változtatásokat hajt végre a szoftveren, akkor a GPL értelmében nem köteles ezeket a változtatásokat elérhetővé tenni, mivel hozzáférést ad a programhoz, de nem “terjeszti” a GPL értelmében. A GNU AGPL viszont előírja, hogy biztosítani kell a letölthetőséget minden változtatással együtt.
-
Mondjon három olyan szabad szoftvert, amely "`Business Edition`” változatban is elérhető, azaz díjkötelesként!
MySQL, Zammad, Nextcloud