Zespół kończy sprint, a w płatnej aplikacji brakuje jeszcze jednego modułu. Ktoś wrzuca link do publicznego repozytorium na GitHubie: „Weźcie to, i tak leży otwarte”. Build przechodzi, klient płaci, a dopiero przy due diligence okazuje się, że w katalogu nie ma pliku LICENSE, a w README widnieje zdanie „do użytku niekomercyjnego”.
Publiczny adres URL nie jest zgodą na sprzedaż produktu. Zanim fragment kodu albo cała biblioteka trafi do aplikacji komercyjnej, trzeba ustalić, kto ma prawa autorskie, jaka licencja obowiązuje i czy jej warunki da się spełnić bez otwierania własnego kodu. [1]
Publiczne repozytorium to nie domena publiczna: punkt wyjścia dla kodu komercyjnego
Cel tej weryfikacji jest prosty: odpowiedzieć, czy dany fragment można legalnie wbudować w płatny produkt, SaaS albo aplikację wewnętrzną sprzedawaną klientom. Kolejność jest stała. Najpierw pochodzenie i licencja, potem zależności, na końcu atrybucja i ślad w dokumentacji wydania. Repozytorium bez jasnej licencji odpada od razu, nawet jeśli kod wygląda na porzucony.
Kod widoczny dla wszystkich a prawo do komercyjnej eksploatacji
GitHub pokazuje pliki, historię commitów i często możliwość sklonowania repozytorium. To funkcja hostingu, nie przeniesienie praw. Komercyjne użycie kodu z GitHuba obejmuje wklejenie funkcji do zamkniętej aplikacji, osadzenie biblioteki w instalatorze, uruchomienie jej po stronie serwera oraz modyfikację i dalszą dystrybucję. Każdy z tych scenariuszy wymaga osobnej podstawy prawnej.
Domena publiczna to inny stan. Powstaje, gdy prawa wygasły albo autor świadomie zrzekł się ich w sposób rozpoznawalny, na przykład licencją CC0 albo dedykacją „Unlicense”, o ile tekst jest kompletny i pochodzi od uprawnionego. Zwykły komentarz „róbcie z tym, co chcecie” w issue nie zastępuje licencji, bo nie wiadomo, czy napisał go właściciel praw i czy obejmuje cały kod, w tym późniejsze commity.
Fork też niczego nie „uwalnia”. Jeśli oryginał był na MIT, fork dziedziczy obowiązek zachowania noty. Jeśli oryginał nie miał licencji, fork nadal nie daje prawa do kopiowania. Gwiazdki, wysoka liczba pobrań i aktywny maintainer nie są substytutem zgody.
Brak licencji oznacza zastrzeżenie praw, nie zaproszenie
Prawo autorskie powstaje z chwilą ustalenia utworu. Autor nie musi rejestrować kodu ani dodawać nagłówka „copyright”, żeby zakazać kopiowania. Brak pliku LICENSE czytamy więc jako „wszelkie prawa zastrzeżone”, a nie jako lukę, którą można wypełnić własną interpretacją.
Dotyczy to także krótkich snippetów z Gista, przykładów w issues i fragmentów wklejonych w dyskusji pull requestu. Krótki fragment bywa trudny do ochrony, gdy jest banalny albo dyktowany jedynym sensownym sposobem zapisu API, ale to wyjątek oceniany indywidualnie, nie zasada „poniżej 15 linii wolno”. W produkcie komercyjnym bezpieczniej przepisać logikę samodzielnie albo dostać pisemną zgodę.
Pierwsza decyzja operacyjna: repozytorium bez pliku LICENSE, bez nagłówka licencyjnego i bez jednoznacznego oświadczenia uprawnionego nie wchodzi do gałęzi release. Nie „na razie”, nie „do czasu, aż autor odpisze”. Odpowiedź po wydaniu nie cofa już rozdystrybuowanego builda.
Regulamin GitHuba nie zastępuje licencji na wdrożenie
Regulamin serwisu określa relację użytkownika z GitHubem: hosting, widoczność, zgłoszenia bezpieczeństwa, czasem ograniczoną licencję potrzebną samemu serwisowi do wyświetlenia repozytorium. Nie przyznaje obcej firmie prawa do wbudowania cudzego kodu w aplikację sprzedawaną klientom.
Przycisk „Use this template”, automatyczne cytowanie w Copilocie albo cache menedżera pakietów również nie tworzą nowej licencji. Źródłem warunków pozostaje plik licencji dołączony przez uprawnionego albo umowa zawarta z nim bezpośrednio. Jeśli licencja jest, czytamy jej tekst z tagu, który faktycznie wchodzi do produktu, a nie z gałęzi main sprzed roku.
Identyfikacja licencji: permisywność kontra wirusowy copyleft
Gdy plik LICENSE istnieje, drugi krok to klasyfikacja, nie cytowanie marketingowego opisu z README. Licencje open source dzielą się praktycznie na permisywne, słaby copyleft i silny copyleft. Od tej klasy zależy, czy zamknięta aplikacja może zostać zamknięta.
Licencje permisywne – zielone światło dla biznesu (MIT, Apache 2.0, BSD)
MIT, BSD-2-Clause, BSD-3-Clause i ISC pozwalają używać kodu w aplikacji komercyjnej, modyfikować go i dystrybuować w formie binarnej. Twardy obowiązek jest zwykle jeden: zachować notę o prawach autorskich i tekst licencji. BSD-3-Clause dokłada zakaz używania nazw autorów do promocji bez zgody. ISC jest krótka, ale nadal wymaga zachowania warunków z pliku. [4]
Apache 2.0 dodaje warstwę, która w produkcie z własnymi patentami bywa ważniejsza niż sam copyright. Licencja zawiera udzielenie licencji patentowej przez kontrybutorów oraz klauzulę wygaśnięcia, gdy licencjobiorca pozywa o naruszenie patentu związanego z oprogramowaniem. Do tego dochodzą obowiązki przy modyfikacji: oznaczenie zmienionych plików i, jeśli są, zachowanie pliku NOTICE. Samo skopiowanie katalogu src bez NOTICE jest typowym błędem przy „czystej” integracji.
MIT a komercja nie oznacza „zero formalności”. Nota może trafić do ekranu About, pliku THIRD-PARTY-NOTICES albo dokumentacji instalatora. Usunięcie nagłówka „bo psuje branding” łamie warunek nawet bardzo liberalnej licencji. Permisywność nie kasuje też znaków towarowych: nazwa biblioteki w logo produktu może wymagać osobnej zgody, choć sam kod wolno linkować.
Licencje z silnym copyleftem – pułapka na kod zamknięty (GPL, AGPL)
GPL, a zwłaszcza GPLv3 i AGPL, nie zabrania zarabiania. Zabrania dystrybucji dzieła zależnego na warunkach, które zamykają kod źródłowy przed odbiorcą. Mechanizm copyleftu uruchamia się, gdy cudzy kod i własny kod tworzą jeden program: statyczne linkowanie, wklejenie funkcji, wspólny proces z wymienianymi strukturami, czasem też dynamiczne łączenie, jeśli powstaje dzieło pochodne. Granica bywa sporna, dlatego w zamkniętym produkcie nie warto „testować” jej na kliencie.
Sam fakt, że aplikacja jest płatna, nie jest problemem. Problemem jest odmowa udostępnienia odpowiadającego źródła osobom, które dostały binarkę, oraz nakładanie dodatkowych ograniczeń sprzecznych z GPL. Licencja GPL w biznesie działa więc tam, gdzie model zakłada otwarte źródła, sprzedaż wsparcia albo appliance z jasną polityką udostępniania kodu. Nie działa jako cichy składnik desktopowego produktu „source available tylko dla nas”.
AGPL zaostrza to dla modelu sieciowego. Samo udostępnianie funkcji przez sieć użytkownikom zewnętrznym może rodzić obowiązek przekazania źródła zmodyfikowanej wersji, nawet jeśli binarka nigdy nie opuszcza serwera. Wewnętrzne narzędzie używane wyłącznie przez pracowników tej samej organizacji bywa oceniane inaczej niż SaaS dla klientów, ale klauzule AGPL czytamy dosłownie, zanim biblioteka wejdzie do ścieżki żądania HTTP. „Przecież to tylko middleware” nie jest argumentem, jeśli middleware jest zmodyfikowany i stanowi część usługi.
Licencje hybrydowe i słaby copyleft (LGPL, MPL)
LGPL i MPL pozwalają często zachować zamknięty kod aplikacji nadrzędnej, o ile biblioteka pozostaje wydzielona. Przy LGPL typowe warunki to możliwość podmiany biblioteki przez użytkownika: dynamiczne linkowanie, dostarczenie plików obiektowych albo inny sposób relinkowania, plus udostępnienie źródła samej biblioteki, jeśli została zmieniona. Statyczne wtopienie LGPL w jeden plik wykonywalny bez drogi podmiany zwykle psuje ten układ.
MPL działa plikowo: zmiany w plikach objętych MPL zostają na MPL, a własne pliki mogą mieć inną licencję. Pułapka polega na refaktorze, który przenosi fragmenty między plikami i zaciera granicę. Izolacja ma być techniczna i widoczna w repozytorium, nie tylko opisana w wiki.
Wniosek z tej klasyfikacji: permisywna licencja na korzeniu repozytorium nie kończy analizy, jeśli komponent owija kod na GPL albo AGPL. Klasę licencji zapisujemy przy każdej zależności, nie przy „głównej” bibliotece, którą widać w package.json.
| Licencja | Aplikacja zamknięta | Typowy obowiązek | Sygnał ostrzegawczy |
|---|---|---|---|
| MIT, BSD, ISC | Zwykle tak | Nota copyright i tekst licencji | Dodatkowe „non-commercial” w README |
| Apache 2.0 | Zwykle tak | NOTICE, oznaczenie zmian, patent grant | Usunięty NOTICE przy rebrandingu |
| LGPL, MPL | Tak, przy izolacji | Źródło zmian biblioteki, możliwość podmiany | Statyczne zlanie w jeden binarny blob |
| GPL | Ryzykowne przy dystrybucji | Źródło dzieła zależnego dla odbiorców binarki | Linkowanie do zamkniętego core |
| AGPL | Ryzykowne także w SaaS | Źródło przy udostępnianiu przez sieć | Modyfikacja serwera bez polityki źródła |
Procedura weryfikacji i integracji kodu krok po kroku
Procedura ma trzy bramki. Niezaliczenie którejkolwiek zatrzymuje merge. Nie zastępujemy jej „szybką zgodą tech leada na Slacku”, bo ta zgoda nie tworzy licencji i ginie przy rotacji zespołu.
Krok 1: Walidacja pochodzenia i historii repozytorium
Otwieramy tag albo commit, który realnie wejdzie do lockfile’a, nie stronę główną projektu. Szukamy pliku LICENSE albo COPYING, nagłówków SPDX w źródłach i sekcji licencyjnej w README. Jeśli te trzy miejsca się rozmijają, wygrywa surowszy sensowny odczyt do czasu wyjaśnienia z maintainerem. SPDX „MIT” w jednym pliku i GPL w innym to konflikt, nie wybór wygodniejszej etykiety.
Potem historia. Kod mógł wejść z cudzego repozytorium bez licencji, z generowanego wyjścia modelu albo z przykładowych plików „tylko do testów”. Przegląd nie musi oznaczać ręcznego czytania pięciu tysięcy commitów. Wystarczy sprawdzić, czy maintainer wymaga Developer Certificate of Origin, CLA albo podpisu, i czy w logu nie ma hurtowego importu oznaczonego „vendored from …” bez śladu licencji. Brak CLA nie dyskwalifikuje projektu permisywnego, ale zwiększa ryzyko, że kontrybutor wgrał kod, do którego nie miał praw.
Zapisujemy: URL, commit SHA, identyfikator licencji, właściciela praw jeśli da się go ustalić, datę przeglądu i osobę, która podjęła decyzję. Ten rekord zostaje przy artefakcie wydania. Screenshot README znika przy następnym redesignie strony projektu.
Krok 2: Audyt zależności pośrednich
Biblioteka na MIT może ciągnąć moduł na GPL. To ukryty copyleft w łańcuchu dostaw: aplikacja nie linkuje GPL bezpośrednio, ale drzewo zależności i tak je dostarcza. Skan obejmuje npm, Maven, pip, NuGet, Cargo, Go modules i vendoring w katalogu third_party. Narzędzia w rodzaju licensee, ScanCode, FOSSA, ORT albo wbudowane raporty license menedżera pakietów dają listę, nie wyrok. Fałszywe wykrycie „GPL” bywa skutkiem skopiowanego nagłówka w teście. Fałszywy „MIT” bywa skutkiem licencji tylko na korzeniu, podczas gdy podkatalog vendor ma własny plik.
Konflikt rozstrzygamy przed mergem. Opcje są konkretne: podmienić zależność, odciąć opcjonalny plugin, uzyskać inną licencję od autora albo świadomie przyjąć copyleft na cały dystrybuowany produkt. „Zostawiamy, bo to devDependency” działa wyłącznie wtedy, gdy pakiet nie trafia do obrazu produkcyjnego, instalatora ani artefaktu klienta. Bundler, który wciąga devDependency do binarki, unieważnia to założenie. Trzeba to sprawdzić na artefakcie, nie na intencji autora package.json.
Krok 3: Spełnienie warunków formalnych
Atrybucja jest częścią produktu, nie zadania „na kiedyś”. Dla MIT i BSD wystarcza zwykle zebranie not w pliku dołączonym do instalacji oraz, jeśli licencja tego wymaga, w interfejsie. Dla Apache 2.0 dokładamy NOTICE. Dla LGPL i MPL dokładamy sposób pobrania źródeł zmienionej biblioteki i opis, jak użytkownik może ją podmienić, jeśli licencja tego żąda.
Warunek uznajemy za spełniony dopiero wtedy, gdy noty da się odnaleźć w artefakcie, który dostaje klient: instalatorze, obrazie kontenera, pakiecie sklepu albo archiwum wydania. Plik leżący wyłącznie w repozytorium źródłowym nie spełnia obowiązku wobec odbiorcy binarki. Przy Apache 2.0 porównujemy NOTICE z tagu źródłowego z NOTICE w wydaniu i dopisujemy własne modyfikacje tam, gdzie licencja każe je oznaczyć. Przy LGPL i MPL do paczki dokładamy adres albo archiwum źródeł zmienionej biblioteki oraz krótką instrukcję podmiany, jeśli relinkowanie jest wymagane.
Przed mergem sprawdzamy jeszcze trzy rzeczy operacyjne. Po pierwsze, czy bundler, obfuscator albo narzędzie do „czyszczenia” nagłówków nie wycina copyrightu. Po drugie, czy rebranding nie usuwa NOTICE i nie wstawia nazwy cudzej biblioteki do logo bez zgody na znak towarowy. Po trzecie, czy polityka prywatności i EULA nie dokładają ograniczeń sprzecznych z licencją komponentu, na przykład zakazu inżynierii wstecznej wobec kodu, który odbiorca ma prawo podmienić.
Krok 4: Bramka wydania i zapis decyzji
Integracja kończy się na artefakcie, nie na zielonym CI. Z wydania, które ma trafić do klienta, generujemy raport licencji i porównujemy go z listą zatwierdzoną w kroku 2. Różnica oznacza albo nową zależność, albo zmianę sposobu pakowania. W obu przypadkach merge do kanału produkcyjnego czeka.
Decyzję zapisujemy przy wersji: SHA, identyfikatory licencji, osoba akceptująca, data, miejsce atrybucji w produkcie i wyjątki (na przykład pakiet tylko w środowisku budowania). Przy kolejnym bumpie zależności procedura wraca do kroku 1 dla zmienionych pozycji, a nie „działało w zeszłym sprincie, więc lecimy”.
Checklista przed wciągnięciem kodu do produktu
- Przed: jest LICENSE albo COPYING na tagu, który realnie wchodzi do produktu, a nie tylko badge na stronie głównej.
- Przed: SPDX, README i plik licencji nie stoją w sprzeczności; konflikt jest wyjaśniony albo komponent odrzucony.
- Przed: brak dodatkowych zakazów w README, CLA albo nagłówkach plików, w szczególności „non-commercial” i „no redistribution”.
- W trakcie: drzewo zależności, vendoring i obraz produkcyjny przeskanowane; devDependency sprawdzona na artefakcie, nie na intencji.
- W trakcie: copyleft nie jest linkowany ani wklejany do zamkniętego rdzenia bez świadomej decyzji o otwarciu źródła.
- W trakcie: przy LGPL i MPL biblioteka zostaje wydzielona, a droga podmiany jest opisana i technicznie możliwa.
- Po: copyright, tekst licencji i NOTICE są w paczce klienta; skrypt release ich nie wycina.
- Po: rekord SHA, licencji i akceptacji leży przy wydaniu i da się go pokazać przy due diligence.
Najgroźniejsze pułapki prawne: na co uważać przed pierwszym wdrożeniem
Najczęstszy błąd to traktowanie braku sprzeciwu jako zgody. Issue bez odpowiedzi, gwiazdka na repozytorium albo komentarz „feel free to use” nie zastępują licencji. Dopóki uprawniony nie udzieli praw na piśmie albo w pliku licencji na użytym commicie, kopiowanie do aplikacji sprzedawanej klientom zostaje bez podstawy. To samo dotyczy kodu wygenerowanego w wątku i wklejonego do cudzego repozytorium: autor snippeta mógł nie mieć prawa go udostępniać, a model nie jest licencjodawcą.
Druga pułapka to licencja na korzeniu i inna w środku. Podkatalog vendor, przykłady, fonty, ikony i pliki testowe często mają własne warunki. Ikona na CC BY-NC albo font z zakazem osadzania w aplikacji komercyjnej psuje wydanie tak samo jak biblioteka na GPL, choć nie widać ich w importach kodu. Skan ograniczony do package.json tego nie złapie.
Trzecia to ciche wejście w copyleft przez sposób łączenia, nie przez nazwę pakietu. Wklejona funkcja, wspólny proces, statyczne zlanie LGPL w jeden plik wykonywalny albo zmodyfikowany komponent AGPL na ścieżce żądania klienta uruchamiają obowiązki, których model „sprzedajemy binarkę i nic więcej” nie udźwignie. Granicy nie warto sprawdzać dopiero w piśmie od klienta albo w pytaniach inwestora.
Czwarta to formalności uznane za kosmetykę. Usunięty nagłówek MIT, zgubiony NOTICE, EULA zabraniająca tego, na co licencja pozwala odbiorcy, oraz użycie nazwy autora w materiałach sprzedażowych bez zgody przy BSD-3-Clause są naruszeniami mimo „przecież licencja jest liberalna”. Patent grant z Apache 2.0 też nie jest ozdobą: pozew patentowy związany z tym oprogramowaniem może wygasić otrzymaną licencję patentową.
Przed pierwszym wdrożeniem przejdź listę na artefakcie wydania, nie na branchu deweloperskim. Jeśli któraś pozycja jest czerwona, komponent nie wchodzi do instalatora ani obrazu klienta. Albo podmieniasz go na zależność o jasnej licencji permisywnej, albo bierzesz pisemną licencję od uprawnionego, albo świadomie zmieniasz model dystrybucji tak, żeby udostępnić źródło w zakresie, którego wymaga copyleft. Skrót „dodamy notę w następnym sprincie” zostawia bieżące wydanie bez spełnionych warunków. [2]
Scenariusze, które rozstrzygasz na artefakcie
Te trzy sytuacje wracają przy prawie każdym pierwszym wydaniu komercyjnym. Każdą zamykasz tym samym ruchem: patrzysz na to, co dostaje klient, a nie na opis w README.
Biblioteka permisywna w SaaS
Aplikacja stoi u was, klient dostaje tylko dostęp przez przeglądarkę. MIT, BSD i Apache 2.0 zwykle nie wymagają wtedy publikacji waszego kodu. Nadal wymagają zachowania copyrightu i, przy Apache, pliku NOTICE w materiale, który faktycznie przekazujecie: obrazie, paczce on-prem albo panelu „licencje open source”, jeśli taki macie. Sam fakt, że binarka nie opuszcza serwera, nie kasuje atrybucji tam, gdzie licencja każe ją dołączyć do kopii.
Sprawdzenie: wygeneruj SBOM albo raport licencji z obrazu produkcyjnego, otwórz ścieżkę atrybucji w tym samym obrazie i porównaj listę. Brakującej noty nie uznajesz za spełnionej, bo „jest w monorepo”.
Snippet wklejony z issue albo z wątku
Kilkanaście linii bez pliku LICENSE na commicie, z dopiskiem „feel free”, nie wchodzi do produktu sprzedawanego klientom. Albo dostajecie od autora krótką zgodę na piśmie (mail z identyfikacją osoby i zakresem: użycie, modyfikacja, dystrybucja w aplikacji zamkniętej), albo przepisujecie funkcję od zera bez patrzenia w ten fragment. Komentarz pod issue nie jest licencją, a wklejka z modelu nie wskazuje uprawnionego.
Sprawdzenie: w rekordzie wydania jest albo URL i SHA z czytelną licencją, albo identyfikator pisemnej zgody. Puste pole „skąd kod” oznacza, że fragment wypada z diffu przed tagiem.
LGPL jako osobna biblioteka, nie jako zlepiony blob
Komponent na LGPL może zostać w zamkniętym produkcie, jeśli użytkownik binarki potrafi podmienić tę bibliotekę na własną kompilację. Statyczne wciągnięcie jej w jeden plik wykonywalny, bez obiektów do relinku i bez instrukcji, ten warunek psuje. MPL działa węziej: obowiązek źródła dotyczy zwykle plików tej licencji, nie całego programu, o ile granica plików jest utrzymana i nie mieszacie kodu MPL z własnym w tym samym pliku.
Sprawdzenie na artefakcie: biblioteka jest osobnym plikiem (albo zestawem obiektów), w paczce jest adres lub archiwum źródeł wersji, którą wysyłacie, oraz krótka instrukcja podmiany, którą ktoś z zespołu przeszedł na czystej maszynie. Jeśli podmiana się nie udaje, komponent nie jedzie w tym wydaniu.
Ostatnia bramka przed pierwszym wdrożeniem
- Tag wydania, nie branch deweloperski, ma raport licencji zgodny z listą zatwierdzoną przy mergu.
- W paczce klienta są copyright, tekst licencji i NOTICE; skrypt paczkowania ich nie wycina i rebranding ich nie nadpisuje.
- Żaden plik spoza importów (font, ikona, fixture, katalog vendor) nie ma „non-commercial”, zakazu redystrybucji ani CC BY-NC.
- Copyleft jest albo świadomie przyjęty razem z polityką udostępnienia źródła, albo go nie ma w obrazie i instalatorze.
- EULA i polityka prywatności nie odbierają odbiorcy praw, które licencja komponentu mu daje, w tym podmiany biblioteki LGPL lub MPL.
- Rekord przy wersji zawiera SHA, identyfikatory licencji, osobę akceptującą, datę, miejsce atrybucji i wyjątki ograniczone do środowiska budowania.
Czerwona pozycja zatrzymuje kanał produkcyjny. Komponent wypada, dostajecie pisemną licencję od uprawnionego albo zmieniacie sposób dystrybucji tak, żeby oddać źródło w zakresie wymaganym przez copyleft. Noty „w następnym sprincie” nie łatają wydania, które już ma iść do klienta.
Najczęściej zadawane pytania (FAQ)
Czy publiczne repozytorium na GitHubie pozwala użyć kodu komercyjnie?
Nie. Publiczna dostępność kodu nie oznacza zgody na jego kopiowanie, modyfikowanie ani dystrybucję. Potrzebna jest licencja lub jednoznaczna zgoda uprawnionego.
Czy można użyć kodu z repozytorium bez pliku LICENSE?
Co do zasady nie. Brak licencji oznacza, że prawa pozostają zastrzeżone. Przed użyciem trzeba uzyskać pisemną zgodę albo zastąpić kod innym rozwiązaniem.
Czy licencja MIT pozwala sprzedawać aplikację?
Zwykle tak, również w aplikacji zamkniętej. Trzeba jednak zachować notę o prawach autorskich i tekst licencji, a także sprawdzić licencje zależności.
Czy kod na GPL można wykorzystać w płatnym produkcie?
Sama odpłatność nie jest zakazana, ale dystrybucja dzieła zależnego może wymagać udostępnienia odpowiedniego kodu źródłowego na warunkach GPL. W zamkniętym produkcie trzeba dokładnie ocenić sposób połączenia kodu. [3]
Czym różni się AGPL od GPL w aplikacji SaaS?
AGPL może uruchamiać obowiązki dotyczące udostępnienia źródła także wtedy, gdy zmodyfikowane oprogramowanie jest udostępniane przez sieć. Dlatego jej warunki należy przeanalizować przed użyciem komponentu w ścieżce obsługi żądań.
Gdzie umieścić informacje o licencjach użytych komponentów?
W zależności od licencji mogą trafić do pliku z informacjami o komponentach, dokumentacji, instalatora albo ekranu About. Należy zachować wymagane noty, teksty licencji i pliki NOTICE.
Najważniejsze punkty
- Publiczne repozytorium na GitHubie nie jest domeną publiczną i samo w sobie nie daje prawa do komercyjnego użycia kodu.
- Brak pliku LICENSE, nagłówka licencyjnego lub jednoznacznej zgody oznacza, że kod nie powinien trafić do wydania.
- Licencje MIT, BSD, ISC i Apache 2.0 zwykle pozwalają na użycie w zamkniętej aplikacji, ale wymagają zachowania określonych informacji i warunków.
- GPL i AGPL mogą wymagać udostępnienia kodu źródłowego, a AGPL stwarza dodatkowe ryzyko przy usługach udostępnianych przez sieć.
- LGPL i MPL wymagają zachowania granic między biblioteką a własnym kodem oraz spełnienia warunków dotyczących zmian i podmiany komponentu.
- Przed integracją trzeba sprawdzić konkretny commit lub tag, historię pochodzenia, zależności, obowiązki licencyjne i dokumentację wydania.
