Rate this post

.NET Aspire позиціонується як безкоштовна платформа з відкритим вихідним кодом. Однак це твердження заслуговує на уважніший розгляд. Глибший аналіз внутрішніх компонентів виявляє пропрієтарний елемент у самому центрі системи оркестрації — що піднімає серйозні питання щодо прозорості, ліцензування та довіри.

Детальніший погляд на середовище виконання Aspire

Після створення нового застосунку Aspire у Windows і його запуску спочатку все виглядає нормально. Панель керування запускається коректно, а досвід розробника відповідає очікуванням від інструмента з відкритим вихідним кодом на .NET.

Однак під час вивчення встановлених пакетів NuGet — зокрема Azure Hosting App Orchestration Tools — виявляється дивний виконуваний файл: DCP.exe.

Що це за файл? Чому він там?

Той самий бінарник на macOS

Повторення експерименту на macOS призводить до того ж результату. Хоча версія Aspire там трохи старіша, той самий бінарний файл DCP з’являється в папці пакетів.

Це піднімає критичне питання:
Якщо Aspire — це відкритий вихідний код, чому він містить закритий виконуваний файл?

Ліцензія розповідає іншу історію

Відкриття ліцензійного файлу, пов’язаного з цим бінарником, виявляє дещо несподіване:
Microsoft Developer Control Plane.

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

Цей бінарник не є відкритим вихідним кодом.

Ще більш тривожно те, що під час встановлення Aspire не з’являється явного запиту на прийняття ліцензії. Пропрієтарний компонент безшумно вбудовується в ланцюжок інструментів.

Що таке DCP?

Документація Aspire описує DCP (Developer Control Plane) так:

«В основі функціональності оркестрації хоста застосунків Azure. Відповідає за оркестрацію всіх ресурсів».

Іншими словами, це не якийсь необов’язковий допоміжний інструмент — він є центральним елементом роботи Aspire.

У документації також зазначається, що DCP написаний на Go, а не на .NET, щоб забезпечити глибоку нативну інтеграцію з API Kubernetes.

Чого в ній не згадується:
що цей критично важливий компонент є закритим вихідним кодом.

Звідки береться цей бінарник?

Схоже, що DCP не поширюється через публічний канал NuGet. Натомість у файлах проєктів Aspire присутні посилання на завантаження пакетів Microsoft Developer Control Plane з приватних джерел.

Є підстави вважати, що ці бінарники можуть походити з внутрішнього репозиторію Microsoft на GitHub, до якого громадськість не має доступу.

Таким чином, ланцюжок інструментів підтягує пропрієтарний бінарник із приватного джерела й упаковує його в Aspire — не надаючи можливості переглянути або прийняти його ліцензію.

Побоювання щодо телеметрії та збору даних

У ліцензії згадуються збір даних і обробка персональних даних. Згідно з коментарями інженерів Microsoft, DCP наразі не збирає телеметрію або дані про використання.

Слово «наразі» тут робить дуже багато.

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

А оскільки DCP запускається на машинах розробників, ця невизначеність має значення.

Чи є це все ще «відкритим вихідним кодом»?

.NET Aspire розміщений під егідою .NET Foundation, яка вимагає ліцензій, схвалених OSI. Формально Aspire цим вимогам відповідає.

Однак на практиці він обгортає пропрієтарний бінарник у самому центрі своєї архітектури.

Це означає:

  • Ви не можете повністю зібрати Aspire з вихідного коду.

  • Ви не можете провести аудит найкритичнішої частини його логіки оркестрації.

  • Ви не можете форкнути його в повністю незалежну реалізацію.

Це розтягує визначення «відкритого вихідного коду» за межі того, що більшість розробників вважала б розумним.

Стурбованість спільноти та відкриті питання

Цю проблему вже було піднято публічно, зокрема на GitHub. Одне з поставлених питань:

Чи є плани відкрити вихідний код Developer Control Plane?

Поточна мова ліцензії наводить на думку, що Microsoft може позиціонувати DCP як майбутній комерційний продукт.

Якщо це станеться, це означатиме, що Aspire фактично є обгорткою навколо пропрієтарного ядра, яке згодом може стати платним програмним забезпеченням.

Це був би класичний «rug pull».

Чому ядро написане на Go?

Ще одна незручна деталь:
DCP написаний на Go, а не на .NET.

Для платформи, що позиціонується як флагманське рішення .NET для оркестрації, винесення найважливішої логіки в Go-бінарник виглядає суперечливо.

Якщо .NET має бути першокласною платформою для cloud-native інструментів, то чому тоді його оркестраційне ядро не реалізоване на .NET?

Справжня цінність Aspire?

Одне з найпроникливіших спостережень із глибокого технічного аналізу полягає в тому, що бінарник DCP може бути найціннішою частиною Aspire. Він виглядає значно складнішим, ніж оточуючий його C#-код.

У цьому світлі Aspire починає виглядати не стільки як платформа з відкритим вихідним кодом, скільки як тонка обгортка навколо закритого рушія.

Кращий напрямок уперед

Ось конструктивна пропозиція:

  • Відкрити вихідний код Developer Control Plane.

  • Якщо Go абсолютно необхідний, залишити його на Go — але зробити код публічним.

  • Ще краще — реалізувати його на .NET.

  • Надати документований, придатний для аудиту API оркестрації.

Повністю відкритий, нативний для .NET рушій оркестрації Kubernetes був би справді вражаючим — і набагато більш відповідним духові .NET Foundation.

Остаточний вердикт

Чи можна сьогодні чесно назвати .NET Aspire платформою з відкритим вихідним кодом?

Ні.

Не тоді, коли пропрієтарний бінарник Microsoft знаходиться в центрі його функціональності.
Не тоді, коли розробники не можуть переглянути, зібрати або замінити цей компонент.
Не тоді, коли ліцензійні умови тихо зв’язують компанії без явної згоди.

Поки цю проблему не буде вирішено, важко рекомендувати Aspire добросовісно.

Microsoft повинна прояснити статус Developer Control Plane, опублікувати його вихідний код або, принаймні, бути прозорою щодо закритої залежності, вбудованої в Aspire.

Прямо зараз ця ситуація не просто заплутана — вона глибоко тривожна.