Pull to refresh
21
-1
Михаил Шевцов @mshewzov

IT-юрист

Send message

Погодите. Вот такой сценарий если. Клонируем репозиторий из GitHub, потом репозиторий на GitHub удаляем, а локальный репозиторий загружаем в другой git-репозиторий, созданный на GitLab, например, или на арендованном сервере в том же Яндекс.Облаке. И вот вопрос - что с хэшами коммитов происходит?

Да, он и не затрагивался. В этом плане нам помогло решение по первому спору.

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

Было бы интересно, как бы развивался суд, будь со стороны разработчика такое заявление :)

В ст. 1285 говорится о передаче исключительного права в полном объёме. И тут имеется в виду, что право передаётся без ограничений по способам использования произведения, то есть приобретатель становится полноправным правообладателем. Тут не идёт речь о полном объёме произведения. Исключительное право в полном объёме можно передать и на часть произведения. Это происходит, к примеру, когда работы сдаются поэтапно.

Статью 1285 нужно читать без отрыва от статьи 1234 ГК РФ.

Плюс в п. 7 ст. 1259 ГК РФ говорится о том, что авторские права распространяются на часть произведения, если по своему характеру она может быть признана самостоятельным результатом творческого труда автора и выражена в объективной форме. В программном коде большинство частей могут считаться самостоятельными произведениями. Всякие модули, библиотеки, функции и так далее - все они могут быть перенесены в другой софт, а могут распространяться и отдельно.

В общем, тут я не вижу противоречий.

Тут вопрос не в незаверенном скриншоте. У нас в деле они были. В частности, разработчик сделал запрос в службу поддержки GitHub - был ли создан аккаунт для заказчика, а также был ли предоставлен доступ на этот аккаунт к репозиториям. GitHub ответил, что да, аккаунт такой-то был создан, доступ к репозиторию ему был предоставлен. Но... слабое место было в том, что аккаунт для заказчика создавал разработчик и факт передачи заказчику данных для доступа к аккаунту он не смог доказать. И в итоге вся эта цепочка рухнула.

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

Ну это длинные варианты. Я уже внёс правки - передача лицензии.

В самом законе допускается масса вольностей в терминах. Например, в п. 1 ст. 1236 ГК РФ написано так:

1. Лицензионный договор может предусматривать:

1) предоставление лицензиату права использования результата интеллектуальной деятельности или средства индивидуализации с сохранением за лицензиаром права выдачи лицензий другим лицам (простая (неисключительная) лицензия);

2) предоставление лицензиату права использования результата интеллектуальной деятельности или средства индивидуализации без сохранения за лицензиаром права выдачи лицензий другим лицам (исключительная лицензия).

То есть в понимании законодателя простую (неисключительную) лицензию можно ещё и выдавать :)

А статус "закрытого" репозитория как влияет на тот факт, что разработчик предоставил GitHub неисключительную лицензию на код? Тут уже всё равно какой был репозиторий. Разработчик просто не был вправе этого делать и всё. Код не принадлежал ему.

В теории - да. А по факту разработчик не смог доказать, что код был выгружен на GitHub до даты приёмки работ и перехода прав к заказчику. В итоге у нас остались только даты, в которые эксперты осматривали код в репозиториях GitHub, а эти даты были уже после даты приёмки работ и перехода прав.

Может, но как получить юридически значимый документ от GitHub, который бы подтверждал такую передачу? Это вопрос. Разве что описать весь процесс детально в самом договоре. Но у нас был не тот случай. В договоре этого не было.

Корректная формулировка мне известна. Я, повторюсь, старался упростить чтение статьи.

Предложенный Вами вариант чрезвычайно длинный. Я думаю, что стоит сократить до "передача лицензии".

Тогда подытожим. У Вас получается тоже претензия к моему упрощению. Я подумаю, как изменить "передача прав" на что-то другое, чтобы было и просто, и согласовалось с общепринятой терминологией. Пока в мыслях фраза "передача лицензии". Это согласуется с терминологией. Фразу "предоставление прав" не хочу использовать, это довольно громоздко.

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

Эти вопросы не подымались в суде. Более того, сам разработчик заявил изначально в прошлом судебном деле, что код в репозиториях по ссылкам - это тот самый код, который его компания разработала по договору. Включать заднюю и говорить, что это личный код Романа Давыдова, было бы уже поздно. Ну и с точки зрения закона, исполнитель тут ООО, а другое ООО заказчик, а значит трудовые взаимоотношения внутри компании-разработчика между неё и её сотрудниками - это не проблема заказчика. По умолчанию исключительное право на служебное произведение принадлежит работодателю.

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

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

Я это не оспаривал, но с таким же успехом можно было выложить в любой файлообменник.

Не совсем. Файлообменники в своих условиях использования обычно не претендуют на права в отношении размещаемых там файлов. Обычно это чисто информационно-технологические услуги.

Часто все начинается именно с локального репозитория, то есть это не так, что у вас код только в облаке. В облаке он нужен для совместной работы и других операций. А то что вам это поможет или не поможет в конкретном деле против конкретного разработчика, не имеет к этому никакого отношения, речь про ваше конкретное утверждение о бэкапах.

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

"Во-первых" исключает "во-вторых" в той мере, в которой это прописано в соглашении с заказчиком.

Мне так не показалось. Всё-таки "во-первых" предполагает использование GitHub до передачи кода заказчику. А "во-вторых" касается удаления кода с GitHub уже после сдачи работы заказчику.

Вам необходимо сделать примечание, что речь идет про использование https://github.com/, потому что еще есть GitHub Enterprise Server, который позволяет хостить код на своем сервере.

Вот это верное замечание. Сделаю корректировку.

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

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

Вопрос идентификации кода, конечно, всегда стоит. Однако, как наше законодательство, так и международное идентифицирует конкретные произведения по... названию. Т.е. юридически верно зафиксировать в договоре конкретное название ПО и описать какие права кому переходят. И всё.

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

Надо помнить, что права на код могут гулять по правообладателям совершенно независимо от самого кода. Это касается любого произведения, не только ПО. Та же картина де-факто может висеть в одной галерее, а исключительные права на неё могут переходить сколько угодно кому угодно.

Исполнитель по-хорошему должен был передать код заказчику, а потом уже заказчик должен был по требованию суда передать код на экспертизу. Однако, исполнитель передал только права на код (сам того не подозревая), а сам код - нет.

А разве коммит - это не что-то типа как результат diff? Получается, что хэш коммита не равно хэш файла, где эти изменения произошли.

Ну так вы рассказываете, что он код не передал – при этом, я так понимаю, есть акт приёма-передачи (пусть даже в силу ошибки заказчика) и эксперты получили доступ к коду – т.е. и фактически он передан.

В акте приёма-передачи написано так "Работы по разработке приложения согласно договора такого-то". Акт отправили на почту заказчика, а он не написал в ответ отказ от приёмки, что автоматически спустя 5 дней сделал приёмку состоявшейся. Формально. Но по факту ничего никто не передавал. И суд это отразил в решении.

Эксперты получили доступ к коду, потому что его им дал разработчик. А заказчику он такие доступы не дал.

Раздражает, что вы ссылаетесь на какую-то не относящуюся к делу вещь и при этом совершаете бросающиеся в глаза ошибки. Можно ж было просто не ссылаться на это, всё равно для решения суда это несущественно?

Давайте тут поподробнее. Сначала Вы меня обвинили в незнании основ GIT, а теперь в том, что я совершаю бросающиеся в глаза ошибки. Может ошибки и есть, я ж тоже человек, да только Вы о них как-то абстрактно сейчас заявили. В чём конкретно я ошибся?

Исключительные права на код - это одна история, а сам код - это другая история. По закону права не привязаны к материальному носителю произведения, в данном случае ПО. Получается, что после признания факта приёмки работ (хоть и без передачи кода) исключительные права перешли к заказчику, но код остался у разработчика.

Если провести аналогию с недвижимостью, то это как если зарегистрировать куплю-продажу в Росреестре и получить права собственности на дом, но по приезду обнаружить, что старые владельцы из дома не очень-то и планируют выезжать.

Information

Rating
Does not participate
Location
Батайск, Ростовская обл., Россия
Date of birth
Registered
Activity