Значит, вы наказали разработчика за то, что он отказался работать себе в убыток.
Это лишь моё предположение, что он отказался работать себе в убыток. Каковы были его причины, что он сказал "мне судиться будет дешевле, чем продолжать работу" - это загадка для меня.
А как следовало поступать в этой ситуации? Вот давайте представим, что вы сами попали в точно такую ситуацию. Вы заключили договор и сделали часть работы, но потом поняли, что за предложенную сумму сделать эту работу невозможно. А значит, исполнение этой работы означает для вас обязательный убыток.
Как бы вы поступили, чтобы выйти из договора, не потеряв никаких денег?
Я попадал в такую ситуацию. Ради своей репутации я просто выполнял работу добросовестно и качественно, как и обещал. Моя неверная оценка стоимости работы - моя проблема, не заказчика.
Как заказчик аргументировал что код на GitHab его? Если он его не получал? Может исполнитель просто взял деньги и не выполнил заказ. А то что он выложил на GitHab — это его личные разработки. В таком случае предмет спора только возврат денег за не выполненный заказ.
А Вы знаете, тут нам очень помогло решение по предыдущему суду, которое прошло апелляционную инстанцию и было оставлено без изменения. Оно в целом хоть и было не в пользу моего клиента, однако из него удалось выжать все соки. В частности, в нём прямо были указаны адреса на конкретные репозитории с кодом, который все фактически признали, что является результатом работы разработчика. Тут мне даже не нужно было ничего аргументировать в этом плане. В трёх экспертизах было указано, что сам разработчик дал удалённый доступ к трём репозиториям с кодом. Очевидно же, что это и был тот самый разработанный по договору код, права на который перешли к заказчику.
И вообще неясно — заплатили ли вы вообще? Обычно подписывается акт передачи кода, так в каком виде код был передан заказчику? Но если код не передавался (по вашим словам) — то заказ не был выполнен. Опять же предмет спора — невыполнения заказа.
Заказчик заплатил за разработку кода, это 100%. Обычно подписывается акт передачи кода, да только тут акты были направлены заказчику молча, и он также молча на них никак не отреагировал. Суд посчитал, что раз 5 дней прошло, активности заказчик не проявил - ни отказался от приёмки, не подтвердил её, то значит работы приняты. Но суд констатировал это формально, это значит, что работы приняты просто за отсутствием возражений со стороны заказчика. А фактически никто и ничего не передавал. Этот вопрос изучался в судебном деле, которое было до меня. Вот ссылка. Как раз там и был предмет спора - невыполнение заказа.
И не понятна позиция исполнителя, что значит он отказался предать код, когда он его аж на GitHab выложил? Вот просто так взял и отказался, из за своей неконтролируемой злобы?
Вот тут хз. Со слов заказчика - отказался, сказал, что судиться ему будет дешевле. А после суда, о котором я написал в статье, вообще заявил, что теперь он его удалит. Честно говоря, мне мотивы такого поведения разработчика были малоинтересны. У меня была задача, которой я нашёл интересное решение.
Сам GitHub тут, конечно, вообще в споре не участвует. Он о нём даже не знает. Но мне важно было выстроить логическую цепочку: отсутствие прав на код -> публикация на GitHub, что равно заключению лицензионного договора -> нарушение исключительных прав. И мне это удалось. Факт размещения кода на GitHub - это как минимум доведение до всеобщего сведения, воспроизведение и распоряжение исключительным правом на код, который публикатору не принадлежит.
Вы наказали нерадивого разработчика и это правильно, но наводить тень на плетень не стоит. Как справедливо отметил oraclejob :
Не согласен. Под комментом @oraclejob в принципе уже всё написано в ответ.
и то что он американский это за уши притянуто. Все кто им пользуется, ему просто доверяют и не задумываются об его принадлежности.
А зря. Вон недавно рассматривался даже вопрос о блокировке аккаунтов российских разработчиков. Вроде пронесло. Но надолго ли?
Наверное, почти все. Защищаем как разработчиков, так и заказчиков. Регистрируем всё, что регистрируется (кроме изобретений и полезных моделей), защищаем всё, что защищается. Если что-то конкретно интересует - напишите в личку.
Там договор был довольно куцый. В плане сдачи-приёмки работ было написано просто, что они сдаются по актам и всё. Но я бы попросил передать код как минимум с описью всех передаваемых файлов и их MD5 или SHA256. Заказчик вообще помимо этого просил ещё и демонстрацию провести, правда договором это не было предусмотрено и я его предупредил, что такое требование хоть и можно заявить (не в суде, а в претензии), но скорее всего его пошлют. Это недоработка самого договора, увы. Хотя с другой стороны, по закону результат, который передает разработчик (как любой подрядчик) должен быть пригоден к использованию. А как это подтвердить, если передавать просто файлы по описи? Никак. Тут без демонстрации никак.
Экспертам дали доступ к приватным репозиториям. Я чуть выше писал, тут продублирую.
Судя по заключению экспертизы разработчик давал экспертам (трём, на минуточку) доступы к приватным репозиториям (там их было три - код под Android, под iOS и серверная платформа). Во всех заключениях присутствует одна и та же фраза: "На исследование был предоставлен удаленный доступ к репозиториям разработанного программного обеспечения со следующими параметрами..." и дальше адреса репозиториев. Сам разработчик в суде заявлял о приватных репозиториях, о доступе только по приглашению и так далее. И вроде бы даже клиент присутствовал при осмотре репозиториев через видеосвязь, но сам доступ к ним разработчик ему никогда не давал, а письма - игнорировал.
Ну, вы частично правы. Дело в том, что я стараюсь писать свои статьи максимально доступным языком, иногда упрощая некоторые вещи. В данном случае фраза "передача прав на код", конечно, является упрощением. По факту конструкция авторских прав имеет следующие уровни вложенности:
исключительное право (имущественное), которое включает следующие способы использования произведения (так называемые правомочия):
правомочие на воспроизведение произведения;
правомочие на распространение произведения;
правомочие на публичный показ произведения;
правомочие на импорт произведения в целях распространения;
правомочие на прокат произведения;
правомочие на публичное исполнение произведения;
правомочие на сообщение в эфир;
правомочие на сообщение по кабелю;
правомочие на ретрансляцию;
правомочие на перевод или другую переработку произведения;
правомочие на практическую реализацию архитектурного, дизайнерского, градостроительного или садово-паркового проекта;
правомочие на доведение произведения до всеобщего сведения;
иные правомочия (список открыт, можно использовать произведение и способом, которого в законе попросту нет).
неимущественные права и иные права:
право следования;
право доступа;
право авторства;
право автора на имя;
право на неприкосновенность произведения;
право на отзыв.
Так вот, говоря о "правомочиях", очень часто это громоздкое слово заменяют на "право". Например, в лицензионных договорах почти всегда пишут "право на воспроизведение ПО".
А зря Вы ничего не говорите про договорные отношения. Вопрос соотношения понятий "публикация" и "передача прав" реально зависит от взаимоотношений публикатора с тем, кто владеет ресурсом, на котором это самое опубликование происходит. В самом простом случае "публикация" не будет равна "передаче прав" только если она происходит на своем собственном сервере, который торчит наружу в сеть 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. И этой копии там по закону быть не должно.
Это лишь моё предположение, что он отказался работать себе в убыток. Каковы были его причины, что он сказал "мне судиться будет дешевле, чем продолжать работу" - это загадка для меня.
Я попадал в такую ситуацию. Ради своей репутации я просто выполнял работу добросовестно и качественно, как и обещал. Моя неверная оценка стоимости работы - моя проблема, не заказчика.
А Вы знаете, тут нам очень помогло решение по предыдущему суду, которое прошло апелляционную инстанцию и было оставлено без изменения. Оно в целом хоть и было не в пользу моего клиента, однако из него удалось выжать все соки. В частности, в нём прямо были указаны адреса на конкретные репозитории с кодом, который все фактически признали, что является результатом работы разработчика. Тут мне даже не нужно было ничего аргументировать в этом плане. В трёх экспертизах было указано, что сам разработчик дал удалённый доступ к трём репозиториям с кодом. Очевидно же, что это и был тот самый разработанный по договору код, права на который перешли к заказчику.
Заказчик заплатил за разработку кода, это 100%. Обычно подписывается акт передачи кода, да только тут акты были направлены заказчику молча, и он также молча на них никак не отреагировал. Суд посчитал, что раз 5 дней прошло, активности заказчик не проявил - ни отказался от приёмки, не подтвердил её, то значит работы приняты. Но суд констатировал это формально, это значит, что работы приняты просто за отсутствием возражений со стороны заказчика. А фактически никто и ничего не передавал. Этот вопрос изучался в судебном деле, которое было до меня. Вот ссылка. Как раз там и был предмет спора - невыполнение заказа.
Вот тут хз. Со слов заказчика - отказался, сказал, что судиться ему будет дешевле. А после суда, о котором я написал в статье, вообще заявил, что теперь он его удалит. Честно говоря, мне мотивы такого поведения разработчика были малоинтересны. У меня была задача, которой я нашёл интересное решение.
Всё верно.
Сам GitHub тут, конечно, вообще в споре не участвует. Он о нём даже не знает. Но мне важно было выстроить логическую цепочку: отсутствие прав на код -> публикация на GitHub, что равно заключению лицензионного договора -> нарушение исключительных прав. И мне это удалось. Факт размещения кода на GitHub - это как минимум доведение до всеобщего сведения, воспроизведение и распоряжение исключительным правом на код, который публикатору не принадлежит.
Не согласен. Под комментом @oraclejob в принципе уже всё написано в ответ.
А зря. Вон недавно рассматривался даже вопрос о блокировке аккаунтов российских разработчиков. Вроде пронесло. Но надолго ли?
Наверное, почти все. Защищаем как разработчиков, так и заказчиков. Регистрируем всё, что регистрируется (кроме изобретений и полезных моделей), защищаем всё, что защищается. Если что-то конкретно интересует - напишите в личку.
Там договор был довольно куцый. В плане сдачи-приёмки работ было написано просто, что они сдаются по актам и всё. Но я бы попросил передать код как минимум с описью всех передаваемых файлов и их MD5 или SHA256. Заказчик вообще помимо этого просил ещё и демонстрацию провести, правда договором это не было предусмотрено и я его предупредил, что такое требование хоть и можно заявить (не в суде, а в претензии), но скорее всего его пошлют. Это недоработка самого договора, увы. Хотя с другой стороны, по закону результат, который передает разработчик (как любой подрядчик) должен быть пригоден к использованию. А как это подтвердить, если передавать просто файлы по описи? Никак. Тут без демонстрации никак.
Экспертам дали доступ к приватным репозиториям. Я чуть выше писал, тут продублирую.
Судя по заключению экспертизы разработчик давал экспертам (трём, на минуточку) доступы к приватным репозиториям (там их было три - код под Android, под iOS и серверная платформа). Во всех заключениях присутствует одна и та же фраза: "На исследование был предоставлен удаленный доступ к репозиториям разработанного программного обеспечения со следующими параметрами..." и дальше адреса репозиториев. Сам разработчик в суде заявлял о приватных репозиториях, о доступе только по приглашению и так далее. И вроде бы даже клиент присутствовал при осмотре репозиториев через видеосвязь, но сам доступ к ним разработчик ему никогда не давал, а письма - игнорировал.Ну если упростить, то можно и так сказать.
Ну, вы частично правы. Дело в том, что я стараюсь писать свои статьи максимально доступным языком, иногда упрощая некоторые вещи. В данном случае фраза "передача прав на код", конечно, является упрощением. По факту конструкция авторских прав имеет следующие уровни вложенности:
исключительное право (имущественное), которое включает следующие способы использования произведения (так называемые правомочия):
правомочие на воспроизведение произведения;
правомочие на распространение произведения;
правомочие на публичный показ произведения;
правомочие на импорт произведения в целях распространения;
правомочие на прокат произведения;
правомочие на публичное исполнение произведения;
правомочие на сообщение в эфир;
правомочие на сообщение по кабелю;
правомочие на ретрансляцию;
правомочие на перевод или другую переработку произведения;
правомочие на практическую реализацию архитектурного, дизайнерского, градостроительного или садово-паркового проекта;
правомочие на доведение произведения до всеобщего сведения;
иные правомочия (список открыт, можно использовать произведение и способом, которого в законе попросту нет).
неимущественные права и иные права:
право следования;
право доступа;
право авторства;
право автора на имя;
право на неприкосновенность произведения;
право на отзыв.
Так вот, говоря о "правомочиях", очень часто это громоздкое слово заменяют на "право". Например, в лицензионных договорах почти всегда пишут "право на воспроизведение ПО".
А зря Вы ничего не говорите про договорные отношения. Вопрос соотношения понятий "публикация" и "передача прав" реально зависит от взаимоотношений публикатора с тем, кто владеет ресурсом, на котором это самое опубликование происходит. В самом простом случае "публикация" не будет равна "передаче прав" только если она происходит на своем собственном сервере, который торчит наружу в сеть 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. И этой копии там по закону быть не должно.
Мы пошли пока по-другому пути. Хотя и ваш вариант тоже имеет место быть.