Ну, вы частично правы. Дело в том, что я стараюсь писать свои статьи максимально доступным языком, иногда упрощая некоторые вещи. В данном случае фраза "передача прав на код", конечно, является упрощением. По факту конструкция авторских прав имеет следующие уровни вложенности:
исключительное право (имущественное), которое включает следующие способы использования произведения (так называемые правомочия):
правомочие на воспроизведение произведения;
правомочие на распространение произведения;
правомочие на публичный показ произведения;
правомочие на импорт произведения в целях распространения;
правомочие на прокат произведения;
правомочие на публичное исполнение произведения;
правомочие на сообщение в эфир;
правомочие на сообщение по кабелю;
правомочие на ретрансляцию;
правомочие на перевод или другую переработку произведения;
правомочие на практическую реализацию архитектурного, дизайнерского, градостроительного или садово-паркового проекта;
правомочие на доведение произведения до всеобщего сведения;
иные правомочия (список открыт, можно использовать произведение и способом, которого в законе попросту нет).
неимущественные права и иные права:
право следования;
право доступа;
право авторства;
право автора на имя;
право на неприкосновенность произведения;
право на отзыв.
Так вот, говоря о "правомочиях", очень часто это громоздкое слово заменяют на "право". Например, в лицензионных договорах почти всегда пишут "право на воспроизведение ПО".
А зря Вы ничего не говорите про договорные отношения. Вопрос соотношения понятий "публикация" и "передача прав" реально зависит от взаимоотношений публикатора с тем, кто владеет ресурсом, на котором это самое опубликование происходит. В самом простом случае "публикация" не будет равна "передаче прав" только если она происходит на своем собственном сервере, который торчит наружу в сеть IP-адресом или даже доступен через какой-то домен. Вот тут передачи прав нет. А если "публикация" производится на ресурс, принадлежащий третьим лицам, то нужно подробно изучить условия договора или соглашения, на основании которых этот ресурс в принципе предоставляет возможность такую публикацию произвести. К примеру, публикация контента в социальной сети ВК тоже предоставляет ее компании-владельцу довольно внушительный набор прав. А вот публикация материалов на своём сайте, который размещён на арендованном хостинге, не приводит к передаче прав на материал хостеру, т.к. он оказывают исключительно информационно-технологические услуги. Так что вопрос соотношения понятий "публикация" и "передача прав" реально сильно зависит от договорных отношений.
Погодите, а что не так? Как можно опубликовать код на GitHub и НЕ ПРИНЯТЬ его условия использования? Никак, я думаю. А принимая его условия использования разработчик заключает с GitHub Inc. лицензионный договор, которым предоставляет этой компании неисключительную лицензию на любой публикуемый на GitHub материал с довольно внушительным перечнем правомочий. И в итоге тут не важна общепринятая терминология, т.к. нужно оперировать теми параметрами, что заложены в условия использования GitHub, а из них фактически следует, что любое хранение материалов на серверах GitHub порождает предоставлением GitHub Inc. определённых прав (правомочий) на эти материалы.
Если рассматривать с точки зрения таймлайна, то получается так: если в договоре прописано, что исключительное право на ПО переходит к заказчику от разработчика в момент подписания акта, то получается, что до подписания акта правообладателем ПО является разработчик, а потому в целом загрузка кода на GitHub не нарушает чьи-то права. Однако, с момента подписания акта, если разработчик теряет исключительное право и не получает встречно какой-то неисключительной лицензии на ПО, то с GitHub лучше код удалить (или закрыть доступ).
Если в договоре ничего не прописано, то тут есть два варианта:
договор на разработку заключён с индивидуальным программистом, т.е. с конкретным автором, и тогда вопрос перехода исключительных прав ОБЯЗАН быть решён в договоре, иначе будет идиотская ситуация, когда код разработан под заказ, но права на него остались у разработчика, а у заказчика нет вообще никаких прав;
договор на разработку заключён с компанией, т.е. разработчиком, который привлекает других авторов к разработке, и тогда по закону все права на ПО, как на произведение принадлежат заказчику. В законе не указано с какого момента, но фраза "принадлежат заказчику", мной трактуется так, что принадлежат сразу, с момента создания.
Я вам больше скажу - условия использования GitHub подчиняются федеральным законам США и законам штата Калифорния.
В секции "R" в пункте 1 вот так написано:
"За исключением случаев, когда применимое право предусматривает иное, настоящее Соглашение между вами и GitHub, а также любой доступ или использование Веб-сайта или Сервиса регулируются федеральными законами Соединенных Штатов Америки и законами штата Калифорния без учета коллизионных норм. Вы и GitHub соглашаетесь подчиняться исключительной юрисдикции и месту проведения судов, расположенных в городе и округе Сан-Франциско, штат Калифорния."
Да только что это меняет? Это правило применяется в отношении споров, которые возникают между пользователем сервиса GitHub и его владельцем - компанией GitHub Inc.
В целях же нашего судебного разбирательства нам важно было установить следующее:
использование GitHub осуществляется на основе лицензионного договора, а это один из видов распоряжения исключительным правом;
публикация кода на GitHub является доведением до всеобщего сведения;
публикация кода на GitHub является частным случаем воспроизведения.
Применяемое к условиям использования GitHub иностранное право нам тут вообще никак не мешает.
Сложный вопрос, на который я не могу ответить, т.к. я тогда в первом судебном деле не участвовал. Но судя по заключению экспертизы разработчик давал экспертам (трём, на минуточку) доступы к приватным репозиториям (там их было три - код под Android, под iOS и серверная платформа). Во всех заключениях присутствует одна и та же фраза: "На исследование был предоставлен удаленный доступ к репозиториям разработанного программного обеспечения со следующими параметрами..." и дальше адреса репозиториев. Сам разработчик в суде заявлял о приватных репозиториях, о доступе только по приглашению и так далее. И вроде бы даже клиент присутствовал при осмотре репозиториев через видеосвязь, но сам доступ к ним разработчик ему никогда не давал, а письма - игнорировал.
Там товарищ разработчик очень принципиальный попался. По рассказам заказчика разработчик в какой-то момент просто бросил разработку и сказал, что ему дешевле будет судиться, чем работать дальше. Возможно он недооценил свои силы, а в договоре была фикс-цена за конкретное ТЗ, и разработчик понял, что он слишком дешево оценил проект. Хз, какие там причины у него были. Первый суд мой клиент (заказчик) выиграл, условно выиграл. Из заявленной суммы взыскания за недоработанное ПО ему суд взыскал 24%, то есть при условном проигрыше ответчика последний фактически "выиграл" на 76%. Плюс распределение стоимости экспертиз и в итоге истец (заказчик) оказался должен ещё хорошую сумму ответчику. Я в том суде не участвовал, поэтому сделать с этим уже ничего не смог. И если бы не идея с GitHub, то угроза разработчика, что ему дешевле судиться, реально оказалась бы претворенной в жизнь.
Да, на самом деле я довольно давно уже рекомендую своим клиентам вне зависимости от способа передачи кода фиксировать переданные файлы в акте с указанием MD5 и SHA256. Плюс прописываю, что заказчик при получении файлов всё открыл, проверил, просмотрел и подписанием акта подтверждает это. А ещё более лучший вариант - двойной акт. Первый акт - передача файлов, второй акт - по завершению тестирования или демонстрации. Либо один акт, но тестирование и демонстрацию как-то прописать в договоре заранее, до подписания акта. Бывают такие заказчики, которые не разбираются в ИТ или у них нет на это времени, или хз какие у них могут на это ещё быть причины, и они попросту не понимают, как проверить то, что они получают от разработчика, на предмет соответствия ТЗ. Двойной акт должен снизить риски такого непонимания.
Заказчик ничего не скачивал. Вроде бы разработчик ему как будто бы создавал логин, так он рассказал на суде, но этот логин был только у разработчика, заказчику он доступы не передал.
Ну, тут я не спорю. В данном случае нас не интересовало наличие локальной копии, потому что нам её просто не давали. А заинтересовало то, что есть копия на серверах GitHub. И этой копии там по закону быть не должно.
Согласен про локальную копию. Но тогда это будет сервер GitHub и сервер разработчика. А в нашем случае разработчик попросту отказался передать заказчику код. И заказчик остался ни с чем. Более того последний раз, когда мы с ним общались уже после суда, он вообще сказал, что он его попросту удалил.
Зачем нам признавать какое-то право? По закону любой договор трактуется в соответствии с правом страны, которое к нему применяется. В нашем случае из условий использования GitHub однозначно следует, что он лицензионный и что он наделяет GitHub правами на код. Он имеет такую же силу в России, как и местные договоры. Плюс не стоит забывать, что публикация кода на GitHub сама по себе уже является доведением до всеобщего сведения.
По умолчанию исключительное право на программу для ЭВМ, базу данных или иное произведение, созданные по договору, предметом которого было создание такого произведения (по заказу), принадлежит заказчику, если договором между подрядчиком (исполнителем) и заказчиком не предусмотрено иное. Но как правило в договорах прописывают, что права переходят с момента подписания акта.
Лучше да, в обратную предоставить какой-то набор прав разработчику. Но в данном случае ничего подобного не было. А по закону разработчик имеет минимум прав на код, права на который он передал заказчику - использовать его для собственных нужд, к которым как минимум не относится его передача по лицензии другим лицам.
Я может чего-то не понимаю, всё же я юрист, а не разработчик, но здесь рассматривается конкретная система - GitHub. Не локальная VCS, а именно та, которая развёрнута на северах GitHub. Как децентрализация поможет, если GitHub отключит все аккаунты российских разработчиков? По-моему никак. Если ошибаюсь - поправьте меня.
С Open Source проектами тоже довольно много инцидентов было. Вспомнить хотя бы тот же TrueCrypt. Только репутацию там портить особо некому. Открытое ПО настолько размазано по разработчикам и корпорациям, что единого ответственного там просто нет. Проект TrueCrypt, например, просто прикрылся и все.
Ну если упростить, то можно и так сказать.
Ну, вы частично правы. Дело в том, что я стараюсь писать свои статьи максимально доступным языком, иногда упрощая некоторые вещи. В данном случае фраза "передача прав на код", конечно, является упрощением. По факту конструкция авторских прав имеет следующие уровни вложенности:
исключительное право (имущественное), которое включает следующие способы использования произведения (так называемые правомочия):
правомочие на воспроизведение произведения;
правомочие на распространение произведения;
правомочие на публичный показ произведения;
правомочие на импорт произведения в целях распространения;
правомочие на прокат произведения;
правомочие на публичное исполнение произведения;
правомочие на сообщение в эфир;
правомочие на сообщение по кабелю;
правомочие на ретрансляцию;
правомочие на перевод или другую переработку произведения;
правомочие на практическую реализацию архитектурного, дизайнерского, градостроительного или садово-паркового проекта;
правомочие на доведение произведения до всеобщего сведения;
иные правомочия (список открыт, можно использовать произведение и способом, которого в законе попросту нет).
неимущественные права и иные права:
право следования;
право доступа;
право авторства;
право автора на имя;
право на неприкосновенность произведения;
право на отзыв.
Так вот, говоря о "правомочиях", очень часто это громоздкое слово заменяют на "право". Например, в лицензионных договорах почти всегда пишут "право на воспроизведение ПО".
А зря Вы ничего не говорите про договорные отношения. Вопрос соотношения понятий "публикация" и "передача прав" реально зависит от взаимоотношений публикатора с тем, кто владеет ресурсом, на котором это самое опубликование происходит. В самом простом случае "публикация" не будет равна "передаче прав" только если она происходит на своем собственном сервере, который торчит наружу в сеть IP-адресом или даже доступен через какой-то домен. Вот тут передачи прав нет. А если "публикация" производится на ресурс, принадлежащий третьим лицам, то нужно подробно изучить условия договора или соглашения, на основании которых этот ресурс в принципе предоставляет возможность такую публикацию произвести. К примеру, публикация контента в социальной сети ВК тоже предоставляет ее компании-владельцу довольно внушительный набор прав. А вот публикация материалов на своём сайте, который размещён на арендованном хостинге, не приводит к передаче прав на материал хостеру, т.к. он оказывают исключительно информационно-технологические услуги. Так что вопрос соотношения понятий "публикация" и "передача прав" реально сильно зависит от договорных отношений.
Погодите, а что не так? Как можно опубликовать код на GitHub и НЕ ПРИНЯТЬ его условия использования? Никак, я думаю. А принимая его условия использования разработчик заключает с GitHub Inc. лицензионный договор, которым предоставляет этой компании неисключительную лицензию на любой публикуемый на GitHub материал с довольно внушительным перечнем правомочий. И в итоге тут не важна общепринятая терминология, т.к. нужно оперировать теми параметрами, что заложены в условия использования GitHub, а из них фактически следует, что любое хранение материалов на серверах GitHub порождает предоставлением GitHub Inc. определённых прав (правомочий) на эти материалы.
Если рассматривать с точки зрения таймлайна, то получается так: если в договоре прописано, что исключительное право на ПО переходит к заказчику от разработчика в момент подписания акта, то получается, что до подписания акта правообладателем ПО является разработчик, а потому в целом загрузка кода на GitHub не нарушает чьи-то права. Однако, с момента подписания акта, если разработчик теряет исключительное право и не получает встречно какой-то неисключительной лицензии на ПО, то с GitHub лучше код удалить (или закрыть доступ).
Если в договоре ничего не прописано, то тут есть два варианта:
договор на разработку заключён с индивидуальным программистом, т.е. с конкретным автором, и тогда вопрос перехода исключительных прав ОБЯЗАН быть решён в договоре, иначе будет идиотская ситуация, когда код разработан под заказ, но права на него остались у разработчика, а у заказчика нет вообще никаких прав;
договор на разработку заключён с компанией, т.е. разработчиком, который привлекает других авторов к разработке, и тогда по закону все права на ПО, как на произведение принадлежат заказчику. В законе не указано с какого момента, но фраза "принадлежат заказчику", мной трактуется так, что принадлежат сразу, с момента создания.
Я вам больше скажу - условия использования GitHub подчиняются федеральным законам США и законам штата Калифорния.
В секции "R" в пункте 1 вот так написано:
"За исключением случаев, когда применимое право предусматривает иное, настоящее Соглашение между вами и GitHub, а также любой доступ или использование Веб-сайта или Сервиса регулируются федеральными законами Соединенных Штатов Америки и законами штата Калифорния без учета коллизионных норм. Вы и GitHub соглашаетесь подчиняться исключительной юрисдикции и месту проведения судов, расположенных в городе и округе Сан-Франциско, штат Калифорния."
Да только что это меняет? Это правило применяется в отношении споров, которые возникают между пользователем сервиса GitHub и его владельцем - компанией GitHub Inc.
В целях же нашего судебного разбирательства нам важно было установить следующее:
использование GitHub осуществляется на основе лицензионного договора, а это один из видов распоряжения исключительным правом;
публикация кода на GitHub является доведением до всеобщего сведения;
публикация кода на GitHub является частным случаем воспроизведения.
Применяемое к условиям использования GitHub иностранное право нам тут вообще никак не мешает.
Сложный вопрос, на который я не могу ответить, т.к. я тогда в первом судебном деле не участвовал. Но судя по заключению экспертизы разработчик давал экспертам (трём, на минуточку) доступы к приватным репозиториям (там их было три - код под Android, под iOS и серверная платформа). Во всех заключениях присутствует одна и та же фраза: "На исследование был предоставлен удаленный доступ к репозиториям разработанного программного обеспечения со следующими параметрами..." и дальше адреса репозиториев. Сам разработчик в суде заявлял о приватных репозиториях, о доступе только по приглашению и так далее. И вроде бы даже клиент присутствовал при осмотре репозиториев через видеосвязь, но сам доступ к ним разработчик ему никогда не давал, а письма - игнорировал.
Там товарищ разработчик очень принципиальный попался. По рассказам заказчика разработчик в какой-то момент просто бросил разработку и сказал, что ему дешевле будет судиться, чем работать дальше. Возможно он недооценил свои силы, а в договоре была фикс-цена за конкретное ТЗ, и разработчик понял, что он слишком дешево оценил проект. Хз, какие там причины у него были. Первый суд мой клиент (заказчик) выиграл, условно выиграл. Из заявленной суммы взыскания за недоработанное ПО ему суд взыскал 24%, то есть при условном проигрыше ответчика последний фактически "выиграл" на 76%. Плюс распределение стоимости экспертиз и в итоге истец (заказчик) оказался должен ещё хорошую сумму ответчику. Я в том суде не участвовал, поэтому сделать с этим уже ничего не смог. И если бы не идея с GitHub, то угроза разработчика, что ему дешевле судиться, реально оказалась бы претворенной в жизнь.
Да, на самом деле я довольно давно уже рекомендую своим клиентам вне зависимости от способа передачи кода фиксировать переданные файлы в акте с указанием MD5 и SHA256. Плюс прописываю, что заказчик при получении файлов всё открыл, проверил, просмотрел и подписанием акта подтверждает это. А ещё более лучший вариант - двойной акт. Первый акт - передача файлов, второй акт - по завершению тестирования или демонстрации. Либо один акт, но тестирование и демонстрацию как-то прописать в договоре заранее, до подписания акта. Бывают такие заказчики, которые не разбираются в ИТ или у них нет на это времени, или хз какие у них могут на это ещё быть причины, и они попросту не понимают, как проверить то, что они получают от разработчика, на предмет соответствия ТЗ. Двойной акт должен снизить риски такого непонимания.
Заказчик ничего не скачивал. Вроде бы разработчик ему как будто бы создавал логин, так он рассказал на суде, но этот логин был только у разработчика, заказчику он доступы не передал.
Прошу возразить аргументированно.
Ну, тут я не спорю. В данном случае нас не интересовало наличие локальной копии, потому что нам её просто не давали. А заинтересовало то, что есть копия на серверах GitHub. И этой копии там по закону быть не должно.
Мы пошли пока по-другому пути. Хотя и ваш вариант тоже имеет место быть.
ФСТЭК тут ни при чём.
Согласен про локальную копию. Но тогда это будет сервер GitHub и сервер разработчика. А в нашем случае разработчик попросту отказался передать заказчику код. И заказчик остался ни с чем. Более того последний раз, когда мы с ним общались уже после суда, он вообще сказал, что он его попросту удалил.
Зачем нам признавать какое-то право? По закону любой договор трактуется в соответствии с правом страны, которое к нему применяется. В нашем случае из условий использования GitHub однозначно следует, что он лицензионный и что он наделяет GitHub правами на код. Он имеет такую же силу в России, как и местные договоры. Плюс не стоит забывать, что публикация кода на GitHub сама по себе уже является доведением до всеобщего сведения.
По умолчанию исключительное право на программу для ЭВМ, базу данных или иное произведение, созданные по договору, предметом которого было создание такого произведения (по заказу), принадлежит заказчику, если договором между подрядчиком (исполнителем) и заказчиком не предусмотрено иное. Но как правило в договорах прописывают, что права переходят с момента подписания акта.
Лучше да, в обратную предоставить какой-то набор прав разработчику. Но в данном случае ничего подобного не было. А по закону разработчик имеет минимум прав на код, права на который он передал заказчику - использовать его для собственных нужд, к которым как минимум не относится его передача по лицензии другим лицам.
Я может чего-то не понимаю, всё же я юрист, а не разработчик, но здесь рассматривается конкретная система - GitHub. Не локальная VCS, а именно та, которая развёрнута на северах GitHub. Как децентрализация поможет, если GitHub отключит все аккаунты российских разработчиков? По-моему никак. Если ошибаюсь - поправьте меня.
С Open Source проектами тоже довольно много инцидентов было. Вспомнить хотя бы тот же TrueCrypt. Только репутацию там портить особо некому. Открытое ПО настолько размазано по разработчикам и корпорациям, что единого ответственного там просто нет. Проект TrueCrypt, например, просто прикрылся и все.