Адаптация ПО: правовой режим и вопросы по адаптации программы для ЭВМ
У меня есть знакомый админ, который однажды “просто перенёс” бухгалтерскую программу на новый сервер. Ничего героического: вечер пятницы, чай остывает, в офисе тихо, в голове список задач. К утру выяснилось, что тихо было зря: программа запускалась, но печать форм падала, интеграция с банком отвалилась, а часть модулей начала ругаться на лицензии. Руководитель сказал сакральное: “Ну вы же просто адаптировали, это же не разработка”. И вот тут начинается самая интересная часть, потому что “просто адаптация ПО” в реальности почти всегда упирается в правовой режим и в то, как вы зафиксируете работа по адаптации на бумаге.
Снаружи это выглядит бытово: подтянуть драйвер, переписать пару конфигов, сменить кодировку, перевести интерфейс, настроить обмен с CRM, подружить с новым ОС. А изнутри это уже вопросы по адаптации: где заканчивается законная настройка под конкретные “железки” пользователя, и где начинается модификация ПО, на которую нужны отдельные права. Ирония в том, что технически разница может быть в паре строк, а юридически это две разные планеты. Я сначала подумала, нет, лучше вот так: в споре всегда выигрывает тот, у кого аккуратнее документы и понятнее цель изменений.
После прочтения вы сможете разложить тему по адаптации по шагам: как описать программу по адаптации, какие мероприятия по адаптации разумно заложить в договор и ТЗ, как не перепутать адаптация модификация ПО, что делать с “права на модификацию ПО”, и как проверять результат так, чтобы это выглядело убедительно для бухгалтерии, юристов и, если совсем не повезёт, для суда. Параллельно зацепим неочевидное: почему иногда в переписке всплывает “адаптация по 1 классу” или “адаптация по 5 классам”, и при чём тут вовсе не школа, а классификация и привычка людей тащить термины из разных сфер в одну кучу.
Пошаговый гайд: как сделать адаптацию ПО и не устроить себе юридический квест
Шаг 1. Отделите “адаптацию” от “модификации” словами, а не ощущениями
Первое, что делаем: фиксируем цель изменений. В российской логике адаптация программного обеспечения обычно понимается как изменения, нужные, чтобы программа работала на конкретных технических средствах пользователя или под управлением его программ. То есть это про “запустить и корректно функционировать здесь”, а не про “добавить новые возможности вообще”. Зачем это нужно: законный пользователь в ряде случаев может сделать адаптацию без согласия правообладателя, если смысл изменений именно в обеспечении функционирования на его стороне. Типичная ошибка: называть адаптацией всё подряд, включая новый функционал, новый интерфейс и переработку модулей, а потом удивляться, почему правообладатель говорит “это модификация ПО”. Проверка простая: если убрать вашу правку, программа перестанет работать в вашей среде или просто станет “менее удобной”? Первое больше похоже на адаптацию, второе часто уезжает в модификацию по другому, то есть в изменение существа продукта.
Мини-кейс: в одной розничной сети (12 магазинов, сроки горели) айтишник Саша “адаптировал” кассовый софт под новый фискальный регистратор. Он не трогал бизнес-логику, только драйвер и обмен. Это похоже на законную адаптацию, потому что цель была обеспечить работу на конкретном оборудовании пользователя. А вот когда через неделю попросили “заодно добавить новый тип скидки” и он полез менять расчёт, начались работы по модификации ПО, и тут уже без прав на модификацию ПО опасно, даже если кажется, что “ну это же мелочь”.
Шаг 2. Опишите объём: что именно меняем и почему это “мероприятия по адаптации”
Второй шаг: делаем письменное описание изменений в формате, который любят и технари, и юристы. Не список ради списка, а связка “проблема в среде пользователя” → “изменение” → “ожидаемое поведение”. Это и есть нормальные мероприятия по адаптации: перенос на другую ОС, настройка под виртуализацию, смена СУБД, правка путей, локализация, интеграция “на уровне обмена” без вмешательства в алгоритмы. Зачем: чтобы потом не спорить, была ли это адаптация ПО (79116) или уже “программист по привычке улучшил продукт”. Типичная ошибка: ТЗ вида “адаптировать под наши нужды”, без расшифровки, а потом оказывается, что “наши нужды” включали полпереписывания. Проверка: у каждого изменения должен быть якорь в инфраструктуре пользователя: конкретный сервер, конкретная версия ОС, конкретное окружение, конкретная политика безопасности.
Иногда в переписке всплывает “адаптация по 1 классу” или “адаптация по 5 классам”. Обычно это не про ГК РФ, а про внутреннюю градацию сложности у подрядчика или про попытку классифицировать объём работ. Если вы видите такие формулировки, просите нормальный перевод на человеческий: что входит, что не входит, и чем “класс” измеряется. И да, встречаются и более экзотические гибриды, вроде “классификация территорий по правовому режиму” в ТЗ на софт: люди копируют шаблоны договоров, где рядом жили “территории по правовому режиму” и IT-раздел. Смешно до тех пор, пока вы не подписали документ, где половина терминов вообще не из вашей темы.
Шаг 3. Проверьте права: кто законный пользователь и что разрешено договором
Третий шаг всегда скучный, но спасает нервы: поднимаем лицензионный договор, договор отчуждения или условия поставки и смотрим, кто вы для программы. Законный пользователь это тот, кто получил право использовать программу на законном основании, и это основание лучше держать под рукой. Зачем: право на адаптацию без согласия правообладателя завязано на статус пользователя и на цель “обеспечить функционирование” в своей среде. Типичная ошибка: адаптацию делает подрядчик, а заказчик не может подтвердить свои права на исходную программу, либо лицензия запрещает любые изменения, включая настройку. Проверка: у вас есть документы на использование, а в договоре/лицензии нет прямого запрета на подобные действия или, если запрет есть, у вас получено согласие правообладателя в явном виде.
Отдельный нервный угол: если у вас параллельно идут процессы модификации ПО (762) и адаптация в одном проекте, границу надо обозначить заранее. Иначе вы подпишете акт “работа по адаптации (7183)”, а фактически примете новый функционал, и потом спор упрётся в права на модификацию ПО (2603). В жизни это выглядит так: “мы чуть-чуть переписали модуль импорта, чтобы он принимал новый формат”. Чуть-чуть это не юридическая категория, увы.
Шаг 4. Оформите результат: акты, исходники, доступы и “что именно передали”
Четвёртый шаг: превращаем код и настройки в понятный результат. Если это адаптация, обычно важны: новая сборка, файлы конфигурации, инструкции по развёртыванию, описание окружения, иногда патч. Если это модификация ПО (24363), добавляются вопросы: кому принадлежат исключительные права на изменения, можно ли их дальше использовать, кто хранит репозиторий. Зачем: чтобы не получилось, что подрядчик “настроил”, но ничего не передал, и вы зависите от его ноутбука. Типичная ошибка: принимать работу актом “всё ок”, без фиксации версии, контрольной суммы, перечня файлов и доступов. Проверка: вы можете развернуть результат на чистом стенде по инструкции и получить идентичное поведение, а не “у нас на машине работало”.
Здесь же всплывает тема “модификации передаются по наследству” и “модификации по наследству”. Люди обычно имеют в виду не наследование прав в быту, а юридический факт: исключительные права могут переходить по наследству в общем порядке. Но это не отменяет того, что права на конкретные изменения должны быть оформлены. Если компания сегодня “допилила” продукт без документов, завтра сменится директор, послезавтра наследники будут разбираться, что вообще принадлежит фирме. Чёрный юмор в том, что код живёт дольше многих договорённостей на словах.
Шаг 5. Протестируйте так, чтобы это было доказательством, а не “ощущением”
Пятый шаг: делаем тест по адаптации (4251), но не в стиле “потыкали кнопки и разошлись”. Зачем: адаптация часто ломается на мелочах, которые видны только в боевом окружении: права доступа, локали, кодировки, сетевые политики, криптопровайдеры. Типичная ошибка: тестировать на ноутбуке разработчика, а не на окружении заказчика. Проверка: есть протокол, где отражены входные данные, ожидаемый результат и фактический результат, плюс сведения о среде. Если используете автоматизацию, фиксируйте логи и версии интеграций.
Мини-кейс: юрист Ирина из небольшой продуктовой компании настояла, чтобы в акте приёмки к “адаптация ПО” приложили протокол тестов: запуск под Windows Server нужной версии, подключение к конкретной СУБД, печать на определённом принтере, обмен с 1С через регламентный файл. Времени это заняло два вечера, зато когда через месяц обновили ОС и всё посыпалось, они быстро доказали, что проблема не в “некачественной адаптации”, а в изменившейся среде. Сэкономили кучу переписки и, честно, нервов.
Шаг 6. Если задач много, автоматизируйте рутину через no-code, но не путайте это с “переписали программу”
Шестой шаг для тех, у кого адаптация это не разовый подвиг, а поток: используйте платформы автоматизации. Например, Make.com (бывший Integromat) позволяет собирать многошаговые сценарии без кода и связывать разные сервисы через визуальный интерфейс, у платформы тысячи интеграций, и это реально помогает разгрузить команду. Зачем: часть мероприятий по адаптации можно вынести в внешний сценарий, не трогая саму программу для ЭВМ, особенно когда речь про перенос данных, синхронизацию между CRM, почтой, таблицами и таск-трекерами. Типичная ошибка: считать, что раз “мы сделали сценарий”, то это автоматически часть исходного ПО и его модификация. Проверка: вы чётко понимаете, что вы меняли: внешний процесс вокруг программы или код программы. Если это внешний сценарий, обычно проще и с правами, и с сопровождением.
Мини-кейс: отдел продаж на Битрикс24, склад в отдельной системе, бухгалтерия в 1С. Раньше менеджер Миша вручную переносил статусы и номера накладных, терялся, злился, а потом ещё и ругали за ошибки. За неделю настроили программу по адаптации (4469) в смысле бизнес-процесса: Make.com стал мостиком, который подтягивал данные и раскладывал по полям, а в саму учетную программу почти не лезли. По правам это спокойнее: меньше риск, что “работы по модификации ПО” сделаны без оснований, и проще документировать, что именно меняли.
Шаг 7. Разведите по документам “адаптация” и “по 2 модификации” заранее
Седьмой шаг: если проект комплексный, в договоре и актах держите две корзины: адаптация и модификации. Иногда это реально два параллельных трека: сначала адаптация под сервер и ОС, потом “по 2 модификации (5095)” вроде нового отчёта и нового алгоритма расчёта. Зачем: чтобы оплата, сроки, ответственность и права не смешались в кашу. Типичная ошибка: подписать один общий акт, где внутри и настройка окружения, и новый функционал, и ещё “перевод интерфейса” в придачу, а потом спорить, что из этого было разрешено без согласия правообладателя. Проверка: в документах видны границы, а для модификации отдельно прописано, кому принадлежат результаты и какие права предоставляются.
Да, иногда заказчик хочет, чтобы “модификации разработки ПО (487)” можно было использовать в других проектах, а подрядчик хочет оставить себе заготовки. Это нормально, просто проговорите и закрепите. И не бойтесь формулировки “модификация по другому (472)” в смысле “иная переработка”, бойтесь отсутствия формулировок вообще.
Подводные камни: где чаще всего ломается адаптация и почему юристы потом плачут
Самое частое место поломки это расплывчатая цель. Когда в переписке “нужно, чтобы работало” без уточнения среды, адаптация превращается в бесконечный ремонт: сегодня одно окружение, завтра другое, послезавтра выясняется, что у заказчика ещё и политика ИБ, и всё должно жить в закрытом контуре. На этом фоне всплывают странные термины, которые вообще не про софт: “территории по правовому режиму (884)”, “правовой режим земель по земельному (279)”, “правовой режим земель по категориям (211)”, “правовой режим земель по целевому назначению (140)”. Я видела договор, куда это попало из шаблона, и никто не заметил, пока не начали спорить о подсудности и “территории”. Смешно? Немного. Полезно? Нет.
Вторая ловушка это смешивание прав. Адаптация ПО может быть допустима для законного пользователя в пределах обеспечения функционирования на его технических средствах, но стоит вам выйти за рамки и вы уже в зоне, где нужны права на модификацию ПО. И тут особенно неприятно, когда работу делает внешний подрядчик: он не “пользователь”, а исполнитель, и без правильно оформленных полномочий можно получить конфликт. Плюс не забывайте про производные элементы: шрифты, библиотеки, SDK, криптопровайдеры, плагины. Формально вы “адаптировали”, а фактически подключили компонент с лицензией, которая запрещает коммерческое использование без оплаты.
Третья боль это доказательства. Когда всё держится на чатике и созвонах, потом очень сложно показать, что именно было сделано: адаптация или модификация, какие работы по модификации ПО (1484) выполнены, какие процессы модификации ПО (762) согласованы, что вы приняли и почему. Нормальная фиксация версий, протоколов и актов кажется бюрократией ровно до первого конфликта. Потом это становится единственной ниточкой, за которую можно вытянуть историю проекта из болота “мы так договаривались устно”.
Мягко про пользу оформления прав: кому это реально экономит время
Если у вас продуктовая команда, вы делаете кастомизации клиентам или регулярно пилите обновления, оформление прав и аккуратная документация по изменениям это не роскошь, а способ жить без пожаров. Особенно когда в проекте есть и адаптация, и модификация, и ещё интеграции через внешние платформы. Хорошо работают форматы, где вам помогают собрать цепочку: кто правообладатель, кто исполнитель, что именно создано, какие права переданы, и как это закрепить в договоре, чтобы потом не выяснять “а кому принадлежит патч”. По товарным знакам логика похожая: иногда проще заранее закрепить бренд, чем потом бегать и доказывать, что “мы первые придумали”. Если вам это близко, посмотрите Юридическая защита интеллектуальной собственности и Регистрация товарного знака, а если вы строите бренд всерьёз и надолго, пригодится и история про Монополия на бренд.
И да, чтобы не пропускать новости и разборы кейсов без занудства, держите ссылку: Хотите защитить свою интеллектуальную собственность, быть в курсе всех новостей? Подпишитесь на наш Telegram-канал. Там же продублирую по-человечески, потому что меня просят: Телеграмм канал Патентного бюро Лирейт”. Иногда один пост в нужный день экономит больше времени, чем неделя чтения форумов.
FAQ
Вопрос: Чем адаптация программы для ЭВМ отличается от модификации ПО по смыслу?
Ответ: Адаптация обычно про изменения, необходимые, чтобы программа работала на конкретных технических средствах пользователя или под управлением его программ, то есть про “запуск и корректную работу в вашей среде”. Модификация ПО чаще про переработку, развитие функционала, изменение алгоритмов и интерфейсов “по сути”, и для неё обычно важнее отдельно урегулировать права на результат.
Вопрос: Можно ли сделать адаптацию ПО без согласия правообладателя?
Ответ: В ряде случаев законный пользователь может выполнить адаптацию, если она направлена исключительно на обеспечение функционирования программы на его технических средствах. Но важно не выйти за пределы этой цели и учитывать условия лицензии или договора, иначе это может стать уже модификацией.
Вопрос: Что обязательно зафиксировать в документах по “работа по адаптации”?
Ответ: Полезно закрепить цель и границы изменений, среду пользователя, версии, состав передаваемых файлов и инструкций, а также критерии приёмки. Если параллельно есть работы по модификации ПО, лучше разделить их в ТЗ и актах, чтобы не спорить о правах на модификацию ПО.
Вопрос: Зачем нужен тест по адаптации, если “и так запускается”?
Ответ: Потому что “запускается” не равно “работает устойчиво в нужной среде”. Тест по адаптации фиксирует, на каком окружении и с какими входными данными вы проверили ключевые сценарии, и помогает отличить дефект адаптации от изменений инфраструктуры или обновлений со стороны заказчика.
Вопрос: Make.com и похожие no-code инструменты это адаптация или модификация?
Ответ: Чаще это автоматизация процессов вокруг программы: интеграции, перенос данных, синхронизация. Обычно вы не меняете код программы для ЭВМ, а строите внешний сценарий. Но границы лучше описать письменно, чтобы не было впечатления, что вы “переписали продукт” без прав.
Вопрос: Что означает “адаптация по 5 классам” или “адаптация по 1 классу” в договорах?
Ответ: Обычно это внутренняя градация сложности у исполнителя или попытка классифицировать объём работ, а не термин из ГК РФ. Просите расшифровку: какие мероприятия по адаптации входят в “класс”, какие сроки, какие результаты и как проверяется готовность.
Вопрос: Могут ли модификации передаются по наследству?
Ответ: Исключительные права в целом могут переходить по наследству, но это не магия: нужно понимать, кому принадлежат права на конкретные изменения и есть ли документы, подтверждающие переход. Если результат модификации нигде не оформлен, потом сложно доказать, что именно наследуется и кем создано.