@jsunderhood @nekrtemplar Добрый вечер! Расскажите пожалуйста, как писать код, не нарушая авторских прав, если ты такой функционал уже писал, работая в другой компании и он как бы принадлежит ей. Изменять названия переменных? Пытаться переделать логику?
Хороший вопрос от @xensola , о том, как писать код, не нарушая прав на аналогичный по функционалу, написанный ранее для предыдущего работодателя. Самое сложное - ответить на него хоть как-то коротко, выделяю в отдельный трэд. twitter.com/xensola/status…
Формальный ответ: в идеале писать заново - менять и логику и названия. Но идеального мира не существует, поэтому важны детали.
За исключением всего, что отдельно предусмотрено законом именно в части защиты софта, на защиту кода распространяются общие правила в части защиты литературных произведений (понятно почему, и там и там речь хоть и о специфических, но языках и произведениях на их основе)
Что касается кода тут прямая аналогия с литературным плагиатом или с самоплагиатом, если говорить совсем грубо. Поэтому по-максимуму выбрасываем 100%-ные заимствования минимально значимых блоков вашего авторства.
Что понимать под “блоком” - зависит от функционала, логики, архитектуры и пр. Но вцелом, только вам, как автору старого и нового кода оценивать степень его реиспользования. Но более важно тут другое:
Судья в случае спора о правах почти неизбежно будет руководствоваться результатами внешней экспертизы кода на предмет заимствований и значимости таких заимствований для функционала софта вцелом.
Важны будут также выводы о том, является ли функционал написанного для вашего нового работодателя результатом переработки предыдущего кода, степени его реиспользования и т.д. и т.п.
Спор будет происходить между старым и новым работодателем, но если новый работодатель проиграет, высоки риски, что, помимо гражданско-правовой ответственности, потерпевшая сторона решит инициировать уголовную и адм ответственность конечных причастных лиц
Такие шансы всегда есть, потому что это очень хороший пример и инструмент давления на всех последующих разработчиков, дополнительный аргумент, чтобы "уносили" меньше кода, конфиденциальной информации и пр
Ситуация, когда разработчиком в компанию берут именно потому, что он уже писал аналогичный код раньше у конкурента и самыми разными способами побуждают его к реиспользованию или “незначительно поменять и тогда не докопаются” - встречается на каждом шагу.
При этом надо понимать, что менеджеры, которые побуждают к этому, часто в рамках должности и обязанностей всегда могут сказать, что не имели к этому отношения, если у вас нет никакого подтверждения, что было указание реализовывать проект схожим способом .
Если вы понимаете, что в силу тех или иных причин идете на риск, старайтесь себя обезопасить в т.ч. на уровне документооборота:просите письменное служебное задание (или его аналог) в форме и виде, который гарантированно сможет остаться у вас и на который потом сможете сослаться
На бытовом уровне это чтобы у вас была возможность сказать: “Вот документ такой-то от такого-то моего руководителя от такого-то числа, в котором мне поручается реализовать такой-то функционал в такой-то архитектуре, с такой-то логикой, с применением таких-то языков и т.д.”
В острых случаях, если возникает конфликт/напряженность по сабжу с непосредственным руководителем, можно пойти к его вышестоящему руководителю или в ответственный отдел (несколько отделов):
например, служебная записка начальнику департамента о том, что начальник отдела требует от меня такой-то реализации и реиспользования кода, которая несет такие-то риски с копией этой же записки в юридический отдел.
На копии записки, которая остается у вас надо получить отметки о получении или реквизиты официальной регистрации в документообороте, если они есть. Зависит от особенностей документооборота, который у вашего работодателя принят.
Если у вас в компании есть юротдел, не бойтесь обращаться туда за консультацией: юристов, как правило, никто не любит со шкалой “от легкого неприятия” до “лютой ненависти”. Поэтому юротделу в этой ситуации, зачастую наплевать на конкуренцию внутри бизнесовых отделов и
между отделами, они отвечают в конечном итоге за то, чтобы верховное руководство понимало риски и потенциальные убытки, поэтому всегда есть шанс, что получите нормальную консультацию и, может быть, даже поддержку.
Также все вышеописанное не значит, что надо идти сразу на открытый конфликт, как правило это может решаться на уровне обычного взаимодействия внутри.
но просьба задокументировать и зарегистрировать в том или ином виде требование, которое вы считаете незаконным или потенциально несущим риски для вас и работодателя - важный и эффективный инструмент, о нем надо помнить.
Чем больше и востребованней на рынке проект и крупнее и известнее предыдущий и новый работодатель, тем выше риски негативных последствий, связанные с реиспользованием кода.
В случаях если у вас переход из одного маленького стартапа в другой с небольшой командой, где нет толком документооборота и прописанных процедур, можно пробовать получить аналогичную бумажку напрямую у генерального или техдира, важно, чтобы это было официально вышестоящее лицо.
Это одна из миллиона причин, о которой в соседнем треде будет о том, почему вы должны хотя бы вцелом понимать содержание вашей должностной инструкции, правил внутреннего трудового распорядка и прочих скучных документов, которые вам дают для ознакомления под роспись.
Не ругайте за слово “бумажки”, уведомления могут быть и с использованием электронных каналов, от почты до внутренних систем, но, в зависимости от степени риска, в голове всегда нужно держать возможность или невозможность вынуть электронные копии в верифицируемом виде
из таких каналов у тех,под чьим контролем они находятся, останется ли у вас возможность заверить электронную переписку у нотариуса после отключения вам доступов и т.д. Но это отдельная ветка, мы тут приближаемся к треду о конфликтах, он у меня на конец недели запланирован.
тема вцелом необъятная, спрашивайте, на что успею - отвечу, просто параллельно предновогодняя жесть :)