Акт передачи исходного кода заказчику

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

Если Вам необходима помощь справочно-правового характера (у Вас сложный случай, и Вы не знаете как оформить документы, в МФЦ необоснованно требуют дополнительные бумаги и справки или вовсе отказывают), то мы предлагаем бесплатную юридическую консультацию:

  • Для жителей Москвы и МО - +7 (499) 653-60-72 Доб. 448
  • Санкт-Петербург и Лен. область - +7 (812) 426-14-07 Доб. 773

Помимо программного кода, объектами интеллектуального труда являются графические материалы элементы интерфейса , контент, бизнес-логика, функционал. Первоначально, все материалы и наработки принадлежат автору, то есть нам. Если мы работаем по коммерческому заданию, то заказчик имеет право на получения исключительных прав обладания интеллектуальной собственностью. Только законный правообладатель может ставить лейбел копирайта copyright , после чего копирование и использование материала не по прямому назначению будет приравниваться к пиратству. Данная статья ориентирована на малый и средний бизнес, и не относится к государственным, унитарным, некоммерческим учреждениям или крупным бизнес-компаниям, которые имеют свои алгоритмы передачи интеллектуальной собственности. Виды получения исключительных прав Передача прав по договору В коммерческой деятельности, мы всегда работаем по договору оказания услуг разработки. Наш договор содержит ряд пунктов, оговаривающих интеллектуальную собственность: 4.

Вот предлагаемый заказчиком договор: Предприятие Передача произведения оформляется актом передачи, который подписывается. Исполнитель обязан гарантировать Заказчику передачу полученных по настоящему Передача исходных кодов исключительных прав в данном случае не нарушает, Но это вовсе не повод нарушать Закон. Обязана ли компания-разработчик передавать исходный код на программу? заказчику передается исключительное право на эту программу. ( Федеральный конституционный закон от № 4-ФКЗ).

Акт передачи исходного кода заказчику

Условия договора могут включать в себя передачу исходников и оговаривать возможности их использования. Также могут включать в себя передачу прав на продукт, в том числе эксклюзивных. Anatoly Moskovsky Теперь требуется документально оформить передачу исходников так, чтобы потом в случае нарушения Разработчиком эксклюзивных прав, можно было доказать в суде, при сравнении исходников, что исходники у Заказчика действительно те, что были переданы по договору. А зачем? Если это действительно взаимоотношения разработчик-заказчик, то я бы сказал, мне не совсем понятно желание сесть задницей на продукте. Имхо, гораздо выгоднее договориться о разделе прибыли с будущих использований : Любые разборки такого рода в суде будут опираться на свидетельские показания и экспертизы и при серьезном споре будет уйма того и другого. Разработчик здесь окажется в довольно сложном положении, поскольку если представленное заказчиком - не есть исходники предмета спора, разработчику естественно будет представить правильные - то есть, попросту говоря, за свой счет быстренько написать еще одну КИС, которая бы с одной стороны по внешнему виду и функционалу повторяла первую, а с другой стороны - явно отличалась от нее по исходникам. Если ставить задачу как "хранить эталонный экземпляр", и не существует аналога агентства по авторским правам, то я пошел бы к нотариусу. Наверняка существует услуга типа "ответственного хранения", при котором он возьмет эти исходники и выдаст их только на указанных условиях например, только в присутствии представителей обеих сторон. Но в любом случае, все будет не так просто. Есть эталонные исходники. Есть версия, которую заказчик давным-давно доработал для своих нужд. Есть код разработчика, немного похожий на эталонные исходники что неудивительно, учитывая что писали те же люди. Если Вы полагаете, что судья сядет, сравнит два листинга и скажет "но они же совпадают!

Передача исходных текстов

Кому принадлежат права на исходники? Акт сдачи-приема работ по созданию сайта Наименования части подсистемы, если описание относится не ко всей системе в целом. Сведения о госзаказчике. Сведения об основаниях для публикации кода например, номер приказа, распоряжения или реквизиты общего нормативного акта и условия, на которых он распространяется объем передаваемых прав и т.

При участии в разработке нескольких организаций субподрядчики указываются только в том случае, если они отвечали за разработку определенного компонента или модуля и могут предоставить консультационную поддержку по нему.

Организация-оператор системы может отличаться от организации-пользователя. В этом случае указываются только организации, являющиеся центрами компетенции по вопросам эксплуатации системы. Сжатый список организаций-пользователей. Если система ориентирована на интернет-пользователей — приводится перечень основных целевых аудиторий.

Неприемлемый вариант описания: Система предназначена для публикации в Интернете исходных кодов программ и программных комплексов, разработанных по госконтрактам МЭРиТ, и реализует следующие функции управления контентом веб-сайта: Рекомендуемый размер раздела — не более страниц. Укрупненное описание программного обеспечения системы, необходимое для понимания принципа ее работы и соответствующее ее фактической структуре т.

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

Структура технического комплекса описывается только в том случае, если она прямо связана со структурой программного обеспечения. Если в составе системы поставляется информационное обеспечение — дополнительно приводится перечень и краткое описание предоставляемых наборов данных. Раздел должен включать: Для всех программ и программных комплексов должны быть указаны: Указывается, используется ли дополнительный компонент на стадии установки сборки, настройки данной программы и системы в целом, или необходим в процессе ее использования.

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

Детальные описания процедур рекомендуется выносить в приложения или приводить точные ссылки на соответствующие проектные и рабочие документы. В общем случае представляет собой перечень файлов с кратким описанием их функционального назначения и пояснениями по принципам их размещения группировки в исходном коде, дистрибутиве и развернутом программном комплексе. Предметная часть Под исходным кодами понимаются тексты программ, пригодные как для анализа и корректировки человеком, так и для непосредственного преобразования в исполняемый код, интерпретации и т.

Форматированные распечатки текстов программ листинги , предназначенные только для чтения и анализа, равно как промежуточные результаты компиляции байт-код и т. В общем случае представление листингов программ при наличии их документированного исходного кода не требуется. Исходные тексты, разработанные и передаваемые исполнителем могут быть представлены в следующем виде: Дополнительно в состав передаваемого исходного кода могут быть включены при условии явного, с точностью до файлов, указания на это в описательной части файлы с управляющими последовательностями для сборки программ из исходного кода make-файлы конфигурационные файлы, дампы структур БД, сценарии установки и т.

Квалификация, требуемая для выполнения сборки программы программного комплекса из исходного кода не должна превышать базового уровня программиста соответствующей программной платформы. В общем случае передаваемый исходный код должен обеспечивать возможность его публикации госзаказчиком. В связи с этим из исходного кода должны быть исключены все объекты, не являющиеся результатом работ по госконтракту и содержащие ограничения на право их публикации.

Способы представления. Если разделение публикуемых и непубликуемых компонентов невозможно или не оправданно по технологическим причинам в частности, в силу высокой трудоемкости восстановления необходимой для нормальной трансляции совокупности исходных кодов , то такой исходный код рассматривается, как имеющий ограничения в целом. Под дистрибутивом программного обеспечения системы понимается набор файлов, достаточный для того, чтобы путем выполнения конечного и четко определенного набора операций инсталляционной процедуры выполнить установку и запуск всех входящих в состав системы программ программного комплекса АС , при этом не обязательно включающий пригодный для непосредственного восприятия человеком код программ.

В общем случае дистрибутив должен включать программу-инсталлятор или инсталляционный сценарий, упрощающий процесс установки и настройки. Требования к квалификации персонала, выполняющего установку системы из дистрибутива, должны определяться в первичной документации госконтракта.

Графические форматы Для представления графических материалов иллюстраций, схем, чертежей , если иное не установлено условиями госконтракта, ТЗ или иной утвержденной документацией, для представления графических материалов в т. Формат представления таких материалов должен быть установлен в первичной документации проекта госконтракте, ТЗ, рабочей программе и т. При выборе формата предпочтение должно отдаваться форматам: В тексте контракта должно использоваться официальное название формата, рекомендуется снабжать его справочной ссылкой URL на официальный источник спецификации.

В документации проекта следует оговаривать конкретную версию например, указывать тип используемого кодека. Процедура публикации В качестве среды распространения раскрываемых материалов по госконтрактам предполагается использовать возможности Интернета. С технической точки зрения процедура публикации должна включать следующие шаги 1 Размещение поступающих материалов в едином Хранилище раскрываемых результатов работ.

Выполняется Оператором Хранилища на основании акта приема-передачи компакт-диска, а по мере реализации соответствующих средств Хранилища - на основании данных ЭЦП исполнителя работ. При размещении производятся следующие действия: Выполняется Оператором Хранилища с включением в процедуру должностных лиц Исполнителя и Госзаказчика. В ходе обработки производятся следующие действия: Требования к Хранилищу раскрываемых материалов по госконтрактам Для публикации и распространения раскрываемых необходимо создание единого технологического комплекса — Хранилища раскрываемых материалов, представляющего собой специализированную систему управления контентом.

Хранилище может быть реализован как функциональная подсистема в рамках уже существующих АИС, например, интернет-портала МЭРиТ, или как самостоятельный информационный ресурс. В основу работы Хранилища должен быть положено манипулировании информационными объектами — документами, пакетами ПО, другими материалами по госконтрактам, снабженными метаописаниями и классифицированными в системе рубрикаторов Хранилища.

Хранилище должен обеспечивать соответствие общим принципам архитектуры электронного государства, в т. Нотаризации наделения правомочностью агентов , Транзакционности обеспечивающих определенность статусов информационных объектов , Внешнего доступа к внутренним статусам.

Создание Хранилища предлагается осуществлять в два этапа: Отслеживание материалов, подлежащих раскрытию, при этом возлагается на Оператора и осуществляется оргметодами. В конечном виде программный комплекс Хранилища должен обеспечивать следующие основные функции: В состав средств подготовки к публикации должны быть включены специальные инструменты для размещения в Хранилище материалов госконтрактов, полученных до ввода в действие новых регламентов публикации.

Пользователям Хранилища должны быть доступны различные способы поиска опубликованных материалов: Помимо функциональных требований при разработке ТЗ ЧТЗ на Хранилище должны быть выработаны требования по персоналу, режимам функционирования, средствам восстановления информации после аварий, способам обеспечения информационной безопасности и защиты от несанкционированного доступа, показателям надежности, доступности и быстродействия, а также требования к различным видам обеспечения автоматизированной системы Хранилища — в первую очередь организационному, методическому и информационному.

Рекомендации Рекомендации по приведению существующих материалов к пригодной для публикации форме В настоящее время государственные органы располагают огромным количеством информационных объектов, полученных в рамках госконтрактов, однако они нуждаются в каталогизации, упорядочении, приведению к единому формату представления. Эти работы не могут быть возложены на исполнителей по соответствующим проектам, особенно полностью завершенным.

С другой стороны, госзаказчики не располагают необходимыми ресурсами и персоналом для выполнения этой работы. В связи с этим предлагается в конкурсном порядке определить уполномоченного оператора Хранилища результатов работ, который взял бы на себя организацию и техническое исполнение соответствующих работ. Оператор от имени госзаказчиков должен быть наделен достаточными полномочиями для того, чтобы запрашивать у исполнителей работ дополнительную информацию, необходимую для приведения к единой форме, каталогизации, классификации, метаописания представленных ими материалов.

Работа по публикации накопленных материалов не может быть осуществлена в короткие сроки. В связи с этим возникает задача С этой целью имеющиеся в распоряжении государственных органов материалы предлагается подвергнуть экспресс-экспертизе и разбить на две группы: Порядок публикации материалов первой группы должен быть определен на основании более подробной экспертной оценки, исходя из их реальной значимости для государства и общества.

Прочие материалы могут не подвергаться дополнительной трудоемкой экспертизе, а обрабатываться и публиковаться по мере высвобождения ресурсов оператора в порядке, обратном хронологическому — то есть более поздние и потенциально более актуальные результаты работ по госконтрактам обрабатываются и публикуются первыми. Рекомендации по развитию процедур, в т. Унификация документации и прочих передаваемых материалов должна осуществляться уже на стадии их разработки, то есть силами исполнителей.

Соответствующие требования должны быть зафиксированы в тексте госконтракта или приложений к нему — рабочих программ, заданий, календарных планов и т. Таким образом, первоочередной задачей по совершенствованию процедур представления результатов работ должно стать введение обязательного внутриведомственного нормоконтроля при заключении госконтракта.

Его функции — проверка наличия и адекватности требований по документированию, форматам и порядку представления данных. Однако вырабатывать соответствующие требования для каждого случая отдельно не рентабельно и не всегда возможно. Госзаказчик может просто не располагать специалистами в соответствующей предметной области почему для выполнения работ и привлекается сторонний исполнитель в рамках госконтракта.

Необходимо создание и публикация единого комплекса стандартов, регламентов и иной нормативно-технической документации, для которых существовали бы достаточно простые и четкие правила применения. Тогда госзаказчику будет достаточно просто включить в текст госконтракта ссылки на соответствующие документы и нормативы. В связи с тем, что принятие новых стандартов на государственном уровне — достаточно сложная и длительная процедура, а техническое регулирование необходимо уже сейчас, на первоначальной стадии соответствующие требования и рекомендации могут вводиться в качестве внутриотраслевых нормативов или ведомственных инструкций — например, на основании приказа по министерству.

С юридической точки зрения различия между ГОСТ, ОСТ и внутриведомственными документами не принципиальны — обязанность применения как тех, так и других возникает только вследствие включения такого требования в договор между сторонами. Тем не менее, статус ГОСТ, несомненно, более весом и универсален. Кроме того, действующие ГОСТы и ОСТы обычно являются предметом изучения при подготовке технических специалистов в профильных ВУЗах и иных учебных заведениях, а практика применения таких нормативно-технических документов значительно шире.

Как следствие, исполнители будут иметь лучшее понимание предъявляемых к ним требований и получат больше возможностей для качественного следования требованиям госзаказчика.

Приведенные ниже рекомендации по разработке новых стандартов относятся в основном к области ИТ, однако представляется очевидной необходимость провести аналогичную работу и в других областях, связанных с разработкой нематериальных имущественных объектов, например в рамках НИОКР в сфере гуманитарных наук и т. Терминология Одной из важнейших проблем при подготовке договорной, проектной и рабочей документации является отсутствие стандартизированной терминологии по современным технологиям.

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

Все это привносит в документацию нежелательный сленговый окрас, затрудняет ее восприятие. Кроме того, толкование многих применяемых терминов неоднозначно и, напротив, одно и то же понятие часто обозначается разными терминами даже в пределах одного документа. В связи с этим имеется насущная необходимость в разработке ряда глоссариев и словарей, которые, с одной стороны, дали бы адекватные российские синонимы для применяемых в международной практике терминов, с другой стороны, предоставили бы их единое толкование для юридических и технических целей.

Среди необходимых словарей сферы ИТ можно выделить: Типология информационных систем Как отмечалось выше, действующая система стандартов в области ИТ имеет отчетливый уклон в сторону автоматизированных систем, причем главным образом производственного класса САПР, СУТП и т.

Однако интенсивное развитие информационной технологий приводит к проникновению информационно-компьютерных технологий в самые различные области человеческой деятельности, включая быт, досуг, масс-медиа и т.

В связи с этим возникает потребность расширения понятийной сферы системы стандартов информационных технологий. Задача стандартов данной группы — введение четкой классификации и определение минимального набора функциональных задач и показателей назначения различных типов и классов информационных систем, в первую очередь систем обеспечения управленческой деятельности, таких, как ERP, CRM и т.

Процедура разработки На настоящий момент в России принят стандарт ИСО , регламентирующий жизненный цикл программных продуктов, однако многими специалистами отмечается сложность его применения на практике в силу чрезмерной универсальности. В рамках этих стандартов, в частности, имеет смысл регламентировать такие общепринятые, но не находящие отражения в современной системе стандартов процедуры и стадии, как: Нефункциональные показатели информационных систем В настоящее время ни на уровне официальных стандартов, ни на уровне практического применения в отрасли не существует методик объективной оценки таких важнейших нефункциональных показателей информационных систем, как: Передача исходного кода программы Передача исключительных прав Вы здесь: Помимо программного кода, объектами интеллектуального труда являются графические материалы элементы интерфейса , контент, бизнес-логика, функционал.

Первоначально, все материалы и наработки принадлежат автору, то есть нам. Только вот ведь какая штука. Сие есть технологическая информация, и обязанности передать исходные коды в законе нет. Разработки должны соответствовать условиям технического задания, предоставленного Заказчиком в рамках настоящего договора. Указанные Разработки будут являться частью программного продукта, используемого в области.

Исполнитель обязуется завершить Разработки в течение с момента подписания настоящего договора. Исполнитель обязуется выполнить Разработки своими силами и средствами. Первоначальный вариант Разработок передается в виде исходного кода и сопутствующей документации и принимается Заказчиком по акту приемки-передачи первоначального варианта, подписываемому обеими сторонами. Договор, предусматривающий передачу работающей программы, но не исходного кода Акт сдачи-приема работ по созданию сайта SEO Акт сдачи-приема работ — документ, фиксирующий завершение выполнения договора.

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

Когда сайт будет готов, поспешите получить подписанный акт, который подтверждает, что все работы выполнены. Если потом заказчик захочет, а такое бывает очень часто, внести какие-то изменения, то это будет уже не за счет бюджета, отведенного на создание сайта.

Вот так выглядит типичный шаблон акта сдачи-приема работ по созданию сайта. Договорная цена выполненных работ оказанных услуг составляет: Правовое положение исходного кода программы для ЭВМ Исполнитель обязуется разработать программный код и алгоритмы, создать и имплементировать программные компоненты далее - "Разработки" , соответствующие характеристикам, указанным в п.

Актуальные юридические консультации по теме: Ключевые слова: То что Вы говорите о приоритете правовых актов над договорами это ясно.

Договор авторского заказа на сайт.

Кому принадлежат права на исходники? Акт сдачи-приема работ по созданию сайта Наименования части подсистемы, если описание относится не ко всей системе в целом. Сведения о госзаказчике. Сведения об основаниях для публикации кода например, номер приказа, распоряжения или реквизиты общего нормативного акта и условия, на которых он распространяется объем передаваемых прав и т. При участии в разработке нескольких организаций субподрядчики указываются только в том случае, если они отвечали за разработку определенного компонента или модуля и могут предоставить консультационную поддержку по нему.

ФГУП «НИИ «Квант»

Блог Договор авторского заказа на сайт. Вы можете ознакомится с Договором, а далее, по согласованию с Вами, мы изменим или дополним его. О подписанта, действующего ей на основании Основание полномочий подписанта, с одной стороны, и Наименование Стороны в лице Должность Ф. Вместе именуемые Стороны, а индивидуально — Сторона. Заключили настоящий Договор авторского заказа на сайт с предоставлением прав на использование далее по тексту — Договор о нижеследующем: 1. Предмет договора 1. Автор обязуется по заданию Заказчика создать интернет-сайт далее по тексту — Сайт и передать Заказчику права на его использование на условиях простой неисключительной лицензии, а Заказчик принять его в порядке и на условиях, установленных Договором. В соответствии с Договором и Заданием Автор выполняет следующие работы далее по тексту — Работы : 1.

ПОСМОТРИТЕ ВИДЕО ПО ТЕМЕ: Заказчик не подписывает акт

Передача исходного кода программы

Настоящий Порядок разработан в целях реализации пунктов 28 и 32 Протокола об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза приложение N 3 к Договору о Евразийском экономическом союзе от 29 мая года далее - Договор о Союзе и определяет процедуру передачи программного обеспечения интеграционного сегмента Евразийской экономической комиссии интегрированной информационной системы Евразийского экономического союза далее соответственно - программное обеспечение, Комиссия, интегрированная система , в отношении которого Комиссия осуществляет права и исполняет обязанности собственника, и правила использования такого программного обеспечения. Понятия используются в настоящем Порядке в значениях, определенных Договором о Союзе, включая Протокол об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза приложение N 3 к Договору о Союзе , решениями Комиссии по вопросам создания и развития интегрированной системы. Программное обеспечение, разработанное в рамках работ по созданию и развитию интегрированной системы, предусматривающее возможность его использования в составе национального сегмента, передается заказчикам национальных сегментов государств - членов Евразийского экономического союза интегрированной системы далее соответственно - национальный сегмент, государства-члены по их заявкам для использования при разработке компонентов национальных сегментов, а также реализации отдельных функций в составе национальных сегментов. Передача Комиссией прав на программное обеспечение в том числе электронных носителей с программным обеспечением, а также эксплуатационной и или проектной документации заказчику национального сегмента осуществляется на безвозмездной основе в соответствии с заключаемым в упрощенном порядке лицензионным договором о предоставлении простой неисключительной лицензии и оформляется актом приема-передачи в соответствии с пунктами 8 - 10 настоящего Порядка. Программное обеспечение передается заказчику национального сегмента в виде исполняемого кода дистрибутива с эксплуатационной документацией на программное обеспечение.

Обязана ли компания-разработчик передавать исходный код на программу? заказчику передается исключительное право на эту программу. ( Федеральный конституционный закон от № 4-ФКЗ). допускается использование исходных текстов (кодов), переданных заказчику Передача заказчиком национального сегмента программного Акт приема-передачи программного обеспечения составляется в. При передаче Заказчик совместно с Разработчиком вычисляют и оформляют акт передачи где указывается "Исходные коды КИС.

Если недостаточно, можно ли что-то сделать в такой ситуации, или с софтом мы встряли по полной? Не обзательно. Договор заказа на разработку программного кода, алгоритма с последующей передачей исключительного права 2.

Договор, предусматривающий передачу работающей программы, но не исходного кода

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

То что Вы говорите о приоритете правовых актов над договорами это ясно. Но В приведённых Вами ссылках на ГК говориться о передаче исключительных и не исключительных прав пользования программ. И я не нашёл указание на необходимость передачи исходных кодов.

.

.

.

ВИДЕО ПО ТЕМЕ: Заказчик не подписывает акт приемки работ, что делать подрядчику?
Понравилась статья? Поделиться с друзьями:
Комментариев: 2
  1. Казимира

    супер ржач!!!!!!!гы гы

  2. ransresttemtu

    Могу поискать ссылку на сайт, на котором есть много статей по этому вопросу.

Добавить комментарий

Отправляя комментарий, вы даете согласие на сбор и обработку персональных данных