Publiczny kod na GitHubie nie jest „niczyj”. Najwięcej problemów zaczyna się od pozornie niewinnego „skopiuję tylko kawałek”, a kończy na konflikcie licencyjnym w produkcie komercyjnym, blokadzie wydania, albo zgłoszeniu DMCA. Do tego dochodzą dwa równoległe ryzyka: plagiat (udawanie autorstwa, zwłaszcza w projektach edukacyjnych i rekrutacyjnych) oraz naruszenie praw autorskich i warunków licencji open source (nawet gdy nie udajesz autora, ale łamiesz warunki użycia).
Najczęstsze „miny”, które wybuchają w repozytoriach kodu:
- brak pliku LICENSE i założenie, że „skoro publiczne, to wolno”,
- wklejanie plików z biblioteki do własnego repo zamiast dodania zależności (vendorowanie),
- mieszanie snippetów z różnych źródeł (GitHub, Stack Overflow, Gist, blogi) bez spójnej dokumentacji,
- usuwanie nagłówków licencyjnych z plików, bo „zaśmiecają kod”,
- copyleft (GPL/AGPL) w zależnościach, o którym zespół dowiaduje się dopiero przed release.
Pomocny skrót decyzyjny przed skopiowaniem czegokolwiek: (1) czy to dependency, vendorowanie czy snippet? (2) czy jest licencja? (3) jakie są obowiązki atrybucji/notice? (4) czy wchodzi w grę copyleft i w jakim modelu dystrybucji (aplikacja instalowana vs SaaS)?
Realne pytania, które pojawiają się przed skopiowaniem kodu (i muszą mieć odpowiedź)
To są pytania, które zwykle padają na PR-ach, w code review, na uczelni albo tuż przed wdrożeniem. Jeśli nie masz na nie szybkiej odpowiedzi, ryzyko rośnie skokowo.
- Czy skopiowanie kodu z GitHuba to automatycznie plagiat kodu, czy tylko naruszenie licencji?
- Czy fakt, że repo jest publiczne, oznacza zgodę na użycie w projekcie komercyjnym?
- Repo nie ma LICENSE: czy wolno użyć fragmentu, a jeśli tak, to jak bezpiecznie?
- Czym różni się dodanie biblioteki jako dependency od skopiowania jej plików do repo?
- Kiedy snippet „kilku linijek” może być problemem i jak rozpoznać czerwone flagi?
- MIT/Apache/BSD — co realnie muszę dołączyć do repo i do produktu?
- GPL/LGPL/AGPL — kiedy projekt komercyjny wpada w konflikt i co można zrobić?
- Jak naprawić sytuację, gdy kod już został wklejony bez licencji/atrybucji?
- Co zrobić, gdy ktoś skopiował moje repo na GitHubie: jakie kroki, jakie dowody, jakie zgłoszenia?
- Jak prowadzić dokumentację źródeł kodu, żeby przejść audyt i nie gasić pożarów przed release?
1) Najpierw nazwij sytuację: inspiracja, plagiat czy naruszenie licencji
Bezpieczniej vs ryzykownie: gdzie przebiega granica „zapożyczenia”
Bezpieczniej jest wtedy, gdy bierzesz ideę (np. algorytm, podejście do walidacji, sposób podziału na moduły) i tworzysz własną implementację bez kopiowania charakterystycznej formy. W praktyce oznacza to: inne nazwy, inna struktura funkcji, inne komentarze, często też inne testy i obsługa edge-case’ów.
Ryzykownie robi się wtedy, gdy kopiujesz konkretne wyrażenie — linie kodu, unikalną sekwencję instrukcji, identyczne komentarze, takie same nazwy zmiennych, a nawet tę samą kolejność funkcji w plikach. W repozytoriach łatwo to „wyczuć”, bo zostają ślady: identyczne literówki, te same specyficzne obejścia błędów, charakterystyczne nazwy helperów.
Plagiat najczęściej dotyczy sytuacji, w której przypisujesz sobie autorstwo (np. w projekcie rekrutacyjnym, w pracy zaliczeniowej, w README, w opisie portfolio). Naruszenie licencji/praw autorskich może wystąpić nawet wtedy, gdy nie udajesz autora — wystarczy, że kopiujesz bez zgody lub łamiesz warunki licencji (np. usuwasz copyright notice w MIT/Apache).
Krok 1/2/3: szybka autodiagnostyka przed PR-em
- Krok 1: porównaj „ślad” — czy masz identyczne komentarze, nazwy, kolejność kroków, te same testy, te same bugi? Jeśli tak, to nie jest „inspiracja”, tylko bardzo możliwe, że kopia.
- Krok 2: ustal źródło i licencję — link do repo, konkretne pliki/fragmenty, warunki licencji. Brak licencji traktuj jak „all rights reserved” (o tym niżej).
- Krok 3: przełącz się na tryb compliance — atrybucja, zachowanie nagłówków, pliki NOTICE/THIRD_PARTY_NOTICES, ewentualnie decyzja „nie używamy, szukamy alternatywy”.
Co sprawdzić (zanim ktoś inny to wytknie)
- Czy w commitach/PR nie ma „maskowania” copy-paste przez rename/refactor bez atrybucji.
- Czy ktoś nie wkleił kodu z repo bez licencji do produktu klienta.
- Czy w README/portfolio nie ma sformułowań sugerujących pełne autorstwo, gdy to fork lub adaptacja.
2) Zanim skopiujesz: ustal licencję (albo załóż „all rights reserved”)
Krok 1/2/3: jak znaleźć licencję w repozytorium
- Krok 1: szukaj oczywistych miejsc: plik LICENSE/LICENCE, COPYING, sekcja „License” w README, opis w nagłówku repo, metadane w rejestrach pakietów (npm, PyPI, Maven).
- Krok 2: sprawdź nagłówki plików: czasem repo ma jedną licencję, ale konkretny plik zawiera inny nagłówek (np. skopiowany z innego projektu). To częsty powód niezgodności.
- Krok 3: zweryfikuj upstream: repo może być mirrorem lub forkiem, a licencja bywa opisana w repo nadrzędnym. Patrz na linki „forked from”, referencje w README i historię commitów.
Gdy nie ma LICENSE: praktyczna zasada bezpieczeństwa
Jeśli repo nie ma licencji, nie zakładaj automatycznie, że wolno kopiować. Publiczna dostępność to tylko dostęp do treści, nie zgoda na ich dowolne użycie. W praktyce brak licencji oznacza, że autor nie udzielił standardowej zgody licencyjnej na kopiowanie, modyfikację i dystrybucję.
Co można zrobić zamiast ryzykownego copy-paste:
- poprosić o licencję (issue, e-mail, dyskusja) i zachować ślad korespondencji,
- znaleźć alternatywę o jasnej licencji (często łatwiej niż negocjować),
- napisać od zera własną implementację na podstawie dokumentacji/specyfikacji (a nie kodu),
- jeśli koniecznie używasz krótkiego fragmentu, upewnić się, że to banalny wzorzec (np. kilka oczywistych linijek konfiguracji) i nie przenosisz unikalnej formy; to jednak obszar ryzykowny i zależny od kontekstu.
Co sprawdzić (zwłaszcza w repo „bez licencji”)
- Czy w plikach są nagłówki copyright lub wzmianki o licencji mimo braku LICENSE.
- Czy fragment nie pochodzi z innego miejsca (np. komentarz z linkiem, nazwa autora, wzmianka o Stack Overflow).
- Czy to, co chcesz skopiować, nie jest kluczowym elementem produktu (im ważniejsze i większe, tym wyższe ryzyko).
3) Rozróżnij trzy tryby użycia kodu: dependency, vendorowanie, snippety (i każdy ma inne skutki)
Dependency (npm/pip/gradle): zwykle najmniej inwazyjne, ale nie „bez obowiązków”
Dodanie biblioteki jako dependency zostawia wyraźny ślad: nazwa paczki, wersja, często też deklarowana licencja w metadanych. To ułatwia audyt i aktualizacje bezpieczeństwa. Nie zwalnia jednak z obowiązków licencyjnych, szczególnie w licencjach wymagających zachowania notice.
Bezpieczniej: dependency ma jasno określoną licencję (MIT/Apache/BSD) i potrafisz wygenerować listę zależności oraz ich licencji do dokumentacji produktu.
Ryzykownie: dependency ma GPL/AGPL, a Twój produkt ma być zamknięty lub dystrybuowany do klientów; ryzyko rośnie też przy zależnościach transytywnych, gdzie copyleft „wchodzi” niepostrzeżenie.
Vendorowanie (kopiowanie plików biblioteki do repo): wygoda dziś, problem jutro
Vendorowanie oznacza, że bierzesz cudze pliki (czasem całe katalogi) i wrzucasz do własnego repo. Technicznie działa, ale compliance robi się trudniejsze: łatwiej usunąć nagłówki, łatwiej zgubić tekst licencji, trudniej śledzić aktualizacje i podatności, trudniej też udowodnić pochodzenie w razie sporu.
Bezpieczniej: vendorujesz tylko wtedy, gdy licencja na to pozwala, zachowujesz nagłówki i dołączasz pełny tekst licencji oraz informację o modyfikacjach (jeśli wymagana). Tworzysz też mechanizm aktualizacji (np. skrypt, submodule, wyraźny folder vendor/ z opisem źródła).
Ryzykownie: kopiujesz pliki, zmieniasz nazwy, usuwasz komentarze i licencję „żeby było czysto”, a potem publikujesz repo lub dystrybuujesz aplikację. Wtedy problemem jest nie tylko licencja, ale i zarzut plagiatu (wygląda jak „Twoje”).
Snippety: kilka linijek, które potrafią zostawić duży ślad
Snippety są zdradliwe, bo wiele osób uważa je za „zbyt krótkie, żeby miały znaczenie”. W praktyce ryzyko zależy od tego, czy fragment jest banalny i typowy, czy jednak unikalny (np. charakterystyczny workaround, specyficzne mapowanie danych, niestandardowa walidacja).
Czerwone flagi przy snippetach:
- identyczne komentarze (zwłaszcza z datami, nazwiskami, linkami),
- specyficzne nazwy zmiennych/funkcji, których sam byś nie wymyślił,
- ta sama kolejność kroków i identyczne formatowanie,
- ten sam błąd lub to samo „dziwne” obejście edge-case’u,
- identyczne testy jednostkowe lub fixtures.
Krótki przykład z praktyki repo: „wklejony plik” bez nagłówka
Zespół kopiuje pojedynczy plik z biblioteki na licencji MIT do własnego projektu, bo „to tylko jeden helper”. Po drodze usuwa nagłówek z copyright notice i nie dołącza tekstu licencji. Technicznie kod działa, ale warunek MIT o zachowaniu notice przestaje być spełniony. Naprawa zwykle polega na przywróceniu nagłówka, dodaniu tekstu licencji do repo i dopisaniu atrybucji w pliku typu THIRD_PARTY_NOTICES.
Co sprawdzić
- Czy wklejony fragment nie zawiera wewnątrz informacji licencyjnej (nagłówek pliku, komentarz).
- Czy forma użycia (dependency vs vendor) nie zmienia obowiązków licencyjnych.
- Czy w projekcie masz miejsce na dokumentację third-party (NOTICE/THIRD_PARTY_NOTICES).
4) Czytanie licencji bez prawniczego wykładu: co realnie musisz zrobić (MIT/Apache/BSD vs GPL/LGPL/AGPL)
Licencje permiswne (MIT/BSD/Apache-2.0): „możesz dużo”, ale zostaw ślady
MIT/BSD są popularne, bo zwykle pozwalają na użycie komercyjne, modyfikacje i dystrybucję. Rdzeń obowiązków jest prosty: zachowaj informację o prawach autorskich i tekst licencji w dystrybucji (w repo, w paczce, w dokumentacji produktu — zależnie od modelu).
Apache-2.0 też jest permiswna, ale częściej wymaga dodatkowej uwagi na element NOTICE i sposób informowania o zmianach, jeśli modyfikujesz pliki. Praktycznie: nie wycinaj nagłówków, pilnuj pliku NOTICE, jeśli jest w repo upstream.
Bezpieczniej: utrzymujesz plik THIRD_PARTY_NOTICES lub NOTICE, a w repo trzymasz kopie licencji zależności (albo automatycznie generujesz listę licencji w pipeline).
Ryzykownie: „czyścisz” cudzy kod z nagłówków i commitujesz jako własny, zwłaszcza w projekcie publicznym.
Copyleft (GPL): kiedy zaczyna „ciągnąć” cały projekt
Licencje typu GPL są zaprojektowane tak, by przy dystrybucji dzieł zależnych utrzymać wolność użytkowników. W ujęciu praktycznym to często oznacza: jeśli dystrybuujesz program będący dziełem zależnym od kodu GPL, możesz mieć obowiązek udostępnić kod źródłowy na warunkach GPL.
Najwięcej nieporozumień bierze się z uproszczenia „używam biblioteki, więc cały mój projekt musi być GPL”. To nie zawsze działa tak prosto. Krok 1: ustal, czy w ogóle dochodzi do dystrybucji. Jeśli kod działa tylko wewnętrznie (np. narzędzie firmowe nieopuszczające organizacji), typowe obowiązki copyleft związane z przekazaniem źródeł zwykle nie „odpalają się” tak jak przy dostarczaniu produktu klientom. Krok 2: ustal, czy tworzysz dzieło zależne (a nie tylko uruchamiasz osobny program obok). Granice bywają nieostre, ale praktycznie: statyczne linkowanie i wbudowanie kodu częściej zwiększa ryzyko „zarażenia” niż uruchamianie niezależnego procesu po API/CLI.
Jeśli planujesz użyć komponentu na GPL, zrób to tak, żeby nie wpaść w pułapkę „wkleiliśmy i jakoś będzie”. Krok 1: wybierz architekturę — osobny serwis/proces z jasno opisanym interfejsem daje więcej opcji niż sklejenie w jedną binarkę. Krok 2: sprawdź, co faktycznie dystrybuujesz (kontener do klienta? instalator? appliance?) i czy wraz z tym nie przekazujesz części GPL jako integralnej części produktu. Typowy błąd: aplikacja komercyjna w Dockerze, a w środku „przy okazji” biblioteka GPL; po chwili nikt nie wie, co jest Twoje, co cudze, a obowiązki licencyjne robią się nagle realne.
W praktyce często pada pytanie: „OK, to może LGPL?”. LGPL bywa kompromisem: pozwala na użycie biblioteki w projektach zamkniętych, ale stawia warunki (np. umożliwienie podmiany/ponownego linkowania biblioteki, zachowanie licencji i notice, udostępnienie zmian w samej bibliotece). Krok 1: sprawdź sposób linkowania (dynamiczne vs statyczne) i mechanizm aktualizacji. Krok 2: oddziel zmiany w upstream — jeśli modyfikujesz samą bibliotekę LGPL, te zmiany zwykle muszą pozostać dostępne na warunkach LGPL, nawet jeśli reszta aplikacji jest zamknięta.
Osobną kategorią jest AGPL, która dopina „dziurę SaaS”. Jeśli udostępniasz aplikację po sieci (hostowana usługa) i w środku jest komponent AGPL będący częścią tego, co użytkownik faktycznie używa, możesz mieć obowiązek udostępnić źródła także w modelu bez klasycznej dystrybucji. Typowy błąd: „to tylko backend, nikt nie dostaje binarki, więc nie musimy nic robić” — przy AGPL to założenie potrafi być po prostu fałszywe. Krok 1: sprawdź, czy komponent AGPL nie jest w ścieżce krytycznej usługi. Krok 2: zdecyduj zawczasu: otwierasz odpowiednią część, kupujesz licencję komercyjną (jeśli dual licensing istnieje), albo szukasz alternatywy na licencji permiswnej.
Co sprawdzić
- Krok 1: czy projekt będzie dystrybuowany (klientom, partnerom, jako instalator/obraz) czy tylko uruchamiany wewnętrznie.
- Krok 2: czy integracja z komponentem copyleft wygląda jak dzieło zależne (wbudowanie/linkowanie/vendorowanie) czy raczej współpraca przez osobny proces/protokół.
- Krok 3: czy nie wpadłeś w AGPL w modelu „usługa”, oraz czy istnieje dual licensing albo zamiennik o jaśniejszych warunkach.
Jeśli w repo jest cudzy kod, zostaw po nim uczciwy ślad: licencję, notice, źródło i jasny opis sposobu użycia. Najwięcej problemów nie wynika z samego użycia open source, tylko z tego, że po kilku miesiącach nikt nie potrafi odpowiedzieć na trzy proste pytania: skąd to jest, na jakiej licencji i czy spełniamy warunki.
5) Atrybucja i „ślady” w repo: jak przypisać autorstwo i nie zniszczyć historii
Najwięcej „plagiatowych” dram wynika z prostego błędu: kod jest użyty legalnie (licencja na to pozwala), ale w repo wygląda, jakby był w 100% Twojego autorstwa. To psuje relacje, utrudnia audyt i w razie sporu stawia Cię w złym świetle.
Krok 1: zostaw atrybucję tam, gdzie jej szukają ludzie i narzędzia
Atrybucja ma działać w praktyce, a nie tylko „gdzieś w mailu”. Najczęściej sprawdzają to: reviewerzy, compliance, a czasem autor upstreamu.
Bezpieczniej:
- zachowujesz nagłówki w plikach (copyright/licencja),
- dodajesz wpis w THIRD_PARTY_NOTICES (albo NOTICE) z nazwą projektu, linkiem i licencją,
- w README (lub w docs) dopisujesz krótki akapit „Third-party” dla istotnych komponentów,
- jeśli vendorujesz: trzymasz to w wyraźnym katalogu (vendor/, third_party/) z plikiem źródłowym SOURCE / ORIGIN.
Ryzykownie: wrzucasz cudzy plik do src/, usuwasz nagłówek i nie zostawiasz żadnego tropu. Nawet przy MIT/Apache to prosta droga do naruszenia warunków licencji i zarzutu „udawania autorstwa”.
Krok 2: nie fałszuj historii — importuj kod tak, żeby było wiadomo „skąd”
Nie trzeba robić perfekcyjnej rekonstrukcji historii git, ale dobrze, by repo miało czytelny punkt „tu wzięliśmy upstream”.
Praktyczne opcje (od najprostszej):
- Commit importujący z jasnym opisem: „Import X v1.2.3 (MIT) z <URL>”.
- Submodule/subtree (gdy chcesz zachować historię i ułatwić aktualizacje).
- Fork, jeśli planujesz dłużej utrzymywać zmiany i chcesz je upstreamować.
Typowy błąd: „squash wszystkiego” i opis commita typu „refactor”, po czym nie da się odróżnić cudzych plików od własnych. To utrudnia też naprawę, gdy pojawi się CVE albo prośba o usunięcie fragmentu.
Krok 3: oznacz modyfikacje, jeśli licencja tego oczekuje (albo jeśli to po prostu uczciwe)
Apache-2.0 lubi, gdy modyfikacje są czytelnie oznaczone; przy vendorowaniu to i tak dobra praktyka. Najprościej: krótki komentarz w nagłówku pliku „Modified by …” albo wpis w PATCHES.md / CHANGES w katalogu vendora.
Bezpieczniej: trzymasz listę poprawek (nawet 3 linijki) i linkujesz do upstream. Ryzykownie: „przepisałeś pół pliku”, ale repo nadal wygląda jak czysty upstream — potem ktoś wkleja Twoje poprawki dalej i robi się chaos z autorstwem.
Krótki przykład: README z wdzięcznością vs realna atrybucja
Zespół dopisuje w README: „thanks to X”, ale jednocześnie usuwa nagłówki licencyjne z plików i nie dołącza tekstu licencji. To nie jest spełnienie warunków MIT/Apache — to tylko grzeczność. Naprawa: przywrócić nagłówki, dołączyć licencję i dodać wpis do THIRD_PARTY_NOTICES.
Co sprawdzić
- Czy w repo da się w 30 sekund znaleźć: źródło, licencję i zakres użycia cudzych fragmentów.
- Czy import/upstream jest udokumentowany w historii git (commit message, tag wersji, link).
- Czy nagłówki w plikach i pliki NOTICE/LICENSE nie zostały „posprzątane” przez formatter lub automatyczne narzędzia.
6) Brak pliku LICENSE: domyślnie traktuj jak „all rights reserved”
Publiczne repo bez licencji to jedna z najczęstszych pułapek. Kod jest widoczny, ale to nie to samo co „wolno używać”. Jeśli autor nie udzielił licencji, prawnie zostajesz bez zgody na kopiowanie (poza wyjątkami typu cytat, które w kodzie i tak rzadko są prostą odpowiedzią).
Krok 1: sprawdź, czy licencja nie jest „ukryta”
Zdarza się, że licencja jest w nietypowym miejscu albo w metadanych.
- sprawdź root repo: LICENSE, LICENSE.txt, COPYING,
- sprawdź nagłówki plików (czasem każdy plik ma własny notice),
- sprawdź paczkę: package.json / pyproject.toml / pom.xml (pole license),
- sprawdź release notes i stronę projektu (czasem jest tam informacja o licencji).
Krok 2: jeśli licencji nie ma — wybierz jeden z bezpiecznych wariantów
Bezpieczniej:
- nie kopiujesz — traktujesz kod jako inspirację i piszesz własną implementację (uważając, by nie przepisać „linia po linii”),
- prosisz autora o licencję (issue lub mail) i czekasz na jednoznaczną zgodę,
- szukasz alternatywy o jasnej licencji (często to najszybsze w projektach komercyjnych).
Ryzykownie: „przecież to GitHub” + kopiuj/wklej + publikacja w swoim repo. To klasyczny scenariusz naruszenia praw autorskich, nawet jeśli nie ma złej woli.
Krok 3: jeśli już skopiowałeś — napraw, zanim kod pójdzie dalej
- usuń fragment/plik z repo (albo zastąp własną implementacją),
- wyczyść historię tylko jeśli musisz (często wystarczy nowy commit usuwający, a nie force-push),
- zostaw notatkę w PR/issue: dlaczego zmieniono i jaki jest zamiennik,
- jeśli autor odpowie i udzieli licencji — dopiero wtedy wróć do użycia (z pełną atrybucją).
Co sprawdzić
- Czy repo, z którego kopiujesz, ma jednoznaczny grant licencyjny (nie „gdzieś w komentarzu”).
- Czy licencja dotyczy całości repo, czy tylko części (np. assets, przykłady, testy).
- Czy w Twoim repo nie ma „osieroconych” plików bez pochodzenia (częsty efekt copy-paste).
7) Jak rozpoznać, że „inspiracja” zaczyna wyglądać jak plagiat
Nie ma magicznej liczby linijek. W praktyce liczy się: unikalność fragmentu, podobieństwo struktury i to, czy Twoje repo wygląda, jakbyś próbował ukryć źródło.
Krok 1: przeanalizuj podobieństwo na trzech poziomach
- Poziom 1: tekst — identyczne linie, komentarze, nazwy zmiennych, „literówki” i charakterystyczne formatowanie.
- Poziom 2: struktura — te same pliki, te same moduły, podobny układ katalogów i identyczne API.
- Poziom 3: zachowanie — te same edge-case’y, te same ograniczenia i te same „dziwne” obejścia.
Bezpieczniej: inspirujesz się ideą (algorytm, podejście), ale implementacja i nazewnictwo są Twoje, a jeśli przejmujesz niebanalny fragment — dodajesz atrybucję. Ryzykownie: kopiujesz strukturę + komentarze + testy, a potem tylko „przemalowujesz” nazwy klas.
Krok 2: zwróć uwagę na „ślady ukrywania”
Samo podobieństwo może wynikać z tego, że problem jest standardowy. Za to ślady ukrywania źródła wyglądają źle niemal zawsze:
- usunięte nagłówki i licencje w skopiowanych plikach,
- sztuczne, masowe zmiany formatowania bez sensu technicznego,
- przepisane komentarze tak, by nie było linków/nazwisk, ale sens i układ zostają ten sam,
- commit, który wrzuca „Twoje” pliki, choć wcześniej były gdzie indziej.
Krok 3: szybki krok naprawczy, zanim sprawa urośnie
- dodaj atrybucję i licencję (gdy licencja pozwala),
- jeśli nie pozwala lub nie ma licencji — usuń i zastąp,
- jeśli to fork — nazwij go forkiem, zostaw link do upstream i nie udawaj niezależnego autorstwa,
- jeśli wziąłeś tylko pomysł — dopisz w docs inspirację (to często rozbraja konflikt zanim się zacznie).
Co sprawdzić
- Czy w Twoim repo są identyczne komentarze/zmienne/testy jak w źródle.
- Czy ktoś w zespole nie „przyniósł” kodu z poprzedniej pracy/projektu bez zgody (to częsty, trudny przypadek).
- Czy repo ma jasny opis: co jest Twoje, a co jest wzięte z zewnątrz.
8) Mini-checklista przed publikacją repo lub release’em
- Krok 1: wypisz wszystkie zależności (w tym transitive) i sprawdź, czy ich licencje pasują do modelu dystrybucji (komercja, SaaS, on-prem).
- Krok 2: dla vendora/snippetów dodaj: źródło (URL), wersję/commit, licencję, atrybucję i pełny tekst licencji (jeśli wymagany).
- Krok 3: upewnij się, że nagłówki w plikach nie zostały usunięte przez „cleanup” lub formatowanie.
- Krok 4: sprawdź repo bez LICENSE w historii „skąd to jest” — jeśli nie umiesz wskazać pochodzenia, traktuj to jako ryzyko i usuń/zastąp.
- Krok 5: jeśli pojawia się GPL/LGPL/AGPL — zatrzymaj się i rozrysuj integrację (linkowanie, dystrybucja, SaaS), zanim kod pójdzie do klientów.
9) Używasz biblioteki jako dependency? Zadbaj o licencję, ale nie „wciągaj” jej do swojego repo bez potrzeby
Najwięcej bałaganu powstaje, gdy zespół miesza dwa światy: deklaruje zależność w managerze paczek, a równolegle kopiuje kawałki tej samej biblioteki do repo „na szybko”. Potem nie wiadomo, co podlega jakiej licencji i skąd pochodzi konkretna linijka.
Krok 1: zdecyduj, czy naprawdę potrzebujesz kopiować kod do repo
Bezpieczniej: używasz biblioteki jako dependency i trzymasz się standardowego mechanizmu (npm/pip/Maven/NuGet). Ryzykownie: „vendorujesz” pliki, bo tak szybciej, a przy okazji gubisz licencję albo mieszasz wersje.
- Dependency — zwykle najmniej ryzykowne organizacyjnie: jasna wersja, łatwiejsze aktualizacje, mniej wątpliwości „kto jest autorem”.
- Vendorowanie — ma sens, gdy musisz patchować, działać offline albo zamrozić kod, ale wymaga dyscypliny (LICENSE/NOTICE, źródło, wersja).
- Snippety — kuszące, bo „to tylko 10 linijek”, ale łatwo wnieść fragment z niekompatybilną licencją lub bez atrybucji.
Krok 2: sprawdź obowiązki licencyjne w kontekście dystrybucji
W praktyce pytanie brzmi: czy tylko uruchamiasz kod (SaaS), czy go dystrybuujesz (aplikacja dla klienta, SDK, biblioteka, kontener sprzedawany jako produkt). To wpływa na to, czy i jakie noty/licencje musisz dołączyć.
Przykład: aplikacja desktopowa bundluje zależności i wysyła je do klienta. To już dystrybucja — zwykle musisz dołączyć noty/licencje, a przy copyleft zatrzymać się i rozrysować obowiązki.
Krok 3: utrzymaj „dowód pochodzenia” zależności
- zapisz wersję (lockfile, tag) i źródło (registry/repo),
- trzymaj listę zależności i licencji w jednym miejscu (np. generowany raport + THIRD_PARTY_NOTICES),
- nie kopiuj plików z node_modules/site-packages do repo „bo build tak wymaga” — lepiej popraw pipeline.
Typowy błąd: zależność ma MIT, ale w środku zawiera pliki na innych warunkach (np. fonty, obrazki, fragmenty kodu z osobnymi notice). Jeśli bundlujesz całość do produktu, to potrafi wrócić jak bumerang.
Co sprawdzić
- Czy Twoja dystrybucja faktycznie „dostarcza” cudzy kod użytkownikowi (np. bundling, statyczne linkowanie, obraz kontenera dla klienta).
- Czy nie masz „podwójnego użycia” tej samej biblioteki: raz jako dependency, raz jako skopiowane pliki.
- Czy w zależnościach nie ma plików z osobnymi licencjami (NOTICE w paczce, licencje zasobów).
10) Snippety z GitHuba i Stack Overflow: traktuj je jak mini-zależności z własnymi zasadami
Ryzyko nie bierze się z długości fragmentu, tylko z jego rozpoznawalności i tego, czy przenosisz unikalną konstrukcję „jeden do jednego” (czasem razem z komentarzem, błędem lub literówką). Do tego dochodzi licencja źródła — snippet też może ją mieć.
Krok 1: ustal, skąd naprawdę pochodzi fragment
Bezpieczniej: link do konkretnego miejsca (commit/permalink, odpowiedź na SO) i zapis źródła w repo. Ryzykownie: fragment krąży po teamie wklejany do kolejnych projektów, a po miesiącu nikt nie pamięta, czy to było z dokumentacji, czy z cudzego repo.
- GitHub: używaj permalinków do plików/linijek (konkretny commit),
- Stack Overflow: sprawdź warunki użycia/licencję treści i nie zakładaj, że „odpowiedź w internecie” jest wolna od ograniczeń,
- dokumentacje vendorów: często mają osobne warunki dla przykładowego kodu (czasem bardzo liberalne, czasem nie).