Ситуация такая: изначально программистом дома (в нерабочее время) написан какой-то код (программный модуль, библиотека и т.п.), который будет задействован для разработки собственных программ, например, на заказ. На работе программист занимается проектом, некоторые задачи которого могут быть решены с помощью данного кода, и программист намерен несколько измененную версию своего кода включить в проект, тем самым решив некоторые задачи проекта, и в рабочее время заиметь массу свободного времени.
Может случиться, что программист, когда реализует свой собственный проект, в чем то похожий на проект работодателя, получит от последнего иск о нарушении его авторских прав (работодатель обладает в данном случае исключительными авторскими на то, что было создано в порядке выполнения служебных обязанностей программиста, и еще получит охранный документ в ФГУ ФИПС). Исключительные авторские права на свой код программист докажет, но вопрос может перейти в такое русло: зачем он привнес в проект работодателя такой код без уведомления?
Варианты передачи работадателю неисключительных прав на код не рассматриваем, поскольку работодатель хочет исключительных. Интересует только вопрос о том, насколько достаточными отличиями должны обладать, например, два модуля, чтобы считать их независимыми.
F>но вопрос может перейти в такое русло: зачем он привнес в проект работодателя такой код без уведомления?
Ответ на него в духе
программист намерен несколько измененную версию своего кода включить в проект, тем самым решив некоторые задачи проекта, и в рабочее время заиметь массу свободного времени.
не прокатит, поскольку зарплату в отличие от договора подряда платят не за результат, а за выполнение трудовой функции.
Теперь по существу:
Интересует только вопрос о том, насколько достаточными отличиями должны обладать, например, два модуля, чтобы считать их независимыми.
При анализе программ на схожесть поступают точно так же, как при проверке литературных текстов на плагиат: собирают экспертную комиссию, которая выносит своё решение. Никаких других формальных (нормативных) критериев нет.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Fender, Вы писали:
F>Ситуация такая: изначально программистом дома (в нерабочее время) написан какой-то код (программный модуль, библиотека и т.п.), который будет задействован для разработки собственных программ, например, на заказ. На работе программист занимается проектом, некоторые задачи которого могут быть решены с помощью данного кода, и программист намерен несколько измененную версию своего кода включить в проект, тем самым решив некоторые задачи проекта, и в рабочее время заиметь массу свободного времени.
Я бы пошел к работодателю, и поговорил. Права на код, написанный в нерабочее время, принадлежат вам, если только в вашем контракте не написано иначе. Соответственно, без вашего разрешения в конторский проект этот код не попадет.
F>Может случиться, что программист, когда реализует свой собственный проект, в чем то похожий на проект работодателя, получит от последнего иск о нарушении его авторских прав (работодатель обладает в данном случае исключительными авторскими на то, что было создано в порядке выполнения служебных обязанностей программиста, и еще получит охранный документ в ФГУ ФИПС). Исключительные авторские права на свой код программист докажет, но вопрос может перейти в такое русло: зачем он привнес в проект работодателя такой код без уведомления?
Может. Кроме того, может получиться так, что вам не поверят, что права на этот код вам принадлежат. Даже если в конечном итоге вы докажете свою правоту, никто вам не скомпенсирует время и нервы, потраченные на судебный процесс.
С людьми лучше договариваться, т.е. учиться общаться, чем делать что-то потенциально проблемное втихую у них за спиной. В общем-то, вменяемые люди предпочитают в открытую обсуждать даже сложные проблемы, а не получать неожиданные сюрпризы в неожиданный момент.
F>Варианты передачи работадателю неисключительных прав на код не рассматриваем, поскольку работодатель хочет исключительных. Интересует только вопрос о том, насколько достаточными отличиями должны обладать, например, два модуля, чтобы считать их независимыми.
Надо правильно вопрос ставить. Придите к начальству, и расскажите, что вот дескать, у вас есть куча кода, написанного в свободное от работы время, и если его применить в конторском проекте, он сократит время разработки проекта на N месяцев. Поэтому за скромное вознаграждение X вы готовы этот код компании неэкслюзивно лицензировать. А за нескромное Y — готовы лицензировать экслюзивно. Но если компания не заинтересована, то пусть пока этот код дома полежит, а вы в оплаченное рабочее время еще один такой же напишете, вам ведь не жалко в рабочее время глупостями заниматься, если за зарплату.
Обратите внимание, вы собираетесь подарить компании лицензию на ваш код — вполне уместно было бы не дарить, а попробовать получить что-то взамен (не обязательно деньги, но деньги тоже неплохо). Только надо делать это аккуратно и корректно, чтобы не у компании не сложилось впечатление, что вы у них что-то украли, а теперь вот пытаетесь на этом еще и нажиться.
Но в самой по себе ситуации, что вы сидели там дома и что-то писали для плезиру, а теперь вот вас вдруг осенило, что родная компания тоже может от этого выиграть, нет ничего плохого. Особенно если вы способны внятно и непротиворечиво изложить, что сподвигло вас написать этот код для себя.
Выкладываешь свой код (движок) под BSD-лицензией. Информируешь работодателя, что хочешь задействовать в своем проекте этот код. Работодатели спокойно смотрят на использование в своих проектах BSD-лицензированного кода.
Ставятся цели:
1. Не лишиться имущественных прав на свой код, поскольку планируется собственная разработка.
2. Использовать выгоду сложившейся ситуации на работе.
Самым естественным был-бы вариант заключения с работодателем юридического соглашения о передаче неисключительных прав за деньги. Но, вполне понятный, ответ работадателя: "А мне зачем? Проект не испытывает дефицит времени, поэтому сделай мне за зарплату и по плану такой же код (в смысле обеспечь требуемый функционал посредством другой имплементации), плюс я буду обладателем исключительных прав". В этом смысле и ставится вопрос об отличиях в коде — создать разные с юридической точки зрения реализации одной и той же идеи, тем самым защитив себя от претензий работодателя (у каждого остаются свои исключительные права). Выгода, получаемая на работе, — это образующееся свободное время, поскольку рефакторинг/даун-рефакторинг займет на порядок меньшее время, нежели разработка с нуля. А при выполненном в срок задании неуместно предъявлять претензии к работнику по поводу его дискретной трудовой функции.
Вариант с BSD-лицензией удовлетворит п.1, но не п.2.
А экспертная комиссия по анализу программ на схожесть ведь все же руководствуется теми или иными критериями. Достаточным ли критерием будет, к примеру, изменение сигнатур функций, наличие NVI (non-virtual interface) или замена private-наследования вложением?
Здравствуйте, Fender, Вы писали:
F>Самым естественным был-бы вариант заключения с работодателем юридического соглашения о передаче неисключительных прав за деньги. Но, вполне понятный, ответ работадателя: "А мне зачем? Проект не испытывает дефицит времени, поэтому сделай мне за зарплату и по плану такой же код (в смысле обеспечь требуемый функционал посредством другой имплементации), плюс я буду обладателем исключительных прав". В этом смысле и ставится вопрос об отличиях в коде — создать разные с юридической точки зрения реализации одной и той же идеи, тем самым защитив себя от претензий работодателя (у каждого остаются свои исключительные права). Выгода, получаемая на работе, — это образующееся свободное время, поскольку рефакторинг/даун-рефакторинг займет на порядок меньшее время, нежели разработка с нуля. А при выполненном в срок задании неуместно предъявлять претензии к работнику по поводу его дискретной трудовой функции.
Ну вы описываете какое-то невменяемое поведение со стороны работодателя, и при этом ставите себе целью его обокрасть. Лучше украдите с работы что-нибудь материальное. Например, сушилку для зонтиков в коридоре. От нее хоть польза в хозяйстве, да и вряд ли подумают именно на вас
F>А экспертная комиссия по анализу программ на схожесть ведь все же руководствуется теми или иными критериями. Достаточным ли критерием будет, к примеру, изменение сигнатур функций, наличие NVI (non-virtual interface) или замена private-наследования вложением?
Вы как будто готовитесь к настоящему суду, с адвокатами, экспертными оценками и т.д. Во-первых, с чего вы взяли, что такой суд будет? Может, вам просто оторвут голову в тёмном переулочке. А во-вторых, а вы выдержите пару-тройку лет такого суда, с регулярными заседаниями в рабочее время, адвокатами, которых вам придется оплачивать из своего кармана, привлечением независимых экспертов, тоже за ваш счет?
Pzz>Вы как будто готовитесь к настоящему суду, с адвокатами, экспертными оценками и т.д. Во-первых, с чего вы взяли, что такой суд будет? Может, вам просто оторвут голову в тёмном переулочке. А во-вторых, а вы выдержите пару-тройку лет такого суда, с регулярными заседаниями в рабочее время, адвокатами, которых вам придется оплачивать из своего кармана, привлечением независимых экспертов, тоже за ваш счет?
Действительно! Какая вероятность того, что кто то вдруг задасться вопросом, а не являются ли эти модули плагиатом?
Спор может возникнуть тогда, когда ущемились чьи то интересы. Если у вас есть исключительные права — вы довольны, у компании есть исключительные права — она довольна. По моему вопрос прав не будет никого интересовать, пока все довольны. Конечно, если вы в свободное от работы время, работали на конкурирующую фирму, то тут другое дело...
Здравствуйте, Fender, Вы писали:
F>А экспертная комиссия по анализу программ на схожесть ведь все же руководствуется теми или иными критериями. Достаточным ли критерием будет, к примеру, изменение сигнатур функций, наличие NVI (non-virtual interface) или замена private-наследования вложением?
Ещё раз — программы приравнены к литературе, поэтому заранее говорить о достаточности каких-то действий по их изменению невозможно. Формальных правил нет.
Если бы я сидел в такой комиссии, то у меня было бы два критерия:
1) одинаковость (или похожесть, опять-таки субъективно) алгоритма работы;
2) если алгоритмы похожи, то я учитывал бы время, по приведению одного кода к другому, включая всякие перименования идентификаторов. И критерием различия для меня было бы, если время по изменению больше хотя бы половины от того, чтобы написать всё с нуля.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Ещё раз — программы приравнены к литературе, поэтому заранее говорить о достаточности каких-то действий по их изменению невозможно. Формальных правил нет.
В литературе как раз есть формальный критерий — 30%. Т.е. если произведение (например, учебник) отличается на эти проценты, то оно считается новым.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, dilmah, Вы писали: D>Выкладываешь свой код (движок) под BSD-лицензией. Информируешь работодателя, что хочешь задействовать в своем проекте этот код. Работодатели спокойно смотрят на использование в своих проектах BSD-лицензированного кода.
+1. Сперва заявить свои права на код — и только потом использовать его на работе. По-моему неплохой вариант.
А еще можно выложить код под коммерческой лицензией и предложить работодателю его купить.
Здравствуйте, Basil2, Вы писали:
F>>Ещё раз — программы приравнены к литературе, поэтому заранее говорить о достаточности каких-то действий по их изменению невозможно. Формальных правил нет. B>В литературе как раз есть формальный критерий — 30%. Т.е. если произведение (например, учебник) отличается на эти проценты, то оно считается новым.
Ссылку на нормативный документ, пожалуйста. И что такое отличие в 30%? Вот если в слове "хлеб" классическим способом сделать 4 ошибки — это сколько процентов будет? А такая замена: хлеб -> хлев, это сколько?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Fender, Вы писали:
F>Варианты передачи работадателю неисключительных прав на код не рассматриваем, поскольку работодатель хочет исключительных. Интересует только вопрос о том, насколько достаточными отличиями должны обладать, например, два модуля, чтобы считать их независимыми.
Ключевой вопрос в этом случае, что произойдет с этим кодом если ты работадателя покинешь. Мне почему-то кажется, что он захочет видеть свой проект в рабочем состоянии и без спорных юридических вопросов.
Поэтому imho остается 2 пути:
1) [простой] выпустить код под open source лицензией и заюзать по этой самой лицензии, на общих условиях как юзаются сторонние open source биюлиотеки. Нужно проверить, что лицензия совместима с проприетарным кодом(впрочем это нужно делать для всех библиотек которые ты юзаешь, а не только для своей). GPL например не подходит, BSD подходит.
2) [сложный, если не хочется в open source] ты подписываешь с работадателем бумажку о том позволяешь ему пользоваться кодом(на возмездной или безвозмездной основе), где оговорены все тонкости.
Вопрос "какими отличиями должны обладать" imho не при чем вообще. Если ты в свое личное время с нуля переписал кусок кода который уже писал на работе, даже с сохранением отступов и стиля — то код другой. Если копировал кусок текста copy/paste — тот же самый, даже если поверх прошелся стайлером/обфускатором. К сожалению узнать как именно получен похожий кусок текста копированием или переписыванием нельзя, поэтому обсуждать это будете если что в суде.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев