Перейти к содержанию

Шесть проверок перед docker compose up: как заранее понять, какую функцию у вас заберут первой

Опубликовано
  • Админы
Хронология лицензионных разворотов в open source
Восемь лет разворотов и процедура проверки проекта до установки

При выборе самохостного сервиса смотрят на интерфейс, на аппетиты к памяти и на наличие готового compose-файла. Почти никто не смотрит на источник дохода проекта — хотя именно этот параметр лучше всех предсказывает, что произойдёт с вашей установкой в горизонте года.

Проверка занимает четверть часа, выполняется однократно и укладывается в шесть пунктов. Ниже — сами пункты вместе с командами, восьмилетний ряд аналогичных разворотов для калибровки ожиданий и недавний случай, из-за которого тема снова стала актуальной: в PLANKA вход через SSO перебрался из бесплатной сборки в платную, причём на минорном обновлении.

Оговорка сразу: ни один из шести пунктов не является запретом на установку. Они показывают исключительно то, за какое место вас держат.

Событие: PLANKA 2.2 и переезд SSO

PLANKA — самохостная канбан-доска, узнаваемый аналог Trello и один из самых частых ответов на вопрос, чем заменить Trello у себя. Начиная с версии 2.2.0 аутентификация по OIDC/SSO доступна только в редакции Pro. Существенно, что мейнтейнеры объявили об этом заранее, в issue #1754, а не поставили перед фактом.

Обоснование состоит из трёх тезисов, и его стоит прочитать, а не сводить к «разработчики захотели денег»:

SSO — безусловный лидер по стоимости поддержки: больше сотни обращений по настройке в месяц.

Тезис второй: SSO задумывался как корпоративная возможность и оказался в Community по недоразумению. Тезис третий: согласно их же лицензионному руководству, прямая поддержка полагается лишь клиентам Pro и Enterprise, а функция, порождающая сотню обращений ежемесячно, без поддержки нежизнеспособна.

Встречное движение тоже было: в Community переехали двухфакторная аутентификация на TOTP, автоматический выход по бездействию и доверенные устройства. Логика мейнтейнеров формулируется так: защита учётной записи остаётся бесплатной и открытой, корпоративное управление идентичностью — платное.

⛔ Так делать нельзя

Теперь про действительно опасную часть, которая к спорам о лицензиях отношения не имеет. Учётные записи, созданные через SSO, пароля не содержат. При обновлении такие пользователи деактивируются, и администратору предстоит вручную выдавать им пароли либо восстанавливать доступ. Если администратор сам заходил через SSO, результат — сервис, в который не может войти никто, и распутывается это только скриптом или переменными окружения.

Правило, которое стоит унести отдельно от всего остального текста: перед любым обновлением сервиса с внешней аутентификацией убедитесь, что заведён локальный администратор с паролем. Оно старше PLANKA лет на двадцать и работает независимо от лицензионной политики вендора.

Тот же сюжет за последние восемь лет

Случай PLANKA не уникален и далеко не самый громкий. Куда полезнее рассматривать его в ряду предшественников: тогда становятся видны и закономерность, и то, что движение иногда идёт в обратную сторону.

ГодСобытиеРеакция экосистемы
Октябрь 2018MongoDB выпускает SSPL для Community Serverлицензия так и не одобрена OSI; дистрибутивы выносят пакет
Январь 2021Elasticsearch и Kibana уходят с Apache 2.0 на SSPL / Elastic LicenseAWS форкает OpenSearch
Апрель 2021Grafana, Loki и Tempo переезжают с Apache 2.0 на AGPLv3форка не возникло, AGPL приняли
Октябрь–декабрь 2022домен и товарный знак Gitea переданы коммерческой Gitea Ltd без голосования мейнтейнеровCodeberg объявляет Forgejo 15 декабря 2022
Август 2023HashiCorp переводит продукты, включая Terraform, на BUSL 1.1форк OpenTofu, в сентябре — под крылом Linux Foundation
Март 2024Redis уходит с BSD на RSALv2 / SSPLфорк Valkey под Linux Foundation
Август 2024Elastic добавляет AGPLv3 как опцию«Elasticsearch снова open source»
Май 2025Redis 8 добавляет AGPLv3Valkey к этому моменту живёт своей жизнью
Август 2026PLANKA 2.2: OIDC/SSO → Proпока обсуждение в issue и на форумах

📌 Заметка

Две строки в таблице ломают удобную схему «все движутся в одну сторону». Elastic в 2024-м и Redis в 2025-м вернулись к лицензии, одобренной OSI, и обе компании признали, что ущерб отношениям с сообществом оказался больше расчётного. Давление форков, стало быть, работает. Только измеряется оно годами, а решение об обновлении вы принимаете сегодня вечером.

Три сценария, которые постоянно смешивают

Значительная часть споров под подобными новостями возникает оттого, что фраза «проект закрылся» покрывает три разных явления с несовпадающими последствиями.

Сценарий A — меняется лицензия исходного кода. MongoDB, Elastic, HashiCorp, Redis. Код по-прежнему открыт для чтения, но правила использования другие. Домашнего сервера это обычно не касается вовсе: SSPL и BUSL нацелены на тех, кто перепродаёт продукт как услугу. А вот для форков ситуация критическая — потому они и появляются практически сразу.

Сценарий B — функция уезжает в платную редакцию, лицензия не меняется. Это и есть PLANKA. Юридический статус кода прежний, но конкретной возможности в бесплатной сборке больше нет. Для частного пользователя такой сценарий болезненнее первого, поскольку срабатывает мгновенно — на ближайшем docker compose pull.

Близкий родственник этого сценария — пересмотр условий бесплатного тарифа у хостинг-провайдера. Механика с точки зрения пользователя идентична: правила изменились уже после того, как всё было построено и настроено.

Сценарий C — меняется владелец проекта и бренда. Gitea. Код тот же, лицензия та же, но поменялся тот, кто определяет завтрашний день. Форк здесь рождается не из юридических ограничений, а из потери доверия к управлению.

⚠️ Осторожно

Отсюда прикладной вывод: встретив заголовок «проект X больше не open source», первым делом определите сценарий. От него зависит, требуются ли действия вообще. По сценарию A домашнему пользователю обычно делать нечего. По сценарию B действовать надо быстро. По сценарию C надо определиться, за кем вы идёте, и время на размышление, как правило, есть.

Шесть проверок до установки

Переходим к главному. Пункты ниже не про идеологию и не про то, «правильный» ли перед вами проект. Они отвечают на один-единственный вопрос: чем этот проект зарабатывает и что заберут первым, когда денег станет недоставать.

Процедура проверки проекта перед установкой
Порядок проверок составлен по публичным лицензионным материалам PLANKA, Redis, Elastic, Grafana, HashiCorp и Forgejo

1. Биография файла LICENSE

Читать нужно не действующий текст лицензии, а историю его изменений:

git clone --filter=blob:none https://github.com/<org>/<repo> && cd <repo>
git log --follow --oneline -- LICENSE
git log -1 --format=%ci -- LICENSE   # когда трогали в последний раз

Единственный коммит «Initial commit» — здоровая картина. Два-три коммита с сообщениями вида «update license» приговором не являются, но остальные пункты после этого стоит проходить внимательнее.

2. CLA против DCO

Пункт, который недооценивают чаще прочих, а предсказательная сила у него выше всех остальных. Требование подписать CLA (Contributor License Agreement) с передачей прав компании означает, что компания юридически способна в одностороннем порядке сменить лицензию на весь код, включая чужой вклад. Использование DCO (Developer Certificate of Origin) оставляет права за авторами, и односторонний разворот становится практически неосуществимым.

ls CONTRIBUTING.md CLA.md .github/  2>/dev/null
grep -ril "contributor license agreement\|Signed-off-by" . --include="*.md" | head

Все громкие развороты из таблицы выше случились в проектах либо с CLA, либо с единственным корпоративным правообладателем. Это не стечение обстоятельств, а работающий механизм.

3. Владелец домена и товарного знака

Ровно об этом история Gitea. Изучите подвал сайта, страницу About, whois домена и владельца организации на GitHub. Фонд (Linux Foundation, Apache, SFC), зарегистрированная некоммерческая организация (Codeberg e.V.) и ООО с единственным владельцем дают три очень разных прогноза на пятилетнем горизонте. Плохого варианта среди них нет, но третий требует запасного плана.

4. Прайс как перечень будущих потерь

Откройте страницу с тарифами и разберите таблицу Community против Pro/Enterprise заранее, до установки. Всё, что у конкурентов уже находится в платной колонке, а у вашего кандидата пока бесплатно, попадает в зону риска. Показатель номер один здесь — SSO: выражение «SSO tax» появилось именно потому, что единый вход стал типовым первым платным рубежом почти по всей отрасли.

5. Каталоги ee/, pro/ и enterprise/

find . -maxdepth 2 -type d \( -name "ee" -o -name "pro" -o -name "enterprise" \)
find . -name "LICENSE*" -not -path "./node_modules/*"

Собственный файл LICENSE внутри такого каталога означает, что линия между бесплатным и платным уже проведена прямо в коде. Это, к слову, честнее неявных ограничений: и границу видно, и её перемещение заметно.

6. Возможность забрать данные без продукта

Самая приземлённая из всех проверок, и лицензий она вообще не касается. Вопрос звучит так: если завтра проект станет для вас неприемлемым, получится ли вытащить данные?

docker compose exec -T db pg_dump -U <user> <db> > backup.sql
docker compose exec -T db psql -U <user> -d <db> -c '\dt'

Читаемая схема в обычной СУБД равна свободе уйти. Закрытый бинарный формат или облачный API как единственная дорога к собственным данным равны привязке, и никакая лицензия на это не влияет.

✅ Как правильно

Компактный список, который имеет смысл проходить перед каждым обновлением, а не только при новостях о лицензиях:

  • заведён локальный администратор с паролем, независимый от внешнего провайдера входа;
  • прочитан CHANGELOG именно целевой версии, а не абстрактной «последней»;
  • образ в compose зафиксирован явной версией, а лучше по digest image@sha256:..., вместо :latest;
  • дамп базы снят сегодня и хотя бы однажды проверен восстановлением;
  • известно, существует ли форк и в каком он состоянии.

Обратная сторона возмущения

Ради честности стоит проговорить и противоположную позицию. Открытость кода не отменяет того, что сопровождение стоит денег, а сотня обращений в месяц по одной функции — это чей-то реальный неоплаченный труд. Open core остаётся законной моделью, и немалая часть ежедневно используемых нами продуктов существует именно благодаря ей. Претензия к PLANKA справедлива не потому, что функция стала платной, а потому, что она была бесплатной и уехала, причём на минорной версии, от которой ломающих изменений обычно не ждут.

❗ Главное

И честное замечание о форках, которое часто опускают. Форк не бесплатен и не мгновенен. Forgejo объявили в декабре 2022-го, а до полноценного hard fork с расхождением кодовой базы проект добрался лишь в феврале 2024-го — больше года он оставался «drop-in заменой». OpenTofu получил cease-and-desist от HashiCorp в апреле 2024-го. Форк существует ровно до тех пор, пока у него есть мейнтейнеры и финансирование; кладбище форков заметно многолюднее списка успешных. Наличие форка — довод, но не гарантия.

Если PLANKA уже стоит

Коротко о порядке действий: отключите автоматическое обновление; создайте или проверьте локального администратора с паролем; снимите дамп базы; прочитайте issue #1754 целиком, включая комментарии про миграцию; оцените, нужен ли SSO на установке из трёх человек (для большинства домашних инсталляций ответ отрицательный) — и только после этого обновляйтесь. Если SSO нужен, а покупать Pro не хочется, время у вас есть: прежняя версия никуда не делась и продолжает работать.

Источники

💬 Вопрос к сообществу

Интересна практика, а не декларации. Кто уже сталкивался с тем, что после обновления самохостного сервиса пропала функция, на которой всё держалось, — и чем всё кончилось: оплатили, откатились, ушли на форк? Отдельный вопрос к тем, у кого дома крутится больше десятка сервисов: вы действительно открываете CHANGELOG перед docker compose pull или узнаёте о переменах от пользователей?

Featured Replies

No posts to show

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

Последние посетители 0

  • Ни одного зарегистрированного пользователя не просматривает данную страницу
Яндекс.Метрика

Account

Navigation

Поиск

Поиск

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.