Plagiat w repozytoriach kodu i na GitHubie: kopiowanie bibliotek, snippetów i licencje open source

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

1. 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.
2. 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).
3. 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

1. 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).
2. 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.
3. 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).

Krok 2: zdecyduj — cytujesz, adaptujesz czy przepisujesz od zera

Bezpieczniej: jeśli fragment jest kluczowy i nietrywialny, potraktuj go jak import — dodaj atrybucję i warunki licencji, albo przepisz od zera po zrozumieniu idei. Ryzykownie: „przemalowanie” nazw zmiennych i usunięcie linku, żeby nie było widać źródła.

Przykład: wklejasz helper do parsowania dat. Działa, ale ma nietypowy workaround i identyczny komentarz. To jest właśnie „podpis” źródła — jeśli fragment ma zostać, lepiej dodać atrybucję (i sprawdzić licencję), niż udawać, że powstał w projekcie.

Krok 3: ustandaryzuj atrybucję snippetów

Najprościej ustalić jeden format, żeby code review było szybkie:

• krótki komentarz nad fragmentem: źródło + licencja + data pobrania,
• albo wpis w SOURCES.md / THIRD_PARTY_NOTICES z mapowaniem: plik → URL → licencja,
• jeśli to większy blok: wydziel do osobnego pliku z nagłówkiem i zachowanym notice.

Typowy błąd: dopisek „credits” w README bez wskazania, gdzie dokładnie jest ten kod i na jakich warunkach został użyty.

Co sprawdzić

• Czy fragment jest na tyle unikalny, że bez atrybucji wygląda jak przywłaszczenie autorstwa.
• Czy źródło ma jasną licencję (a jeśli nie — traktuj jak brak LICENSE).
• Czy snippet nie jest wklejony do wielu miejsc (łatwo wtedy „zgubić” atrybucję przy refaktorze).

11) Copyleft w praktyce: szybki test ryzyka dla GPL/LGPL/AGPL

Copyleft nie jest „złe”, ale jest wymagające. Problem zaczyna się wtedy, gdy zespół bierze fragment GPL „bo działa”, a potem wrzuca produkt klientowi albo publikuje SDK — i nagle robi się dyskusja o obowiązkach, których nikt nie planował.

Krok 1: rozpoznaj, czy jesteś w scenariuszu wysokiego ryzyka

Bezpieczniej: trzymasz GPL w narzędziach developerskich (np. wewnętrzne CLI) i niczego z tego nie dystrybuujesz. Ryzykownie: kod z GPL ląduje w artefakcie, który wysyłasz klientowi albo w bibliotece, którą inni linkują.

• projekt jest produktem dystrybuowanym (installer, pakiet, kontener dla klienta),
• tworzysz SDK/bibliotekę dla innych,
• włączasz kod GPL bezpośrednio do własnego kodu (kopiowanie plików/snippetów, statyczne linkowanie),
• AGPL wchodzi w grę, gdy udostępniasz funkcjonalność jako usługa i licencja tego wymaga.

Krok 2: jeśli musisz użyć copyleft — wybierz najprostszy wariant integracji

To nie jest porada prawna, tylko praktyczna heurystyka: im luźniejsze powiązanie, tym mniej niespodzianek. Czasem zamiast „wklejania” kodu lepiej:

• uruchomić komponent jako osobny proces/usługę z wyraźnym interfejsem,
• znaleźć alternatywę na MIT/Apache/BSD,
• użyć LGPL zgodnie z jej warunkami (np. dynamiczne linkowanie, jeśli pasuje do Twojej dystrybucji).

Typowy błąd: traktowanie LGPL „jak MIT”, bo „to prawie to samo”. Potem build statycznie linkuje bibliotekę i robi się trudna rozmowa o obowiązkach.

Krok 3: naprawa po fakcie (gdy copyleft wpadł do repo)

• zidentyfikuj zakres: czy to dependency, vendor, czy fragmenty wklejone do plików,
• zatrzymaj dystrybucję do czasu decyzji (jeśli to produkt),
• albo usuwasz/zastępujesz, albo dostosowujesz spełnienie warunków (w tym noty i udostępnianie źródeł, jeśli wymagane).

Co sprawdzić

• Czy w repo nie ma skopiowanych fragmentów z projektów GPL/AGPL (to często „znikające” ryzyko, bo snippet wygląda niewinnie).
• Czy pipeline nie bundluje zależności do paczki dla klienta bez świadomej decyzji licencyjnej.
• Czy masz spis komponentów copyleft i jasną decyzję: używamy / nie używamy / gdzie wolno.

12) Gdy ktoś skopiował Twój kod: ścieżka od miękkiej reakcji do formalnego zgłoszenia

Najgorszy ruch to zaczynać od publicznej awantury. Lepiej działać etapami i zbierać dowody, bo część przypadków to zwykła nieświadomość (np. skopiowane pliki bez zostawienia LICENSE).

Krok 1: zbierz dowody i sprawdź licencję swojego repo

• zapisz linki do plików/commitów po obu stronach (permalinki),
• sprawdź, czy w Twoim repo jest jasna licencja i copyright (bez tego rozmowa jest trudniejsza),
• porównaj nie tylko kod, ale też komentarze, testy, strukturę katalogów.

Bezpieczniej: masz jasny LICENSE i nagłówki w plikach. Ryzykownie: repo bez licencji — wtedy formalnie sam też nie dałeś innym jasnych warunków, a egzekwowanie bywa bardziej skomplikowane.

Krok 2: kontakt „miękki” i konkretna prośba

Najczęściej działa prosty komunikat z checklistą naprawczą:

• wskaż konkretne pliki i podobieństwa (linki),
• poproś o dodanie atrybucji i spełnienie warunków licencji (np. dołączenie LICENSE/NOTICE),
• albo o usunięcie fragmentów, jeśli licencja na to nie pozwala.

Typowy błąd: ogólne „ukradłeś mój kod” bez wskazania miejsc. Maintainer po drugiej stronie nie ma jak tego szybko zweryfikować i temat się przeciąga.

Krok 3: eskalacja — issue, raport do hostingu, formalny tryb usunięcia

• jeśli brak reakcji: publiczne issue w repo (bez obrażania, tylko fakty i wymagania licencji),
• jeśli to naruszenie praw autorskich: procedura takedown u hostingu (np. GitHub) — przygotuj linki, daty i opis, co jest Twoją własnością,
• jeśli to projekt firmowy: dołącz do zgłoszenia informację, jaka naprawa jest akceptowalna (atrybucja vs usunięcie).

Co sprawdzić

• Czy przypadkiem nie jest to fork (wtedy oczekiwania są inne, ale nadal licencja musi się zgadzać).
• Czy naruszenie dotyczy kodu, czy np. dokumentacji, testów, przykładów (te elementy też mają prawa autorskie).
• Czy masz własne repo „porządnie” oznaczone licencyjnie — to ułatwia każdą rozmowę.

13) Checklista „przed merge” dla PR-ów z cudzym kodem

• Krok 1: Czy w PR jest jasne źródło każdego większego fragmentu (link do upstream/odpowiedzi/commit)?
• Krok 2: Czy licencja źródła jest kompatybilna z Twoim projektem i sposobem dystrybucji (SaaS vs produkt dla klienta)?
• Krok 3: Czy dodano wymagane pliki: LICENSE/NOTICE/THIRD_PARTY_NOTICES oraz zachowano nagłówki w plikach?
• Krok 4: Czy w historii jest commit importujący z opisem wersji/commita źródła (zamiast „refactor”)?
• Krok 5: Czy zespół wie, co jest dependency, co jest vendorowane, a co jest snippetem (i dlaczego)?
• Krok 6: Jeśli pojawia się GPL/LGPL/AGPL — czy jest świadoma decyzja i opis integracji (a nie „przypadkiem wpadło”)?

Najczęściej zadawane pytania (FAQ)

Czy skopiowanie kodu z GitHuba to plagiat czy „tylko” naruszenie licencji?

To mogą być dwie różne rzeczy, które czasem występują jednocześnie. Plagiat dotyczy udawania autorstwa (np. w projekcie rekrutacyjnym, na uczelni, w portfolio), a naruszenie licencji/praw autorskich może wystąpić nawet wtedy, gdy wprost napiszesz, skąd kod pochodzi — wystarczy złamać warunki licencji albo kopiować bez zgody.

Krok 1/2/3 do szybkiej oceny: (1) czy w Twoim repo widać identyczne komentarze, nazwy zmiennych, kolejność funkcji, testy albo „te same bugi”? (2) czy źródło ma licencję i jaką? (3) czy spełniasz obowiązki: atrybucja, nagłówki, pliki NOTICE/THIRD_PARTY_NOTICES?

Czy publiczne repozytorium na GitHubie oznacza zgodę na użycie w projekcie komercyjnym?

Nie. Publiczne oznacza „dostępne do czytania”, a nie „do dowolnego użycia”. O tym, czy możesz kopiować, modyfikować i dystrybuować kod (zwłaszcza w produkcie komercyjnym), decyduje licencja albo osobna zgoda autora.

Typowy błąd: „repo jest publiczne, więc wrzucę fragment do aplikacji klienta”. To często kończy się blokadą wydania, gdy ktoś w audycie zauważy brak licencji lub konflikt copyleft.

Repo na GitHubie nie ma pliku LICENSE — czy mogę skopiować choćby fragment?

Bezpieczne założenie jest takie: brak licencji = „all rights reserved”. Czyli nie masz standardowej zgody na kopiowanie, modyfikację i dystrybucję. Sam fakt, że kod da się podejrzeć, nie załatwia strony prawnej.

Krok 1/2/3, żeby nie wejść na minę: (1) sprawdź, czy licencja nie jest w README, nagłówkach plików, metadanych paczki (npm/PyPI/Maven) albo w repo nadrzędnym (fork/mirror), (2) jeśli dalej brak — poproś autora o dodanie licencji i zachowaj ślad, (3) jeśli nie ma zgody, wybierz alternatywę albo napisz własną implementację na podstawie dokumentacji/specyfikacji, a nie cudzego kodu.

Czym się różni dodanie biblioteki jako dependency od skopiowania plików do repo (vendorowanie)?

Dependency (npm/pip/gradle) zostawia czytelny ślad: wersję, nazwę, często licencję w metadanych. To ułatwia audyt, aktualizacje i wykrywanie podatności. Vendorowanie (wklejenie plików biblioteki do własnego repo) bywa wygodne, ale compliance robi się trudniejsze: łatwiej „zgubić” licencję, usunąć nagłówki i nie wiedzieć, co tak naprawdę trafiło do produktu.

Praktyczny scenariusz: zespół vendoruje kawałek biblioteki „bo szybciej”, a miesiąc później nie potrafi udowodnić pochodzenia plików ani odtworzyć licencji. Audyt pyta o źródło — i release staje.

Ile linijek kodu mogę skopiować bez problemu? Czy mały snippet jest „bezpieczny”?

Nie ma magicznego limitu „X linijek”. Ryzyko zależy od tego, czy przenosisz unikalną formę (charakterystyczny układ funkcji, komentarze, nazwy, specyficzne obejścia błędów), czy tylko banalny wzorzec (np. oczywista konfiguracja). Czerwone flagi to identyczne literówki, te same komentarze, bardzo podobne nazewnictwo i ta sama kolejność kroków.

Krok 1/2/3 przed wklejeniem snippetu: (1) sprawdź licencję źródła i warunki atrybucji, (2) zachowaj informację o pochodzeniu (link + commit/plik), (3) jeśli to istotny fragment logiki produktu — częściej lepiej napisać własną wersję, niż „pożyczać” gotowca.

MIT/Apache/BSD — co muszę dołączyć do repo i do produktu, jeśli używam open source?

W licencjach permissive (MIT/BSD/Apache) zwykle kluczowe są obowiązki „notice”: zachowanie informacji o autorze/copyright oraz tekstu licencji. Apache 2.0 często wiąże się też z plikiem NOTICE (jeśli jest wymagany przez upstream) i bardziej formalnymi zapisami.

Krok 1/2/3 w praktyce: (1) nie usuwaj nagłówków licencyjnych z plików („bo przeszkadzają”), (2) trzymaj kopię licencji w repo (np. w THIRD_PARTY_NOTICES lub katalogu licenses), (3) dopilnuj, by dystrybucja produktu (instalka, paczka, obraz Docker itp.) też zawierała wymagane noty, jeśli to konieczne.

GPL/LGPL/AGPL na GitHubie — kiedy to blokuje projekt komercyjny i co można zrobić?

Copyleft (GPL/AGPL, czasem LGPL) potrafi wymusić udostępnienie kodu lub spełnienie dodatkowych warunków przy dystrybucji. Konflikt najczęściej wychodzi w dwóch sytuacjach: (1) aplikacja jest dystrybuowana do klientów (instalowana/on‑prem), (2) wchodzi AGPL, gdzie ryzyko dotyczy także modelu SaaS, bo licencja „aktywuje się” przy udostępnianiu funkcji przez sieć.

Krok 1/2/3, gdy odkryjesz GPL/AGPL tuż przed release: (1) ustal, czy to dependency bezpośrednie czy transytywne i jak jest linkowane/używane, (2) oceń model dystrybucji (instalowana vs usługa) i realny wpływ copyleft, (3) wybierz ścieżkę: zamiana na alternatywę, uzyskanie innej licencji (commercial license/dual licensing), refaktor izolujący komponent — i dopiero potem decyzja „zostaje/wywalamy”.

• Co sprawdzić przed skopiowaniem lub vendorowaniem: czy jest LICENSE/NOTICE, czy pliki mają własne nagłówki, czy repo nie jest tylko forkiem/mirrorem, czy w historii nie ma śladów copy‑paste „maskowanego” refaktorem oraz czy Twoja dystrybucja (instalka/SaaS) nie uruchamia obowiązków copyleft.

Najważniejsze punkty

• Publiczny kod na GitHubie nie jest „niczyj” — ryzyko idzie dwutorowo: plagiat (gdy przypisujesz sobie autorstwo) oraz naruszenie praw autorskich/licencji (nawet gdy autora podajesz, ale łamiesz warunki, np. usuwasz copyright notice).
• Najczęstsze miny w repo: brak LICENSE i założenie „skoro publiczne, to wolno”, vendorowanie plików biblioteki zamiast dodania dependency, mieszanie snippetów z wielu źródeł bez dokumentacji oraz odkrycie copyleft (GPL/AGPL) dopiero tuż przed release.
• Krok 1/2/3 przed skopiowaniem czegokolwiek: (1) nazwij typ użycia — dependency vs vendorowanie vs snippet; (2) znajdź i potwierdź licencję (repo, pliki, upstream); (3) przejdź na compliance: atrybucja, zachowanie nagłówków, NOTICE/THIRD_PARTY_NOTICES albo decyzja „nie używamy i szukamy alternatywy”.
• Granica „inspiracja vs kopia” jest praktyczna, nie akademicka: inspiracja to własna implementacja idei; czerwona flaga to identyczne komentarze, nazwy zmiennych, kolejność funkcji, te same literówki czy charakterystyczne obejścia błędów — takie ślady często wychodzą w code review i audycie.
• Brak pliku LICENSE traktuj jak „all rights reserved”: publiczna dostępność daje możliwość czytania, nie automatycznej zgody na kopiowanie/modyfikację/dystrybucję; zamiast copy-paste lepiej poprosić o licencję (zostawić ślad), znaleźć alternatywę albo napisać własną wersję na podstawie specyfikacji, nie cudzego kodu.