Чек-лист договора подряда для разработки ПО: на что смотрим

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

Про служебные произведения подробнее здесь.

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

Наличие каких условий проверяем в договоре подряда на разработку ПО:

Нужно достаточно подробно указать, что будет создавать подрядчик. Если ПО сложное, можно составить техническое задание.

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

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

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

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

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

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

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

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

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

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

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

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

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

Как итог: в бюджет вы заплатите больше налогов, чем могли бы.

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

Сроки могут указываться по-разному:

- указание срока, к которому все будет выполнено,

- указание сроков по каждому этапу и когда все будет выполнено.

Рецепта, как правильно указывать сроки, – нет.

Однако я часто сталкивалась с такой ситуацией: указаны календарные сроки выполнения каждого этапа (например, первый этап - до 21 декабря 2018 года, второй - до 17 января 2019 года), а потом подрядчик не укладывается в один этап, потому что заказчик не согласовывает быстро или быстро не предоставляет информацию, материалы. В итоге: все сроки поехали, негодование заказчика растет, и он начинает обвинять подрядчика в срыве сроков, угрожать расторжением договора, судом.

Вариантом решения может быть: указывать сроки выполнения этапов, но делать оговорку в договоре (или дополнительно в техническом задании), что (1) сроки согласования заказчиком промежуточного результата не включаются в сроки выполнения работ, и (2) сроки, установленные для подрядчика, продлеваются, если заказчик не предоставляет информацию/не согласует что-то в течение [●] дней.

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

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

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

Связано это с тем, что такие лицензии подразумевают определенные ограничения по использованию объектов, которые создаются с их помощью (коммерческое/не коммерческое использование, предоставление/непредоставление исходного кода программы, созданной с использованием таких лицензий). США и Европе известны споры, связанные с нарушениями использования копилефтных лицензий, и большими суммами штрафов по итогу.

В России таких споров я пока не видела. Но если вы разрабатываете для иностранной компании, или наоборот – вы иностранная компания - заказчик, стоит поразмыслить над этим условием. Или, как минимум, попросить у подрядчика список лицензий, который тот использовал при выполнении проекта, чтобы хотя бы просто знать.

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