Кому принадлежит написанное ПО юридически

[Jackson]

В нормативной документации конкретного заказчика

То есть в договоре/ТЗ?

[leon78]

То есть в договоре/ТЗ?

РД-35.240.50-КТН-109-17 с Изм.2
5.7.3.1 Прикладное ПО должно быть:
 открытым для модернизации;
 иметь листинги программ;
 сопровождаться описанием на русском языке.

РД-35.240.50-КТН-241-19 ч.1
5.23 Требования к предоставлению поставщиком программного обеспечения исходных кодов ПО
Поставщик предоставляет исходные коды для разрабатываемого прикладного ПО СУ и ВУ МПСА.

[olexsa]

РД-35.240.50-КТН-109-17

РД-35.240.50-КТН-241-19

Это всё документы отраслевые - Транснефть. Соответственно, и требования, указанные в них, применимы для исполнителей, заказчиком у которых выступает Транснефть. И то ведь наверняка все эти требования указываются в ТЗ, проектах, договорах, и тому подобное.

Кто-нибудь может найти какое-то нормативное требование о том, что поставщик ПТК обязан передать заказчику исходники или хотя бы листинги разработанного им софта?

Наверняка подразумевается нормативная документация РФ?

[Jackson]

Это всё документы отраслевые - Транснефть

Об этом и предупредили. Всё в порядке. Выше я описывал свой опыт - это тоже отраслевое. А единого норматива - делаю такой вывод - не существует.
Это ответ автору вопроса в первом посте.

[misha_os]

Все прописывается в договоре и в ТЗ, кто и что делает со сроками и ответственностью сторон: ниокр, тех. требования, разработка РКД и/или ППО, изготовление, испытания, поставка, СМР, ПНР, опытная эксплуатация и т.п., не забывая про внесение изменений после каждого этапа в документацию и ПО. Если в договоре и ТЗ нет конкретного списка разрабатываемой РКД и/или ППО, то см. описания на ГОСТ и др. нормативку в соответствии с которой должно быть разработано РКД и/или ППО, там все описано что разрабатывается в обязательном порядке. Если есть, например, упоминание что разрабатываемая документация и/или ППО должна быть разработана в соответствии с ГОСТ 34.201-89, то для программных продуктов он ссылается на ГОСТ 19.101-77, в соответствии с которым по умолчанию разработчиком предоставляются тексты программ на каждый компонент (а вот в бумажном или электронном виде они поставят, это желательно прописывать Вам в договоре и/или ТЗ).

[Jackson]

ГОСТ 19.101-77, в соответствии с которым по умолчанию разработчиком предоставляются тексты программ на каждый компонент

Выше я это спрашивал. Найдите пожалуйста в ГОСТ 19.101 требование включить в документацию листинг. Я не нашёл.

[misha_os]

См ГОСТ 19.101-77, табл. 4 - Текст программы, код документа - 12.

[Jackson]

А ТрансНефти, кстати, с одной стороны респект и уважуха, а с другой - ограниченный перечень поставщиков, потому как например мы свои ПТК формально им поставить не можем. :)

Отправлено спустя 4 минуты 34 секунды:

См ГОСТ 19.101-77, табл. 4 - Текст программы, код документа - 12.

да, я про это Выше писал. Спасибо, понял.

Отправлено спустя 3 минуты 10 секунд:
Но это только документ. В 1977 году по листингу можно было легко восстановить всё, в 2021 - листинг займёт листов 200-300 и он практически может быть бесполезен для работы. Самих исходников-то нет.

[misha_os]

Да, тут разработчик может формально на бумаге распечатать на 100500 никому не нужных страниц ППО.
Но тогда нужно смотреть и ссылаться на стадии создания и стадии разработки РКД и ППО. Например, в ГОСТ 19.102-77, табл.1 (5. Внедрение). Соответственно ППО (исходники) нужны для сопровождения Заказчиком функционирования (восстановления, внесения изменений и т.п.) АС, после окончания, например, гарантийного срока обслуживания или ввода в эксплуатацию (когда Разработчик больше не принимает участия в сопровождении разработанной АС).

[Jackson]

Например, в ГОСТ 19.102-77, табл.1 (5. Внедрение)

Там чуть ниже

2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

.
То бишь если в явном виде перечислить перечень передаваемой документации и материалов и явно не указать в нём сами исходники - это можно считать "по согласованию с заказчиком" и исходники не передавать. Либо вообще забыть упомянуть эту группу ГОСТ, что сплошь и рядом - с тем же результатом. Так?

[misha_os]

Про этапы сказано, т.к. они там избыточны или иногда Заказчик разбивает этапы на разные лоты (например требуется сделать только стадию ЭП или ТП и т.п.).

А так в договоре и/или ТЗ:
1. Если конкретизировать, то соответственно лучше прописывать все что надо Заказчику в договоре и ТЗ (этапы, сроки, оплата, документация, ППО, в каком виде передается документация и ППО и т.п.).
2. Если без конкретики, соответственно, ссылки на ГОСТ и др. нормативные документы. Соответственно Заказчик (и другие заинтересованные лица) должны будут оперировать этими ГОСТ и нормативными документами, что должно быть разработано, поставлено и т.п.
3. На Ваш вопрос. Если что то конкретизируется, например только разрабатываемая документация РКД и есть ссылка о разработке АС согласно ГОСТ 34.201-89, то соответственно см. что там все остальное делается кроме документации. Т.е. ППО должно быть разработано, отлажено, поставлено и предоставлено.

[petr2off]

Да, там целый раздел по программным документам с разъяснением содержания каждого из них. Так вот в каком из них листинг должен быть?

Приведите свой вариант содержания документов без исходников. Я пытаюсь Вам донести достаточно простую вещь, наверно можно и без исходников обойтись. Но получится дольше и сложнее. потому как потребуется:
1) Описать всю структуру ПО до каждой процедуры. Далее для каждой процедуры:
1) Описать Всех входные и выходные переменные (сигналы)
2) Описать все информационные массивы
3) Для каждой процедуры описать алгоритм (либо в графическом, либо в текстовом виде), который однозначно описывает, как получается результат (выходных переменные/сигналы) Их входных переменных (сигналов) и информационных массивов.
А если учесть, что процедуры могут быть еще и вложенные, то задача получится совсем не тривиальная.
А вот исходный код процедуры (например на FDB) - просто и быстро решает задачу описания ее алгоритма. Хотя все равно придется описывать и ее функциональное назначение, и входные и выходные параметры, и используемые информационные массивы.
Хотя если Вы предложите более быстрый и простой способ, с удовольствием ознакомлюсь.

[misha_os]

Всегда интересовал вопрос. Почему при разработке АСУ ТП, некоторые "разработчики" считают что ППО это "не передаваемая" часть, в части исходников, Заказчику, а РКД, эксплуатационную, ремонтную документацию, док-цию по тех. обслуживанию можно передавать? Если судить по их логике, то это все разработанное (за деньги Заказчика) тех. документация и ППО их собственность, которую они могут и не передавать или передать за еще доп. плату. :)

[Looker]

Приведите свой вариант содержания документов без исходников.

Далее пропущено (но, присоединяюсь): чтобы все описать - куча времени (кто оплатит?). 40 лет назад проходили - куча бумаг, а пользы никакой (Заказчику). Сейчас отдаю все исходники в среде IDE, иногда с паролем в ожидании оплаты. Запись двух CD с исходниками не гарантирует их потерю Заказчиком.

[Rus_Bear]

Написанное ПО или сконфигурированное?
Я вижу чёткую границу когда есть готовое решение в котором вы реализуете свои способности конструктора (т.е. то что выше описано - привязка переменных и т.д.) - тут речи и нет о какой либо интеллектуальной собственности... Собрать в кучку (пусть и для кого-то это и тяжело) это не написать ПО...
Касаемо Транснефти:
1) Ограниченный круг интеграторов - только прошедшие допуск, это не прихоть и не "свои в деле" - множество случаев когда огромные интеграторы (реально крупные компании с миллиардными оборотами) - еле допилив выигранный лот, сливаются (банкроты или ещё чего не владею информацией) - и никакой гарантии и устранения косяков.
2) ПО для АСУ - например шнайдер давно запилил и сделал для интеграторов (и для всех в свободном доступе) код основных типовых блоков для Транснефти, берите бесплатно и используйте в любом проекте.
3) Даже за такое ПО, которое в принципе не разрабатывается интеграторами, а адаптируется и внедряется, платят огромные деньги как за полноценное приложение, не смотря на учтённые в других статьях расходы на ПНР и разработку ПО - это только ПЛК касается.

Есть множество полезных приложений разработанных интеграторами (в т.ч. и касающихся безопасности и унификации ПНР) - за исключением скриптов и макросов - ни разу не видел открытого исходного кода и не слышал о требовании его предоставить.

[VADR]

Написанное ПО или сконфигурированное?
Я вижу чёткую границу когда есть готовое решение в котором вы реализуете свои способности конструктора (т.е. то что выше описано - привязка переменных и т.д.) - тут речи и нет о какой либо интеллектуальной собственности... Собрать в кучку (пусть и для кого-то это и тяжело) это не написать ПО...

Тогда тут несколько "чётких граней":
1. Готовый параметрируемый контроллер, в котором не меняется логика работы, а только назначаются типы входных/выходных сигналов и параметры регуляторов. Разработчик системы параметрирует его на основе ТЗ.
2. Программируемый контроллер, в котором из готовых блоков собирается программа, например, управления распределением воздуха в котлоагрегате. Программа делается на основании подробного ТЗ, то есть вроде как разработчик её не придумал, а только перевёл из языка человеческого в язык контроллера. Готовые блоки с регуляторами различных типов разработаны производителем контроллера.
3. Собственно эти блоки внутри контроллера (различные ПИД-регуляторы и т.п.). Они также написаны на основе чужих трудов: все формулы известны и расписаны в учебниках. То есть - разработчик так же их не придумал, а перевёл с одного языка на другой.
В каком/каких из этих случаев можно говорить об авторском праве разработчика?

Есть множество полезных приложений разработанных интеграторами (в т.ч. и касающихся безопасности и унификации ПНР) - за исключением скриптов и макросов - ни разу не видел открытого исходного кода и не слышал о требовании его предоставить.

Эти полезные приложения в большинстве случаев нужны в процессе внедрения/пусконаладки (позволяют ускорить/упростить большое количество операций), а далее в ходе эксплуатации без них можно и обойтись (доработки систем обычно небольшие). И они не работают непоредственно в управлении объектом. А вот обратный пример (из жизни): при запуске система выдаёт сообщение "не все конвейеры в автоматическом режиме", и оператор идёт пешком обходить кучу конвейеров в поисках того, на котором забыли ключ в автомат перевести. Разработчик упёрся на тему "это наше стандартное решение и менять его мы не будем", договор такие переделки не включает. Нормальный выход - местной экплуатации влезть в систему и отобразить на экране у оператора значки автоматического режима около каждого конвейера. Ну и как тут без исходников?

[Valerich]

Написанное ПО или сконфигурированное?

Если следовать вашей логике, то получается, что ПО сейчас абсолютно никто (включая "классических" программистов) не пишет, только конфигурирует в готовой среде разработки.