Сравнительный анализ лицензионных режимов для IT-продуктов

Когда IT-компания слышит слово «лицензия», она обычно представляет себе договор с правообладателем на использование софта. На практике же в России под этим термином скрываются три принципиально разных юридических режима, и путаница между ними обходится слишком дорого — от блокировки продукта до отказа в сертификации. Это гражданско-правовая лицензия на ПО (ст. 1235–1236 ГК РФ), открытая лицензия на код по модели OSI и государственная лицензия ФСБ на деятельность с криптографией (СКЗИ). Картина, знакомая по десяткам объектов внедрения: компания разработала медицинскую систему с модулем шифрования, использовала GPL-библиотеку, договор с вендором не подписала и при этом уверена, что лицензия на Linux покрывает требования регулятора. В реальности спустя полгода приходит отказ в сертификации, а то и предписание о нарушении авторских прав. Разберёмся, чем отличаются эти режимы и как выстроить легальную защиту без пробелов.

Что именно мы сравниваем: три уровня лицензирования в IT

В своей практике я не раз сталкивался с тем, что один и тот же термин «лицензия» в техническом задании на разработку и в запросе от ФСБ означает совершенно разные вещи. Чтобы не утонуть в терминологии, запомните три уровня регулирования.

Гражданская лицензия — это разрешение от правообладателя использовать конкретную программу для ЭВМ. По сути, договор между вами и вендором: неисключительная лицензия на коробочный продукт или исключительная на уникальную разработку. Всё регулируется ст. 1235–1236 ГК РФ. Отсутствие такого договора даже на легально купленный код превращает его в «чёрный» с точки зрения суда.

Государственная лицензия — выдаётся органом власти (в нашем случае ФСБ, для отдельных направлений — Минпромторг или Росздравнадзор) и разрешает вид деятельности: разрабатывать, производить или продавать СКЗИ. Это не о праве пользоваться кодом, а о допуске компании к работам. Без неё даже самый качественный криптографический модуль не пройдёт сертификацию.

Открытая лицензия — третий и самый часто упускаемый из виду режим. Он не сводится к ГК РФ напрямую: работает связка ст. 1286.1 ГК РФ и стандартов Open Source Initiative. Если вы встраиваете MIT-библиотеку, вы не подписываете договор с разработчиком, но обязаны соблюсти условия лицензии — иначе получите нарушение авторских прав в коммерческом продукте.

Для наглядности три режима удобно сравнить по ключевым параметрам:

Ключевое отличие: гражданская лицензия защищает использование продукта, открытая — распространение и модификацию кода, государственная — легальность деятельности вендора. Без государственной лицензии ФСБ даже легально купленное ПО с гражданской лицензией не может быть сертифицировано как СКЗИ.

Гражданская лицензия на ПО: неисключительная vs исключительная

Когда я готовлю документы для клиента, всегда обращаю внимание на то, что ст. 1236 ГК РФ выделяет всего два вида лицензионных договоров — простую (неисключительную) и исключительную лицензию. Остальное — от лукавого. И разница между ними критична для дальнейшей судьбы продукта.

Неисключительная (простая) лицензия

В 90% B2B-проектов, которые я сопровождал при внедрении систем автоматизации медосмотров, использовалась именно неисключительная лицензия. Вендор продаёт право использовать софт сотням клиентов, оставляя за собой исключительное право. Для покупателя это означает: можно запускать программу, воспроизводить её, иногда модифицировать — но строго в оговорённых пределах. Молчание по поводу возмездности суды теперь трактуют как возмездность, поэтому не забывайте прописывать цену или прямо указывать безвозмездность. Частая проблема на практике: лицензионный договор свёрстан как оферта на сайте. Клиент думает, что получил право на всё, а по факту — только на использование в личных целях, без интеграции в свой продукт. Суд потом встаёт на сторону правообладателя.

Основные характеристики:

• Правообладатель сохраняет исключительные права.
• Лицензиат получает право использовать ПО только в пределах оговорённых способов (воспроизведение, запуск, модификация, если разрешено).
• Передавать право можно только с согласия правообладателя, если не указано иное.
• Возмездность должна быть прямо указана; молчание суды трактуют как возмездность.
• Отсутствие детализации объёма прав в договоре — самая частая причина споров в суде. Рекомендую максимально конкретизировать, например: «Лицензиат вправе инсталлировать ПО на 10 серверах, осуществлять переработку в целях интеграции с АРМ врача».

Типовые случаи применения:

• Продажа коробочного ПО (1С, Kaspersky).
• SaaS-подписки (доступ к облачному сервису).
• Использование ПО внутри компании без права распространения.

Преимущества:

• Простота оформления (часто — оферта на сайте).
• Низкая стоимость для клиента.
• Вендор сохраняет контроль над продуктом.

Риски:

• Клиент не может модифицировать код без согласия.
• При смене вендора (например, уход из РФ) лицензия может стать недействительной, если в договоре не предусмотрено условие о сохранении прав при переходе исключительного права к другому лицу.
• В суде трудно доказать объём переданных прав, если договор не детализирован.

Исключительная лицензия

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

Основные характеристики:

• Полная передача прав на использование (но не на создание новых версий, если не указано).
• Лицензиат может защищать права в суде как правообладатель.
• Часто сопровождается передачей дистрибутива, исходного кода, документации.
• Возмездность обязательна (безвозмездность должна быть прямо прописана).
• Важно прописать в договоре, имеет ли лицензиат право на модификацию и создание производных продуктов — иначе даже с исключительной лицензией он останется только пользователем, не разработчиком.

Типовые случаи применения:

• Покупка ПО для крупного предприятия с правом модификации.
• Интеграция ПО в собственный продукт (например, библиотека встраивается в медицинский софт).
• Передача прав на разработку уникального решения под заказ.

Преимущества:

• Клиент получает полный контроль над продуктом.
• Можно модифицировать, распространять, продавать.
• Защита от конкурентов (вендор не продаёт аналог другим).

Риски:

• Высокая стоимость (часто 3–10× дороже неисключительной).
• Вендор теряет контроль над продуктом.
• Сложность оформления (требуется письменный договор, подпись гендиректора).

Чек-лист: проверка лицензионного договора перед подписанием

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

• Наименование и версия программы указаны точно, без обобщений (например, «MedOS 3.2», а не «медицинская система»). Именно несовпадение версий в документе и в дистрибутиве потом становится основанием для признания договора незаключённым.
• Перечислены все разрешённые способы использования: воспроизведение, распространение, модификация, интеграция, запуск на серверах; не надейтесь на «разумный объём прав» — суд его не угадает.
• Прописаны территория действия и срок лицензии (например, «РФ, бессрочно» или «2024–2029»). Для продуктов, которые могут использоваться за рубежом или в облаке, обратите внимание на территориальные оговорки.
• Согласовано вознаграждение или прямо указана безвозмездность.
• Определён порядок передачи дистрибутива или доступа к программе (физический носитель, облачный доступ, API).
• Письменная форма обязательна для всех B2B-лицензий с вознаграждением. Электронный документооборот с УКЭП тоже подходит, но обычный скан без ЭП — риск.
• Договор подписывается уполномоченными лицами: для юридических лиц — генеральным директором или представителем по доверенности. Всегда проверяйте срок действия доверенности и полномочия — без этого подпись ничего не стоит.

Типовая ошибка: использование ПО без договора (например, скачивание из интернета). Суд трактует это как нарушение авторских прав, даже если код открыт. Любой код имеет автора, и отсутствие бумаги не освобождает от ответственности.

Открытые лицензии (Open Source): permissive vs copyleft

В российских медицинских проектах я постоянно вижу две крайности: либо полное игнорирование открытых лицензий (мол, open source — значит бесплатно и без обязательств), либо панический страх перед GPL, порождённый мифами. На самом деле, ст. 1286.1 ГК РФ легализовала открытые лицензии, но с важной оговоркой: условия должны быть явно выражены в оферте или в тексте лицензии, включённом в дистрибутив. Около 70 свободных лицензий признаны OSI, и все они делятся на две большие группы — разрешительные (permissive) и взаимные (copyleft).

Разрешительные лицензии (Permissive)

Типичные представители: BSD, MIT, Apache. Это самый комфортный для коммерческой разработки вариант. Вы обязаны включить в конечный продукт текст оригинальной лицензии и уведомление об авторских правах — и на этом ограничения заканчиваются. При внедрении телемедицинских платформ мы активно используем MIT-библиотеки, не раскрывая исходный код всей системы.

Что разрешено:

• Модифицировать код.
• Распространять как открытое, так и закрытое (коммерческое) ПО.
• Не обязывать распространять производный продукт под той же лицензией.

Типовые случаи:

• Использование библиотек в коммерческом продукте (React, Node.js).
• Встраивание кода в медицинский софт без раскрытия источника.
• Создание SaaS на базе open-source фреймворка.

Преимущества:

• Минимальные ограничения.
• Можно продавать продукт как закрытый.
• Низкий риск юридических претензий.

Риски:

• Если не включить лицензию и уведомление — формальное нарушение авторских прав, которое может всплыть при due diligence.
• При смене автора кода (особенно если он ушёл из РФ и прекратил поддержку) лицензия остаётся в силе, но могут возникнуть споры о территории действия.

Взаимные лицензии (Copyleft)

Яркий пример: GPL, LGPL, MPL. Они содержат «вирусное» условие: если вы создаёте производный продукт на основе кода под копилефт-лицензией (модифицируете его или используете как значительную часть своего проекта), вы обязаны распространять конечный продукт под той же самой копилефт-лицензией. Именно это условие регулярно вызывает споры при согласовании методик защиты информации — неправильно выбранная библиотека может закрыть дорогу к сертификации.

Что разрешено:

• Модифицировать код.
• Распространять только как открытое ПО.
• Использовать в коммерческих продуктах, но с раскрытием исходного кода.

Типовые случаи:

• Использование Linux в серверных решениях.
• Разработка медицинских систем на базе open-source платформ.
• Создание инструментов для телемедицины с расчётом на общественный аудит.

Преимущества:

• Защита от «закрытия» кода сторонними игроками.
• Сообщество развивается быстрее.
• Низкая стоимость входа.

Риски:

• Критическая ошибка: использование GPL-кода в закрытом коммерческом продукте без раскрытия источника. В суде это трактуется как нарушение авторских прав, продукт может быть заблокирован, а в случае с медицинским ПО — отозван из эксплуатации.
• Сложность интеграции: если ваш продукт использует GPL-модуль, весь продукт должен стать открытым, что часто несовместимо с требованиями регулятора по защите гостайны.

Таблица: сравнение permissive и copyleft

Важный нюанс для России: ст. 1286.1 ГК РФ признаёт открытые лицензии, но требует, чтобы они были прямо указаны в тексте договора или оферте. Если лицензия не прописана, суд может трактовать использование как нарушение авторских прав. При сопровождении проектов я рекомендую всегда прикладывать к дистрибутиву текстовый файл с полным текстом лицензии и копирайтами.

Государственная лицензия ФСБ на разработку СКЗИ: обязательный режим для криптографии

Для IT-компаний, внедряющих криптографические решения, государственная лицензия ФСБ — не опция, а обязательное условие. Без неё продукт не может быть сертифицирован как СКЗИ, не проходит проверку Роскомнадзора и не может использоваться в медицинских организациях, подпадающих под требования ФЗ-152 и Приказа ФСБ № 378. Мой опыт подготовки к лицензированию показал, что основная боль здесь не в сборе бумаг, а в правильной организации процессов внутри компании.

Что такое СКЗИ и когда нужна лицензия

СКЗИ (средство криптографической защиты информации) — программное, аппаратное или комбинированное средство, реализующее криптографические алгоритмы (шифрование, электронная подпись, хеширование) для защиты информации. На практике самый частый вопрос от медорганизаций звучит так: «Мы купили готовый программный комплекс с шифрованием, нам нужна лицензия ФСБ?». Если вы только используете сертифицированное СКЗИ без доработок и интеграции криптоалгоритмов в свою систему — лицензия не требуется. Но если вы дорабатываете модуль шифрования под свои нужды или интегрируете его в собственную разработку — вы становитесь разработчиком, и лицензия обязательна.

Лицензия ФСБ обязательна, если:

• Вы разрабатываете СКЗИ (создаёте новый модуль, алгоритм, устройство).
• Вы производите СКЗИ (изготавливаете на заводе).
• Вы продаёте СКЗИ (включая дистрибьюцию).
• Вы используете СКЗИ в медицинской организации для защиты персональных данных (ПДн) или врачебной тайны — но только в том случае, если дорабатываете его или встраиваете в свои процессы с модификацией.

Лицензия не нужна, если:

• Вы только используете уже сертифицированное СКЗИ (например, покупаете у лицензированного вендора).
• Вы разрабатываете ПО без криптографических модулей (например, интерфейс для телемедицины без шифрования).

Требования к лицензиату (по Приказу ФСБ № 378)

При первичной подготовке пакета документов я часто сталкивался с иллюзией, что достаточно двух «бумажных» сертификатов у инженеров. На самом деле инспекторы обращают внимание на профильное образование и реальный стаж работы с криптоалгоритмами. Если у специалиста сертификат есть, а подтверждённого опыта внедрения криптозащиты нет, это вскрывается на собеседовании, и лицензию не продлевают.

Минимальный набор:

• Наличие квалифицированных специалистов: минимум 2 инженера-криптографа с сертификатом ФСБ или аналогичным. Сертификат должен быть действующим и полученным в аккредитованном учебном центре.
• Техническая база: собственное оборудование для тестирования, лаборатория криптографии. Требования к лаборатории включают экранированную зону или камеру для измерения побочных электромагнитных излучений — инспектор обязательно проверит.
• Методики: разработанные и согласованные методики криптографической защиты. Их отсутствие — самая частая причина замечаний при первичном выезде.
• Регламенты: внутренние документы по безопасности, хранению ключей, аудиту. Должны быть не формальными, а отражать реальные процессы — инспектор может попросить продемонстрировать, как происходит смена ключевой информации.
• Отсутствие иностранных связей: для критических объектов (медицина, госсектор) проверяется наличие аффилированности с недружественными государствами. Если ваш инвестор или ключевой разработчик — гражданин страны из особого перечня, готовьте дополнительные обоснования.

Процесс получения лицензии

Подача через портал Госуслуг ускоряет формальный приём документов, но после этого всё равно приедет инспектор. Лучше заранее подготовить помещение и документы к выездной проверке больше, чем к камеральной.

1. Подача заявления в ФСБ (через портал «Госуслуги» или напрямую).
2. Предоставление документов: устав, регламенты, методики, сертификаты специалистов. Все документы должны быть подписаны усиленной квалифицированной подписью.
3. Проверка на месте: инспекторы ФСБ посещают лабораторию, проверяют оборудование и проводят собеседование с криптографами. Это самый волнительный этап, и к нему нужно готовить специалистов отдельно — они должны уметь обосновать каждую методику.
4. Выдача лицензии: ожидаемый срок — 30–60 дней, но при выявлении недочётов даётся 30 дней на исправление, и общий срок легко растягивается до полугода.
5. Продление: каждые 5 лет. За три месяца до окончания срока подавайте документы на продление — опоздание грозит остановкой всех контрактов.

Стоимость: от 50 тыс. руб. (заявление) + 100–300 тыс. руб. (проверка, включая командировочные инспектора) + 50–100 тыс. руб. (сертификация специалистов). В итоге реальная цена входа — 200–500 тыс. руб.

Типовая ошибка: попытка получить лицензию без квалифицированных специалистов или с фальсификацией сертификатов. ФСБ проверяет подлинность, и отказ последует неизбежно.

Сертификация СКЗИ: что нужно знать

После получения лицензии продукт должен пройти сертификацию в аккредитированном центре. Основные центры — система сертификации ФСТЭК и система сертификации СЗИ ФСБ. Для медицинских изделий с криптографией может дополнительно потребоваться заключение Росздравнадзора, если устройство формально относится к медицинским изделиям.

Процесс сертификации:

1. Тестирование: проверка криптографических алгоритмов, устойчивости к взлому. Проводятся как лабораторные, так и стендовые испытания на реальном оборудовании.
2. Аудит документации: регламентов, методик. Особое внимание — к описанию жизненного цикла ключевой информации.
3. Выдача сертификата: срок — 1–3 года.
4. Продление: каждые 2–3 года. Без продления сертификат аннулируется, и использование продукта становится незаконным в регулируемой сфере.

Стоимость: от 200 тыс. руб. до 1 млн руб. в зависимости от сложности продукта. Без сертификата СКЗИ не может использоваться в медицинских организациях, подпадающих под требования ФЗ-152.

Сравнительная таблица: три режима в одном продукте

Рассмотрим типовой кейс: IT-компания разрабатывает медицинскую систему с криптографическим модулем для защиты ПДн пациентов. Именно на таком проекте я когда-то впервые столкнулся с необходимостью вести все три трека одновременно. Таблица ниже показывает, что требуется для каждого режима и какие риски возникают при пробеле.

Ключевой вывод: для полноценного медицинского IT-продукта нужны все три режима одновременно. Без гражданской лицензии — нарушение авторских прав, без открытой — нарушение open-source, без государственной — запрет на использование в медицине.

Типовые ошибки при выборе лицензионного режима

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

Ошибка 1: использование GPL-кода в закрытом коммерческом продукте

Ситуация: компания встраивает GPL-модуль (например, OpenSSL) в свой закрытый медицинский софт без раскрытия исходного кода. Думают, что «никто не узнает». При проверке или сделке M&A вскрывается, и продукт оказывается под угрозой блокировки.

Риск: нарушение авторских прав, продукт может быть заблокирован в суде, а в случае медицинского ПО — отозван из эксплуатации с огромными репутационными потерями.

Как исправить:

• Перейти на permissive лицензию (например, заменить OpenSSL на BoringSSL с лицензией BSD) — технически это может быть несложно, но нужно проверить совместимость API.
• Раскрыть исходный код всего продукта, если это допустимо.
• Получить исключительную лицензию от правообладателя GPL-кода — редко реализуемо, но для некоторых крупных проектов возможно.

Ошибка 2: отсутствие договора с вендором ПО

Ситуация: компания скачивает ПО из интернета и использует без договора, полагая, что бесплатность означает свободу действий.

Риск: нарушение авторских прав, штраф до 5 млн руб. по ст. 14.53 КоАП. Суды в таких случаях практически безальтернативно встают на сторону правообладателя.

Как исправить:

• Подписать лицензионный договор (неисключительная лицензия) с точным указанием версии и наименования.
• Указать территорию и срок лицензии.
• Если ПО получено от иностранного вендора, проверить возможность легального использования на территории РФ без дополнительных разрешений.

Ошибка 3: попытка получить лицензию ФСБ без специалистов

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

Риск: отказ ФСБ, процесс начинается заново, а в худшем случае — включение в «чёрный список» заявителей, что усложнит повторную подачу.

Как исправить:

• Нанять минимум 2 инженеров с действующим сертификатом ФСБ из реестра, проверить подлинность документов.
• Если сертификатов нет — направить сотрудников на обучение в аккредитованный центр, но учесть, что это займёт от 2 до 6 месяцев.
• Подготовить внутренние регламенты и методики заранее, а не за неделю до приезда инспектора.

Ошибка 4: смешение понятий «лицензия ПО» и «лицензия ФСБ»

Ситуация: компания считает, что наличие лицензии на open-source код или гражданского договора с вендором заменяет лицензию ФСБ на СКЗИ.

Риск: продукт не проходит сертификацию, запрет на использование в медицине, срыв контракта.

Как исправить:

• Чётко разделить понятия: гражданская лицензия — для использования, государственная — для допуска к деятельности.
• Получить лицензию ФСБ для разработки СКЗИ, пройти сертификацию продукта.
• Включить проверку наличия всех трёх режимов в внутренний чек-лист запуска продукта.

Пошаговый алгоритм: как выбрать режим для вашего IT-продукта

Этот алгоритм я выстроил по итогам нескольких десятков проектных аудитов. Он помогает не упустить ни один режим.

Шаг 1: Определите тип продукта

• Если продукт — только интерфейс (без криптографии): нужна только гражданская лицензия на ПО. Но проверьте, вдруг интерфейс вызывает стороннюю криптобиблиотеку — тогда требования расширяются.
• Если продукт — open-source библиотека: нужна открытая лицензия (permissive или copyleft). Определитесь с моделью: хотите ли вы, чтобы другие могли закрывать код на основе вашей библиотеки.
• Если продукт — криптографический модуль: нужна государственная лицензия ФСБ + сертификация. Без вариантов.

Шаг 2: Проверьте наличие стороннего кода

• Если используете стороннее ПО: подписать гражданский договор (неисключительная лицензия). Убедитесь, что договор покрывает все способы использования, включая интеграцию в ваш продукт.
• Если используете open-source: включить текст лицензии и уведомление об авторских правах. Для copyleft — проверить совместимость лицензий всех компонентов.
• Если используете GPL-код: раскрыть исходный код всего продукта или перейти на permissive-аналог — это решение принимается на уровне архитектуры.

Шаг 3: Оцените необходимость лицензии ФСБ

• Если разрабатываете СКЗИ: получить лицензию ФСБ + сертифицировать специалистов. Запланируйте это на раннем этапе, так как сроки могут сдвинуть запуск.
• Если только используете СКЗИ: лицензия не нужна, но нужен договор с вендором. Убедитесь, что вендор имеет действующую лицензию и сертификат на продукт.
• Если продукт — медицинский софт с криптографией: нужна лицензия ФСБ + сертификация. Дополнительно учтите требования ФЗ-152 и Приказа ФСБ № 378.

Шаг 4: Подготовьте документы

• Гражданская лицензия: договор с точным наименованием версии, территорией, сроком, вознаграждением и перечнем способов использования. Подпишите уполномоченным лицом.
• Открытая лицензия: текст лицензии в составе дистрибутива, уведомление об авторских правах, ссылка на источник кода.
• Государственная лицензия: устав, регламенты, методики, сертификаты специалистов. Всё должно быть подписано УКЭП и готово к предъявлению в бумажном виде на месте.

Шаг 5: Пройдите сертификацию (если нужно)

• Для СКЗИ: тестирование в аккредитованной лаборатории, аудит документации, получение сертификата. Запланируйте запас времени на доработку замечаний тестовой лаборатории — почти всегда они есть.
• Для медицинского ПО: проверка Роскомнадзора на соответствие ФЗ-152, при необходимости — регистрация в Росздравнадзоре как медицинского изделия.

FAQ: частые вопросы по лицензированию IT-продуктов в России

В этом разделе я собрал вопросы, которые звучат на каждом втором консультационном созвоне. Ответы даны с учётом актуальной практики правоприменения.

1. Нужна ли лицензия ФСБ, если я только использую СКЗИ, а не разрабатываю?

Нет. Лицензия ФСБ нужна только для разработчиков, производителей и продавцов СКЗИ. Если вы купили сертифицированное СКЗИ у лицензированного вендора и используете его без модификации, лицензия не требуется. Но обязательно сохраните договор и сертификат вендора — их запросят при проверке Роскомнадзора.

2. Можно ли использовать GPL-код в коммерческом продукте без раскрытия источника?

Нет. Это прямое нарушение авторских прав. Если вы используете GPL-код, весь производный продукт должен распространяться под той же лицензией с открытым исходным кодом. Обойти можно только заменой на permissive-аналог или получением отдельного разрешения от правообладателя, что маловероятно.

3. Что делать, если вендор ПО ушёл из РФ?

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

4. Сколько стоит лицензия ФСБ на разработку СКЗИ?

Реальная цена входа — от 200 тыс. до 500 тыс. руб. Расклад: от 50 тыс. руб. за подачу заявления, 100–300 тыс. руб. на проверку (включая командировочные инспектора), 50–100 тыс. руб. на сертификацию двух специалистов. Сюда не входит подготовка лаборатории — бюджет на неё зависит от существующей инфраструктуры.

5. Можно ли получить лицензию ФСБ без квалифицированных специалистов?

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

6. Что такое «permissive» и «copyleft» в открытых лицензиях?

Permissive (MIT, Apache) — можно использовать код в закрытом продукте, только сохранив текст лицензии и уведомление. Copyleft (GPL, LGPL) — весь производный продукт должен стать открытым под той же лицензией. Выбор зависит от бизнес-модели: для коммерческого закрытого ПО — только permissive, для публичных проектов — допустим copyleft.

7. Нужна ли гражданская лицензия, если я использую open-source код?

Да. Открытая лицензия — это разновидность гражданской лицензии, но с особыми условиями. Вы обязаны включить текст лицензии и уведомление об авторских правах, иначе использование незаконно.

8. Как проверить, что продукт проходит сертификацию СКЗИ?

Запросить сертификат в аккредитированном центре (ФСТЭК или система сертификации СЗИ ФСБ) и проверить его в реестре. Обратите внимание на срок действия сертификата — просроченный сертификат делает использование продукта нелегитимным в регулируемой сфере.

Вывод: как не утонуть в бюрократии и выбрать правильный режим

Выбор лицензионного режима для IT-продукта в России — это не теоретическая задача, а практический вопрос безопасности бизнеса. Гражданская лицензия защищает от нарушения авторских прав, открытая лицензия — от нарушения open-source, государственная лицензия ФСБ — от запрета на использование в медицине и госсекторе.

Ключевые рекомендации, вынесенные из десятков проектов:

• Не смешивайте понятия: гражданская лицензия — для использования, государственная — для допуска к деятельности.
• Проверяйте сторонний код: включите текст лицензии и уведомление, особенно для GPL. Сделайте это частью процедуры сборки продукта.
• Получайте лицензию ФСБ на разработку СКЗИ, если планируете работать в медицине или с госсистемами, — без неё сертификация невозможна.
• Подписывайте договоры с вендорами ПО, даже если продукт open-source. Отсутствие бумаги — это всегда риск.
• Нанять квалифицированных специалистов для получения лицензии ФСБ — это не формальность, а требование, которое проверят при выездной проверке.

Типичная ошибка — попытка сэкономить на лицензиях. В итоге: штраф до 5 млн руб., блокировка продукта, запрет на использование в медицине, сорванный контракт и потерянная репутация.

Итог: для полноценного медицинского IT-продукта нужны все три режима одновременно. Без гражданской лицензии — нарушение авторских прав, без открытой — нарушение open-source, без государственной — запрет на использование в медицине. Только комплексный подход даёт легальную и устойчивую позицию на рынке. Если не уверены в выборе — обращайтесь к специалисту с реальным опытом внедрения и лицензирования; рынок не нуждается в ещё одном вендоре, но остро нуждается в внятном разборе регуляторной базы.