Архив недели @twit_iggy
Вторник
Привет, я Игорь - корпоративный юрист, который в свое время ушел в собственный IT-бизнес. Шишки были набиты в огромном количестве, постараюсь поговорить тут о практичном. Буду говорить не о чистых юризмах, а о базовых принципах, которые позволят вам себя обезопасить.
Как повод для начала использую хайповую тему прошлой недели - историю с рамблером и nginx, тем более, что сегодня рамблер еще на твитч решил напасть. Итак, чем показательна история с nginx:
если вы создали свой продукт и пытаетесь начать его каким-то образом предлагать миру, попытки предъявить права на него, откусить кусок, забрать etc. будут расти в геометрической прогрессии вместе с ростом его стоимости - это обычный ход вещей.
в истории любого софта можно найти хвосты, важно понимать базовые вещи касательно его юридической чистоты, особенно на ранних этапах, когда он делается параллельно с работой или происходит реиспользование кода в нескольких проектах, особенно тех, которые продаются за деньги
не менее важна защищенность и прозрачность, когда вы делаете продукт в партнерстве или подключаете к созданию первых наемных работников, когда шишки еще не набиты, а траты сил и времени на юридическую защищенность кажутся ненужной бюрократией
Шумиха в конкретном случае с nginx вызвана текущими реалиями и попыткой в очередной раз решить экономический спор с помощью силовых структур на фоне ухода инвесторов с рынка; если бы ситуация произошла году в 2010 и началось с гражданского суда, резонанса почти точно не было бы
то есть, если задумываетесь или уже создаете и, тем более, продаете свое решение, вы должны понимать, что попытка в любой форме откусить кусок ваших благ с использованием юридических процедур становится почти неизбежной
Я планирую взять тему защиты авторских прав на ваш продукт и минимизацию рисков, как основу и порассуждать по следующим направлениям в этом ключе:
Во-первых, рассмотрим группу рисков, связанных с работой по трудовому договору - эта ветка во многом краеугольно отличается от регулирования работы по другим видам гражданско-правовых договоров.
Ниже темы, которые планирую в той или иной степени зацепить, поскольку этот тред вводный - был бы рад собрать фидбэк, что интереснее, а что нет
- страшилки в трудовом договоре: реальные и мифические
- должностные инструкции и как с ними жить
- регулирование авторских прав по проделанной вами работе
- ограничения на работу у конкурентов, разработку конкурирующих продуктов, ведение своих проектов во внерабочее время
- конфликты в процессе работы, что из бюрократии нужно соблюдать, чтобы минимизировать последствия для себя
- конфликты при увольнении и после
- какиш шагов нельзя предпринимать в процессе конфликта с работодателем, дабы не вырыть себе самому яму
- риски «болтовни», последствия и виды ответственности: разглашение коммерческой тайны, нанесение ущерба деловой репутации, причинение убытков
- Разбираем типовые вещи в NDA: что опасно, а что – просто страшилка
Можете добавлять в этот тред ваши пожелания, какие темы еще в рамках именно трудового договора затронуть, в течение дня вторника я их обработаю и ночью выпущу
Помимо особенностей трудовых отношений, отдельная ветка будет посвящена защите вашего продукта в гражданско-правовых отношениях вцелом, но она настолько огромна, что опять же, пока выбираю самое интересное, буду рад вопросам в части того, что важно для вас
Тред (@twit_iggy)
Среда
@jsunderhood @nekrtemplar Добрый вечер! Расскажите пожалуйста, как писать код, не нарушая авторских прав, если ты такой функционал уже писал, работая в другой компании и он как бы принадлежит ей. Изменять названия переменных? Пытаться переделать логику?
Хороший вопрос от @xensola , о том, как писать код, не нарушая прав на аналогичный по функционалу, написанный ранее для предыдущего работодателя. Самое сложное - ответить на него хоть как-то коротко, выделяю в отдельный трэд. twitter.com/xensola/status…
Формальный ответ: в идеале писать заново - менять и логику и названия. Но идеального мира не существует, поэтому важны детали.
За исключением всего, что отдельно предусмотрено законом именно в части защиты софта, на защиту кода распространяются общие правила в части защиты литературных произведений (понятно почему, и там и там речь хоть и о специфических, но языках и произведениях на их основе)
Что касается кода тут прямая аналогия с литературным плагиатом или с самоплагиатом, если говорить совсем грубо. Поэтому по-максимуму выбрасываем 100%-ные заимствования минимально значимых блоков вашего авторства.
Что понимать под “блоком” - зависит от функционала, логики, архитектуры и пр. Но вцелом, только вам, как автору старого и нового кода оценивать степень его реиспользования. Но более важно тут другое:
Судья в случае спора о правах почти неизбежно будет руководствоваться результатами внешней экспертизы кода на предмет заимствований и значимости таких заимствований для функционала софта вцелом.
Важны будут также выводы о том, является ли функционал написанного для вашего нового работодателя результатом переработки предыдущего кода, степени его реиспользования и т.д. и т.п.
Спор будет происходить между старым и новым работодателем, но если новый работодатель проиграет, высоки риски, что, помимо гражданско-правовой ответственности, потерпевшая сторона решит инициировать уголовную и адм ответственность конечных причастных лиц
Такие шансы всегда есть, потому что это очень хороший пример и инструмент давления на всех последующих разработчиков, дополнительный аргумент, чтобы "уносили" меньше кода, конфиденциальной информации и пр
Ситуация, когда разработчиком в компанию берут именно потому, что он уже писал аналогичный код раньше у конкурента и самыми разными способами побуждают его к реиспользованию или “незначительно поменять и тогда не докопаются” - встречается на каждом шагу.
При этом надо понимать, что менеджеры, которые побуждают к этому, часто в рамках должности и обязанностей всегда могут сказать, что не имели к этому отношения, если у вас нет никакого подтверждения, что было указание реализовывать проект схожим способом .
Если вы понимаете, что в силу тех или иных причин идете на риск, старайтесь себя обезопасить в т.ч. на уровне документооборота:просите письменное служебное задание (или его аналог) в форме и виде, который гарантированно сможет остаться у вас и на который потом сможете сослаться
На бытовом уровне это чтобы у вас была возможность сказать: “Вот документ такой-то от такого-то моего руководителя от такого-то числа, в котором мне поручается реализовать такой-то функционал в такой-то архитектуре, с такой-то логикой, с применением таких-то языков и т.д.”
В острых случаях, если возникает конфликт/напряженность по сабжу с непосредственным руководителем, можно пойти к его вышестоящему руководителю или в ответственный отдел (несколько отделов):
например, служебная записка начальнику департамента о том, что начальник отдела требует от меня такой-то реализации и реиспользования кода, которая несет такие-то риски с копией этой же записки в юридический отдел.
На копии записки, которая остается у вас надо получить отметки о получении или реквизиты официальной регистрации в документообороте, если они есть. Зависит от особенностей документооборота, который у вашего работодателя принят.
Если у вас в компании есть юротдел, не бойтесь обращаться туда за консультацией: юристов, как правило, никто не любит со шкалой “от легкого неприятия” до “лютой ненависти”. Поэтому юротделу в этой ситуации, зачастую наплевать на конкуренцию внутри бизнесовых отделов и
между отделами, они отвечают в конечном итоге за то, чтобы верховное руководство понимало риски и потенциальные убытки, поэтому всегда есть шанс, что получите нормальную консультацию и, может быть, даже поддержку.
Также все вышеописанное не значит, что надо идти сразу на открытый конфликт, как правило это может решаться на уровне обычного взаимодействия внутри.
но просьба задокументировать и зарегистрировать в том или ином виде требование, которое вы считаете незаконным или потенциально несущим риски для вас и работодателя - важный и эффективный инструмент, о нем надо помнить.
Чем больше и востребованней на рынке проект и крупнее и известнее предыдущий и новый работодатель, тем выше риски негативных последствий, связанные с реиспользованием кода.
В случаях если у вас переход из одного маленького стартапа в другой с небольшой командой, где нет толком документооборота и прописанных процедур, можно пробовать получить аналогичную бумажку напрямую у генерального или техдира, важно, чтобы это было официально вышестоящее лицо.
Это одна из миллиона причин, о которой в соседнем треде будет о том, почему вы должны хотя бы вцелом понимать содержание вашей должностной инструкции, правил внутреннего трудового распорядка и прочих скучных документов, которые вам дают для ознакомления под роспись.
Не ругайте за слово “бумажки”, уведомления могут быть и с использованием электронных каналов, от почты до внутренних систем, но, в зависимости от степени риска, в голове всегда нужно держать возможность или невозможность вынуть электронные копии в верифицируемом виде
из таких каналов у тех,под чьим контролем они находятся, останется ли у вас возможность заверить электронную переписку у нотариуса после отключения вам доступов и т.д. Но это отдельная ветка, мы тут приближаемся к треду о конфликтах, он у меня на конец недели запланирован.
тема вцелом необъятная, спрашивайте, на что успею - отвечу, просто параллельно предновогодняя жесть :)
Тред (@twit_iggy)
Ветка по трудовым отношениям. Спасибо за комментарии, касательно вычитки трудового договора мнения, как и ожидалось, разделились на полярные: активные “читаю и прошу поменять,” и фаталисты “а смысл, все равно пошлют в сад”. Ниже начало треда по этой теме, оно будет дополняться.
Читать надо, но будьте готовы, что у ряда работодателей, если вы соберетесь прочитать всё, что регулирует вас внутри компании, рискуете потратить на это год или стать параноиком. Попробую составить список (понятно, не исчерпывающий) того, на что обращать внимание
Для начала немного о том, почему все-таки "надо":
а) это ваши деньги и время вашей жизни, потраченное на коммерческие интересы чужих вам людей
б) процент случаев, когда работодатель идет навстречу и удовлетворяет часть ваших разумных замечаний не так ничтожно мал как вам кажется, потому что вы ему потенциально нужны
в) понятно, что на стадии трудоустройства - это, возможно, работодатель вашей мечты, но со временем всё достаточно быстро меняется и усложняется; когда случается конфликт (а это сплошь и рядом) у работодателя готова библиотека ваших обязательств, о которых в не не знаете
г) если при расторжении трудовых отношений есть возможность лишить увольняющегося обещанных при начале отношений бонусов, парашютов, компенсаций, неиспользованных отпусков - чаще всего это происходит
д) когда происходит конфликтная ситуация с работодателем, доступ к документации волшебным образом почему-то магически усложняется, а она ваи в этот момент становится критично нужна
Этот список можно продолжать долго, но общий смысл его таков: что чтение и/или понимание матрицы регулирующих ваши отношения с работодателем документов - не самый маловажный вопрос вашей безопасности, спокойствия и финансового благополучия.
Обязательно храните свои экземпляры подписанных документов, а также копии того, в "ознакомлении" с чем расписываетесь, даже если не собираетесь их читать. Когда случится конфликт, нехватка любой бумажки и информации будет использована против вас
1.1. Трудовой договор, приложения к нему, изменения и допсоглашения, любые другие подписанные с двух сторон документы - обязательно в оригинале. Старайтесь не подписывать документы, не проставив на них дату подписания.
Если hr просит не ставить пока дату, вежливо попросите его дать объяснения, зачем и почему это делается и эти объяснения должны быть вам абсолютно понятны. Если подписали без даты на основе разумных объяснений... [to be continued]
Тред (@twit_iggy)
Суббота
Прошу прощения, что пропал, постараюсь за ночь и за завтра наверстать. Важные вещи, которые нельзя делать в конфликте с работодателем. Они простые, но, к сожалению, крайне распространены.
Между работой по найму и работой на заказчика существенная разница. С одной стороны, в трудовых отношениях вы больше защищены законом, с другой - некоторые вещи, допустимые в коммерческих отношениях, недопустимы в трудовых.
В случае, если у вас конфликт при увольнении, не важно по какой причине, НЕ уничтожайте код, НЕ шантажируйте работодателя его удержанием, не рушьте доступы к серверам и т.д. и т.п. Последствия могут быть самыми серьезными
Все это является собственностью работодателя и ваши действия будут подпадать под нормы об умышленном причинении убытков, в ряде случаев под умышленное уничтожение чужого имущества.
Если в отношениях с внешним заказчиком по гражданско-правовому договору у вас есть механизмы удержания и непередачи результатов работ, то по трудовому все созданное - его собственность. Кроме того, убытки не ограничиваются сделанным только вами.
Ответственность может быть как имущественная, так и административная и уголовная. При этом следует понимать, что с учетом зарплат в отрасли, а также дополнительных составляющих, сумма ущерба легко доходит до крупных и особо крупных размеров.
Не шантажируйте работодателя, это тоже подпадает под уголовный кодекс. В отличие от вас у работодателя значительно больше возможностей включить механизмы юридического преследования.
В бытовом плане описанные выше истории могут выражаться в самых разных формах, чаще всего: “не отдам код, пока не…”, “не верну доступы, пока не…”, угрозы опубликовать значимую или порочащую информацию, различные виды “мести”.
Также следует быть осторожным и крайне аккуратным в оценке людей и предыдущих работодателей в сети, кто-то не обратит на это внимание, а кто-то может заявить иск о защите деловой репутации.
Бизнес - это история о деньгах, ваши действия наносят считаемый ущерб и шансы, что будут включены механизмы юридической защиты гораздо выше, чем в бытовых отношениях.
Тред (@twit_iggy)
Воскресенье
Служебное произведение. Общим местом являются условия трудового договора о переходе исключительного авторского права на ваш код работодателю. Но есть интересные нюансы, о чем ниже.
Гражданский кодекс предусматривает выплату автору вознаграждения (помимо заработной платы) за использование работодателем произведения. Размер такого вознаграждения должен определяться договором между вами
И вот тут возникает предмет для дискуссий: абсолютное большинство компаний включают эти нормы в трудовой договор - формулируют, что это дополнительное вознаграждение включено в оклад либо определяют его размер нулевой ставкой
Судебная практика и часть юристов говорят, что вознаграждение автору СП носит гражданско-правовой (не трудовой) характер и должно определяться отдельным договором с работником.
С другой стороны, повсеместная практика применения такова, что работодатель уходит от этого требования и часть юристов также обосновывают его правоту возможностью включать данное вознаграждение в з/п.
Работодателя тоже можно понять - при штате в тысячу программистов введение подобной практики довольно сильно перевернуло бы их экономику
Вам вряд ли удастся переубедить работодателя в отношении данного вопроса при заключении трудового договора, но нередки случаи, когда эта норма может оказаться полезной.
Часто (особенно в случаях стартапов) ключевым разработчикам обещаются бонусы в различных формах: проценты от будущих прибылей, опционы и прочая ерунда, которая труднофиксируема и еще меньше выплачиваема
Заключение гражданско-правового договора о вознаграждении автора в дополнение к трудовому может стать удобным инструментом фиксации таких обещаний. Для работодателя же это хороший способ фиксации мотивации сотрудников.
Надо понимать, что это право остается за автором и после расторжения трудового договора: для начала важен факт начала использования софта компанией-работодателем (либо его передачи третьим лицам, либо принятии решения о сохранении софта в тайне)
Если работодатель в течение трех лет
- не начал использование софта,
- не передал (в т.ч. продал) его третьим лицам
- не принял решение сохранить его в тайне,
исключительное право переходит назад к разработчику.
Трехлетний срок начинает течь с даты, когда произведение было предоставлено в распоряжение работодателя.
В практическом плане возврат исключительного права - не самый частый случай, но, если брать ту же историю с nginx и рамблером, даже если бы nginx создавался как служебное произведение (а это не так по имеющейся информации),трехлетний срок для начала использования рамблером истек.
Тред (@twit_iggy)