Pull to refresh

Comments 55

Интересно, что будет для 3-го случая если разработчик заберет (не отдаст) исходники и запустит конкурирующую компанию?
Не самый лучший вариант. Ведь программа (включая исходники) в 3-м случае уже зарегистрирована на имя ООО как правообладателя. Любое использование исходника без согласия правообладателя (даже самим автором!) будет незаконным. Это грабли, на которые наступают, к сожалению, очень часто. Исключительное право на использование программы (и любого другого результата интеллектуальной деятельности) далеко не всегда принадлежит автору, а авторство не означает неограниченного использования (если правообладатель и автор — разные лица).
«Не отдать» исходники ему не удастся — раз программа зарегистрирована, их текст был представлен в Роспатент вместе с заявлением, а значит, они есть у заказчика.

Хотя, конечно, я бы предложил разработчику некоторые решения. Можно переработать алгоритм и написать новый исходник (лучше на другом языке). Тоже рискованно — бывший партнёр может обвинить в недобросовестной конкуренции, незаконном использовании коммерческой тайны (если разработчик расписался за её неразглашение) и много ещё в чем, вплоть до незаконного использования идеи как части произведения (программа с точки зрения права — произведение). Но если в каждом конкретном случае провести юридический анализ ситуации, то найти приемлемое решение можно. Спасибо за комментарий и за вопрос.
Любое использование исходника без согласия правообладателя (даже самим автором!) будет незаконным.


Если не ошибаюсь, то не любое. Автор может использовать «для себя» и для демонстрации.
Спасибо за комментарий.
Права автора произведения определены в ст. 1255 Гражданского кодекса. К ним относятся:
1) исключительное право на произведение;
2) право авторства;
3) право автора на имя;
4) право на неприкосновенность произведения;
5) право на обнародование произведения.
(плюс несколько дополнительных прав, например, право на вознаграждение за служебное произведение).
Все, что связано с использованием произведения, охватывается понятием «исключительное право». Но из пяти перечисленных выше прав автора именно исключительное право является отчуждаемым, т.е. может быть передано автором другому лицу. И уже все последующие отношения, связанные с использованием программы, будут определяться условиями такой передачи.

Право использования автором программы/произведения «для себя» (если автор не является правообладателем) по умолчанию (как нечто абсолютное и непререкаемое) законом не предусмотрено. Например, было бы странно, если бы созданное служебное произведение автор «унес» с работы домой и там начал его использовать «для себя». Но в случаях, когда изначально правообладателем был автор (а потом передал исключительные права кому-то другому), можно предположить, что даже после передачи исключительных прав автор продолжает оставаться правомерным обладателем экземпляра созданной им программы и на этом основании может продолжать пользоваться ею в личных целях (если явного запрета на это не предусмотрено условиями передачи прав).

Что касается «демонстрации», то ее нельзя путать с «правом на обнародование» (п. 5 ст. 1255, 1268 ГК). Я не хочу сказать, что автор программы вообще не может показать созданную им ранее программу (или ее фрагмент), скажем, при устройстве на работу, либо потенциальным заказчикам в качестве портфолио. Но здесь много «подводных граблей». Опять же — не окажется ли такая демонстрация, например, разглашением конфиденциальной информации (если было подписано соглашение о конфиденциальности)? Не будет ли это расценено правообладателем как неправомерное использование произведения? (вопрос о том, узнает он об этом или не узнает, оставим за рамками этого обсуждения) и т.д. Риски претензий возникают вполне реальные.

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

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

насколько я понимаю, на предприятии должен быть введен режим коммерческой тайны и какая-то существенная информация должна быть проведена как кт


Вы все правильно понимаете. Я написал «если разработчик расписался за ее неразглашение» для краткости, подразумевая при этом, что расписался он не на огрызке листочка в клеточку, а с соблюдением всех необходимых процедур. Многие фирмы «сыплются» на том, что работники у них в буквальном смысле «уводят» КТ, а когда с ними начинают судиться и требовать компенсации убытков за якобы разглашение КТ, выясняется, что в суд ничего кроме второпях настряпанного приказа, в котором расписался работник, и представить нечего — нет ни положения о КТ, ни перечня информации, ее составляющей, ни в трудовых договорах с работниками нет обязанности не разглашать КТ, ни соглашений о конфиденциальности, ни регламентов оборота информации и документов, составляющих КТ, ни доказательств получения работником доступа к КТ — ничего нет. И суды правильно приходят к выводу, что не было никакой КТ. Поэтому, разумеется, речь идет о режиме КТ. О том, как его правильно ввести, оформить и использовать, возможно, тоже напишу как-нибудь.
Насколько я знаю, для регистрации ПО требуют порядка 50 страниц А4 листинга кода, что составляет пренебрежимо малую часть проекта и может быть легко заменено.
Сейчас, согласно правилам, действующим с прошлого года, заявитель сам определяет объём депонируемого исходного года, достаточного по его мнению для идентификации программы. До этого действительно было ограничение в 70 страниц, сейчас оно снято.
«Не отдать» исходники ему не удастся — раз программа зарегистрирована, их текст был представлен в Роспатент вместе с заявлением, а значит, они есть у заказчика.

Роспатент принимает только ограниченный размер исходного кода — до 70-ти страниц крупного текста (~50 строк на страницу) — т.е. ~3500 строк. Остальное депонируется за дополнительную оплату и на мой взгляд, крайне редко встречается даже у крупных компаний. 3500 строк кода — это чаще всего — «крохи» от реального объема программ. Поэтому сопоставление кодов в суде крайне маловероятный вариант.
Сейчас ограничения в объеме депонируемого материала нет, достаточность фрагмента для идентификации определяет правообладатель. В ответе на предыдущий комментарий я дал ссылку на действующий порядок, он вступил в силу в июле прошлого года.
«Не отдать» исходники ему не удастся — раз программа зарегистрирована, их текст был представлен в Роспатент вместе с заявлением, а значит, они есть у заказчика.

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

Если разработчик предполагает потенциальный вариант военных действий с владельцем бизнеса, то водить за нос последнего у него есть просто огромное количество возможностей:
— В исходники для заявки на регистрацию попадёт тонна макулатурных и фактически бесполезных данных, которые таковыми трудно признать без въедливого аудита.
— На прилагающийся диск с, якобы, актуальным исходным кодом продукта ляжет древняя ревизия из системы контроля версий.
— Явная или неявная обфускация, проведенная в «официальном» исходном коде сделает его бесполезным для интеграции другими программистами.
— За скобками системы контроля версий могут (умышленно или «нечаянно») остаться большие и важные пласты знаний и материалов, без которых осуществлять поддержку, а иногда даже и использование продукта, не говоря уже о развитии, становится примерно сопоставимым по затратам с написанием продукта заново (особенное если учесть наличие глубоко вовлеченного в предметную область и разработку продукта специалиста, пусть даже не программиста).

Я это к чему. Вроде понятие репозитория еще не прижилось в нормах юридической практики. Если программа для юристов — это буковки на листочках, то у меня плохие новости, есть докер-контейнеры, системы сборки и тестирования, аккаунты и виртуальные машины в амазоне или у других хостеров…
Когда речь о компании из нескольких человек, проводить профилактику против гипотетических конфликтов мудрый руководитель начнёт задолго до того, как они смогут больно долбануть по бюджету и продукту. И рычаг тут один — аккуратное разбавление незаменимых участников проекта
новыми грамотными специалистами плюс обучение молодых. Это дорого, но лишняя корзина для яиц может уберечь от потери всего.
Вот тут на лицо какой-то наивный или устаревший подход.


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

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


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

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

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

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

Если программа для юристов — это буковки на листочках


Перечитал еще раз то, что написал. Ни про буковки, ни про листочки у меня нет.

Хотя то, что Вы написали про юристов — отчасти на самом деле так. С точки зрения права на программы для ЭВМ распространяется режим литературных произведений. А значит, когда речь идет о программе как об объекте авторского права — это в определенном смысле действительно «буковки на бумажке», нравится это или нет.

понятие репозитория еще не прижилось в нормах юридической практики


Прижилось. В одном из дел, ссылки на которые я привел, разработчик, как и в нашей ситуации № 3, требовал признать недействительной регистрацию программы на работодателя и просил суд признать его автором и владельцем исключительных прав на программу, которую он якобы разработал сам еще до устройства на работу и «принес» ее с собой. Ответчик-работодатель представил суду в качестве доказательств распечатки журнала действий из системы контроля версий и тем самым доказал, что в создании программы участвовал не только истец, но и другие работники, а последняя версия практически ни в чем не была похожа на версию, первоначально написанную истцом. Работодатель суд выиграл. Как видите, даже «буковок на бумажках» не потребовалось.

проводить профилактику против гипотетических конфликтов мудрый руководитель начнёт задолго до того, как они смогут больно долбануть по бюджету и продукту


А здесь полностью согласен. Это и была главная мысль всего моего поста, Вы ее правильно уловили.

рычаг тут один — аккуратное разбавление незаменимых участников проекта
новыми грамотными специалистами плюс обучение молодых


Да, это эффективный рычаг. В деле, которое я кратко описал в предыдущем абзаце — ровно все так и произошло. Насчет того, что «единственный» — я бы поспорил. Но это уже вопрос стиля руководства.

Спасибо за комментарий.
UFO just landed and posted this here
Да все описанные истории — классика жанра. Более раскрученными являются истории с зарубежными стартапами (раскрутка таких историй иногда — часть раскрутки стартапа, порой грех не воспользоваться поводом!). Я лишь показал, как похожие ситуации разрешаются в Российской судебной практике. Спасибо за комментарий.
Да все описанные истории — классика жанра. Более раскрученными являются истории с зарубежными стартапами (раскрутка таких историй иногда — часть раскрутки стартапа, порой грех не воспользоваться поводом!). Я лишь показал, как похожие ситуации разрешаются в Российской судебной практике. Спасибо за комментарий.


И правильно.
В РФ (и кстати в ЕС) такие вещи решаются совсем не так как в США.
Учитывая многообразие жизни, принцип один — Сарочка была умная потом
Вот по исключительным правам интересно.Например: на фрилансе я по заказу делаю плагин. Про исключительные права и прочее ничего не обговаривалось.
Как обычно — «мне надо это, вот так, и это».
Отдаю плагин заказчику, чуть дорабатываю дизайн, функционал и выставляю на codecanyon. Я как разработчик нарушаю что либо?
По ст 1296 нарушаете права заказчика, если предметом заказа была разработка плагина, а не доработка сайта заказчика, которую вы решили выполнить, создав плагин.
А если так: создание нового продукта повторяющего функционал старого — не является нарушением?

Например запись к специалисту: алгоритм же один и тот же. Выбрал время, забронировал. И таких повторяющихся алгоритмов много. Это же не уникально. Я понимаю крупные игроки бодаются за дизайн кнопок — скругленная кнопка, квадратная. Теперь и разработать ничего нельзя чтобы не получить иск?

Из поста:


Читатели, хорошо знакомые с данной темой, могут возразить: идеи не охраняются авторским правом. Такой же позиции придерживался и ответчик. Но, по мнению российских судов, идеи не охраняются законом, пока не воплощены в конкретную форму. Если же результатом идеи стало конкретное произведение (в нашем примере – программа для ЭВМ), то сам замысел тоже может рассматриваться как часть творческого труда по его созданию. Без первоначального замысла Василия, — указал суд в решении, — Николай не написал бы соответствующую компьютерную программу, а без написанной Николаем компьютерной программы идея Василия осталась бы не нереализованной и не воплощенной в материальной форме. Суд решил, что программа была создана совместным творческим трудом Василия и Николая. К тому же, Василию принадлежала не только идея, но также разработка алгоритмов действия сервиса, руководствуясь которыми Николай и написал исходный код программы.

В данном случае суд решил, что это совместная разработка "заказчика" и "подрядчика", может решить, что только "заказчика", может, что только "подрядчика".

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

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

Но вопрос не настолько простой. Например, запись на приём к врачу посредством веб-приложения (просто как идея, возможность, потребительское свойство программы) не охраняется авторским правом. Я не специалист по алгоритмированию, но мне кажется, что решение данной задачи может быть осуществлено далеко не одним только типовым алгоритмом. Точнее, алгоритм действий пользователя здесь может быть и один (выбрать врача — выбрать дату и т.д.), но я сейчас говорю об алгоритмах машинной обработки запросов пользователей — тех алгоритмов, на основе которых написаны исходники. А алгоритм уже — результат творческого труда и вполне может оказаться частью зарегистрированной на чьё-то имя программы для ЭВМ (в юридическом смысле программа — это не только исходник, но и в том числе подготовительные материалы, включая алгоритмы).

Поэтому иск от правообладателя, который «увидит» в Вашей программе свой алгоритм, не исключён (такие случаи были). Шансы защититься, впрочем, есть. Но лучше ещё до запуска проверить Ваш продукт на «чистоту» и оценить риски.
ЕМНИП все зависит от того, как оформлены ваши отношения с заказчиком/биржей.

Работодатель-работник: если вы значитесь в штате как разработчик — по умолчанию права пренадлежат работодателю.
Заказчик-исполнитель: зависит от того, что оговорено в договоре. Обычно договор «на разработку ПО» идет с передачей исключительных прав.
«В черную»: все права принадлежат разработчику (заказчик может попробовать доказать в суде, что на самом деле он соавтор или даже автор).

У меня была одна обратная история — я сделал небольшой плагин, а заказчик выставил его на подобную площадку, ничего не сказав и не предупредив.
Заодно указал свою студию в виде автора/разработчика. Деньги небольшие, плагин маленький — ссориться не стали, но осадочек остался.
Вспоминается наш опыт. В чём-то успешный, в чём-то — не особо. Да, мы чуть-чуть заработали, но главное, что вынес для себя:
* Не веди дела с друзьями (отношения могут сильно испортиться);
* Если с кем-то что-то делаешь, что для тебя критически важно: фиксируй на бумаге (хоть формально, но доказательство согласия);
* Если делали всё на дружбе и дело вдруг попёрло: разграничивайте на бумаге всё-всё (от вложенных сил и средств до обязанностей и их соотношении в общем деле). Да, очень неприятная процедура, но позволит избежать в будущем недоговорённостей и более неприятных последствий;
* Если идея твоя, то сам ищи деньги и полностью владей всем (ООО, к примеру, единолично на себя).
>* Не веди дела с друзьями (отношения могут сильно испортиться);
Они могут испортиться и от того, что ты отказался начинать с ними дело, а взял в партнеры кого-то со стороны )
Спасибо за комментарий. Соглашусь, что лучше по возможности все фиксировать на бумаге. Даже с друзьями. Что касается друзей — мне известны примеры, когда успешные стартапы организовывались давними друзьями. Главное в этом случае — разграничивать «дружбу» и«дело». Поэтому когда я даю консультации и разрабатываю юридические модели стартапов — узнаю в том числе и характер личных отношений между партнерами. Это тоже имеет значение.

Насчет последнего тезиса (идея твоя -сам ищи деньги и полностьювсем владей) — он верен не всегда, но в России часто именно такая модель стартапов оказывается более жизнеспособной, ставя в тупик тех, кто учился по американским учебникам. Периодически я рекомендую использовать именно её — в зависимости от конкретных условий. Наша беда в том, что мы любим делить, толком ещё ничего не заработав.
Договорённость и бухгалтерия должна возникать с момента начала совместной работы над идеей, или максимально быстро. Всюду находятся, как исключения, так и подтверждение истин. У кого это проходило не так гладко, вырабатывается своеобразный «иммунитет», чтобы не быть «кинутым» в очередной раз.

Я не знаю, как оно в Америке, более того не так хорошо знаком с их законодательством и налоговой системой и сказать про это ничего не могу. Думается мне, что те, кто начинал там, либо по их учебникам, округляют здесь глаза, так как всё совсем не так. Не могу сказать, что меня увлекало чтение книг наших бизнесменов, но и их советы лучше не принимать на веру как истину, а критически рассматривать. Более того, есть тонкости, связанные с налогообложением (к примеру, ООО, когда не владея 51% доли, вы не можете без подоходного налога внести личные средства насчёт компании), что порождает ненужные издержки, в условиях нехватки финансов. Тонкостей таких у нас предостаточно. Это первое.

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


И родственниками. Наблюдал распад небольшой компании на две, с разделом имущества. Владельцы первоначальной компании — брат и сестра.
И родственниками. Наблюдал распад небольшой компании на две, с разделом имущества. Владельцы первоначальной компании — брат и сестра.

Кумовство в самом начале встречал редко, а после развития — часто. Могу сказать так: бежать из этой компании при первой возможности.
Представим следующий вариант:
Вася и Петя решили запустить мега стартап. Вася занимается офлайн частью, а Петня — онлайн и веб-разработкой. Все юридические регистрации и проводки идут на ИП Васи.

Доступ на сервера есть у обоих, но у Пети на домашнем компьютере есть «настоящие» исходники, а на вебсервере находится только минифицированная, обфусцированная версия скриптов (допустим JS).

Вася с Петей ссорятся и Васе остается рабочий, но обфусцированный веб-сервис. А Петя имеет на руках все исходники.

Вопрос: Если Петя поменяет название и дизайн, а так же изменит алгоритм обфускации, как можно доказать, что Петя использует ту же программу, что и Вася? Причем Петя может ее дорабатывать, а Вася… скорее всего нет.

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

Аттракцион неслыханной щедрости какой-то! Мне таких предложений поступает очень много, даже за год минимум 2-3 проскакивает. Причём, когда уточняешь у человека, будем ли фиксировать это, то он так хмурит бровки и становится серьёзным: «ты меня не знаешь, что ли? Не уважаешь?» И не припомню, чтобы кто-то из них успешно развился.
Мне казалось, что чаще друга-программиста удается найти.

Сплошь и рядом "генераторы идей" ищут того, кто воплотит их идею в жизнь за долю в будущей прибыли. Не имея возможности или просто не желая платить рыночную зарплату специалисту(ам) нужного уровня. Вернее, начинают искать, когда понимают, что за 100 рублей в час (после обвала рубля, раньше на 50 искали максимум) никто этим заниматься не будет, или начнёт, но результата нормального не будет.

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

Именно столько и предлагают многие "генераторы идеи". На порядок больше предложить не могут или не хотят (очень малое число авторов идей "стопудово взлетит, разбогатеем как Дуров" готовы хотя бы заложить своё единственное жильё для получения приличного стартового капитала). Когда никого не находят или помучаются с каким-нибудь начинающим фрилансером, то становятся щедрыми и предлагают долю в прибылях, вплоть до 49%, иногда даже вдобавок к изначальным 100 рублям в час, хотя часто просто долю..

Вот мы подходим к другой важной составляющей, которая отсекает эмоциональность и ангажированность «генератора идей» (да точно взлетит, я проверял!). Называется она финансовая ответственность за результат. Это видно практически сразу: вам обещают золотые горы, когда взлетит, а на вопросы о том «что будет если» — отмахиваются. Лучше тактично попросить поискать в другом месте.

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

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

И туда же сразу личные права и отчуждаемые.

UFO just landed and posted this here
Да, как вариант — «аккаунт не мой, впервые вижу». Но такие утверждения надо соотносить с другими доказательствами, которые есть в деле.
Вспоминается известная история двух братьев, заказавших Цукербергу прообраз Фейсбука :)
Уже интересно, поделитесь вкратце с общественностью плиз, а-то она как-то прошла мимо меня :/
Ах да, действительно, спасибо, не провел параллели…
Тут даже, скорее, Эдуардо вспоминается, а не братишки :)
Sign up to leave a comment.

Articles