О где ты же ты, код?!

О где ты же ты, код?!

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. должна присутствовать подробная информация о процедурах отладки ПО в указанной среде разработки – расстановка точек прерывания, пошаговая обработка команд, просмотр содержимого переменных и областей памяти.

Приглашаю ругать и комментировать. Не знаю, стоит ли выложить текст отдельным файлом в облако?

2 комментария

Комментарий недоступен

1

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