Книга: Мобильное приложение как инструмент бизнеса
Договор с разработчиками
Договор с разработчиками
Для того чтобы правильно прочитать договор, всего-то и нужны: здравый смысл, логика и немного терпения. Здравый смысл поможет отнестись к тексту критически: если вы три раза прочитали договор и вам все понятно, но в пункте 13.13 вас явно обманывают – скорее всего, вас действительно обманывают.
Если вы думаете, что оплата разработки мобильного приложения автоматически делает его вашим, вы ошибаетесь. Также ошибаетесь, если думаете, что станете автором мобильного приложения, созданного кем-то другим. Я видел договоры, в которых было написано о передаче авторских прав, об их уступке и даже об отказе в чью-то пользу. Вот только по закону авторское право от человека к человеку не передается. Оно вообще не передается, поскольку является личным неимущественным правом, и передать его другому человеку невозможно ни по закону, ни по здравому смыслу. Тот, кто создал приложение, всегда будет его автором.
Презумпция авторства означает, что автором считается тот, кто первым заявил о своем авторстве, до тех пор, пока юридически не будет доказано обратное. Единственно верный способ сделать так, чтобы разработчик мобильного приложения или его частей, то есть автор или авторы, не могли распоряжаться результатами своего труда, – правильно оформить юридические отношения с ними. Заключите договор, в котором будет предусмотрено, что права использование мобильного приложения, созданного разработчиком, принадлежат только вам.
Неверно написанный договор, например, прямо противоречащий действующему законодательству, может быть признан в суде недействительным со всеми вытекающими последствиями. То есть заключая такие договора, вы платите свои деньги и отдаете свои идеи на создание приложение, рискуя все потерять.
Работать без договора, только на основе устных договоренностей, крайне не рекомендуется. Договор не столько инструмент устрашения, сколько помощник в устранении недоразумений. В нем перечислены права и обязанности обеих сторон, что делает работу над приложением более эффективной. Договор способствует выполнению обязательств не только разработчиком, но и заказчиком.
Знаете, чем грешат абсолютно все разработчики мобильных приложений? Срывом сроков. Это обыденное явление в ИТ, и не стоит его бояться. Откровенно говоря, никто не может вам выдать 100 %-ную гарантию соблюдения сроков и качества работ, потому что это физически невозможно. При создании мобильного приложения, как бы детально ни было описано техническое задание, всегда возникает множество проблем, которые разработчик просто не в состоянии предвидеть. И только регулярное и тесное общение с разработчиком поможет вам понять, на какой стадии разработки находится ваше приложение.
Если нет договора, сроки будут сорваны на неопределенное время и никто не понесет за это никакой ответственности. В договоре вы можете указать, при каких обстоятельствах разработчик несет ответственность за срыв сроков работы и какую именно (доработка за своей счет, компенсация).
Если выбранные вами разработчики работают не первый год, у них уже есть стандартный договор. Советую как можно быстрее попросить у них его копию, чтобы отдать юристу на ознакомление. Если стандартного договора по какой-то причине нет, значит, разработчик готов оговаривать условия сделки на взаимовыгодных условиях. Можете предложить ему свой договор.
При ознакомлении с договором всегда помните, что вы не обязаны подписываться под каждым пунктом, предложенным разработчиком. Почти о любом пункте можно договориться, изменив так, чтобы всем было выгодно и удобно. Например, можно изменить формулировку конкретного пункта договора. Единственный пункт, который останется неизменным, – это пункт о необходимости своевременной оплаты разработчику, но даже по этому вопросу можно вести переговоры.
Не стоит слепо полагаться на чутье и опыт юриста. Договор подписываете вы, значит, вы несете ответственность за подписанное. Внимательно читайте каждый пункт, и, если чего-то не понимаете или в чем-то сомневаетесь, обязательно обсудите это со своим юристом и разработчиками. Каждая ваша устная договоренность должна быть четко и понятно сформулирована в договоре. Абсолютно каждая, без исключения. Поэтому к договору часто добавляют приложения, например бриф, техническое задание и подобные дополнения.
Основываясь на своем многолетнем опыте разработки мобильных приложений, наиболее важными пунктами в договоре на создание мобильного приложения я считаю следующие:
1. Передача исключительных прав.
Все права на использование, распространение, модификацию, копирование и любые другие действия должны переходить к заказчику. Особенно это касается исходных программных кодов на само приложение, а также исходных файлов для работы с изображениями, звуками и всем остальным. Получив «исходники», вы получаете возможность в дальнейшем с легкостью модифицировать любую часть приложения на свое усмотрение.
Бывали случаи, когда разработчики передавали все права только на часть интеллектуальной собственности, например только на дизайн. Тогда за разработчиками оставалось законное право продать исходные коды мобильного приложения кому-то иному, без дизайна или создав новый дизайн. Проследите за тем, что вам передали все права, а не часть.
Так как автором все равно остается разработчик, вы должны добавить пункт о праве использования приложения без указания имени автора.
Если вы поменяете разработчика, ни в коем случае не передавайте ему права на использование вашего исходного кода, контента либо приложения. Задача нового разработчика не использовать то, что вам принадлежит, а доделать либо улучшить то, что вы уже имеете.
С точки зрения производства мобильное приложение защищено от копирования намного лучше, чем обыкновенный товар, устройство или услуга. Его код можно надежно зашифровать, так что никто не сможет его разобрать на части и использовать эти самые части для производства своего собственного приложения. Однако если кто-то получит доступ к исходному коду приложения, то сможет создать даже не копию вашего приложения, а точно такое же приложение, как у вас. Или, например, если кто-то получит доступ к отдельным частям исходного кода, то сможет реализовать часть функционала вашего мобильного приложения.
2. Предусматривание ответственности за использование чужих материалов.
Ответственность за использование чужих материалов полностью лежит на разработчике. В противном случае он может незаконно использовать чужой код или другие материалы, а ответственность за это понесете вы.
3. Техническое задание.
Техническое задание должно идти в виде приложения к договору и быть описанным в договоре как часть условий соглашения. В техническом задании, о котором подробнее будет написано далее, вы можете перечислить детальные требования к каждой части мобильного приложения. Таким образом, техническое задание становится частью договора и условием, от которого нельзя отказаться.
4. Условия приема-передачи дизайна.
Дизайн мобильного приложения подписывается отдельным актом приема-передачи и оговаривается в отдельной секции технического задания. Это необходимо, потому что дизайн всегда требуется дорабатывать.
5. Перечень этапов разработки мобильного приложения.
Поскольку разработка мобильного приложения может быть довольно длительным проектом, советую в договоре описать этапы работы и сроки выполнения каждого этапа. Это позволит более эффективно придерживаться сроков выполнения договора.
6. Соглашение о неконкуренции.
Соглашение о неконкуренции должно идти в договоре отдельным пунктом. Например, вы можете указать, что разработчик не может использовать идеи и технологии из вашего мобильного приложения в других приложениях.
Вы не можете заставить разработчика не использовать ваши идеи, но можете дополнительно прописать запрет на использование созданного кода для вашего мобильного приложения в других проектах. По закону разработчик и так не имеет права этого делать, но многие из разработчиков об этом даже не догадываются. Отдельный пункт в договоре напомнит им о том, как это важно.
7. Условия нераспространения информации.
Обязательно оговорите условия нераспространения информации о вашем приложении. Обычно оно называется Non-Disclosure Agreement, что переводится как «договор о конфиденциальности», или «договор о неразглашении информации», в числе которых персональные данные, коммерческая тайна, условия сотрудничества и т. д. Такое соглашение гарантирует, что разработчик не будет рассказывать о своей работе, а также делиться вашими секретами и технологиями со всеми подряд. Важно также, что этот пункт действует и после завершения договора, то есть бессрочно.
8. Результат сотрудничества.
В договоре должна быть указана конкретная сумма и конкретный результат труда, который вы получите за эти деньги. Иначе вы рискуете попасть в постоянное «Доплатите, пожалуйста, и мы все доделаем». Если же исполнитель ошибся суммой, а такое также случается, то всегда можно внести изменения в договор на взаимовыгодных условиях.
Часто заключают договор с использованием почасовой оплаты. В таком случае убедитесь, что есть отдельный пункт, обеспечивающий прозрачный контроль за затраченным разработчиком временем при создании приложения. К примеру, контроль можно осуществлять через сторонний сервис, постоянно следящий за тем, что делает разработчик за своим компьютером, или же видео выполнения работы.
9. Условия оплаты.
Предоплата в разработке программных продуктов – дело естественное, и этого не нужно бояться. На самых ранних этапах разработчики выполняют множество задач, которые остаются за кадром. Об этой работе вы обычно даже не подозреваете, но и она должна быть оплачена. Предоплата позволяет исполнителям качественно работать с самого начала.
Если рассчитываетесь по безналичному расчету, то обычно с подтверждением оплаты проблем не возникает. Если платите наличными, советую получить от разработчика документ, подтверждающий факт оплаты. Документ требуйте в момент оплаты, а не когда-нибудь «завтра». Также на документе должны стоять печать и подпись от компании разработчика.
10. Акт выполненных работ.
Для каждого разработчика наличие акта выполненных работ очень важно. Это документ необходим при налоговых проверках в качестве подтверждения, что все работы по контракту были выполнены и договор считается закрытым. Ни в коем разе не подписывайте акт выполненных работ до того, как все работы будут выполнены, но и не вздумайте шантажировать им разработчика, чтобы он делал то, о чем вы не договаривались. Вам еще наверняка пригодятся его услуги, не нужно портить отношения.
- Техническое задание
- 19.2. Лучшие практические приемы при взаимодействии с разработчиками открытого исходного кода
- Соглашение с пользователями
- Приложение 9 Акт выполненных работ (к Договору на оказание информационных услуг)
- 7.3. Порядок заключения, изменения, расторжения договоров
- 7.6. Классификация договоров. Договоры в сфере рекламы
- Приложение 2 Образец Договора купли-продажи
- ТМ-регламенты и командные договоренности
- Вариант 4. Договориться о бесплатном размещении анонсов в чужих рассылках
- Как применить эти условия договора к своим новым программам
- Как договориться о личной встрече
- ГЛАВА 7 ГРАЖДАНСКО-ПРАВОВЫЕ ОТНОШЕНИЯ РЕКЛАМОДАТЕЛЕЙ, РЕКЛАМОПРОИЗВОДИТЕЛЕЙ И РЕКЛАМОРАСПРОСТРАНИТЕЛЕЙ. ДОГОВОРЫ В СФЕРЕ...