Создание программы для ЭВМ: как доказать факт разработки на конкретную дату — договор и фиксация прав
Один из самых нервных разговоров, который у меня случается регулярно, звучит так: «Эльвира, мы уже всё сделали, оно работает, но нам нужно доказать, что разработка была “тогда”, а не “вчера”, потому что партнёр внезапно вспомнил про права». И дальше начинается магия: кто-то тянет скрин из чата, кто-то показывает архив с проектом, а кто-то (прости господи) приносит ссылку на «программа для изменения даты создания файла» и говорит, что можно же “подкрутить дату”, и всё будет хорошо. Нет, не будет. Так вы только создадите себе второй фронт проблем.
Парадокс в том, что само создание программ ЭВМ обычно выглядит буднично: таски в трекере, коммиты, сборки, короткие созвоны, кофе, баги, ещё кофе. Но когда дело доходит до спора, будничность резко становится “доказательной базой”. И вот тут всплывает неприятное: дата создания программы сама по себе не живёт внутри папки с исходниками так, чтобы судья (или оппонент) поверил с первого взгляда. «Программа время дата создания» на вашем ноутбуке может показывать хоть 2012 год, но это ровно то место, куда лезут всякие «изменить дату создания файла программа» и похожие игрушки.
Зачем вам вообще эта “конкретная дата”
Чтобы спорить о правах на софт, мало сказать «мы делали раньше». Обычно нужно показать, что разработка действительно велась, что объект определён (а не “какая-то система”), и что права перешли или закреплены. После этого разговора вы сможете собрать связку документов и цифровых следов так, чтобы дата создания программы выглядела не как желание задним числом, а как нормальная история проекта: кто заказал, кто сделал, когда сделал, на каких условиях, кому принадлежат права и что именно передали.
Пошаговый гайд: как фиксировать разработку и права без шаманства
Шаг 1. Назвать программу вслух и описать её границы
Первое, что мы делаем на практике, это перестаём говорить «приложуха» и «наш сервис». Выберите рабочее название и краткое описание: что это за программа, какие модули, какая платформа, что входит и что не входит. Зачем? Потому что спорят почти всегда не про красивое слово “софт”, а про конкретику: «этот модуль ваш или наш», «админка входила?», «интеграция с платёжкой это отдельная работа?». Типичная ошибка тут простая: зафиксировали “разработку сайта”, а по факту сделали бэкенд, личный кабинет и мобильное приложение. Проверка, что всё работает: откройте документ и попробуйте по нему объяснить третьему человеку, что именно создаётся. Если он задаёт десять уточнений, значит границы размыты.
Мини-кейс: у клиента был небольшой маркетплейс для локальных производителей. Два разработчика, сроки горели, делали в три итерации. Название проекта менялось три раза, а “программа” в переписке называлась то “витрина”, то “CRM”, то “бот”. Когда бывший подрядчик заявил, что “основная система” его, оказалось, что даже внутри команды нет единого описания. Мы сели и восстановили структуру: что за репозиторий, что за сборки, что отдавалось в релизах, что было в ТЗ. Это заняло неделю, но иначе спор превращался бы в болото.
Шаг 2. Заключить договор: лучше скучный, чем героический
Если разработчик внешний, вам нужен договор на создание программы для ЭВМ. На языке ГК РФ обычно это договор авторского заказа или смешанная конструкция, но смысл человеческий: стороны, сроки, стоимость, что передаётся и на каких условиях. Важно прописать способы использования, срок и территорию передачи прав, вознаграждение, и иные существенные условия. Это не бюрократия ради галочки: без этого вы будете спорить о том, что вообще подразумевали, когда договорились “сделать MVP за 300 тысяч”. Типичная ошибка: договор есть, но про исключительное право и передачу прав сказано туманно, либо права вообще “где-то в приложении”, которого никто не видел. Проверка: в договоре должно быть понятное место, где написано, кому принадлежат исключительные права, когда и при каком событии они переходят, и что считается результатом.
Да, я знаю, что часто используют договора заказа на создание программы эвм в формате «два листа, подписи, поехали». Иногда это спасает, иногда нет. Если вы платите за разработку и рассчитываете владеть результатом, не стесняйтесь требовать ясности. И ещё момент: если часть делается силами вашего сотрудника, а часть подрядчиком, не смешивайте это в одной переписке без фиксации. В споре потом сложно объяснить, почему кусок кода “вдруг” стал служебным.
Шаг 3. Техническое задание и служебное поручение: то, что все ленятся делать
ТЗ можно ненавидеть, но оно очень помогает. Для подрядчика это приложение к договору, для сотрудника это служебное задание. Зачем: чтобы показать, что создание программы входило в поручение и было ожидаемым результатом, а не “он по вечерам для себя писал, а вы потом присвоили”. Типичная ошибка: поручение даётся голосом в переговорке или в мессенджере и дальше исчезает в истории чатов. Проверка: у вас должно быть хотя бы одно место, где в письменной форме отражены требования, сроки и принимающий. И да, должностные инструкции тоже имеют смысл, если речь о служебном произведении: когда обязанности сотрудника сформулированы как “разное”, доказывать потом неприятно.
Мини-кейс: у одной компании был сильный разработчик, который официально числился “системным администратором”, а по факту писал внутренние скрипты и небольшой сервис для автоматизации закупок. Когда он ушёл, всплыл вопрос: кому принадлежит программа и какая дата создания программы вообще считается отправной. Помогло то, что руководитель проекта хотя бы письменно утверждал задания и акты приёмки по этапам. Без этих бумажек можно было бы очень долго спорить, что было “по работе”, а что “для души”.
Шаг 4. Приёмка результата и фиксация версий: не верьте одному архиву
Когда говорят «у нас есть папка с датой», я обычно вздыхаю. Метаданные файла редактируются, иногда случайно, иногда с помощью “удобных утилит”. Существуют и совсем прямолинейные вещи вроде «программа для изменения даты создания» или «программа для изменения даты создания фото», но даже без злого умысла дата на устройстве легко съезжает после переустановки, синхронизации, переноса на другой диск. Поэтому вместо упора в один “файл с датой” лучше иметь историю версий: репозиторий, теги релизов, выгрузки сборок, акты приёмки этапов, письма о сдаче, ссылки на таски. Зачем: так вы показываете процесс разработки, а не один финальный артефакт. Типичная ошибка: приняли работу “в переписке ок”, деньги перевели, а результат не идентифицировали. Проверка: возьмите любую версию, которую считаете “готовой на дату”, и убедитесь, что вы можете её воспроизвести и сопоставить с документом приёмки.
Ещё тонкость: если вы опасаетесь, что кто-то попытается “доказать” прошлое через утилиты из серии «программа для изменения даты создания файла» или «изменить дату создания файла программа», не играйте в это поле. В споре часто выигрывает тот, у кого спокойная цепочка документов и событий. А человек, который приносит следы вмешательства в метаданные, выглядит, мягко говоря, странно.
Шаг 5. Регистрация программы для ЭВМ в Роспатенте как якорь по дате
Когда нужно “прибить” дату к стене, я часто советую регистрацию программы для ЭВМ в Роспатенте. Важно понимать нюанс: Роспатент фиксирует факт обращения с заявкой и вносит запись в реестр по представленным сведениям и материалам, идентифицирующим программу. При этом принадлежность исключительных прав по существу не проверяется, это не экспертиза “кто настоящий владелец”. Зачем тогда это делать? Потому что свидетельство о госрегистрации удобно как официальный ориентир: на какую дату вы заявили объект, как он идентифицирован, кто указан автором и правообладателем. Типичная ошибка: думать, что свидетельство автоматически “закрывает” любой спор о правах. Нет, спор может быть, но вам будет проще собирать картину. Проверка: убедитесь, что поданные материалы действительно идентифицируют программу, а сведения об авторах и правообладателе не “примерные”.
Мини-кейс: ИП заказал разработку кассовой интеграции и личного кабинета для сети пунктов выдачи. Подрядчик сдал, потом начал тянуть с передачей исходников, а через пару месяцев стал намекать, что “ядро” его и будет лицензия. У ИП был договор авторского заказа, этапная приёмка и регистрация программы в Роспатенте после первого стабильного релиза. Спор всё равно был нервным, но точка опоры по дате и идентификации помогла говорить не эмоциями, а фактами.
Шаг 6. Нотариус и электронные доказательства: когда пахнет конфликтом
Если чувствуете, что история идёт к спору, полезно подумать о нотариальном заверении ключевых материалов или фиксации электронных доказательств: например, снимки экрана, переписка, контрольные суммы, файлы релиза на носителе. Зачем: чтобы не спорить потом о том, “а это вы вчера дорисовали”. Типичная ошибка: бежать к нотариусу с набором хаотичных файлов без связки с договором и версиями. Нотариус не будет разбираться в вашей архитектуре, ему нужно что-то обозримое и логичное. Проверка: вы сами должны понимать, что именно вы фиксируете и почему это привязано к конкретной версии и конкретной дате.
И ещё, на всякий случай: если у кого-то в команде возник соблазн сделать “поправку дат” через утилиты, которые обещают “программа время дата создания” отредактировать красиво, остановите человека. Такие следы иногда всплывают неожиданно, и потом объяснять их дороже. Отдельно скажу странное: запросы вроде «рсдрп лидеры дата создания программа» я видела в аналитике, и каждый раз думаю, что интернет держится на случайностях. Но в юридическом споре случайности лучше не приносить.
Шаг 7. Финальная стыковка: права, люди и доступы
Когда программа готова, важно довести до конца не только код, но и права: подписать акты, получить исходники и доступы, зафиксировать, кто авторы, а кто правообладатель. Если разработка шла в компании, соберите подтверждения служебного характера: поручения, переписку о задачах, должностные инструкции, документы о приёмке. Если подрядчик, проверьте, что договор и акты не противоречат друг другу. Типичная ошибка: забывают закрыть вопрос доступов к репозиторию и сервисам, а потом выясняется, что “история коммитов” живёт на аккаунте бывшего подрядчика. Проверка простая и неприятная: попробуйте развернуть проект без участия ключевого разработчика. Если не получается, значит вы приняли продукт, но не приняли контроль.
Подводные камни, где чаще всего всё ломается
Первый разлом всегда там, где люди путают “мы заплатили” и “права перешли”. Платёж сам по себе не равен передаче исключительных прав, а формулировки в договоре иногда такие, что хочется позвать переводчика с русского на русский. Я видела ситуации, где стороны год работали нормально, а потом один пункт про “неисключительную лицензию” внезапно превращал заказчика в арендатора собственного же продукта. И да, это случается не у больших корпораций, а у маленьких команд, которым “некогда”.
Второй разлом, более бытовой: попытка доказывать дату через свойства файлов. Дата создания программы на компьютере, дата “создано” у архива, даже дата на скриншоте не являются тем фундаментом, на который стоит ставить спор. Слишком много способов, как это меняется. И тут опасно не только “создание вредоносных программ для эвм” (да, бывают и такие истории, когда кто-то ломает инфраструктуру), а просто обычные утилиты и настройки системы. В итоге оппонент приносит эксперта, который говорит: метаданные редактируемы. И всё, вы стоите с красивой папкой, но без веса.
Третий разлом тоньше: авторы и вклад. У софта редко бывает один человек, который “всё написал”. Есть фронт, бэк, дизайн, DevOps, иногда ещё фрилансер “на пару вечеров”. Когда вы подаёте на регистрацию или формируете документы, важно не перепутать автора (физическое лицо) и правообладателя (часто компания), и не “забыть” кого-то, кто объективно создавал код. Это не про мораль, это про будущие риски. Если кто-то обижен и у него остались артефакты участия, конфликт может прийти очень некстати.
Кому реально пригодится помощь с фиксацией прав
Если вы стартап и у вас релизы каждую неделю, проще один раз настроить процесс, чем потом раскапывать историю по чатам. Если вы бизнес с подрядчиками, особенно когда один уходит и приходит другой, документы и фиксация по версиям экономят месяцы споров. И если вы работодатель с сильными разработчиками, которые делают “внутренний софт”, лучше заранее оформить служебные задания и понятную приёмку, чем потом выяснять, что у вас ключевой сервис “висит” на личном Git-аккаунте.
Я люблю формат, когда юрист не мешает разработке, а просто тихо ставит опоры: нормальный договор авторского заказа, вменяемые приложения, аккуратная регистрация в Роспатенте там, где это уместно, и понятная карта, где что лежит. Если вам важно быть в курсе новостей и разборов по интеллектуалке, подпишитесь на наш Telegram-канал и на Телеграмм канал Патентного бюро Лирейт». По смежным темам иногда полезно посмотреть: Юридическая защита интеллектуальной собственности, Регистрация товарного знака и Монополия на бренд, потому что в реальной жизни софт почти всегда живёт рядом с брендом и договорной работой.
FAQ
Вопрос: Что считается доказательством, что дата создания программы была именно такой?
Ответ: Лучше всего работает связка: договор и ТЗ, этапная приёмка, история версий (репозиторий, релизы), плюс официальная фиксация вроде регистрации программы для ЭВМ в Роспатенте. Одна “дата” в свойствах файла почти никогда не тянет на самостоятельное доказательство.
Вопрос: Регистрация в Роспатенте доказывает, что права точно мои?
Ответ: Она подтверждает факт обращения и запись в реестре по представленным сведениям, и даёт свидетельство. Но Роспатент не проверяет принадлежность исключительных прав по существу, поэтому договоры и документы о создании всё равно важны.
Вопрос: Можно ли “поправить” метаданные, чтобы вышла нужная дата?
Ответ: Технически существуют вещи вроде «программа для изменения даты создания» или «программа для изменения даты создания файла». Юридически это плохая идея: метаданные редактируемы, и попытки их “улучшить” могут выглядеть как фальсификация. Надёжнее строить доказательства на документах и истории разработки.
Вопрос: Если разработчик сотрудник, нужно ли что-то кроме трудового договора?
Ответ: Желательно иметь должностную инструкцию с релевантными обязанностями и письменные служебные задания на конкретные разработки, плюс документы приёмки результата. Без поручения шансы доказать служебный характер могут стать заметно хуже.
Вопрос: Как оформить отношения с фрилансером, чтобы не потерять права?
Ответ: Заключайте договор на создание программы для ЭВМ (часто это договор авторского заказа) с понятными условиями о передаче исключительных прав, территории, сроках и вознаграждении. И обязательно принимайте работу актами или иными документами, где идентифицируется результат.
Вопрос: Что делать, если часть кода уже написана, а договора не было?
Ответ: Приводить в порядок “задним числом” рискованно, но можно собрать переписку, выгрузки версий, подтверждения оплат, оформить соглашение о передаче прав на уже созданные материалы и зафиксировать текущую версию через нотариуса или регистрацию в Роспатенте. Главное не пытаться заменить историю проекта одной “правильной” датой файла.
Вопрос: Это как-то связано с темой “создание вредоносных программ для эвм”?
Ответ: В большинстве нормальных проектов нет, но в спорах иногда всплывают подозрения в вмешательстве в инфраструктуру или подмене артефактов. Поэтому я и упираю на прозрачную фиксацию версий и документов, чтобы не приходилось доказывать, что вы не верблюд (и что у вас никто не игрался с датами и файлами).