Ліцензії YOLO: повний огляд від v1 до YOLO26 (посібник 2026)

Щороку з'являється дедалі більше моделей YOLO, і щороку знову постає питання ліцензування, зазвичай за п'ять хвилин до рішення щодо продукту. Плутанина виникає тому, що «YOLO» не є одним проєктом. Це назва бренду для приблизно двох десятків сімейств моделей від різних авторів. І ось деталь, яку пропускає більшість посібників із ліцензування: ліцензія належить репозиторію, а не моделі. Та сама версія YOLO може одночасно існувати в репозиторіях із GPL і MIT від тих самих авторів. Так і є з YOLOv9, і це повністю змінює рішення.

У цьому посібнику наведено карту репозиторій за репозиторієм із посиланнями на кожну статтю та кодову базу, актуальну станом на липень 2026 року. Кожну ліцензію нижче звірено з файлом LICENSE у відповідному репозиторії, адже чимало написаного про ліцензування YOLO, зокрема в найпопулярніших посібниках на цю тему, є помилковим.

Якщо вам потрібно лише розібратися з AGPL від Ultralytics, ми докладно розглянули це в статті Чи можна безкоштовно використовувати YOLO в комерційних цілях?. Тут наведено повну карту.

Перш ніж почати, два розкриття інформації. По-перше, ми підтримуємо LibreYOLO, бібліотеку під MIT, яка конкурує з кількома проєктами нижче, і останній розділ цієї статті присвячено їй. Це привід перевірити нашу роботу, а не приймати її на віру, тому кожне твердження про ліцензію містить посилання на першоджерело. По-друге, ця стаття містить загальну інформацію про опубліковані тексти ліцензій і публічні заяви, актуальні на вказану вище дату. Це не юридична консультація і не заміна юриста у вашій юрисдикції. Ліцензії та позиції мейнтейнерів змінюються. Перш ніж ухвалити рішення про випуск продукту, прочитайте актуальний файл LICENSE кожного репозиторію.

Таблиця ліцензій

«Дозвільний варіант» означає репозиторій із реалізацією цієї моделі, яку можна використовувати в комерційному продукті із закритим кодом, не відкриваючи код своєї програми й не сплачуючи за ліцензію.

Прочитайте таблицю по стовпцях, і стане очевидним одне: номер версії нічого не говорить про ліцензію. Важливий репозиторій.

Та сама модель, дві ліцензії: випадок YOLOv9

YOLOv9 найкраще доводить, що питання «яка ліцензія у YOLOvN?» сформульоване неправильно. Цю хронологію варто викласти точно, бо це єдиний випадок в історії YOLO, коли тиск спільноти справді змінив результат.

• 18 лютого 2024 року: WongKinYiu/yolov9 оприлюднюють разом зі статтею.
• 22 лютого 2024 року: користувач створює issue #10 із питанням про ліцензію. Chien-Yao Wang (WongKinYiu) відповідає: "I think it should be GPL3", а через чотири дні додає файл GPL-3.0.
• 26 лютого 2024 року: інший користувач створює issue #82, "An Apache/MIT rewrite". Протягом наступних двох із половиною тижнів долучаються десятки комерційних користувачів.
• 14 березня 2024 року: Wang пише в цій гілці: "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."

Цей репозиторій, спочатку названий yolov9mit, тепер має назву MultimediaTechLab/YOLO: ліцензія MIT, авторське право «Kin-Yiu, Wong and Hao-Tang, Tsui», а сам репозиторій називає себе "the official implementation of YOLOv7 and YOLOv9, YOLO-RD." Основну частину переписування зробили не волонтери з гілки, а колега Wang по лабораторії Hao-Tang Tsui, якому належить приблизно 90 відсотків комітів.

Отже, YOLOv9 одночасно «непридатна до випуску» і «придатна до випуску», залежно від того, який репозиторій ви клонували. Та сама архітектура, та сама лабораторія, дві ліцензії.

Перш ніж покладатися на неї у продукті, врахуйте три застереження, про які на головній сторінці репозиторію не скажуть:

1. Проєкт ще розвивається. У відкритому issue за лютий 2026 року повідомляють, що випущені контрольні точки не відтворюють показники COCO зі статті й мають помітно більше параметрів, ніж заявлено в статті. Навчання сегментації та ключових точок ще не реалізовано. Після тегу v1.0 у грудні 2025 року до main нічого не зливали.
2. Для ваг немає окремої заяви про ліцензію. За звичайною практикою ліцензія MIT репозиторію поширюється на його релізні матеріали, а технічні дані вказують, що контрольні точки навчили в цьому проєкті, а не скопіювали з GPL-репозиторію: файли відрізняються розміром і кількістю параметрів від контрольних точок GPL-репозиторію. Однак жоден документ не стверджує, що файли .pt мають ліцензію MIT, а запит спільноти на формальний аудит щодо забруднення AGPL досі відкритий. У документації є прогалина: ніхто не заявляв, що все «перевірено й чисто», але й ніхто не стверджував, що є проблема.
3. Це окрема кодова база, а не пряма заміна скриптів GPL-репозиторію.

Усе це не робить проєкт непридатним. Це означає, що його треба оцінити, а не просто поставити позначку у списку.

Епоха 1: роки суспільного надбання (YOLOv1–YOLOv4)

Joseph Redmon випустив YOLOv1, YOLOv2 (опубліковану як статтю YOLO9000) і YOLOv3 у складі фреймворку Darknet. Файл LICENSE відомий тим, що містить лише три рядки:

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

Це справжнє передання у суспільне надбання. YOLOv4, яку підтримував Alexey Bochkovskiy у форку Darknet, має той самий файл, а не Unlicense, як стверджують деякі посібники з ліцензування. Власний класифікатор GitHub не може визначити її тип і показує «Other». Це важливо, якщо ваше ПЗ для перевірки відповідності читає це поле: сканер позначить ліцензію як невизначену, а не як дозвільну, хоча її текст навряд чи можна зробити дозвільнішим.

Сам Darknet не зовсім занедбаний. Репозиторій Redmon не оновлювався з 2022 року, але тепер README AlexeyAB вказує hank-ai/darknet як рекомендованого, активно підтримуваного наступника на C/C++.

Пастка полягає в портах. У 2026 році майже ніхто не навчає моделі в Darknet. Натомість обирають реалізацію на PyTorch, а такі реалізації мають власні ліцензії:

• ultralytics/yolov3, найпопулярніший порт YOLOv3, має ліцензію AGPL-3.0. Архітектуру із суспільного надбання повторно поширюють під найсуворішою з поширених тут ліцензій. Отримана вами ліцензія цілком залежить від того, чий порт ви встановили через pip.
• eriklindernoren/PyTorch-YOLOv3 має ліцензію GPL-3.0.
• Tianxiaomo/pytorch-YOLOv4 має ліцензію Apache-2.0, тож для v4 зберігся дозвільний варіант на PyTorch.
• У WongKinYiu/PyTorch_YOLOv4, створеному співавтором YOLOv4, взагалі немає файлу LICENSE. Це гірше за copyleft: без ліцензії жодних прав не надано, і за замовчуванням усі права захищено.

Перевіряйте ліцензію репозиторію, який клонували, а не номер версії у статті.

Епоха 2: GPL-3.0 (YOLOv6, v7, v9)

YOLOv6 (Meituan), YOLOv7 і YOLOv9 випускалися під GPL-3.0.

GPL-3.0 є copyleft: якщо ви поширюєте змінену версію або об'єднуєте код GPL зі своїм кодом в одну програму, потрібно надати повний відповідний вихідний код цієї об'єднаної роботи під GPL-3.0. Важливі дві межі. Просте агрегування означає, що окремі незалежні програми, які просто постачаються разом, автоматично не стають єдиною роботою. А тригером є поширення: на відміну від AGPL, якщо ви не випускаєте об'єднану роботу, звичайна GPL не зобов'язує розкривати код. Саме тому деякі компанії тримають модель GPL виключно за власним API.

Цей шлях вужчий, ніж здається, і має три проблемні місця, які рідко враховують заздалегідь. Щойно модель потрапляє на пристрій клієнта або в локальне встановлення, ви її поширюєте. «Лише для внутрішнього використання» перестає бути правдою, коли копія виходить за межі вашої юридичної особи: передати збірку підряднику, команді розробників на аутсорсі чи окремій дочірній компанії означає поширити її, хоча копіювання всередині однієї компанії таким не є. І цей захист працює, лише якщо все, до чого можна дістатися через API, має GPL або дозвільнішу ліцензію, бо один компонент AGPL у будь-якому місці роботи, яку обслуговує система, поширює вимоги розділу 13 на всю роботу, незалежно від тексту самого файла GPL.

Для YOLOv7 і YOLOv9 є варіант MIT, описаний вище. Для YOLOv6 його немає. Найвагоміший доказ цього наводить Baidu: PaddleDetection має ліцензію Apache-2.0, а його мейнтейнери навмисно ізолювали YOLOv5, YOLOv6, YOLOv7 і YOLOv8 в окремому репозиторії GPL-3.0, PaddleYOLO, заявивши, що код цих моделей «will not be merged into PaddleDetection». Коли така велика компанія, як Baidu, зводить стіну, щоб не допустити YOLOv6 до свого фреймворку з дозвільною ліцензією, це показує, чого варта ця ліцензія.

Епоха 3: AGPL-3.0 (YOLOv5, v8, v10, 11, v12, v13, 26, YOLOE)

Ultralytics перейшла на AGPL-3.0 14 квітня 2023 року, а не у 2022-му, як часто стверджують, зокрема посібники, що з'являються на першій сторінці результатів пошуку. Усе випущене після цього (YOLOv8, YOLO11 і YOLO26) має AGPL-3.0, альтернативою є платна Enterprise License. На сторінці ліцензій сказано, що рівень Enterprise охоплює «YOLO26, попередні версії YOLO та будь-які майбутні моделі YOLO», тож ця політика свідомо розрахована на майбутнє. Ціни не оприлюднено.

Цю дату можна перевірити, і варто це зробити, бо популярний виклад цієї історії помилковий у важливому аспекті:

• За всю історію файл LICENSE у ultralytics/yolov5 змінювали рівно тричі. Третя зміна, коміт 34cf749 «Update LICENSE to AGPL-3.0 (#11359)», датований 2023-04-14. У 101 файлі він замінює GNU GENERAL PUBLIC LICENSE на GNU AFFERO GENERAL PUBLIC LICENSE.
• В останньому релізі YOLOv5 за 2022 рік, v7.0 (22 листопада 2022 року), ще була GPL-3.0, як і в попередніх v6.2, v6.1 та v6.0. Те саме стосується тисяч форків, синхронізація яких припинилася до квітня 2023 року: GitHub досі показує для будь-якого з них GPL-3.0.
• Того самого дня, через 41 хвилину, так само оновили ultralytics/ultralytics (PR #2031).

Звідси випливає факт, якого майже ніхто не знає: YOLOv8 вийшла не під AGPL. У січні 2023 року вона вийшла під GPL-3.0, а через три місяці ліцензію змінили на AGPL. Запис PyPI однозначний: у релізах ultralytics від 8.0.0 (10 січня 2023 року) до 8.0.76 (13 квітня 2023 року) вказано GPL-3.0. Версія 8.0.80, завантажена 16 квітня 2023 року, першою вказує AGPL-3.0.

Це не лазівка. Надану ліцензію не відкликають заднім числом, тож старі версії залишаються доступними на умовах, на яких їх випустили. Однак вони застаріли на три роки, їх більше не підтримують і не виправляють, GPL-3.0 усе ще є copyleft (ви замінили умову для мережевого доступу умовою для поширення, а не позбулися copyleft), і комерційна позиція Ultralytics ширша за сам текст ліцензії. Корисний висновок вужчий і загальніший: ліцензія прив'язана до отриманої вами версії, а не до назви проєкту. Зафіксуйте версії залежностей і запишіть умови ліцензії на день отримання копії, адже завтра проєкт може їх змінити, і ваша документація відповідності має залежати від того, яку саме версію ви отримали.

AGPL-3.0 це GPL із розділом 13, мережевою умовою: якщо ви змінюєте Програму, користувачам, які взаємодіють із вашою зміненою версією через мережу, потрібно запропонувати її вихідний код. Це закриває шлях SaaS, який звичайна GPL залишає відкритим.

Зверніть увагу на уточнення, яке більшість статей пропускає. У розділі 0 AGPL «змінити» означає скопіювати або адаптувати роботу у спосіб, що потребує дозволу на використання авторського права. Запуск незміненого коду навчання на власному датасеті означає виконання програми, а не адаптацію її джерельного коду. Це так само, як компіляція власного коду незміненим компілятором GPL не змінює компілятор. Отже, саме навчання автоматично не є тригером, і той, хто стверджує протилежне, не врахував визначення.

До сфери дії ліцензії вас вводить об'єднання або вбудовування пакета у власну кодову базу так, що обидві частини постачаються або обслуговуються як одна програма. За тлумаченням самої FSF, компонування роботи GPL або AGPL з іншими модулями утворює об'єднану роботу. Чи поширив би суд це тлумачення на імпорт Python, поки не перевіряли. Також майте на увазі, що власні комерційні умови Ultralytics вимагають Enterprise License для SaaS-платформ, API та хмарних систем, які використовують YOLO у фоновому режимі, тож позиція постачальника ширша за буквальний текст ліцензії. Вважайте інтеграцію в продукт, який ви надаєте або випускаєте, ризиком і не припускайте, що саме навчання окремо створює такий ризик.

Щодо YOLO26 дати повсюди плутають, тому уточнимо: її попередньо показали у вересні 2025 року на YOLO Vision, фактично випустили в січні 2026 року (у релізі ultralytics 8.4.0, де в примітках сказано «Ultralytics YOLO26 has arrived»), а стаття вийшла в червні 2026 року. Модель міститься в основному репозиторії ultralytics/ultralytics; ultralytics/yolo26 є лише цільовою сторінкою.

Ось що дивує багатьох: академічні YOLO останніх двох років також мають AGPL, і не тому, що їх написала Ultralytics.

• YOLOv10 створена в Університеті Цінхуа. У README сказано "The code base is built with ultralytics."
• YOLOv12: "The code is based on ultralytics."
• YOLOv13: "The code is based on Ultralytics."
• YOLOE, модель «бачити все» з відкритим словником від команди YOLOv10, також має AGPL-3.0 і побудована на Ultralytics.

Copyleft успадковується: похідну від коду AGPL потрібно передавати під AGPL, тож щойно один із цих форків випустили або надали через сервіс, він несе із собою цю ліцензію. (Якщо змінити код і залишити його виключно для себе, жодних зобов'язань не виникає, тож дослідницьке використання не обмежується.) Дослідження незалежне, ліцензія ні. З 2024 року публікація «наступної YOLO» як похідної від Ultralytics стала типовим процесом. Це означає, що AGPL тепер автоматично поширюється на новіші номери версій.

Якщо ви бачите сторінку, де для YOLOv13 указано Apache-2.0, це помилка. У файлі LICENSE, GitHub API й картці моделі зазначено AGPL-3.0.

Дозвільний варіант YOLOv8, якого більше немає

У багатьох досі доступних посібниках, зокрема в попередній версії цієї статті, про Apache-2.0 для YOLOv8 у KerasCV пишуть як про простий спосіб уникнути AGPL YOLOv8. Тепер покладатися на нього не можна. Ось публічні дані:

• В обговоренні KerasCV Clarifications regarding YOLOv8 licensing один із учасників написав, що «many parts are derived form ultralytics». Жоден мейнтейнер не відповів у гілці, тож публічно так і не з'ясували, наскільки незалежною була реалізація.
• Issue KerasHub add YOLOV8 у липні 2025 року закрив мейнтейнер Keras зі словами: «Hey all!! Because of license issues, we have decided to drop this.» Після цього двоє людей запитали, що це означає для наявних комерційних користувачів версії KerasCV. Відповіді не отримав ніхто.
• KerasCV заархівовано, а KerasHub, його наступник, який підтримують, не постачає YOLOv8.

Ми не знаємо, чи пов'язані ці дві події, і не стверджуємо, що сталося щось неналежне. Але будувати продукт на такій основі не варто.

Дозвільні винятки: YOLOX, PP-YOLOE, YOLO-NAS

Не всі YOLO долучилися до copyleft.

• YOLOX (Megvii, 2021) має ліцензію Apache-2.0 без винятків, і для коду, і для ваг. Це досі найчистіший класичний варіант YOLO для комерційного використання, хоча в репозиторії не було комітів із середини 2025 року, а питання про включення попередньо навчених ваг до комерційної програми відкрите з березня 2026 року без відповіді. Текст ліцензії однозначний. Просто зараз нікому відповісти на запитання про неї. Ми писали про запуск YOLOX із LibreYOLO.
• PP-YOLOE (Baidu) має ліцензію Apache-2.0 у складі PaddleDetection. Беріть її звідти, а не з PaddleYOLO, де є майже ідентична директорія конфігурацій і діє GPL-3.0. Та сама модель, та сама компанія, два репозиторії, дві ліцензії. Це ситуація з YOLOv9 навпаки.
• YOLO-NAS (Deci, 2023) часто вводить людей в оману. Код має Apache-2.0, офіційні ваги ні. В окремій ліцензії зазначено: "may not use the Software for any commercial use, including in connection with any models used in a production environment." Після придбання Deci компанією NVIDIA у 2024 році ми не знайшли в репозиторії нових робіт над функціями, а початкові URL ваг більше не працюють (тепер контрольні точки розміщено на іншому хості). Іноді пропонують обхідний варіант: навчити архітектуру з нуля, щоб залишитися в межах Apache. Це припущення правдоподібне, але ні Deci, ні NVIDIA його не підтвердили, і воно погано узгоджується з текстом ліцензії, яка поширюється на «any components comprising the model». Докладніше про YOLO-NAS тут.
• MMYOLO у старих посібниках іноді помилково вказують як Apache-2.0. Насправді MMYOLO має GPL-3.0 (Apache має споріднений проєкт MMDetection), а комітів не було з липня 2024 року.
• YOLO-World (Tencent) має GPL-3.0, а не AGPL і не дозвільну ліцензію. Варто про це сказати, оскільки часто припускають, що YOLO з відкритим словником мають дозвільну ліцензію через їхню спорідненість з екосистемою на кшталт CLIP.

Ці випадки охоплюють три найпоширеніші помилки з ліцензуванням у цій сфері: припущення, що ваги мають ту саму ліцензію, що й код; що всі проєкти однієї організації мають однакову ліцензію; і що ліцензію моделі можна визначити за її назвою.

Ліцензії охоплюють код, а не ідеї (але пам'ятайте про патенти)

Один принцип лежить в основі кожного з описаних вище дозвільних варіантів: авторське право захищає форму вираження, а не ідеї. Це не гасло, а норма закону по обидва боки Атлантики.

У США це 17 U.S.C. 102(b), де «ідеї, процедури, процеси, системи, методи роботи, концепції, принципи або відкриття» виключені з-під захисту авторського права. Ця норма сягає справи Baker v. Selden (1879). У ЄС, де діє право, що регулює нашу діяльність і, ймовірно, стосується багатьох читачів, стаття 1(2) Директиви про програмне забезпечення (2009/24/EC) зазначає, що «ідеї та принципи, на яких ґрунтується будь-який елемент комп'ютерної програми», не захищені. Суд ЄС підтвердив у справі SAS Institute v World Programming (C-406/10, 2012), що функціональність програми, її мова програмування та формати даних самі по собі не є захищеною формою вираження. Захищено лише код.

Архітектура, описана в статті arXiv, є опублікованою ідеєю. Будь-хто може її реалізувати. Не можна копіювати або адаптувати чужі вихідні файли GPL/AGPL і повторно ліцензувати результат. Незалежна реалізація, написана людьми на основі статті, а не вихідного коду, є новою роботою, ліцензію на яку обирає її автор.

Два чесні застереження, які більшість постачальників оминає:

• Незалежність має бути справжньою. Захищений варіант цього підходу передбачає процес чистої кімнати: люди, які пишуть код, працюють за статтею та специфікацією, а не з copyleft-вихідним кодом. Уважно прочитати репозиторій GPL, а потім «переписати його» не те саме. Якщо справа колись дійде до розгляду, ця різниця матиме значення.
• Цей аргумент стосується авторського права, а не патентів. Незалежна розробка не є захистом від патенту. Чиста кімната для повторної реалізації розв'язує питання авторського права, але нічого не змінює щодо патентів. Сьогодні немає широко відомого патенту на архітектури YOLO, але «ще ніхто не подав позов» не означає «немає підстав для позову».

Ваги мають окрему ліцензію

Найдорожча помилка в цій сфері: перевірити код і забути про контрольну точку. Ліцензії поширюються на три рівні, і всі вони можуть відрізнятися:

1. Код. Усе описане вище.

2. Ваги. Іноді умови вказані прямо, як у випадку YOLO-NAS. Іноді заявлені: на сторінці ліцензій Ultralytics стверджує, що AGPL-3.0 «охоплює код навчання та моделі, створені цим кодом навчання», поширюючи це також на моделі, які ви навчили власноруч за допомогою її коду. Як власник авторських прав на власні опубліковані матеріали компанія може встановлювати умови для своїх контрольних точок. Чи є ваги, створені вами, юридично похідною роботою коду навчання, справді відкрите питання: судових прецедентів немає, а таке тлумачення суперечить загальному правилу самої FSF про те, що на результати програми автоматично не поширюється авторське право на програму. Та те, що питання не вирішене, не означає, що ризику немає. На практиці вважайте опубліковані ваги AGPL обтяженими ліцензійними умовами.

Ось де ця стаття може підвести тих, хто скористається її порадою: у репозиторіях GPL для YOLOv7 і YOLOv9 взагалі нічого не сказано про ваги. Їхні контрольні точки є релізними матеріалами у репозиторії GPL-3.0, але окремого дозволу немає. Якщо завантажити ці файли .pt у реалізацію під MIT, код буде чистим, а статус контрольної точки залишиться нез'ясованим. Якщо ви перейшли через ліцензію, використовуйте ваги, навчені самим дозвільним проєктом, або навчіть власні.

3. Дані навчання. Анотації COCO мають ліцензію CC BY 4.0, тож із мітками все гаразд. Зображення не належать COCO для ліцензування: це фотографії Flickr, на які поширюється набір індивідуальних умов, і консорціум COCO прямо заявляє, що не володіє ними. Більшість галузі вважає цей ризик низьким і рухається далі, але «з COCO все гаразд» стосується лише анотацій. Для інших датасетів вимоги швидко стають суворішими: чимало наборів аерофотознімків, медичних зображень і даних водіння забороняють комерційне використання, а дозвільна ліцензія коду моделі не скасовує таких обмежень.

Щоразу перевіряйте всі три рівні.

Коротко про MIT та Apache-2.0

Ми випускаємо бібліотеку під MIT, тому нам було б зручно сказати, що MIT просто найкраща ліцензія. Чесне порівняння цікавіше.

MIT не означає відсутності зобов'язань: у копіях, які ви поширюєте, потрібно зберігати повідомлення про авторське право й текст ліцензії. Це реальна умова, але виконати її нескладно. А Apache-2.0 має те, чого немає в MIT: пряме надання патентної ліцензії від кожного учасника та положення про взаємність, за яким ліцензія припиняється для кожного, хто подає позов щодо цієї роботи. MIT про патенти мовчить. Для компанії, яка найбільше боїться патентних ризиків, Apache-2.0 може бути безпечнішим варіантом, саме тому значна частина екосистеми дозвільної детекції (YOLOX, RT-DETR, D-FINE, DEIM) використовує Apache-2.0.

MIT забезпечує простоту та сумісність. Жодна з цих ліцензій ніколи не змусить вас публікувати вихідний код, а саме про це йдеться у цій статті. Якщо хтось каже, що найважливіше рішення це MIT чи Apache, він щось продає. Важливий вибір між дозвільною ліцензією та copyleft.

Яку YOLO можна використовувати?

• Комерційний продукт із закритим кодом: YOLOv7 або YOLOv9 з репозиторію MIT лабораторії, YOLOX або PP-YOLOE (з PaddleDetection) серед оригіналів, або фреймворк MIT, який підтримують, наприклад LibreYOLO, якщо не хочете самостійно збирати й перевіряти все це. Уникайте GPL і AGPL, якщо не плануєте відкрити код усієї програми або придбати Enterprise License.
• Проєкт із відкритим кодом: будь-яка модель, якщо її ліцензія сумісна з вашою. Якщо ваш проєкт має AGPL, лінійка Ultralytics добре підходить, а найновіші дослідження (YOLOv13, YOLO26, YOLOE) спершу з'являються саме там.
• Дослідження та бенчмаркінг: ліцензії майже не обмежують вас. Використовуйте будь-які моделі, що відповідають статті, з якою ви порівнюєте результати.
• План «розберемося пізніше»: не спрацює. Вилучити залежність AGPL після створення продукту означає заново навчати, валідувати й експортувати все, зокрема ваги. Спочатку оберіть репозиторій, а отже, і ліцензію.

Щоб порівняти самі фреймворки, а не їхні ліцензії, див. Найкращі альтернативи Ultralytics у 2026 році.

Варіант MIT: що постачає LibreYOLO

Розкриття інформації: LibreYOLO є нашим проєктом, а його ліцензія і є причиною появи цієї статті.

LibreYOLO це одна кодова база під MIT для наведених нижче детекторів з єдиним API, вбудованими навчанням та експортом в ONNX, TensorRT, OpenVINO і NCNN. Без copyleft, мережевої умови й рівня Enterprise.

Ось повний перелік моделей виявлення об'єктів із джерелом кожного сімейства та його ліцензією, щоб ви могли точно побачити, звідки походить кожен дозвільний варіант:

Два моменти в цьому стовпці навмисно подано без прикрас.

У кодову базу не скопійовано вихідний код GPL або AGPL. Кожне з наведених вище сімейств походить від джерела з ліцензією суспільного надбання, MIT або Apache-2.0. Саме це зберігає ліцензію фреймворку MIT. Якщо в архітектури є як дозвільне джерело, так і джерело з copyleft, ми використовуємо дозвільне: наші YOLOv9 і YOLOv7 походять від репозиторію лабораторії під MIT, а не від оригіналів GPL, а наш RTMDet від MMDetection під Apache, а не від MMYOLO під GPL. YOLO-World відсутня у списку, хоча про неї часто питають, оскільки вона має GPL-3.0 і дозвільного джерела для неї немає.

Дозвільна ліцензія не означає відсутність обмежень, і ми краще скажемо про це прямо, ніж дозволимо вам дізнатися про них під час аудиту. Більші розміри DEIMv2 успадковують умови Meta для DINOv3, зокрема заборону військового, ядерного використання, шпигунства та застосування зброї. Це справжнє обмеження для тих, хто працює у сфері подвійного призначення. Деякі контрольні точки з дослідницьких попередніх версій навчали на некомерційних датасетах (DOTA, VisDrone), і на Hugging Face їх позначено як cc-by-nc, а не тихо подано як вільні для використання. Та сама обережність, якої ми дотримуємося щодо чужих ваг, стосується й наших: контрольні точки YOLO9 перетворено з контрольних точок лабораторного репозиторію під MIT, тож на них поширюються ті самі умови, про які йшлося вище: їх «заявлено, але формально не перевірено». Ліцензія MIT охоплює написаний нами код. Для кожної контрольної точки умови джерела та даних навчання публікуються окремо.

Крім виявлення, той самий API підтримує сегментацію екземплярів і семантичну сегментацію, оцінювання пози, орієнтовані рамки, класифікацію (MobileNetV4, ConvNeXt, EfficientNetV2, ResNet, CLIP), оцінювання монокулярної глибини, відновлення зображень та оцінювання напрямку погляду.

pip install libreyolo

from libreyolo import LibreYOLO

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

Той самий робочий процес YOLO, без клопоту з ліцензіями.

Поставте зірку на GitHub: github.com/LibreYOLO/libreyolo | Документація: libreyolo.com/docs

Торговельні марки та афілійованість: YOLO, YOLOv8, YOLO11, YOLO26 і Ultralytics є торговельними марками відповідних власників, зокрема Ultralytics Inc. LibreYOLO є незалежним проєктом і не пов'язаний, не спонсорується та не схвалений Ultralytics або будь-якою іншою організацією, названою у цій статті. Назви продуктів і репозиторіїв використано лише для ідентифікації та порівняння згаданого програмного забезпечення.

Ця стаття містить загальну інформацію, а не юридичну консультацію. Вона актуальна станом на 11 липня 2026 року і написана одним із постачальників у цьому порівнянні. Перед випуском продукту перевірте актуальну ліцензію.