Текст разделен на три части. В первой я расскажу о пяти важных шагах по формализации таких разработок. Эта формализация поможет не только закрепить за компанией права на эти разработки, но и сократить юридические риски, связанные с «перехватом» прав на ПО бывшими сотрудниками, а также экономические риски неправильного учёта ПО как актива. Из второй части станет понятно, какими правами на программный продукт, созданный для компании, обладают непосредственно программисты. И в третьей части я поясню, почему так важно правильно оформлять документы и с какими рисками может столкнуться компания-разработчик.
Опыт последних трёх лет показывает, как изменилось отношение компаний ко внутренним разработкам. Даже простой, созданный «на коленке» софт, воспринимается как некая сущность, имеющая свою ценность. В некоторых компаниях ценность внутренних разработок увеличилась еще и под влиянием политики импортозамещения: для них написанное собственной командой программистов ПО – альтернатива зарубежным продуктам, часто уже достаточно близкая к ним по функциональности. Как бы то ни было, организации стремятся формализовать внутренние разработки – мы видим это по количеству соответствующих обращений в наш департамент.
Пять шагов к формализации внутренних разработок
Под формализацией мы имеем в виду прежде всего надлежащее документальное оформление созданного результата интеллектуальной деятельности. Нужно чётко понимать, что в соответствии с действующим законодательством авторское право на программу для ЭВМ возникает с момента ее создания в силу самого факта её создания. Справедливо, что если сотрудник, работающий в организации по трудовому договору, занимается разработкой программного продукта для компании, то данный программный продукт должен принадлежать компании, поскольку это относится к его обязанностям, и именно за это он получает заработную плату и иные виды компенсации (премии и другие выплаты компенсационного характера). Однако крайне важно понимать, что в авторском праве разграничены две вещи — авторское право (нематериальное) и т.н. исключительное право (материальное право, право распоряжаться объектом авторского права). И если авторское право возникает в силу создания и принадлежит физическим лицам, создавшим продукт, то «материальное» право подлежит тонкой документальной настройке. Механизм по защите внутренних разработок включается в пять шагов.
Шаг первый. В рамках трудового договора формализуйте функции сотрудников и подчеркните, что в обязанности сотрудника входит разработка служебных произведений, программ для ЭВМ, баз данных и т.д. Также проверьте тот трудовой договор, который уже подписан сторонами – это может быть типовой документ, в котором пункты о разработке служебных произведений могут быть не указаны. В этом случае заключите с разработчиком дополнительное соглашение, в котором следует сделать акцент на функциональных задачах специалиста, а также прописать принадлежность возникающих исключительных прав компании нанимателю. Также в договоре обязательно должен быть указан порядок уплаты авторского вознаграждения за созданные программы ЭВМ. Авторское вознаграждение может быть включено в заработную плату, премирование, либо иные виды материального поощрения.
Шаг второй. Всегда составляйте служебное задание на разработку программы для ЭВМ. Строго говоря, с него должна начинаться любая разработка. Служебное задание готовится в свободной форме. Оно содержит цели конкретного проекта, разработку которого планируется начать, а также некое краткое описание функциональности либо задач, которые создаваемое приложение будет решать. Совсем идеально, если служебные задания будут готовиться под конкретные модули разрабатываемого решения и содержать в себе полное и чёткое техническое задание на каждый модуль. Если такой документ отсутствует, рекомендуется его разработать для текущих проектов, либо составить новый на развитие ранее разработанного продукта, в котором следует дополнительно прописать принадлежность исключительных прав компании. Своим заказчикам мы упрощаем жизнь и предлагаем им готовые шаблоны, но вы можете написать и в свободной форме.
Не страшно, если вы не составляли служебное задание на предыдущих этапах разработки. Ваш продукт наверняка дорабатывается, и начать практику заданий имеет смысл при развитии продукта. В этом случае сформулируйте задание так, чтобы из контекста было понятно: дорабатывается именно существующее решение, работа над которым велась и ранее. Если служебные задания так или иначе были сформулированы, нелишним будет провести их аудит – либо самостоятельно, либо с помощью привлеченного консультанта. Это позволит понять, все ли в порядке с документами, если нет, то привести их в порядок. Нужно понимать, что собственный софт, не имеющий документов, проверяющими органами будет восприниматься как пиратский. А это – лишние риски, которые ни к чему любой компании.
Шаг третий. Сделайте так, чтобы разработчик (если он один) или тим-лидер (если у вас отдел разработки) подготовили вам докладную записку о выполнении служебного задания. В ней содержится информация о функциональности разработанного модуля, либо о функциональности продукта в целом. Также в обращении должен быть тезис о том, что программный продукт к эксплуатации готов. Фактически докладная записка фиксирует документально факт выполнения служебного задания и представляет собой аналог акта приёма-передачи.
Шаг четвертый. На основании докладной записки специально назначенная комиссия производит анализ возможности приема программного продукта в тестовую или промышленную эксплуатацию, после прохождения которой на основании акта приемки формируется приказ по организации о переводе данного ПО в промышленную эксплуатацию.
Шаг пятый. После приказа по организации о том, что продукт введен в эксплуатацию, следует подготовить распоряжение о постановке ПО на бухгалтерский баланс, определить его начальную стоимость, полезный срок использования и пр. Как это сделать? Необходимо создать экспертный совет, который в рамках обсуждения функциональности ПО выдаст рекомендации и оценки, связанные со стоимостью программного обеспечения. Рекомендации экспертов лучше формулировать в виде протокола, который затем должен быть передан в бухгалтерию. Начальная стоимость определяется самостоятельно компанией-разработчиком и чаще всего включает в себя непосредственно прямые затраты. Не стоит завышать стоимость ПО, т.к. после постановки на бухгалтерский учет компания должна будет платить налоги, которые будут зависеть от начальной стоимости. Подробные правила формирования в бухгалтерском учете и бухгалтерской отчетности информации о нематериальных активах организаций устанавливает ПБУ 14/2007 (Положение по бухгалтерскому учету «Учет нематериальных активов», приложение к приказу Минфина РФ от 27.12.2007 №153н).
Итак, чтобы внутренняя разработка была полностью формализована, она должна быть защищена следующими документами:
1. Служебное задание
2. Докладная записка о выполнении задания
3. Акт приемки программного продукта к эксплуатации в компании
4. Распоряжение о постановке программного обеспечения на бухгалтерский баланс
Толково и правильно проведенный процесс формализации превращает внутреннюю разработку в программный актив. Говоря юридическим и бухгалтерским языком, таким образом получается нематериальный актив, повышающий капитализацию компании. Несмотря на нематериальный статус, у программного актива много общего с обычными активами, но, прежде всего, – это его стоимость. Компания может зарабатывать, например, передавая неисключительные права на программный продукт другим компаниям/пользователям или использовать его в организации, оптимизируя расходы на задачи, которые ранее не были автоматизированы, сокращая трудозатраты на их выполнение. Если данная разработка является дорогостоящим продуктом, она существенно увеличит капитализацию компании.
На Хабре неоднократно поднимался вопрос о важности регистрации приложений в Роспатенте. На мой взгляд, это весьма желательно, поскольку свидетельство Роспатента описывает не программный продукт как таковой, а совокупность его характеристик, определяющие его ценность для пользователя. Вложив деньги и время в защиту приложения, вы можете в какой-то степени обезопасить свою разработку от повторения. Важно: Роспатент при регистрации производит формальную экспертизу поступившей заявки, но не производит детальную экспертизу программного продукта. Поэтому правильное составление заявки на интеллектуальную защиту программного продукта – действительно другая история. При этом отмечу, что в соответствии с действующим законодательством России государственная регистрация программы для ЭВМ не является обязательной. То есть нельзя сказать, что если вы не зарегистрируете программу для ЭВМ в Роспатенте, то не сможете защитить свои права на неё, т.к., повторюсь, авторское право возникает в силу создания продукта, а не в силу его регистрации где бы то ни было.
На что может рассчитывать рядовой разработчик?
Это очень частый вопрос со стороны программистов: «Какую выгоду я, как создатель, получаю от формализации написанного мною приложения?» Если работодатель, для которого разработчик создал приложение, юридически правильно это приложение формализовал, программисту остается так называемое личное неимущественное право автора. Никаких денежных бенефитов оно с собой, скорее всего, не несет, поскольку создатель уже получил вознаграждение за выполненную работу, и никакими имущественными правами на написанный им софт он уже не обладает. Неимущественные права позволяют потешить собственное эго и добавить проект в портфолио. Например, автор разработки вправе сам предложить название ПО, разрешать указывать свое имя в контексте приложения. Но имейте в виду, что право указывать имя автора, либо его не указывать, тоже регулируется вышеупомянутым трудовым договором. Отмечу ещё, что неимущественные права распространяются в том числе на несколько человек, то есть у продукта может быть несколько авторов.
Обратите внимание, что если на стадии разработки, или в течение трех лет после, работодатель объявил, что программный продукт представляет из себя коммерческую тайну, то разглашать любые сведения о ПО запрещено.
Почему важна бумажная работа?
Мне и моим коллегам нередко приходится сталкиваться с ситуацией, когда собственник или топ-менеджеры компаний-заказчиков даже не знают, какое ПО и для каких целей создала команда разработки. Информацию о таком софте мы получаем на самом первом этапе процедуры Software Asset Management, когда специальные средства сканируют серверы и ПК в компании-заказчике. Обнаружив такие «артефакты», мы вместе с ответственными сотрудниками поднимаем необходимую документацию и по крайней мере понимаем, что перед нами внутренняя разработка.
Представьте себе ситуацию, что в компанию приходит проверка, которая обнаруживает непонятный «левый» софт, на который нет никакой документации, подтверждающей его лицензионность. Оправдание «это наши программисты разработали» в данном случае не работает, нужны подтверждающие документы. Без них компании может грозить изъятие аппаратно-программного обеспечения до выяснения обстоятельств. Вероятно, компания рано или поздно докажет, что данный софт это их собственная разработка, но силы и время, потраченные на это, не сопоставимы с рисками для непрерывности бизнеса, которые компания может понести. Такая вот страшилка вместо заключения.
Если остались вопросы – пишите в комментариях, я постараюсь ответить.
Комментарии (22)
alan008
03.03.2017 18:00+1На основании докладной записки специально назначенная комиссия производит анализ возможности приема программного продукта в тестовую или промышленную эксплуатацию, после прохождения которой на основании акта приемки формируется приказ по организации о переводе данного ПО в промышленную эксплуатацию
Какая же у вас мохровая бюрократия. Обычно говорят что в бизнесе на принятие решения уходят считанные минуты, а то не угонишься за конкурентами
d-stream
04.03.2017 00:13Ну тут можно противопоставить от «семь раз отмерь» до «больше бумаги — чище жо..» -)
В бизнесе в виде размера «я директор, я и сторож» — можно и мгновенно, а как быть с бизнесами немного покрупнее?
Softliner
04.03.2017 11:32На самом деле всё очень просто: нужно понять базовый принцип. Я в статье, скорее, говорил о запущенных случаях. Безусловно, можно оптимизировать и включить в трудовые договоры со ВСЕМИ сотрудниками положения, которые освободят от почти половины озвученных в статье бумажек и документов. Нужно иметь в виду, что мы хотим защититься и постараться минимизировать споры о правах на ПО. Поэтому лучше «закрыться» бумажками.
VolCh
04.03.2017 13:12+1Решение может приниматься быстро, всё это вовсе не означает, что комиссия должна сутками сидеть и тестировть каждый патч. Решение принимается принятым в фирме способом, а потом просто секретарь заполняет приготовленную юристами "рыбы", подставляя дату, название, версию и фамилии членов комиссии и бегает за подписями, если нет нормальной СЭД.
ukt
05.03.2017 22:56+1Это очень частый вопрос со стороны программистов: «Какую выгоду я, как создатель, получаю от формализации написанного мною приложения?» Если работодатель, для которого разработчик создал приложение, юридически правильно это приложение формализовал, программисту остается так называемое личное неимущественное право автора. Никаких денежных бенефитов оно с собой, скорее всего, не несет, поскольку создатель уже получил вознаграждение за выполненную работу, и никакими имущественными правами на написанный им софт он уже не обладает. Неимущественные права позволяют потешить собственное эго и добавить проект в портфолио. Например, автор разработки вправе сам предложить название ПО, разрешать указывать свое имя в контексте приложения.
ГК РФ Статья 1295. Служебное произведение
Если работодатель в срок, предусмотренный в абзаце втором настоящего пункта, начнет использование служебного произведения или передаст исключительное право другому лицу, автор имеет право на вознаграждение. Автор приобретает указанное право на вознаграждение и в случае, когда работодатель принял решение о сохранении служебного произведения в тайне и по этой причине не начал использование этого произведения в указанный срок. Размер вознаграждения, условия и порядок его выплаты работодателем определяются договором между ним и работником, а в случае спора — судом.
ЗП за выполнение трудовых обязанностей и вознаграждение за использование — это разные деньги.
Softliner
06.03.2017 09:33Безусловно, ЗП и вознаграждение – это юридически разные вещи, поэтому чтобы «два раза не вставать», всегда проще определиться с этим раз и навсегда для работника и работодателя в соглашении между ними. Как правило, формулировки такого соглашения сводятся к тому, что авторское вознаграждение включено в заработную плату либо выплачивается как премия. Здесь я сторонник не усложнять.
ukt
06.03.2017 13:22+1Два раза не вставать не получится.
1) Человек может уволиться, что никаким образом не отменяет вознаграждение.
2) При «учете в ЗП» это будет ЗП и оно не может быть включено в ЗП. Оно должно быть отдельной строкой, как в счете за ЖКХ.
3) На авторское вознаграждение оформляется другой документ, т.к. заранее учесть как и какие объекты авторских прав будут разработаны, невозможно.
4) На каждый объект оформляется свой документ, т.к. они разработаны в разное время.
Как видно, даже при учете пунктов 3, 4, уже невозможно авторское вознаграждение «учесть» в ЗП.
Благодарить нужно копирастов и капитализм.
Все работодатели мечтают о своем собственном рабе-разработчике программисте — всё, что он разработал за зарплату, считают своим, а зачастую, что и он не в рабочее время пытаются узурпировать. Однако, на эту позицию ГК остужает пыл.
byria
06.03.2017 03:18Подскажите,
1. если софт ( программа) написаны до организации юридического лица, а в последствии на основании его регистрируется фирма( то есть фирма создается для продажи или предоставления ПО за деньги). Но софт писался 1м или более человек до факта регистрации фирмы и первых попыток продажи продукта. Какие моменты вы бы порекомендовали заранее просчитать и что необходимо сделать?
2. Не могли бы вы привести пошаговый пример регистрации в Роспатенте, с цифрами и картинками.
3. Как с подобным происходит в других странах, если известно, по примеру вашей статьи?
4. Есть ли какие-то отличия особенности в указанных вами случаях\примерах выше для развлекательного ПО ( мобильных, локальных игр, ПО с дополнительно реальностью)?
5. Как может законно разработчик ПО уйдя из компании, использовать наработки аналогичного функционала своем новом продукте, при этом не быть привлеченным к судебному иску со стороны предыдущего работодателя.
Спасибо!VolCh
06.03.2017 07:401.1 Определиться с составом авторов
1.2 Определиться как авторский коллектив передаёт фирме права на использования программы (варианты от передачи в общественное достояние до полной передачи исключительных имущественных прав) и оформить эту передачу
1.3 Определиться как фирма будет передавать клиентам софт (сильно зависит от 1.2)
5 Привлеченным в качестве ответчика по судебному иску всегда может быть, а там что суд решит. Минимизировать вероятность решения в пользу бывшего работодателя — не подписывать никаких NDA, никаких полных передач исключительных прав и т. п., оставаясь полноправным автором хотя бы своих фрагментов кода. Но чем дальше тем сложнее будет найти работы без такой необходимости, в том числе благодаря этому посту :)
Softliner
06.03.2017 09:351. Самое важное здесь — правильно передать права на программу для ЭВМ фирме, которая будет заниматься продажей этого софта. Это может быть лицензионное соглашение, а может быть полная передача прав таким образом, чтобы фирма, созданная для продажи, стала полным правообладателем ПО.
2. Хорошая идея, в целом. Оставлю это как идею для будущего поста.
3. К сожалению, про многие страны не знаю, но в целом и общем схема приблизительно такая же в некоторых.
4. Никакой разницы в жанре ПО для целей его надлежащего оформления нет. Программа для ЭВМ — это результат интеллектуальной деятельности, и не имеет значения, какой он направленности.
5. Крайне сложный вопрос, ответить на который очень коротко я не смогу. Функционал – это, по сути, идея, то, что должен уметь делать софт. Программ с аналогичным функционалом – множество (к примеру, MS Office, Мой Офис, офисные продукты от Apple и др.). Авторское право на идею не распространяется. Поэтому никто не запрещает разрабатывать у другого работодателя ПО с аналогичным функционалом. Но код должен быть иным, интерфейс и т.д.
yiliya
13.03.2017 04:35Коротко и понятно, но, в силу того, что коротко, не все моменты учтены. Про вознаграждение уже написали выше.
Всегда интересовал вопрос — а если нет записки о создании ПО от автора, то что, ПО не считается служебным произведением? Тогда зачем автору совершать лишние телодвижения и что-то там писать, если по идее это его программа и теоретически он может ее продать? *ситуация из разряда сферического коня в вакууме, но тем не менее* Поэтому я склоняюсь к тому, что ПО принадлежит работодателю в силу его создания автором-работником, и никакие докладные не нужны.
Также можно добавить в трудовой договор условие о том, что автор не против переработки его ПО.
И что-то непонятно с правом автора на имя, как так можно не указывать имя автора?
Ст. 1265 ГК:
1. Право авторства — право признаваться автором произведения и право автора на имя — право использовать или разрешать использование произведения под своим именем, под вымышленным именем (псевдонимом) или без указания имени, то есть анонимно, неотчуждаемы и непередаваемы, в том числе при передаче другому лицу или переходе к нему исключительного права на произведение и при предоставлении другому лицу права использования произведения. Отказ от этих прав ничтожен.VolCh
13.03.2017 10:40Всё что создаст человек, работающий удаленно, с ненормированным рабочим нём будет принадлежать его работодателю? Записка от автора может и не нужна, но вот без задания работодателю будет очень сложно доказать, что программа написана для него в рамках служебных обязанностей.
Сами же пишите, что автор вправе разрешать использовать произведение без указания его имени.
yiliya
13.03.2017 12:43С удаленкой сложнее конечно.
«В силу создания» — не означает без служебного задания.
Автор да, при его желании можно не указывать, сорри.VolCh
13.03.2017 13:13Обычный способ выявить дыру в рассуждениях — взять максимально неудобный, гипертрофированный, даже абсурдный вариант. :) Но по сути ничем от обычного офисного работника не отличается, если нет служебного задания — максимум дисциплинарное взыскание вплоть до увольнения, если работник вместо выполнения служебных задач будет писать какой-то софт.
Частый вариант у меня — приходит бизнес и просит подготовить какой-то отчёт, а я не отчёт готовлю, а пишу софт, готовящий отчёты. Формально это моё авторское произведение, исключительные права на использование которого я бизнесу не передаю.
yiliya
13.03.2017 14:37Ну тут смотря кого мы защищаем:) Я — бизнес, который не всегда дает именно документированные задания.
Разработка по Вашей инициативе — вопросов нет, хотя может и работодателя будет бомбить:) Но он может, узнав о разработке, выдать Вам задание написать такую же программу — и вопрос решен в его пользу.
VolCh
Имеет ли смысл занижать или завышать балансовую стоимость? Оценивать её по рыночным ценам на аналогичные продукты или по затратам? Не придерется ли кто, если поставить стоимость 1 рубль?
Softliner
Если себестоимость больше одного рубля, то я бы не рекомендовал её указывать в размере 1 руб. Не исключена вероятность, что такая заниженная сумма вызовет вопросы у налоговых органов. Что касается завышения, то в этом случае я не вижу проблем, поскольку это вопрос оценки. Если Вы оцениваете программу больше себестоимости разработки, то вы повышаете стоимость компании (капитализации).
VolCh
Вопрос определения себестоимости сложный. Например, в трудовом договоре или подобных документах у разработчика может быть указано авторское вознаграждение в размере 1 рубля (по совету юристов, заявляющих, что отказ от вознаграждения может быть признан ничтожным) и исходя из него и считают себестоимость.
С другой стороны есть практика постановки на баланс бесплатно распространяемых продуктов с символической оценкой стоимости типа акта комиссии "потратили 1 рубль на скачивании из интернета" и вроде вопросов не вызывает.
AVX
А как правильно делать, если софт по GPL, но доработан внутри компании, и изменения не были возвращены в основную ветку разработки? (доработки для собственного использования предполагались).
Можно ли его ставить на баланс и как? С какой стоимостью?
С программистами/тестировщиками тоже не понятно —
1. все кто дорабатывал должны это делать по должностным обязанностям — тут понятно.
2. все кто дорабатывал НЕ должны это делать по должностным (к примеру, делали в свободное от работы время) — получается, никак нельзя уже включить софт в баланс.
3. Часть людей делали это в рамках должностных, а часть нет. Тут как?
Softliner
Не смогу ответить универсально на этот вопрос. Нужно внимательно ознакомиться с лицензионным соглашением. Если лицензия позволяет свободно дорабатывать и использовать доработку как свой софт, то на баланс можно ставить, безусловно. Стоимость точно так же определяется как и в случае с полностью своей разработкой.
По Вашему вопросу №2: софт включить в баланс можно. Это не зависит от того, должны были или не должны в рамках должностных обязанностей сотрудники заниматься разработкой ПО. Должны или не должны – это вопрос к последующему оформлению и возникновению прав на ПО, но это никак не влияет на постановку на баланс в качестве нематериального актива.
Ну, и по вопросу № 3 ответ тот же.
VolCh
Универсальный правильный способ вряд ли сейчас существует. Если под ним понимать отсутствие претензий со стороны регуляторов и сотрудников как авторов, то я бы сделал три актива: