Договор доработка 1с

Рубрики Статьи

Авторское право на доработки типовой конфигурации

>Как это прописать в договоре?

зачем? исключительные права принадлежат заказчику если не указано иного

>если он этот код будет другим толкать под соусом того что разработал под них то же самое решение с нуля?

суд и франь будет возмещать ущерб

у ПО есть исходники, документация и тп — это все принадлежит заказчику

(25) >Если тебе для решения проблемы некий франч тупо накопипастит некое типовое решение Франч:Нетленка, то оно будет в своем праве даже не продавая тебе ее как продук

так это уже его ПО, он продает лицензию на право пользования. а это не ситуация из (0)

(5) > исходный код типовых не при чем вопрос звучит именно про доработку а не разработку целиком.

доработка — использования типовой функциональности, которую написала 1с, у которой исключительные права на своё детище
=> у тебя должен быть договор 1с

какие проблемы его повторить ?

(64) стоимость договора тогда должна быть далеко за 500 000 🙂

Чтобы от целой отрасли потенциальных клиентов отказаться

У меня такие были клиенты: с одной стороны выспрашивали как другие решают те или иные проблемы, а с другой стороны просили не продавать мой продукт больше никому:)

Причём покупали у меня именно готовый продукт

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

франчи пусть пишут в 1С обертку для компоненты.

компоненту соответственно защищайте.
оформляйте как вашу разработку, регистрируйте и тд и тп..

вот тогда да — есть ваш продукт и он защищен..

но опять же. это сработает в примерах типа (22)

(73) Еще про патенты в штатах:

А случилось следующее. Во время войны в Лос-Аламосе был один замечательный парень, ответственный за правительственное патентное бюро. Его звали капитан Смит. Он разослал всем циркуляр, в котором говорилось что-то вроде: «Мы в патентном бюро будем рады запатентовать любую вашу идею для правительства Соединенных Штатов, на которое вы сейчас работаете. Любую идею по ядерной энергии или ее применению, которую, как вам кажется, знает каждый. Это не так. Каждый не знает о ней. Просто зайдите ко мне в кабинет и расскажите о своей идее».
Я вижу Смита во время ланча и по дороге назад в техническую зону говорю ему: «Этот циркуляр, который Вы разослали всем – это же просто безумие – прийти и рассказывать о каждой идее».
Мы обсудили это вдоль и поперек – к этому времени мы уже были у него в кабинете, и я говорю: «У меня столько идей по ядерной энергии совершенно очевидных, что мне придется провести весь день здесь, выдавая их одну за другой».
– НУ, НАПРИМЕР?
– А, чепуха, – говорю я. – Пример первый: ядерный реактор… под водой… вода поступает внутрь… пар идет с другой стороны… Пшшш – это подводная лодка. Или: ядерный реактор… воздух врывается спереди… нагревается ядерной реакцией… выходит сзади… Бум! По воздуху – это самолет. Или: ядерный реактор… через него проходит водород… Зум! – это ракета. Или: ядерный реактор… только вместо того, чтобы использовать обычный уран, используется обогащенный уран с окисью берилия при высоких температурах, чтобы было эффективней… это – атомная электростанция. Миллион идей! – сказал я, выходя за двери.
Ничего не произошло.
Через три месяца Смит звонит мне в кабинет и говорит: «Фейнман, подводную лодку уже взяли. Но остальные три – Ваши». Вот почему, когда парни из авиастроительной компании в Калифорнии запланировали свою лабораторию и попытались найти специалиста по всяким реактивным штуковинам, – нет ничего проще, – они смотрят, кто взял патент!

Договор доработка 1с

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

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

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

Проект идет полным ходом. Проведено проектирование, подготовлено ТЗ, начато его согласование. Как это часто бывает, Заказчик не спешит с согласованием проектной документации. ИТ компания принимает решение начать разработку на основе еще несогласованного ТЗ на свой страх и риск. Остается чуть более двух недель до завершения работ по разработке и ТЗ наконец-то согласовано. Сроки сдачи работ при этом официально сдвинуты не были. Было уже понятно, что в определенный договором срок уложиться не удастся. Одним из требований заказчика было начать работать в новой системе сразу после новогодних праздников. Исполнитель решил рискнуть, начать эксплуатировать часть подсистем созданного программного решения как планировалось, т.е. сразу после новогодних праздников, выполнив для этого во время новогодних каникул подготовительные работы. Но как это обычно бывает в подобной ситуации, белый пушистый зверек подкрался незаметно. Пойдя на поводу ИТ компания недооценила инертность специалистов заказчика, а также взяла на себя обязательства выполнить ряд работ не оговоренных в договоре, задействовав для этого часть ресурсов занятых разработкой, что в свою очередь снизило ее скорость. А возникшие проблемы в ходе опытной эксплуатации реализованных подсистем переключили оставшуюся часть разработчиков на тушение пожаров. Разработка остального функционала фактически встала. Возник кризис управления внутри проектной команды исполнителя. Взаимоотношения с заказчиком стали усугубляться.

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

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

Выявленные ошибки

Первая ошибка – обтекаемо сформулирован предмет договора. Но был сформулирован следующим образом «…Заказчик поручает, а Исполнитель принимает на себя обязательства по поставке и внедрению программного обеспечения 1С: Предприятие 8 согласно Приложения №2…». Приложение 2 содержало мало конкретики, по форме это была спецификация с указанием видов работ и трудозатрат по ним. Каждая из сторон по-своему трактовала предмет договора. Компания исполнитель понимала под этим доработку стандартной конфигурации 1С: Предприятие под задачи заказчика, ее настройку и внедрение. Заказчик видел то, что будет произведена установка и настройка 1С: Предприятие без какой-либо ее модификации. Он исходил из буквального значения слов и выражений зафиксированных в договоре, такой же точки зрения придерживался суд, игнорируя факт создания составного программного продукта в рамках выполнения обязательств по договору.

Немного судебной практики:
Статья 431 ГК РФ при толковании условий договора судом принимается во внимание буквальное значение содержащихся в нем слов и выражений. Буквальное значение условия договора в случае его неясности устанавливается путем сопоставления с другими условиями и смыслом договора в целом.

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

Третья ошибка – отсутствие подробного технического задания. Созданное в процессе выполнения работ ТЗ на разработку конфигурации на базе стандартной конфигурации 1С: Предприятие 8 было не достаточно хорошо проработано. Оно содержало только общие сведения о создаваемой конфигурации, а также имело ссылки на функционал (печатные формы, некоторые алгоритмы работы и т.д.) существовавшей ранее у заказчика информационной системы, и которая продолжала в этот момент эксплуатироваться в силу того, что новая информационная система еще не была полностью готова. За время проекта существующая ИС еще и продолжала модифицироваться специалистами заказчика. Соответственно исполнителю приходилось вносить модификации в создаваемую ИС с учетом модификаций старой системы. Все это в совокупности привело к трудностям при сдаче работ.

Четвертая ошибка – исполнитель согласился на требования заказчика внести ряд условий в договор явно не выгодных для себя, но поскольку сроки поджимали и представители заказчика не хотели договариваться по условиям договора руководство ИТ компании приняло решение пойти по пути наименьшего сопротивления. Напомню, это был конец 2014 г., санкции, отсутствие других заказов и т.д, картина типичная для многих небольших ИТ компаний, которые хватаются за любую работу и руководствуются принципом «главное начать, а там просмотрим». Условия договора были сформулированы таким образом, что за каждый день просрочки выполнения работ исполнитель должен был выплатить крупную неустойку. Через некоторое время размер неустойки вырос до такого уровня, что рентабельность проекта стала практически нулевой и неуклонно стремилась стать минусовой. Этому способствовала слабая организация работ внутри проекта, и неспособность оперативно справиться с возникшими проблемами проекта из-за нехватки ресурсов, которые были рассчитаны исходя из прогнозируемого по условиям договора объема работ, и не были рассчитаны на его увеличение. С учетом кабальных условий приходилось идти на компромисс с заказчиком и выполнять все его пожелания. Также ситуация усугубилась за счет того, что для продолжения проекта требовалось внешнее финансирование, привлечение которого было сильно затруднено.

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

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

Немного судебной практики:
Пункт 3 статьи 75 АПК РФ гласит, что документы, полученные посредством факсимильной, электронной или иной связи, в том числе с использованием информационно-телекоммуникационной сети «Интернет», а также документы, подписанные электронной подписью или иным аналогом собственноручной подписи, допускаются в качестве письменных доказательств в случаях и в порядке, которые установлены договором.

Постановление Федерального арбитражного суда Московского округа от 17 мая 2013г. по делу N А40-102005/12-57-977 отказывая истцу в удовлетворении его требований, суд указал на:

• предусмотренную договором простую письменную форму документооборота между сторонами;
• отсутствие условий о возможности исполнения договора по электронной переписке;
• отсутствие ссылок на электронные адреса, определяемые сторонами в качестве допустимых для передачи какой-либо информации;
• невозможность установить принадлежность адреса ответчику и его сотрудникам;
• адрес электронной почты зарегистрирован на домене kameya.ru, который является доступным для использования неограниченным кругом лиц.
Постановлением ФАС дальневосточного округа от16.11.12 №Ф03-5177/2012 был отклонен довод Истца о передаче спорных претензий ответчику по электронной почте. Причинами такого вывода суда послужили как не предоставление доказательств согласования сторонами использования электронных документов в претензионном порядке по спорному договору так и тот факт, что передача претензий по электронной почте не свидетельствует об их получения истцом.

  • Четко формулируйте предмет договора, чтобы исключить двусмысленное его понимание;
  • Техническое задание или документ его заменяющий, формируйте так, чтобы у сторон договора было единое понимание о том, как должно функционировать создаваемое ПО, как должен выглядеть пользовательский интерфейс, система отчетов, какие технологии должны быть использованы при создании ПО и т.д.;
  • Указывайте реально осуществимые сроки выполнения работ с учетом времени, необходимого на согласования проектной документации и приемо-сдаточные мероприятия. Предусматривайте увеличение сроков выполнения работ, на случай задержек со стороны заказчика сроков согласования проектной документации или выполнения работ находящихся в его зоне ответственности, а также его ответственность за подобные действия или бездействия;
  • Описывайте порядок сдачи работ, документально фиксируйте сам факт передачи заказчику результата работ и документации по проекту (проектной, первичной и т.д.).
  • Описывайте порядок коммуникаций, каким образом будет вестись переписка при выполнении работ, указывайте ФИО уполномоченных лиц, их адреса электронной почты, телефоны. Просите подтверждения наличия полномочий у доверенных лиц (доверенность, приказ о наделении полномочиями).
  • Кроме того, при заключении договора или при его исполнении рекомендуем избегать прямых ссылок на ГОСТы или иные нормативные документы, это поможет избежать злоупотреблений со стороны заказчика, если созданное вами ПО или проектная документация не будет полностью соответствовать требованиям ГОСТов, если конечно это явно не предусмотрено договором.
  • И последняя рекомендация, не поддавайтесь на давление со стороны заказчика ни в момент заключения договора, ни в процессе его исполнения, не соглашайтесь на заведомо не выгодные для вас условия. Лучше откажитесь от контракта, сэкономите нервы и деньги. Работайте только с теми, кто готов выполнять свои обязательства, ну и конечно сами их выполняйте.
Читайте так же:  Жалоба отравление продуктами

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

Договор на разработку (доработку) конфигурации программного продукта «1С»

на разработку (доработку) конфигурации программного продукта «1С»

г. Иваново «___» ____________ 20__ г.

__________________________________________________, именуемое в дальнейшем «Заказчик», в лице ________________________________________________________ действующего на основании ___________________________________________________________, с одной стороны

и индивидуальный предприниматель , именуемый в дальнейшем «Исполнитель», действующий на основании свидетельства о государственной регистрации серия 37 № 000 от 01.01.2001 г., выданного г. Иваново, с другой стороны, вместе именуемые «Стороны», а индивидуально — «Сторона», заключили настоящий договор подряда (далее по тексту – «Договор») о нижеследующем:

1.1. По настоящему Договору Исполнитель обязуется по заданию Заказчика в установленный Договором срок выполнить работы, указанные в п. 1.2. Договора (далее по тексту – Работы), а Заказчик обязуется принять результат Работ и уплатить обусловленную Договором цену.

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

1.3. Сроки выполнения Работ указаны в «Календарном плане работ» (Приложение к Договору), являющимся неотъемлемой частью настоящего Договора.

1.4. Исключительные права на результаты Работ переходят к Заказчику после полной оплаты выполненных работ Исполнителю.

2. Срок действия договора

2.1. Настоящий Договор вступает в силу с даты подписания и действует до полного исполнения Сторонами принятых на себя обязательств.

3. Права и обязанности сторон

3.1. Заказчик обязуется:

3.1.1. Утвердить техническое задание на выполнение Работ.

3.1.2. Предоставить Исполнителю все необходимые материалы для проведения Работ в сроки, указанные в настоящем Договоре.

3.1.3. Оплатить Исполнителю выполнение Работ на условиях и в порядке, установленных Договором.

3.1.4. При обнаружении отступлений от Договора, ухудшающих результат Работ, или иных недостатков в Работах немедленно заявить об этом Исполнителю.

3.2. Исполнитель обязуется:

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

3.2.2. Своевременно устранить недостатки и дефекты, выявленные при приемке Работ и в течение гарантийного срока.

3.2.3. Немедленно предупредить Заказчика и до получения его указаний приостановить Работы при обнаружении:

— возможности неблагоприятных для Заказчика последствий выполнения его указаний о способе выполнения Работ;

— отрицательного результата или нецелесообразности дальнейшего проведения Работ;

— иных, не зависящих от Исполнителя обстоятельств, которые грозят годности результатов выполняемых Работ либо создают невозможность их завершения в срок. Вопрос о целесообразности продолжения Работ решается Сторонами в течении 5 (Пяти) рабочих дней со дня получения Заказчиком уведомления о приостановлении Работ.

3.2.4. Исполнитель вправе не приступать к работе, а начатую работу приостановить в случаях, когда Заказчик нарушает свои обязательства, предусмотренные настоящим Договором.

4. Сроки выполнения работ

4.1. Сроки выполнения Работ определяются поэтапно в «Календарном плане работ» (Приложение к Договору), являющимся неотъемлемой частью Договора.

4.2. Перенос сроков начала и окончания Работ на период просрочки исполнения Заказчиком встречных обязательств, предусмотренных п.3.1.3 Договора, дополнительно согласовывается Сторонами.

5. Стоимость Работ и порядок расчетов

5.1. Стоимость Работ по Договору составляет ______________ (__________ рублей 00 копеек), рублей. НДС не облагается, в связи с применением упрощенной системы налогообложения (УСН). Стоимость Работ по Договору определена Сторонами в «Протоколе согласования договорной цены» (Приложение к Договору), являющимся неотъемлемой частью Договора.

5.2. Оплата по Договору производится в следующем порядке: в течении 10 (Десяти) рабочих дней со дня подписания Договора Сторонами Заказчик осуществляет предварительную оплату этапа Работ в размере 50% (Пятьдесят) процентов от стоимости этапа Работ на основании счета Исполнителя. Оставшуюся часть стоимости этапа Работ Заказчик оплачивает в течении 10 (Десяти) рабочих дней с момента подписания Сторонами акта сдачи-приемки этапа Работ в соответствии с условиями Договора.

5.3. Способ оплаты по Договору производиться путем передачи Заказчиком наличных денежных средств Исполнителю.

6. Порядок сдачи и приемки Работ

6.1. Исполнитель передает Заказчику результаты Работ в срок, указанный в Календарном плане.

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

6.2.1. Исполнитель по завершении выполнения Работ (этапа Работ) в сроки, установленные в п. 4.1 Договора, предоставляет Заказчику два экземпляра акта сдачи-приемки выполненных Работ.

6.2.2. Заказчик обязан в течении 10 рабочих дней со дня получения документов, указанных в п.6.2.1. Договора, принять выполненные Работы (результат Работ), подписать и вернуть Исполнителю один экземпляр акта сдачи-приемки Работ или направить Исполнителю мотивированный отказ от приемки Работ. По истечении указанного срока, при отсутствии мотивированного отказа Заказчика, Работы считаются принятыми Заказчиком и подлежащими оплате на основании одностороннего акта, составленного Исполнителем.

6.3. При досрочном выполнении Исполнителем Работ Заказчик обязан принять и оплатить эти Работы на условиях Договора.

7. Гарантия качества работ

7.1. Гарантия качества распространяется на все Работы, выполненные Исполнителем по Договору.

7.2. Гарантийный срок Работ устанавливается 3 (Три) месяца с даты подписания Сторонами конечного акта сдачи-приемки выполненных Работ.

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

7.4. Срок обнаружения ненадлежащего качества результатов Работ Заказчиком устанавливается в пределах гарантийного срока.

8. Ответственность сторон

8.1. За нарушения обязательств по данному Договору Стороны несут ответственность в соответствии с действующим законодательством Российской Федерации.

8.2. В случае несоответствия результатов Работ характеристикам, указанным в Техническом задании, Заказчик вправе потребовать от Исполнителя устранения указанных недостатков.

8.3. При установке программного обеспечения ответственность за невыполнение условий лицензионных соглашений возлагается на Заказчика.

8.4. В случае несвоевременной оплаты выполненных Работ Заказчиком Заказчик уплачивает Исполнителю пеню в размере 0,1% (Ноль целых одна десятая процента) от невыплаченной суммы за каждый день просрочки.

8.5. В случае нарушения сроков выполнения работ и передачи результатов Работ Заказчику Исполнитель уплачивает Заказчику пеню в размере 0,1% (Ноль целых одна десятая процента) от стоимости невыполненных своевременно Работ.

9. Основания и порядок расторжения договора

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

9.2. Расторжение Договора в одностороннем порядке производится по письменному требованию Сторон в течении 5 (Пяти) рабочих дней со дня получения Стороной такого требования.

9.3. Заказчик вправе расторгнуть Договор в одностороннем порядке в случаях:

9.3.1. В любое время до сдачи Заказчику результата Работ, уплатив Исполнителю часть установленной Договором стоимости Работ, пропорционально выполненной части Работ, до получения извещения об отказе Заказчика от исполнения Договора.

9.4. Исполнитель вправе расторгнуть Договор в одностороннем порядке в случаях:

9.4.1. Существенного увеличения стоимости Работ или необходимости проведения дополнительных работ и отказа Заказчика от заключения дополнительного соглашения об увеличении стоимости Работ.

9.4.2. Задержка Заказчиком оплаты выполненных Работ более чем на 10 (Десять) рабочих дней.

10. Разрешение споров и разногласий

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

10.2. Претензионные письма направляются Сторонами нарочным, заказным почтовым отправлением с уведомлением о вручении последнего адресату, либо доставляются лично по юридическим (почтовым) адресам Сторон, указанным в п.15 Договора, с получением под расписку соответствующими должностными лицами.

10.3. Допускается направление Сторонами претензионных писем иными способами: по факсу либо на электронный почтовый ящик, указанными в п.15 Договора. Такие претензионные письма имеют юридическую силу, в случае получения Сторонами их оригиналов способом, указанным в п. 10.2 Договора.

10.4. При не урегулировании споров и разногласий путем переговоров с применением претензионного порядка, они подлежат разрешению в судебном порядке в Арбитражном суде г. Иваново.

11. Условия конфиденциальности.

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

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

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

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

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

12.2. При наступлении обстоятельств, указанных в п.12.1 настоящего Договора, каждая Сторона должна без промедления (не позднее 3 (Трех) рабочих дней) известить о них в письменном виде другую Сторону. Извещение должно содержать данные о характере обстоятельств, а также официальные документы, удостоверяющие наличие этих обстоятельств, и, по возможности, дающие оценку их влияния на возможность исполнения Стороной своих обязательств по данному Договору. Достаточным подтверждением возникновения и существования обстоятельств непреодолимой силы будет являться справка, выданная компетентным органом Государственной власти/управления Российской Федерации.

12.3. Если Сторона не направит или несвоевременно направит извещение, предусмотренное в п.12.2 настоящего Договора, то она обязана возместить другой Стороне понесенные последней убытки.

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

12.5. Стороны признают, что неплатежеспособность Сторон не является форс-мажорным обстоятельством.

13.1. Стороны не имеют никаких сопутствующих устных договоренностей. Содержание текста Договора полностью соответствует действительному волеизъявлению Сторон.

13.2. Вся переписка по предмету Договора, предшествующая его заключению, теряет юридическую силу со дня заключения Договора.

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

13.4. Во всем остальном, что не предусмотрено договором, стороны руководствуются законодательством РФ.

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

13.6. Все уведомления и сообщения в рамках настоящего Договора должны направляться Сторонами друг другу в письменной форме.

13.7. Договор составлен в 2 (Двух) подлинных экземплярах на русском языке, имеющих равную юридическую силу, по одному для каждого из Сторон.

14. Список приложений

14.1. Приложение – Техническое задание.

14.2. Приложение – Календарный план работ.

14.3. Приложение – Протокол согласования договорной цены.

15. Адреса, реквизиты и подписи сторон

Гражданско-правовые договоры в сфере IT: способы приобретения прав на софт. Часть 2

Екатерина Соколова, руководитель юридического отдела, группа компаний CUSTIS

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

Ситуация 2. Программное обеспечение пока не существует

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

Читайте так же:  Налог на имущества для ооо в 2019 году

Договор на создание ПО (на разработку ПО, на выполнение работ по разработке/созданию ПО)

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

Стороны договора: исполнитель (реже — подрядчик) — заказчик.

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

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

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

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

Важным отличием договора на создание ПО (и иных договоров, которые будут рассмотрены ниже) от договоров, описанных в первой части статьи, является то, что цена договора может быть определена соответствии с п. 3 ст. 424 ГК РФ (как цена, которая при сравнимых обстоятельствах обычно взимается за аналогичные работы). Таким образом, при отсутствии в договоре условия о цене договор все равно будет считаться заключенным, хотя на практике сложно встретить договор на создание ПО, в котором не была бы определена стоимость работ. Цена работ может определяться как в виде фиксированной суммы, рассчитанной экспертно на основании сметы или планируемой трудоемкости работ, так и в виде оплаты на основании почасовки (системы Time & Materials ) — по реальной трудоемкости работ исполнителя. Второй способ, конечно, зачастую менее выгоден заказчику работ, поскольку, во-первых, вносит неопределенность в сумму затрат, а во-вторых, может вызвать у недобросовестного исполнителя соблазн завысить реальную трудоемкость работ. Однако этот способ может оказаться выигрышным при изначально непонятном объеме работ при условии полного доверия заказчика исполнителю либо наличию эффективных средств контроля трудозатрат исполнителя компетентными сотрудниками заказчика. К таким средствам контроля можно отнести регулярную фиксацию исполнителем трудозатрат в системе ведения дел, предоставление исполнителем отчетов с определенной периодичностью, наличие возможности у заказчика приостановить работы при превышении некоторой трудоемкости их выполнения и т. д.

Поскольку создание ПО не является льготируемой по НДС деятельностью, стоимость работ облагается НДС в общем порядке.

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

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

Также интересный нюанс заключается в формулировках о правах. Исходя из формулировки ст. 1296 ГК РФ, исключительное право не передается от стороны стороне, а принадлежит какой-либо из сторон с момента создания ПО. Формулировка о передаче исключительного права признается в силу ст. 1296 ГК РФ налоговыми органами некорректной (см., например, письмо УФНС по г. Москве от 11 августа 2008 г. № 19-11/75222). Чтобы избежать лишних вопросов и просто грамотнее составить договор, рекомендуем использовать формулировку, предусмотренную ГК РФ, и не писать про передачу исключительного права, коей здесь нет.

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

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

Налоговые последствия:

стоимость договора полностью облагается НДС. Согласно указанному выше письму УФНС по г. Москве, разделение цены договора на две части: за создание ПО (облагается НДС) и передачу исключительного права от исполнителя заказчику (не облагается НДС) — является незаконным;

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

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

Договор авторского заказа (авторский договор)

Стороны договора: автор — заказчик.

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

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

Примечательно, что в ст. 1288 ГК РФ, регулирующей договор авторского заказа, законодатель использует термин «отчуждение исключительного права», в отличие от редакции ст. 1296 ГК РФ, которая говорит о том, что исключительное право принадлежит заказчику с момента создания. Указанная формулировка может ввести в заблуждение относительно момента возникновения у заказчика исключительного права на ПО в случае, если оно переходит к нему по договору. Однако и в этом случае исключительное право на создаваемое ПО по умолчанию принадлежит заказчику с момента создания объекта, поскольку п. 4 ст. 1234 ГК РФ говорит о том, что «исключительное право на результат интеллектуальной деятельности … переходит от правообладателя к приобретателю в момент заключения договора об отчуждении исключительного права, если соглашением сторон не предусмотрено иное», п. 3 же ст. 1288 ГК РФ говорит о том, что к договору авторского заказа применяются положения о договоре отчуждения исключительного права, если исключительное право отчуждается в пользу заказчика. Однако в момент заключения договора ПО еще не создано и исключительного права на такой несозданный объект, конечно, нет. Таким образом, исключительное право на ПО возникает с момента его создания при условии, что к тому времени заключен договор авторского заказа. Получается, что, несмотря на разные формулировки, п. 1 ст. 1296 ГК РФ и п. 2 ст. 1288 ГК РФ говорят об одном и том же.

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

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

Ввиду формулировок о том, что к договору авторского заказа применяются правила о договоре отчуждения исключительного права либо лицензионного договора, встает вопрос: необходимо ли разделять вознаграждение автора на две части —за создание объекта и за предоставление соответствующих прав. Прямого ответа на этот вопрос ни закон, ни разъяснения регуляторов не дают. К тому же, поскольку договор заключается с физическим лицом, которое в большинстве своем не является плательщиком НДС (исключение — индивидуальные предприниматели на общей системе налогообложения, коих единицы), данный вопрос почти полностью лишен практического смысла. Однако будет нелишним на всякий случай разобрать и его.

Согласно разъяснениям Минфина (письмо от 02.06.2008 № 03-07-08/134), смешанный договор не дает права на применение льготы, установленной подп. 26 п. 2 ст. 149 НК РФ: для получения вычета по НДС надо иметь явно выраженный лицензионный договор либо договор отчуждения исключительного права. Хотя нельзя не отметить, что де-факто налоговая признает право на льготу в договоре на предоставление лицензии и оказание услуг сопровождения при условии разделения цены договора. В нашем случае договор не относится ни к одному из перечисленных договоров, несмотря на то что к нему применяются установленные для них правила. Таким образом, делаем вывод, что разделение вознаграждения на две части с целью освободить одну из них от НДС приводит к значительным налоговым рискам. Однако разделять стоимость договора на две части и прописывать НДС для обеих частей, несмотря на то что предоставление прав на ПО по лицензионным договорам либо договорам отчуждения исключительного права НДС не облагается, также, на наш взгляд, некорректно. Таким образом, методом исключения рекомендуем для всех случаев (даже для тех, когда речь идет о физических лицах, не являющихся плательщиками НДС) указывать единую сумму вознаграждения, отмечая, что в данную сумму включены как вознаграждение автора за создание произведения, так и стоимость предоставляемых заказчику прав. Это позволит, в том числе, минимизировать риски доначисления неуказанной стоимости вознаграждения за предоставление прав в целях НДФЛ либо налога на прибыль и НДС индивидуального предпринимателя.

Читайте так же:  Уголовный кодекс франции 1810 структура

Налоговые последствия:

— соответствуют налоговым последствиям договора на создание ПО, если физическое лицо является предпринимателем;

— если физическое лицо не является предпринимателем, заказчик как налоговый агент должен самостоятельно исчислить и уплатить с суммы вознаграждения НДФЛ и страховые взносы. При этом доход по договору в целях налогообложения может быть уменьшен на сумму документально подтвержденных расходов автора либо, если их невозможно подтвердить, на 20%.

Трудовой договор

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

Разработка программного обеспечения силами работников имеет один очень важный нюанс, на который многие работодатели, к сожалению, не обращают внимания. Этот нюанс касается вознаграждения работника, установленного абз. 3 п. 2 ст. 1295 ГК РФ. В случае начала использования работодателем служебного произведения или передачи исключительного права на ПО другому лицу, а также принятия работодателем решения о сохранении служебного произведения в тайне в трехгодичный срок, автор имеет право на вознаграждение, размер которого устанавливается договором между автором и его работодателем. Многие работодатели склонны полагать, что это вознаграждение может быть включено в состав заработной платы сотрудника (ее оклада либо премиальной части). Это не так. Исходя из сложившейся практики, это вознаграждение является вознаграждением sui generis, которое не зависит от трудовых отношений сторон, а носит гражданско-правовой характер, потому не может быть включено в состав трудовых доходов работника. Таким образом, рекомендуем, не дожидаясь момента, когда размер вознаграждения будет установлен судом (как это предусматривается тем же абз. 3 п. 2 ст. 1295 ГК РФ), заключить с работниками, разрабатывающими программное обеспечение, а также иные произведения науки, литературы или искусства, соответствующее соглашение, устанавливающее разумную сумму вознаграждения автору произведения в случае наступления указанных выше условий. Обращаем внимание также на то, что указанное вознаграждение уплачивается единожды и не зависит от наличия трудовых отношений между автором и правообладателем на момент наступления условия выплаты вознаграждения.

И несколько слов о служебном задании. Служебное задание должно быть оформлено по установленным в организации правилам, содержать точное задание на разработку и быть выдано авторам произведения под роспись. По факту исполнения служебного задания работодатель составляет соответствующий акт за подписями комиссии (в нее могут входить авторы и представители работодателя), к которому должны прикладываться исходные тексты разработанной программы на машиночитаемом носителе. Это позволит в дальнейшем доказать наличие прав именно на данное ПО. Естественно, это довольно просто теоретически, однако на практике работодатель сталкивается с тем, что программное обеспечение — это очень динамичный объект, который может видоизменяться каждый день, и невозможно (и не нужно) на малейшую доработку составлять служебное задание. Однако мы рекомендуем периодически все же составлять служебные задания на крупные доработки и актировать полученные результаты работ по созданию новых полезных версий ПО для защиты своих прав от недобросовестного автора. Нелишним будет также регистрация созданного ПО в Роспатенте с депонированием самых ценных отрывков программного кода либо исходников ПО в полном объеме.

Налоговые последствия:

— постановка на учет НМА по стоимости разработки, определяемой в учетной политике компании;

— уплата НДФЛ с суммы вознаграждения авторов ПО.

Смешанные формы договоров

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

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

Сопутствующие договоры (сопровождение, доработка, адаптация)

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

Сопровождение (техподдержка)

Договор оказания услуг, регулируется главой 39 ГК РФ.

Стороны договора: исполнитель — заказчик.

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

Одним из специальных видов договора сопровождения является Service — Level Agreement ( SLA , соглашение об уровне предоставления услуг), который направлен на поддержание бесперебойного функционирования используемой заказчиком IT -инфраструктуры или IT -продукта. Он обычно имеет особую структуру и набор обязательств сторон. Однако базовые требования к договору сопровождения (в частности, правовые основания оказания услуг исполнителем) применимы и к данному договору.

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

Отдельно скажем про договоры оказания услуг гарантийного сопровождения, когда исполнитель в течение гарантийного срока на ПО безвозмездно исправляет ошибки программного кода. Такой договор нечасто встречается в виде отдельного документа, обычно это раздел в лицензионном договоре или в договоре на разработку ПО. Проблема такого договора в том, что эти услуги — совершено логично — оказываются бесплатно (а точнее, цена сопровождения уже заложена в стоимость основной услуги по договору). Это может вызвать определенные вопросы налоговиков (особенно когда речь идет о лицензионном договоре без НДС, а услуги сопровождения НДС облагаются). В этом случае настоятельно рекомендуем выделять хотя бы какую-то символическую стоимость таких услуг и облагать ее НДС. Если же все услуги (работы) по договору облагаются НДС или, наоборот, не облагаются НДС (например, если исполнитель применяет УСН), можно указывать, что стоимость гарантийного сопровождения включается в стоимость основной услуги (работы, реализации права) по договору.

Адаптация (настройка) ПО

Оказание услуг по внесению в ПО изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя. Договор оказания услуг, регулируется главой 39 ГК РФ.

Стороны договора: исполнитель — заказчик.

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

Доработка (модификация) ПО

Стороны договора: исполнитель (подрядчик) — заказчик.

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

Это договор на выполнение работ (договор подряда), и к нему применяются правила главы 37 ГК РФ с учетом особых правил, устанавливаемых частью IV ГК РФ. Самое важное в договорах на выполнение доработок (и мелких, и крупных) — это то, что у исполнителя должны быть права на модификацию ПО. Проблема снимается, если правообладателем ПО является сам заказчик либо исполнитель. В противном случае правообладателем должно быть предоставлено исполнителю соответствующее право (как вариант, право на модификацию может быть предоставлено заказчику с возможностью осуществления модификации ПО третьими лицами по заданию заказчика).

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

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

2. Момент появления нового ПО неочевиден. В какой момент мы можем понять, что модифицированное ПО «уже не то»? При договоре на создание ПО момент появления ПО ясен — когда исполнены требования ТЗ, работоспособное ПО принято по акту. В случае рассматриваемого договора момент появления нового охраноспособного объекта неочевиден. Законодатель не дает разъяснений по данному вопросу, поэтому на практике лицо, которому по договору принадлежит исключительное право на создаваемые объекты, самостоятельно принимает решение о появлении нового охраноспособного ПО. После приходования ПО на основании решения комиссии, оформленного локальным актом организации, должен быть создан соответствующий НМА. Представляется, что старый НМА (немодифицированное ПО) может быть списан по решению комиссии, если новое ПО заменяет функциональность предыдущего. Однако мы не рекомендуем этого делать, если прошло менее 2 лет с момента постановки первичного НМА на учет, чтобы не вызывать лишних вопросов налоговиков.

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