GitHub-kód kereskedelmi termékben: licencek és ellenőrizendő tudnivalók

Terméket fejleszt, és talál egy kész megoldást a GitHubon: egy könyvtárat, egy sablont vagy akár egy teljes projektet, amely pontosan azt tudja, amire szüksége van. Claude azt javasolja, hogy vegye át a projektjébe. Ön pedig megtorpan: a kód nyilvánosan elérhetőnek tűnik, de valóban használhatja? Eladhatja az azt tartalmazó terméket? Később felléphet Ön ellen a szerző?

Sorban átveszem, miért nem jelent önmagában engedélyt, ha egy kód nyilvánosan elérhető a GitHubon; mely licencek teszik lehetővé a kód használatát és a termék értékesítését; mely copyleft-feltételek írhatják elő az érintett mű megfelelő forráskódjának átadását; és hogyan ellenőrizheti a licencet egy perc alatt, mielőtt felhasználja a kódot. Nincs olyan válasz, hogy „attól függ”.

Az Ailoot használatával kapcsolatos gyakorlati tudnivalókat a dokumentációban találja.

Igaz, hogy ha egy kód fent van a GitHubon, ingyen használhatja?#

A fő csapda itt a „nyílt” szó. Látja a forráskódot, ezért úgy tűnhet, hogy mivel nem rejtették el, használhatja. Ez a gondolatmenet téves. A „nyíltan olvasható” és a „felhasználásra licencelt” két külön dolog.

Alapértelmezés szerint minden alkotás, így a kód is, a létrehozás pillanatától szerzői jogi védelem alatt áll. Amíg a szerző kifejezetten nem ad engedélyt, nem használhatja fel. Ezt írja le a GitHub a saját licencútmutató-oldalán is.

A második réteg maga a GitHub. Sokan úgy gondolják, hogy mivel a kód közzétételével elfogadták a GitHub szabályait, mások ottani kódját is felhasználhatják. A szabályok pontosan az ellenkezőjét mondják. Nyilvános tároló létrehozásával a szerző csak arra ad engedélyt másoknak, hogy megtekintsék és forkot készítsenek róla, vagyis másolatot hozzanak létre magán a GitHubon belül. Ez nem jogosít fel arra, hogy a kódot a saját munkájában használja.

A kulcsfontosságú szavak az utolsó mondatban vannak: „a GitHub funkcióin belül” és „a további jogokat licenc biztosítja”. A fork a GitHubon belül marad. Amint a kódot a saját termékében szeretné felhasználni, nem is beszélve az értékesítéséről, külön engedélyre van szüksége a szerzőtől. Licenc nélkül nincs joga hozzá, akkor sem, ha a kód mindenki szeme előtt van.

Mi határozza meg, hogy használhatja-e valaki más kódját?#

Minden egy fájlon múlik. Egy megfelelően karbantartott tárolóban van licencfájl, általában LICENSE, néha LICENSE.md néven, vagy a README közvetlenül említi a licencet. Ez a szerző engedélye, amely megadja, milyen feltételekkel használhatja a kódot. A GitHub rendszerint már a fájl megnyitása előtt megjeleníti a licenc nevét a tárolóoldal oldalsávjában.

Hogy ne vesszen el a jogi megfogalmazásokban, érdemes három, az Ön helyzetére vonatkozó kérdés segítségével elolvasni a licencet:

1. Használhatja-e ezt a kódot olyan kereskedelmi termékben, amelyért az emberek fizetnek?
2. Módosíthatja-e a kódot az igényei szerint?
3. Nyilvánosságra kell-e hoznia később a termék forráskódját, vagy zártan tarthatja?

A licencek közötti különbségek szinte mind a harmadik kérdésre adott eltérő válaszokból erednek. Az első kettőre a népszerű nyílt licencek többnyire „igent” mondanak: használhatja, módosíthatja, eladhatja. Az emberek ott hibáznak, amikor arról kell dönteni, hogy a licenc miatt nyilvánosságra kell-e hozniuk a saját kódjukat. Most a három kérdés alapján áttekintjük a fő licenctípusokat.

Mely licencek engedik a kód használatát és a termék értékesítését?#

Kezdjük a jó hírrel. Aki eladásra szánt terméket épít, annak a megengedő licencek csoportja a legjobb választás. Több ilyen licenc létezik, de a három leggyakoribb az MIT, az Apache 2.0 és a BSD. Mindhárom „igent” mond az első két kérdésre, és lehetővé teszi, hogy saját forráskódját zártan tartsa.

A leggyakoribb és legegyszerűbb az MIT. A szövege elfér egyetlen bekezdésben.

Egyszerűbben fogalmazva az MIT szinte bármit megenged a kóddal kapcsolatban, beleértve a termék értékesítését és a saját forráskód zártan tartását. Az egyetlen kötelezettség, hogy mellékelje a licenc szövegét és az attribúciós sort. Például a Babel, a .NET és a Rails MIT-licenc alatt jelent meg, így szinte biztos, hogy már Ön is használt ilyen licencű kódot.

Az Apache 2.0 hasonlóan működik, de két fontos elemmel egészül ki. Először is kifejezetten véd a szabadalmi igények ellen: a kód szerzői vállalják, hogy nem perelik be Önt a kódhoz kapcsolódó szabadalmak miatt. Másodszor, néhány további, formálisabb használati követelményt tartalmaz.

A BSD (2 és 3 záradékos változatban) lényegében hasonló az MIT-hez: használhatja, módosíthatja és értékesítheti, de meg kell őriznie a szerzői jogi nyilatkozatot. Az áttekinthetőség kedvéért mindhármat táblázatba foglaltam.

Így alkalmazhatja mindezt a saját helyzetére: ha valaki más kódjánál MIT, Apache 2.0 vagy BSD licencet lát, megnyugodhat: használhatja kereskedelmi termékben, módosíthatja, és saját forráskódját zártan tarthatja. Arra kell ügyelnie, hogy ne távolítsa el az átvett rész licencfájlját és attribúcióját.

Hogyan érvényesülnek a GPL és az AGPL forráskódra vonatkozó kötelezettségei?#

A copyleft az érintett művet és származékait azonos licenc alatt tartja, ha a vonatkozó feltételek teljesülnek. A GPLv3 szerint a licenc hatálya alá tartozó mű vagy összekapcsolt származékos mű forrás- vagy tárgykódú példányainak terjesztésekor teljesíteni kell a licenc és a megfelelő forráskód átadásának követelményeit. Ez nem terjed ki automatikusan az azonos termékben vagy szerveren futó összes független programra.

Vegyük a webszolgáltatás példáját. Egy GPL-könyvtár saját szerveren történő futtatása anélkül, hogy a felhasználóknak példányokat adna át, önmagában nem követeli meg a teljes szolgáltatás közzétételét. Az érintett, összekapcsolt alkalmazás ügyfeleknek való terjesztése viszont GPL-kötelezettségeket válthat ki; a kód integrációja és licence alapján állapítsa meg, milyen forráskódot kell mellékelnie. A felhasználóknak átadott böngészős kliens terjesztése külön vizsgálandó kérdés.

Az AGPLv3 hálózati feltételt is hozzáad: ha módosítja a programot, és a felhasználók távolról lépnek kapcsolatba ezzel a verzióval, jól látható módon fel kell ajánlania nekik annak megfelelő forráskódját. Ez pontosabb annál az állításnál, hogy bármely AGPL-komponens puszta szerveroldali futtatása megnyitja a szolgáltatás minden független részét.

Zárt terméknél vizsgálja meg az érintett művet, a komponensek összekapcsolását, a példányok terjesztését és az AGPL hálózati feltételét. Válasszon kompatibilis, megengedő licencű alternatívát, vagy szerezzen külön engedélyt, ha a vonatkozó kötelezettségeket nem tudja teljesíteni. A kereskedelmi felhasználás önmagában megengedett; a kérdés a tényleges licencnek és integrációnak való megfelelés.

Mit tegyen, ha a tárolóban egyáltalán nincs licencfájl?#

Gyakori hiba azt feltételezni, hogy ha nincs licenc, nincsenek korlátozások, így a kód szabadon használható. Ennek az ellenkezője igaz. A licenc hiánya nem engedély; alapértelmezés szerint azt jelenti, hogy nincs engedély. A licenc nélküli kód teljes egészében a szerző szerzői jogi védelme alatt áll, és nem nyúlhat hozzá.

Újra érvényes az az alapszabály, amellyel kezdtünk: a kódot alapértelmezés szerint szerzői jog védi, és kifejezett engedély nélkül nem másolhatja, módosíthatja vagy terjesztheti. A GitHubon belüli megtekintés és fork készítése nem töri át ezt a korlátot, és nem ad jogot arra, hogy a kódot saját termékében használja.

Mit tegyen a gyakorlatban, ha a kódnak nincs licence, de valóban szüksége van rá?

1. Írjon a szerzőnek. Kérdezze meg közvetlenül a tároló beszélgetési felületén vagy e-mailben, hogy használhatja-e a kódot, és milyen feltételekkel. Néha a szerző egyszerűen elfelejtette hozzáadni a licencet, és kérésre pótolja.
2. Keressen helyettesítőt. Szinte bármilyen feladathoz talál még egy, egy harmadik vagy akár egy tizedik hasonló tárolót; ezek között akad megfelelő MIT- vagy Apache-licencű is.
3. Ne használja. Ha nincs engedélye és helyettesítő sincs, a kód nem az Öné, és nem teheti bele egy eladásra szánt termékbe. A „ki fogja megtudni?” gondolat kísértése éppen akkor ér véget rosszul, amikor a termék pénzt kezd termelni és figyelmet kap.

Mi van, ha Claude maga adott hozzá valaki más kódját a projekthez?#

Van itt egy második réteg is, amely könnyen összekeverhető az elsővel. Más a helyzet, amikor megnyit egy tárolót, és kimásol belőle egy fájlt: ilyenkor a licenccel kapcsolatos fentiek közvetlenül Önre vonatkoznak. És más az, amikor Claude egy kérésre kódot ír Önnek.

Szokásos esetben az AI saját, az Ön feladatára összeállított szöveget készít, nem valaki más fájljának másolatát. Ekkor más területre kerül át a kérdés: kié a létrehozott kód, és eladhatja-e? Ez önmagában is nagy téma, amelyről a kié az AI által írt kód című cikkben írtam.

Van azonban egy kivétel, amelyet érdemes észben tartani. Néha az AI szinte szó szerint előállítja valaki más kódjának egy felismerhető részletét, például egy teljes függvényt egy ismert könyvtárból. Ilyenkor a könyvtár licence továbbra is érvényes, függetlenül attól, hogy fizikailag ki nyomta le a billentyűket. Ezért a Claude által teljes egészében átvett nagy kész kódblokkokat úgy kell ellenőrizni, mintha Ön másolta volna ki őket.

Hogyan ellenőrizze a licencet a kód használata előtt: követendő lépések#

Foglaljuk össze az egészet egy rövid ellenőrzőlistában, amellyel bármilyen külső kódot megvizsgálhat, mielőtt beemeli a projektjébe. Haladjon fentről lefelé.

1. Keresse meg a licenc nevét a tároló oldalán

   Nyissa meg a tárolót a GitHubon. A licenc neve rendszerint a jobb oldali oszlopban vagy a fájllista alatt látható, például: „MIT License”, „Apache-2.0” vagy „GPL-3.0”. Ha a mező üres, és nincs licencfájl, az már figyelmeztető jel; az utolsó lépésben térjen vissza erre.

2. Nyissa meg magát a licencfájlt

   Keresse meg a fájllistában a LICENSE, LICENSE.md vagy COPYING fájlt, és nyissa meg. Győződjön meg róla, hogy a neve megegyezik az oldalsávban láthatóval, és hogy a licenc arra a kódra vonatkozik, amelyet használni szeretne, nem csak a tároló egy különálló részére.

3. Állapítsa meg a típusát: megengedő vagy copyleft

   Az MIT, az Apache 2.0 és a BSD megengedő; zárt kereskedelmi termékben is használhatja a kódot. A GPL és az AGPL copyleft licencek; a forráskód-kötelezettségek megállapításához vizsgálja meg az érintett művet, a terjesztést és az AGPL esetleges hálózati feltételét. A név önmagában nem határozza meg, mely független komponensekre terjed ki a licenc.

4. Vesse össze a saját helyzetével

   Válaszoljon három kérdésre: értékesíti-e a terméket, módosítja-e a kódot, és zártan szeretné-e tartani a forráskódot? Az MIT, az Apache és a BSD eladásra szánt, zárt termékhez is megfelelő. GPL és AGPL esetén állapítsa meg, mely érintett vagy összekapcsolt mű megfelelő forráskódját kellene átadnia és milyen feltétel váltja ki ezt; mérlegelje, teljesíteni tudja-e a kötelezettségeket.

5. Licenc nélkül ne használja

   Ha nincs licencfájl, és a README semmit sem mond az engedélyről, nem használhatja a kódot. Írjon a szerzőnek engedélyért, vagy keressen egy megfelelő licencű, egyenértékű megoldást. A „nyilvánosan elérhető” nem jelent engedélyt.

Ez az ellenőrzés egészen addig tűnik fárasztónak, amíg a terméke növekedni nem kezd, pénzt nem hoz, és valaki rá nem kérdez a benne lévő külső kódra. Két perc az elején kevesebbe kerül, mint később egy vita rendezése. Külön írtam arról is, mit tegyen ezután a termékével, hogy ne akadjon el az indulás után: AI-val építettem terméket; mi következik.

Nyissa meg az Ailootot.