Kod z GitHuba w produkcie komercyjnym: licencje i co sprawdzić

Tworzysz produkt i znajdujesz na GitHubie gotowy fragment: bibliotekę, szablon albo cały projekt, który robi dokładnie to, czego potrzebujesz. Claude sugeruje, żeby dodać go do projektu. I wtedy się zatrzymujesz: kod wydaje się publicznie dostępny, ale czy naprawdę możesz go używać, a tym bardziej sprzedawać produkt, który go zawiera? Czy autor może później wystąpić przeciwko tobie?

Omówię to po kolei: dlaczego otwarty kod na GitHubie sam w sobie nie oznacza pozwolenia, które licencje pozwalają używać kodu i sprzedawać produkt, które warunki copyleft mogą wymagać odpowiadających źródeł objętego utworu oraz jak sprawdzić licencję w minutę przed użyciem kodu. Bez „to zależy od sytuacji”.

Praktyczne informacje o korzystaniu z Ailoot znajdziesz w dokumentacji.

Czy to prawda, że jeśli kod jest na GitHubie, możesz używać go za darmo?#

Główną pułapką jest tu słowo „otwarty”. Widzisz kod źródłowy, więc wydaje się, że skoro nie został ukryty, wolno ci go używać. To błędne rozumowanie. „Otwarty do odczytu” i „objęty licencją zezwalającą na użycie” to dwie różne rzeczy.

Domyślnie każdy utwór, w tym kod, jest chroniony prawem autorskim od chwili powstania. Dopóki autor wyraźnie nie udzieli zgody, nie wolno ci go używać. Tak opisuje to GitHub na własnej stronie z informacjami o licencjach.

Druga kwestia dotyczy samego GitHuba. Niektórzy uważają, że skoro publikując kod, zaakceptowali zasady GitHuba, mogą też używać zamieszczonego tam kodu innych osób. Zasady mówią dokładnie coś przeciwnego. Upubliczniając repozytorium, autor pozwala innym jedynie je przeglądać i forkować, czyli tworzyć kopię w samym GitHubie. Nie upoważnia to do używania kodu we własnej pracy.

Kluczowe są ostatnie słowa: „w ramach funkcji GitHuba” oraz „dodatkowe prawa przyznaje licencja”. Fork pozostaje w GitHubie. Gdy tylko zechcesz użyć kodu we własnym produkcie, a tym bardziej go sprzedawać, potrzebujesz osobnej licencji od autora. Bez licencji nie masz praw — nawet jeśli kod leży tuż przed tobą i jest widoczny dla wszystkich.

Co decyduje o tym, czy możesz używać cudzego kodu?#

Wszystko sprowadza się do jednego pliku. Prawidłowo utrzymywane repozytorium zawiera plik licencji — zwykle LICENSE, czasem LICENSE.md albo wzmiankę bezpośrednio w README. To zgoda autora określająca warunki, na jakich możesz używać kodu. GitHub zwykle wyświetla nazwę licencji na pasku bocznym strony repozytorium, zanim jeszcze otworzysz sam plik.

Aby nie zgubić się w języku prawnym, warto czytać licencję, zadając sobie trzy pytania dotyczące swojej sytuacji:

1. Czy możesz użyć tego kodu w produkcie komercyjnym, za który ludzie płacą?
2. Czy możesz modyfikować kod na własne potrzeby?
3. Czy musisz później udostępnić kod źródłowy swojego produktu, czy możesz zachować go jako zamknięty?

Prawie wszystkie różnice między licencjami sprowadzają się do różnych odpowiedzi na trzecie pytanie. Na dwa pierwsze popularne licencje open source najczęściej odpowiadają „tak”: używaj, modyfikuj, sprzedawaj. Problem pojawia się wtedy, gdy licencja wymaga udostępnienia własnego kodu. Dalej omówimy główne typy licencji, kierując się tymi trzema pytaniami.

Które licencje pozwalają używać kodu i sprzedawać produkt?#

Zacznijmy od dobrej wiadomości. Dla osoby tworzącej produkt na sprzedaż najlepszym wyborem jest grupa licencji nazywanych licencjami liberalnymi. Jest ich kilka, ale najczęściej spotyka się trzy: MIT, Apache 2.0 i BSD. Wszystkie trzy odpowiadają „tak” na dwa pierwsze pytania i pozwalają zachować własny kod źródłowy jako zamknięty.

Najpopularniejsza i najprostsza jest MIT. Jej treść mieści się w jednym akapicie.

Prościej mówiąc, MIT pozwala robić z kodem prawie wszystko, w tym sprzedawać produkt i zachować własny kod źródłowy jako zamknięty. Jedynym obowiązkiem jest dołączenie treści licencji i informacji o autorstwie. Na przykład Babel, .NET i Rails są wydawane na licencji MIT, więc niemal na pewno już korzystałeś z kodu objętego tą licencją.

Apache 2.0 działa podobnie, ale dodaje dwa ważne elementy. Po pierwsze, wyraźną ochronę przed roszczeniami patentowymi: autorzy kodu obiecują, że nie będą pozywać cię w związku z patentami dotyczącymi tego kodu. Po drugie, kilka dodatkowych formalnych wymogów dotyczących korzystania.

BSD (w wersjach z 2 i 3 klauzulami) jest zasadniczo podobna do MIT: można używać, modyfikować i sprzedawać, zachowując informację o prawach autorskich. Zestawiłem wszystkie trzy licencje w tabeli, żeby można było szybko porównać różnice.

Jak zastosować to w praktyce: jeśli przy cudzym kodzie widzisz MIT, Apache 2.0 lub BSD, możesz się nie martwić — możesz użyć go w produkcie komercyjnym, modyfikować go i zachować własny kod źródłowy jako zamknięty. Musisz tylko pamiętać, żeby nie usuwać pliku licencji i oznaczenia autorstwa z wykorzystanej części.

Jak stosuje się obowiązki źródeł GPL i AGPL?#

Copyleft zachowuje objęty utwór i pochodne na tej samej licencji przy właściwych warunkach. GPLv3 wymaga zgodności z licencją i odpowiadającymi źródłami przy rozpowszechnianiu kopii źródłowych lub wynikowych objętego utworu lub połączonej pochodnej. Nie obejmuje automatycznie każdego niezależnego programu tego samego produktu lub serwera.

W przykładzie usługi hostowanie biblioteki GPL na własnym serwerze bez dawania kopii użytkownikom samo nie wymaga publikacji całej usługi. Dystrybucja objętej połączonej aplikacji klientom może wyzwalać obowiązki GPL; przed ustaleniem źródeł sprawdź integrację i licencję. Klient przeglądarkowy dostarczany użytkownikom to osobna kwestia dystrybucji.

AGPLv3 dodaje warunek sieci: jeśli modyfikujesz program, a użytkownicy korzystają z tej wersji zdalnie, musi wyraźnie oferować im odpowiadające źródła. To dokładniejsze niż twierdzenie, że samo hostowanie dowolnego AGPL otwiera wszystkie niezależne części usługi.

Dla produktu zamkniętego sprawdź objęty utwór, sposób łączenia, dystrybucję kopii i interakcję sieciową AGPL. Wybierz zgodną liberalną alternatywę lub uzyskaj osobne pozwolenie, jeśli nie spełnisz obowiązków. Użycie komercyjne jest dozwolone; liczy się zgodność z rzeczywistą licencją i integracją.

Co zrobić, jeśli repozytorium w ogóle nie ma pliku licencji?#

Częstym błędem jest założenie, że brak licencji oznacza brak ograniczeń i pozwala swobodnie korzystać z kodu. Jest odwrotnie. Brak licencji nie oznacza zgody; domyślnie oznacza jej brak. Kod bez licencji pozostaje objęty pełną ochroną prawnoautorską autora i nie wolno go używać.

Ponownie obowiązuje zasada, od której zaczęliśmy: kod jest domyślnie chroniony prawem autorskim, a bez wyraźnej zgody nie wolno go kopiować, modyfikować ani rozpowszechniać. Możliwość przeglądania i forkowania go w GitHubie nie znosi tego ograniczenia — nie daje prawa do użycia kodu we własnym produkcie.

Co zrobić w praktyce, jeśli kod nie ma licencji, ale naprawdę go potrzebujesz:

1. Napisz do autora. Bezpośrednio w sekcji dyskusji repozytorium albo pocztą elektroniczną zapytaj, czy możesz użyć kodu i na jakich warunkach. Czasem autor po prostu zapomniał dodać licencję i zrobi to, jeśli go o to poprosisz.
2. Poszukaj zamiennika. Do niemal każdego zadania istnieje drugie, trzecie i dziesiąte podobne repozytorium — znajdziesz wśród nich takie z prawidłową licencją MIT lub Apache.
3. Nie używaj go. Jeśli nie masz zgody i nie ma zamiennika, kod nie należy do ciebie i nie możesz umieścić go w produkcie przeznaczonym na sprzedaż. Pokusa, by pomyśleć „kto się dowie?”, źle się kończy, gdy produkt zaczyna zarabiać i przyciągać uwagę.

Co jeśli Claude sam dodał do projektu cudzy kod?#

Jest tu jeszcze druga kwestia, którą łatwo pomylić z pierwszą. Gdy wchodzisz do repozytorium i kopiujesz z niego plik, wszystko, co wyżej napisano o licencji, staje się twoim bezpośrednim obowiązkiem. Inaczej jest, gdy Claude pisze kod na twoją prośbę.

W typowych przypadkach AI tworzy własny tekst dopasowany do twojego zadania, a nie kopię cudzego pliku. Wtedy pytanie przenosi się na inny obszar: kto posiada wygenerowany kod i czy można go sprzedać? To osobny, obszerny temat, który omówiłem w artykule o tym, do kogo należy kod napisany przez AI.

Warto jednak pamiętać o wyjątku. Czasami AI generuje rozpoznawalny fragment cudzego kodu niemal słowo w słowo — na przykład całą funkcję ze znanej biblioteki. W takim przypadku nadal obowiązuje licencja biblioteki, bez względu na to, kto fizycznie nacisnął klawisze. Dlatego duże gotowe fragmenty, które Claude przeniósł w całości, należy sprawdzić tak samo, jakbyś skopiował je samodzielnie.

Jak sprawdzić licencję przed użyciem kodu: kolejne kroki#

Zbierzmy wszystko w krótką listę kontrolną, która pomoże sprawdzić dowolny kod innej osoby przed dodaniem go do projektu. Przechodź kolejno od góry do dołu.

1. Znajdź nazwę licencji na stronie repozytorium

   Otwórz repozytorium na GitHubie. Nazwa licencji jest zwykle widoczna w prawej kolumnie albo pod listą plików — na przykład „MIT License”, „Apache-2.0” lub „GPL-3.0”. Jeśli pole jest puste i nie ma pliku licencji, to już sygnał ostrzegawczy; wróć do tej kwestii w ostatnim kroku.

2. Otwórz sam plik licencji

   Znajdź na liście plików LICENSE, LICENSE.md albo COPYING i otwórz go. Upewnij się, że nazwa zgadza się z tą widoczną na pasku bocznym oraz że licencja dotyczy używanego przez ciebie kodu, a nie tylko odrębnej części repozytorium.

3. Ustal typ: liberalna czy copyleft

   MIT, Apache 2.0 i BSD to licencje liberalne; możesz używać kodu w zamkniętym produkcie komercyjnym. GPL i AGPL to copyleft; sprawdź objęty utwór, dystrybucję i ewentualny warunek sieci AGPL przed ustaleniem obowiązków źródeł. Sama nazwa nie ustala zakresu niezależnych komponentów.

4. Porównaj licencję ze swoją sytuacją

   Odpowiedz na trzy pytania: czy sprzedajesz produkt, czy modyfikujesz kod i czy chcesz zachować kod źródłowy jako zamknięty? MIT, Apache i BSD pasują do zamkniętego produktu na sprzedaż. Dla GPL i AGPL ustal objęty lub połączony utwór wymagający odpowiadających źródeł i wyzwalacz obowiązku; oceń możliwość spełnienia warunków.

5. Brak licencji oznacza, że nie wolno używać kodu

   Jeśli nie ma pliku licencji, a README nie mówi nic o zgodzie, nie możesz używać kodu. Napisz do autora z prośbą o zgodę albo znajdź odpowiednik z prawidłową licencją. „Jest publicznie dostępny” nie oznacza zgody.

Ta kontrola wydaje się uciążliwa aż do chwili, gdy twój produkt urośnie, zacznie zarabiać, a ktoś zapyta o kod innych osób, który się w nim znajduje. Dwie minuty na początku kosztują mniej niż późniejsze rozwiązywanie sporu. Osobno opisuję, co zrobić z produktem po tym, żeby nie utknął po premierze: Zbudowałem produkt z AI; co dalej.

Otwórz Ailoot.