О где ты же ты, код?!
1. Юристы – настоящие супермены, новаторы и визионеры, когда речь идёт о лигалтех, юридических конференциях, after-party после них и встречах с HRом, сулящих повышением зарплаты. А вот если копнешь в результаты базовой юридической работы, которые генерируют реальные риски для бизнеса, у нас часто оказывается всё по принципу «я вообще-то котик, у меня лапки».
Короче, ярмарка тщеславия, лень и нищета экспертности – I’m loving it.
2. Часто работаю с договорами на создание ПО, в том числе критически значимого и на существенные суммы. Такие договоры базово предполагают отчуждение исключительного права на созданное ПО заказчику (скучная юридическая справка – по ст. 1296 ГК РФ договор заказа на создание ПО в базе предполагает переход исключительного права к заказчику, если стороны не договорились по-другому). То есть писать это ещё раз в договоре не надо.
Но юристы всё равно пишут. Что-то вроде:
Заказчику принадлежит исключительное право на Интеллектуальную собственность в полном объеме в отношении использования Интеллектуальной собственности любым способом и в любой форме на территории всего мира, в течение всего срока действия исключительных прав, с правом их передачи полностью или частично, в том числе с правом выдачи лицензий любым лицам на условиях, определяемых по собственному усмотрению Заказчика и без выплаты Подрядчику какого-либо дополнительного вознаграждения
Ай юрист красавчик – написал, теперь можно идти светить лицом на конференции по смарт-контрактам для будущего работодателя/клиента.
На всякий случай - не надо записывать эту формулировку. Она не оптимальна. Я просто скопировал её из первого попавшегося под руку договора - она вообще не нужна, поэтому зачем мне её сейчас делать лучше или хуже.
3. А вот про исходный код создаваемого на заказ ПО юристы очень часто забывают. И вот это действительно важно и можно записать:
Проблема: Ни законодательство РФ, ни судебная практика РФ не отвечают однозначно на вопрос: должен ли исполнитель вместе с исключительным правом на само ПО передавать заказчику исходный код этого ПО?
Риск: заказчик может остаться с весьма абстрактным исключительным правом на ПО, но без исходного кода и, соответственно, с весьма ограниченными возможностями по поддержке, доработке и обновлению такого ПО.
Вывод: критически важно предусматривать в договорах на создание ПО условие о передаче исполнителем заказчику исходного кода.
Решение: включить в договор минимально достаточное положение «Исполнитель обязуется передать Заказчику исходный код ПО».
4. Юрист такой: «Смотри как всё круто, любимый глубокоуважаемык клиент. Юрист сделал свою работу, теперь юрист может ехать в Турцию на твои деньги?»
Работодатель такой: «Ну нет. Пока ещё нет, пока ещё не время для плохих бесплатных коктейлей, мой беспечный алчный друг».
Тогда юрист: «Ну почему???почему??? ты, злой жадный мелочный человечишко»
5. Всё просто. Раз законодательство РФ и судебная практика не отвечают на вопрос, а должен ли исполнитель передать исходный код ПО, то и законодательству, и судебной практике абсолютно всё равно, каким образом и в каком виде и качестве исходный код будет передан.
То есть, если исполнитель, выполняя свое обязательство «передать Заказчику исходный код ПО», передаст заказчику обфусцированный код без документации, то с точки зрения российского суда он сделает всё правильно. И суду абсолютно не важно, что такой вот исходный код – что он есть, что его нет. И это не высосанный из пальца риск – я видел такое уже много раз, в том числе у лучших юридических IT-команд самых крупных представителей рынка.
6. Что делать?
Предусматривать требования к передаваемому исходному коду.
Какие они должны быть?
Вот здесь у меня нет однозначного ответа. Есть только ряд идей и наработок, которыми я хочу поделиться, получить обратную связь и попытаться выработать что-то вроде мягкого стандарта таких требований для всеобщей пользы.
7. За время своей практики я собрал следующий набор требований к исходному коду.
Этот набор составлен из самых разных источников: тексты классических открытых лицензий, типовые тексты контрактов (например, Приказ Минцифры России от 17.12.2020 N 715); отдельные удачные примеры контрактов крупных игроков рынка; обсуждения с stackexchange.
Отдаю себе отчёт, что это пока ещё достаточно отрывочный, сырой и не финализированный набор, поэтому на условиях AS IS и WAIVER OF LIABILITY, но надеясь на вклад со стороны сообщества:
1. Требования к комплекту передачи исходного кода ПО:
1.1 Исходный код
1.2 Объектный код
1.3 Файлы конфигурации
1.4 Документация
2. Требования к исходному коду ПО:
2.1 Язык программирования: Исходный код ПО должен быть написан на языке программирования: __;
2.2. Запрет обфускации: Исходный код ПО не должен быть намеренно запутан (обфусцирован). Не допускается предоставление промежуточных форм исходного кода ПО, таких как выходные данные препроцессора или транслятора;
2.3. Требования к нотации и оформлению исходного кода ПО:
- исходный код должен быть оформлен в единой системе нотации используемого языка программирования;
- должны использоваться единые правила расстановки элементов синтаксиса блоков, функций, циклов и прочих элементов, а также пробелов, переносов строк и расставления пустых строк;
- должны использоваться единые правила именования констант, переменных и функций, в том числе и расстановка заглавных и строчных символов;
- не допускается использование строковых и числовых значений непосредственно в исходном коде, они должны быть вынесены в константы;
3. Общие требования к Документации:
3.1. документация должны быть предоставлена в форме комментариев в исходном коде ПО;
3.2. должны быть использованы общепринятые нотации по документированию, позволяющие автоматически генерировать файл документации;
4. Требования к документации исходного кода ПО:
4.1. должны быть задокументированы объявления типов составных объектов (классов, структур), описаны назначения атрибутов и методов таких объектов;
4.2. должны присутствовать описания локальных и глобальных переменных;
4.3. должны присутствовать описания функций, их параметров и возвращаемых значений;
4.4. должны присутствовать описания условий ветвления, циклов и переходов;
4.5. должны присутствовать описания методов и данных, экспортируемых из программного модуля для использования другими модулями кода и внешними системами;
4.6. для кода на объектно-ориентированных языках программирования должны быть приложены UML диаграммы классов в одном из видов: графический файл, UML диаграмма Microsoft Visio, UML диаграмма Sybase PowerDesigner;
4.7. должны присутствовать логи системы отслеживания ошибок и информация о такой системе;
5. Требования к документации по среде разработки и сборки:
5.1. Исходный код должен быть предоставлен в форме, готовой к открытию в следующей среде разработки (Integrated Development Environment — IDE): __;
ИЛИ
Исполнитель обязан предоставить Заказчику в составе Документации список используемых для сборки сред разработки;
5.2. должны быть представлены все необходимые для сборки и запуска ПО библиотеки зависимостей, инструкции, программные сценарии (скрипты), средства отладки, компоненты, эмуляторы внешних систем/компонентов, необходимые для проведения компиляции, создания дистрибутива и установки (развертывания) ПО;
ИЛИ
должен быть представлен список необходимых для сборки и запуска ПО библиотек зависимостей, инструкций, программных сценариев (скрипты), средств отладки, компонентов, эмуляторов внешних систем/компонентов, необходимых для проведения компиляции, создания дистрибутива и установки (развертывания) ПО, а также информация о лицензировании, правах использования и правах модификации таких компонентов;
В случае, если какие-либо из этих компонентов не распространяются на условиях бесплатной лицензии или не доступны к платному лицензированию и отсутствуют в свободном доступе, такие компоненты должны быть предоставлены Исполнителем Заказчику в составе комплекта передачи с правом передачи таких компонентов третьим лицам для модификации исходного кода ПО;
5.3. должен быть предоставлен список аппаратных платформ, на которых возможно выполнить сборку и разработку ПО, с указанием их минимальной и максимальной конфигурации;
5.4. должен быть предоставлен список операционных систем и их компонентов, на которых возможно выполнить сборку и разработку, с указанием минимальной и максимальной версии, номера патчей и service pack;
5.5. должны быть описаны настроечные параметры, которые могут влиять на функционирование ПО, полученного путем сборки;
5.6. должен быть подробно описан процесс получения инсталляционного пакета ПО из результатов сборки;
5.7. должна присутствовать подробная информация о процедурах отладки ПО в указанной среде разработки – расстановка точек прерывания, пошаговая обработка команд, просмотр содержимого переменных и областей памяти.
Приглашаю ругать и комментировать. Не знаю, стоит ли выложить текст отдельным файлом в облако?
Комментарий недоступен
о, крутяк. Поищу по другим языкам, почитаю. Не думаю, что они прямо вот сейчас пошли настолько плохо. Я, наоборот, надеюсь, что тренд на вменяемость в бизнесе замещает тренд на "сделаю все на отъе...". Так что, может, это какие-то хвосты более раннего наследия, когда можно было вот так работать, и ты все равно находил заказчиков. Но я лично видел уже столько историй с исходным кодом, что, по крайней мере, риски по своей части стараюсь всегда закрывать заранее