Встретились однажды два человека (давайте дадим им имена – Василий и Николай). Василий относился к категории людей, которых часто называют «генераторами идей», при этом он умел выбирать именно те идеи, которые могут быть «подхвачены» рынком. Николай – талантливый программист, владеющий навыками не только разработки, но и web-дизайна. Василий вынашивал идею запустить один web-сервис, который (он был в этом уверен!) мог бы приносить неплохой доход. Им были продуманы принципы действия сервиса и разработан его алгоритм. Своими мыслями он поделился с Николаем, который быстро ухватился за новую идею и предложил услуги в написании программы. Через пару недель web-сервис был готов к тестированию, а через месяц состоялся его официальный запуск, появились первые пользователи, а с ними — первый доход, который партнеры решили делить пополам. Василий взял на себя продвижение проекта, а Николай стал отвечать за техническую часть…
Не секрет, что многие стартапы рождаются примерно так (разумеется, мы предельно упростили ситуацию). Но, к сожалению, поначалу успешные проекты могут закончиться тем, что один из основателей решает распрощаться с партнером и продолжить вести бизнес самостоятельно. Его коллега в это же время может вынашивать аналогичные планы. В результате вместо совместной творческой работы – судебные тяжбы и требования о возмещении многомиллионных убытков, потеря контроля над проектом и репутационные издержки.
История первая, в которой разработчик решил присвоить проект, но автор идеи отстоял свое право участвовать в стартапе
…Итак, наши герои — Василий и Николай — запустили созданный ими web-сервис. Вся их совместная деятельность строилась на доверительных отношениях, письменного договора между собой не заключали. Доменное имя для сайта Василий зарегистрировал на себя, но пароли доступа к управлению сайтом были не только у него, но и у Николая. Электронные кошельки, куда поступали деньги от пользователей сервиса, были привязаны к банковскому счету Николая (оказалось, что Николай был зарегистрирован как ИП, и у него был открыт счет, который компаньоны решили использовать для общего дела). Некоторое время Николай ежемесячно переводил половину дохода, полученного от эксплуатации сервиса, на счет Василия, пока тот не объявил, что хочет выйти из бизнеса и предложил Николаю «купить» его долю. Николай выразил свое несогласие с таким предложением и его условиями, после чего переименовал web-сервис, сменил пароли доступа к сайту и панели управления хостингом, прекратил перечислять компаньону деньги и перестал выходить на связь с ним.
Василий обратился в суд с требованием признать его соавтором программы для ЭВМ, на основе которой функционировал web-сервис. В случае признания Василия соавтором программы за ним, как и за его недавним партнером, будут признаны исключительные права на нее, в том числе право на получение части вознаграждения от ее использования (по правилам ст. 1229 и 1258 Гражданского кодекса РФ). В качестве одного из главных доказательств, представленных суду Василием, была Skype-переписка с Николаем на этапе разработки программы. Из анализа переписки суд сделал вывод, что именно Василием была сформулирована идея работы web-сервиса, разработан алгоритм его работы и разъяснен смысл формул.
Читатели, хорошо знакомые с данной темой, могут возразить: идеи не охраняются авторским правом. Такой же позиции придерживался и ответчик. Но, по мнению российских судов, идеи не охраняются законом, пока не воплощены в конкретную форму. Если же результатом идеи стало конкретное произведение (в нашем примере – программа для ЭВМ), то сам замысел тоже может рассматриваться как часть творческого труда по его созданию. Без первоначального замысла Василия, — указал суд в решении, — Николай не написал бы соответствующую компьютерную программу, а без написанной Николаем компьютерной программы идея Василия осталась бы не нереализованной и не воплощенной в материальной форме. Суд решил, что программа была создана совместным творческим трудом Василия и Николая. К тому же, Василию принадлежала не только идея, но также разработка алгоритмов действия сервиса, руководствуясь которыми Николай и написал исходный код программы.
Анализируем ошибки
В рассмотренной ситуации Василий имел все шансы утратить контроль над проектом и остаться ни с чем. Можно сказать, что только чудо в виде сохранившейся переписки в мессенджере с подробным описанием формул, алгоритма и принципа действия сервиса помогло Василию доказать свое право авторства на программу для ЭВМ. Не будь ее – доказать что-либо было бы весьма проблематично (но с учетом конкретных обстоятельств спора суды далеко не всегда могут принять электронную переписку в качестве «железного» доказательства).
Но причина не только в том, что партнеры в свое время не договорились письменно, как они намереваются распоряжаться своим исключительным правом на созданную программу и распределять доход от ее использования. Другой фактор риска состоял в организации самого бизнеса: с правовой точки зрения стартап был бизнесом только одного из партнеров (Николая), при том что другой не имел юридически закрепленных прав на участие в нем.
Таким образом, Василий весьма опрометчиво доверился Николаю: фактически, «подарив» ему идею, он не предпринял необходимых мер ни для закрепления своих прав на созданный программный продукт, ни для юридического закрепления своей роли в совместном стартапе.
История вторая, в которой автор идеи оказался выброшенным «за борт» стартапа
Показательным является еще один кейс, начало которого схоже с ситуацией, описанной выше. Николай, разрабатывавший web-сервис по заданию Василия (и, по утверждению последнего, за его деньги), в какой-то момент понял, что сможет эксплуатировать его сам, без участия партнера. Он поместил на заставку веб-приложения логотип принадлежащей ему фирмы, указал ее в качестве правообладателя, а себя – а качестве автора. В таком виде представил очередной вариант программы и Василию. Василий возмутился: он планировал сам выступать в качестве правообладателя, когда сервис будет запущен. Но Николай его опередил, воспользовавшись тем, что отношения между «партнерами» были, как и в предыдущей ситуации, доверительными, а письменный договор на разработку программы заключен не был. Василий лишь давал Николаю задания по электронной почте и указывал на необходимость доработок, а также время от времени переводил ему деньги за выполненную работу.
Продолжение тоже напоминает предыдущую ситуацию: дело дошло до суда. Только Василий не заявлял требования о признании его соавтором программы. Он просил суд признать за ним исключительное право на программу, поскольку данная программа, как он уверял, разрабатывалась по его заказу, а значит он как заказчик должен считаться ее единственным правообладателем согласно ст. 1296 Гражданского кодекса РФ.
В отсутствие заключенного между Василием и Николаем письменного договора в качестве доказательства наличия договорных отношений суду были предъявлены распечатки электронных писем. Но Николай заявил, что никаких писем от Василия не получал (к тому же, Василий и сам не смог представить ответы Николая). Анализ же содержания писем (которые Василий громко именовал в суде «техническими заданиями») показал, что в них давалось лишь описание функционала программы, ее желаемых характеристик, но не более. Проведенная экспертиза «технических заданий» показала, что они не соответствуют требованиям к техническим заданиям, установленным ГОСТом, и носят декларативный характер. В итоге суд отклонил требования Василия, признав, что приложение разрабатывалось Николаем самостоятельно и независимо от Василия.
Анализируем ошибки
Здесь основная ошибка – та же, что и в предыдущей ситуации. Не следует начинать стартап исключительно на доверительных отношениях, без заключения договоров, распределяющих обязанности между участниками проекта и закрепляющих права на создаваемый интеллектуальный продукт. Тем более если партнерами выступают люди, ранее не знавшие друг друга. В нашем примере Василий, доверившись Николаю, не учел того, что Николай может воспользоваться идеями Василия и пренебречь первоначальными договоренностями, не закрепленными документально.
История третья, в которой «за бортом» стартапа оказывается разработчик программы
«Генератор идей» Василий является учредителем компании (например, ООО «Сигма»), ее единственным участником и директором. По его поручению Николай (не состоявший до этого ни с Василием, ни с его фирмой в каких-либо отношениях) пишет исходный код программы и получает вознаграждение (вероятно, снова без оформления договора). Василий понимает, что в будущем потребуется устранение ошибок, добавление новых модулей, выпуск обновленных версий, поэтому решает предложить Николаю должность в ООО «Сигма» с солидным наименованием (например, «директор по IT»), собственным кабинетом с кожаным креслом и «окладом согласно штатному расписанию», сопоставимым, как уверяет Василий, с размером вознаграждения, которое Николай бы получал как соавтор программы.
Поскольку функционирование web-сервиса планируется осуществлять от лица ООО «Сигма», Василий принимает решение зарегистрировать данную программу для ЭВМ в Роспатенте, указав в заявлении в качестве правообладателя свою фирму, а себя и Николая — в качестве соавторов программы. Николай расписывается в заявлении, давая согласие на указание его в качестве соавтора. И уже потом, когда программа зарегистрирована Роспатентом, кто-то объясняет Николаю, что теперь он – «всего лишь» ее соавтор, но уже не правообладатель (Гражданский кодекс РФ разводит эти понятия, и автор и правообладатель – не всегда одно и то же лицо). У Николая есть, например, право требовать указания на всех экземплярах программы его имени в качестве разработчика. В то же время, исключительное право разрешать или запрещать использование программы и получать вознаграждение от ее использования отныне принадлежит правообладателю, коим является ООО «Сигма» — компания, принадлежащая Василию, и в которой Николай не более чем наемный работник.
Приходит к Николаю и осознание того, что его зарплата может оказаться гораздо меньше, чем половина прибыли компании (скорее всего, по мере роста дохода от эксплуатации сервиса прибыль Василия и его фирмы будет возрастать, а зарплата Николая может оставаться неизменной, либо расти гораздо меньшими темпами, чем доход компании).
Николай принимает решение судиться со своим работодателем, а заодно требовать признать недействительной регистрацию программы для ЭВМ, осуществленную на имя ООО «Сигма».
Утверждает, что он разработал эту программу еще не будучи работником «Сигмы». Следовательно, программа не может рассматриваться как служебное произведение. Только он – автор – изначально являлся и продолжает оставаться единственным владельцем исключительных прав на нее, что вытекает из ст. 1270 Гражданского кодекса РФ. Ведь ни Василию, ни его фирме он свои права на созданную программу не передавал, каких-либо договоров (кроме трудового) не заключал.
К огорчению Николая, суды в таких случаях (а они не единичны) обычно встают на сторону правообладателей, на чье имя зарегистрирована программа. Само по себе отсутствие договора об отчуждении исключительных прав на программу в пользу фирмы еще не говорит, по мнению судов, что передачи прав не было. Когда Николай расписывался в заявлении в Роспатент, он не мог не видеть, что правообладателем в заявлении указан не он, а ООО «Сигма». Следовательно, к моменту подписания уже определился с тем, кого именно он рассматривает в качестве владельца исключительных прав на разработанную им программу.
Анализируем ошибки
Маловероятно, что Николай, после проигранного суда с работодателем, останется на ключевой позиции в стартапе. Даже если на какое-то время и останется – он уже не будет работать столь же эффективно, ведь проект теперь уже «не его». Главная ошибка, как и в предыдущих ситуациях, — юридическая неопределенность будущих ролей партнеров, которая должна быть снята еще до начала работы над проектом. Сохраняется и второй фактор риска – «совместный» бизнес реально контролируется только одним из партнеров, который всегда будет находиться в более выгодном положении по отношению к компаньону, участвующему в стартапе не в качестве собственника бизнеса, а в качестве наемного работника или, что еще хуже, вообще без какого-либо юридического статуса.
Большую роль в анализируемой ситуации сыграл факт регистрации программы для ЭВМ. Часто в профессиональном сообществе разработчиков можно услышать мнение, что регистрация программы – это лишь возможность получить красивую «бумажку», чтобы потом приложить ее к диплому или диссертации, показать маме и т.д. Отнюдь. «Бумажка» в нашей ситуации сыграла решающую роль: суд встал на сторону указанного в ней правообладателя.
Некоторые общие рекомендации
Существует ли универсальное решение, как обезопасить стартап от подобных конфликтов? Ответ – нет. Иногда встречаются «рекомендации» различного рода «юридических гуру» типа «создайте общество с ограниченной ответственностью с равным распределением долей» или «зарегистрируйте программу для ЭВМ на имя всех основателей» и т.п. В одних случаях такие решения действительно могут быть оправданны, в других же могут только навредить.
Но все же «универсальный закон» существует: необходимо договариваться обо всем «на берегу», до начала работы над проектом, и закреплять договоренности в правовой форме. Вовсе не обязательно, чтобы договор между автором идеи и разработчиком программы непременно представлял собой соглашение между соавторами с закреплением равного распределения доходов. Это может быть, например, договор оказания услуг на разработку программы, в котором будет закреплен переход исключительных прав на программу заказчику. Это может быть какая-то другая форма (подходов здесь достаточно много). Важно, чтобы каждый из участников проекта изначально понимал, как будут распределены права, связанные с использованием созданной ими программы (если заметили, во всех трех описанных ситуациях источником конфликта было несоответствие действий партнеров ожиданиям). То же касается и участия основателей в бизнесе.
И, конечно, при создании программ для ЭВМ настоятельно рекомендуется регистрировать их в Роспатенте. Наличие документа, в котором указаны правообладатели и авторы, служит в суде хорошим доказательством принадлежности исключительных прав на результат творческого труда (если, конечно, такое свидетельство не было получено обманным путем, например, при указании в качестве автора постороннего лица. Реальный автор сможет оспорить такую регистрацию в суде и требовать признать его и автором, и правообладателем программы).
Ниже приведено несколько ссылок на судебные решения по делам, фабулы которых похожи на описанные выше истории. Точного соответствия искать не нужно: какие-то реальные истории мы упростили, отбросив не имеющие юридического значения подробности, похожие истории – «слили» в одну. Приведенные ссылки – лишь единичные примеры из числа похожих ситуаций (но в целом такие ситуации решаются похожим образом). Если кто-то в описанных историях узнал себя – уверяем, это чистая случайность.
Ссылки: Гражданский кодекс РФ (ст. 1229, 1258, 1270, 1296)
Некоторые судебные акты (для примера): раз, два, три, четыре
Комментарии (55)
mwambanatanga
16.02.2017 19:59+2Классическая история — разработка планшета Joojoo. В википедии хорошо проиллюстрирована, а на техресурсах типа Engadget и в блоге инвестора ещё и хорошо обсмакована.
Artnem
16.02.2017 20:46+1Да все описанные истории — классика жанра. Более раскрученными являются истории с зарубежными стартапами (раскрутка таких историй иногда — часть раскрутки стартапа, порой грех не воспользоваться поводом!). Я лишь показал, как похожие ситуации разрешаются в Российской судебной практике. Спасибо за комментарий.
binkaminka
17.02.2017 11:41Да все описанные истории — классика жанра. Более раскрученными являются истории с зарубежными стартапами (раскрутка таких историй иногда — часть раскрутки стартапа, порой грех не воспользоваться поводом!). Я лишь показал, как похожие ситуации разрешаются в Российской судебной практике. Спасибо за комментарий.
И правильно.
В РФ (и кстати в ЕС) такие вещи решаются совсем не так как в США.
OtshelnikFm
16.02.2017 22:48+1Вот по исключительным правам интересно.Например: на фрилансе я по заказу делаю плагин. Про исключительные права и прочее ничего не обговаривалось.
Как обычно — «мне надо это, вот так, и это».
Отдаю плагин заказчику, чуть дорабатываю дизайн, функционал и выставляю на codecanyon. Я как разработчик нарушаю что либо?VolCh
17.02.2017 10:49По ст 1296 нарушаете права заказчика, если предметом заказа была разработка плагина, а не доработка сайта заказчика, которую вы решили выполнить, создав плагин.
OtshelnikFm
17.02.2017 11:56А если так: создание нового продукта повторяющего функционал старого — не является нарушением?
Например запись к специалисту: алгоритм же один и тот же. Выбрал время, забронировал. И таких повторяющихся алгоритмов много. Это же не уникально. Я понимаю крупные игроки бодаются за дизайн кнопок — скругленная кнопка, квадратная. Теперь и разработать ничего нельзя чтобы не получить иск?VolCh
17.02.2017 12:16Из поста:
Читатели, хорошо знакомые с данной темой, могут возразить: идеи не охраняются авторским правом. Такой же позиции придерживался и ответчик. Но, по мнению российских судов, идеи не охраняются законом, пока не воплощены в конкретную форму. Если же результатом идеи стало конкретное произведение (в нашем примере – программа для ЭВМ), то сам замысел тоже может рассматриваться как часть творческого труда по его созданию. Без первоначального замысла Василия, — указал суд в решении, — Николай не написал бы соответствующую компьютерную программу, а без написанной Николаем компьютерной программы идея Василия осталась бы не нереализованной и не воплощенной в материальной форме. Суд решил, что программа была создана совместным творческим трудом Василия и Николая. К тому же, Василию принадлежала не только идея, но также разработка алгоритмов действия сервиса, руководствуясь которыми Николай и написал исходный код программы.
В данном случае суд решил, что это совместная разработка "заказчика" и "подрядчика", может решить, что только "заказчика", может, что только "подрядчика".
Artnem
17.02.2017 12:30Отношения между соавторами по созданию произведения и отношения заказчик-подрядчик — это разные отношения с точки зрения гражданского права. В первом случае «заказчик» избрал первую стратегию и убедил суд в том, что они создавали сервис в паре с автором исходника (действительно, это была в его ситуации более выигрышная стратегия). Во второй истории «заказчик» при обращении в суд выбрал вторую стратегию. Он не считал себя соавтором программы и не собирался делить на двоих исключительные права на неё с создателем кода. Он рассматривал себя именно как заказчик — т.е. лицо, давшее задание на разработку продукта и не принимавшее непосредственного участия в его создании. Но как заказчик он рассчитывал заполучить исключительные права на программу в полном объёме. Ему это (с учётом выбранной тактики и не самой блестящей защиты) не удалось (впрочем, шансы быть признанным соавтором в конкретной ситуации, на основе которой была написана эта история, было ещё меньше).
Если дело доходит до суда, то исход будет зависеть от:
А) заявленных истцом требований (суд всегда ограничен ими)
Б) выбранной истцом и ответчиком тактики защиты своих интересов
В) имеющихся у суда доказательств (которые были представлены сторонами)
Artnem
17.02.2017 21:56+1Знаете, иск можно получить всегда. Даже за скругленную кнопку. Как-нибудь о таких исках тоже расскажу. Что касается функционала, то надо смотреть в каждом конкретном случае. Общее правило: авторским правом охраняется только результат творческого труда. Сами по себе идеи и принципы действия не охраняются. Поэтому если речь идёт о распространённом функционале, то здесь в большинстве случаев нарушения может не оказаться.
Но вопрос не настолько простой. Например, запись на приём к врачу посредством веб-приложения (просто как идея, возможность, потребительское свойство программы) не охраняется авторским правом. Я не специалист по алгоритмированию, но мне кажется, что решение данной задачи может быть осуществлено далеко не одним только типовым алгоритмом. Точнее, алгоритм действий пользователя здесь может быть и один (выбрать врача — выбрать дату и т.д.), но я сейчас говорю об алгоритмах машинной обработки запросов пользователей — тех алгоритмов, на основе которых написаны исходники. А алгоритм уже — результат творческого труда и вполне может оказаться частью зарегистрированной на чьё-то имя программы для ЭВМ (в юридическом смысле программа — это не только исходник, но и в том числе подготовительные материалы, включая алгоритмы).
Поэтому иск от правообладателя, который «увидит» в Вашей программе свой алгоритм, не исключён (такие случаи были). Шансы защититься, впрочем, есть. Но лучше ещё до запуска проверить Ваш продукт на «чистоту» и оценить риски.
haldagan
17.02.2017 11:41ЕМНИП все зависит от того, как оформлены ваши отношения с заказчиком/биржей.
Работодатель-работник: если вы значитесь в штате как разработчик — по умолчанию права пренадлежат работодателю.
Заказчик-исполнитель: зависит от того, что оговорено в договоре. Обычно договор «на разработку ПО» идет с передачей исключительных прав.
«В черную»: все права принадлежат разработчику (заказчик может попробовать доказать в суде, что на самом деле он соавтор или даже автор).
У меня была одна обратная история — я сделал небольшой плагин, а заказчик выставил его на подобную площадку, ничего не сказав и не предупредив.
Заодно указал свою студию в виде автора/разработчика. Деньги небольшие, плагин маленький — ссориться не стали, но осадочек остался.
vozhd99
16.02.2017 23:49+3Вспоминается наш опыт. В чём-то успешный, в чём-то — не особо. Да, мы чуть-чуть заработали, но главное, что вынес для себя:
* Не веди дела с друзьями (отношения могут сильно испортиться);
* Если с кем-то что-то делаешь, что для тебя критически важно: фиксируй на бумаге (хоть формально, но доказательство согласия);
* Если делали всё на дружбе и дело вдруг попёрло: разграничивайте на бумаге всё-всё (от вложенных сил и средств до обязанностей и их соотношении в общем деле). Да, очень неприятная процедура, но позволит избежать в будущем недоговорённостей и более неприятных последствий;
* Если идея твоя, то сам ищи деньги и полностью владей всем (ООО, к примеру, единолично на себя).sergarcada
17.02.2017 11:42+1>* Не веди дела с друзьями (отношения могут сильно испортиться);
Они могут испортиться и от того, что ты отказался начинать с ними дело, а взял в партнеры кого-то со стороны )
Artnem
17.02.2017 22:22+1Спасибо за комментарий. Соглашусь, что лучше по возможности все фиксировать на бумаге. Даже с друзьями. Что касается друзей — мне известны примеры, когда успешные стартапы организовывались давними друзьями. Главное в этом случае — разграничивать «дружбу» и«дело». Поэтому когда я даю консультации и разрабатываю юридические модели стартапов — узнаю в том числе и характер личных отношений между партнерами. Это тоже имеет значение.
Насчет последнего тезиса (идея твоя -сам ищи деньги и полностьювсем владей) — он верен не всегда, но в России часто именно такая модель стартапов оказывается более жизнеспособной, ставя в тупик тех, кто учился по американским учебникам. Периодически я рекомендую использовать именно её — в зависимости от конкретных условий. Наша беда в том, что мы любим делить, толком ещё ничего не заработав.vozhd99
17.02.2017 23:22+1Договорённость и бухгалтерия должна возникать с момента начала совместной работы над идеей, или максимально быстро. Всюду находятся, как исключения, так и подтверждение истин. У кого это проходило не так гладко, вырабатывается своеобразный «иммунитет», чтобы не быть «кинутым» в очередной раз.
Я не знаю, как оно в Америке, более того не так хорошо знаком с их законодательством и налоговой системой и сказать про это ничего не могу. Думается мне, что те, кто начинал там, либо по их учебникам, округляют здесь глаза, так как всё совсем не так. Не могу сказать, что меня увлекало чтение книг наших бизнесменов, но и их советы лучше не принимать на веру как истину, а критически рассматривать. Более того, есть тонкости, связанные с налогообложением (к примеру, ООО, когда не владея 51% доли, вы не можете без подоходного налога внести личные средства насчёт компании), что порождает ненужные издержки, в условиях нехватки финансов. Тонкостей таких у нас предостаточно. Это первое.
Второе. Всегда должен быть лидер в компании, который мотивирует других на достижение целей. Не нужно порождать коллективной (колхозной) ответственности, а, наоборот, максимально разграничивать ответственность, хотя это и трудно в компании из двух-трёх человек.
Miller777
18.02.2017 12:52Не веди дела с друзьями
И родственниками. Наблюдал распад небольшой компании на две, с разделом имущества. Владельцы первоначальной компании — брат и сестра.vozhd99
19.02.2017 22:48И родственниками. Наблюдал распад небольшой компании на две, с разделом имущества. Владельцы первоначальной компании — брат и сестра.
Кумовство в самом начале встречал редко, а после развития — часто. Могу сказать так: бежать из этой компании при первой возможности.
Akuma
17.02.2017 01:28+1Представим следующий вариант:
Вася и Петя решили запустить мега стартап. Вася занимается офлайн частью, а Петня — онлайн и веб-разработкой. Все юридические регистрации и проводки идут на ИП Васи.
Доступ на сервера есть у обоих, но у Пети на домашнем компьютере есть «настоящие» исходники, а на вебсервере находится только минифицированная, обфусцированная версия скриптов (допустим JS).
Вася с Петей ссорятся и Васе остается рабочий, но обфусцированный веб-сервис. А Петя имеет на руках все исходники.
Вопрос: Если Петя поменяет название и дизайн, а так же изменит алгоритм обфускации, как можно доказать, что Петя использует ту же программу, что и Вася? Причем Петя может ее дорабатывать, а Вася… скорее всего нет.
И что им за это будет?
Areso
17.02.2017 10:54Мое скромное мнение таково:
есть такое понятие, как «производная работа», включающая себя в том числе даже переписывание на другой язык. Если суд примет решение, что это производная работа от Васиного сервиса, то, несмотря на то, что права на саму производную работу будут у Пети, то Вася сможет диктовать Пети условия касательно переписанного сервиса.
Разница между между fair use и производной работой бывает довольно тонкой, но чаще всего идет вопрос насколько один сервис в части функциональности копирует другой. Т.е. если после сравнения первого и второго сервисов осталось впечатление, что второй сервис — ровно тоже самое, но в другой оболочке — то это производная работа.
Другой момент, что во время доработки функционал у Пети сможет довольно сильно изменится с течением времени, и тогда это будет уже fair use (заимствование идей не возбраняется).
trapwalker
17.02.2017 13:39+1На мой взгляд стоит еще добавить, что обфускация бывает не только явной и не только умышленной. То есть, бывает, что разработчик из-за довольно фривольного отношения к хорошим практикам и хорошему стилю разработки ПО нарочно или нечаянно создают условия, когда в их исходниках, конфигурациях, серверах и базах данных буквально черт ногу сломит.
Тут при конфликте такому программисту не требуется ни винт форматровать, ни бэкдоров оставлять для вредительства. Уход такого «специалиста» (а если философски подойти, то скорее приход его) автоматически несет массу неудобств.
roboter
17.02.2017 10:55Ещё вопрос про лицензию исходников. Могу ли я как автор поставить любую лицензию, например MIT и выложить на Github?
Areso
17.02.2017 11:02Если вы единственный автор и передачи прав на код, в числе которых входит установление лицензии на его посл. распространение, не было, то можете.
В обратном случае надо оговаривать такие вещи, если они не оговорены и исключительные права у правообладателя, но не автора, то выбор лицензии — за ним.
ConceptDesigner
17.02.2017 11:42Сложно себе представить ситуацию, когда два посторонних человека начинают серьезный стартап. Обычно все же собираются вместе единомышленники, между которыми конфликт маловероятен, ведь они объединены общей идеей.
x07
17.02.2017 12:09Конфликт может возникнуть, даже на самой примитивной почве, не смотря на то, что все кругом единомышленники. Был случай когда не могли договорится насчет дизайна. Одному нравится, другому нет. В итоге разругались все в хлам.
x07
17.02.2017 12:16На мой взгляд, серьезный стартап начинают те, у кого есть на это средства. И на эти самые средства нанимаются разработчики, которые являются наемными сотрудниками, и просто работают за ЗП, не являясь партнерами.
А вот ситуация, когда у человека есть идея, но нет ресурсов на ее реализацию достаточно частая. Тут и получается, что он ищет разработчиков(если таковых нет среди его друзей и знакомых) на стороне, которые будут работать на перспективу( «за еду»), но зато будут партнерами. Если повезет, то такой стартап станет серьезным, кто-то посчитает что он сделал больше и тогда конфликт неизбежен…vozhd99
17.02.2017 18:26+1Тут и получается, что он ищет разработчиков(если таковых нет среди его друзей и знакомых) на стороне, которые будут работать на перспективу( «за еду»), но зато будут партнерами.
Аттракцион неслыханной щедрости какой-то! Мне таких предложений поступает очень много, даже за год минимум 2-3 проскакивает. Причём, когда уточняешь у человека, будем ли фиксировать это, то он так хмурит бровки и становится серьёзным: «ты меня не знаешь, что ли? Не уважаешь?» И не припомню, чтобы кто-то из них успешно развился.
VolCh
17.02.2017 12:21Сплошь и рядом "генераторы идей" ищут того, кто воплотит их идею в жизнь за долю в будущей прибыли. Не имея возможности или просто не желая платить рыночную зарплату специалисту(ам) нужного уровня. Вернее, начинают искать, когда понимают, что за 100 рублей в час (после обвала рубля, раньше на 50 искали максимум) никто этим заниматься не будет, или начнёт, но результата нормального не будет.
vozhd99
17.02.2017 18:31На гиктаймс предлагают водителям убера доставлять еду за 37 рублей в час. Посмотрим, много ли будет откликов.
100 рублей в час — это 16 тысяч рублей в месяц.VolCh
18.02.2017 12:13Именно столько и предлагают многие "генераторы идеи". На порядок больше предложить не могут или не хотят (очень малое число авторов идей "стопудово взлетит, разбогатеем как Дуров" готовы хотя бы заложить своё единственное жильё для получения приличного стартового капитала). Когда никого не находят или помучаются с каким-нибудь начинающим фрилансером, то становятся щедрыми и предлагают долю в прибылях, вплоть до 49%, иногда даже вдобавок к изначальным 100 рублям в час, хотя часто просто долю..
vozhd99
19.02.2017 22:53Вот мы подходим к другой важной составляющей, которая отсекает эмоциональность и ангажированность «генератора идей» (да точно взлетит, я проверял!). Называется она финансовая ответственность за результат. Это видно практически сразу: вам обещают золотые горы, когда взлетит, а на вопросы о том «что будет если» — отмахиваются. Лучше тактично попросить поискать в другом месте.
Gesheft
17.02.2017 11:42Очень полезная и поучительная информация но хотелось бы, чтобы вы написали и возможные варианты недопущения подобных ошибок с примерами (и\или ссылками на сайт) договорв, последовательности действий и т.д. спасибо
Artnem
17.02.2017 11:44Спасибо всем за комментарии. Постараюсь на каждый ответить вечером или на выходных.
le1ic
17.02.2017 13:36В первом случае у Николая был ленивый или плохой адвокат, иначе бы Василий не смог доказать, что скайп-переписка велась с Николаем
Artnem
17.02.2017 23:55Да, как вариант — «аккаунт не мой, впервые вижу». Но такие утверждения надо соотносить с другими доказательствами, которые есть в деле.
lega
Интересно, что будет для 3-го случая если разработчик заберет (не отдаст) исходники и запустит конкурирующую компанию?
Artnem
Не самый лучший вариант. Ведь программа (включая исходники) в 3-м случае уже зарегистрирована на имя ООО как правообладателя. Любое использование исходника без согласия правообладателя (даже самим автором!) будет незаконным. Это грабли, на которые наступают, к сожалению, очень часто. Исключительное право на использование программы (и любого другого результата интеллектуальной деятельности) далеко не всегда принадлежит автору, а авторство не означает неограниченного использования (если правообладатель и автор — разные лица).
«Не отдать» исходники ему не удастся — раз программа зарегистрирована, их текст был представлен в Роспатент вместе с заявлением, а значит, они есть у заказчика.
Хотя, конечно, я бы предложил разработчику некоторые решения. Можно переработать алгоритм и написать новый исходник (лучше на другом языке). Тоже рискованно — бывший партнёр может обвинить в недобросовестной конкуренции, незаконном использовании коммерческой тайны (если разработчик расписался за её неразглашение) и много ещё в чем, вплоть до незаконного использования идеи как части произведения (программа с точки зрения права — произведение). Но если в каждом конкретном случае провести юридический анализ ситуации, то найти приемлемое решение можно. Спасибо за комментарий и за вопрос.
devpreview
Если не ошибаюсь, то не любое. Автор может использовать «для себя» и для демонстрации.
Artnem
Спасибо за комментарий.
Права автора произведения определены в ст. 1255 Гражданского кодекса. К ним относятся:
1) исключительное право на произведение;
2) право авторства;
3) право автора на имя;
4) право на неприкосновенность произведения;
5) право на обнародование произведения.
(плюс несколько дополнительных прав, например, право на вознаграждение за служебное произведение).
Все, что связано с использованием произведения, охватывается понятием «исключительное право». Но из пяти перечисленных выше прав автора именно исключительное право является отчуждаемым, т.е. может быть передано автором другому лицу. И уже все последующие отношения, связанные с использованием программы, будут определяться условиями такой передачи.
Право использования автором программы/произведения «для себя» (если автор не является правообладателем) по умолчанию (как нечто абсолютное и непререкаемое) законом не предусмотрено. Например, было бы странно, если бы созданное служебное произведение автор «унес» с работы домой и там начал его использовать «для себя». Но в случаях, когда изначально правообладателем был автор (а потом передал исключительные права кому-то другому), можно предположить, что даже после передачи исключительных прав автор продолжает оставаться правомерным обладателем экземпляра созданной им программы и на этом основании может продолжать пользоваться ею в личных целях (если явного запрета на это не предусмотрено условиями передачи прав).
Что касается «демонстрации», то ее нельзя путать с «правом на обнародование» (п. 5 ст. 1255, 1268 ГК). Я не хочу сказать, что автор программы вообще не может показать созданную им ранее программу (или ее фрагмент), скажем, при устройстве на работу, либо потенциальным заказчикам в качестве портфолио. Но здесь много «подводных граблей». Опять же — не окажется ли такая демонстрация, например, разглашением конфиденциальной информации (если было подписано соглашение о конфиденциальности)? Не будет ли это расценено правообладателем как неправомерное использование произведения? (вопрос о том, узнает он об этом или не узнает, оставим за рамками этого обсуждения) и т.д. Риски претензий возникают вполне реальные.
Здесь во всяком случае рекомендую включать в договоры на разработку ПО, предполагающие передачу исключительных прав на программу заказчику, условия о том, в каких случаях и в каком объеме разработчик программы сможет ее использовать (и сможет ли вообще) в личных и демонстрационных целях.
grossws
Для этого, насколько я понимаю, на предприятии должен быть введен режим коммерческой тайны и какая-то существенная информация должна быть проведена как кт. Плюс разработчик должен явно поставить подпись на бумаге при получении доступа к экземпляру кт.
Artnem
Вы все правильно понимаете. Я написал «если разработчик расписался за ее неразглашение» для краткости, подразумевая при этом, что расписался он не на огрызке листочка в клеточку, а с соблюдением всех необходимых процедур. Многие фирмы «сыплются» на том, что работники у них в буквальном смысле «уводят» КТ, а когда с ними начинают судиться и требовать компенсации убытков за якобы разглашение КТ, выясняется, что в суд ничего кроме второпях настряпанного приказа, в котором расписался работник, и представить нечего — нет ни положения о КТ, ни перечня информации, ее составляющей, ни в трудовых договорах с работниками нет обязанности не разглашать КТ, ни соглашений о конфиденциальности, ни регламентов оборота информации и документов, составляющих КТ, ни доказательств получения работником доступа к КТ — ничего нет. И суды правильно приходят к выводу, что не было никакой КТ. Поэтому, разумеется, речь идет о режиме КТ. О том, как его правильно ввести, оформить и использовать, возможно, тоже напишу как-нибудь.
TerraV
Насколько я знаю, для регистрации ПО требуют порядка 50 страниц А4 листинга кода, что составляет пренебрежимо малую часть проекта и может быть легко заменено.
Artnem
Сейчас, согласно правилам, действующим с прошлого года, заявитель сам определяет объём депонируемого исходного года, достаточного по его мнению для идентификации программы. До этого действительно было ограничение в 70 страниц, сейчас оно снято.
akumidv
Роспатент принимает только ограниченный размер исходного кода — до 70-ти страниц крупного текста (~50 строк на страницу) — т.е. ~3500 строк. Остальное депонируется за дополнительную оплату и на мой взгляд, крайне редко встречается даже у крупных компаний. 3500 строк кода — это чаще всего — «крохи» от реального объема программ. Поэтому сопоставление кодов в суде крайне маловероятный вариант.
Artnem
Сейчас ограничения в объеме депонируемого материала нет, достаточность фрагмента для идентификации определяет правообладатель. В ответе на предыдущий комментарий я дал ссылку на действующий порядок, он вступил в силу в июле прошлого года.
trapwalker
Вот тут на лицо какой-то наивный или устаревший подход. В общем случае программа — это огромное количество данных. Они не все текстовые и напечатать какие-то куски на 100500 страниц — это бред, на мой взгляд. Если бы речь шла о разработке какой-то достаточно статичной библиотеки или кодека — это ещё ок, но поднять большой сайт или сборку нативного приложения имея на руках только исходники, возможно даже без понимания как их применять — это довольно больно ударит по бизнесу, вернее фактически парализует его.
Если разработчик предполагает потенциальный вариант военных действий с владельцем бизнеса, то водить за нос последнего у него есть просто огромное количество возможностей:
— В исходники для заявки на регистрацию попадёт тонна макулатурных и фактически бесполезных данных, которые таковыми трудно признать без въедливого аудита.
— На прилагающийся диск с, якобы, актуальным исходным кодом продукта ляжет древняя ревизия из системы контроля версий.
— Явная или неявная обфускация, проведенная в «официальном» исходном коде сделает его бесполезным для интеграции другими программистами.
— За скобками системы контроля версий могут (умышленно или «нечаянно») остаться большие и важные пласты знаний и материалов, без которых осуществлять поддержку, а иногда даже и использование продукта, не говоря уже о развитии, становится примерно сопоставимым по затратам с написанием продукта заново (особенное если учесть наличие глубоко вовлеченного в предметную область и разработку продукта специалиста, пусть даже не программиста).
Я это к чему. Вроде понятие репозитория еще не прижилось в нормах юридической практики. Если программа для юристов — это буковки на листочках, то у меня плохие новости, есть докер-контейнеры, системы сборки и тестирования, аккаунты и виртуальные машины в амазоне или у других хостеров…
Когда речь о компании из нескольких человек, проводить профилактику против гипотетических конфликтов мудрый руководитель начнёт задолго до того, как они смогут больно долбануть по бюджету и продукту. И рычаг тут один — аккуратное разбавление незаменимых участников проекта
новыми грамотными специалистами плюс обучение молодых. Это дорого, но лишняя корзина для яиц может уберечь от потери всего.
Artnem
В данном случае я всего лишь исходил из того, что заказчик, решивший зарегистрировать программу на свое ООО, проявил достаточно благоразумия и осмотрительности, чтобы потребовать от исполнителя экземпляр программы, включающий в себя, согласно ГК, в том числе исходный код. Может быть, его юристы все-таки надоумили, а может, бухгалтер, которому нужно было оприходовать образовавшуюся интеллектуальную собственность. Про распечатывание всего программного кода от начала до конца на бумаге я не говорил.
Пост и комментарий — не про то, как «водить за нос» заказчика. Разумеется, если бы ко мне обратился разработчик в похожей ситуации и сказал, что письменного договора на разработку ПО с ним не заключалось, то я первое, что рекомендовал бы — ни в коем случае не передавать исходный код заказчику до прояснения ситуации.
В примерах, которые я привел в тексте, я специально оговорил, что между заказчиком и исполнителем сложились отношения взаимного доверия. И исполнитель, доверяя заказчику, исходный код ему передал «в обмен» на красивую должность, зарплату с бонусами и указание его в качестве автора. Ну, передал — молодец.
Насчет других «вождений за нос» — конечно, можно оставить заказчику обфусцированную версию (типа тоже исходник). Изначальный вопрос был не в том, что он с ней будет делать, а сможет ли юридически этот разработчик в дальнейшем использовать данную программу и безопасно для себя коммерциализировать ее? Я бы не советовал. Если дело дойдет до суда и суд назначит по делу судебно-техническую экспертизу, то разработчика, скорее всего, обяжут представить эксперту «нормальную» исходную версию, а из обфусцированной версии, имеющейся у заказчика, эксперты, скорее всего, смогут восстановить исходную версию с качеством, достаточным для того, чтобы определить, тождественны сравниваемые программы или нет. Тем более что сравниваться будут не только исходники, но и производные от них объектные коды, и алгоритмы, лежащие в основе программ, и порождаемые программами отображения — в общем, сравниваться будет все, что охватывается понятием «программа для ЭВМ» в юридическом смысле. И если тождество программ будет установлено, то разработчик, решивший «перехитрить» «лопуха»-заказчика, рискует попасть на нехилые деньги.
То же будет касаться и ситуации, если разработчик под видом исходника решит подсунуть заказчику что-то совершенно левое, лишь отдаленно напоминающее исходник программы и совершенно неработоспособное.
Перечитал еще раз то, что написал. Ни про буковки, ни про листочки у меня нет.
Хотя то, что Вы написали про юристов — отчасти на самом деле так. С точки зрения права на программы для ЭВМ распространяется режим литературных произведений. А значит, когда речь идет о программе как об объекте авторского права — это в определенном смысле действительно «буковки на бумажке», нравится это или нет.
Прижилось. В одном из дел, ссылки на которые я привел, разработчик, как и в нашей ситуации № 3, требовал признать недействительной регистрацию программы на работодателя и просил суд признать его автором и владельцем исключительных прав на программу, которую он якобы разработал сам еще до устройства на работу и «принес» ее с собой. Ответчик-работодатель представил суду в качестве доказательств распечатки журнала действий из системы контроля версий и тем самым доказал, что в создании программы участвовал не только истец, но и другие работники, а последняя версия практически ни в чем не была похожа на версию, первоначально написанную истцом. Работодатель суд выиграл. Как видите, даже «буковок на бумажках» не потребовалось.
А здесь полностью согласен. Это и была главная мысль всего моего поста, Вы ее правильно уловили.
Да, это эффективный рычаг. В деле, которое я кратко описал в предыдущем абзаце — ровно все так и произошло. Насчет того, что «единственный» — я бы поспорил. Но это уже вопрос стиля руководства.
Спасибо за комментарий.