Моя прошлая заметка о состоянии с использованием Third-Party Licence в российских реалиях оказалась интересна публике, так что я решил пройтись по базовым вопросам данной темы и постараться человеческим языком объяснить что тут к чему.
А начну я с первого вопроса, который может возникнуть у практически любого человека. Что такое "депонирование"? Особенно в контексте разработки софта.
Говоря простым языком, это юридический процесс закрепления прав на source code (исходный код) программного продукта. Превращение плодов ваших(или не совсем) трудов бессонными ночами, в юридически значимый объект интеллектуальной собственности. Только после депонирования можно "официально" продавать и покупать исходный код, ставить его на баланс организации, получать роялти и судится с нарушителями прав. До этих пор, доказать что исходники принадлежат вам или вашей организации будет крайне проблематично, ведь любой разработчик умыкнувший ваши исходники, сможет объявить себя его создателем а вас принудить выплачивать ему за нарушение авторских прав, если продукт дошел до этапа коммерческой эксплуатации.
Думаю в этом месте многие разработчики заметят... "В моей организации ничего такого нет, у меня просто в договоре написано что всё что я напишу принадлежит организации" . Это классическая ошибка менеджмента и попытка сэкономить на юристах. Дело в том что код это текст, т.е авторское произведение. Невозможно закрепить в договоре переход прав на все будущие произведения автора, а значит в любой момент разработчик подает иск в суд и говорит, что вот в этой программе были использованы его авторские наработки без спроса, вот мой исходный код, вон продукт где его украли. И для организации доказать, что конкретно этот фрагмент кода был написан в рамках работы на организацию и по её заданию без предварительного депонирования прав нельзя.
Как же должен выглядеть процесс с точки зрения нашего законодательства, чтобы плоды трудов разработчиков перешли к организации?
Вот примерный набросок must have пунктов :
1. Разработка технического задания на разработку конкретного продукта, с определенным названием.
2. Создание распоряжения или договора с разработчиками на создание продукта согласно ТЗ из п.1
3. Приемка продукта в том или ином виде у исполнителей
4. Передача прав от исполнителей к заказчику по договору и с обязательной выплатой юридически значимого авторского вознаграждения. Тут есть прецеденты когда формальные выплаты в 1р признавали ничтожными в суде, поэтому рекомендую выплачивать МРОТ и выше.
5. Подготовка исходного кода и пакета документов к регистрации в Роспатенте
6. Получение патента через 62 дня.
Дальше можно ставить программу на баланс, продавать другим организациям, закладывать в банке и делать много чего еще :)
На этом пока всё, всем спасибо кто дочитал до конца, надеюсь информация была полезной. Буду рад ответить на ваши вопросы в комментариях.
Можно пруфы на авторитетные источники с юридическим анализом?
Особенно вот эта часть интересует:
Приказ Минэкономразвития http://www1.fips.ru/wps/wcm/connect/content_ru/ru/documents/russian_laws/order_mert/prik_mert_210_05042016
Пункт 13. Срок предоставления государственной услуги в части государственной регистрации программы для ЭВМ или базы данных и выдачи свидетельства составляет шестьдесят два рабочих дня с даты приема заявки.
Хочу заметить, что я лишь работаю с юридической службой, как руководитель проектов. Так что какого-то глубинного юридического анализа предоставить не могу, и только рассказываю вещи с которыми встречаюсь каждый день.
Предмет регулирования регламента:
Это же о предоставлении гос. услуг. Как это относится к общему случаю и что я упускаю?
Процесс регистрации прав является государственной услугой, и в государственный же суд ходят за тем чтобы права свои защищать. Возможно я не совсем понимаю какой у вас возник вопрос, поэтому не знаю как на него точнее ответить :(
Чтобы в этом был какой-то смысл, это должен быть чертовски важный и нужный код. Который к тому же не меняется при каждом обновлении.
Имхо, общий тренд идет в диаметрально противоположном направлении - открытие своих исходных кодов. Так что их патентование выглядит как попытка запрыгнуть в поезд, который не то что давно ушел, а дошел до конечной остановки и дальше не едет.
Еще один момент - любой код можно изменить так, что его родная мама не узнает, причем автоматизировано, средства для этого есть. Он будет работать также но выглядеть по другому - ну и в чем тогда смысл?
Кажется вы не совсем представляете глубину данной проблемы. Для коммерческого продукта который находится на рынке и приносит доход, нет не важного кода. Вы не сможете постфактум после предъявления иска о нарушении авторских прав от разработчика изменить код. Даже наше судопроизводство прекрасно освоило контроль версий и есть соответствующие эксперты. Нормальная практика производить депонирование в каждый коммерческий релиз, что у крупных компаний обычно раз в квартал.
И тренд как раз на всё большую защиту прав, так как всё больше разработчиков осознают что можно лупануть с нерадивого работодателя пяток миллионов за красивые глаза.
На счет автоматизированных средств рефакторинга, полноценных палочек-выручалочек не существует. Мне уже не раз приходилось сталкиваться с тем, что компания после тщетных попыток договорится с разработчиком о передаче прав на код, тупо начинает исключать его код из проекта. А если это core функциональность крупного сервиса и человек работал 2 года? Разработка реально встает на месяц, увы.
Тема open source вообще отдельная... там есть и плюсы и минусы, в любом случае всегда есть лицензия под которой он публикуется, далеко не каждая разрешает модификацию и перепродажу.
@denislo Поздравляю! Вы добились некоторого прогресса на Голосе и были награждены следующими новыми бейджами:
Вы можете нажать на любой бейдж, чтобы увидеть свою страницу на Доске Почета.
Чтобы увидеть больше информации о Доске Почета, нажмите здесь
Если вы больше не хотите получать уведомления, ответьте на этот комментарий словом
стоп