Maven Central: малый объём публикаций не освобождает SDK
Небольшой объём публикаций сам по себе не освобождает коммерческий SDK от требований Maven Central Publisher Pro. Sonatype разделяет два основания: объём организации и коммерческий характер артефакта. Если команда выпускает клиент платного сервиса, проверять нужно оба, а не только число загруженных файлов.
Сентябрьское разъяснение и октябрьские условия
В разъяснении от 8 сентября 2026 года Sonatype указывает применение этих оснований с 1 октября 2026. Артефакт коммерческой природы определяется по связи с внедрением, интеграцией или работой коммерческого продукта либо сервиса. Малый объём не создаёт отдельного исключения для такого артефакта.
Одновременно компания прямо говорит: сопровождение проекта организацией не делает его автоматически коммерческим. Обычная community open source-публикация не объявлена платной целиком. Поэтому неверны сразу два простых ответа: «мы маленькие, правила нас не касаются» и «теперь любое ПО компании требует оплаты».
Два вопроса, которые нельзя заменить одним
Сначала опишите назначение каждого публикуемого компонента. Затем отдельно посмотрите объём публикаций и область организации в текущем учёте. Лицензия, публичный репозиторий или редкие релизы сами по себе не завершают оценку коммерческой природы по опубликованному разъяснению.
Для учебного примера возьмём портфель небольшой SaaS-команды: клиент сервиса, самостоятельную библиотеку и общий namespace. Это вымышленные артефакты для разбора правил, а не официальные решения Sonatype по конкретным проектам.
| Учебный артефакт | Связь с продуктом | Сведения об объёме | Что требуется проверить | Следующее решение |
|---|---|---|---|---|
| SDK платного сервиса | Нужен для интеграции с коммерческим продуктом | Релизы редкие | Применимость коммерческого критерия независимо от объёма | Уточнить нужные условия публикации |
| Самостоятельная community-библиотека | По условию не часть коммерческого предложения | Объём ещё не сверен | Назначение и текущие пороги организации | Не классифицировать только по работодателю автора |
| Смешанный портфель | Есть компоненты разного назначения | Учёт может охватывать общую организацию | Область конкретных artifact/group ID и возможность review | Подготовить обоснованный запрос по нужной части |
| Независимый проект с частыми выпусками | Коммерческая связь не установлена | Возможен высокий объём | Текущие пределы и доступные корректировки | Проверить Usage Center и условия рассмотрения |
Где смотреть действующие пределы
Страница Publishing Limits относит текущие пороги, расход организации и предупреждения к Usage Center. Она также отмечает, что пороги могут корректироваться. Поэтому прошлые графики распределения публикаций нельзя копировать в план как вечную бесплатную квоту.
Различайте расход, предупреждение и принятое исключение. Внутреннее письмо разработчика «обычно помещаемся» не подтверждает применимость правил к следующему выпуску. Сохраните источник проверки и дату решения, чтобы смена ответственного не обнулила понимание условий.
Не подменяйте правила публикации условиями скачивания зависимостей. Рассматриваемая задача относится к издателю артефактов. Если приложение только использует публичные компоненты, сначала выясните, есть ли у команды собственная публикация, к которой относится этот процесс.
Как подготовить рассмотрение смешанного портфеля
Разъяснение допускает запрос review для community-артефактов, не являющихся частью коммерческой деятельности, по отдельным артефактам или group ID. Возможность подать запрос не означает его одобрения. Нужны понятные границы компонента и описание назначения.
В подготовке полезны координаты, репозиторий, связь с продуктами и причина отдельного рассмотрения. Не добавляйте выдуманные независимость или статус только ради льготного результата. Важно, чтобы описание соответствовало тому, как компонент действительно распространяется и используется.
Что включить в процесс выпуска
- Составьте перечень собственных публикуемых артефактов.
- Опишите назначение и связь каждого с коммерческим предложением.
- Проверьте область организации и текущий расход в официальном учёте.
- Отделите нужные уточнения и возможный review community-компонентов.
- Сохраните подтверждённые условия и владельца процесса.
- Проверьте готовность публикации до обещанного срока выпуска.
- Повторяйте проверку при изменении портфеля и правил площадки.
Оптимизация лишних публикаций может быть полезна для расхода, но не отменяет коммерческий критерий. Не стоит обещать команде решение одной уборкой файлов, если основание связано с назначением SDK. Точно так же новый namespace не должен быть способом скрыть реальный состав организации.
Для разработки API-интеграции передайте план распространения SDK вместе с контрактом API. В автоматизации выпуска назначьте владельца проверки условий, а при доработке проекта учитывайте существующих пользователей артефакта. В рамках статьи аккаунты не открывались, обращения не отправлялись, публикации и оплаты не выполнялись.
Вопросы и ответы
Нужен ли Publisher Pro при небольшом объёме коммерческого SDK?
Разъяснение Sonatype рассматривает коммерческую природу независимо от объёма. Нахождение ниже порогов не создаёт для такого артефакта отдельного объёмного исключения.
Где уточнять стоимость и условия Publisher Pro?
Сверяйте актуальные официальные условия для своей организации и перечня артефактов. Старые ценовые каталоги и таблицы объёма публикаций не следует считать действующим предложением.
Правила издателя Maven Central относятся к любому скачиванию библиотек?
Рассматриваемые условия посвящены публикации собственных артефактов. Использование чужой зависимости и выпуск своего SDK нужно сначала различить как разные действия команды.