Знакомая история: проект вроде бы сдан, заказчик доволен, а потом начинается — «тут поправь, здесь добавь кнопку, а давай ещё вот это переделаем». Через месяц ты понимаешь, что бесплатно отработал ещё половину проекта, а оплату за основную часть до сих пор не получил целиком. И самое обидное — формально возразить нечем, потому что в договоре про объём правок не сказано ни слова, а права на код ты уже отдал.
Разработчики часто относятся к юридической части как к формальности: главное же код написать. Но именно эта часть решает, получишь ты деньги полностью или будешь месяцами доделывать даром. Причём закон в базовой конфигурации на твоей стороне — права на написанный код изначально твои. Вопрос в том, как грамотно ими распорядиться. Разберём по-честному: когда права переходят заказчику, как привязать их к оплате, как остановить бесконечные правки и не потерять собственные наработки.
Материал открывает подборку для исполнителей в разделе «Юридическая и бухгалтерская помощь». Рядом — что делать, если заказчик не платит, и как работать с зарубежными клиентами.
Что ты узнаешь из статьи
- Кому по умолчанию принадлежат права на написанный тобой код
- Как привязать переход прав к полной оплате и почему это работает
- Как зафиксировать объём правок и прекратить бесплатные доработки
- Как не потерять права на свои библиотеки и наработки
- Зачем нужен акт и как он защищает при споре об оплате
Кому принадлежат права на твой код
Начнём с приятного: по закону исключительное право на написанный код изначально возникает у автора — то есть у тебя. Оплата работы сама по себе это право заказчику не передаёт. Он получает права только тогда, когда договор прямо об этом говорит. Многие заказчики этого не знают и искренне считают, что раз заплатили, то владеют всем автоматически.
Отсюда следует важный вывод: у тебя есть законный рычаг, о котором стоит помнить при переговорах. Права переходят на тех условиях, которые согласованы в договоре, и ты вправе предложить конструкцию, защищающую твои интересы. Самая рабочая — привязать момент перехода исключительного права к полной оплате по договору. Пока деньги не получены, права остаются у тебя. Это дисциплинирует заказчика лучше любых напоминаний.
Чтобы всё это работало, нужен нормальный правовой статус — с безымянным исполнителем без документов заказчик просто не станет заключать договор. Если ещё не разобрался, что выбрать, посмотри разбор, как оформить статус самозанятого или ИП: без него ты ограничен и в договорах, и в потоке серьёзных клиентов.
Как остановить бесконечные правки
Главная дыра в бюджете фрилансера — не низкая ставка, а неоплаченные доработки. Схема всегда одна: договорились на проект, ТЗ было устным или размытым, и теперь любое пожелание заказчика подаётся как «ну это же мелочь, доделай». Мелочей набирается на недели работы, а денег за них нет, потому что границы согласованного никто не проводил.
Лечится это в договоре, а не в переписке. Зафиксируй объём работ по конкретному техническому заданию — что именно входит в проект. Отдельно пропиши количество итераций правок, включённых в стоимость: например, две-три раунда доработок по согласованному ТЗ. И главное — укажи, что всё, выходящее за рамки ТЗ, оформляется как отдельная оплачиваемая работа с новой оценкой.
После этого разговор с заказчиком меняется полностью. Вместо неловкого «ну я не хочу спорить» у тебя есть документ: вот ТЗ, вот что в него входило, вот новая задача — она оценивается отдельно. Это не жадность, а нормальная деловая практика, и адекватные клиенты воспринимают её спокойно. А вот если оплата всё равно зависает, действовать нужно уже иначе — разбор про то, что делать, если заказчик не платит, стоит держать под рукой заранее.
Не отдай свои наработки целиком
У опытного разработчика всегда есть своя база: готовые модули, библиотеки, шаблонные решения, накопленные за годы. Именно они позволяют делать проекты быстрее конкурентов. И вот тут прячется ловушка, о которой мало кто думает: если в договоре записано отчуждение исключительных прав на весь результат работ без оговорок, ты можешь формально лишиться права использовать собственный наработанный код в следующих проектах.
Решение простое, но его нужно прописать заранее. Раздели в договоре то, что создаётся специально под проект заказчика, и то, что является твоими предсуществующими наработками. На первое — отчуждение прав, если так договорились. На второе — неисключительная лицензия: заказчик получает право пользоваться модулем в рамках своего продукта, а ты сохраняешь возможность применять его дальше. Эта короткая оговорка защищает твой главный профессиональный актив.
Зачем нужен акт и как он спасает
Акт приёма-передачи кажется бюрократией ровно до первого конфликта. Его смысл в том, что он фиксирует факт: работа сдана в согласованном объёме, результат принят, права переданы. Пока акта нет, заказчик всегда может заявить, что работа не сделана или сделана не так, и разговор об оплате уходит в бесконечное «мне не нравится».
Подписанный акт переводит спор в другую плоскость. У тебя на руках документ, подтверждающий выполнение обязательств, и на него можно опереться и в переговорах, и в претензии, и в суде. Заодно акт закрывает вопрос с правками: всё, что заказчик просит после подписания, — уже новая работа за отдельные деньги, и это очевидно из документов, а не из твоих слов.
Отдельная тема — работа с зарубежными клиентами, где к акту добавляются валютные и налоговые нюансы. Если такие заказы уже появляются или планируются, посмотри разбор про договор с иностранным заказчиком: там своя специфика оформления и получения оплаты.
Как платформа помогает работать спокойно
На Где.Эксперт ты получаешь доступ к заказчикам, которые ищут исполнителя осознанно и готовы работать по нормальным правилам, а не «на честном слове в мессенджере». Условия сделки фиксируются заранее, оплата закреплена в заказе — то есть предмет и сумма понятны обеим сторонам до начала работы, и почвы для «доделай ещё бесплатно» становится заметно меньше.
Модель площадки честная к исполнителю: без депозита и обязательных взносов за доступ к заказам, оплата по факту выполненной работы, а расчёты защищены механизмом разрешения споров. Ты сам выбираешь заказы и формируешь цену, а отзывы прошлых клиентов копятся в профиле и приводят новых. Чем прозрачнее оформлены отношения на старте, тем реже приходится выяснять, кому принадлежит код и кто кому что должен за правки.
Часто задаваемые вопросы
Когда права на код переходят заказчику?
Только если это прописано в договоре. По умолчанию право у автора. Разумно привязать переход к полной оплате — пока не оплачено, права твои.
Можно ли отдать только лицензию?
Да, если заказчик согласен и это в договоре. Лицензия оставляет исключительное право у тебя и подходит для наработок, которые планируешь переиспользовать.
Как остановить бесплатные правки?
Зафиксируй объём по ТЗ и число итераций в цене. Всё сверх ТЗ — отдельная оплачиваемая доработка с новой оценкой.
Что с моими библиотеками?
Раздели в договоре созданное под проект и свои предсуществующие наработки. На вторые давай лицензию, а не отчуждение, иначе рискуешь потерять свой же код.
Нужен ли акт?
Обязательно. Он фиксирует сдачу работы и передачу прав, защищает при споре об оплате и отсекает бесплатные правки после приёмки.
Заключение
Юридическая сторона для разработчика — это не бумажки ради бумажек, а прямая защита заработка. Главное, что стоит запомнить: права на код изначально твои, и переходят они только на тех условиях, которые ты согласуешь. Привязка перехода прав к полной оплате, зафиксированный объём работ по ТЗ и оговорённое число правок закрывают три самые дорогие дыры в бюджете фрилансера.
Не отдавай отчуждением собственные наработки — на них давай лицензию. Подписывай акт, он превращает спорную ситуацию в задокументированную. А чтобы не выстраивать эту защиту заново с каждым новым клиентом, разумнее работать там, где условия и оплата зафиксированы в самом заказе, расчёты защищены, а деньги приходят по факту выполненной работы — без депозитов и вложений на старте.
Начни брать заказы на Где.Эксперт — работай по прозрачным условиям и получай оплату по факту.