Меня зовут Михаил, я юрист в сфере IT/IP и это моя первая статья на Хабре на юридическую тематику. Обычно я их публикую на своём сайте, но в этот раз она сильно затрагивает сообщество программистов, поэтому я решил поделиться ею и на Хабре тоже.
В заголовок своей очередной статьи я вынес весьма непростой и, отчасти, провокационный вопрос.
GitHub, как и другие ему подобные облачные сервисы, стал неотъемлемой частью процесса разработки программного обеспечения.
Исходный код в нём удобно хранить, удобно отслеживать изменения в нём, удобно делиться им с другими разработчиками, удобно передавать разработку другим командам. Очень много удобства. Но есть ли у такого удобного сервиса недостатки?
Я провел собственное исследование этого вопроса и представляю его результаты в этой статье. Более того, я уже успел применить его на практике, о чём расскажу в конце статьи (спойлер - если вы разрабатываете код под заказ, то хранение кода на GitHub лучше согласовывать с заказчиком письменно, или не хранить его там вообще).
Какие недостатки могут быть у GitHub?
Самый первый недостаток GitHub (здесь и далее имеется в виду именно онлайн-сервис https://github.com/, а не локальная платформа GitHub Enterprise Server) - это то, что он принадлежит совершенно посторонней американской компании GitHub Inc.
Это означает, что исходный код программы передаётся на хранение совершенно чужой компании, находящейся под юрисдикцией другого государства.
Нет никакой гарантии, что эта компания в определённый момент не отключит сервера, обеспечивающие работу GitHub и весь доступ к исходному коду просто накроется медным тазом.
И хорошо, если у вас будет бэкап, а если нет? А если бэкап достаточно старый? Это будет невероятной проблемой.
А есть ли юридические основание передавать такой код на хранение американской компании? Конечно есть. Но это и есть второй недостаток GitHub.
Хранение кода на GitHub - это передача ему лицензии на код
Не в отношении всех способов использования, конечно, но перечень достаточно широкий, что может вызвать массу проблем у разработчиков с заказчикам. Эти способы использования в законе называют правомочиями, а иногда (в частности в документах GitHub) также называют и правами.
Так, при регистрации на GitHub пользователю предлагается принять условия использования сервиса, изложенные в документе "GitHub Terms of Service" (перев. с англ. – "Условия использования GitHub") по ссылке https://github.com/site/terms.
Тут надо отметить, что сам GitHub представляет собой интернет-сайт, который законы РФ (и не только РФ) определяют как совокупность программ для ЭВМ, баз данных и информации, хранящейся и обрабатываемой при помощи них.
Правовое регулирование использования сервисов такого рода осуществляется при помощи условий использования, которые юридически представляют собой комбинацию лицензионного договора и, в некоторых случаях, договора об оказании информационных услуг.
В нашем случае условия использования сервиса GitHub представляют собой практически чистый лицензионный договор.
Какие правомочия получает GitHub на код?
Для ответа на этот вопрос обратимся к тексту условий использования GitHub.
Так в секции "D" условий использования GitHub определено следующее:
Английская версия:
"Short version: You own content you create, but you allow us certain rights to it, so that we can display and share the content you post. You still have control over your content, and responsibility for it, and the rights you grant us are limited to those we need to provide the service. We have the right to remove content or close Accounts if we need to."
Приблизительный перевод на русский язык:
"Краткая версия: Вы являетесь владельцем создаваемого вами контента, но предоставляете нам определенные права на него, чтобы мы могли отображать и делиться размещенным вами контентом. Вы по-прежнему контролируете свой контент и несете за него ответственность, а права, которые вы предоставляете нам, ограничены теми, которые нам необходимы для предоставления сервиса. Мы имеем право удалять контент или закрывать Учетные записи, если это необходимо."
В разделе 4 секции "D" условий использования GitHub определено следующее:
Английская версия:
"We need the legal right to do things like host Your Content, publish it, and share it. You grant us and our legal successors the right to store, archive, parse, and display Your Content, and make incidental copies, as necessary to provide the Service, including improving the Service over time. This license includes the right to do things like copy it to our database and make backups; show it to you and other users; parse it into a search index or otherwise analyze it on our servers; share it with other users; and perform it, in case Your Content is something like music or video.
This license does not grant GitHub the right to sell Your Content. It also does not grant GitHub the right to otherwise distribute or use Your Content outside of our provision of the Service, except that as part of the right to archive Your Content, GitHub may permit our partners to store and archive Your Content in public repositories in connection with the GitHub Arctic Code Vault and GitHub Archive Program."
Приблизительный перевод на русский язык:
"Нам нужно законное право делать такие вещи, как размещать ваш Контент, публиковать его и делиться им. Вы предоставляете нам и нашим правопреемникам право хранить, архивировать, анализировать и отображать ваш Контент, а также делать случайные копии, если это необходимо для предоставления Сервиса, включая улучшение Сервиса с течением времени. Эта лицензия включает в себя право делать такие вещи, как копировать его в нашу базу данных и создавать резервные копии; показывать его вам и другим пользователям; анализировать его в поисковом индексе или иным образом анализировать на наших серверах; делиться им с другими пользователями; и выполнять его, если ваш контент представляет собой что-то вроде музыки или видео.
Эта лицензия не дает GitHub права продавать ваш Контент. Это также не дает GitHub права иным образом распространять или использовать ваш Контент за пределами нашего предоставления Услуг, за исключением того, что в рамках права на архивирование вашего Контента GitHub может разрешить нашим партнерам хранить и архивировать ваш Контент в общедоступных репозиториях в связи с программами GitHub Arctic Code Vault и GitHub Archive Program."
В разделе 5 секции "D" условий использования GitHub определено следующее:
Английская версия:
"Any User-Generated Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).
If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you adopt a license. If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users."
Приблизительный перевод на русский язык:
"Любой Пользовательский Контент, который вы размещаете публично, включая вопросы, комментарии и вклады в репозитории других Пользователей, может быть просмотрен другими Пользователями. Устанавливая общедоступность ваших репозиториев, вы соглашаетесь разрешить другим Пользователям просматривать и "разветвлять" ваши репозитории (это означает, что другие могут создавать собственные копии содержимого из ваших репозиториев в репозиториях, которые они контролируют).
Если вы настроили публичный просмотр своих страниц и репозиториев, вы предоставляете каждому Пользователю GitHub неисключительную всемирную лицензию на использование, отображение и воспроизведение вашего Контента через Сервис GitHub, а также на воспроизведение вашего Контента исключительно на GitHub, как это разрешено функциональными возможностями GitHub (например, с помощью разветвления). Вы можете предоставить дополнительные права, если вы принимаете лицензию. Если вы загружаете Контент, который вы не создавали или не являетесь владельцем, вы несете ответственность за то, чтобы загружаемый вами Контент лицензировался на условиях, которые предоставляют эти разрешения другим Пользователям GitHub."
Таким образом, при регистрации пользователя на GitHub и принятии им условий использования GitHub» (https://github.com/site/terms) фактически между пользователем и компанией GitHub Inc. заключается лицензионный договор о предоставлении этой компании неисключительной (простой) лицензии на любой материал, который такой пользователь публикует в репозиториях сервиса GitHub, в том числе и исходный код компьютерных программ.
Такой лицензионный договор предоставил в отношении программного кода компании GitHub Inc. следующие права:
хранить, архивировать, анализировать и отображать программный код;
делать случайные копии программного кода;
копировать программный код в базу данных GitHub и создавать резервные копии;
показывать программный код пользователям;
анализировать программный код в поисковом индексе или иным образом анализировать на серверах GitHub;
делиться программным кодом с другими пользователями;
проигрывать графические, аудио и видео элементы, загруженные в GitHub.
Учитывая, что в большинстве случаев при разработке программного обеспечения на заказ все права на программный код принадлежат заказчику, то возникает вопрос - а на каком основании разработчик выложил уже не свой код на совершенно посторонний ресурс, заключив с его владельцем при этом лицензионный договор? Лицензионный договор, на минуточку, в отношении кода, которым разработчик больше не владеет.
На самом деле ни на каком основании. В том и проблема, что в отсутствие каких-либо прав на программный код разработчик просто не вправе заключать в отношении него лицензионные договоры, а потому, как следствие, он не вправе его выкладывать на GitHub.
Выгрузка программного кода на GitHub означает, что разработчиком произведена запись программного кода на электронный носитель (т.е. в хранилище данных сервера GitHub) с последующим предоставлением доступа к программному кода любому лицу из любого места и в любое время (т.е. предоставление доступа к коду любому пользователю GitHub, который имеет ссылку, в т.ч. сотрудникам самого GitHub) – всё это является и воспроизведением, доведением до всеобщего сведения и распоряжением исключительным правом на программный код. Незаконным.
Итого, сам по себе факт выгрузки программного кода на GitHub будет означать, что разработчик нарушил права заказчика на программный код.
Решают ли эту проблему закрытые репозитории на GitHub?
Совершенно нет, не решают. Обратимся снова к условиям использования GitHub.
В отношении так называемых "закрытых", "приватных" или "частных", репозиториев в разделе 3 секции "Е" условий использования GitHub определено следующее:
Английская версия:
"GitHub personnel may only access the content of your private repositories in the situations described in our Privacy Statement."
Приблизительный перевод на русский язык:
"Сотрудники GitHub могут получать доступ к содержимому ваших частных репозиториев только в ситуациях, описанных в нашем Заявлении о конфиденциальности."
Само именование репозитория, как или "закрытого", или "приватного", или "частного", никоим образом не влияет на факт размещения исходного кода на GitHub, поскольку придание репозиторию такого статуса является просто одной из функций GitHub, как компьютерной программы, при помощи которой реализуется доступность репозитория по ссылке или путём добавления пользователей в специальный список доступа.
Иными словами, именно пользователь решает, какой статус будет иметь его репозиторий. Он может сделать его в любой момент "закрытым" или открыть для всеобщего доступа, а также распространять специальные ссылки для доступа к репозиторию, что в принципе обесценивает статус "закрытого" репозитория при наличии неопределённого числа лиц, имеющих ссылки для доступа к нему.
Соответственно, закрытие репозитория не решает проблему, хотя и может её скрыть от посторонних глаз, если, конечно, это не всплывёт каким-то иным способом.
Какие могут быть последствия у публикации кода на GitHub?
Поскольку несанкционированная публикация исходного кода на GitHub является нарушением прав на этот код, которые уже принадлежат заказчику, то логично, что вся ответственность будет аналогичной той, какую несёт любой нарушитель авторских прав.
Самый популярный способ - это взыскание через суд компенсации в размере либо от 10 000 до 5 000 000 рублей, либо в размере двойной ставки лицензионного вознаграждения по договорам с аналогичными условиями, как у нарушения, либо двойной цены контрафактного программного кода.
Реже можно встретить уголовное преследование за нарушение исключительных прав. За публикацию кода на GitHub я пока такого не встречал, так как моё исследование - это новинка. И на практике мне такое удалось реализовать только один раз.
Так что там с судебной практикой?
Мне удалось применить результаты исследования на практике, поэтому я и написал эту статью, как предостережение всем разработчикам.
Фабула дела была такова. После завершения разработки компания разработчик передала все права на код заказчику, но вот сам код не передала. Как так получилось - не спрашивайте. Оставим этот вопрос за рамками статьи.
Я подключился уже на этапе, когда уже было ничего не сделать. Но сам код оказался выгружен на GitHub, так как в трёх экспертизах в предыдущем судебном деле эксперты знакомились с кодом именно на GitHub на аккаунте разработчика. Да только экспертизы эти были уже сильно позже даты официального перехода прав на код к заказчику.
Я провёл исследование и пришёл к выводу, что разработчик, не имея никаких прав на код (кроме очень ограниченной неисключительной лицензии по закону) загрузил его на GitHub.
Как я расписал выше загрузка кода на GitHub - это заключение лицензионного договора с американской компанией GitHub Inc., который наделяет её правами публиковать код, распространять его и так далее.
Поскольку заключение лицензионного договора и выгрузка кода на GitHub - это нарушение исключительных прав, то я обратился в интересах клиента с иском к разработчику в арбитражный суд и потребовал взыскать компенсацию в двойном размере от цены контрафактного кода.
При этом мне удалось доказать, что цена контрафактного кода равна цене его разработки, зафиксированной в договоре и впоследствии подтверждённой экспертом.
Итого, суд поддержал мою позицию, признал факт размещения кода на GitHub нарушением исключительных прав заказчика на код и взыскал двойную стоимость разработки.
В результате разработчик потерял денег в два раза больше, чем приобрёл.
Казалось бы я тут выгляжу очень коварным юристом, разработавшим план по отъёму денег у разработчика, но это не так. Разработчик повёл себя очень некрасиво - ему дважды писались письма о том, чтобы он передал код, но он на них так и не ответил, а устно сообщил, что ничего передавать он не намерен и мы можем судиться до побеления. Но вышло не так.
С самим делом вы можете ознакомиться по этой ссылке.
Есть рекомендации, как этого избежать?
Да, я уже упоминал об этом в статье. Во-первых, если очень хочется использовать GitHub, то пропишите это в договоре с заказчиком. И тогда, если у него будут претензии, то это вас защитит.
Во-вторых, после завершения разработки и сдачи работ заказчику удалите код из GitHub, ну или хотя бы закройте к нему доступ (но это не убирает нарушение, а только скрывает его).
В-третьих, будьте добросовестными разработчиками и не делайте ничего назло.
Комментарии (351)
DustCn
09.04.2023 14:15+25Пугалки от фстэк оставьте себе.
Adverte
09.04.2023 14:15Человек себе на хлеб зарабатывает как может и тут вы
vikarti
09.04.2023 14:15+10Человек упомянул именно юридические риски, и дал пример дела когда суд решил что низзя было на гитхаб (но с тем же успехом — нельзя на любой сервис ведь наверно?).
Мне вот казалось совсем не очевидным что можно так придратся.
Была бы пугалка от ФСТЭК — была бы реклама gitflic'а :)
oraclejob
09.04.2023 14:15+4Поскольку заключение лицензионного договора и выгрузка кода на GitHub - это нарушение исключительных прав
Судью не смутило то, что GitHub находится в юрисдикции, отличающейся от российской правовой системы, и английский язык - не тот, на котором ведется процесс? Т.е. недостаточно перевести текст договора, это не художественная литература, где, если Майк любит Саманту, то мы понимаем, о чем речь. На основании какого российского закона (мы ведь в России, да?) был принят юридически значимым договор с GitHub, мы стали признавать англо-саксонское право? На месте исполнителей я бы сказал, что не разбираюсь в английской юриспруденции, текст договора не читал (его ведь никто не читал, не так ли?) и смысла его не понимаю, силы в России он не имеет и на гитхабе просто несколько раз нажал Yes при создании аккаунта, а то, что гитхаб - общепринятое хранилище кода, никто не оспаривает вроде.
aborouhin
09.04.2023 14:15+8В VI разделе ГК Вас ждёт масса увлекательных открытий.
SerjV
09.04.2023 14:15+3Вы имели в виду 4-ю часть ГК РФ?..
Нет, не туда надо смотреть oraclejob . А в третью часть.
Там будет ответ даже на вопрос "почему при рассмотрении дела в российском суде применяется право иностранного государства", не говоря уж о менее "удивительных" моментах в его сообщении.
aborouhin
09.04.2023 14:15+5Я имел в виду то, что и написал, - VI раздел, который в третьей части. Потому что V раздел той же третьей части, посвящённый наследственному праву, тут точно не при чём, так что я конкретизировал :)
SerjV
09.04.2023 14:15+1имел в виду то, что и написал, - VI раздел, который в третьей части.
Тогда поддерживаю вас, всё верно!
mshewzov Автор
09.04.2023 14:15+7Зачем нам признавать какое-то право? По закону любой договор трактуется в соответствии с правом страны, которое к нему применяется. В нашем случае из условий использования GitHub однозначно следует, что он лицензионный и что он наделяет GitHub правами на код. Он имеет такую же силу в России, как и местные договоры. Плюс не стоит забывать, что публикация кода на GitHub сама по себе уже является доведением до всеобщего сведения.
SerjV
09.04.2023 14:15+2По закону любой договор трактуется в соответствии с правом страны, которое к нему применяется.
Тут всё верно.
В нашем случае из условий использования GitHub однозначно следует, что он лицензионный и что он наделяет GitHub правами на код. Он имеет такую же силу в России, как и местные договоры.
А вот тут вы забыли о самом главном, на что замахнулись в предыдущем предложении - об этом самом применимом праве. Да, лицензионный договор в любой стране будет лицензионным. Вот только применимым правом может оказаться не только российское, но и иностранное. Причём даже в случае рассмотрения дела в российском суде. Это всё определяется сочетанием закона и договора... Хотя даже и подсудность может быть договорной.
mshewzov Автор
09.04.2023 14:15Я вам больше скажу - условия использования GitHub подчиняются федеральным законам США и законам штата Калифорния.
В секции "R" в пункте 1 вот так написано:
"За исключением случаев, когда применимое право предусматривает иное, настоящее Соглашение между вами и GitHub, а также любой доступ или использование Веб-сайта или Сервиса регулируются федеральными законами Соединенных Штатов Америки и законами штата Калифорния без учета коллизионных норм. Вы и GitHub соглашаетесь подчиняться исключительной юрисдикции и месту проведения судов, расположенных в городе и округе Сан-Франциско, штат Калифорния."
Да только что это меняет? Это правило применяется в отношении споров, которые возникают между пользователем сервиса GitHub и его владельцем - компанией GitHub Inc.
В целях же нашего судебного разбирательства нам важно было установить следующее:
использование GitHub осуществляется на основе лицензионного договора, а это один из видов распоряжения исключительным правом;
публикация кода на GitHub является доведением до всеобщего сведения;
публикация кода на GitHub является частным случаем воспроизведения.
Применяемое к условиям использования GitHub иностранное право нам тут вообще никак не мешает.
SerjV
09.04.2023 14:15+2Применяемое к условиям использования GitHub иностранное право нам тут вообще никак не мешает.
Согласен. Поскольку Гитхаб не является стороной спора, а потому применимое к лицензионного договору с ним право для спора имеет значение ровно настолько, чтобы можно было определить тип договора (или типы договора, если это договор смешанного типа). А после присоединения США к Бернской конвенции - принципы, позволяющие это определить, одинаковы и у них, и у нас.
А со спором заказчика с разработчиком всё понятно :)
Просто в цепочке рассуждений в вопросе комментатора и вашем ответе ему эта мысль явно не прозвучала - что гитхаб не сторона спора, а к договору между заказчиком и разработчиком, у которых спор как раз и есть, применимо право российское.
mshewzov Автор
09.04.2023 14:15+1Наверное я упустил этот момент. Мне казалось, что это очевидно, что GitHub не сторона спора :)
oraclejob
09.04.2023 14:15+1Таким образом, исходный код приложения (версии для Android, iOS и
серверной платформы) на момент исследования находился в сети Интернет в репозиториях, которыми владеет ООО «Ера»Где можно посмотреть доказательства? Я вижу обратное - некто Roman fescoxxx имеет личный репозиторий, в нем лежат результаты его личного труда
// Created by Роман Давыдов on 26.07.2018.
// Copyright © 2018 Админ. All rights reserved.
Разрешала ли компания публиковать исходный код там? Есть ли приказ на это? Есть ли вообще договор о правах на ПО между компанией и этим разработчиком? Куча не отвеченных вопросов. Может быть, Роман считает написанный код своим? Я приведу Вам другой пример, один программист написал в рабочее время веб-сервер, выложил исходники в открытый доступ, а через некоторое время продал права на него за много миллионов - так выглядит позиция с т.з. юриста компании. А так выглядит ситуация с другой стороны:
https://habr.com/ru/articles/480040/
https://habr.com/ru/articles/480510/
https://habr.com/ru/news/507790/
Сдается мне, Эра просто сэкономила на юристе.
публикация кода на GitHub сама по себе уже является доведением до всеобщего сведения
Я это не оспаривал, но с таким же успехом можно было выложить в любой файлообменник.
mshewzov Автор
09.04.2023 14:15Разрешала ли компания публиковать исходный код там? Есть ли приказ на это? Есть ли вообще договор о правах на ПО между компанией и этим разработчиком? Куча не отвеченных вопросов. Может быть, Роман считает написанный код своим?
Эти вопросы не подымались в суде. Более того, сам разработчик заявил изначально в прошлом судебном деле, что код в репозиториях по ссылкам - это тот самый код, который его компания разработала по договору. Включать заднюю и говорить, что это личный код Романа Давыдова, было бы уже поздно. Ну и с точки зрения закона, исполнитель тут ООО, а другое ООО заказчик, а значит трудовые взаимоотношения внутри компании-разработчика между неё и её сотрудниками - это не проблема заказчика. По умолчанию исключительное право на служебное произведение принадлежит работодателю.
Я приведу Вам другой пример, один программист написал в рабочее время веб-сервер, выложил исходники в открытый доступ, а через некоторое время продал права на него за много миллионов - так выглядит позиция с т.з. юриста компании.
Там история была сложнее. Насколько я помню автор nginx вообще не был штатным программистом, а был сисадмином. Т.е. даже гипотетически его разработка не должна была стать служебным произведением работодателя, т.к. просто программирование не входило в его служебные обязанности.
Я это не оспаривал, но с таким же успехом можно было выложить в любой файлообменник.
Не совсем. Файлообменники в своих условиях использования обычно не претендуют на права в отношении размещаемых там файлов. Обычно это чисто информационно-технологические услуги.
Aldrog
09.04.2023 14:15Не совсем. Файлообменники в своих условиях использования обычно не претендуют на права в отношении размещаемых там файлов. Обычно это чисто информационно-технологические услуги.
Неужели им не нужно делать бекапы и предоставлять доступ другим пользователям? Или по какой-то причине им, в отличие от GitHub, для этого не нужна лицензия?
mshewzov Автор
09.04.2023 14:15Не знаю. По факту я не видел ни одного файлообменника, у которого условия использования выглядели бы как лицензионный договор. Ни один из них не запрашивает права на использование контента. Я думаю, что они бэкапы делают не конкретного контента, а полностью весь сервер. Возможно при таком подходе никакого использования контента, который загружают пользователи на этот сервер, они не производят - файлообменники его не демонстрируют, никому не распространяют, не передают, поэтому используется конструкция оказания информационно-технологических услуг. Видимо, причина в этом, это моё предположение. Взять тех же самых операторов связи. Они тоже пропускают через свои сети огромное количество пользовательского контента. Но при этом они в свои договоры не включают, что они претендуют на какие-то права на этот контент.
developer7
09.04.2023 14:15+2как лицензионный договор
А как должен выглядит этот договор? По логике любое условие использования — это уже договор. И эти договора есть практически везде. Просто в большинстве случаев там стоит что то типа, если вы пользуетесь сервисом, значит приняли договор. Что тоже выглядит мутно — но так все себя защищают от юридических нападений.
Ради интереса посмотрел, а есть ли договор на VisualStudio, никогда его не видел, и так мельком посмотрев увидел например такое:
Программное обеспечение может собирать сведения о Вас и об использовании Вами программного обеспечения и передавать затем эти сведения в корпорацию Microsoft. Корпорация Microsoft может использовать ее для предоставления услуг и улучшения своих продуктов и служб. Вы можете отказаться от применения большинства таких сценариев, но не от всех.
Во всех студиях будет нечто похожее. А Windows со своими отслеживающими сервисами. И весь тот код который разрабатывал исполнитель уже будет покрыт такими соглашениями. И ни о каких исключительных правах речи не может идти, т.к. раньше них уже идут соглашения студий разработки.
SerjV
09.04.2023 14:15По факту я не видел ни одного файлообменника, у которого условия использования выглядели бы как лицензионный договор. Ни один из них не запрашивает права на использование контента. Я думаю, что они бэкапы делают не конкретного контента,
А тут всё просто (было до недавнего времени по крайней мере). Файлообменники работают с информацией, а на информацию авторское право не распространяется.
mshewzov Автор
09.04.2023 14:15Ох, с информацией всё сложнее. Информация - это общее понятие, которое в принципе охватывает и объекты авторского права.
По закону (см. Закон № 149-ФЗ) информация - это сведения (сообщения, данные) независимо от формы их представления.
И вот далее в этом законе используется вот такой термин "информация, содержащая объекты авторских и (или) смежных прав". То есть в информации могут быть как объекты авторских или смежных прав, так и могут не быть (например, это какая-то информация, которую нельзя назвать результатом творчества, те же IP-адреса, какие-то общеизвестные факты и так далее).
PereslavlFoto
09.04.2023 14:15+1То есть в информации могут быть как объекты авторских или смежных прав, так и могут не быть (например, это какая-то информация, которую нельзя назвать результатом творчества, те же IP-адреса, какие-то общеизвестные факты и так далее).
ГК РФ 1259 пишет, что некоторые тексты не охраняются авторским правом, потому что не являются результатом творчества. В законе даётся пример — «сообщения о новостях дня».mshewzov Автор
09.04.2023 14:15Да-да, ну я просто всё не перечислял. Как раз такие тексты можно считать информацией, но нельзя считать объектом авторского права. И напротив, художественный рассказ будет и информацией, и объектом авторского права одновременно
SerjV
09.04.2023 14:15Информация - это общее понятие, которое в принципе охватывает и объекты авторского права.
При том, что в самом законе сказано, что "Положения настоящего Федерального закона не распространяются на отношения, возникающие при правовой охране результатов интеллектуальной деятельности и приравненных к ним средств индивидуализации, за исключением случаев, предусмотренных настоящим Федеральным законом." Причём изначально приписки "за исключением" там не было, её добавили в 2013г, когда начали "растягивать" блокировки в интернете с изначальных якобы "защиты детей" на новые области применения.
А растягивать начали... Ну потому что так удобнее понятно борцам за что. Ну и потому что подводить под ст.273 УК с формальным составом преступления гораздо удобнее, чем доказывать по ст.146 УК РФ или по аналогичной в КоАП, а по сравнением с КоАП - еще и тяжесть раскрытого преступления больше (при том, что "в минимальном варианте" преступление по ст.273 УК более тяжкое, чем за ту же наркоту!).
То, что с таким подходом программы резервного копирования можно объявлять вредоносными и сажать половину персонала датацентров и даже производителей "отечественных ОС" - умалчивают в силу избирательного применения закона.
Из-за этого и сделал оговорку про "до недавнего времени". Оно как-бы и сейчас ст.15.6 149-ФЗ (откель ваша цитата) стоит там особняком подобно отменённой презумпции невиновности для нарушений ПДД в КоАП, но лоббисты работают в этом направлении.
mshewzov Автор
09.04.2023 14:15На мой взгляд и без всех этих изменений логично, что информация - это более общее понятие, а потом уже эта информация может делиться на подкатегории - конфиденциальная, коммерческая тайна, персональные данные, объекты авторского права, просто сообщения о фактах и так далее.
SerjV
09.04.2023 14:15На мой взгляд и без всех этих изменений логично, что информация - это более общее понятие, а потом уже эта информация может делиться на подкатегории - конфиденциальная, коммерческая тайна, персональные данные, объекты авторского права, просто сообщения о фактах и так далее.
Совершенно не логично.
Если распространить авторское право на информацию, то вне закона оказываются, например, такое действие, как резервное копирование.
То есть не можете просто так, например, на собственном же диске случайным образом сектора ноликами заполнить - т.к. если там записан объект авторского права, принадлежащий не вам, вы незаконно его модифицируете. Или незаконно сделали резервную копию, которых должно быть минимум три, а закон вам даёт право только одну копию с объекта авторского права сделать.
mshewzov Автор
09.04.2023 14:15А может оно не вне закона?
Ведь тот же хостер не делает резервное копирование по своему желанию. Он производит его на основании договора об оказании услуг с владельцем сайта. В п. 73 Постановления Пленума Верховного Суда РФ от 23.04.2019 N 10 "О применении части четвертой Гражданского кодекса Российской Федерации" разъяснено следующее:
73. Использование результатов интеллектуальной деятельности и средств индивидуализации по поручению или заданию правообладателя (например, выпуск типографией экземпляров произведений по заданию издательства, производство товаров с нанесением товарного знака по договору с правообладателем) охватывается исключительным правом правообладателя и не требует заключения лицензионного договора.Получается, что если хостер или тот же Яндекс.Диск производит резервное копирование файлов, охраняемых авторским правом, которые загрузил их автор, то это не является, во-первых, нарушением, т.к. производится на основании поручения правообладателя и фактически считается его действием, просто совершённым чужими руками, а во-вторых, лицензионный договор для этого не требуется по той же причине - права на файлы не предоставляются Яндексу, даётся лишь поручение (задание) что-то с ними сделать.
Я думаю, кстати, что это и есть причина, по которой Яндекс не запрашивает получение прав на контент в своих условиях использования Яндекс.Диска. И тем страннее выглядят условия использования Облака@Mail.ru.
SerjV
09.04.2023 14:15А может оно не вне закона?
Ведь тот же хостер не делает резервное копирование по своему желанию. Он производит его на основании договора об оказании услуг с владельцем сайта.
Проблема в том, что владелец сайта будет совпадать с правообладателем всего, что составляет сайт, только в случае, если он сайт написал с нуля сам.
Что еще работало во времена Web1.0, но сейчас там будет куча кода - от джаваскриптов до CMS. И вот правообладетелем этого добра будет не владелец сайта, и он хостеру лицензию на использование своей интеллектуальной собственности не давал. И права владельцу сайта сублицензировать хостеру свой объект собственности - тоже не давал.
Вот прямо как в вашем случае с Гитхабом.
Пока же хостер работает с информацией, обладателем которой (ст.6 149-ФЗ) является владелец сайта - всё законно. Обладатель информации может ею распоряжаться.
Но как только хостер начинает делать производные и/или составные произведения интеллектуальной собственности - он тут же попадает в область действия авторского, а не информационного права.
Так было до тех пор, пока стараниями "лоббистов" не засунули авторское право в информационное.
Aldrog
09.04.2023 14:15+1но сейчас там будет куча кода — от джаваскриптов до CMS. И вот правообладетелем этого добра будет не владелец сайта, и он хостеру лицензию на использование своей интеллектуальной собственности не давал. И права владельцу сайта сублицензировать хостеру свой объект собственности — тоже не давал.
Как минимум в случае СПО — вполне себе давал и то, и другое, в явном виде, в лицензии.
SerjV
09.04.2023 14:15Как минимум в случае СПО — вполне себе давал и то, и другое, в явном виде, в лицензии.
Ну не СПО единым это живёт, это может быть и проприетарная CMS, и вообще заказная разработка, лицензированная владельцу сайта без права сублицензирования (по умолчанию как раз лицензия даётся без этого права).
А так да, использование СПО в этом плане безопаснее :)
mshewzov Автор
09.04.2023 14:15Проблема в том, что владелец сайта будет совпадать с правообладателем всего, что составляет сайт, только в случае, если он сайт написал с нуля сам.
Что еще работало во времена Web1.0, но сейчас там будет куча кода - от джаваскриптов до CMS. И вот правообладетелем этого добра будет не владелец сайта, и он хостеру лицензию на использование своей интеллектуальной собственности не давал. И права владельцу сайта сублицензировать хостеру свой объект собственности - тоже не давал.
Мне кажется это не проблема. Всякие открытые лицензии, типа GPL, MIT, Apache и так далее - они дают практически неограниченный перечень правомочий по использованию кода. В том числе и воспроизведение, которым и является загрузка кода на хостинг, и даже сублицензирование (например, в MIT и Apache точно разрешено, в GPL есть раздел 10, там что-то похожее, но описано с точки зрения права США, видимо), что может потребоваться для интеграции в свой проект и дальнейшей его перепродажи путём комбинированного отчуждения исключительных прав на свой код и сублицензирования чужого кода.
Но как только хостер начинает делать производные и/или составные произведения интеллектуальной собственности - он тут же попадает в область действия авторского, а не информационного права.
Ну так-то да. Но хостер обычно этого не делает. Поэтому просто выполняет действия с объектом ИС по поручению правообладателя и ему в понимании разъяснения ВС РФ для этого лицензия не нужна.
SerjV
09.04.2023 14:15+2Мне кажется это не проблема. Всякие открытые лицензии, типа GPL, MIT, Apache и так далее - они дают практически неограниченный перечень правомочий по использованию кода.
Открытые лицензии - это не всё, что может затесаться в общем случае в состав сайта. Там может быть любая проприетарщина.
С GPL отдельный интересный разговор, она необычна даже для опенсорсных лицензий ;) И начнётся разговор с главного - действительна ли GPL в РФ :)
Ну так-то да. Но хостер обычно этого не делает. Поэтому просто выполняет действия с объектом ИС по поручению правообладателя и ему в понимании разъяснения ВС РФ для этого лицензия не нужна.
Еще раз - владелец сайта - не правообладатель всего, что входит в состав сайта, а потому может распоряжаться своим правом на сайт только так, чтобы при этом не нарушались права правообладателей компонентов этого сайта.
А потому "в общем случае" он не имеет права сублицензирования.
(И даже в некоторых СПО-лицензиях у него такого права формально нет, если на то пошло, там право предоставляется по весьма хитрой конструкции. Но это отдельная тема)
mshewzov Автор
09.04.2023 14:15Открытые лицензии - это не всё, что может затесаться в общем случае в состав сайта. Там может быть любая проприетарщина.
Да, конечно, я ж не спорю с этим.
С GPL отдельный интересный разговор, она необычна даже для опенсорсных лицензий ;) И начнётся разговор с главного - действительна ли GPL в РФ :)
Я думаю да, а почему нет? У нас в законе минимум условий прописан, который должен быть в лицензионном соглашении. Всё остальное отдаётся на откуп автору ПО - что хочешь, то и пишешь.
Еще раз - владелец сайта - не правообладатель всего, что входит в состав сайта, а потому может распоряжаться своим правом на сайт только так, чтобы при этом не нарушались права правообладателей компонентов этого сайта.
А потому "в общем случае" он не имеет права сублицензирования.
А, я не понял вашу мысль сразу. Вы имеете в виду то, что если выполнение действий над ИС по поручению (заданию) правообладателя не требует лицензионного договора, то получается, что всё равно нужно, чтобы исходной точкой для того же Яндекс.Диска ихи хостинга был правообладатель, а не тот, кому он что-то лицензировал без права сублицензирования.
Да, вроде выглядит именно так. Но что если по аналогии с разъяснением, касающимся исключительного права, использование ПО по лицензии при техническом содействии какого-то третьего лица - это всё ещё использование ПО в пределах лицензии? Например, у меня есть лицензия на запуск ПО на компьютере и использование его по назначению. И там не конкретизировано, как в лицензиях MS, что это за компьютер может быть. Получается, что я могу запустить его в принципе и на виртуальном компьютере, запущенном на Яндекс.Облаке. Последнее при этом будет мне оказывать просто техническое содействие по моему поручению в реализации моих прав как лицензиата.
С хостингом или Яндекс.Диском та же идея. У меня есть лицензия на какой-то проприетарный код, там нет права сублицензирования, но при этом этот код предполагает назначение, что он будет использоваться в составе веб-сайта. Получается, чтобы реализовать это право, предоставленное мне лицензией, я могу как поднять свой хостинг, так и привлечь третье лицо - хостера - и реализация этого права через хостера, который будет по моему заданию хостить этот код, - не требует правомочия на сублицензирование, т.к. я в целом использую код по назначению, а хостер по условиям договора с ним не претендует на этот код, выполняя моё поручение просто.
Aldrog
09.04.2023 14:15+1Из интереса открыл правила пользования Dropbox, и, на мой непросвещённый взгляд, формулировки там весьма похожи на гитхабовские, за исключением того, что написаны более простым языком и менее конкретно:
When you use our Services, you provide us with things like your files, content, messages, contacts, and so on (“Your Stuff”). Your Stuff is yours. These Terms don’t give us any rights to Your Stuff except for the limited rights that enable us to offer the Services.
Dropbox accesses, stores, and scans Your Stuff. You give us permission to do those things, and this permission extends to our affiliates and trusted third parties we work with.developer7
09.04.2023 14:15+2Да там на GitHab всё сводится к тому что им нужны права что бы просто показывать код на своём сервисе. Что как бы логично. Как можно закачать код на сайт, а он не имел прав его показывать.
И получаем — если разработчик закачал код и расшарил его всем. То он конечно "нехороший человек" и должен страдать. Но если код закачан и показывается только разработчику — то тогда GitHab используется в качестве инструмента работы с кодом.
При придаче эксклюзивных прав, если не оговорено другого, у разработчика остаются права на просмотр кода. Т.е. он может его хранить у себя и использовать в режиме "Only view". Вроде где то тут в комментах про это писали. Так вот GitHab в закрытом репозитории как раз и обеспечивает этот режим "Only view"
SerjV
09.04.2023 14:15+1Но если код закачан и показывается только разработчику — то тогда GitHab используется в качестве инструмента работы с кодом.
Проблемы бы не было, если бы гитхаб работал как информационный сервис (а в договоре отсутствовали NDA и санкции за нарушение коммерческой тайны). Но - он решил работать с объектами авторского права... А разработчик решил использовать Гитхаб...
При придаче эксклюзивных прав, если не оговорено другого, у разработчика остаются права на просмотр кода. Т.е. он может его хранить у себя и использовать в режиме "Only view". Вроде где то тут в комментах про это писали. Так вот GitHab в закрытом репозитории как раз и обеспечивает этот режим "Only view"
В вашем рассуждении опущен один фактор.
Разработчику не предоставлено право сублицензирования кода.
Используя гитхаб - разработчик сублицензировал гитхабу код, на что права не имел (т.е. лицензионный "договор присоединения" гитхаба для разработчика оказался сублицензионным).
И вот за это сублицензирование и поплатился. В полном соответствии не только с буквой, но и духом закона.
Ну а что разработчк не читал договор с гитхабом и воспринимал гитхаб чисто как место хранения информации - лишний раз наводит на мысль, что нельзя заключать договоры не понимая, о чём они...
developer7
09.04.2023 14:15+3работал как информационный сервис
Ну так он и работает как информационный сервис. Сервис работающий с кодом который пишут люди. Получается что вся информация будет авторской. Вот GitHab и просит разрешение у автора показывать эту информацию самому же автору.
Автор — разработчик. Эта неотчуждаемое право. Вот разработчик дал разрешение GitHab показать самому себе его же код.Разработчику не предоставлено право сублицензирования кода.
Разрешено ли разработчику смотреть на свой код? Он автор. Автору разрешено. Поэтому разрешения типа разрешить самому себе смотреть свой код, такие разрешения автор давать может.
SerjV
09.04.2023 14:15+1Ну так он и работает как информационный сервис.
Сервис, работающий с информацией, не заключает с вами лицензионное соглашение относительно того, что вы в этот сервис загружаете. А только в отношении того, что вам этот сервис сам предоставляет.
Вот GitHab и просит разрешение у автора показывать эту информацию самому же автору.
Не информацию, в том-то и дело. Они могли бы работать с этим просто как с информацией, но гитхабы написали: "Вы являетесь владельцем создаваемого вами контента, но предоставляете нам определенные права на него".
Разработчик не являлся "владельцем контента" и не имел права предоставлять кому-то какие-то права на него.
Да, если бы разработчики смогли доказать, что загрузили код до того, как лишились исключительного права... Но не смогли.
А по-хорошему договоры составляют так, что исключительное право принадлежит заказчику сразу, тогда вообще не возникает отрезка времени, когда оно находится у разработчика (для чего законом разработчику и выдана своеобразная "принудительная лицензия").
developer7
09.04.2023 14:15Сервис, работающий с информацией, не заключает с вами лицензионное соглашение относительно того, что вы в этот сервис загружаете. А только в отношении того, что вам этот сервис сам предоставляет.
Сервис простого показа кода автору не может его ему показывать без его разрешения. Т.е. таких сервисов в правовом поле не может существовать.
Значит могут существовать только сервисы которые будут всегда просить это право.
Поэтому получается что суд запрещает вообще существованию сервисов которые бы показывали автору его творение. Т.е. по сути суд запрещает автору видеть своё творение. Вообще везде. Потому как код можно посмотреть только через локальную программу или распечатать на принтере. А для этого везде нужно получить от автора соглашение на показ.
Вы являетесь владельцем создаваемого вами контента, но предоставляете нам определенные права на него". Разработчик не являлся "владельцем контента" и не имел права предоставлять кому-то какие-то права на него.
Может ли разработчик предоставить право просматривать самому себе его творение?
SerjV
09.04.2023 14:15+1Может ли разработчик предоставить право просматривать самому себе его творение?
Сам себе показывать может. Но не может предоставить другому лицу право показывать это не важно кому, в т.ч. себе же, это уже будет сублицензированием. Это право может предоставить только правообладатель.
Говорю же, запрос гитхаба - достаточно нетипичен для "инструмента". Тот же текстовый редактор - инструмент - выкатывает пользователю лицензионный договор на использование себя (редактора), но не просит предоставить владельцу редактора лицензию на то, что будет в редакторе набираться якобы для того, чтобы это потом показывать тому, кто пользуется редактором.
Лучше ищите подвох на стороне Гитхаба... И сдаётся мне, что это подвох имеет отношение к Копилоту по крайней мере :)
developer7
09.04.2023 14:15Сам себе показывать может.
Ну так получается что не может. Т.к. нету ни какой возможности воспользоваться любым ПО для просмотра, но не предоставляя ему разрешение на показ.
Мы не рассматриваем ПО которое не просит такое разрешение. Потому что такое ПО само нарушает закон. А разработчик как законопослушный гражданин не использует ПО нарушающее закон.
Тот же текстовый редактор — инструмент — выкатывает пользователю лицензионный договор на использование себя...
Ну так такой редактор нарушает закон. А вот GitHab не нарушает. Просит разрешение. И у разработчика получается единственная возможность не нарушить закон воспользоваться GitHab.
И такое разрешение не нарушает эксклюзивные права. Потому что эксклюзивные права не запрещают автору смотреть на свой творение. И получается автор может это прав предать другому. Т.е. право показывать только самому себе и никому больше.
P.S. Я понимаю что мои утверждения выглядят абсурдными. Но они абсурдны ровно настолько, насколько абсурдно решение суда. Да и вообще — просто решил поупражняться в словоблудии, отдохнуть от ненавистного написания ПО.
SerjV
09.04.2023 14:15Т.к. нету ни какой возможности воспользоваться любым ПО для просмотра, но не предоставляя ему разрешение на показ.
Вы не можете предоставить ПО право на показ (оно же лицензия), т.к. ПО не является лицом в гражданском законодательстве.
Просто говоря "гитхаб что-то там" надо понимать, что договор заключается не с софтом сервиса, а с владельцем этого сервиса. И право предоставляет не программе-просмотрщику кода, а владельцу этого сервиса.
И это предоставляемое право - не access rights к файлу для программы в составе сервиса. Это право использования объекта авторского права.
Для того, чтобы показать пользователю содержание файла - владельцу сервиса не нужна от пользователя лицензия на код, загруженный пользователем в сервис.
Ну так такой редактор нарушает закон.
Редактор - это программа, она в принципе не может нарушить закон. Закон может нарушить лицо - физическое или юридическое.
developer7
09.04.2023 14:15Ну вроде как это ничего не меняет. Не с программой конечно договор. А будет в договоре что то типо инкорпорейтед такая то. И ставя галочку пользователь заключает договор с инкорпорейтед.
Просто не поставив галочку, программа не заработает. И получается что бы иметь доступ к просмотру своего кода, либо ты ставишь галочку, либо просто не имеешь возможности просмотра.
А программа, тоже не имеет возможности не спросить у тебя возможность отображать тебе же твой код, иначе она нарушит закон.
SerjV
09.04.2023 14:15А программа, тоже не имеет возможности не спросить у тебя возможность отображать тебе же твой код, иначе она нарушит закон.
Программа не может нарушить закон. В принципе не может.
Просто не поставив галочку, программа не заработает. И получается что бы иметь доступ к просмотру своего кода, либо ты ставишь галочку, либо просто не имеешь возможности просмотра.
Не просто поставить галочку. А заключить договор с собственником программы, разрешающем тебе использовать эту программу. И всё.
Если собственник программы не претендует на то, чтобы что-то в своих интересах делать с тем, что вы в программе просматриваете - ему не нужно получать никаких разрешений от вас.
И ставя галочку пользователь заключает договор с инкорпорейтед.
Вот только без этого договора - пользователь не имеет права использовать программу, т.к. программа - объект авторского права.
Внимание, вопрос: а зачем вообще собственнику прав на программу для чего-то использовать то, что пользователь смотрит в этой программе?.. А оно ему нафиг не нужно.
А вот владельцу гитхаба нужно. Хотя бы затем, чтобы кормить кодом Копилот, чего без разрешения от правообладателя кода он делать не имеет права. Или еще что-то делать интересное с этим кодом. И вовсе не за тем, чтобы этот код обратно пользователю показывать!
developer7
09.04.2023 14:15Не просто поставить галочку. А заключить договор с собственником программы, разрешающем тебе использовать эту программу.
Ну как бы на GitHabe ставишь галочки, да и вообще повсеместно. Некоторые и их не предоставляют. Просто в договоре написано раз используешь сервис значит согласился с договором.
… в программе просматриваете — ему не нужно получать никаких разрешений от вас.
Мы говорим о классе сервисов которые отображают код. И на отображение этого кода — должно быть разрешение со стороны того кто туда собственно код загрузил. Просто это как бы само собой разумеется, раз загрузил, значит дал разрешение, просто в GitHab запросили это явно.
собственнику прав на программу для чего-то использовать то, что пользователь смотрит в этой программе
Как зачем? Найдётся такой юрист как в посте, и накатает иск. Я дал вам право загрузить в ОЗУ мой код. Но я не давал права выводить его на монитор! Плати 100500 миллионов.
Копилот, чего без разрешения от правообладателя кода он делать не имеет права. Или еще что-то делать интересное с этим кодом.
Ну это другая история. В явном же виде GitHab просит разрешение на обработку кода для возможности показать его вам. И всё.
SerjV
09.04.2023 14:15+1Ну как бы на GitHabe ставишь галочки, да и вообще повсеместно. Некоторые и их не предоставляют. Просто в договоре написано раз используешь сервис значит согласился с договором.
Это называется "договор присоединения". Так что люди не просто галочки ставите, люди договоры заключают...
Мы говорим о классе сервисов которые отображают код. И на отображение этого кода — должно быть разрешение со стороны того кто туда собственно код загрузил. Просто это как бы само собой разумеется, раз загрузил, значит дал разрешение, просто в GitHab запросили это явно.
Разрешение КОМУ? Зачем разрешение ВЛАДЕЛЬЦУ СЕРВИСА, если код показывает программа, которую он предоставляет пользователю? Разрешение на использование программы должен получить пользователь сервиса, а что программа делает - значения не имеет, важно, что он её использует. Пусть даже это и веб-приложение.
Как зачем? Найдётся такой юрист как в посте, и накатает иск. Я дал вам право загрузить в ОЗУ мой код. Но я не давал права выводить его на монитор! Плати 100500 миллионов.
А я, как лицо-владелец гитхаба, его вам на монитор и не выводил. Его выводил программный год, которым вы пользовались с моего разрешения. Не нравится - не пользуйтесь программным кодом моего сервиса, я же вас не заставляю.
Ну это другая история. В явном же виде GitHab просит разрешение на обработку кода для возможности показать его вам. И всё.
Не другая, а та самая. И владельцу гитхаба нафиг не нужно разрешение на использование кода пользователя для того, чтобы показывать этот когд пользователю.
Наоборот, пользователь сервиса должен от владельца гитхаба получить разрешение на использование кода гитхаба для просмотра кода, принадлежащего пользователю. Потому что владелец гитхаба в этом показе не участвует.
Владельцу гитхаба нужно разрешение на использование кода пользователя только в одном случае - если этот код для чего-то использует владелец гитхаба.
developer7
09.04.2023 14:15а что программа делает — значения не имеет, важно, что он её использует.
Как я вижу есть 2 вида отношений. Разработчик программы разрешает мне пользоваться своей программой.
А я ожидаю от программы что бы она не нарушала мои права. Я даю право на обработку кода или не даю.
Т.е. разработчик мне, я разработчику. А не что то одно.
А то по вашей логике за программу с вирусом закачанную на свой комп, создатель ни за что не отвечает.
А я, как лицо-владелец гитхаба, его вам на монитор и не выводил. Его выводил программный год, которым вы пользовались с моего разрешения.
За программный код полностью несёт владелец создавший этот код. Это же очевидно. А то зайдёшь так на сайт покупок, ведёшь карту. А у тебя все деньги спишутся. И разработчика такой это не я. Это программа виновата. В тюрьму её.
И владельцу гитхаба нафиг не нужно разрешение на использование кода пользователя для того, чтобы показывать этот код пользователю.
Ну как же не нужно? Код ему принадлежит? Нет. А он с ним что то должен делать что бы вывести вам на экран.
Именно за это же натянули исполнителя в этой статье. Типо оперировал кодом который ему не принадлежит.И сам факт закачки кода на GitHab не говорит о том что с ним вообще что то можно делать. Вот GitHab в явном виде это и спрашивает. Можно отобразить, Ну и выполнить другие действия которые связанны ТОЛЬКО с отображением. Ты явно говоришь ДА. Всё все вопросы разрешены заранее.
SerjV
09.04.2023 14:15Как я вижу есть 2 вида отношений. Разработчик программы разрешает мне пользоваться своей программой.
Верно.
А я ожидаю от программы что бы она не нарушала мои права. Я даю право на обработку кода или не даю.
Не верно. Вы не можете дать прав на обработку программе, а разработчик программы не участвует в обработке программой вашего кода. Код программы используете вы, а не разработчик программы. Право нужно тому, кто а) осуществляет обработку, б) использование программы, то есть вам в обоих случаях.
Так обстоит дело с обычными инструментами, к которым все привыкли.
С некоторыми, типа гитхаба, это не так, и там "разработчик программы" зачем-то запрашивает право для себя. Наверное, они там сами что-то делают с вашим кодом, а не только вы его обрабатываете после загрузки в их "программу".
Недаром они там указывают в договоре, что гитхаб исходит из того, что "вы" (англо-американский оборот для договоров) обладаете необходимыми правами на то, что "вы" туда загружаете и несёте ответственность за нарушение авторских прав, если вдруг их нарушаете.
А то по вашей логике за программу с вирусом закачанную на свой комп, создатель ни за что не отвечает.
Отвечает, по ст.273 УК, может быть по ст.272 УК (смотря какую информацию задело) и (одновременно) по ГК в соответствии с нанесённым ущербом. Но не в связи с нарушением ваших авторских прав.
А вот вы, ковыряясь в вирусе, одновременно
- нарушаете авторские права автора вируса (вряд ли он подаст на вас в суд, но тем не менее)
- совершаете преступление, предусмотренное ст.273 УК РФ.Вот где настоящий маразм законодательства. А не в том, что многие пользователи не читают договоров, которые заключают.
За программный код полностью несёт владелец создавший этот код. Это же очевидно.
Не несёт практически никакой, так что поосторожнее с оборотами про "очевидно" - обычно за этим скрывают то, что доказать очень трудно или даже вообще невозможно.
Мало того, что из-за особенностей американского рынка нынче везде принято писать "программа предоставляется КАК ЕСТЬ без гарантий чего бы то ни было", так оно еще и без этой приписки так и есть. Т.к. вам предоставляется не программа, а право использовать эту программу. Ну по меркам материального мира это как если бы за деньги разрешили покататься, но деньги заплатили не за аренду машины, а на право на ней покататься, и заодно переложили на катающегося всю ответственность за использование машины, потому что для покатушек ему щелчком пальцев сделали копию машины. Очень удобно, чё.
А то зайдёшь так на сайт покупок, ведёшь карту. А у тебя все деньги спишутся.
А в данном случае вы имеете дело не с использованием программы, а оказанием услуги. Которая регулируется не авторским правом, а другими разделами права. Ну а уж насколько хорошо или плохо регулируется - другой разговор.
Ну как же не нужно? Код ему принадлежит? Нет. А он с ним что то должен делать что бы вывести вам на экран.
А он и не выводит. Пользователь выводит его себе сам, используя программу (тоже сам).
Именно за это же натянули исполнителя в этой статье. Типо оперировал кодом который ему не принадлежит.
Не оперировал, а сублицензировал владельцу гитхабу право опрерировать кодом, чего не имел права делать.
Кстати, если бы по договору после акта разработчик утрачивал право использования кода - то да, было бы достаточно и того, что на гитхабе было свидетельство того, что он им оперировал после утраты права использования кода.
developer7
09.04.2023 14:15Не несёт практически никакой,
Правильно ли я понимаю, если я сделаю автономный website, даже в шапке напишу мол код написан и запущен на сервере, и больше к нему никто не притрагивается.
Сайт даёт возможность закачать любую музыку кому угодно, и слушать кому угодно. При этом сайт никаких прав не запрашивает.
А все претензии правообладателей слать
лесомк тем кто собственно закачивал и скачивал. Это они виноваты. Мы даже може IP вам предоставить.
SerjV
09.04.2023 14:15А все претензии правообладателей слать
лесомк тем кто собственно закачивал и скачивал. Это они виноваты. Мы даже може IP вам предоставить.Примерно так, но надо выполнить ряд условий, включая круглосуточную реакцию на обращения (ну по крайней мере без праздником и выходных, чтобы в сроки уложиться), хранение логов три года, хранение трафика и прочих данных столько же, доступ товарищу майору к некоторым данным вашей системы...
И да, после этого вы своими силами и за свой счёт будете блокировать/удалять у себя контент по запросам, а с требованиями с вас компенсаций за нарушения чужих прав - слать лесом к тем, кто это закачал.
mshewzov Автор
09.04.2023 14:15Как зачем? Найдётся такой юрист как в посте, и накатает иск. Я дал вам право загрузить в ОЗУ мой код. Но я не давал права выводить его на монитор! Плати 100500 миллионов.
По закону "не считается воспроизведением краткосрочная запись произведения, которая носит временный или случайный характер и составляет неотъемлемую и существенную часть технологического процесса, имеющего единственной целью правомерное использование произведения либо осуществляемую информационным посредником между третьими лицами передачу произведения в информационно-телекоммуникационной сети, при условии, что такая запись не имеет самостоятельного экономического значения" (пп. 1 п. 2 ст. 1270 ГК РФ).
Это что касается загрузки кода в ОЗУ. Если разрешение воспроизводить код есть, то отдельное разрешение на загрузку его в ОЗУ. Также редко кто использует в лицензионных договорах узкие понятия из закона, типа "воспроизведение", "демонстрация" и так далее. В лицензионном договоре часто пишут, что ПО лицензируется для использования по его назначению (к примеру, если это AutoCAD, то очевидно для проектирования и так далее), что в принципе подразумевает как загрузку ПО в ОЗУ, так и отображение на экране, т.к. это неотъемлемый технологический процесс, направленный на достижение единой цели - правомерное использование ПО.
developer7
09.04.2023 14:15не считается воспроизведением краткосрочная запись произведения, которая носит временный или случайный характер и составляет неотъемлемую и существенную часть технологического процесса, имеющего единственной целью правомерное использование произведения либо осуществляемую информационным посредником между третьими лицами передачу произведения в информационно-телекоммуникационной сети, при условии, что такая запись не имеет самостоятельного экономического значения
Кратковременная запись на GitHab в качестве демонстрации в суде а также не имеющая для исполнителя экономического значения (он с этой записи никакого профита не имел) ->По закону "не считается… ?
Вроде как суд решил что очень даже считается.
Опять же у меня сервер годы не выключается, там в ОЗУ данные годами могут лежать, я понимаю что это бул шит, но раз уже доводить формальности до абсурда так доводить.
что в принципе подразумевает как загрузку ПО в ОЗУ, так и отображение на экране,
Оооо, суд наверно любит формулировки по типу в принципе подразумевается, вон исполнитель тоже загружая на GitHab код в принципе подразумевал что это просто инструмент, но когда начали докапываться до каждого слова, уже как то всё не в принципе подразумевается.
Я это к тому, что если явно не написано в контракте, или лицензии — то в случае споров, к этому можно придраться, ка и показал обсуждаемый суд.
mshewzov Автор
09.04.2023 14:15Ну у нас она не такая уж и кратковременная. Адреса репозиториев в трёх экспертизах одни и те же. Между первой экспертизой и третьей - 1,5-2 года. И всё это время код был на GitHub. Это явно не кратковременная запись.
developer7
09.04.2023 14:15+11,5-2 года
Ого. Я смотрю там всё намного запущеннее.
Можно конечно подискутировать что же является кратковременным, например время жизни солнца по сравнению временем жизни вселенной — кратковременно )))
Но я вижу другой изъян. Вы можете утверждать фактами что во время экспертизы код был на GitHab, но вы не докажите — а был ли он там между?
И того время сокращается до 2 дней. 1 день первая экспертиза. 2 день вторая. Или сколько там они его смотрели?
mshewzov Автор
09.04.2023 14:15Ха, ну это, конечно, да, но это была уже не моя задача, а разработчика. А он прошляпил этот момент. Более того, его юрист прямо в заседании на вопрос судьи "А где этот код сейчас?" ответил: "Он всё это время был на GitHub и он до сих пор там". У меня даже аудиозапись есть :)
developer7
09.04.2023 14:15А где этот код сейчас?" ответил: "Он всё это время был на GitHub и он до сих пор там
Ну как можно искать лазейки для такого "сказочного" ответчика ))))
А всего то надо было говорить, надо уточнить, сейчас данных нету.
mshewzov Автор
09.04.2023 14:15Судебный процесс же у нас состязательный. Что мне теперь жалеть что ли тех, кто в этой самой состязательности не преуспел? :)
SerjV
09.04.2023 14:15+1Поэтому получается что суд запрещает вообще существованию сервисов которые бы показывали автору его творение.
Неееет. Ладно, скажем проще.
Фразу из договора с гитхабом "Вы являетесь владельцем создаваемого вами контента, но предоставляете нам определенные права на него " надо понимать как "гитхаб разрешает использовать свои сервисы только правообладателям контента".
Выбирайте для работы инструменты, не требующие от вас предоставления прав на то, с чем вы в инструменте работаете, владельцу инструмента.
Aldrog
09.04.2023 14:15Однако, автор статьи умудрился доказать в суде, что это не так, и загрузка кода в приватный репозиторий является лицензированием его гитхабу, и что это нарушает эксклюзивное право заказчика.
SerjV
09.04.2023 14:15+1и загрузка кода в приватный репозиторий является лицензированием его гитхабу
Так и является таковым в соответствии с договором, заключаемым с гитхабом.
Если бы код еще и опубликован для всеобщего доступа был - то нарушение исключительного права заказчика заключалось бы не только в незаконном сублицензировании, но и в незаконной публикации.
rsashka
09.04.2023 14:15Автор статьи умудрился доказать, что владеет правами на программное обеспечение которое ему в полном объеме никогда не передавалось.
developer7
09.04.2023 14:15+3Иронично. Автор построил обвинение на соглашение GitHab как лицензирование, но в эту игру можно играть вдвоём. Все те соглашение которые были применены к коду до его передачу заказчику — нивелирует исключительную лицензию.
mshewzov Автор
09.04.2023 14:15Ну погодите, тут много раз уже было сказано про то, что, мол, если код не передан, то как же могли быть переданы на него права. Давайте приведём пример с крупной корпорацией Microsoft. У них есть (или была) такая разновидность лицензионного договора как корпоративная подписка. Называлась Microsoft Subscribe или что-то подобное. Я когда-то такое себе присматривал для покупки. Так что меня удивило - за подписку платишь 100500 денег, а дистрибутивы на дисках не получаешь, только на скачивание. Дистрибутивы на дисках, получается, только за деньги отдельные покупать. Вот и вопрос - я заключил такое соглашение, оплатил, но мне никто ничего не передал ни на дисках, никак. Да, есть ссылки, мол сам качай. Ну а если я не скачаю? Получается в отношении чего у меня лицензия, если у меня ничего нет? А вот и есть - в отношении определённого программного обеспечения, поименованного в этой лицензии. Так вот и в нашем случае (только у нас не лицензия, но разница только в объёме прав). Исключительные права на те самые 75% кода переданы заказчику в полном объёме, а сам код - нет.
Об этом говорит и ст. 1227 ГК РФ:
1.Интеллектуальные права не зависят от права собственности и иных вещных прав на материальный носитель (вещь), в котором выражены соответствующие результат интеллектуальной деятельности или средство индивидуализации.2.Переход права собственности на вещь не влечет переход или предоставление интеллектуальных прав на результат интеллектуальной деятельности или на средство индивидуализации, выраженные в этой вещи, за исключением случая, предусмотренного абзацем вторым пункта 1 статьи 1291 настоящего Кодекса.В обратную это тоже работает - переход исключительного права на код не влечёт автоматический переход права собственности на носитель, на который этот код записан. Да и переход информации во владение от одного владельца к другому это тоже не влечёт автоматически.
developer7
09.04.2023 14:15Да, есть ссылки, мол сам качай. Ну а если я не скачаю? Получается в отношении чего у меня лицензия, если у меня ничего нет?
1 этап.
Ну когда вы только приобрели ключ. То у вас ничего нет — кроме этого самого ключа. С юридической точки зрения вам продали 30 цифр за N денег и всё. И обещание что если вы вставите этот код в программу то программа заработает.2.этап
Далее вы скачиваете программу. Запускаете её — и тут вам предоставляется уже лицензия и договор, где внизу вы вставляете ключ. Нажав OK, именно с этого момента вам передали права на пользование программой.Т.е. сначала у вас был право как бы пользоваться маленькой такой программой в 30 цифр. А потом вы получили право пользоваться большой программой уже на большее число цифр.
Обратите внимание и в 1 и во 2 случае права были на конкретный код, а не на код в вакууме.
mshewzov Автор
09.04.2023 14:15+1Не согласен.
Во-первых, когда приобретается ключ в рамках такой подписки, то там не договор на продажу 30 цифр за N денег, а полноценное лицензионное соглашение с перечнем ПО и правомочий по его использованию, а также ограничений и прочих условий.
Во-вторых, при скачивании того же дистрибутива Windows или Office, и при запуске его установки текст лицензии... не отображается. Там в окне по команде winver можно прочитать только, что это специальная сборка, условия использования которой регулируются отдельным соглашением, которое у вас должно быть заключено с поставщиком. Там буквально две строчки.
Ну и в третьих, в том же лицензионном соглашении с Microsoft предоставляются права, как вы выразились на "конкретный код", который идентифицируется только лишь... по названию программного продукта. И всё. Это мы все знаем, что такой продукт есть у Microsoft, потому что он есть и всё тут. Но вот у меня когда-то была подписка TechNet, я имел доступ к Windows XP, а потом бац, условия подписки вроде не менялись, мне уведомлений не приходило, а вот скачать дистрибутив я уже не могу. Его просто нет в личном кабинете в центре загрузки.
В общем, конкретный код или код в вакууме из договора совершенно нельзя понять. Только по факту, при передаче кода, или по другим данным. А пока не доказано обратное лицензионный договор даже на код в вакууме нельзя будет признать недействительным только потому, что кому-то кажется, что кода нет.
developer7
09.04.2023 14:15А что это меняет? Ну не код вы купили. А программу сервере лицензий. Т.е. и право и программа у вас есть.
А далее при запуске и инициализации каждой копии Office или Windows вы получаете право на эту копию. Опять же право и программа.
А то что там как вы пишите пару строчек лицензии так это тоже лицензия. Тем более я уверен что там если по ссылкам перейти вывалится такая портянка с соглашением. По типу что они будут за вами следить и использовать телеметрию всего и всея.
а вот скачать дистрибутив я уже не могу.
Про это я и говорю. Вам продали ключ и обещание скачки программы. Программу вы не скачали — они нарушили соглашение которое шло к ключу, а не программы.
У программы будут свои собственные соглашения.
Даже возможны варианты. Вы купили ключ, устанавливаете программу. А в программе будут галочки согласны ли вы с соглашением программы. Если вы не согласны — программа просто не установится.
И получается ситуация — ключом вы владеете, а программой нет. И всё законно.
mshewzov Автор
09.04.2023 14:15Ну нет же. Право на использование копии Windows или Office я получаю не в момент её запуска, а в момент подписания соглашения, т.е. задолго до запуска.
Пару строчек в окне лицензии - это не лицензия, это отсылка на бумажное соглашение с поставщиком. Вот нашёл в сети, примерно такое оно у корпоративных лицензий:
developer7
09.04.2023 14:15В момент установки разве нету там галочек что вы соглашаетесь с условиями лицензионного соглашения?
Обычно эту билеберду в крякнутых версих вырезают, либо есть тихая установка, там в файле сразу все соглашения на да стоят, и всё устанавливается без пауз.
Вы получаете право использовать — это одно право. Оно как раз покупается с ключами.
А когда вы устанавливает программу там идут другие права, по типу следить за вами, или если вам ПО принесло вред, то мы ни причём. Это как бы не право, а соглашение. Но оно идёт отдельно к программе.
mshewzov Автор
09.04.2023 14:15Нет, никаких галочек нет. Это особенность корпоративных версий. В версиях Windows 7 и Windows 8 были галочки, но там в окне над ними было написано ровно то, что и в этом же окне выше - лицензия в отдельном корпоративном соглашении, все вопросы туда. По сути такая галочка была просто элементом интерфейса, считайте подтверждали, что, мол, да, есть такое соглашение у нас на бумаге.
И как раз в корпоративных версиях право использовать Windows или Office не покупается с ключами. Там оно покупается в момент оплаты корпоративного лицензионного соглашения, а ключи выдаются по факту запроса в центре загрузок (по-моему так). Они просто подтверждают легальность использования, своего рода средство защиты.
developer7
09.04.2023 14:15Там вроде ключи выдаются сервером лицензий. Но все Windows должны иметь ключ, хоть корпорат хоть другое. По крайней мере так у мелкомягких устроено.
mshewzov Автор
09.04.2023 14:15Возможно, я уже давно не пользовался этим. У меня только TechNet подписка была. Там ключи в центре загрузок выдавались. Но принцип тот же. Они не выдаются в момент оплаты по лицензионному соглашению, а по запросу.
SerjV
09.04.2023 14:15А что это меняет? Ну не код вы купили. А программу сервере лицензий. Т.е. и право и программа у вас есть.
Принципиально меняет с т.з. закона. Т.к. если вы купили код - вы нарушили закон.
Потому что Майкрософт не продаёт коды. Оно продаёт право на использование, т.е. вместе с кодом вам предоставляется лицензия. Не важно, что галочки в инсталляторе вы понажимаете потом.
А вот то, что технически для пользователя всё выглядит именно так, как вы описали - это всё конечно верно... Но с точки зрения закона происходит не то, что происходит с технической точки зрения.
rsashka
09.04.2023 14:15Давайте приведём пример
Давайте без аналогий, так как они всегда лживы, тем более, что ваш пример с лицензионным договором отличается от передачи исключительных прав, и дело тут совсем не в объеме этих прав, а принципиальном отличии между "лицензированием" и "передачей исключительных прав". Вы опять путаетесь в терминах - предоставляется права на условиях простой (неисключительной) лицензии, а передаётся (отчуждается) только исключительное право
К тому же я вам тоже приводил пример с несуществующим ПО, поэтому лучше говорить конкретно о вашем случае. Вы цитируете ст. 1227 ГК РФ, которая относится только к физическому носителю, на который записан исходный код, но не на сам исходный код, т.е. это не ваш случай.
И вы сами утверждаете, что исходники программы истец не получил, из чего выстраивается следующая логическая цепочка:
Раз нет исходников, нельзя реализовать пп. 9 п. 2 ст. 1270 ГК РФ
Раз истец не имеет возможности использовать ПО в полном объеме исключительных прав, значит он этими правами не владеет, а разработчик эти права в полном объеме ему не передал.
SerjV
09.04.2023 14:15Раз истец не имеет возможности использовать ПО в полном объеме исключительных прав, значит он этими правами не владеет, а разработчик эти права в полном объеме ему не передал.
Одно с другим не связано.
Право может принадлежать кому угодно, а объект прав - находиться в чужом незаконном владении, из-за чего истец и не имеет возможность использовать своё право в полном объёме. И чем менее материален объект прав - тем больше интересных ситуаций может возникать ;)
Право на код у заказчика могло (при другом содержании договора) возникнуть с момента создания этого кода разработчиком. Да, сложно доказывать потом, а есть ли код и где он, но если он есть - то у разработчика лицензия, а не исключительное право. Ну а в данном случае имеем аналог виндикационного иска из "материального" мира.
rsashka
09.04.2023 14:15Право может принадлежать кому угодно, а объект прав - находиться в чужом незаконном владении, из-за чего истец и не имеет возможность использовать своё право в полном объёме.
Я все это понимаю и пытаюсь донести до автора статьи немного другую мысль. Из-за отсутствия исходников на ПО истец не может доказать, что владеет исключительным правами, даже несмотря на наличие договора и согласия ответчика.
Может получится так, что сам ответчик создал фейк или передал права на ПО которое ему не принадлежит и т.д.
Вдруг они находятся в сговоре и судятся только для того, чтобы создать прецедент и зафиксировать факт перехода права на ПО, чтобы потом на него ссылаться в третьем иске уже к реальному владельцу исключительных прав? :-)
mshewzov Автор
09.04.2023 14:15+1Если нет исходников и никогда не было, но было получение денег при заведомо отсутствующих планах что-либо программировать, то я бы тогда назвал это мошенничеством. Тут уже, конечно, вопрос перехода исключительных прав отправляется на второй план. Его можно считать недействительным, а вот уголовное дело выходит на первый план. Но у нас было не так.
rsashka
09.04.2023 14:15... я бы тогда назвал это мошенничеством. Тут уже, конечно, вопрос перехода исключительных прав отправляется на второй план
Вот про это я и говорю. Может быть исходников вообще никогда не было, или разработчик не является их владельцем. Тогда о каком исключительном праве на ПО можно говорить?
mshewzov Автор
09.04.2023 14:15Ну так в нашем деле ведь было не так. Если бы было так, как вы описали, то, конечно, переход исключительного права был бы фейком, недействительной сделкой.
Такое ведь происходит не только с исключительными правами. Бывает даже договор купли-продажи заключают на имущество, которое не принадлежит продавцу. Например, сбыт краденого. Но ладно, тут хотя имущество есть, но оно просто не принадлежит продавцу. А бывает так, когда продают партию товара, например, партию бочек. В договоре может быть прописано, что право собственности и риск случайной гибели переходит к покупателю в момент внесения аванса. Да, такое возможно. Проходит какое-то время, а товара нет и нет, никто не везёт, на звонки не отвечают. Приезжаешь по адресу, указанному в договоре, а там вообще никого нет и не было никогда. Вопрос тот же встаёт - если товар никогда не существовал, то на что тогда право собственности перешло к покупателю? А ни на что. И в этом случае договор скорее всего будет считаться недействительным в связи с отсутствием предмета договора и отсутствием у продавца намерения создать соответствующие правовые последствия от сделки (я думаю, что такой договор будет мнимой сделкой), а сами действия продавца скорее всего мошенническими.
mshewzov Автор
09.04.2023 14:15Давайте без аналогий, так как они всегда лживы, тем более, что ваш пример с лицензионным договором отличается от передачи исключительных прав, и дело тут совсем не в объеме этих прав, а принципиальном отличии между "лицензированием" и "передачей исключительных прав". Вы опять путаетесь в терминах - предоставляется права на условиях простой (неисключительной) лицензии, а передаётся (отчуждается) только исключительное право
Я в терминах не путаюсь. Я оцениваю с точки зрения предмета. В лицензионном договоре предмет - это право пользования программой, а в договоре отчуждения исключительного права - исключительное право на программу. Можно ли что в том, что в другом договоре произвести либо предоставление права пользования программой, либо отчуждение исключительного права на программу, которую физически никто не видит в момент заключения договора и не получает? С вашей точки зрения - нет. С моей - да, т.к. права на программу и сама программа - это вещи независимые друг от друга.
К тому же я вам тоже приводил пример с несуществующим ПО, поэтому лучше говорить конкретно о вашем случае. Вы цитируете ст. 1227 ГК РФ, которая относится только к физическому носителю, на который записан исходный код, но не на сам исходный код, т.е. это не ваш случай.
Нет, вы неправильно трактуете эту норму. Исходный код ВСЕГДА будет на каком-то физическом носителе. Даже если он в облаке, то он всё равно на физическом носителе. Если вам передают код на диске, то код передаётся вместе с физическим носителем, а если вам дают возможность скачать код, то код перезаписывается с одного физического носителя на другой через телекоммуникационные каналы связи. Характерным признаком любого объекта авторского права является его выражение в объективной форме. Если код нигде не записан, а существует только в уме, то он и не охраняется авторским правом. А если он записан хоть где-то, то у него есть объективная форма, а значит есть и материальный носитель.
rsashka
09.04.2023 14:15Давайте тогда прекратим этот разговор, так как я не понимаю, как можно называть себя владельцем исключительных прав до тех пор, пока они не переданы вам разработчиком в полном объеме.
SerjV
09.04.2023 14:15владельцем исключительных прав до тех пор, пока они не переданы вам разработчиком в полном объеме.
По-моему вы не разделяете "владение правом" и "владение тем, на что это право распространяется".
Вы можете владеть (законно) диском с программой, но не владеть записанной на этом диске программой (а вы ей никогда не владеете, если вы не правообладатель, вопреки обывательскому представлению в духе "купить программу").
А может быть и наоборот - вы владеете правом на программу, а диск с программой закатился к соседу, и он вам его не отдаёт.
Отличие этого случая от рассмотренного в статье - у закатившегося диска есть что-то "очевидно материальное", что можно истребовать из незаконного владения, а "просто сорсы" воспринимаются столь же "нематериальными", как и права на них.
И оно почти так и есть :) Но достаточно владеть правом на код, после чего можно распоряжаться любой его копией на любом материальном носителе (но не самим носителем). Нельзя распоряжаться только кодом, который нигде не записан.
В данном случае вопрос "а в гитхабе тот самый код или не тот самый код" не стоял - ответчик сам подтвердил, что тот самый. Скорее всего потому, что если бы заявил, что кода нет - то пришлось бы возвращать деньги за непроделанную работу, а деньги возвращать не хотел.
vikarti
09.04.2023 14:15А что такого? :)
Законы бывают интересные…
В США есть 17 U.S. Code § 201
Там в том числе в пункте e рассматривается вариант можно ли авторские права передать когда автор(или текущий их владелец) вообще этого не хотел. В статье http://law2.wlu.edu/deptimages/law%20review/haemmerliwithnewauthorfn.pdf немного описывается как это работает и зачем там сделали на первый взгляд странные правила.
mshewzov Автор
09.04.2023 14:15А вот лицензионное соглашение (https://yandex.ru/legal/disk_termsofuse/) и пользовательское соглашение (https://yandex.ru/legal/rules/), которым регулируется использование Яндекс.Диска таких положений не содержат. Яндекс не претендует на права пользователей на их контент. Я там такого не нашёл.
А у вот у Облака@Mail.ru (https://help.mail.ru/legal/terms/cloud/LA) - нашёл:
5.10. Лицензиат предоставляет Лицензиару право использовать Контент исключительно для целей функционирования Сервиса необходимым для этого способом.5.11. Использование Лицензиатом Контента, размещенного на Сервисе Лицензиаром, третьими лицами с согласия Лицензиара или Лицензиатами, допускается в рамках функционала Сервиса с соблюдением любых разрешений и ограничений, которые могут быть установлены правообладателем, при условии сохранения знаков авторства (копирайт) или других уведомлений об авторстве, сохранения имени автора в неизменном виде.Как каждый файлообменник определяет - нужно ему запрашивать такие права это или нет - я не знаю. Получается, что можно шарить файлы через Облако@Mail.ru и при этом даже не знать, что в общем-то предоставил ему очень ограниченную, но всё же лицензию. И твой контент уже не такой лицензионно чистый, как хотелось бы.
В случае с GitHub я использовал это в интересах своего клиента, однако в такую ситуацию можно попасть в принципе не только с кодом. Например, с видеоклипом, музыкой, книгой и так далее. Подписываешь договор с продюсером, гарантируя чистоту, что права на произведения никому не предоставлялись, а на самом деле и знать не знаешь, что это не так.
developer7
09.04.2023 14:15+1А вот лицензионное соглашение (https://yandex.ru/legal/disk_termsofuse/) и пользовательское соглашение (https://yandex.ru/legal/rules/), которым регулируется использование Яндекс.Диска таких положений не содержат.
Ну так я и говорю, что автор нашёл мутную дыру в юриспруденции и открыл ящик Пандоры. Получается он уже сейчас может идти и натягивать Яндекс ссылаясь на выигранный им суд.
Хотя у на не прецедентное право.mshewzov Автор
09.04.2023 14:15Яндекс-то тут причём? Мэйл разве что. Но и тут причин у меня для этого пока что нет.
developer7
09.04.2023 14:15Ну яндекс не спросил у вас права на манипулирование вашим контентом которое вы туда закачали. Эксклюзивными правами на контент обладаете вы. Закачав его в яндекс вы дали добро только на закачку. А яндекс и архивировал его, и анализировал, и на веб сервер отправил — что бы вы его на сайте увидели. Короче делал всё то же самое за что засудили исполнителя в статье.
mshewzov Автор
09.04.2023 14:15Тут как раз большое значение имеет эта электронная бумажка, которой регулируется использование Яндекс.Диска. Покуда Яндекс не запросил у меня неисключительную лицензию на загружаемый мной контент, то он просто производит по моему поручению технологические операции с информацией и никак не претендует на использование этого контента хоть каким-либо способом. А если это будет выявлено, то да, есть основание для иска о защите авторских прав.
developer7
09.04.2023 14:15Ну так вы идёте в суд и говорит — я ничего не давал! То что я загрузил != давать разрешение на все операции. Я давал разрешение что бы файл загрузился и оставался в озу загрузочного сервера краткосрочное время, а потом удалился.
А яндекс сам взял да и начал использоваьт мой контент в сомнительных операциях. Разве не это произошло с исполнителем в статье?
mshewzov Автор
09.04.2023 14:15Нет, в моём примере в сообщении выше я говорил про иск к Яндекс. Мол, Яндексу я не давал никаких прав, а он, злодей такой, мой контент начал использовать.
А в моём судебном деле иск был не к GitHub, а к разработчику, который его использовал. И как раз GitHub, в отличие от Яндекса, такие права получил от разработчика, а не должен был.
developer7
09.04.2023 14:15Ну так GitHub подстраховался, мол просил разрешение, и всю ответственность переложил на того кто даёт разрешение. Если бы не просил, то по логике был бы таким же виновником как и тот кто загрузил.
А вот яндекс не просит. Поэтому становится виновником. Такая логика получается.
mshewzov Автор
09.04.2023 14:15Получается.
Но если б разработчик в нашем случае разместил код на Яндексе, то ситуация была бы уже немного другая. Разработчик получается тогда бы произвёл просто незаконное воспроизведение и доведение до всеобщего сведения, без предоставления Яндексу прав. Думаю, что я бы тогда именно так стратегию и выстраивал.
SerjV
09.04.2023 14:15Если бы не просил, то по логике был бы таким же виновником как и тот кто загрузил.
Опять таки нет. "По нашему" если бы не запросил, то это бы означало, что он сказал, что он - "информационный посредник, предоставляющий возможность размещения материала в информационно-телекоммуникационной сети", в пользовательский контент не вмешивается сверх того, что от него требует закон (а закон выше договора), все претензии - к тому, кто выкладывает контент.
И всё, если Яндекс отреагировал в положенный срок на обращение в связи с (защитой детей от информации, нарушением где-то авторских прав и т.п.) - то на этом ответственность Яндекса заканчивается.
И как раз наоборот - тот, кто использует залитые к ним объекты авторского права самостоятельно (майл.ру, гитхаб) - как раз и могут быть привлечены к ответственности за нарушение авторских прав, ну или по крайней мере за свой счёт устранить нарушение этих прав несмотря на то, что в оном нарушении нет их вины. Потому что уже не сможет сказать, что он "он не знал и не должен был знать о том, что использование соответствующих результата интеллектуальной деятельности или средства индивидуализации, содержащихся в таком материале, является неправомерным". Т.к. он уже не посредник, а издатель, со всеми вытекающими.
aborouhin
09.04.2023 14:15+7Юридически - при составлении договора надо думать о том, что если искл. права отчуждаются полностью (авторский заказ или отчуждение по факту выполнения работ), то надо "в обратную" сразу предоставить разработчику необходимый для разработки и последующей поддержки объём прав. Иначе не только с выкладыванием Github будут проблемы. И в целом не ограничиваться общими формулировками и переписыванием ГК на пару листиков, а понятными словами излагать в договоре порядок взаимодействия сторон, так, как по факту предполагается работать - в т.ч. и что где размещается.
Практически - если заказчик озабочен приватностью кода или непокиданием оным рубежей родины - пусть сразу предоставляет свой сервер. Gitea замечательно хороша.
mshewzov Автор
09.04.2023 14:15+1Лучше да, в обратную предоставить какой-то набор прав разработчику. Но в данном случае ничего подобного не было. А по закону разработчик имеет минимум прав на код, права на который он передал заказчику - использовать его для собственных нужд, к которым как минимум не относится его передача по лицензии другим лицам.
developer7
09.04.2023 14:15+1использовать его для собственных нужд
А разве исполнитель использовал код для собственных нужд? исполнитель предоставил код суду. Это не для собственных нужд.
Тут упор делается на то что мол исполнитель вообще даже смотреть в сторону кода не должен был.Но как тогда в суде доказательства представлять? Абсурд?
Давайте тогда схватим человека, работника суда, за то что принёс вещ-доки, например наркотики в зал суда. И сразу в тюрьму. Потому как по закону наркотиков ни у кого не должны быть.
SerjV
09.04.2023 14:15+2Потому как по закону наркотиков ни у кого не должны быть.
Не "ни у кого", законом урегулировано, у кого они могут быть и при каких условиях, а у кого - нет.
"Ни у кого" не должно пользоваться "вредоносных программ для ЭВМ", т.к. никаких исключений не предусмотрено законом (Госдума посчитала, что они опаснее оружия и наркотиков, получается), и формально поэтому половина Лаборатории Касперского давно должна сидеть, и вот тут как раз тот самый случай, когда закон исполняется весьма избирательно.
developer7
09.04.2023 14:15+1Не "ни у кого", законом урегулировано
Ну я сразу видел к чему можно придраться, потому как морфий может быть у врачей, а героин вроде вообще нигде, но мне лень было это расписывать.
А вот про Касперского вы точно подметили.
Просто если аппроксимировать всю эту ситуацию то получаем следующее. Законы никогда не описываю 100% ситуации. Не зря их просто постоянно штампуют новые. И не зря вечно идут споры в суде. И ситуация с GitHab, который явно использовался как инструмент разработки, в такой не описанной законом ситуации, эту ситуацию вывернули в абсурдном виде.
SerjV
09.04.2023 14:15Ну я сразу видел к чему можно придраться, потому как морфий может быть у врачей, а героин вроде вообще нигде, но мне лень было это расписывать.
В гражданском обороте - да. Но есть исключения для целей правосудия. Т.е. потом - только уничтожить, как, например, контрафактные произведения, которые тоже можно только уничтожить, даже если вся контрафактность заключается в легко снимаемой наклейке.
А вот про Касперского вы точно подметили.
Да ладно бы Касперского, там еще правоохранители сами себя давно должны были посадить...
И ситуация с GitHab, который явно использовался как инструмент разработки, в такой не описанной законом ситуации, эту ситуацию вывернули в абсурдном виде.
Вот только эта абсурдность для вас и многих людей - соответствует не только букве закона, но и его духу. Т.к. соответствует сути т.н.з. "интеллектуальной собственности".
Почему в своё время и сказал - претензии надо предъявлять не суду в этом случае, а институту интеллектуальной собственности как таковой.
developer7
09.04.2023 14:15Но ведь чистая логика — это тоже про: Духу закону?
Вроде эта ситуация с точки зрения чистой логики абсурдна. Но и следую правилу "критикуешь, предлагай" можно предложить вполне логичный выход из ситуации — инструменты для написания кода, если они не передают код в публичный доступ, являются инструментами и не нарушают всякие там эксклюзивные права.
Разве суд не должен принять логичное решение?
SerjV
09.04.2023 14:15+3Вроде эта ситуация с точки зрения чистой логики абсурдна.
Не чистой, а "житейской". И вообще, "здравый смысл" лучше выключать, т.к. он мешает понять происходящее.
инструменты для написания кода, если они не передают код в публичный доступ, являются инструментами и не нарушают всякие там эксклюзивные права.
Т.к. публикация и лицензирование - это два разных способа использования исключительного права. А для того, чтобы кому-то лицензировать чужой код - надо обладать правом сублицензирования этого кода.
Что тут сказать... Надо читать договоры даже на инструменты, а то мало ли какой подвох там есть... Например, ваша IDE вставляет в бинарники код, несовместимый с лицензией на исходный код - и вуаля, у вас после компиляции появились контрафактные бинарники.
Просто обычно так не делают. Все привыкли, что инструменты на посягают на содержание того, с чем эти инструменты работают. А гитхаб оказался на таким инструментом.
PereslavlFoto
09.04.2023 14:15+1в большинстве случаев при разработке программного обеспечения на заказ все права на программный код принадлежат заказчику
Правильно ли я понимаю, что права на программный код, ещё не принятый заказчиком и не оплаченный заказчиком, уже принадлежат заказчику?mshewzov Автор
09.04.2023 14:15+1По умолчанию исключительное право на программу для ЭВМ, базу данных или иное произведение, созданные по договору, предметом которого было создание такого произведения (по заказу), принадлежит заказчику, если договором между подрядчиком (исполнителем) и заказчиком не предусмотрено иное. Но как правило в договорах прописывают, что права переходят с момента подписания акта.
PereslavlFoto
09.04.2023 14:15+2Но ведь загрузка на гитхаб происходит задолго до подписания акта?
mshewzov Автор
09.04.2023 14:15Если рассматривать с точки зрения таймлайна, то получается так: если в договоре прописано, что исключительное право на ПО переходит к заказчику от разработчика в момент подписания акта, то получается, что до подписания акта правообладателем ПО является разработчик, а потому в целом загрузка кода на GitHub не нарушает чьи-то права. Однако, с момента подписания акта, если разработчик теряет исключительное право и не получает встречно какой-то неисключительной лицензии на ПО, то с GitHub лучше код удалить (или закрыть доступ).
Если в договоре ничего не прописано, то тут есть два варианта:
договор на разработку заключён с индивидуальным программистом, т.е. с конкретным автором, и тогда вопрос перехода исключительных прав ОБЯЗАН быть решён в договоре, иначе будет идиотская ситуация, когда код разработан под заказ, но права на него остались у разработчика, а у заказчика нет вообще никаких прав;
договор на разработку заключён с компанией, т.е. разработчиком, который привлекает других авторов к разработке, и тогда по закону все права на ПО, как на произведение принадлежат заказчику. В законе не указано с какого момента, но фраза "принадлежат заказчику", мной трактуется так, что принадлежат сразу, с момента создания.
Ndochp
09.04.2023 14:15+2Вот поэтому я всю жизнь (1С, доработки) стараюсь заниматься не "разработкой", а "настройкой" учетной системы заказчика. Дальнейшее тиражирование заказчиком не предполагается, не нужны ему исключительные права на то, что я накодил. А я с чистой совестью занимаюсь копипастом наработок между разными заказчиками.
Не, бывают самоуверенные ребята, которые считают, что их ТЗ достаточно для написания тиражируемого продукта, но от таких лучше свалить, или отдельный прайс.
Так как для них кроме общедоступной под СС4 библиотеки от 1С никаких своих доработок использовать не получится, ну и плюс заявка "наше ТЗ — идеальный конечный вариант ТЗ" обычно первая примета грядущих проблем.
SerjV
09.04.2023 14:15Но как правило в договорах прописывают, что права переходят с момента подписания акта.
А это потому, что бухгалтерия живёт в собственном мире, в котором поглядывает на закон, конечно, но больше смотрит на мнение налогового органа, даже если оно не является нормативным.
rsashka
09.04.2023 14:15+6Хранение кода на GitHub - это передача ему прав на код
После этого вы называете себя юристом?
mshewzov Автор
09.04.2023 14:15Прошу возразить аргументированно.
rsashka
09.04.2023 14:15+13Аргументированно возразить чему, вашему утверждению, что "Хранение кода на GitHub - это передача ему прав на код"?
Попробуйте хотя бы немного разобраться в ИТ терминологии, почитайте про Open Source и Free Software и может быть начнете немного понимать, что публикация кода не имеет ничего общего с передачей прав на код, о которой вы так уверено написали.
Как вы считаете, можно ли человека действительно называть специалистом, если он не владеет даже минимальной терминологией в важной для него области?
PereslavlFoto
09.04.2023 14:15Насколько я понял, автор статьи ничего не говорит про свободное программное обеспечение. Напротив, он говорит только о программах, автор которых не имеет права запускать свои программы, потому что это право якобы сразу принадлежит заказчику.
rsashka
09.04.2023 14:15+4А я ничего не говорю про договорные отношения. Я отвечаю на его вопрос про конкретику и аргументы, в частности, что факт "публикации" никак не связан с фактом "передачи прав", о чем у него написано в одном из заголовков в статье, а открытое и свободное ПО это только хороший пример в различиях между "публикацией" и "передачей прав".
mshewzov Автор
09.04.2023 14:15А зря Вы ничего не говорите про договорные отношения. Вопрос соотношения понятий "публикация" и "передача прав" реально зависит от взаимоотношений публикатора с тем, кто владеет ресурсом, на котором это самое опубликование происходит. В самом простом случае "публикация" не будет равна "передаче прав" только если она происходит на своем собственном сервере, который торчит наружу в сеть IP-адресом или даже доступен через какой-то домен. Вот тут передачи прав нет. А если "публикация" производится на ресурс, принадлежащий третьим лицам, то нужно подробно изучить условия договора или соглашения, на основании которых этот ресурс в принципе предоставляет возможность такую публикацию произвести. К примеру, публикация контента в социальной сети ВК тоже предоставляет ее компании-владельцу довольно внушительный набор прав. А вот публикация материалов на своём сайте, который размещён на арендованном хостинге, не приводит к передаче прав на материал хостеру, т.к. он оказывают исключительно информационно-технологические услуги. Так что вопрос соотношения понятий "публикация" и "передача прав" реально сильно зависит от договорных отношений.
rsashka
09.04.2023 14:15+2У меня претензия к конкретной кликбейтной формулировке, которая не согласуется с общепринятой терминологией и вводит читателей в заблуждение.
А в части договорных отношения вы в большей части правы и у меня к этому нет принципиальный возражений. Так зачем мне про этого говорить?mshewzov Автор
09.04.2023 14:15+1Тогда подытожим. У Вас получается тоже претензия к моему упрощению. Я подумаю, как изменить "передача прав" на что-то другое, чтобы было и просто, и согласовалось с общепринятой терминологией. Пока в мыслях фраза "передача лицензии". Это согласуется с терминологией. Фразу "предоставление прав" не хочу использовать, это довольно громоздко.
rsashka
09.04.2023 14:15Заключение лицензионного соглашения, принятие договора оферты или просто оферты, согласие с условиями использования ...
mshewzov Автор
09.04.2023 14:15+1Ну это длинные варианты. Я уже внёс правки - передача лицензии.
В самом законе допускается масса вольностей в терминах. Например, в п. 1 ст. 1236 ГК РФ написано так:
1. Лицензионный договор может предусматривать:1) предоставление лицензиату права использования результата интеллектуальной деятельности или средства индивидуализации с сохранением за лицензиаром права выдачи лицензий другим лицам (простая (неисключительная) лицензия);2) предоставление лицензиату права использования результата интеллектуальной деятельности или средства индивидуализации без сохранения за лицензиаром права выдачи лицензий другим лицам (исключительная лицензия).То есть в понимании законодателя простую (неисключительную) лицензию можно ещё и выдавать :)
mayorovp
09.04.2023 14:15+3Тем не менее, это связано через условия использования сайта.
К примеру, когда я отправлю этот комментарий, Хабр получит право показывать его всем подряд на основании пункта 4.8 пользовательского соглашения.
PereslavlFoto
09.04.2023 14:15+4Честно говоря, когда я отправляю этот комментарий, я навязываю Хабру обязательство показывать его всем подряд.
powerman
09.04.2023 14:15+5Вряд ли хабр тоже так думает - иначе не прилетало бы временами НЛО и не удаляло комменты и аккаунты.
tyomitch
09.04.2023 14:15+1Хабр никому не обязан его показывать: НЛО может его скрыть по желанию левой пятки, даже не уведомляя вас.
rsashka
09.04.2023 14:15+2Давайте избежим ситуации, когда "ученый изнасиловал журналиста". Как вы понимаете словосочетание "передача права на код" в контексте статьи от юриста?
Что же касается Хабра, то тут все еще интереснее. Если мне не изменяет память, то когда вы пишите и публикуете на Хабре свой материал (по крайне мере для ППА), то вы передается Хабру право не только его показывать, но и право собственности на него, а Хабр в свою очередь публикует этот материал под лицензией CC BY 3.0, что защищает его от возможных проблем в случае, если автор решит изменить лицензию на статью в последствии.
Ndochp
09.04.2023 14:15+1Так там же подробно описано. "Передача неисключительных прав на хранение, копирование с целью бэкапов, демонстрацию [не]ограниченному списку пользователей гитхаб."
Но даже такую фигню имеет право заключать только владелец кода. Значит наличие кода на акке разработчика после подписания акта с заказчиком — нарушение.rsashka
09.04.2023 14:15+2Так там же подробно описано.
Именно поэтому я и написал, что формулировка Хранение кода на GitHub - это передача ему прав на код является кликбейтной, которую никак не ожидаешь от юриста.
Ниже уже написали корректную формулировку подобного словестного выверта:
с учётом того, что дальше автор говорит про соглашение с Гитхабом - "условия использования сервиса GitHub представляют собой практически чистый лицензионный договор".
Уже лет 15 это называется предоставлениям права на условиях простой (неисключительной) лицензии. А передаётся (отчуждается) только исключительное право.
Поэтому формулировка от юриста должна быть "Хранение кода на GitHub - это предоставление права на код на условиях простой (неисключительной) лицензии", и это принципиально важно!
mshewzov Автор
09.04.2023 14:15+1Корректная формулировка мне известна. Я, повторюсь, старался упростить чтение статьи.
Предложенный Вами вариант чрезвычайно длинный. Я думаю, что стоит сократить до "передача лицензии".
rsashka
09.04.2023 14:15+1И да и нет.
Тут принципиально важен временной момент публикации и момент передачи права на код. Например, если права на код передаются в момент подписания акта приема передачи и полной оплаты, то до этого момента владельцем исключительных прав на код является разработчик. Или, например, у них в договоре может быть прописана передача кода как раз таким способом.
SerjV
09.04.2023 14:15+5Аргументированно возразить чему, вашему утверждению, что "Хранение кода на GitHub - это передача ему прав на код"?
Я бы, кстати, тоже домахался до оборота "Хранение кода на GitHub - это передача ему прав на код" с учётом того, что дальше автор говорит про соглашение с Гитхабом - "условия использования сервиса GitHub представляют собой практически чистый лицензионный договор".
Уже лет 15 это называется предоставлениям права на условиях простой (неисключительной) лицензии. А передаётся (отчуждается) только исключительное право.
А вот в старом законодательстве это действительно называлось "передачей неисключительного права".
Не надо смотреть на бухгалтерские документы - они пишутся не в соответствии с законом, а в соответствии с мнением налоговой, не имеющем силы нормативного акта, но зато имеющем значение при взаимодействии с этой самой налоговой.
MountainGoat
09.04.2023 14:15Вы докапываетесь не до автора, а до бедности русского языка в технических вопросах. "Передача" может означать и move и copy. Автор утверждает что докопался до того, что разработчик не имел права копировать никакие права Гитхабу, в это же время принятие оферты гитхаба означает копирование прав на показ кода от выкладывающего в Гитхаб.
SerjV
09.04.2023 14:15Вы докапываетесь не до автора, а до бедности русского языка в технических вопросах. "Передача" может означать и move и copy. А
Русский язык тут совершенно не причём. Формулировки совершенно чётко определены в 4-й части ГК РФ - той самой, что вступила в силу ~15 лет назад. И есть устаревшие формулировки, не менее чётко определённые законодательством, прекратившим действовать с момента вступления в силу 4-й части ГК РФ.
Это вам не художественный текст, тут лучше тавтологию 10 раз подряд написать, т.к. "одно и то же должно называться одним термином".
mshewzov Автор
09.04.2023 14:15Да ладно Вам, мы же на Хабре, не в суде. Я хочу, чтобы моя статья была понятна всем, а не только юристам.
SerjV
09.04.2023 14:15+2Да ладно Вам, мы же на Хабре, не в суде. Я хочу, чтобы моя статья была понятна всем, а не только юристам.
Вот потому лучше использовать формулировки из актуального законодательства, а не утратившего силу 15 лет назад, просто "а бухгалтерия-то не знает".
Т.к. в современных условиях сбиваете с толку - увидев "передача права" сразу возникает ассоциация с отчуждением исключительного права (нередкая вещь, впрочем, при публикациях), а не с предоставлением права по лицензии.
mshewzov Автор
09.04.2023 14:15+1Я спорить не буду. Приму к сведению. Если будет критическое количество читателей, сбитых с толку моими упрощениями, тогда вернусь к оригинальным формулировкам.
SerjV
09.04.2023 14:15+2Есть подозрение, что именно об этой "передаче" и говорил rsashka ...
Замени вы во всей статье одно единственное слово - в заголовке "Хранение кода на GitHub - это передача ему прав на код" - слово "передача" на "предоставление" - и вообще разговора бы этого не было :)
Из-за него по тексту статьи непоследовательность возникает - вы везде в контексте лицензии говорите о предоставлении права, даже в том самом параграфе про "передачу" прав гитхабу, и о передаче в контексте исключительного права. И т.о. только термин в заголовке параграфа не бьётся с его содержанием.
SerjV
09.04.2023 14:15+1Ну и повод лишний раз напомнить, что бухгалтерия живёт в собственном мире, а не по закону :)
mshewzov Автор
09.04.2023 14:15+1Ну, вы частично правы. Дело в том, что я стараюсь писать свои статьи максимально доступным языком, иногда упрощая некоторые вещи. В данном случае фраза "передача прав на код", конечно, является упрощением. По факту конструкция авторских прав имеет следующие уровни вложенности:
-
исключительное право (имущественное), которое включает следующие способы использования произведения (так называемые правомочия):
правомочие на воспроизведение произведения;
правомочие на распространение произведения;
правомочие на публичный показ произведения;
правомочие на импорт произведения в целях распространения;
правомочие на прокат произведения;
правомочие на публичное исполнение произведения;
правомочие на сообщение в эфир;
правомочие на сообщение по кабелю;
правомочие на ретрансляцию;
правомочие на перевод или другую переработку произведения;
правомочие на практическую реализацию архитектурного, дизайнерского, градостроительного или садово-паркового проекта;
правомочие на доведение произведения до всеобщего сведения;
иные правомочия (список открыт, можно использовать произведение и способом, которого в законе попросту нет).
-
неимущественные права и иные права:
право следования;
право доступа;
право авторства;
право автора на имя;
право на неприкосновенность произведения;
право на отзыв.
Так вот, говоря о "правомочиях", очень часто это громоздкое слово заменяют на "право". Например, в лицензионных договорах почти всегда пишут "право на воспроизведение ПО".
-
mshewzov Автор
09.04.2023 14:15Погодите, а что не так? Как можно опубликовать код на GitHub и НЕ ПРИНЯТЬ его условия использования? Никак, я думаю. А принимая его условия использования разработчик заключает с GitHub Inc. лицензионный договор, которым предоставляет этой компании неисключительную лицензию на любой публикуемый на GitHub материал с довольно внушительным перечнем правомочий. И в итоге тут не важна общепринятая терминология, т.к. нужно оперировать теми параметрами, что заложены в условия использования GitHub, а из них фактически следует, что любое хранение материалов на серверах GitHub порождает предоставлением GitHub Inc. определённых прав (правомочий) на эти материалы.
SerjV
09.04.2023 14:15+2Я бы, кстати, тоже домахался до оборота "Хранение кода на GitHub - это передача ему прав на код" ... Погодите, а что не так? ... которым предоставляет этой компании неисключительную лицензию
В термине "передача" вместо "предоставление". Передаётся/отчуждается исключительное право, право на использование - предоставляется.
Но вот до вступления в силу в 2008 году 4-й части ГК РФ были Закон Российской Федерации "Об авторском праве и смежных правах" и Закон Российской Федерации "О правовой охране программ для электронных вычислительных машин и баз данных", и вот там не "предоставлялось право на использование", а "передавалось неисключительное право".
Бухгалтерия до сих пор живёт в реальности "до 2008 года" и у неё право возникает на основании акта приёмки-передачи (непонятно чего передачи, но зато нет вопросов у налоговой), а не предоставляется договором (и никакие акты для этого не нужны, но зато трудно объясняться потом налоговой).
rsashka
09.04.2023 14:15+1Лицензионный договор может быть у каждой компании свой и описывать какие то свои условия или термины, даже не согласующиеся с общепринятой терминологией. Поэтому общепринятая терминология не менее важна, в противном случае вас просто не будут понимать.
vikarti
09.04.2023 14:15+1Технически он ведь прав. :)
Гитхабу надо ж право например показывать этот код в веб-интерфейсе или там отдавать по запросу с правильными ключами и прочие вещи которые нужны для обеспечения собственно работы с кодом.
То что там права прописаны слегка в общем виде… ну так понятно почему — вот выпустил гитхаб Codespaces и что — просить всех согласится с новыми правилами а кто не согласился — не давать использовать Codespaces?Да, разработчикам очевидно зачем это нужно. А юристу — заметил потенциальную проблему (которой никто бы наверно и не воспользовался потому что любой адекватный эксперт бы сказал что тут чисто технические права). И даже сумел ее использовать в пользу своего клиента.
PereslavlFoto
09.04.2023 14:15Но сам код оказался выгружен на GitHub, так как в трёх экспертизах в предыдущем судебном деле эксперты знакомились с кодом именно на GitHub на аккаунте разработчика.… Разработчик повёл себя очень некрасиво — ему дважды писались письма о том, чтобы он передал код. ...
Правильно ли я понимаю, что разработчик загрузил код на Гитхаб, однако заказчик, увидев там этот код и скачав к себе, потом ещё дважды просил разработчика передать код каким-то другим способом, без помощи интернета?mshewzov Автор
09.04.2023 14:15Заказчик ничего не скачивал. Вроде бы разработчик ему как будто бы создавал логин, так он рассказал на суде, но этот логин был только у разработчика, заказчику он доступы не передал.
PereslavlFoto
09.04.2023 14:15+1Если не передал доступ, тогда вообще непонятно, зачем разработчику нужен гитхаб.
Но почему заказчик не знал, как подключиться, если три (!) судебных эксперта знали? Здесь какая-то путаница.
MountainGoat
09.04.2023 14:15А где вы видели утверждение, что на Гитхабе лежал весь код, а так же ресурсы, документация, вспомогательные программы?
mshewzov Автор
09.04.2023 14:15Экспертам дали доступ к приватным репозиториям. Я чуть выше писал, тут продублирую.
Судя по заключению экспертизы разработчик давал экспертам (трём, на минуточку) доступы к приватным репозиториям (там их было три - код под Android, под iOS и серверная платформа). Во всех заключениях присутствует одна и та же фраза: "На исследование был предоставлен удаленный доступ к репозиториям разработанного программного обеспечения со следующими параметрами..." и дальше адреса репозиториев. Сам разработчик в суде заявлял о приватных репозиториях, о доступе только по приглашению и так далее. И вроде бы даже клиент присутствовал при осмотре репозиториев через видеосвязь, но сам доступ к ним разработчик ему никогда не давал, а письма - игнорировал.PereslavlFoto
09.04.2023 14:15+1Могу лишь повториться. При таких условиях вообще непонятно, зачем разработчику понадобился гитхаб. Какое-то тотальное неразумие.
mshewzov Автор
09.04.2023 14:15Тут я согласен. Получается, что никто им не пользовался, кроме разработчика. На этом и спалились.
rsashka
09.04.2023 14:15+1В таком случае приватная репа гитхаба может выступать в качестве третьей независимой стороны для подтверждения как самого факта передачи и фиксации списка и состава передаваемых файлов.
И подобный способ передачи результатов работ ничуть не хуже флешки или компакт диска, лишь бы он устраивал обе стороны договора.
mshewzov Автор
09.04.2023 14:15Может, но как получить юридически значимый документ от GitHub, который бы подтверждал такую передачу? Это вопрос. Разве что описать весь процесс детально в самом договоре. Но у нас был не тот случай. В договоре этого не было.
rsashka
09.04.2023 14:15mshewzov Автор
09.04.2023 14:15Тут вопрос не в незаверенном скриншоте. У нас в деле они были. В частности, разработчик сделал запрос в службу поддержки GitHub - был ли создан аккаунт для заказчика, а также был ли предоставлен доступ на этот аккаунт к репозиториям. GitHub ответил, что да, аккаунт такой-то был создан, доступ к репозиторию ему был предоставлен. Но... слабое место было в том, что аккаунт для заказчика создавал разработчик и факт передачи заказчику данных для доступа к аккаунту он не смог доказать. И в итоге вся эта цепочка рухнула.
rsashka
09.04.2023 14:15Ну это вопрос больше к юристу, а не к поддержке Гитхаба.
Я бы на месте вашего оппонента вообще не стал доказывать факт передачи результатов работы, а согласился бы с вами, что да не передал :-)
Тогда выходит, что компания-разработчик передала только часть прав на программу, что не соответствует положениям ст. 1285 ГК РФ. Ведь согласно договору об отчуждении исключительного права на произведение автор или иной правообладатель передает или обязуется передать принадлежащее ему исключительное право на произведение в полном объеме.
А раз этого не произошло, то и передачи исключительного права на произведение тоже не состоялось и оно осталось у разработчика. Да, это тоже нарушение договора, но другого рода, и разработчик, как владелец исключительных прав (раз он их не передал), мог делать с исходниками что угодно, в том числе и публиковать на гитхабе.
mshewzov Автор
09.04.2023 14:15Было бы интересно, как бы развивался суд, будь со стороны разработчика такое заявление :)
В ст. 1285 говорится о передаче исключительного права в полном объёме. И тут имеется в виду, что право передаётся без ограничений по способам использования произведения, то есть приобретатель становится полноправным правообладателем. Тут не идёт речь о полном объёме произведения. Исключительное право в полном объёме можно передать и на часть произведения. Это происходит, к примеру, когда работы сдаются поэтапно.
Статью 1285 нужно читать без отрыва от статьи 1234 ГК РФ.
Плюс в п. 7 ст. 1259 ГК РФ говорится о том, что авторские права распространяются на часть произведения, если по своему характеру она может быть признана самостоятельным результатом творческого труда автора и выражена в объективной форме. В программном коде большинство частей могут считаться самостоятельными произведениями. Всякие модули, библиотеки, функции и так далее - все они могут быть перенесены в другой софт, а могут распространяться и отдельно.
В общем, тут я не вижу противоречий.
rsashka
09.04.2023 14:15Без передачи исходников нельзя реализовать пп. 9 п. 2 ст. 1270 ГК РФ, из чего следует, что в полном объеме права все же не переданы.
Более того, учитывая ст. 1288 и 1296 ГК РФ не стоит полагать, что созданная программа по договору авторского заказа безраздельно ваша. Я уже писал выше про Open Source и Free Software, которое тоже может быть использовано при разработке заказного ПО, но права на него не переходят заказчику, т.к. исполнителю просто не принадлежат.
Нюансов может быть множество, и даже при один и тех же исходных данных два разных суда могут вынести противоположные заключения.
mshewzov Автор
09.04.2023 14:15Без передачи исходников нельзя реализовать пп. 9 п. 2 ст. 1270 ГК РФ, из чего следует, что в полном объеме права все же не переданы.
Нет, не так. Права переданы в полном объёме, просто разработчик чинит препятствия в их реализации.
Более того, учитывая ст. 1288 и 1296 ГК РФ не стоит полагать, что созданная программа по договору авторского заказа безраздельно ваша. Я уже писал выше про Open Source и Free Software, которое тоже может быть использовано при разработке заказного ПО, но права на него не переходят заказчику, т.к. исполнителю просто не принадлежат.
Верно, но об этом речи в данном конкретном споре не было. Никто об этом даже не вякнул, а само ПО рассматривалось как полностью авторская разработка.
Нюансов может быть множество, и даже при один и тех же исходных данных два разных суда могут вынести противоположные заключения.
Вполне. Но на то и нужна судебная практика, чтобы при идентичных вводных таких случаев было меньше и они стремились к нулю.
rsashka
09.04.2023 14:15+2Нет, не так. Права переданы в полном объёме, просто разработчик чинит препятствия в их реализации.
Истец заплатил деньги за программу с искусственным интеллектом. Ответчик предоставил удаленный доступ для проверки её работы, истец остался доволен результатом и заплатил за передачу прав "в полном объеме".
Но при передаче результатов работы возник спор, так исходников ПО переданы не были. В результате судебных разбирательств выяснилось, что ответчик при демонстрации работы программы только имитировал работу ИИ, а самой программы и её исходников как таковой не существует.
Внимание вопрос, на что "в полном объеме" переданы права?
mshewzov Автор
09.04.2023 14:15В описанном случае - нет, права не будут переданы. Но это выяснится только в процессе судебного разбирательства. Такие казусы встречаются довольно часто. Например, когда автомобиль де-факто не существует, т.к. уничтожен, но числится в базе данных МРЭО и ФНС. Это обычно либо следствие злоупотреблений и недобросовестного поведения, либо просто сочетания неожиданных обстоятельств.
vikarti
09.04.2023 14:15+6А что было бы адекватным выполнением требований?
- отправка по почте флешки, с трекингом?(а если заказчик скажет что не получал или она не читается? А если она реально не читается — у него?)
- отправка по почте DVD?
- передача того и другого прямо на заседании?
- отправка (видимо курьерской доставкой) распечаток исходного кода?
mshewzov Автор
09.04.2023 14:15Там договор был довольно куцый. В плане сдачи-приёмки работ было написано просто, что они сдаются по актам и всё. Но я бы попросил передать код как минимум с описью всех передаваемых файлов и их MD5 или SHA256. Заказчик вообще помимо этого просил ещё и демонстрацию провести, правда договором это не было предусмотрено и я его предупредил, что такое требование хоть и можно заявить (не в суде, а в претензии), но скорее всего его пошлют. Это недоработка самого договора, увы. Хотя с другой стороны, по закону результат, который передает разработчик (как любой подрядчик) должен быть пригоден к использованию. А как это подтвердить, если передавать просто файлы по описи? Никак. Тут без демонстрации никак.
Giperoglif
09.04.2023 14:15+1так если код передавался по акту то на момент его передачи разработчиком гитхабу, права на него ведь принадлежали разработчику, а не заказчику?
mshewzov Автор
09.04.2023 14:15В теории - да. А по факту разработчик не смог доказать, что код был выгружен на GitHub до даты приёмки работ и перехода прав к заказчику. В итоге у нас остались только даты, в которые эксперты осматривали код в репозиториях GitHub, а эти даты были уже после даты приёмки работ и перехода прав.
Sayonji
09.04.2023 14:15Подскажите, пожалуйста, почему ответчик должен доказывать дату? Разве по умолчанию ответчик не считается правым, и не должен истец доказывать, что ответчик нарушил что-то?
mshewzov Автор
09.04.2023 14:15А истец и доказал. Мы сказали, что исходный код был доступен на GitHub в даты проведения экспертиз, а это уже после подписания акта передачи прав. Другой даты ответчик не смог доказать. То есть наши доводы он не опроверг.
PuerteMuerte
09.04.2023 14:15+2Разве по умолчанию ответчик не считается правым, и не должен истец доказывать, что ответчик нарушил что-то?
Презумпция невиновности ответчика, это в уголовном и административном праве. В хозяйственных спорах она не применяется.
Adverte
09.04.2023 14:15+2Какие дела в сфере IP вы берёте в работу?
mshewzov Автор
09.04.2023 14:15Наверное, почти все. Защищаем как разработчиков, так и заказчиков. Регистрируем всё, что регистрируется (кроме изобретений и полезных моделей), защищаем всё, что защищается. Если что-то конкретно интересует - напишите в личку.
saipr
09.04.2023 14:15+3Итого, суд поддержал мою позицию, признал факт размещения кода на GitHub нарушением исключительных прав заказчика на код и взыскал двойную стоимость разработки.
GitHub здесь всё же не причем:
Разработчик повёл себя очень некрасиво — ему дважды писались письма о том, чтобы он передал код, но он на них так и не ответил, а устно сообщил, что ничего передавать он не намерен и мы можем судиться до побеления.
Вы наказали нерадивого разработчика и это правильно, но наводить тень на плетень не стоит. Как справедливо отметил oraclejob :
гитхаб — общепринятое хранилище кода, никто не оспаривает вроде.
и то что он американский это за уши притянуто. Все кто им пользуется, ему просто доверяют и не задумываются об его принадлежности.
mshewzov Автор
09.04.2023 14:15GitHub здесь всё же не причем:
Сам GitHub тут, конечно, вообще в споре не участвует. Он о нём даже не знает. Но мне важно было выстроить логическую цепочку: отсутствие прав на код -> публикация на GitHub, что равно заключению лицензионного договора -> нарушение исключительных прав. И мне это удалось. Факт размещения кода на GitHub - это как минимум доведение до всеобщего сведения, воспроизведение и распоряжение исключительным правом на код, который публикатору не принадлежит.
Вы наказали нерадивого разработчика и это правильно, но наводить тень на плетень не стоит. Как справедливо отметил oraclejob :
Не согласен. Под комментом @oraclejob в принципе уже всё написано в ответ.
и то что он американский это за уши притянуто. Все кто им пользуется, ему просто доверяют и не задумываются об его принадлежности.
А зря. Вон недавно рассматривался даже вопрос о блокировке аккаунтов российских разработчиков. Вроде пронесло. Но надолго ли?
NeiroNx
09.04.2023 14:15+1Сервер можно где угодно разместить - заказчик сам должен об этом подумать заранее при составлении договоров. Понятно что у больших контор есть свои типа Gitlab.
GitHub большая помойка, не редко там можно найти годные вещи, но говна там предостаточно. Иногда трудно найти, а иногда случайно попадается интересующий "закрытый" алгоритм шифрования.
А тем кто боится - можно локальный Gogs запустить - он умеет по расписанию зеркалировать репы.
denis-19
09.04.2023 14:15GitHub перевёл репозиторий IPMI Tool и другие проекты разработчика Александра Амелькина в режим Public archive из-за санкций.
2 марта 2022 года представители команды веб-сервиса для хостинга IT-проектов и их совместной разработки GitHub закончили спор о том, нужно ли блокировать российских разработчиков. Платформа обозначила, что будет домом для всех разработчиков, независимо от того, где они проживают, а также заявила, что будет следить за ситуацией и не позволит попасть под блокировку всем подряд, включая обычных разработчиков.
sshemol
09.04.2023 14:15Может немного не в тему, но напомню, что на гихабе поднимался вопрос о бане всех российских разработчиков.
okovalevski
09.04.2023 14:15+1Михаил Юрьевич все написал абсолютно правильно, тем более что все это есть почти дословно и в решении суда первой инстанции и в апелляции. Выкладывать на GitHub код права на который переданы заказчику неправомерно (как минимум надо спросить согласие). Применимое право в данной ситуации Российское, никаких сомнений в этом нет. ООО "Ера" вместо того чтобы удалить код с GitHub дало к нему доступ экспертам, вместо того чтобы принести флэшку в суд и потребовать принять результат работ господин Давыдов пошел сам себя закапывать, результат очевиден.
PereslavlFoto
09.04.2023 14:15Выкладывать на GitHub код… ООО «Ера»… дало к нему доступ экспертам
То есть подрядчик поместил код на гитхабе, однако не дал доступа никому? И поэтому гитхаб ничего не смог сделать с этим кодом?
schulzr
09.04.2023 14:15+1Спасибо! Очень полезно. А я правильно понимаю, что использование sourceforge, gitlab, bitbucket предполагает похожие юридические ограничения?
MountainGoat
09.04.2023 14:15+2Да. И если вы планируете арендовать VPS у одобренного всеми службами провайдера в России и иногда запускать код там - тоже надо очень внимательно читать соглашение. Если там написано, что вы передаёте провайдеру права на запуск программного обеспечения, установленного вами на VPS - то тоже можно точно так же докопаться.
Ну или договор с заказчиком составлять так, чтобы это всё вас не касалось.
developer7
09.04.2023 14:15Как заказчик аргументировал что код на GitHab его? Если он его не получал? Может исполнитель просто взял деньги и не выполнил заказ. А то что он выложил на GitHab — это его личные разработки. В таком случае предмет спора только возврат денег за не выполненный заказ.
И вообще неясно — заплатили ли вы вообще? Обычно подписывается акт передачи кода, так в каком виде код был передан заказчику? Но если код не передавался (по вашим словам) — то заказ не был выполнен. Опять же предмет спора — невыполнения заказа.
И не понятна позиция исполнителя, что значит он отказался предать код, когда он его аж на GitHab выложил? Вот просто так взял и отказался, из за своей неконтролируемой злобы?Мутная какая то история, что то явно не договаривают.
developer7
09.04.2023 14:15Почитал выше комменты немного объясняющие мутные моменты, но честно говоря история от этого мутной не перестаёт быть.
Остаётся вопрос — лежал ли код на GitHab до подписания договора с заказчиком о получении кода ( вроде как выше сказано что заказчик принял какой то код. 70%) Хотя не понимаю как такой акт приёма передачи будет выглядеть. Ведь контракт на 100%. И он либо выполнен полностью, либо нет.
В общем если код лежал на GitHab до передачи эксклюзивных прав — то не понятно как тогда можно было натянуть исполнителя. Разве что права которые были переданы, уже не являются эксклюзивными.
Но честно говоря это реально уже какой то тонкий лёд. Ведь наверняка есть какие то соглашения на импользование и на компьютер, и на интернет которым пользовался исполнитель, и на флешку. Всякие условия использования есть вообще на всё. Там будут банальщины, но они будут. И получается что куда бы заказчик с кодом не полез — везде он бы нарушил "эксклюзивные" права. Бред получается.
mshewzov Автор
09.04.2023 14:15Остаётся вопрос — лежал ли код на GitHab до подписания договора с заказчиком о получении кода ( вроде как выше сказано что заказчик принял какой то код. 70%)
Наверное, Вы имели в виду до подписания акта о передаче кода, а не договора. Лежал ли до акта - неизвестно. Может и лежал. Разработчик об этом писал в своих возражениях. Гораздо важнее, что он лежал и после. А самим договором использование GitHub хоть для чего-нибудь не предусматривалось.
вроде как выше сказано что заказчик принял какой то код. 70%) Хотя не понимаю как такой акт приёма передачи будет выглядеть. Ведь контракт на 100%. И он либо выполнен полностью, либо нет.
Разработчик ясен пень клялся, что разработал 100% и всё выполнил, но экспертиза посчитала, что им выполнено около 74% объёма работ от ТЗ. Именно за 26% недоработок заказчику суд в первом деле и взыскал аванс обратно. Правда он потерялся в сумме судебных расходов. Но это другая история.
В общем если код лежал на GitHab до передачи эксклюзивных прав — то не понятно как тогда можно было натянуть исполнителя. Разве что права которые были переданы, уже не являются эксклюзивными.
А вот это главный секрет - исполнитель не смог доказать дату размещения кода на GitHub. Я не знаю почему и не хочу знать. В итоге у нас остались только даты, когда экспертам предоставлялся доступ на GitHub для осмотра кода. А эти даты были позднее передачи исключительных прав заказчику.
Но честно говоря это реально уже какой то тонкий лёд. Ведь наверняка есть какие то соглашения на импользование и на компьютер, и на интернет которым пользовался исполнитель, и на флешку. Всякие условия использования есть вообще на всё. Там будут банальщины, но они будут. И получается что куда бы заказчик с кодом не полез — везде он бы нарушил "эксклюзивные" права. Бред получается.
Я тут ничего не понял, но скажу так: в нашем случае у разработчика с заказчиком был очень простой и незамысловатый договор на разработку с приложением в виде ТЗ. Все права на код переходят к заказчику после приёмки работ. Даже если она была формальной (прислали акты, а заказчик отмолчался).
developer7
09.04.2023 14:15Я тут ничего не понял, но скажу так
Понимаю )) Написал сумбурно. Я имел ввиду следующее. Имеем код который был размещён на сайте GitHab, где были заключены какие то соглашения на размещения. Получаем ситуацию что код который не должен иметь никаких других соглашений, т.е. должен быть чистым, и такой чистый код можно отдать под эксклюзивным соглашением., так вот мы код испачкали соглашением от GitHab
Если код побывает хоть где то (как на GitHab) где также имеются соглашение на пользование, получаем ситуацию когда код пачкается этими соглашениями и не может уже быть передан как эксклюзивный.
Код передавался через провайдера исполнителя. Значит код побывал в среде — которая имела какие то соглашения с разработчиком. Всё код испачкали. Он уже не эксклюзивный.
Взять компьютер — там наверняка есть инструкция типа, в блок питания пальцы не совать иначе ударит током. Если вы сунули — сами виноваты, компания ответственности не несёт. Понятно что компания так перестраховывается. И ещё скорее всего приписка есть — если вы начали пользоваться железякой, то соглашения приняты, и все риски по удару током берёте на себя. Получается очередное соглашение которое берёт заказчик на себя. И на этом же компе разрабатывается чистый код, который уже замаран этим соглашением.
Короче выше описанное выглядит как чистый бред, но это бред такого же характера как и размещение на GitHab в закрытом репозитории.
mshewzov Автор
09.04.2023 14:15Ваша мысль о том, что если до передачи кода (и прав на него) опубликовать его где-нибудь и принять соглашение, которое предоставляет хоть какую-нибудь лицензию владельцу сайта, где он опубликован, то код можно считать "испачканным" таким соглашением - это верная мысль.
Но Вы далеко зашли. Те же инструкции к компьютеру, его деталям и так далее - они не содержат никаких положений о том, что производителям этих железок переходят хоть какие-то права (или правомочия) на разрабатываемый с применением таких железок код.
developer7
09.04.2023 14:15они не содержат никаких положений о том, что производителям этих железок переходят хоть какие-то права
А разве имеет какие то значение конкретика? передали права или ещё что то?
С одной стороны имеем "эксклюзивные права", которые в том числе подразумевают что на код не должно быть вообще ни каких дополнительных соглашений.
А с другой стороны имеем те же права, но уже с доп соглашением, по типу этот код разрабатывался на таком компьютере. И ни на каком ином. Т.е. эксклюзивные права уже испачканы дополнительным ограничением.
Вроде как в юриспруденции как в математике, формальность превыше всего.
Собственно я это пишу не как юрист (даже рядом не стоял), а как программист))) да и вообще ради потрепаться.Пишу этот бред что бы показать, что эксклюзивные права не должны портится от взаимодействием с правами систем требующих для разработки самого кода.
Компьютер нужен как не крути. Поэтому права связанные с компом не должны пачкать эксклюзивную передачу прав. Так же и GitHab — это инструмент для разработки. Разработчику нужна контроль версий и прочего. Так код разрабатывают. Поэтому он не должен пачкать лицензию.
А то получаем — тут пачкает, тут нет.
mshewzov Автор
09.04.2023 14:15А разве имеет какие то значение конкретика? передали права или ещё что то?
Конечно имеет. Должно быть чётко прописано, какие права, на что, кому и от кого передаются.
С одной стороны имеем "эксклюзивные права", которые в том числе подразумевают что на код не должно быть вообще ни каких дополнительных соглашений.
А с другой стороны имеем те же права, но уже с доп соглашением, по типу этот код разрабатывался на таком компьютере. И ни на каком ином. Т.е. эксклюзивные права уже испачканы дополнительным ограничением.
Не верно. Вот эти вот самые "дополнительные соглашения" должны касаться конкретного произведения, должны предполагать передачу каких-то конкретных прав (или правомочий) конкретному лицу от другого конкретного лица.
developer7
09.04.2023 14:15Конечно имеет. Должно быть чётко прописано, какие права, на что, кому и от кого передаются.
Как я понял там договор максимально ни о чём был. Как и сам факт передачи кода — то же какой то бред.
Но в договоре было написано передача эксклюзивных прав. Правильно?
А что под эти подразумевается? Под эксклюзивность. В договоре был определён этот термин с перечнем требований?
Ну или в юриспруденции есть чёткое описание этого требования?
Потому как на этом можно играть в обе стороны почти до предела. Для одних эксклюзивность это код кинул на почту и забыл про него. А для других это рабство разработчика например.
должны предполагать передачу каких-то конкретных прав
Это в нормальном договоре. И чем больше пунктов тем меньше разногласий. Но как я понял в договоре "курильщика" было только про эксклюзивность?
mshewzov Автор
09.04.2023 14:15В договоре было написано, что с момента подписания акта исключительные (не эксклюзивные, а исключительные) права на результаты работы переходят к заказчику. По закону такой фразы достаточно, чтобы заказчик стал правообладателем кода
developer7
09.04.2023 14:15Так он и стал. Никто не спорит. Проблема в том, а что конкретно входит в эти исключительные права?
Входит ли туда такое — в первое мгновение обладания исключительными правами на код заказчиком, должно ли в тоже мгновение этот же код исчезнуть у исполнителя со всех носителей где он есть (в том числе GitHab)? Бредово. Ладно, сколько даётся времени что бы исполнитель удалил код. Если время в договоре не указанно, может ли исполнитель удалить код в течении года?
Хотя если код был размещён после передачи прав. Честно говоря я что то вообще запутался. Зачем исполнитель вообще что то размещал на GitHab после передачи эксклюзивных прав. Как я понял по просьбе заказчика, потому как у него не было кода вообще?
Как вообще можно обладать эксклюзивными правами на пустоту? Кода же не было. История реально мутная.mshewzov Автор
09.04.2023 14:15Так он и стал. Никто не спорит. Проблема в том, а что конкретно входит в эти исключительные права?
Всё входит. Как в право собственности. Полная власть над объектом права.
Входит ли туда такое — в первое мгновение обладания исключительными правами на код заказчиком, должно ли в тоже мгновение этот же код исчезнуть у исполнителя со всех носителей где он есть (в том числе GitHab)? Бредово. Ладно, сколько даётся времени что бы исполнитель удалил код. Если время в договоре не указанно, может ли исполнитель удалить код в течении года?
По умолчанию, если иное не предусмотрено договором, исполнитель при отчуждении исключительного права на ПО получает на него неисключительную лицензию использовать этот код в собственных нуждах. Но в них не входит, например, лицензирование кода кому-либо. Это за пределами такой лицензии. Плюс договором можно предусмотреть, что у исполнителя и этих прав не остаётся. Тогда да, придётся удалить незамедлительно изо всех мест.
Хотя если код был размещён после передачи прав. Честно говоря я что то вообще запутался. Зачем исполнитель вообще что то размещал на GitHab после передачи эксклюзивных прав.
А кто его знает зачем. Он и сам не смог ответить на этот вопрос в суде. Он клялся, что разместил до передачи, а доказать не смог.
Как я понял по просьбе заказчика, потому как у него не было кода вообще? Как вообще можно обладать эксклюзивными правами на пустоту? Кода же не было. История реально мутная.
Код был, иначе что тогда исследовали эксперты? Просьба заказчика о размещении на GitHub не было.
developer7
09.04.2023 14:15Что то я совсем запутался. Вроде было сказано что эксперты исследовали код на GitHab, доступ к которому им дал исполнитель. При этом код у заказчика отсутствовал. Если код был у заказчика, зачем тогда вообще GitHab всплывал в истории?
mshewzov Автор
09.04.2023 14:15Я имел в виду, что код был, т.е. существовал в принципе. Из Вашего предыдущего комментария я понял так, что как могут быть права на пустоту, кода же нет. Код был, но был не у заказчика, а у исполнителя.
SerjV
09.04.2023 14:15А вот это главный секрет - исполнитель не смог доказать дату размещения кода на GitHub. Я не знаю почему и не хочу знать.
Отсюда, кстати, еще один полезный вывод - права должны переходить к заказчику не по акту, а с момента создания соответствующего объекта авторского права. Тогда дата публикации вообще не будет иметь значения.
Благо закон это позволяет. Не надо смешивать закон и бухгалтерские заморочки.
mshewzov Автор
09.04.2023 14:15Как заказчик аргументировал что код на GitHab его? Если он его не получал? Может исполнитель просто взял деньги и не выполнил заказ. А то что он выложил на GitHab — это его личные разработки. В таком случае предмет спора только возврат денег за не выполненный заказ.
А Вы знаете, тут нам очень помогло решение по предыдущему суду, которое прошло апелляционную инстанцию и было оставлено без изменения. Оно в целом хоть и было не в пользу моего клиента, однако из него удалось выжать все соки. В частности, в нём прямо были указаны адреса на конкретные репозитории с кодом, который все фактически признали, что является результатом работы разработчика. Тут мне даже не нужно было ничего аргументировать в этом плане. В трёх экспертизах было указано, что сам разработчик дал удалённый доступ к трём репозиториям с кодом. Очевидно же, что это и был тот самый разработанный по договору код, права на который перешли к заказчику.
И вообще неясно — заплатили ли вы вообще? Обычно подписывается акт передачи кода, так в каком виде код был передан заказчику? Но если код не передавался (по вашим словам) — то заказ не был выполнен. Опять же предмет спора — невыполнения заказа.
Заказчик заплатил за разработку кода, это 100%. Обычно подписывается акт передачи кода, да только тут акты были направлены заказчику молча, и он также молча на них никак не отреагировал. Суд посчитал, что раз 5 дней прошло, активности заказчик не проявил - ни отказался от приёмки, не подтвердил её, то значит работы приняты. Но суд констатировал это формально, это значит, что работы приняты просто за отсутствием возражений со стороны заказчика. А фактически никто и ничего не передавал. Этот вопрос изучался в судебном деле, которое было до меня. Вот ссылка. Как раз там и был предмет спора - невыполнение заказа.
И не понятна позиция исполнителя, что значит он отказался предать код, когда он его аж на GitHab выложил? Вот просто так взял и отказался, из за своей неконтролируемой злобы?
Вот тут хз. Со слов заказчика - отказался, сказал, что судиться ему будет дешевле. А после суда, о котором я написал в статье, вообще заявил, что теперь он его удалит. Честно говоря, мне мотивы такого поведения разработчика были малоинтересны. У меня была задача, которой я нашёл интересное решение.
Raz0o0r
09.04.2023 14:15Как вариант: заказчик внёс предоплату (в неустановленном объёме), по неизвестным причинам не захотел/ не смог выплатить оставшуюся часть, соответственно исполнитель код не передал.
И вы правы, история мутная
mshewzov Автор
09.04.2023 14:15Чуть больше подробностей по самой истории разработки и оплаты можно найти здесь. Это предыдущее дело между теми же сторонами, в котором я не участвовал. Предоплата там была, по-моему, в 100% размере. Но разработчик толком не разработал вменяемое ПО. Собственно экспертиза показала массу ошибок и недоработок, хотя и признала итоговое ПО относительно годным к использованию с устранимыми недостатками. Эксперт посчитал, что разработчик завершил работы на 74%.
aborouhin
09.04.2023 14:15+1Там как раз, судя по тексту решения, предоплата плюс-минус сошлась со стоимостью работ, которую "уменьшил" эксперт с учётом выявленных недостатков. Взыскали в основном неустойку. И весь сыр-бор был именно в экспертизах, которых там была не одна, с допросами экспертов и прочими развлечениями (мне кажется, что судебные расходы там должны были превысить сумму спора, не говоря уже про скромный результат оного).
В общем, с правовой точки зрения совершенно неинтересный кейс, а что там было в экспертизах - нам не видать. Я на месте истца в целом возражал бы против постановки вопроса, что реальная стоимость работ должна определяться экспертизой без учёта бизнес-планов заказчика на приложение (даже доделанный на 99% результат может быть на 100% бесполезным). Однако суд констатировал, что против финальных выводов экспертизы обе стороны не возражали.
mshewzov Автор
09.04.2023 14:15Да там в первом деле много было странностей. Но я подключился уже после того, как апелляция вынесла своё постановление. С точки зрения практики само первое дело, конечно, неинтересное. Просто удалось выжать из него неплохое второе дело.
UMenyaNeudobnieVoprosiki
09.04.2023 14:15+2Судя по комментариям, далеко не все разработчики в курсе, что на GH репозитории можно делать закрытыми и вообще как это работает, и почему этим пользуются вполне себе крупные коммерческие конторы за бугром не испытывая таких проблем. Это довольно прискорбно, как и попытка подоить разработчиков за использование актуальным инструментом вместо "версионирования в архивах на дискете на магнитике на холодильнике". Как и формулировочки в духе "передали права GitHub", как писали выше. Не удивлюсь, если с таким подходом заказчик сам виноват в том, что ПО было готово только на 74% ввиду мутных формулировок, регулярных переделок и прочих мутков. Да и софт может ему не нужен был, тут же новая модель бизнеса - взыскать вдвое больше стоимости софта (что уже за гранью здравого смысла). Странно что не предложили всё имущество разраба конфисковать сразу, на нём же код писали.
mshewzov Автор
09.04.2023 14:15А статус "закрытого" репозитория как влияет на тот факт, что разработчик предоставил GitHub неисключительную лицензию на код? Тут уже всё равно какой был репозиторий. Разработчик просто не был вправе этого делать и всё. Код не принадлежал ему.
SerjV
09.04.2023 14:15Странно что не предложили всё имущество разраба конфисковать сразу, на нём же код писали
Вот вы просто на удачу это написали, или реально знали, что это тоже потенциально возможно (но не в описанном в статье случае скорее всего)?..
mshewzov Автор
09.04.2023 14:15Ну почему же, когда взысканы деньги и их добровольно не собираются отдавать, то это вполне закономерный следующий этап.
SerjV
09.04.2023 14:15Для этого не нужна оговорка "на нём же код писали".
А с такой оговоркой - это намёк на КоАП. Хотя, скорее всего это оспоримо в КС, аналогичный случай был по другой статье, но тем не менее :)
tester12
09.04.2023 14:15+2Ну, без GitHub ещё можно обойтись. А электронная почта? Когда разработчик отправляет заказчику код, он же тоже заключает соглашение с почтовым сервисом и предоставляет право на хранение и передачу информации (в т.ч. отправляемого кода), на анализ этой информации всякими спам-фильтрами и т.п.
mshewzov Автор
09.04.2023 14:15+1Не замечал, чтобы в условиях использования электронной почты были какие-то параметры по предоставлению прав оператору электронной почты на пересылаемый контент. Такого не встречал я.
developer7
09.04.2023 14:15+1Наткнулся на следующую формулировку в законе:
Кроме того, по умолчанию труды создателя нельзя искажать, представлять по частям, снабжать пояснениями. Чтобы новый правообладатель имел право на усовершенствование, рекомендуется включать в договор условие о согласии автора внесения изменений в произведение.
Значит ли это что новый владелиц, если это не разрешено в договоре, не имеет право и буквы в коде исправить? Это получается код в мусор превращается.
mshewzov Автор
09.04.2023 14:15Формально - да, это называется "право на неприкосновенность произведения". Но я всегда такую формулировку в свои договоры включаю. Плюс для программ для ЭВМ есть ряд исключений, см. ст. 1280 ГК РФ:
1. Лицо, правомерно владеющее экземпляром программы для ЭВМ или экземпляром базы данных (пользователь), вправе без разрешения автора или иного правообладателя и без выплаты дополнительного вознаграждения:1) осуществлять действия, необходимые для функционирования программы для ЭВМ или базы данных (в том числе в ходе использования в соответствии с их назначением), включая запись и хранение в памяти ЭВМ (одной ЭВМ или одного пользователя сети), внесение в программу для ЭВМ или базу данных изменений исключительно в целях их функционирования на технических средствах пользователя, исправление явных ошибок, если иное не предусмотрено договором с правообладателем;2) изготовить копию программы для ЭВМ или базы данных при условии, что эта копия предназначена только для архивных целей или для замены правомерно приобретенного экземпляра в случаях, когда такой экземпляр утерян, уничтожен или стал непригоден для использования. При этом копия программы для ЭВМ или базы данных не может быть использована в иных целях, чем цели, указанные в подпункте 1 настоящего пункта, и должна быть уничтожена, если владение экземпляром таких программы или базы данных перестало быть правомерным.2. Лицо, правомерно владеющее экземпляром программы для ЭВМ, вправе без согласия правообладателя и без выплаты дополнительного вознаграждения изучать, исследовать или испытывать функционирование такой программы в целях определения идей и принципов, лежащих в основе любого элемента программы для ЭВМ, путем осуществления действий, предусмотренных подпунктом 1 пункта 1 настоящей статьи.3. Лицо, правомерно владеющее экземпляром программы для ЭВМ, вправе без согласия правообладателя и без выплаты дополнительного вознаграждения воспроизвести и преобразовать объектный код в исходный текст (декомпилировать программу для ЭВМ) или поручить иным лицам осуществить эти действия, если они необходимы для достижения способности к взаимодействию независимо разработанной этим лицом программы для ЭВМ с другими программами, которые могут взаимодействовать с декомпилируемой программой, при соблюдении следующих условий:1) информация, необходимая для достижения способности к взаимодействию, ранее не была доступна этому лицу из других источников;2) указанные действия осуществляются в отношении только тех частей декомпилируемой программы для ЭВМ, которые необходимы для достижения способности к взаимодействию;3) информация, полученная в результате декомпилирования, может использоваться лишь для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, не может передаваться иным лицам, за исключением случаев, когда это необходимо для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, а также не может использоваться для разработки программы для ЭВМ, по своему виду существенно схожей с декомпилируемой программой для ЭВМ, или для осуществления другого действия, нарушающего исключительное право на программу для ЭВМ.4. Применение положений, предусмотренных настоящей статьей, не должно противоречить обычному использованию программы для ЭВМ или базы данных и не должно ущемлять необоснованным образом законные интересы автора или иного правообладателя.То есть существует ряд разрешений в силу закона, которые позволяют что-то менять в коде программы для ЭВМ, если это сделано указанных выше целях.
developer7
09.04.2023 14:15+2О, придумал вариант как выкрутится для исполнителя.
Надо перейти на следующую позицию. Мол GitHab аккаунт не его. Он загрузил туда код. И передал ключи заказчику. А так же передал аккаунт заказчику. А то что заказчик потерял ключи на вход, ну это его проблема.
Способ передачи кода в контракте не был оговорён, так что исполнитель выбрал GitHab. Вполне распространённый способ.
У исполнителя остался резервный ключ входа. Заказчик мог удалить его, но почему то этого не сделал.
Т.е. Аккаунт на GitHab это аккаунт заказчика, следовательно исполнитель ничего не нарушал.
Как вам такой финт ушами ))))
mshewzov Автор
09.04.2023 14:15Так себе идея :)
Мол GitHab аккаунт не его.
Его, он же запрос в GitHub делал, а служба поддержки отвечала, что, мол, да, к вашему репозиторию предоставлялся доступ следующим аккаунтам, в частности указывалось на якобы аккаунт, который специально создавался для заказчика.
И передал ключи заказчику. А так же передал аккаунт заказчику. А то что заказчик потерял ключи на вход, ну это его проблема.
Исполнителю в итоге не удалось доказать, что он передал ключи, передал аккаунт и что он в принципе хоть что-то передал заказчику.
Способ передачи кода в контракте не был оговорён, так что исполнитель выбрал GitHab. Вполне распространённый способ.
Если способ не оговорён, то значит должно быть передано на бумаге по акту с приложением материального носителя. А то если рассуждать как вы, то исполнитель тогда может выбрать способ передачи голубиной почтой. Ну а что, в договоре же способ не оговорён, исполнитель выбрал самый распространённый в начале 20-го века способ :)
У исполнителя остался резервный ключ входа. Заказчик мог удалить его, но почему то этого не сделал.
Ну это при условии, что он хоть что-то бы передал заказчику, а он не передал ничего.
Аккаунт на GitHab это аккаунт заказчика, следовательно исполнитель ничего не нарушал.
Ага, и поэтому в ответе GitHub везде фигурирует, что это репозиторий Романа Давыдова - директора ООО исполнителя. Нестыковочка :)
GitHab
Почему вы GitHub называете GitHab? Звучит, как название ирландского паба. Все тут мне тыкали в неточность моих формулировок, мол, терминологию надо соблюдать. Так что я тоже замечание сделаю :)
developer7
09.04.2023 14:15+1Исполнителю в итоге не удалось доказать, что он передал ключи, передал аккаунт и что он в принципе хоть что-то передал заказчику.
Реально не понимаю. В суде выяснили что исполнитель ничего не передавал, но при этом заказчик вдруг оказался владельцем каких то прав. Ладно вроде это уже где то тут обсуждалось, и лень искать что там было сказано.
А по поводу передачи — вариант с GitHab-ом вполне нормальный. DVD — уже вымерло, разве что на flash-ке. Но online передовать — так все делают.Походу уже обсудили всё что можно и пора завязывать )
А по по воду GitHab — да по приколу.
mshewzov Автор
09.04.2023 14:15Под названием GitHab было бы круто открыть реально паб какой-нибудь в программистском стиле. Всё оформлено листингами кодов, старая техника, как-то стилизовать тарелки, кружки и так далее.
developer7
09.04.2023 14:15Идея интересная — вот только бы мелкомягкие в суд не подали ) Хотя GitLub вроде норм существует )
SerjV
09.04.2023 14:15+1В суде выяснили что исполнитель ничего не передавал, но при этом заказчик вдруг оказался владельцем каких то прав.
Есть старинный анекдот про консультацию у юриста:
- а у меня право есть на...
- есть, есть.
- а раз есть, я могу...
- нет, не можете.Недаром же говорят, что люди не собственники даже своих смартфонов )
ReadOnlySadUser
После этого можно переставать читать. Вы видимо вообще не в курсе как работают децентрализованные VCS)
Marwin
и всё же проблема не невозможна... легко представить заказ на десктопную программу у шарашки-однодневки, которая выполнила ТЗ, собрала, установила софт заказчику, крайне далёкому от IT, и дала аккаунт от гитхаба с исходником, а сама самоликвидировалась. Пройдет месяц-другой, гитхаб станет в позу, дропнет акк как расово неверный, и всё, код утерян, при последующих доработках надо будет пилить с нуля, ведь заказчик само собой ничего заранее себе качать не будет и вообще ни бум-бум. У меня в практике такие вполне себе встречались.
vikarti
И как быть?
Альтернативы тут по большому счету:
У меня был случай.
У руководства заказчика возникли вопросы с аутсорсером (при этом с разработчиком кто вс — все было нормально но он просто уходить хотел и сказал об этом всем).
Заказчик сказал что они уходят, дайте исходники, доступы и прочее.
Аутсорсер отдал, но строго формально — например отдали не репозиторий а срез исходников. (без папки .git), ключи подписи не отдали. Вот только заказчику это и надо было чисто формально потому что заключили договор с тем разработчиком что работал над проектом и раньше. И потом еще несколько лет работали и расстались вполне себе довольные друг другом.
Xambey97
Self Hosted only решения и нет проблем
Kenya-West
Хостер дропнет ваш "селф"-хост - и чем это отличается от ситуации с GitHub? Судиться с хостером, а заказчик в свою очередь судится с вами? А если хостер зарегистрирован на Кипре? Удачи
Ndochp
Self — это даже не в облаке. и тем более не у хостера.
SaNNy32
Может сдохнуть жесткий диск, а бэкапа не быть. Или быть, но очень старый.
larasage
Мальчик заходит в автобус и покупает два билета. Водитель у него спрашивает:- Зачем тебе два билета, ты же один?- На всякий случай, если один билет потеряю.- А если второй потеряешь?- На этот случай у меня проездной.
saboteur_kiev
Это же ералаш!
domix32
И сдохнет сразу у разраба, ага.
vikarti
это случай
PuerteMuerte
Это ровно то же самое, что отдать заказ на десктопную программу у шарашки-однодневки, которая выполнила ТЗ, собрала, установила софт заказчику, крайне далёкому от IT, и дала ему код каким угодно способом, а заказчик ввиду некомпетентности его посеял, а шарашка самоликвидировалась. Гитхаб в схеме с таким заказчиком и таким исполнителем наоборот, островок стабильности и надёжности :)
0x131315
До сих пор в ходу такая методология как передача кода в архиве. Я сам в осадок выпал, когда узнал что оно не только еще живо, но и вполне распространено среди таких вот контор-однодневок и несведущих работодателей.
Код передается от заказчика разработчику и обратно в архиве. На сервера заливается через архивы. И попробуй угадай что было изменено и когда. Ну а если архив с нужной версией потеряют - бекапов нет, это не git.
Ndochp
Обычно передают архив, а в приложение к договору или акт идет MD5 (да, я знаю, что это не лучший вариант, но это то, что я видел). А вот как зафиксировать, что именно было передано (с точки зрения целостного пакет электронных артефактов), если это гитреп — непонятно.
Так что архив — отличная вещь для фиксации конкретной версии. Ну а прав на продукт(название, бренд, торговую марку) у разработчика на контракте изначально не было, их он передавать не может.
mshewzov Автор
Да, на самом деле я довольно давно уже рекомендую своим клиентам вне зависимости от способа передачи кода фиксировать переданные файлы в акте с указанием MD5 и SHA256. Плюс прописываю, что заказчик при получении файлов всё открыл, проверил, просмотрел и подписанием акта подтверждает это. А ещё более лучший вариант - двойной акт. Первый акт - передача файлов, второй акт - по завершению тестирования или демонстрации. Либо один акт, но тестирование и демонстрацию как-то прописать в договоре заранее, до подписания акта. Бывают такие заказчики, которые не разбираются в ИТ или у них нет на это времени, или хз какие у них могут на это ещё быть причины, и они попросту не понимают, как проверить то, что они получают от разработчика, на предмет соответствия ТЗ. Двойной акт должен снизить риски такого непонимания.
ogost
В году эдак в 15-ом пришить CD с переданным кодом к акту о завершении работы было нормальным явлением. И хорошо, если додумаются не дырявить сам диск.
mayorovp
Да даже для сведущих это распространено.
На прошлой работе мы выкачивали наш же код с svn (промежуточного) заказчика, добавляли туда же бинарники из его же jenkins, заливали на диск и передавали ему обратно. Просто потому что так проще всё оформить...
shark14
Github — это не только версионирование кода, а еще пулл-реквесты со всеми обсуждениями и комментариями. Зачастую они представляют не меньшую ценность, чем собственно код.
mshewzov Автор
Я может чего-то не понимаю, всё же я юрист, а не разработчик, но здесь рассматривается конкретная система - GitHub. Не локальная VCS, а именно та, которая развёрнута на северах GitHub. Как децентрализация поможет, если GitHub отключит все аккаунты российских разработчиков? По-моему никак. Если ошибаюсь - поправьте меня.
Adverte
Спасибо за уточнение! Теперь понятно
aborouhin
Вам пытались намекнуть, что git в принципе не работает в режиме "всё только на удалённом сервере", если разработчик хранит код на github или другом git-сервере - локальная копия у него тоже есть, он работает с ней и только потом делает push на сервер. Хотя, конечно, можно представить разные ситуации, когда такая локальная копия будет утрачена, но это уже по части раздолбайства.
mshewzov Автор
Согласен про локальную копию. Но тогда это будет сервер GitHub и сервер разработчика. А в нашем случае разработчик попросту отказался передать заказчику код. И заказчик остался ни с чем. Более того последний раз, когда мы с ним общались уже после суда, он вообще сказал, что он его попросту удалил.
aborouhin
Убедительный расчёт упущенной выгоды способен сотворить чудеса в вопросе восстановления удалённых данных :)
mshewzov Автор
Мы пошли пока по-другому пути. Хотя и ваш вариант тоже имеет место быть.
vikarti
Иногда это даже правда :).
Потому что подьем бекапа — это время сисадминов и ресурсы с тем куда его накатить (это хорошо если инфраструктура позволяет просто запустить бекап в виртуалке никуда не восстанавливая а если нет?). А если бекап вообще (или конкретно эти старые) на лентах? Ну или не на лентах а спокойно лежит в Amazon Web Services, в Glacier или чем то похожем (там хранение очень дешевое но вот если потребуется восстанавливать то это будет очень дорого).
aborouhin
Думаю, там вопрос не в этом. Вряд ли кто-то в своём уме реально удалил собственный код, каким бы старым он ни был. И вряд ли, если спор уже в суде (т.е. потрачены существенные суммы на юристов, время и нервы) стоимость восстановления хоть терабайта с Glacier будет на фоне цены такого спора ощутимой. Скорее, просто издеваются, мол, удалил и что ты со мной сделаешь :) Всех обстоятельств дела не знаю, так что насколько такое поведение обоснованно - вопрос.
mshewzov Автор
Там товарищ разработчик очень принципиальный попался. По рассказам заказчика разработчик в какой-то момент просто бросил разработку и сказал, что ему дешевле будет судиться, чем работать дальше. Возможно он недооценил свои силы, а в договоре была фикс-цена за конкретное ТЗ, и разработчик понял, что он слишком дешево оценил проект. Хз, какие там причины у него были. Первый суд мой клиент (заказчик) выиграл, условно выиграл. Из заявленной суммы взыскания за недоработанное ПО ему суд взыскал 24%, то есть при условном проигрыше ответчика последний фактически "выиграл" на 76%. Плюс распределение стоимости экспертиз и в итоге истец (заказчик) оказался должен ещё хорошую сумму ответчику. Я в том суде не участвовал, поэтому сделать с этим уже ничего не смог. И если бы не идея с GitHub, то угроза разработчика, что ему дешевле судиться, реально оказалась бы претворенной в жизнь.
PereslavlFoto
Значит, вы наказали разработчика за то, что он отказался работать себе в убыток.
А как следовало поступать в этой ситуации? Вот давайте представим, что вы сами попали в точно такую ситуацию. Вы заключили договор и сделали часть работы, но потом поняли, что за предложенную сумму сделать эту работу невозможно. А значит, исполнение этой работы означает для вас обязательный убыток.
Как бы вы поступили, чтобы выйти из договора, не потеряв никаких денег?
mshewzov Автор
Это лишь моё предположение, что он отказался работать себе в убыток. Каковы были его причины, что он сказал "мне судиться будет дешевле, чем продолжать работу" - это загадка для меня.
Я попадал в такую ситуацию. Ради своей репутации я просто выполнял работу добросовестно и качественно, как и обещал. Моя неверная оценка стоимости работы - моя проблема, не заказчика.
PereslavlFoto
Иначе говоря, если подрядчик неверно оценил стоимость, значит, он должен работать в убыток и обогатить заказчика. С точки зрения человеческих моральных ценностей это хорошо. Советские люди одобряли такой подход к делу. Однако сегодня, при капитализме, когда все рвут друг у дружки рубль, такой подход не будет популярным.
mshewzov Автор
Ну погодите, разве должен подрядчик перекладывать свои проблемы в идентификации стоимости своего труда на заказчика? А что если все начнут так делать? Купите Вы хлеб за 30 рублей, а завтра в магазине Вам скажут - чувак, доплати, плиз, рублей 5, я тут посчитал, что мне хлеб-то в производстве дороже обошёлся. Не обессудь, капитализм же.
У нас компании сотнями банкротятся из-за того, что неэффективный менеджер наворотил делов и вогнал компанию в убыток. И никто из них не говорит своим покупателям или заказчикам, что, мол, ребята, я тут в банкротство почти упал, поднимите плиз, накиньте на прошлогоднюю поставку ещё 100% от цены, а то я неправильно оценил стоимость тогда.
PuerteMuerte
Если вы хлеб будете покупать по предоплате, сегодня оставите 30 рублей, а завтра его в магазин хлебозавод завезёт по новым ценам, именно так вам магазин и скажет :)
А это зависит от размера проблемы. Помните один из классических "бизнесовых" фильмов — "Бойцовский клуб"?
" — Когда мы выпускаем партию автомобилей с дефектом, мы оцениваем возможные суммы исков от пострадавших и сравниваем это со стоимостью отзыва партии. Если отзывать партию дороже, мы партию не отзываем.
— А в какой компании вы работаете?
— В крупной."
Тут нет единого паттерна. Если вы можете просто немного докинуть из своего кармана, чтобы закрыть проект, и вам интересно и с заказчиком отношения продолжать, и репутация ваша должна быть белая и пушистая, почему бы и нет? Но если вы очень сильно ошиблись, а это в ИТ не редкость, увы, (потому что чтобы правильно оценить объем работ, надо по сути софтину наполовину разработать), зафиксировать текущий финансовый и репутационный убыток, заплатить возможные штрафы и неустойки, и выйти из проекта — тоже вполне себе жизнеспособная стратегия.
SerjV
Если магазин умный - то в договоре будут условия, позволяющие ему изменить цену при определённых условиях. А если дурак - получит жалобы в контролирующие органы, проверки и прочее.
Ну это да - если санкции за неисполнение договора дешевле убытков от его исполнения, то именно что дешевле понести эти санкции и выйти из проекта...
Вот только при дефолтном договоре выплата неустойки не освобождает от исполнения обязательства в натуре, так что если с другой стороны не лохи - то этот риск будет учтён и просто так выйти из проекта не получится, не переплатив. А вот если лохи - то да... Вот именно этом всём и строится современный бизнес :)
mshewzov Автор
Зависит от договорных условий. Если я физик-потребитель, то магазин так сделать по закону не сможет. Если я организация-заказчик (или ИП), то если в договоре не прописана возможность изменения цены, то изменить её будет нереально.
Вот именно для таких случаев в договоре нужно предусматривать максимально сбалансированные условия выхода из проекта. Однако, согласитесь, что зафиксировать "текущий финансовый и репутационный убыток, заплатить возможные штрафы и неустойки, и выйти из проекта" - это не то же самое, что взять деньги, не выполнить обязательства, потому что решил, что неверно оценил свои силы, и НИЧЕГО НЕ ВЕРНУТЬ! В зафиксированный убыток должна входить сумма возврата аванса, плюс возмещение убытков заказчику (а такое вполне возможно).
PuerteMuerte
Я имею в виду, конечно же, реальные условия — при устном договоре, как это обычно происходит. "Мань, вот тебе 30 рэ, отложи завтра с утра буханку хлеба, я после работы зайду".
Если это какой-то другой, более гипотетический кейс, то у вас все равно есть выбор между "отработать в убыток" и "выйти из договора". А в крупных проектах и промежуточные варианты бывают, например, "упрятать свои увеличившиеся косты в дополнительных соглашениях".
Конечно. Но тут проблема явно не в гитхабе :)
mshewzov Автор
При устном договоре изменить цену на товар невозможно будет.
И все эти "варианты" лучше прописывать в договоре. Иначе будут использоваться "варианты" из закона, а там они совсем невыгодные.
PuerteMuerte
Зато можно безболезненно его разорвать, вернув деньги.
Ну как бы косты — это всё-таки внутренняя кухня исполнителя, заказчик про них знает только то, что они там какие-то должны быть, и не в состоянии оценить, "вот эта сумма работ по допсоглашению включает в себя только новые работы плюс маржа, или там запрятано ещё 10% переработок по предыдущему блоку работ"
mshewzov Автор
Вот именно, что безболезненно. Но это если вопрос в 1 булке хлеба. А не в грузовике. Там уже не так безболезненно.
А никто и не просит в договоре прописывать всю внутреннюю кухню. Достаточно прописать порядок изменения цен в случае чего, а также порядок расторжения договора.
SerjV
Напоминаю (вместе с ВС РФ), что "предпринимательской является самостоятельная, осуществляемая на свой риск деятельность, направленная на систематическое получение прибыли от пользования имуществом, продажи товаров, выполнения работ или оказания услуг." (п.1 ст.2 ГК РФ) и "Условия договора определяются по усмотрению сторон, кроме случаев, когда содержание соответствующего условия предписано законом или иными правовыми актами (статья 422)." (п.4 ст. 421 ГК РФ).
Поэтому всё совершенно верно: подписал - исполняй, твои убытки от договора никого не волнуют. И именно потому, что капитализм.
Чтобы не попадать в такие ситуации - помните про ст.421 "Свобода договора" и закладывайте условия и процедуры для ситуаций "цена договора оказалась слишком низкой".
А не вот это вот "сначала сдемпингуем в цене договора, а потом кинем заказчика, если он не захочет доплачивать".
aamonster
Мне казалось, что на такой случай предусматриваются условия разрыва договора одной из сторон... (какая-то неустойка или ещё что).
SerjV
Ну если стороны думают о рисках, то да, такой случай предусматривается договором. А если "лишь бы поменьше бумажек и попроще бумажки" - то вот случается всякое.
PuerteMuerte
Есть существенная разница между исполнителем-консультантом и исполнителем-девелоперской компанией: если вы неверно оценили своё личное время, вы можете огрести недополученную прибыль, но вы никогда не получите убытка. Если же вы неверно оценили стоимость проекта, план ресурсов которого включает несколько больше позиций, чем одна строчка "Я", вы как раз рискуете получить реальный убыток, который в зависимости от масштабов проектов может оказаться и несовместимым с бизнесом.
SerjV
Может. Не заключайте договоров, которые не можете выполнить, или которые недостаточно учитывают риски при его выполнении. Исполнителя же никто не заставляет?
PuerteMuerte
Никто от ошибок не застрахован. Очевидно же, что исполнитель, заключая договор, на этом этапе совсем не ожидает, что он потратит кучу ресурсов и бросит проект с потерями для себя на полпути. А наоборот, имеет какую-то вполне положительную оценку. Да, какие-то риски она, очевидно, не учитывает… только исполнитель про это узнает намного более потом, при их реализации :)
tommyangelo27
Достаточно или недостаточно учтены риски можно узнать только в моменте, когда они реализовались.
SerjV
Риски "высокого уровня" всегда можно учесть. А вот механизмы работы с ними и конкретику - требуют некоторой практики.
Т.е. всегда можно предположить, что работа по какой-то причине не будет завершена в срок. Но предположить эти причины и действия в случае их наступления - трудно или даже невозможно на практике, если проект уникальный и до сих пор никто не делал ничего подобного. В этом случае логично не подписываться на фикс прайс вообще.
А если это 100500-й случай - то вполне можно разделить причины на "по вине исполнителя" (тянул время), "по вине заказчика" (слишком часто вносил правки или тоже тянул время на предоставление зависящей от него информации), "в виду слишком больших неопределённостей" (по достижении определённого предела выводящих проект за рамки фикс прайса).
Проще говоря, всегда можно предположить, что любое обязательство сторон по договору может быть невыполнено или выполнено не в срок. Почему, насколько это вероятно и как это критично для каждой из сторон и что делать - это как раз то, что требует от сторон усилий по проработке при заключении договора.
mshewzov Автор
С одной сторон да, когда речь идёт об индивидуальном исполнителе-консультанте, однако и тут есть нюансы - та же репутация, которая может упасть в ноль. А если речь идёт об организации с наёмными сотрудниками, то тут дело не ограничивается недополученной прибылью. Я, к примеру, работаю не один. У меня масса ежемесячных расходов. И неверная оценка стоимости работы может привести к тому, что я закрою месяц/квартал/год в убытках.
gohrytt
Вся статья звучит так, будто у разработчика действительно была причина так поступить.
mshewzov Автор
Причины его такого поведения мне неизвестны. Я защищал другую сторону, не разработчика. Так что, увы. А личные взаимоотношения между заказчиком и разработчиком это уже дело их личное. В суде они ни к чему по такой категории дел.
Metotron0
Не знаю, как другие, а лично я работаю по принципу: закончились задачи по какому-то проекту — удалил репозиторий со своего компьютера. Правда, у нас на работе свой гитлаб, а не гитхаб, но в случае гитхаба я бы поступал так же. Правда, если по какому-то проекту регулярно приходят доработки, то его я оставляю лежать. А в остальных случаях место жалко.
aborouhin
Как человеку, который за последние 25 лет не удалил ни одного документа, электронного письма (кроме спама), фотографии, и уж тем более ни одной написанной строчки кода, мне это сложно понять :)
Понятно, что не всё хранится прямо на рабочем ноуте - но, благо, сейчас легкодоступны и сервера/NASы, и публичные/частные облака. Лучше сохранить лишний терабайт, который никогда не пригодится, чем удалить тот единственный документ, который через 10 лет неожиданно вдруг станет нужен...
А в случае заказного кода хранить его весьма полезно даже тем, кто не страдает подобной страстью к архивированию вообще всего, как я. Чтобы подстраховаться от возможных претензий, как по качеству кода, так и по нарушению прав третьих лиц, которые могут возникнуть совершенно неожиданно и через много лет.
P.S. Сорри, уже написав ответ, понял, что Ваш комментарий был не к ветке выше про разработчика, который в суде утверждал, что "удалил код", а про сохранность кода на Гитхабе. Тогда я не совсем в тему ответил, но пусть уж лежит коммент, раз написан :)
0x131315
На практике у многих большие проблемы с доступным местом под подобного рода архивы. А один проект может и 10гб спокойно весить. Из-за этого иногда возникают конфликты - часть разработчиков имеет настолько мало свободного места, что предпочитает работать на общих серверах, не предназначенных для этого, значительно их нагружая. Самое смешное, что разработчик за день может заработать на диск большого объема и на годы вперед закрыть для себя этот вопрос, но заработать - это одно, а потратить - совсем другое дело.
aborouhin
Я бы разделил тут две вещи - хранение работодателем (если разработчик не фрилансер, а где-то в штате трудится) и хранение самим разработчиком. Для страховки от возможных проблем, как бы и где бы там ни хранил код работодатель, жизненно необходимо иметь и собственный архив, который останется с тобой, даже если завтра тебя уволят одним днём (служба безопасности - молчать :)
Ну и да, я ещё понял бы страдания операторов видеомонтажа по поводу стоимости необходимого для всех проектов места... но пару Тб хоть под столом дома, хоть в облаке (лучше, конечно, и там, и там) по нынешним временам - не те деньги, ради которых стóит идти на риски и компромиссы.
eee94
Хранение кода (юридическим лицом и, тем более, на личном оборудовании разработчика) после истечения срока действия договора - вполне себе нарушение прав на код. Не говоря о возможных претензиях "вы использовали наш код" для получения выгоды и/или нанесения ущерба (бывшему) клиенту.
aborouhin
Может быть и нарушением, если об этом, опять же, не подумали на стадии составления договора и не предусмотрели.
Но даже если это будет формальным нарушением - я лично предпочёл бы нарушить, но иметь страховку от неожиданно возникших через пару лет претензий "а Вы в своём коде нарушили авторские права ООО Ромашка, мы вынуждены были ему заплатить компенсацию многоденег", "а Вы допустили ошибку, которая положила всю нашу систему и нанесла ущерба на многоденег" и даже "а Вы туда закладку встроили, а мы стратегическое предприятие, пройдёмте со мной, товарищ".
Поверьте, в ситуации, когда одна сторона показывает код, экспертное заключение, акт приёмки выполненных работ по написанию этого кода, а другая голословно возражает "а я совсем не это написал", но не может представить альтернативной версии, - реальный (а не сферический в вакууме) судья вполне может вынести решение в логике "нет оснований не доверять... ответчик не представил доказательств в обоснование своих возражений".
В этом плане, кстати, недурно бы вообще приёмку работ по договору оформлять как передачу подписанного ЭЦП архива или что-то подобное...
SerjV
И самое правильное. И даже оговорить в договоре, что возможность верификации сторонами кода по подписи и/или контрольной сумме является необходимым условием для предъявления претензий с обоснованием причины. А то мало ли какие там изменения были внесены потом умышленно или случайно...
aborouhin
Так да. Про возможные проблемы надо думать на стадии заключения договора, чтобы потом не пришлось про них думать в суде. И относиться при этом к договору как к алгоритму, в котором все возможные сценарии развития событий должны быть предусмотрены и разумно урегулированы.
А у нас как обычно? В худшем случае стянут типовой договор с интернета, "чтобы был", который вообще не очень соответствует ситуации. В лучшем - наймут юриста, который "я в этих ваших айтишных вопросах ничего не понимаю", в итоге нальёт в договор массу ненужной воды, а сутевые вопросы останутся неурегулированными.
SerjV
Вот всё именно так, да. Зачем этот учёт рисков - на него же время надо тратит, причём сейчас, а проблемы может быть и не возникнут, а если и возникнут, то потом...
mshewzov Автор
Вы знаете, не хочу никого из товарищей разработчиков обижать, но эту опцию - с контрольной суммой в акте при передаче кода - я пытаюсь внедрить уже лет 5, наверное. И самое смешное, что именно разработчики в первую очередь отказываются от её внедрения. А ведь это такое благо! ПО можно передавать даже не на дисках или флэшках, а через облако, если прописать переданные файлы и их контрольные суммы. Но почему-то никому это не нравится. Все считают, что акт раздуется до невероятных размеров (и это да), но ведь можно запихнуть всё в архив и прописать контрольную сумму по SHA256 только его.
mayorovp
А хеш коммита в git чем не контрольная сумма?
Разработчики отказываются его называть или вы отказываетесь его принимать?
mshewzov Автор
А разве коммит - это не что-то типа как результат diff? Получается, что хэш коммита не равно хэш файла, где эти изменения произошли.
Stanislavvv
Скорее, результат от NNN diff от пустого репозитория. С практической точки зрения от хеша архива не отличается, но зато имеется история изменений.
SerjV
Тут сложнее. Если у вас клон репозитория - то хэш коммита у всех, у кого эти этот репозиторий, даст файлы в этом коммите в одном и том же состоянии всем, у кого есть репозиторий. И позволит определить отличия любых файлов между двумя коммитами.
Но если вы вытащили файлы из репозитория и залили их в новый чистый репозиторий - то хэши коммитов не совпадут даже если сами файлы в двух разных репозиториях совпадут.
Так что определить, в каком файле случились отличия - можно.
Но сопоставление предоставленного сторонами кода по списку файлов с контрольными суммами, зафиксированными в акте, сработает даже в случае, если обе стороны потеряли копии репозиториев и есть только предъявленные суду одной из сторон файлы.
mshewzov Автор
Вот и ответ на мой вопрос. Получается хэши коммитов привязаны к репозиторию и в общем-то не выполняют ту самую функцию идентификации файлов, которая нужна. То есть вне GitHub они попросту бесполезны.
SerjV
Выполняют, но при условии депонирования где-то репозитория. Не обязательно в гитхабе - можно и на диск записать. Но если репозиторий утерян всеми сторонами - идентифицировать файлы не получится.
mshewzov Автор
Погодите. Вот такой сценарий если. Клонируем репозиторий из GitHub, потом репозиторий на GitHub удаляем, а локальный репозиторий загружаем в другой git-репозиторий, созданный на GitLab, например, или на арендованном сервере в том же Яндекс.Облаке. И вот вопрос - что с хэшами коммитов происходит?
mayorovp
Ничего не произойдёт, они останутся теми же. Можно кстати без локального, у GitLab есть опция клонировать удалённый репозиторий напрямую.
SerjV
не изменятся (если специально чего-то не делать).
А вот если из текущего состояния рабочей директории загрузить файлы в новую чистую созданную с нуля репу - то несмотря на совпадение файлов в коммитах, хэши у коммитов будут разными.
Потому идентифицировать файлы можно только до тех пор, пока где-то депонирована копия репозитория и её заинтересованная сторона сможет предъявить суду.
mayorovp
Коммит выглядит как результат diff только в интерфейсе пользователя, а реально он состоит из снимка репозитория и метаинформации. И его хеш считается именно на их основе.
Aldrog
Пожалуй, самое корректное описание.
Соответственно, идентифицировать конкретное состояние кода он перестаёт только при утере метаинформации (директории .git).
Склонированный репозиторий, куда его ни копируй, и на какие сервера не перезаливай, позволяет проверять соответствие состояний через сравнение хэшей коммитов, а вот скачанный с GitHub через "Download ZIP" уже нет, потому что так скачивается только снимок без метаинформации.
vikarti
Возможно разработчики считают что он не указывает однозначно на то что поставляется?
Опции сборки и прочее.
Пример из нашего проекта.
А конкретно — клиентского мобильного приложения сложной системы.
В зависимости от build variant которым собираются apk а также выбранного сервера (в некоторых build variant меню выбора сервера нет и жестко зашит прод), целевого стора (у Huawei же нет GMS и сборку надо делать с HMS) могут быть особенности поведения из-за обфускации (обычно сборки без нее но релизы с ней), из-за того прод это или не прод (некоторые вещи пришлось делать только для продового сервера потому что с одной стороны безопасность а с другой стороны — разработчикам именно эти вещи и надо делать)
Ах да, куча функционала вообще включается(и выключается!) удаленно с бека.
Aldrog
Обсуждалась передача исходного кода. Если результатом работы по контракту должен быть не код, а собранная программа или библиотека, тогда, конечно, хеш коммита плохо подходит для идентификации.
Darth_Biomech
Всегда было интересно, что это за программы которые чистым кодом весят по 10 гб.
PuerteMuerte
У меня нет ни одного проекта из тех, которые ещё находятся в эксплуатации, по которым когда-никогда не возникает новых задач, даже после годичного перерыва.
Metotron0
Я фронтендер, мне проект склонировать — меньше полуминуты времени. Потом нужно node_modules выкачать, это ещё минута. Так что, нет проблемы в том, чтобы через месяц снова себе его скачать, поработать, и опять удалить.
saboteur_kiev
а причем тут гит?
Постоянно натыкаюсь, что люди давно уже перестали отличать систему контроля версий от системы код ревью
Wrench_IT
В 99% случаев GitHub используется в качестве площадки для резервного копирования кода и удаленного взаимодействия между разработчиками. То есть, если вы видите некий проект на GitHub, это значит, что весь код также присутствует по крайней мере на одном локальном компьютере.
Да, де факто GitHub предоставляет веб-редактор и теоретически можно работать с проектом, вообще не выгружая его на локальную машину, но на практике это актуально разве что для личного блога на GitHub Pages, поскольку в данном случае GitHub предоставляет систему сборки и хостинг, вы редактируете код онлайн и сразу видите результат. Но это, пожалуй, единственная ситуация, когда код может храниться только на GitHub (да и то адекватный разработчик сделает бэкап проекта).
mshewzov Автор
Ну, тут я не спорю. В данном случае нас не интересовало наличие локальной копии, потому что нам её просто не давали. А заинтересовало то, что есть копия на серверах GitHub. И этой копии там по закону быть не должно.
powerman
Честно говоря, во всей этой истории я лично не могу понять только одно: как именно может быть одновременно "нам код не давали" и "код лежит на гитхабе и доступен для изучения экспертами". Если код на гитхабе, и не в приватном репо (раз эксперты до него добрались), то что мешало заказчику взять этот код с гитхаба самостоятельно?
mshewzov Автор
Сложный вопрос, на который я не могу ответить, т.к. я тогда в первом судебном деле не участвовал. Но судя по заключению экспертизы разработчик давал экспертам (трём, на минуточку) доступы к приватным репозиториям (там их было три - код под Android, под iOS и серверная платформа). Во всех заключениях присутствует одна и та же фраза: "На исследование был предоставлен удаленный доступ к репозиториям разработанного программного обеспечения со следующими параметрами..." и дальше адреса репозиториев. Сам разработчик в суде заявлял о приватных репозиториях, о доступе только по приглашению и так далее. И вроде бы даже клиент присутствовал при осмотре репозиториев через видеосвязь, но сам доступ к ним разработчик ему никогда не давал, а письма - игнорировал.
aamonster
Знаете, зря вы полезли в эту область, не разобравшись хотя бы в основах.
Вкратце: у любого, кто сделал git clone (первое действие для получения доступа к исходникам) образуется копия репозитория – со всей историей изменений.
Вам с клиентом очень повезло, что ваше незнание не испортило всё.
mshewzov Автор
Я вот не пойму, все меня обвиняют в незнании основ. Но я основы знаю. Только как мне это тут поможет? Мой клиент (заказчик) не получал доступ к репозиторию. Не получал, а значит и не делал git clone, а значит у него и не образовалась копия репозитория. У меня и самого есть ряд копий репозиториев на локальном компьютере. По-моему я даже MPC плеер скачивал после его реинкарнации новым разработчиком. Я понимаю, что это такое. Но не было ничего подобного. Никто и ничего не скачивал. Разработчик клялся, что создал аккаунт для моего клиента и якобы передал логин и пароль ему и вроде как будто бы даже доступ к репозиторию выдавал на этот аккаунт. Да только мой клиент ничего не получал - ни логина, ни пароля, ничего. А разработчик не смог доказать ни факт передачи логина и пароля, ни факт передачи кода, ни факт предоставления доступа к закрытому репозиторию. Так что мои знания о работе GIT вообще тут не пригодились. Зато все сразу как накинулись, что я, мол, не знаю основ. Ох, пусть даже так. Вот разработчик видимо знал основы. Помогло?
developer7
Так если он не доказал что код передал. Тогда получается что заказчик код не получал. И соответственно никаких прав эксклюзивных тоже не получал.
Почему тогда суд решил что получил? Всё выглядит как — исполнитель не выполнил заказ.
mshewzov Автор
Исключительные права на код - это одна история, а сам код - это другая история. По закону права не привязаны к материальному носителю произведения, в данном случае ПО. Получается, что после признания факта приёмки работ (хоть и без передачи кода) исключительные права перешли к заказчику, но код остался у разработчика.
Если провести аналогию с недвижимостью, то это как если зарегистрировать куплю-продажу в Росреестре и получить права собственности на дом, но по приезду обнаружить, что старые владельцы из дома не очень-то и планируют выезжать.
PereslavlFoto
Приёмка работ без передачи кода?
То есть заказчик подписал акт на неизвестно что?
Цырк не гасит огни!
mshewzov Автор
Заказчик акт не подписывал. Исполнитель отправил заказчику акт по электронной почте. Заказчик или не заметил, или я не знаю, что произошло, но он на него ничего не ответил. Прошло 5 дней и по условиям договора при отсутствии ответа на акт работы считаются принятыми. Иными словами работы считаются принятыми сугубо по формальному основанию. Фактической сдачи-приёмки работ не происходило, и программный код никто не передавал.
developer7
А не является ли условие "при отсутствии ответа на акт работы считаются принятыми. " превращающий договор в ничтожный?
Ведь получается что исполнитель мог ничего не отправлять, и заказчик соответственно не мог ответить. И потом бац! Заказ выполнен идите все лесом.
mshewzov Автор
К сожалению, нет. Это распространённая практика. И закону она соответствует. Это направлено на то, чтобы со стороны заказчика тоже было добросовестное поведение. Иначе исполнитель может выполнить работы, отправить их на приёмку и ждать с моря погоды. В данном случае это сыграло против заказчика.
developer7
Ну если в суде показать полный абсурд ситуации, то суд это не примет во внимание? Как тогда вообще что то доказывать если не работает элементарная логика?
PuerteMuerte
Так а что тут абсурдного? Возник какой-то конфликт, подробности которого мы не знаем, и не можем судить, кто там прав, кто виноват. Но в итоге стороны совместно работать не смогли, и одна из сторон, с помощью юристов, докопалась до нарушений условий контракта, на которые вторая сторона забила ввиду некомпетентности или недальновидности (юристов-то и там можно было нанять и сыграть на опережение). Судебное разрешение хозяйственного спора, это не про то, как надо конструктивно разойтись бизнесменам (потому что к моменту его начала они уже могли успеть разойтись по-всякому), а про то, кто меньше дыр в своей позиции допустил.
developer7
Я уже отвечал на этот вопрос. Абсурдна не сама ситуация. Она типична. Абсурдны выводы суда. А абсурдны они потому как не логичны. По крайней мере той логики которая обсуждается в комментах.
PuerteMuerte
Все равно не понимаю. Для меня выводы суда вполне логичны. Контрагент А нарушил вот такие условия контракта, значит, контрагент А оплачивает банкет. Повторюсь, перед хозяйственным судом не стоит задача найти справедливость. У него стоит задача наказать ответчика за то, что его не любит истец. Наказать на основе претензий, которые выдвинули юристы истца, покопавшись в документах. А задача ответчика не донести до суда, что дескать причина конфликта была в другом, а всего лишь донести, что вот эти конкретные претензии — фигня.
developer7
Абсурд в следующем.
Ты едешь на машине. Видишь гаишника он тебе приказывает остановится, ты останавливаешься. А он тебе — оп-па, тут разметка, остановка запрещена, платите штраф.
В нашем же случае, ответчик предъявил суду коды для анализа. А суд его за это наказывает. Мол ответчик никуда не имел право копировать код, потому как это нарушает эксклюзивную лицензию.
Тогда как ответчик вообще мог себя в суде защитить?
SerjV
Можно же и еще дальше пойти...
Доказательства, полученные с нарушением закона, не должны приниматься судом во внимание - а потому после вступления в законную силу решения по второму делу, - можно попросить пересмотр дела по первому проигранному делу "в связи с вновь открывшимися обстоятельствами".
А что ему в том первом суде вообще доказать надо было?..
developer7
В этом как раз и весь сыр-бор. Первое дело вообще какое то непонятное. Вообще всё указывает что исполнитель не выполнил договор, и вся дальнейшая история должна плясать по этому направлению.
Но вдруг оказывается что исполнитель выполнил договор, но при этом не предоставил код заказчику. Это реально нелепо выглядит.
SerjV
Предыдущий суд решил, что договор выполнен на 75%. У суда не нашлось оснований не доверять решению предыдущего суда, более того, он вряд ли смог бы им не доверять даже если бы очень захотел, т.к. "сторонам запрещено оспаривать не только факты, но и правоотношения, установленные судом по ранее рассмотренному делу между теми же лицами."
developer7
Ну так и эксклюзивные права переданы на 75% Такой же уровень аргументации как у суда)))
Заказчик не дописал 25% кода — и соответственно не смог передать все 100% эксклюзивных прав )))
SerjV
Вот если напишет остальные 25% кода - вот на те 25% кода и будет иметь права.
А на то, что уже написал - права лишился. Как он будет использовать 25% кода без остальных 75% - никого не волнует :)))))
PuerteMuerte
А это неверная аналогия. Если продолжать с гаишниками, то приезжает гаишник на ДТП, в котором обе стороны обвиняют друг друга. Одна из сторон говорит: да я в принципе не виноват, он выскочил на красный, вот смотрите, я даже после того, как уехал с места ДТП, вернулся на то же самое место, чтобы стать как было. И что делает гаишник? Правильно, "О-па, вы уехали с места ДТП? Вот за это мы вас и оштрафуем".
Так же, как и истец — юристов нанять, чтобы они общались между собой, а не самому, в неравных весовых категориях, отвечать на вопросы юристов своего контрагента.
developer7
Оно то понятно, что исполнитель максимально себя закопал, а надо было просто ничего не делать и ничего не показывать. Раз каким то боком было принято решение что код был уже передан.
Вся дискуссия идёт из того, как натянули исполнителя во 2 суде. А натянули его мягко говоря бредово. Потому как если реально так натягивать — то можно наверно иск предъявить всем на всех.
PereslavlFoto
Ох, ох, это распространённый миф… Ведь хороших юристов может нанять только богатый, который станет ещё богаче по результатам их работы. А бедный (и бедная фирма) не может нанять хороших юристов, поэтому станет ещё беднее. Вообще, это очень тяжёлая проблема всех юридических дел.
PuerteMuerte
Я вряд ли ошибусь, если скажу, что большинство мелких ИТ-контор сможет этак на порядок повысить свои шансы выигрыша судебных дел, просто если наймёт обычного юриста.
PereslavlFoto
… При прежнем размере фонда оплаты труда, сиречь за счёт других сотрудников.
PuerteMuerte
Простите, но это невозможно. Зарплаты/премии сотрудников фиксированы и изменяться в меньшую сторону не могут без перечисленных в ТК оснований. А ФОТ, наоборот, никаких особых ограничений к увеличению не имеет, кроме желания/нежелания руководства компании (ну и её финансовых возможностей, конечно). Но естественно, к данной ситуации отношения не имеет, т.к. юриста на сопровождение дела наймут не в штат, а просто обратятся за юридическими услугами к профильному специалисту-ИП или организации.
PereslavlFoto
Если юрист работает в другой фирме, ему надо платить деньгами. Но если зарплаты останутся прежними, откуда же взять деньги на юриста? Из чьего кармана появятся эти деньги?
PuerteMuerte
Не совсем понимаю ваш вопрос. Откуда вообще деньги берутся у компании или у людей? Они их зарабатывают.
У любой организации любого размера есть масса статей расходов, не только на ФОТ, ну добавится к ним ещё одна небольшая, юридические консультации — это не существенно, никто и не заметит.
PereslavlFoto
У бедной компании не хватит на юриста. Придётся отнимать у сотрудников.
И все эти расходы отнимают из премиального фонда.
За небольшие деньги юрист работать не будет. Ему придётся каждый месяц платить по 30 тысяч рублей, не меньше.
PuerteMuerte
Блин :)
Смотрите, я работаю в крохотной, бедной ИТ-компании. У нас средние зарплаты по рынку, штат в десять тел. У нас месячный доход — примерно 4 млн рублей. И это совершенно типовой уровень доходов для бедных ИТ-компаний. Вы вот правда думаете, что чтобы выделить из 4 млн 30К на юриста на пару месяцев, нам надо их у программистов отобрать, что ли?
mshewzov Автор
Любой ИТ-юрист когда-то был обычным юристом, в том числе и я. У нас нигде на них не учат. Так что да, шансы станут на порядок больше, а обычный юрист получит шанс прокачаться до ИТ-юриста.
vikarti
А вот кстати как юридически в таких случаях решается вопрос с тем что акт был отправлен?
Верим отправителю?
Я в том контексте что есть спам-фильтрация, есть кривые настройки серверов с админами-идиотами (при попытке все же выяснить в чем дело — можно получить ответ, что у них есть Документ что надо настраивать вот именно так а на последствия им плевать — случаи вроде https://habr.com/ru/articles/662555/ или например слишком активное использование RBL).
Нет, понятно что если у отправителя почта на своем сервере — он может и логи показать но даже так:
SerjV
Отправляют по СЭД или заказным письмом с уведомлением. Или приносят в секретариат и получают отметку на своём экземпляре. Ну, это если стороны думают над тем, что подписывают...
mshewzov Автор
Если речь идёт об отправке акта по электронной почте, то, во-первых, оценивается, указана ли была эта электронная почта, и сама возможность обмена актами через неё, в самом договоре, а во-вторых - одна сторона приносит скриншоты переписки и говорит, что акты направляла, а другая сторона тоже молчать не должна - она либо подтвердит это (или промолчит, что равнозначно подтверждению), либо опровергнет, например, своими скриншотами, что ничего не приходило. Иногда осмотр электронной почты производится прямо в судебном заседании. А если есть подозрения, что письмо было удалено, то можно и к оператору почтового сервиса сделать запрос.
aamonster
Ну так вы рассказываете, что он код не передал – при этом, я так понимаю, есть акт приёма-передачи (пусть даже в силу ошибки заказчика) и эксперты получили доступ к коду – т.е. и фактически он передан.
Раздражает, что вы ссылаетесь на какую-то не относящуюся к делу вещь и при этом совершаете бросающиеся в глаза ошибки. Можно ж было просто не ссылаться на это, всё равно для решения суда это несущественно?
mshewzov Автор
В акте приёма-передачи написано так "Работы по разработке приложения согласно договора такого-то". Акт отправили на почту заказчика, а он не написал в ответ отказ от приёмки, что автоматически спустя 5 дней сделал приёмку состоявшейся. Формально. Но по факту ничего никто не передавал. И суд это отразил в решении.
Эксперты получили доступ к коду, потому что его им дал разработчик. А заказчику он такие доступы не дал.
Давайте тут поподробнее. Сначала Вы меня обвинили в незнании основ GIT, а теперь в том, что я совершаю бросающиеся в глаза ошибки. Может ошибки и есть, я ж тоже человек, да только Вы о них как-то абстрактно сейчас заявили. В чём конкретно я ошибся?
developer7
Да тут как я понял какая то околесица произошла. Экспертам код предоставил, передал логин к GitHab, исполнитель уже во время суда. И вроде как до суда уже как бы код был передан заказчику и принадлежал ему. При этом у заказчика кода не было.
Зачем исполнитель предоставил доступ экспертам на свой GitHab? Мог бы послать с чистой совестью. Мол код передал — ничего не знаю.
И вот к этому уже придрались во 2 суде. Типо исполнитель разместил не принадлежащий ему код на GitHab.
Как по мне история выглядит максимально мутно.
PuerteMuerte
С моей точки зрения, история выглядит как раз максимально прозрачно. Исполнитель по каким-то причинам решил разорвать проект с заказчиком, не суть важно, или по токсичности оного, или по причине собственного непрофессионализма, видя, что проект "не тянет". При этом с юридической точки зрения исполнитель сделал всё, чтобы разорвать контракт максимально неудобным для себя способом — с одной стороны, вконец разосравшись с заказчиком (извините за мой французский деловой жаргон), с другой, не имея никаких подтверждений о передаче производных материалов (да блин, хотя бы емейлом отправили бы), с третьей, не изучив подробно условий собственного же договора, и как его надо было выполнять.
Ну и огрёб по-полной за первую же найденную зацепку.
developer7
Мутно не потому что исполнитель захотел кинуть заказчика (или заказчик захотел исполнителя раба), это то обыденность.
Мутно как вся эта история выглядит в суде.
mshewzov Автор
Ну, в суде она выглядит так, как нам удалось это доказать, а разработчику не удалось это опровергнуть и доказать свои утверждения.
mshewzov Автор
Надо помнить, что права на код могут гулять по правообладателям совершенно независимо от самого кода. Это касается любого произведения, не только ПО. Та же картина де-факто может висеть в одной галерее, а исключительные права на неё могут переходить сколько угодно кому угодно.
Исполнитель по-хорошему должен был передать код заказчику, а потом уже заказчик должен был по требованию суда передать код на экспертизу. Однако, исполнитель передал только права на код (сам того не подозревая), а сам код - нет.
SerjV
Акт приёма-передачи чего именно? С материальными результатами работ проще, а тут результат делится на две части - исключительное право и собственно коды, представленные в объективной форме.
По акту выполненных работ "формально принятому" исполнителем, право было передано заказчику, коды фактически не были переданы. Если бы речь шла об "обычных" результатах работы (там, мебель изготовить, например), такого разделения просто бы не было - табурет или передан, или не передан, заказчику.
developer7
Исключительное право на неизвестный код — как по мне юридически ничтожная формулировка, или как там юриспруденции это называется.
Нельзя передать права на код. Стать полноценным владельцем прав, но при этом не получить кода.
Права дают право (тавтология) защищать код, не давать его копировать другим. Но как можно защищать того что нет.
Короче как не посмотри со всех сторон бред. Не может быть права без предмета на которое это право ссылается.
И пример с правом владения на дом тут совершенно не подходит. Нельзя владеть правом на неизвестный дом.
Но как я посмотрю в судах всё бывает.
SerjV
Ну почему же нельзя? Очень даже можно, причём исключительное право может перейти заказчику вообще с момента создания исполнителем кода. Вот то есть он его еще только пишет, а право на этот код уже у заказчика.
Так что претензии тут не к суду надо обращать, а к самому институту интеллектуальной собственности, в котором принадлежность права не связана с принадлежностью воплощения оной в объективной форме.
developer7
Если код пишет наёмный работник — то можно прописать в контракте мол всё что пишет работник с 8 до 6 всё принадлежит работодателю. В особо извращённых случаях можно конечно заиметь раба и прописать в договоре всё что пишет работник с 0 до 24 часов всё принадлежит работодателю.
Когда дело имеешь по контракту со стороннем исполнителем, мне трудно представить себе контракт с условиями что всё что пишет исполняющая сторона принадлежит заказчику.
По этому совершенно нельзя определить какой код пишет в данный момент времени исполнитель. Твой или для себя или вообще параллельный заказ.
И определить код который принадлежит заказчику и на который передаются заказчику исключительные права можно только в момент подписания договора об исполнении работ с ОДНОВРЕМЕННОЙ передачей кода.
В нормальном виде код можно заранее передать на согласование, а уже когда подписываешь акт выполненных работ, указываешь список файлов, хеш суммы, короче максимально конкретизируешь на что именно передаются права.
Права на "коня в вакууме" как я писал выше не имею смысла, а значит юридически ничтожны.
SerjV
Тут верно, определить "что это за код" - проблемно... Но ответчик решил эту проблему за заказчика, подтвердив, что да, это тот самый код.
Претензии просьба предъявлять в Госдуму, т.к. изложенное представление о правильном расходится с тем, что они понаписали.
Мне тоже многое в действующем законодательства многое не нравится. Например, легальная возможность отжать домен через регистрацию товарного знака.
mshewzov Автор
Тут претензии даже не в Госдуму, т.к. наше законодательство опирается на международные конвенции по интеллектуальной собственности, а там по сути плюс-минус то же самое.
На самом деле у разработчика в нашем деле были возможности для противодействия, которыми он не воспользовался. Но это будет на вине его юриста. В первой инстанции его интересы ещё представлял юрист, а уже в апелляции - был сам директор. Видимо юриста послали.
Вопрос идентификации кода, конечно, всегда стоит. Однако, как наше законодательство, так и международное идентифицирует конкретные произведения по... названию. Т.е. юридически верно зафиксировать в договоре конкретное название ПО и описать какие права кому переходят. И всё.
SerjV
:) Естественно не в Госдуму, но я тоже иногда упрощаю.
Ну, поскольку авторство не оспаривалось - то вопрос идентификации можно было и не затрагивать в данном конкретном споре.
mshewzov Автор
Да, он и не затрагивался. В этом плане нам помогло решение по первому спору.
inscriptios
Вам ведь говорят совсем про другое и никто ни в чем не обвиняет (это не судебный процесс). Вы просто написали следующее:
Часто все начинается именно с локального репозитория, то есть это не так, что у вас код только в облаке. В облаке он нужен для совместной работы и других операций. А то что вам это поможет или не поможет в конкретном деле против конкретного разработчика, не имеет к этому никакого отношения, речь про ваше конкретное утверждение о бэкапах.
Кстати:
"Во-первых" исключает "во-вторых" в той мере, в которой это прописано в соглашении с заказчиком.
Ну, и это:
Вам необходимо сделать примечание, что речь идет про использование https://github.com/, потому что еще есть GitHub Enterprise Server, который позволяет хостить код на своем сервере.
mshewzov Автор
Тут согласен. Я попытался объяснить юридические риски именно облачного хранения на GitHub. То, что код где-то хранится и локально, в данном контексте совершенно не важно.
Мне так не показалось. Всё-таки "во-первых" предполагает использование GitHub до передачи кода заказчику. А "во-вторых" касается удаления кода с GitHub уже после сдачи работы заказчику.
Вот это верное замечание. Сделаю корректировку.
vikarti
А в чем проблема передать этот логин и пароль просто еще раз? Прям в суде.
Или заказчику было уже это не интересно?
mshewzov Автор
Проблем в этом нет. Логин мы видели, пароль правда - нет. Но есть ли в этом смысл? 2 года спустя этот код просто устарел безнадёжно.