Licencje YOLO: od v1 do YOLO26, kompletny przewodnik na 2026 rok

Każdego roku pojawia się więcej modeli YOLO i każdego roku ponownie pada pytanie o licencje, zwykle na pięć minut przed decyzją produktową. Zamieszanie wynika z tego, że „YOLO” nie oznacza jednego projektu. To nazwa współdzielona przez około dwadzieścia rodzin modeli różnych autorów. Jest tu szczegół, który umyka w większości przewodników po licencjach: licencja dotyczy repozytorium, a nie modelu. Ta sama wersja YOLO może jednocześnie występować w repozytorium na GPL i w repozytorium na MIT, nawet u tych samych autorów. Tak jest w przypadku YOLOv9 i zmienia to całą decyzję.

Ten przewodnik przedstawia sytuację repozytorium po repozytorium, z odnośnikami do artykułów i baz kodu. Stan na lipiec 2026 roku. Każdą wymienioną licencję sprawdzono w faktycznym pliku LICENSE danego repozytorium, ponieważ zaskakująco wiele informacji o licencjach YOLO, również w najwyżej pozycjonowanych przewodnikach, jest nieprawdziwych.

Jeśli interesuje Cię tylko kwestia AGPL w Ultralytics, szczegółowo omawia ją artykuł Czy YOLO można bezpłatnie wykorzystywać komercyjnie?. Tutaj znajduje się pełna mapa.

Dwa zastrzeżenia, zanim zaczniemy. Po pierwsze, rozwijamy LibreYOLO, bibliotekę na licencji MIT, która konkuruje z kilkoma opisanymi niżej projektami. Ostatnia część artykułu dotyczy właśnie LibreYOLO. To powód, by sprawdzić przedstawione informacje, a nie przyjmować ich bezkrytycznie, dlatego każde twierdzenie o licencji odsyła do źródła pierwotnego. Po drugie, artykuł zawiera ogólne informacje o opublikowanych tekstach licencji i publicznych oświadczeniach, aktualne na wskazaną wyżej datę. Nie jest poradą prawną ani jej zamiennikiem udzielanym przez prawnika w danej jurysdykcji. Licencje i stanowiska opiekunów projektów się zmieniają. Przed podjęciem decyzji o wdrożeniu sprawdź aktualny plik LICENSE każdego repozytorium.

Tabela licencji

„Liberalna ścieżka” oznacza repozytorium implementujące dany model, którego można użyć w komercyjnym produkcie o zamkniętym kodzie źródłowym, bez udostępniania kodu źródłowego aplikacji i bez opłaty licencyjnej.

Wystarczy czytać kolejne kolumny, by dostrzec oczywisty wniosek: numer wersji nic nie mówi o licencji. Liczy się repozytorium.

Ten sam model, dwie licencje: przypadek YOLOv9

YOLOv9 to najlepszy dowód na to, że pytanie „na jakiej licencji jest YOLOvN?” jest niewłaściwe. Warto dokładnie przyjrzeć się osi czasu, bo to jedyny przypadek w historii YOLO, gdy nacisk społeczności rzeczywiście zmienił sytuację.

• 18 lutego 2024: repozytorium WongKinYiu/yolov9 zostaje upublicznione razem z artykułem.
• 22 lutego 2024: użytkownik otwiera zgłoszenie nr 10 z pytaniem o licencję. Chien-Yao Wang (WongKinYiu) odpowiada „I think it should be GPL3”, a cztery dni później dodaje plik GPL-3.0.
• 26 lutego 2024: kolejny użytkownik otwiera zgłoszenie nr 82, „An Apache/MIT rewrite”. W ciągu następnych dwóch i pół tygodnia dołącza tuzin użytkowników komercyjnych.
• 14 marca 2024: Wang publikuje w tym wątku: "Okay I create a new repo for mit rewrite... I think I can handle most of implementation of architectures and loss functions. And need someone to give great help about dataloader and ddp training."

To repozytorium, początkowo nazwane yolov9mit, to obecnie MultimediaTechLab/YOLO: licencja MIT, właściciele praw autorskich „Kin-Yiu, Wong and Hao-Tang, Tsui”, opis projektu: "the official implementation of YOLOv7 and YOLOv9, YOLO-RD." Większość przepisanego kodu nie powstała dzięki wolontariuszom z wątku, lecz za sprawą Hao-Tanga Tsui, współpracownika Wanga z laboratorium, autora około 90 procent commitów.

YOLOv9 jest więc jednocześnie „nie do wdrożenia” i „do wdrożenia”, zależnie od sklonowanego repozytorium. Ta sama architektura, to samo laboratorium, dwie licencje.

Zanim oprzesz na tym produkt, poznaj trzy zastrzeżenia, których repozytorium nie podaje na stronie głównej:

1. Projekt jest nadal rozwijany. W otwartym zgłoszeniu z lutego 2026 roku opisano, że udostępnione checkpointy nie odtwarzają wyników COCO z artykułu i mają zauważalnie więcej parametrów, niż podano w artykule. Trenowanie segmentacji i punktów kluczowych nie zostało jeszcze zaimplementowane. Od oznaczenia v1.0 w grudniu 2025 roku nie scalono niczego z gałęzią main.
2. Wagi nie mają osobnej informacji o licencji. Zgodnie z przyjętą praktyką licencja MIT repozytorium obejmuje jego zasoby wydania, a dowody techniczne wskazują, że checkpointy wytrenowano w tym projekcie, a nie skopiowano z repozytorium GPL: pliki różnią się rozmiarem i liczbą parametrów od checkpointów GPL. Żaden dokument nie stwierdza jednak, że pliki .pt podlegają MIT, a społecznościowy wniosek o formalny audyt pod kątem skażenia AGPL pozostaje otwarty. To luka w dokumentacji: nikt nie ogłosił, że kod jest „zweryfikowany jako czysty”, ale nikt też nie zgłosił problemu.
3. To inna baza kodu, a nie zamiennik skryptów z repozytorium GPL, który można wstawić bez zmian.

To nie znaczy, że projekt jest bezużyteczny. Należy go ocenić, zamiast traktować jako pozycję do odhaczenia.

Era 1: lata domeny publicznej (YOLOv1–YOLOv4)

Joseph Redmon opublikował YOLOv1, YOLOv2 (znany jako artykuł YOLO9000) oraz YOLOv3 w ramach frameworka Darknet. Plik LICENSE jest znany z tego, że ma tylko trzy wiersze:

0. Darknet is public domain.
1. Do whatever you want with it.
2. Stop emailing me about it!

To rzeczywiste przekazanie do domeny publicznej. YOLOv4, którego opiekunem jest Alexey Bochkovskiy w forku Darknet, zawiera ten sam plik, a nie Unlicense przypisywaną mu w kilku przewodnikach po licencjach. Własny klasyfikator GitHuba nie rozpoznaje tej licencji i raportuje „Other”. Warto o tym wiedzieć, jeśli narzędzia zgodności korzystają z tego pola: skaner oznaczy ją jako nierozpoznaną, a nie jako permisywną, choć trudno o bardziej permisywny tekst.

Sam Darknet nie jest całkiem martwy. Repozytorium Redmona nie było aktualizowane od 2022 roku, ale README AlexeyaAB wskazuje teraz hank-ai/darknet jako zalecanego, aktywnie rozwijanego następcę w C/C++.

Pułapka tkwi w portach. W 2026 roku prawie nikt nie trenuje modeli w Darknet. Zamiast tego używa implementacji w PyTorch, które mają własne licencje:

• ultralytics/yolov3, najpopularniejszy port YOLOv3, jest objęty AGPL-3.0. Architektura z domeny publicznej, ponownie rozpowszechniana na jednej z najbardziej restrykcyjnych licencji w tej dziedzinie. Otrzymana licencja zależy wyłącznie od tego, czyj port zainstalowano przez pip.
• eriklindernoren/PyTorch-YOLOv3 jest objęty GPL-3.0.
• Tianxiaomo/pytorch-YOLOv4 jest objęty Apache-2.0, więc permisywna ścieżka dla v4 jest dostępna również w PyTorch.
• WongKinYiu/PyTorch_YOLOv4, projekt współautora YOLOv4, nie ma żadnego pliku LICENSE. To gorsza sytuacja niż copyleft: bez licencji nie są przyznane żadne prawa, a domyślnie obowiązuje pełna ochrona praw autorskich.

Sprawdź licencję sklonowanego repozytorium, a nie numer wersji w artykule.

Era 2: GPL-3.0 (YOLOv6, v7, v9)

YOLOv6 (Meituan), YOLOv7 i YOLOv9 wydano na GPL-3.0.

GPL-3.0 to copyleft: przy rozpowszechnianiu zmodyfikowanej wersji albo połączeniu kodu GPL z własnym kodem w jeden program trzeba udostępnić pełny odpowiadający mu kod źródłowy tego połączonego utworu na GPL-3.0. Istotne są dwie granice. Samo zestawienie oznacza, że osobne, niezależne programy dostarczone razem nie stają się automatycznie jednym utworem. Drugą granicą jest rozpowszechnianie: w odróżnieniu od AGPL zwykła GPL nie nakłada obowiązku ujawnienia kodu, jeśli połączony utwór nigdy nie jest przekazywany dalej. Dlatego niektóre firmy używają modelu GPL wyłącznie za własnym API.

Ta ścieżka jest węższa, niż się wydaje, i ma trzy pułapki, których rzadko uwzględnia się w planach. Gdy model trafia na urządzenie klienta lub do instalacji lokalnej, dochodzi do rozpowszechniania. Określenie „wyłącznie do użytku wewnętrznego” przestaje być prawdziwe, gdy kopia opuszcza podmiot prawny: przekazanie kompilacji wykonawcy, zewnętrznemu zespołowi programistów albo odrębnej spółce powiązanej stanowi rozpowszechnianie, choć kopiowanie wewnątrz jednej firmy nim nie jest. Ochrona działa tylko wtedy, gdy wszystkie elementy dostępne przez API są objęte GPL lub licencją bardziej permisywną, ponieważ pojedynczy komponent AGPL w udostępnianym utworze powoduje zastosowanie sekcji 13, niezależnie od treści pliku GPL.

YOLOv7 i YOLOv9 mają opisaną wyżej alternatywę na MIT. YOLOv6 jej nie ma. Najmocniejszym dowodem jest działanie Baidu: PaddleDetection jest objęte Apache-2.0, a jego opiekunowie celowo odseparowali YOLOv5, YOLOv6, YOLOv7 i YOLOv8 w osobnym repozytorium GPL-3.0, PaddleYOLO, stwierdzając, że kod tych modeli „will not be merged into PaddleDetection”. Jeśli firma tak duża jak Baidu stawia barierę, by nie dopuścić YOLOv6 do swojego permisywnie licencjonowanego frameworka, wiele mówi to o konsekwencjach tej licencji.

Era 3: AGPL-3.0 (YOLOv5, v8, v10, 11, v12, v13, 26, YOLOE)

Ultralytics przeszło na AGPL-3.0 14 kwietnia 2023 roku, a nie w 2022 roku, jak często się powtarza, także w przewodnikach z pierwszej strony wyników wyszukiwania. Wszystkie późniejsze modele (YOLOv8, YOLO11 i YOLO26) są objęte AGPL-3.0, a alternatywą jest płatna licencja Enterprise. Na stronie licencji podano, że poziom Enterprise obejmuje „YOLO26, earlier YOLO versions, and any future YOLO models”, więc polityka jest celowa i obejmuje przyszłe modele. Ceny nie są publicznie dostępne.

Tę datę można sprawdzić i warto to zrobić, ponieważ popularna wersja tej historii jest błędna w istotnym szczególe:

• W historii plik LICENSE w ultralytics/yolov5 zmieniono dokładnie trzy razy. Trzecia zmiana to commit 34cf749 „Update LICENSE to AGPL-3.0 (#11359)” z datą 2023-04-14. Zmienia on GNU GENERAL PUBLIC LICENSE na GNU AFFERO GENERAL PUBLIC LICENSE w 101 plikach.
• Ostatnie wydanie YOLOv5 z 2022 roku, v7.0 (22 listopada 2022 roku), nadal było objęte GPL-3.0, podobnie jak wcześniejsze v6.2, v6.1 i v6.0. Tak samo jest w przypadku tysięcy forków, które przestały być synchronizowane przed kwietniem 2023 roku: GitHub nadal podaje dla dowolnego z nich GPL-3.0.
• Tego samego dnia, 41 minut później, w repozytorium ultralytics/ultralytics wprowadzono tę samą zmianę (PR #2031).

Wynika z tego mało znany fakt: YOLOv8 nie zadebiutowało na AGPL. Wydano je w styczniu 2023 roku na GPL-3.0, a zmianę licencji wprowadzono trzy miesiące później. Dane PyPI są jednoznaczne: ultralytics od wersji 8.0.0 (10 stycznia 2023 roku) do 8.0.76 (13 kwietnia 2023 roku) deklaruje GPL-3.0. Pierwszą wersją deklarującą AGPL-3.0 jest 8.0.80, opublikowana 16 kwietnia 2023 roku.

To nie jest luka w licencji. Udzielona licencja nie zostaje cofnięta z mocą wsteczną, więc stare wersje pozostają dostępne na warunkach obowiązujących w chwili publikacji. Są jednak przestarzałe o trzy lata, nieutrzymywane i niezałatane. GPL-3.0 nadal oznacza copyleft (klauzulę sieciową zastąpiono klauzulą dotyczącą rozpowszechniania, ale copyleft nie znika), a stanowisko komercyjne Ultralytics jest szersze niż sam tekst licencji. Praktyczny, bardziej ogólny wniosek jest taki: licencja odnosi się do otrzymanej wersji, a nie do nazwy projektu. Przypinaj zależności i zapisuj treść licencji z dnia pobrania kopii, bo projekt może ją zmienić następnego dnia, a kwestia zgodności zależy od tego, którą wersję faktycznie otrzymano.

AGPL-3.0 to GPL uzupełniona sekcją 13, klauzulą sieciową: jeśli zmodyfikowano Program, użytkownikom korzystającym z tej zmodyfikowanej wersji przez sieć trzeba udostępnić jej kod źródłowy. To zamyka ścieżkę SaaS, którą pozostawia zwykła GPL.

Warto zwrócić uwagę na to zastrzeżenie, ponieważ wiele artykułów je pomija. Sekcja 0 AGPL definiuje „modyfikację” jako kopiowanie utworu lub jego adaptację w sposób wymagający zgody na podstawie prawa autorskiego. Uruchamianie niezmodyfikowanego kodu treningowego na własnym zbiorze danych oznacza wykonanie programu, a nie adaptację jego źródeł. Podobnie skompilowanie własnego kodu za pomocą niezmodyfikowanego kompilatora GPL nie modyfikuje kompilatora. Samo trenowanie nie uruchamia więc automatycznie tego obowiązku. Kto twierdzi inaczej, pominął tę definicję.

Zakres licencji obejmuje połączenie lub osadzenie pakietu we własnej bazie kodu w taki sposób, że oba elementy są rozpowszechniane lub udostępniane jako jeden program. Według interpretacji FSF połączenie utworu GPL lub AGPL z innymi modułami za pomocą linkowania tworzy połączony utwór. Nie sprawdzono jeszcze, czy sąd rozszerzyłby tę interpretację na import w Pythonie. Warto również zauważyć, że własne warunki komercyjne Ultralytics wymagają licencji Enterprise dla platform SaaS, API i systemów chmurowych korzystających z YOLO w tle. Stanowisko dostawcy jest zatem szersze niż sam tekst licencji. Integrację z produktem udostępnianym lub rozpowszechnianym należy traktować jako ryzyko. Nie należy zakładać, że samo trenowanie w odosobnieniu je powoduje.

W przypadku YOLO26 daty są wszędzie mylone, dlatego: model zaprezentowano we wrześniu 2025 roku podczas YOLO Vision, wydano w styczniu 2026 roku (wydanie ultralytics 8.4.0, którego informacje o wydaniu mówią „Ultralytics YOLO26 has arrived”), a artykuł opublikowano w czerwcu 2026 roku. Model znajduje się w głównym repozytorium ultralytics/ultralytics; ultralytics/yolo26 to tylko strona informacyjna.

Zaskakujący szczegół: akademickie YOLO z ostatnich dwóch lat również są objęte AGPL, i to nie dlatego, że napisało je Ultralytics.

• YOLOv10 pochodzi z Uniwersytetu Tsinghua. W README napisano "The code base is built with ultralytics."
• YOLOv12: "The code is based on ultralytics."
• YOLOv13: "The code is based on Ultralytics."
• YOLOE, model z otwartym słownikiem, który „widzi wszystko”, stworzony przez zespół YOLOv10, również podlega AGPL-3.0 i bazuje na Ultralytics.

Copyleft jest dziedziczony: utwór zależny od kodu AGPL musi być rozpowszechniany na AGPL, więc gdy tylko jeden z tych forków zostanie rozpowszechniony lub udostępniony, jego licencja ma zastosowanie. (Jeśli wprowadzono modyfikacje, ale kod pozostaje wyłącznie do własnego użytku, obowiązek nie powstaje, dlatego użycie badawcze pozostaje bez zmian). Badania są niezależne, licencja nie. Od 2024 roku publikowanie „kolejnego YOLO” jako utworu zależnego od Ultralytics stało się domyślną praktyką, więc AGPL automatycznie przechodzi teraz na kolejne wersje.

Strona twierdząca, że YOLOv13 jest objęte Apache-2.0, podaje błędną informację. Plik LICENSE, API GitHuba i karta modelu wskazują AGPL-3.0.

Liberalna ścieżka dla YOLOv8, która już nie istnieje

Wiele nadal dostępnych przewodników, w tym wcześniejszy szkic tego artykułu, wskazuje YOLOv8 z KerasCV na Apache-2.0 jako prostą alternatywę dla YOLOv8 na AGPL. Obecnie nie można na niej polegać. Oto publicznie dostępne informacje:

• W dyskusji KerasCV Clarifications regarding YOLOv8 licensing jeden z uczestników napisał, że „many parts are derived form ultralytics”. Żaden opiekun projektu nie odpowiedział, więc kwestia niezależności implementacji nie została publicznie rozstrzygnięta.
• Zgłoszenie KerasHub add YOLOV8 zamknął w lipcu 2025 roku opiekun Keras z komentarzem: „Hey all!! Because of license issues, we have decided to drop this.” Dwie osoby zapytały później, co to oznacza dla dotychczasowych użytkowników komercyjnych wersji KerasCV. Żadna nie otrzymała odpowiedzi.
• KerasCV jest teraz zarchiwizowane, a jego utrzymywany następca, KerasHub, nie udostępnia YOLOv8.

Nie wiadomo, czy te dwie sprawy są ze sobą powiązane, i nie twierdzimy, że doszło do czegoś niewłaściwego. Nie jest to jednak solidna podstawa dla produktu.

Liberalne wyjątki: YOLOX, PP-YOLOE i YOLO-NAS

Nie każdy model YOLO dołączył do ruchu copyleft.

• YOLOX (Megvii, 2021) jest objęte Apache-2.0 bez wyjątków, zarówno kod, jak i wagi. Nadal jest to najczystszy klasyczny model YOLO do zastosowań komercyjnych, choć repozytorium nie było aktualizowane od połowy 2025 roku, a pytanie o dołączenie wstępnie wytrenowanych wag do aplikacji komercyjnej pozostaje bez odpowiedzi od marca 2026 roku. Treść licencji jest jednoznaczna. Po prostu nie ma już nikogo, kto mógłby odpowiedzieć na pytania. Opisaliśmy uruchamianie YOLOX z LibreYOLO.
• PP-YOLOE (Baidu) jest objęte Apache-2.0 w ramach PaddleDetection. Należy korzystać właśnie z niego, a nie z PaddleYOLO, które zawiera niemal identyczny katalog konfiguracji i jest objęte GPL-3.0. Ten sam model, ta sama firma, dwa repozytoria, dwie licencje. To odwrotna sytuacja niż w przypadku YOLOv9.
• YOLO-NAS (Deci, 2023) to przypadek, który często zaskakuje. Kod jest objęty Apache-2.0, oficjalne wagi już nie. W osobnej licencji zapisano, że "may not use the Software for any commercial use, including in connection with any models used in a production environment." Od przejęcia Deci przez NVIDIA w 2024 roku nie znaleźliśmy nowych prac nad funkcjami w repozytorium, a pierwotne adresy wag przestały działać (checkpointy są teraz na innym serwerze). Czasem sugeruje się obejście, według którego trenowanie architektury od zera pozwala zachować zgodność z Apache, ale Deci ani NVIDIA tego nie potwierdziły. Jest to też trudne do pogodzenia z tekstem licencji obejmującym „any components comprising the model”. Więcej o YOLO-NAS tutaj.
• MMYOLO bywa w starszych przewodnikach określane jako Apache-2.0. To nieprawda: MMYOLO jest objęte GPL-3.0 (jego siostrzane MMDetection jest objęte Apache), a od lipca 2024 roku nie wprowadzono tam żadnych zmian.
• YOLO-World (Tencent) podlega GPL-3.0, a nie AGPL ani licencji permisywnej. Warto to podkreślić, ponieważ często zakłada się, że modele YOLO z otwartym słownikiem są permisywnie licencjonowane, bo korzystają z ekosystemu podobnego do CLIP.

Te przypadki pokazują trzy najczęstsze błędy dotyczące licencji w tej dziedzinie: założenie, że wagi podlegają tej samej licencji co kod, że wszystkie projekty danej organizacji mają tę samą licencję oraz że licencję można wywnioskować z nazwy modelu.

Licencje obejmują kod, nie idee (ale trzeba uważać na patenty)

Jedna zasada stanowi podstawę prawną wszystkich opisanych wyżej permisywnych ścieżek: prawo autorskie chroni sposób wyrażenia, a nie idee. To nie slogan, lecz jednoznaczna norma prawna po obu stronach Atlantyku.

W Stanach Zjednoczonych jest to 17 U.S.C. 102(b), które wyłącza spod ochrony prawnoautorskiej wszelkie „idea, procedure, process, system, method of operation, concept, principle, or discovery”, zgodnie z zasadą sięgającą sprawy Baker v. Selden (1879). W Unii Europejskiej, której prawo nas dotyczy i prawdopodobnie dotyczy też wielu czytelników, art. 1 ust. 2 dyrektywy oprogramowania (2009/24/WE) stanowi, że „ideas and principles which underlie any element of a computer program” nie podlegają ochronie. Trybunał Sprawiedliwości potwierdził w sprawie SAS Institute przeciwko World Programming (C-406/10, 2012), że funkcjonalność programu, jego język programowania i formaty danych same w sobie nie są chronionym sposobem wyrażenia. Ochrona obejmuje wyłącznie kod.

Architektura opisana w artykule na arXiv to opublikowana idea. Każdy może ją zaimplementować. Nie można natomiast kopiować ani adaptować plików źródłowych GPL/AGPL i zmieniać licencji. Niezależna implementacja napisana na podstawie artykułu, a nie kodu źródłowego, jest nowym utworem, którego autor wybiera licencję.

Dwa istotne zastrzeżenia, które pomija większość dostawców:

• Implementacja musi być rzeczywiście „niezależna”. Można to wiarygodnie wykazać przez proces clean-room: osoby piszące kod korzystają z artykułu i specyfikacji, a nie ze źródeł objętych copyleft. Dokładne czytanie repozytorium GPL, a następnie „przepisywanie go” to co innego. Różnica ma znaczenie, jeśli ktokolwiek kiedyś ją zbada.
• To argument dotyczący prawa autorskiego, a nie patentów. Niezależne wynalezienie nie chroni przed patentem. Implementacja clean-room rozstrzyga kwestię prawa autorskiego, ale nie zmienia sytuacji patentowej. Obecnie nie ma powszechnie wskazywanego patentu obejmującego architektury YOLO, ale „nikt jeszcze nie pozwał” nie oznacza „nie ma podstaw do pozwu”.

Wagi podlegają osobnej licencji

Najkosztowniejszym błędem w tej dziedzinie jest audyt kodu z pominięciem checkpointu. Licencje mogą obejmować trzy warstwy i każda z nich może mieć inne warunki:

1. Kod. Wszystko, co omówiono wyżej.

2. Wagi. Czasem licencja jest podana wprost, jak w przypadku YOLO-NAS. Czasem jest to deklaracja: strona licencji Ultralytics twierdzi, że AGPL-3.0 „covers the training code and the models produced by that training code” i obejmuje też modele wytrenowane samodzielnie za pomocą tego kodu. Jako właściciel praw autorskich do publikowanych materiałów Ultralytics może ustalać warunki dla własnych checkpointów. Kwestia tego, czy wyprodukowane samodzielnie wagi są prawnie utworem zależnym od kodu treningowego, pozostaje otwarta: nie rozstrzygnięto jej w orzecznictwie, a stoi ona w sprzeczności z ogólną zasadą FSF, według której wynik działania programu nie jest automatycznie objęty prawami autorskimi do samego programu. Brak rozstrzygnięcia nie oznacza jednak bezpieczeństwa. W praktyce opublikowane wagi AGPL należy traktować jako objęte ograniczeniami.

Istotne ryzyko dla osób korzystających z zaleceń tego artykułu: repozytoria GPL z YOLOv7 i YOLOv9 w ogóle nie określają licencji wag. Ich checkpointy są zasobami wydań w repozytorium GPL-3.0, bez odrębnego zezwolenia. Wczytanie tych plików .pt do implementacji na MIT oznacza czysty kod, ale status checkpointu pozostaje niewyjaśniony. Jeśli powodem zmiany była licencja, należy użyć wag wytrenowanych przez projekt z permisywną licencją albo wytrenować własne.

3. Dane treningowe. Adnotacje COCO są objęte CC BY 4.0, więc etykiety nie sprawiają problemu. Zdjęcia nie należą do COCO i nie są przez nie licencjonowane: to zdjęcia z Flickr, objęte różnymi warunkami, do których konsorcjum COCO wyraźnie nie ma praw. Większość branży uznaje to za małe ryzyko i idzie dalej, ale stwierdzenie „COCO jest w porządku” dotyczy wyłącznie adnotacji. Poza COCO ograniczenia szybko rosną: wiele zbiorów danych lotniczych, medycznych i drogowych nie dopuszcza użycia komercyjnego, a permisywna licencja kodu modelu tego nie zmienia.

Za każdym razem należy sprawdzać wszystkie trzy warstwy.

Kilka słów o MIT i Apache-2.0

Utrzymujemy bibliotekę na MIT, więc wygodnie byłoby stwierdzić, że MIT to po prostu najlepsza licencja. Uczciwe porównanie jest ciekawsze.

MIT nie oznacza braku obowiązków: w rozpowszechnianych kopiach trzeba zachować informację o prawach autorskich i tekst licencji. To rzeczywisty warunek, choć mało uciążliwy. Apache-2.0 ma coś, czego brakuje MIT: wyraźne zezwolenie patentowe od każdego współtwórcy i klauzulę odwetu, która odbiera to zezwolenie każdemu, kto wniesie pozew dotyczący patentu związanego z utworem. MIT milczy na temat patentów. Dla firmy, która najbardziej obawia się ryzyka patentowego, Apache-2.0 może być bezpieczniejszą licencją. Z tego właśnie powodu wiele projektów na licencjach permisywnych do detekcji (YOLOX, RT-DETR, D-FINE, DEIM) stosuje Apache-2.0.

MIT zapewnia prostotę i zgodność. Żadna z tych licencji nie zmusi do opublikowania kodu źródłowego. To właśnie na tej kwestii skupia się ten artykuł. Jeśli ktoś twierdzi, że ważniejszy jest wybór między MIT a Apache, próbuje coś sprzedać. Kluczowy wybór dotyczy licencji permisywnej albo copyleft.

Którego YOLO można faktycznie użyć?

• Komercyjny produkt o zamkniętym kodzie źródłowym: YOLOv7 lub YOLOv9 przez repozytorium laboratorium na MIT, YOLOX albo PP-YOLOE (z PaddleDetection) spośród oryginalnych projektów, ewentualnie utrzymywany framework na MIT, taki jak LibreYOLO, jeśli wolisz uniknąć samodzielnego łączenia i audytowania komponentów. Należy unikać GPL i AGPL, chyba że kod całej aplikacji zostanie udostępniony albo zostanie kupiona licencja Enterprise.
• Projekt open source: dowolny, o ile jego licencja jest zgodna. Jeśli projekt jest na AGPL, naturalnym wyborem jest linia Ultralytics, a najnowsze badania (YOLOv13, YOLO26, YOLOE) trafiają najpierw właśnie tam.
• Badania i benchmarki: licencje rzadko ograniczają takie zastosowanie. Należy użyć modelu zgodnego z tym, którego wyniki są porównywane.
• Plan „zajmiemy się tym później”: nie zadziała. Usunięcie zależności AGPL po zbudowaniu produktu oznacza ponowne trenowanie, walidację i eksport wszystkiego, łącznie z wagami. Najpierw należy wybrać repozytorium, a tym samym licencję.

Porównanie samych frameworków, a nie ich licencji, znajduje się w artykule Najlepsze alternatywy dla Ultralytics w 2026 roku.

Opcja MIT: co udostępnia LibreYOLO

Informacja: LibreYOLO to nasz projekt, a jego licencja jest powodem powstania tego artykułu.

LibreYOLO to jedna baza kodu na licencji MIT, która udostępnia poniższe detektory przez jedno API. Obejmuje trenowanie i wbudowany eksport do ONNX, TensorRT, OpenVINO oraz NCNN. Bez copyleft, klauzuli sieciowej ani poziomu Enterprise.

Poniżej znajduje się pełna lista modeli do detekcji obiektów wraz z projektami źródłowymi i ich licencjami. Dzięki temu można dokładnie sprawdzić, skąd pochodzi każda permisywna ścieżka:

Dwie kwestie w tej tabeli przedstawiono celowo bez zatajania ograniczeń.

W bazie kodu nie skopiowano żadnych źródeł GPL ani AGPL. Wszystkie wymienione rodziny bazują na projektach źródłowych z domeny publicznej, MIT lub Apache-2.0, co pozwala zachować licencję MIT frameworka. Tam, gdzie architektura ma zarówno permisywną, jak i copyleftową wersję, korzystamy z tej permisywnej: YOLOv9 i YOLOv7 pochodzą z repozytorium laboratorium na MIT, a nie z oryginalnych repozytoriów GPL. RTMDet pochodzi z MMDetection na Apache, a nie z MMYOLO na GPL. YOLO-World nie znalazło się na liście mimo częstych pytań, bo jest objęte GPL-3.0 i nie ma permisywnego źródła, z którego można byłoby skorzystać.

Liberalna licencja nie oznacza braku ograniczeń. Wolimy o tym powiedzieć, niż pozwolić odkryć to podczas audytu. Większe warianty DEIMv2 podlegają warunkom Meta DINOv3, w tym zakazowi użycia w wojsku, energetyce jądrowej, szpiegostwie i przy produkcji broni, co jest realnym ograniczeniem w zastosowaniach podwójnego przeznaczenia. Kilka checkpointów z wersji poglądowych do badań wytrenowano na zbiorach danych niekomercyjnych (DOTA, VisDrone) i oznaczono na Hugging Face jako cc-by-nc, zamiast udostępniać je bez informacji o ograniczeniach. Do naszych wag stosuje się ta sama ostrożność co do wag innych projektów: checkpointy YOLO9 konwertujemy z checkpointów repozytorium laboratorium na MIT, więc obowiązują je te same warunki, które opisano wyżej jako „deklarowane, ale niepoddane formalnemu audytowi”. Licencja MIT obejmuje napisany przez nas kod. Każdy checkpoint podlega warunkom danych i źródeł, z których powstał, publikowanym osobno dla poszczególnych wag.

Poza detekcją to samo API obejmuje segmentację instancji i semantyczną, estymację pozy, obrócone ramki, klasyfikację (MobileNetV4, ConvNeXt, EfficientNetV2, ResNet, CLIP), estymację głębi z pojedynczego obrazu, przywracanie obrazu i estymację kierunku wzroku.

pip install libreyolo

from libreyolo import LibreYOLO

model = LibreYOLO("LibreYOLO9c.pt")
results = model("image.jpg", save=True)
print(results[0].boxes.xyxy)

Ten sam sposób pracy z YOLO, bez sprawdzania licencji.

Dodaj gwiazdkę w GitHubie: github.com/LibreYOLO/libreyolo | Dokumentacja: libreyolo.com/docs

Znaki towarowe i powiązania: YOLO, YOLOv8, YOLO11, YOLO26 i Ultralytics są znakami towarowymi ich właścicieli, w tym Ultralytics Inc. LibreYOLO to niezależny projekt, który nie jest powiązany z Ultralytics ani inną organizacją wymienioną w tym artykule, nie jest przez nie sponsorowany ani przez nie rekomendowany. Nazwy produktów i repozytoriów służą wyłącznie do identyfikacji i porównania omawianego oprogramowania.

Ten artykuł zawiera ogólne informacje, nie poradę prawną. Jest aktualny na 11 lipca 2026 roku i napisał go jeden z dostawców uwzględnionych w porównaniu. Przed wdrożeniem należy sprawdzić aktualną licencję.