Топ-6 выводов участников онлайн-семинара «Разработка программного обеспечения: юридический аспект»

1. Договор на разработку ПО — договор подряда.

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

Иногда выдвигается мнение, что разработка ПО — договор возмездного оказания услуг, но эта позиция скорее ошибочна. Возмездное оказание услуг — процесс, тогда как сторонам нужен результат в виде некоего продукта. 

2. Всегда нужно четко делить работы на этапы.

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

Это позволит, во-первых, четко понять, к чему идет разработка, то есть разрабатывается ли то, что нужно, а во-вторых, в случае спора упростит заказчику доказывание необходимости оплаты фактических затрат подрядчика. 

3. Договор подряда + передача исключительных прав.

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

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

4. Акт приема-передачи НЕ на 300 страниц.

Как уже было сказано, ПО — комплексный продукт, включающий различные элементы, которые как-то нужно указать в акте приема-передачи. В акте в общих случаях указывается товар или передаваемое имущество. И чтобы этот акт не был на 300 страниц, перечисляя каждый элемент от кода до кнопок и элементов дизайна, в акте можно указывать реализованные задачи, отраженные в техническом задании на разработку. 

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

5. Привлекайте бухгалтерию.

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

6. Гарантия на ПО.

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

Однако не следует забывать, что срок исковой давности по договору подряда довольно короткий — год (ст. 678 ГК). Поэтому заказчику не стоит затягивать с предъявлением претензий хотя бы формально, если разработчик не хочет исправлять ошибки в продукте.