Comments 55
«Не отдать» исходники ему не удастся — раз программа зарегистрирована, их текст был представлен в Роспатент вместе с заявлением, а значит, они есть у заказчика.
Хотя, конечно, я бы предложил разработчику некоторые решения. Можно переработать алгоритм и написать новый исходник (лучше на другом языке). Тоже рискованно — бывший партнёр может обвинить в недобросовестной конкуренции, незаконном использовании коммерческой тайны (если разработчик расписался за её неразглашение) и много ещё в чем, вплоть до незаконного использования идеи как части произведения (программа с точки зрения права — произведение). Но если в каждом конкретном случае провести юридический анализ ситуации, то найти приемлемое решение можно. Спасибо за комментарий и за вопрос.
Любое использование исходника без согласия правообладателя (даже самим автором!) будет незаконным.
Если не ошибаюсь, то не любое. Автор может использовать «для себя» и для демонстрации.
Права автора произведения определены в ст. 1255 Гражданского кодекса. К ним относятся:
1) исключительное право на произведение;
2) право авторства;
3) право автора на имя;
4) право на неприкосновенность произведения;
5) право на обнародование произведения.
(плюс несколько дополнительных прав, например, право на вознаграждение за служебное произведение).
Все, что связано с использованием произведения, охватывается понятием «исключительное право». Но из пяти перечисленных выше прав автора именно исключительное право является отчуждаемым, т.е. может быть передано автором другому лицу. И уже все последующие отношения, связанные с использованием программы, будут определяться условиями такой передачи.
Право использования автором программы/произведения «для себя» (если автор не является правообладателем) по умолчанию (как нечто абсолютное и непререкаемое) законом не предусмотрено. Например, было бы странно, если бы созданное служебное произведение автор «унес» с работы домой и там начал его использовать «для себя». Но в случаях, когда изначально правообладателем был автор (а потом передал исключительные права кому-то другому), можно предположить, что даже после передачи исключительных прав автор продолжает оставаться правомерным обладателем экземпляра созданной им программы и на этом основании может продолжать пользоваться ею в личных целях (если явного запрета на это не предусмотрено условиями передачи прав).
Что касается «демонстрации», то ее нельзя путать с «правом на обнародование» (п. 5 ст. 1255, 1268 ГК). Я не хочу сказать, что автор программы вообще не может показать созданную им ранее программу (или ее фрагмент), скажем, при устройстве на работу, либо потенциальным заказчикам в качестве портфолио. Но здесь много «подводных граблей». Опять же — не окажется ли такая демонстрация, например, разглашением конфиденциальной информации (если было подписано соглашение о конфиденциальности)? Не будет ли это расценено правообладателем как неправомерное использование произведения? (вопрос о том, узнает он об этом или не узнает, оставим за рамками этого обсуждения) и т.д. Риски претензий возникают вполне реальные.
Здесь во всяком случае рекомендую включать в договоры на разработку ПО, предполагающие передачу исключительных прав на программу заказчику, условия о том, в каких случаях и в каком объеме разработчик программы сможет ее использовать (и сможет ли вообще) в личных и демонстрационных целях.
незаконном использовании коммерческой тайны (если разработчик расписался за её неразглашение)
Для этого, насколько я понимаю, на предприятии должен быть введен режим коммерческой тайны и какая-то существенная информация должна быть проведена как кт. Плюс разработчик должен явно поставить подпись на бумаге при получении доступа к экземпляру кт.
насколько я понимаю, на предприятии должен быть введен режим коммерческой тайны и какая-то существенная информация должна быть проведена как кт
Вы все правильно понимаете. Я написал «если разработчик расписался за ее неразглашение» для краткости, подразумевая при этом, что расписался он не на огрызке листочка в клеточку, а с соблюдением всех необходимых процедур. Многие фирмы «сыплются» на том, что работники у них в буквальном смысле «уводят» КТ, а когда с ними начинают судиться и требовать компенсации убытков за якобы разглашение КТ, выясняется, что в суд ничего кроме второпях настряпанного приказа, в котором расписался работник, и представить нечего — нет ни положения о КТ, ни перечня информации, ее составляющей, ни в трудовых договорах с работниками нет обязанности не разглашать КТ, ни соглашений о конфиденциальности, ни регламентов оборота информации и документов, составляющих КТ, ни доказательств получения работником доступа к КТ — ничего нет. И суды правильно приходят к выводу, что не было никакой КТ. Поэтому, разумеется, речь идет о режиме КТ. О том, как его правильно ввести, оформить и использовать, возможно, тоже напишу как-нибудь.
«Не отдать» исходники ему не удастся — раз программа зарегистрирована, их текст был представлен в Роспатент вместе с заявлением, а значит, они есть у заказчика.
Роспатент принимает только ограниченный размер исходного кода — до 70-ти страниц крупного текста (~50 строк на страницу) — т.е. ~3500 строк. Остальное депонируется за дополнительную оплату и на мой взгляд, крайне редко встречается даже у крупных компаний. 3500 строк кода — это чаще всего — «крохи» от реального объема программ. Поэтому сопоставление кодов в суде крайне маловероятный вариант.
«Не отдать» исходники ему не удастся — раз программа зарегистрирована, их текст был представлен в Роспатент вместе с заявлением, а значит, они есть у заказчика.
Вот тут на лицо какой-то наивный или устаревший подход. В общем случае программа — это огромное количество данных. Они не все текстовые и напечатать какие-то куски на 100500 страниц — это бред, на мой взгляд. Если бы речь шла о разработке какой-то достаточно статичной библиотеки или кодека — это ещё ок, но поднять большой сайт или сборку нативного приложения имея на руках только исходники, возможно даже без понимания как их применять — это довольно больно ударит по бизнесу, вернее фактически парализует его.
Если разработчик предполагает потенциальный вариант военных действий с владельцем бизнеса, то водить за нос последнего у него есть просто огромное количество возможностей:
— В исходники для заявки на регистрацию попадёт тонна макулатурных и фактически бесполезных данных, которые таковыми трудно признать без въедливого аудита.
— На прилагающийся диск с, якобы, актуальным исходным кодом продукта ляжет древняя ревизия из системы контроля версий.
— Явная или неявная обфускация, проведенная в «официальном» исходном коде сделает его бесполезным для интеграции другими программистами.
— За скобками системы контроля версий могут (умышленно или «нечаянно») остаться большие и важные пласты знаний и материалов, без которых осуществлять поддержку, а иногда даже и использование продукта, не говоря уже о развитии, становится примерно сопоставимым по затратам с написанием продукта заново (особенное если учесть наличие глубоко вовлеченного в предметную область и разработку продукта специалиста, пусть даже не программиста).
Я это к чему. Вроде понятие репозитория еще не прижилось в нормах юридической практики. Если программа для юристов — это буковки на листочках, то у меня плохие новости, есть докер-контейнеры, системы сборки и тестирования, аккаунты и виртуальные машины в амазоне или у других хостеров…
Когда речь о компании из нескольких человек, проводить профилактику против гипотетических конфликтов мудрый руководитель начнёт задолго до того, как они смогут больно долбануть по бюджету и продукту. И рычаг тут один — аккуратное разбавление незаменимых участников проекта
новыми грамотными специалистами плюс обучение молодых. Это дорого, но лишняя корзина для яиц может уберечь от потери всего.
Вот тут на лицо какой-то наивный или устаревший подход.
В данном случае я всего лишь исходил из того, что заказчик, решивший зарегистрировать программу на свое ООО, проявил достаточно благоразумия и осмотрительности, чтобы потребовать от исполнителя экземпляр программы, включающий в себя, согласно ГК, в том числе исходный код. Может быть, его юристы все-таки надоумили, а может, бухгалтер, которому нужно было оприходовать образовавшуюся интеллектуальную собственность. Про распечатывание всего программного кода от начала до конца на бумаге я не говорил.
Если разработчик предполагает потенциальный вариант военных действий с владельцем бизнеса, то водить за нос последнего у него есть просто огромное количество возможностей
Пост и комментарий — не про то, как «водить за нос» заказчика. Разумеется, если бы ко мне обратился разработчик в похожей ситуации и сказал, что письменного договора на разработку ПО с ним не заключалось, то я первое, что рекомендовал бы — ни в коем случае не передавать исходный код заказчику до прояснения ситуации.
В примерах, которые я привел в тексте, я специально оговорил, что между заказчиком и исполнителем сложились отношения взаимного доверия. И исполнитель, доверяя заказчику, исходный код ему передал «в обмен» на красивую должность, зарплату с бонусами и указание его в качестве автора. Ну, передал — молодец.
Насчет других «вождений за нос» — конечно, можно оставить заказчику обфусцированную версию (типа тоже исходник). Изначальный вопрос был не в том, что он с ней будет делать, а сможет ли юридически этот разработчик в дальнейшем использовать данную программу и безопасно для себя коммерциализировать ее? Я бы не советовал. Если дело дойдет до суда и суд назначит по делу судебно-техническую экспертизу, то разработчика, скорее всего, обяжут представить эксперту «нормальную» исходную версию, а из обфусцированной версии, имеющейся у заказчика, эксперты, скорее всего, смогут восстановить исходную версию с качеством, достаточным для того, чтобы определить, тождественны сравниваемые программы или нет. Тем более что сравниваться будут не только исходники, но и производные от них объектные коды, и алгоритмы, лежащие в основе программ, и порождаемые программами отображения — в общем, сравниваться будет все, что охватывается понятием «программа для ЭВМ» в юридическом смысле. И если тождество программ будет установлено, то разработчик, решивший «перехитрить» «лопуха»-заказчика, рискует попасть на нехилые деньги.
То же будет касаться и ситуации, если разработчик под видом исходника решит подсунуть заказчику что-то совершенно левое, лишь отдаленно напоминающее исходник программы и совершенно неработоспособное.
Если программа для юристов — это буковки на листочках
Перечитал еще раз то, что написал. Ни про буковки, ни про листочки у меня нет.
Хотя то, что Вы написали про юристов — отчасти на самом деле так. С точки зрения права на программы для ЭВМ распространяется режим литературных произведений. А значит, когда речь идет о программе как об объекте авторского права — это в определенном смысле действительно «буковки на бумажке», нравится это или нет.
понятие репозитория еще не прижилось в нормах юридической практики
Прижилось. В одном из дел, ссылки на которые я привел, разработчик, как и в нашей ситуации № 3, требовал признать недействительной регистрацию программы на работодателя и просил суд признать его автором и владельцем исключительных прав на программу, которую он якобы разработал сам еще до устройства на работу и «принес» ее с собой. Ответчик-работодатель представил суду в качестве доказательств распечатки журнала действий из системы контроля версий и тем самым доказал, что в создании программы участвовал не только истец, но и другие работники, а последняя версия практически ни в чем не была похожа на версию, первоначально написанную истцом. Работодатель суд выиграл. Как видите, даже «буковок на бумажках» не потребовалось.
проводить профилактику против гипотетических конфликтов мудрый руководитель начнёт задолго до того, как они смогут больно долбануть по бюджету и продукту
А здесь полностью согласен. Это и была главная мысль всего моего поста, Вы ее правильно уловили.
рычаг тут один — аккуратное разбавление незаменимых участников проекта
новыми грамотными специалистами плюс обучение молодых
Да, это эффективный рычаг. В деле, которое я кратко описал в предыдущем абзаце — ровно все так и произошло. Насчет того, что «единственный» — я бы поспорил. Но это уже вопрос стиля руководства.
Спасибо за комментарий.
Да все описанные истории — классика жанра. Более раскрученными являются истории с зарубежными стартапами (раскрутка таких историй иногда — часть раскрутки стартапа, порой грех не воспользоваться поводом!). Я лишь показал, как похожие ситуации разрешаются в Российской судебной практике. Спасибо за комментарий.
И правильно.
В РФ (и кстати в ЕС) такие вещи решаются совсем не так как в США.
Как обычно — «мне надо это, вот так, и это».
Отдаю плагин заказчику, чуть дорабатываю дизайн, функционал и выставляю на codecanyon. Я как разработчик нарушаю что либо?
Например запись к специалисту: алгоритм же один и тот же. Выбрал время, забронировал. И таких повторяющихся алгоритмов много. Это же не уникально. Я понимаю крупные игроки бодаются за дизайн кнопок — скругленная кнопка, квадратная. Теперь и разработать ничего нельзя чтобы не получить иск?
Из поста:
Читатели, хорошо знакомые с данной темой, могут возразить: идеи не охраняются авторским правом. Такой же позиции придерживался и ответчик. Но, по мнению российских судов, идеи не охраняются законом, пока не воплощены в конкретную форму. Если же результатом идеи стало конкретное произведение (в нашем примере – программа для ЭВМ), то сам замысел тоже может рассматриваться как часть творческого труда по его созданию. Без первоначального замысла Василия, — указал суд в решении, — Николай не написал бы соответствующую компьютерную программу, а без написанной Николаем компьютерной программы идея Василия осталась бы не нереализованной и не воплощенной в материальной форме. Суд решил, что программа была создана совместным творческим трудом Василия и Николая. К тому же, Василию принадлежала не только идея, но также разработка алгоритмов действия сервиса, руководствуясь которыми Николай и написал исходный код программы.
В данном случае суд решил, что это совместная разработка "заказчика" и "подрядчика", может решить, что только "заказчика", может, что только "подрядчика".
Если дело доходит до суда, то исход будет зависеть от:
А) заявленных истцом требований (суд всегда ограничен ими)
Б) выбранной истцом и ответчиком тактики защиты своих интересов
В) имеющихся у суда доказательств (которые были представлены сторонами)
Но вопрос не настолько простой. Например, запись на приём к врачу посредством веб-приложения (просто как идея, возможность, потребительское свойство программы) не охраняется авторским правом. Я не специалист по алгоритмированию, но мне кажется, что решение данной задачи может быть осуществлено далеко не одним только типовым алгоритмом. Точнее, алгоритм действий пользователя здесь может быть и один (выбрать врача — выбрать дату и т.д.), но я сейчас говорю об алгоритмах машинной обработки запросов пользователей — тех алгоритмов, на основе которых написаны исходники. А алгоритм уже — результат творческого труда и вполне может оказаться частью зарегистрированной на чьё-то имя программы для ЭВМ (в юридическом смысле программа — это не только исходник, но и в том числе подготовительные материалы, включая алгоритмы).
Поэтому иск от правообладателя, который «увидит» в Вашей программе свой алгоритм, не исключён (такие случаи были). Шансы защититься, впрочем, есть. Но лучше ещё до запуска проверить Ваш продукт на «чистоту» и оценить риски.
Работодатель-работник: если вы значитесь в штате как разработчик — по умолчанию права пренадлежат работодателю.
Заказчик-исполнитель: зависит от того, что оговорено в договоре. Обычно договор «на разработку ПО» идет с передачей исключительных прав.
«В черную»: все права принадлежат разработчику (заказчик может попробовать доказать в суде, что на самом деле он соавтор или даже автор).
У меня была одна обратная история — я сделал небольшой плагин, а заказчик выставил его на подобную площадку, ничего не сказав и не предупредив.
Заодно указал свою студию в виде автора/разработчика. Деньги небольшие, плагин маленький — ссориться не стали, но осадочек остался.
* Не веди дела с друзьями (отношения могут сильно испортиться);
* Если с кем-то что-то делаешь, что для тебя критически важно: фиксируй на бумаге (хоть формально, но доказательство согласия);
* Если делали всё на дружбе и дело вдруг попёрло: разграничивайте на бумаге всё-всё (от вложенных сил и средств до обязанностей и их соотношении в общем деле). Да, очень неприятная процедура, но позволит избежать в будущем недоговорённостей и более неприятных последствий;
* Если идея твоя, то сам ищи деньги и полностью владей всем (ООО, к примеру, единолично на себя).
Они могут испортиться и от того, что ты отказался начинать с ними дело, а взял в партнеры кого-то со стороны )
Насчет последнего тезиса (идея твоя -сам ищи деньги и полностьювсем владей) — он верен не всегда, но в России часто именно такая модель стартапов оказывается более жизнеспособной, ставя в тупик тех, кто учился по американским учебникам. Периодически я рекомендую использовать именно её — в зависимости от конкретных условий. Наша беда в том, что мы любим делить, толком ещё ничего не заработав.
Я не знаю, как оно в Америке, более того не так хорошо знаком с их законодательством и налоговой системой и сказать про это ничего не могу. Думается мне, что те, кто начинал там, либо по их учебникам, округляют здесь глаза, так как всё совсем не так. Не могу сказать, что меня увлекало чтение книг наших бизнесменов, но и их советы лучше не принимать на веру как истину, а критически рассматривать. Более того, есть тонкости, связанные с налогообложением (к примеру, ООО, когда не владея 51% доли, вы не можете без подоходного налога внести личные средства насчёт компании), что порождает ненужные издержки, в условиях нехватки финансов. Тонкостей таких у нас предостаточно. Это первое.
Второе. Всегда должен быть лидер в компании, который мотивирует других на достижение целей. Не нужно порождать коллективной (колхозной) ответственности, а, наоборот, максимально разграничивать ответственность, хотя это и трудно в компании из двух-трёх человек.
Не веди дела с друзьями
И родственниками. Наблюдал распад небольшой компании на две, с разделом имущества. Владельцы первоначальной компании — брат и сестра.
Вася и Петя решили запустить мега стартап. Вася занимается офлайн частью, а Петня — онлайн и веб-разработкой. Все юридические регистрации и проводки идут на ИП Васи.
Доступ на сервера есть у обоих, но у Пети на домашнем компьютере есть «настоящие» исходники, а на вебсервере находится только минифицированная, обфусцированная версия скриптов (допустим JS).
Вася с Петей ссорятся и Васе остается рабочий, но обфусцированный веб-сервис. А Петя имеет на руках все исходники.
Вопрос: Если Петя поменяет название и дизайн, а так же изменит алгоритм обфускации, как можно доказать, что Петя использует ту же программу, что и Вася? Причем Петя может ее дорабатывать, а Вася… скорее всего нет.
И что им за это будет?
есть такое понятие, как «производная работа», включающая себя в том числе даже переписывание на другой язык. Если суд примет решение, что это производная работа от Васиного сервиса, то, несмотря на то, что права на саму производную работу будут у Пети, то Вася сможет диктовать Пети условия касательно переписанного сервиса.
Разница между между fair use и производной работой бывает довольно тонкой, но чаще всего идет вопрос насколько один сервис в части функциональности копирует другой. Т.е. если после сравнения первого и второго сервисов осталось впечатление, что второй сервис — ровно тоже самое, но в другой оболочке — то это производная работа.
Другой момент, что во время доработки функционал у Пети сможет довольно сильно изменится с течением времени, и тогда это будет уже fair use (заимствование идей не возбраняется).
Тут при конфликте такому программисту не требуется ни винт форматровать, ни бэкдоров оставлять для вредительства. Уход такого «специалиста» (а если философски подойти, то скорее приход его) автоматически несет массу неудобств.
А вот ситуация, когда у человека есть идея, но нет ресурсов на ее реализацию достаточно частая. Тут и получается, что он ищет разработчиков(если таковых нет среди его друзей и знакомых) на стороне, которые будут работать на перспективу( «за еду»), но зато будут партнерами. Если повезет, то такой стартап станет серьезным, кто-то посчитает что он сделал больше и тогда конфликт неизбежен…
Тут и получается, что он ищет разработчиков(если таковых нет среди его друзей и знакомых) на стороне, которые будут работать на перспективу( «за еду»), но зато будут партнерами.
Аттракцион неслыханной щедрости какой-то! Мне таких предложений поступает очень много, даже за год минимум 2-3 проскакивает. Причём, когда уточняешь у человека, будем ли фиксировать это, то он так хмурит бровки и становится серьёзным: «ты меня не знаешь, что ли? Не уважаешь?» И не припомню, чтобы кто-то из них успешно развился.
Сплошь и рядом "генераторы идей" ищут того, кто воплотит их идею в жизнь за долю в будущей прибыли. Не имея возможности или просто не желая платить рыночную зарплату специалисту(ам) нужного уровня. Вернее, начинают искать, когда понимают, что за 100 рублей в час (после обвала рубля, раньше на 50 искали максимум) никто этим заниматься не будет, или начнёт, но результата нормального не будет.
100 рублей в час — это 16 тысяч рублей в месяц.
Именно столько и предлагают многие "генераторы идеи". На порядок больше предложить не могут или не хотят (очень малое число авторов идей "стопудово взлетит, разбогатеем как Дуров" готовы хотя бы заложить своё единственное жильё для получения приличного стартового капитала). Когда никого не находят или помучаются с каким-нибудь начинающим фрилансером, то становятся щедрыми и предлагают долю в прибылях, вплоть до 49%, иногда даже вдобавок к изначальным 100 рублям в час, хотя часто просто долю..
Очень полезная и поучительная информация но хотелось бы, чтобы вы написали и возможные варианты недопущения подобных ошибок с примерами (и\или ссылками на сайт) договорв, последовательности действий и т.д. спасибо
Моя — идея, твоя — программа, или три реальные истории о том, как автор идеи и разработчик делили в суде стартап