Привет, Хабр. Меня зовут Владимир Разуваев, я руководитель департамента бизнес-консалтинга. Наша команда занимается тем, что помогает клиентам понимать значимость программных активов и управлять ими. В этом посте я предлагаю поговорить о внутренних разработках, которые в той или иной мере есть практически в любой компании.
Текст разделен на три части. В первой я расскажу о пяти важных шагах по формализации таких разработок. Эта формализация поможет не только закрепить за компанией права на эти разработки, но и сократить юридические риски, связанные с «перехватом» прав на ПО бывшими сотрудниками, а также экономические риски неправильного учёта ПО как актива. Из второй части станет понятно, какими правами на программный продукт, созданный для компании, обладают непосредственно программисты. И в третьей части я поясню, почему так важно правильно оформлять документы и с какими рисками может столкнуться компания-разработчик.
Опыт последних трёх лет показывает, как изменилось отношение компаний ко внутренним разработкам. Даже простой, созданный «на коленке» софт, воспринимается как некая сущность, имеющая свою ценность. В некоторых компаниях ценность внутренних разработок увеличилась еще и под влиянием политики импортозамещения: для них написанное собственной командой программистов ПО – альтернатива зарубежным продуктам, часто уже достаточно близкая к ним по функциональности. Как бы то ни было, организации стремятся формализовать внутренние разработки – мы видим это по количеству соответствующих обращений в наш департамент.
Под формализацией мы имеем в виду прежде всего надлежащее документальное оформление созданного результата интеллектуальной деятельности. Нужно чётко понимать, что в соответствии с действующим законодательством авторское право на программу для ЭВМ возникает с момента ее создания в силу самого факта её создания. Справедливо, что если сотрудник, работающий в организации по трудовому договору, занимается разработкой программного продукта для компании, то данный программный продукт должен принадлежать компании, поскольку это относится к его обязанностям, и именно за это он получает заработную плату и иные виды компенсации (премии и другие выплаты компенсационного характера). Однако крайне важно понимать, что в авторском праве разграничены две вещи — авторское право (нематериальное) и т.н. исключительное право (материальное право, право распоряжаться объектом авторского права). И если авторское право возникает в силу создания и принадлежит физическим лицам, создавшим продукт, то «материальное» право подлежит тонкой документальной настройке. Механизм по защите внутренних разработок включается в пять шагов.
Шаг первый. В рамках трудового договора формализуйте функции сотрудников и подчеркните, что в обязанности сотрудника входит разработка служебных произведений, программ для ЭВМ, баз данных и т.д. Также проверьте тот трудовой договор, который уже подписан сторонами – это может быть типовой документ, в котором пункты о разработке служебных произведений могут быть не указаны. В этом случае заключите с разработчиком дополнительное соглашение, в котором следует сделать акцент на функциональных задачах специалиста, а также прописать принадлежность возникающих исключительных прав компании нанимателю. Также в договоре обязательно должен быть указан порядок уплаты авторского вознаграждения за созданные программы ЭВМ. Авторское вознаграждение может быть включено в заработную плату, премирование, либо иные виды материального поощрения.
Шаг второй. Всегда составляйте служебное задание на разработку программы для ЭВМ. Строго говоря, с него должна начинаться любая разработка. Служебное задание готовится в свободной форме. Оно содержит цели конкретного проекта, разработку которого планируется начать, а также некое краткое описание функциональности либо задач, которые создаваемое приложение будет решать. Совсем идеально, если служебные задания будут готовиться под конкретные модули разрабатываемого решения и содержать в себе полное и чёткое техническое задание на каждый модуль. Если такой документ отсутствует, рекомендуется его разработать для текущих проектов, либо составить новый на развитие ранее разработанного продукта, в котором следует дополнительно прописать принадлежность исключительных прав компании. Своим заказчикам мы упрощаем жизнь и предлагаем им готовые шаблоны, но вы можете написать и в свободной форме.
Не страшно, если вы не составляли служебное задание на предыдущих этапах разработки. Ваш продукт наверняка дорабатывается, и начать практику заданий имеет смысл при развитии продукта. В этом случае сформулируйте задание так, чтобы из контекста было понятно: дорабатывается именно существующее решение, работа над которым велась и ранее. Если служебные задания так или иначе были сформулированы, нелишним будет провести их аудит – либо самостоятельно, либо с помощью привлеченного консультанта. Это позволит понять, все ли в порядке с документами, если нет, то привести их в порядок. Нужно понимать, что собственный софт, не имеющий документов, проверяющими органами будет восприниматься как пиратский. А это – лишние риски, которые ни к чему любой компании.
Шаг третий. Сделайте так, чтобы разработчик (если он один) или тим-лидер (если у вас отдел разработки) подготовили вам докладную записку о выполнении служебного задания. В ней содержится информация о функциональности разработанного модуля, либо о функциональности продукта в целом. Также в обращении должен быть тезис о том, что программный продукт к эксплуатации готов. Фактически докладная записка фиксирует документально факт выполнения служебного задания и представляет собой аналог акта приёма-передачи.
Шаг четвертый. На основании докладной записки специально назначенная комиссия производит анализ возможности приема программного продукта в тестовую или промышленную эксплуатацию, после прохождения которой на основании акта приемки формируется приказ по организации о переводе данного ПО в промышленную эксплуатацию.
Шаг пятый. После приказа по организации о том, что продукт введен в эксплуатацию, следует подготовить распоряжение о постановке ПО на бухгалтерский баланс, определить его начальную стоимость, полезный срок использования и пр. Как это сделать? Необходимо создать экспертный совет, который в рамках обсуждения функциональности ПО выдаст рекомендации и оценки, связанные со стоимостью программного обеспечения. Рекомендации экспертов лучше формулировать в виде протокола, который затем должен быть передан в бухгалтерию. Начальная стоимость определяется самостоятельно компанией-разработчиком и чаще всего включает в себя непосредственно прямые затраты. Не стоит завышать стоимость ПО, т.к. после постановки на бухгалтерский учет компания должна будет платить налоги, которые будут зависеть от начальной стоимости. Подробные правила формирования в бухгалтерском учете и бухгалтерской отчетности информации о нематериальных активах организаций устанавливает ПБУ 14/2007 (Положение по бухгалтерскому учету «Учет нематериальных активов», приложение к приказу Минфина РФ от 27.12.2007 №153н).
Итак, чтобы внутренняя разработка была полностью формализована, она должна быть защищена следующими документами:
1. Служебное задание
2. Докладная записка о выполнении задания
3. Акт приемки программного продукта к эксплуатации в компании
4. Распоряжение о постановке программного обеспечения на бухгалтерский баланс
Толково и правильно проведенный процесс формализации превращает внутреннюю разработку в программный актив. Говоря юридическим и бухгалтерским языком, таким образом получается нематериальный актив, повышающий капитализацию компании. Несмотря на нематериальный статус, у программного актива много общего с обычными активами, но, прежде всего, – это его стоимость. Компания может зарабатывать, например, передавая неисключительные права на программный продукт другим компаниям/пользователям или использовать его в организации, оптимизируя расходы на задачи, которые ранее не были автоматизированы, сокращая трудозатраты на их выполнение. Если данная разработка является дорогостоящим продуктом, она существенно увеличит капитализацию компании.
На Хабре неоднократно поднимался вопрос о важности регистрации приложений в Роспатенте. На мой взгляд, это весьма желательно, поскольку свидетельство Роспатента описывает не программный продукт как таковой, а совокупность его характеристик, определяющие его ценность для пользователя. Вложив деньги и время в защиту приложения, вы можете в какой-то степени обезопасить свою разработку от повторения. Важно: Роспатент при регистрации производит формальную экспертизу поступившей заявки, но не производит детальную экспертизу программного продукта. Поэтому правильное составление заявки на интеллектуальную защиту программного продукта – действительно другая история. При этом отмечу, что в соответствии с действующим законодательством России государственная регистрация программы для ЭВМ не является обязательной. То есть нельзя сказать, что если вы не зарегистрируете программу для ЭВМ в Роспатенте, то не сможете защитить свои права на неё, т.к., повторюсь, авторское право возникает в силу создания продукта, а не в силу его регистрации где бы то ни было.
Это очень частый вопрос со стороны программистов: «Какую выгоду я, как создатель, получаю от формализации написанного мною приложения?» Если работодатель, для которого разработчик создал приложение, юридически правильно это приложение формализовал, программисту остается так называемое личное неимущественное право автора. Никаких денежных бенефитов оно с собой, скорее всего, не несет, поскольку создатель уже получил вознаграждение за выполненную работу, и никакими имущественными правами на написанный им софт он уже не обладает. Неимущественные права позволяют потешить собственное эго и добавить проект в портфолио. Например, автор разработки вправе сам предложить название ПО, разрешать указывать свое имя в контексте приложения. Но имейте в виду, что право указывать имя автора, либо его не указывать, тоже регулируется вышеупомянутым трудовым договором. Отмечу ещё, что неимущественные права распространяются в том числе на несколько человек, то есть у продукта может быть несколько авторов.
Обратите внимание, что если на стадии разработки, или в течение трех лет после, работодатель объявил, что программный продукт представляет из себя коммерческую тайну, то разглашать любые сведения о ПО запрещено.
Мне и моим коллегам нередко приходится сталкиваться с ситуацией, когда собственник или топ-менеджеры компаний-заказчиков даже не знают, какое ПО и для каких целей создала команда разработки. Информацию о таком софте мы получаем на самом первом этапе процедуры Software Asset Management, когда специальные средства сканируют серверы и ПК в компании-заказчике. Обнаружив такие «артефакты», мы вместе с ответственными сотрудниками поднимаем необходимую документацию и по крайней мере понимаем, что перед нами внутренняя разработка.
Представьте себе ситуацию, что в компанию приходит проверка, которая обнаруживает непонятный «левый» софт, на который нет никакой документации, подтверждающей его лицензионность. Оправдание «это наши программисты разработали» в данном случае не работает, нужны подтверждающие документы. Без них компании может грозить изъятие аппаратно-программного обеспечения до выяснения обстоятельств. Вероятно, компания рано или поздно докажет, что данный софт это их собственная разработка, но силы и время, потраченные на это, не сопоставимы с рисками для непрерывности бизнеса, которые компания может понести. Такая вот страшилка вместо заключения.
Если остались вопросы – пишите в комментариях, я постараюсь ответить.
Текст разделен на три части. В первой я расскажу о пяти важных шагах по формализации таких разработок. Эта формализация поможет не только закрепить за компанией права на эти разработки, но и сократить юридические риски, связанные с «перехватом» прав на ПО бывшими сотрудниками, а также экономические риски неправильного учёта ПО как актива. Из второй части станет понятно, какими правами на программный продукт, созданный для компании, обладают непосредственно программисты. И в третьей части я поясню, почему так важно правильно оформлять документы и с какими рисками может столкнуться компания-разработчик.
Опыт последних трёх лет показывает, как изменилось отношение компаний ко внутренним разработкам. Даже простой, созданный «на коленке» софт, воспринимается как некая сущность, имеющая свою ценность. В некоторых компаниях ценность внутренних разработок увеличилась еще и под влиянием политики импортозамещения: для них написанное собственной командой программистов ПО – альтернатива зарубежным продуктам, часто уже достаточно близкая к ним по функциональности. Как бы то ни было, организации стремятся формализовать внутренние разработки – мы видим это по количеству соответствующих обращений в наш департамент.
Пять шагов к формализации внутренних разработок
Под формализацией мы имеем в виду прежде всего надлежащее документальное оформление созданного результата интеллектуальной деятельности. Нужно чётко понимать, что в соответствии с действующим законодательством авторское право на программу для ЭВМ возникает с момента ее создания в силу самого факта её создания. Справедливо, что если сотрудник, работающий в организации по трудовому договору, занимается разработкой программного продукта для компании, то данный программный продукт должен принадлежать компании, поскольку это относится к его обязанностям, и именно за это он получает заработную плату и иные виды компенсации (премии и другие выплаты компенсационного характера). Однако крайне важно понимать, что в авторском праве разграничены две вещи — авторское право (нематериальное) и т.н. исключительное право (материальное право, право распоряжаться объектом авторского права). И если авторское право возникает в силу создания и принадлежит физическим лицам, создавшим продукт, то «материальное» право подлежит тонкой документальной настройке. Механизм по защите внутренних разработок включается в пять шагов.
Шаг первый. В рамках трудового договора формализуйте функции сотрудников и подчеркните, что в обязанности сотрудника входит разработка служебных произведений, программ для ЭВМ, баз данных и т.д. Также проверьте тот трудовой договор, который уже подписан сторонами – это может быть типовой документ, в котором пункты о разработке служебных произведений могут быть не указаны. В этом случае заключите с разработчиком дополнительное соглашение, в котором следует сделать акцент на функциональных задачах специалиста, а также прописать принадлежность возникающих исключительных прав компании нанимателю. Также в договоре обязательно должен быть указан порядок уплаты авторского вознаграждения за созданные программы ЭВМ. Авторское вознаграждение может быть включено в заработную плату, премирование, либо иные виды материального поощрения.
Шаг второй. Всегда составляйте служебное задание на разработку программы для ЭВМ. Строго говоря, с него должна начинаться любая разработка. Служебное задание готовится в свободной форме. Оно содержит цели конкретного проекта, разработку которого планируется начать, а также некое краткое описание функциональности либо задач, которые создаваемое приложение будет решать. Совсем идеально, если служебные задания будут готовиться под конкретные модули разрабатываемого решения и содержать в себе полное и чёткое техническое задание на каждый модуль. Если такой документ отсутствует, рекомендуется его разработать для текущих проектов, либо составить новый на развитие ранее разработанного продукта, в котором следует дополнительно прописать принадлежность исключительных прав компании. Своим заказчикам мы упрощаем жизнь и предлагаем им готовые шаблоны, но вы можете написать и в свободной форме.
Не страшно, если вы не составляли служебное задание на предыдущих этапах разработки. Ваш продукт наверняка дорабатывается, и начать практику заданий имеет смысл при развитии продукта. В этом случае сформулируйте задание так, чтобы из контекста было понятно: дорабатывается именно существующее решение, работа над которым велась и ранее. Если служебные задания так или иначе были сформулированы, нелишним будет провести их аудит – либо самостоятельно, либо с помощью привлеченного консультанта. Это позволит понять, все ли в порядке с документами, если нет, то привести их в порядок. Нужно понимать, что собственный софт, не имеющий документов, проверяющими органами будет восприниматься как пиратский. А это – лишние риски, которые ни к чему любой компании.
Шаг третий. Сделайте так, чтобы разработчик (если он один) или тим-лидер (если у вас отдел разработки) подготовили вам докладную записку о выполнении служебного задания. В ней содержится информация о функциональности разработанного модуля, либо о функциональности продукта в целом. Также в обращении должен быть тезис о том, что программный продукт к эксплуатации готов. Фактически докладная записка фиксирует документально факт выполнения служебного задания и представляет собой аналог акта приёма-передачи.
Шаг четвертый. На основании докладной записки специально назначенная комиссия производит анализ возможности приема программного продукта в тестовую или промышленную эксплуатацию, после прохождения которой на основании акта приемки формируется приказ по организации о переводе данного ПО в промышленную эксплуатацию.
Шаг пятый. После приказа по организации о том, что продукт введен в эксплуатацию, следует подготовить распоряжение о постановке ПО на бухгалтерский баланс, определить его начальную стоимость, полезный срок использования и пр. Как это сделать? Необходимо создать экспертный совет, который в рамках обсуждения функциональности ПО выдаст рекомендации и оценки, связанные со стоимостью программного обеспечения. Рекомендации экспертов лучше формулировать в виде протокола, который затем должен быть передан в бухгалтерию. Начальная стоимость определяется самостоятельно компанией-разработчиком и чаще всего включает в себя непосредственно прямые затраты. Не стоит завышать стоимость ПО, т.к. после постановки на бухгалтерский учет компания должна будет платить налоги, которые будут зависеть от начальной стоимости. Подробные правила формирования в бухгалтерском учете и бухгалтерской отчетности информации о нематериальных активах организаций устанавливает ПБУ 14/2007 (Положение по бухгалтерскому учету «Учет нематериальных активов», приложение к приказу Минфина РФ от 27.12.2007 №153н).
Итак, чтобы внутренняя разработка была полностью формализована, она должна быть защищена следующими документами:
1. Служебное задание
2. Докладная записка о выполнении задания
3. Акт приемки программного продукта к эксплуатации в компании
4. Распоряжение о постановке программного обеспечения на бухгалтерский баланс
Толково и правильно проведенный процесс формализации превращает внутреннюю разработку в программный актив. Говоря юридическим и бухгалтерским языком, таким образом получается нематериальный актив, повышающий капитализацию компании. Несмотря на нематериальный статус, у программного актива много общего с обычными активами, но, прежде всего, – это его стоимость. Компания может зарабатывать, например, передавая неисключительные права на программный продукт другим компаниям/пользователям или использовать его в организации, оптимизируя расходы на задачи, которые ранее не были автоматизированы, сокращая трудозатраты на их выполнение. Если данная разработка является дорогостоящим продуктом, она существенно увеличит капитализацию компании.
На Хабре неоднократно поднимался вопрос о важности регистрации приложений в Роспатенте. На мой взгляд, это весьма желательно, поскольку свидетельство Роспатента описывает не программный продукт как таковой, а совокупность его характеристик, определяющие его ценность для пользователя. Вложив деньги и время в защиту приложения, вы можете в какой-то степени обезопасить свою разработку от повторения. Важно: Роспатент при регистрации производит формальную экспертизу поступившей заявки, но не производит детальную экспертизу программного продукта. Поэтому правильное составление заявки на интеллектуальную защиту программного продукта – действительно другая история. При этом отмечу, что в соответствии с действующим законодательством России государственная регистрация программы для ЭВМ не является обязательной. То есть нельзя сказать, что если вы не зарегистрируете программу для ЭВМ в Роспатенте, то не сможете защитить свои права на неё, т.к., повторюсь, авторское право возникает в силу создания продукта, а не в силу его регистрации где бы то ни было.
На что может рассчитывать рядовой разработчик?
Это очень частый вопрос со стороны программистов: «Какую выгоду я, как создатель, получаю от формализации написанного мною приложения?» Если работодатель, для которого разработчик создал приложение, юридически правильно это приложение формализовал, программисту остается так называемое личное неимущественное право автора. Никаких денежных бенефитов оно с собой, скорее всего, не несет, поскольку создатель уже получил вознаграждение за выполненную работу, и никакими имущественными правами на написанный им софт он уже не обладает. Неимущественные права позволяют потешить собственное эго и добавить проект в портфолио. Например, автор разработки вправе сам предложить название ПО, разрешать указывать свое имя в контексте приложения. Но имейте в виду, что право указывать имя автора, либо его не указывать, тоже регулируется вышеупомянутым трудовым договором. Отмечу ещё, что неимущественные права распространяются в том числе на несколько человек, то есть у продукта может быть несколько авторов.
Обратите внимание, что если на стадии разработки, или в течение трех лет после, работодатель объявил, что программный продукт представляет из себя коммерческую тайну, то разглашать любые сведения о ПО запрещено.
Почему важна бумажная работа?
Мне и моим коллегам нередко приходится сталкиваться с ситуацией, когда собственник или топ-менеджеры компаний-заказчиков даже не знают, какое ПО и для каких целей создала команда разработки. Информацию о таком софте мы получаем на самом первом этапе процедуры Software Asset Management, когда специальные средства сканируют серверы и ПК в компании-заказчике. Обнаружив такие «артефакты», мы вместе с ответственными сотрудниками поднимаем необходимую документацию и по крайней мере понимаем, что перед нами внутренняя разработка.
Представьте себе ситуацию, что в компанию приходит проверка, которая обнаруживает непонятный «левый» софт, на который нет никакой документации, подтверждающей его лицензионность. Оправдание «это наши программисты разработали» в данном случае не работает, нужны подтверждающие документы. Без них компании может грозить изъятие аппаратно-программного обеспечения до выяснения обстоятельств. Вероятно, компания рано или поздно докажет, что данный софт это их собственная разработка, но силы и время, потраченные на это, не сопоставимы с рисками для непрерывности бизнеса, которые компания может понести. Такая вот страшилка вместо заключения.
Если остались вопросы – пишите в комментариях, я постараюсь ответить.
