Авторские права в программировании: Кто владеет кодом – разработчик или компания?

Разработчики игр и ПО

Примеряем роли

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

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

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

Разработчик
Кажется, что роль разработчика — самая незатейливая. Рабочая лошадка: создает код и воплощает идеи клиента, трансформированные в техническое задание усилиями бизнес-аналитика и архитектора. И придерживается сроков, установленных проект-менеджером. 

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

Тестировщик
Задача тестировщика — выявить в продукте баги, проблемы и неудачные решения, которые могут негативно сказаться на качестве и снизить ценность приложения для клиента. Тестировщик обязан понимать и учитывать контекст применения программного продукта: кто, как и для чего будет его использовать на стороне заказчика. Если функция X выполняется корректно и выдает правильный результат, но его получение занимает в среднем час, тестировщик может признать ее работу неудовлетворительной — зная, что клиенту требуется выполнять эту функцию 20–30 раз в день. 

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

Релиз-менеджер
В Microsoft Solutions Framework, что касается выпуска готового продукта или любой его работоспособной версии, — на релиз-менеджере. Он создает план выпуска версий, сертифицирует готовый продукт и следит за тем, чтобы программа дошла до клиента. Кроме того, в его обязанности входит информационное сопровождение версий, например описание новых функций, изменений и нововведений. 

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

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

Несмотря на множество ролей, модель MSF подходит не только большим коллективам, но и маленьким командам: в этом случае каждый участник берет на себя несколько ролей. 

Методология MSF подчеркивает, что все роли — равноправны, и ни один член команды не может считаться более влиятельным или принимать решения единолично.

Кому нужна лицензия ФСТЭК

Этот документ нужен только IT-компаниям, которые:

  1. Разрабатывают ПО или технические средства для защиты данных, например, антивирусы, межсетевые экраны, защитные программные комплексы.
  2. Помогают другим компаниям работать с персональными данными: хранят их на своих серверах, строят на заказ защищенные IT-инфраструктуры.
  3. Хранят сведения, являющиеся государственной тайной, или разрабатывают для этого ПО и технические инструменты.

Если компания просто хранит персональные данные клиентов и сотрудников, лицензия ей не нужна — это подтверждается специальным разъяснением ФСТЭК. То есть ФСТЭК не выдает никакой лицензии на обработку персональных данных, потому что она для этой деятельности не требуется.

Если компания разрабатывает ПО, не связанное с защитой информации, о получении лицензии ФСТЭК думать тоже не надо.

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

Ответственность разработчика

1. Защита личных данных пользователей

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

2. Обеспечение безопасности высокого уровня

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

3. Внедрение безопасности по умолчанию

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

4. Содействие образованию и осведомленности

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

Как правильно закрепить отношения с работниками

По умолчанию, исключительное право на программу принадлежит работодателю (ст. 1295 ГК РФ), но тут зарыта собака. Если документы между работником и работодателем не будут оформлены надлежащим образом, то, несмотря на наличие нормы закона, работник может «увести» права на программу и запретить работодателю использовать ее.

Чтобы не допустить такого варианта развития событий, рекомендую придерживаться следующих правил:

  • Четко и ясно прописать в трудовом договоре функции, которые должен выполнять сотрудник (например, разрабатывать такую-то программу);
  • Разработать положение о служебном произведении и дать его под роспись сотрудникам на ознакомление;
  • Составить должностную инструкцию и точно так же получить подписи работников;
  • Для каждого проекта составлять служебное задание и доносить его до сотрудника (можно электронно);
  • Ежемесячно подписывать акт приемки работ (иногда это называют отчетом о проделанной работе — разницы нет), где будет зафиксировано, какую работу выполнил сотрудник;
  • Прописать в отдельном соглашении размер вознаграждения сотрудника за создание программы и порядок его выплаты (1295 ГК РФ). Закон напрямую предусматривает необходимость выплаты вознаграждения и отделяет этот институт от заработной платы;
  • Выплатить работнику вознаграждение.

Если компания будет придерживаться указанного выше алгоритма, то ей удастся избежать «кейса Мамичева».  

Права на внутренние разработки (служебные произведения)

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

Если работодатель в течение трех лет не начнет использование произведения, не передаст исключительное право на него другому лицу или не сообщит работнику о сохранении произведения в тайне, исключительное право на служебное произведение возвращается работнику-автору (ст. 1295 ГК РФ).

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

Поэтому в настоящий момент не достаточно, что программный продукт или его часть созданы:

  • работником по трудовому договору;
  • в рабочее время и/или на оборудовании работодателя;
  • на основании конкретного служебного задания.

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

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

Это связано с тем, что в законодательстве отсутствует описание должностных обязанностей менеджера проектов. В Едином тарифно-квалификационном справочнике специалистов (ЕТКС) нет такой должности, а в трудовом договоре с сотрудником указываются общие обязанности.

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

Аналогичным образом обстоят дела с подавляющим большинством должностей, занимаемых сотрудниками ИТ-компаний, разрабатывающих программное обеспечение.

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

Похожие проблемы с пробелами в законодательстве могут возникать и при наличии наименования должности в ЕТКС. Несмотря на то, что ЕТКС содержит описание должности «инженер-программист» , в нем отсутствует указание на конкретные языки программирования. Должностная инструкция программиста должна конкретизировать круг их трудовых обязанностей применительно к конкретным предметам разработок.

Существует множество языков программирования и используемых технологий, а также прикладных объектов разработок. Они существенно отличаются. Поэтому программисту PHP нельзя вменить в обязанность разработку программного приложения на Java.

Вместо заключения

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

Когда на эту же ситуацию смотрит юрист, он видит совсем другие сущности и у него возникают совершенно другие вопросы. Какой именно код, какой конкретно программист и на каких именно условиях написал? Кому принадлежат права? Что с авторским вознаграждением? И если юрист не находит ответов, у него может непроизвольно произойти системный сбой: «Шеф, всё пропало! Гипс снимают, клиент уезжает!» Тогда во избежание рисков юрист вдруг рожает абсурдную рекомендацию: «Разработку использовать категорически не рекомендуется!»

Чем лицензия отличается от аттестата и сертификата ФСТЭК

Кроме лицензий ФСТЭК выдает еще аттестаты и сертификаты. Сравним эти три документа, чтобы понять отличия:

  1. Лицензию ФСТЭК выдают самой компании. Она дает право заниматься определенной деятельностью, связанной с защитой информации.
  2. Аттестат ФСТЭК также выдают компании. Он показывает, что компания соблюдает технические требования ФСТЭК по защите персональных данных. Этот документ нужен, если вы храните данные, требующие особой защиты — об этом мы рассказывали в статье про аттестат ФСТЭК.
  3. Сертификат ФСТЭК выдают на программное обеспечение. Он показывает, что это ПО соответствует техническим требованиям, его можно использовать для защиты персональных данных. Например, такой сертификат можно получить на разработанный антивирус.

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

У облака VK Cloud (бывш. MCS) есть аттестат безопасности ФСТЭК. В публичном облаке VK можно хранить персональные данные в соответствии с УЗ-2, 3 и 4. Для хранения данных с УЗ-2 и УЗ-1 также есть возможность сертификации, как в формате частного облака, так и на изолированном выделенном гипервизоре в ЦОДе VK. При построении гибридной инфраструктуры для хранения персональных данных на платформе VK Cloud (бывш. MCS) вы получаете облачную инфраструктуру, уже соответствующую всем требованиям законодательства. При этом частный контур нужно аттестовать, в этом могут помочь специалисты VK, что позволит быстрее пройти необходимые процедуры.

Что делать, кто-то украл ваш код

Как и в случае с текстом, у создателя программы есть исключительное право на использование его кода, в том числе право копировать, передавать другим лицам или выкладывать в открытый доступ.

Если нарушитель каким-то образом использует код без согласия автора или присвоил авторство себе, то последствия будут теми же, что и для человека, выложившего на своем сайте чужую статью.

За нарушение авторских прав на программу нарушителю полагается гражданская ответственность в одном из трех вариантов:

  1. Возмещение убытков.
    Их размер сложно доказать, поэтому на практике способ используется редко.
  2. Двойная цена за право на использование такого кода.
    Если это нечто уникальное, а не программа, которая массово продается, то здесь тоже могут возникнуть сложности.
  3. Компенсация в фиксированном размере.
    От 10 тысяч рублей до 5 миллионов рублей на усмотрение судьи.

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

Если нарушение было в крупном от 100 тысяч рублей или особо крупном размере от 1 млн рублей, то виновный несет уголовную ответственность вплоть до лишения свободы.

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

А что если ваш код украли и не скопировали точь-в-точь, а переработали?

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

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

Гражданский кодекс РФ подробно не объясняет, что такое переработка. Фактически, переработкой считаются все ситуации, когда на основе чего-то одного создается нечто новое. Переработка литературного произведения — это постановка спектакля по нему.

В отношении переработки кода в законе прямо назван только один пример — перевод с одного языка программирования на другой.

Кейс: полтора миллиона за софт

Московская компания разработала программный комплекс для финансового анализа и управления рисками. В 2017 году она обратилась в Арбитражный суд с претензией к своему бывшему сотруднику: сотрудник после увольнения создал свой сайт, через который продавал очень похожий софт. Он внес доработки в саму программу, в руководство к ней и поменял название.

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

Должностные обязанности

В настоящий момент обязанности инженера-программиста на предприятии прописаны в ЕКСД для трех должностных позиций:

  1. Техник-программист.
  2. Инженер-программист.
  3. Инженер-программист (программист).

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

  • первая — без деления на категории для специалистов воздушного транспорта;
  • вторая — межотраслевая, с категориями и более высокими требованиями к стажу, поскольку программирование — основная профессиональная функция.

Основной вид профессиональной деятельности — разработка, отладка, проверка работоспособности, модификация программного обеспечения. Стандарт содержит четыре обобщенные трудовые функции. Чем большим набором обобщенных функций владеет программист, тем выше должностная позиция. Чем «выше» должность, тем серьезнее требования к образованию, квалификации и практическому стажу — это видно на схеме (цвет должности соответствует цветам функции и квалификации).

По усмотрению работодателя, инструкция разрабатывается на основе:

  • квалификационных характеристик, содержащихся в ЕКСД 2018 (ред. от 01.07.2018);
  • профессионального стандарта 06.001 «Программист»;
  • прав и обязанностей сотрудника, принимаемого на эту должность;
  • внутренних ЛНА.

ВАЖНО!

Раздел «Общие положения» должностной инструкции разработчика, подготовленной на основе стандарта, выглядит следующим образом.

Специалист этой служебной позиции имеет среднее профессиональное образование и повышение квалификации в качестве дополнительного требования. На момент заключения трудового договора его опыт практической работы в области разработки программного обеспечения составляет не менее 6 месяцев.

Два раздела посвящены умениям и знаниям.

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

Как выбрать договор на создание программного обеспечения

Заказчики не всегда понимают отличие между договорами на создание программного обеспечения. Обычно для оформления заказа на разработку программных продуктов используются договор возмездного оказания услуг, договор подряда либо договор авторского заказа (авторский договор).

Договор на услуги в принципе не подходит на данную роль, поскольку его предметом выступает осуществление определенной деятельности, а не создание определенного объекта и передача на него прав. Услуги по определению реализуются и потребляются в процессе их оказания и не имеют материального выражения. Безусловно, в результате оказания услуг может создаваться в том числе программное обеспечение, но такая деятельность является вторичной и, соответственно, права заказчика на такое ПО не защищаются должным образом по договору возмездного оказания услуг.

В отличие от договора на услуги возможность использования для разработки программного обеспечения договора подряда прямо предусмотрена в ст.1296 ГК РФ. Предметом такого договора является выполнение по заданию заказчика определенных работ по созданию конкретного ПО. Результатом работ, в отличие от услуг, всегда выступает определенный материальный объект. В рассматриваемом случае таким результатом является программное обеспечение с необходимыми заказчику характеристиками.

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

Договор авторского заказа также может использоваться для создания программного обеспечения. Однако в отличие от договора подряда на разработку ПО, авторский договор заключается непосредственно с автором, т.е. физическим лицом.Поскольку автор как человек, творческим трудом которого создается программное обеспечение, традиционно считается более слабой стороной в сделке, нежели заказчик, законодательство предоставляет ему ряд преимуществ (см. ст.1288 – 1290 ГК РФ). В частности, по договору авторского заказа права на ПО не переходят автоматически к заказчику, а сохраняются у автора. Поэтому положения о передаче прав на ПО в полном объеме необходимо прямо включать в договор авторского заказа.

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

Таким образом, при выборе конструкции договора необходимо обращать внимание на то, что является непосредственным предметом заказа и кто выступает на стороне исполнителя. Если предмет заказа – конкретное программное обеспечение, договор на услуги не подходит, т.к

последний направлен на деятельность определенного рода, в которой результат имеет вторичную роль. Если исполнителем по договору выступает физическое лицо (автор), то следует заключать договор авторского заказа.

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

Готовое решение для вашего бизнеса

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

В заключение

Пять «белых книг» описывают MSF в мельчайших деталях, давая точные определения ее компонентам, а также подробные описания процессов. 

Тем не менее методология MSF остается гибкой и может легко масштабироваться для использования в корпорациях или стартап-проектах. Она очень демократична по своей сути, но категорически требует одного — отказаться от иерархии и диктатуры в управлении. Любое решение должно быть выработано в коллективе коллегиально, а ответственность распределяется между всеми. Кроме того, MSF поощряет постоянный обмен информацией и накопление коллективного опыта, а также подталкивает каждого члена команды к совершенствованию знаний и повышению квалификации.

Методология не требует применять специализированные средства компании Microsoft. Существуют системы, «заточенные» под MSF, например Visual Studio Team System — и Microsoft прямо призывает организации, использующие ее, следовать MSF. Но ничто не мешает применять MSF с любыми другими средствами организации производства.

Microsoft Solutions Framework используется уже более четверти века, помогая компании Microsoft разрабатывать новые решения и развиваться. И это аргумент в пользу методологии.

Rate article