Руководство по госзакупкам ПО с открытым исходным кодом в Евросоюзе

Материал из Xgu.ru

Содержание 1 Источник 2 Почему в wiki? 3 Руководство по госзакупкам ПО с открытым исходным кодом 4 Информация 5 1. Вступление 6 2. Руководство по закупкам ПО с открытым кодом 6.1 2.1 Требования госсектора: прозрачность, устойчивость, рентабельность 6.2 2.1 Определение национальной / Европейской политики 6.3 2.1.1 Коробочное или заказное ПО ? 6.4 2.1.2 "На равных условиях" или открытое ПО ? 6.5 2.2 Определение потребностей приобретения 6.6 2.2.1 Определение ИТ-архитектуры 6.7 2.2.2 Определение требований 6.8 2.2.3 Изучение затрат и выгод 6.9 2.2.4 Скачивать или покупать ? 6.10 2.3 Скачивание открытого ПО 6.11 2.3.1 Источники ПО 6.12 2.3.2 Идентификация и выбор ПО 6.13 2.3.3 Тендеры для оценки, поддержки, настройки, услуг 6.14 2.4 Покупка ПО с открытым исходным кодом 6.15 2.4.1 Определение требований 6.16 2.4.2 Другие требования 6.17 2.4.3 Процесс выбора на тендере 6.18 2.5 Заключение 6.19 A. Шаблоны текстов для тендеров 6.19.1 A.1 Функциональные / технические спецификации 6.19.2 A.2 Требования открытости 6.19.3 A.3 Требования открытых стандартов 6.19.4 B.2 Закупка открытого ПО: соответствует ли правилам? 6.19.5 B.2.1 Получение открытого ПО без проведения тендеров 6.19.6 B.2.2 Тендеры, оговаривающие поставку открытого ПО или открытых стандартов 6.20 C. Источники

[править] Источник

Файл:Guidance on public procurement of open source software.odt Руководство по госзакупкам ПО с открытым исходным кодом на Хабрахабре

[править] Почему в wiki?

Как говорит сам автор перевода:

Поэтому, всем кто читает документ, сравнивая его с оригиналом на английском, и находит ошибки перевода либо неадекватный тексту перевод — большая просьба: внесите необходимые исправления и перешлите документ мне, чтобы я мог его обновить.

Wiki тем и хороша, что можно не направлять документы автору, а редактировать всем миром

[править] Руководство по госзакупкам ПО с открытым исходным кодом

Март 2010 (в редакции от июня 2010 г.)

Руководство подготовлено для программы IDABC:

Ришаб Эйе Гош (ghosh@merit.unu.edu) Университет ООН/MERIT Рудигер Глотт - Университет ООН/MERIT Патрис-Эммануэль Шмитц - Unisys Бельгия Абделькрим Бужраф - Unisys Бельгия

Специальный контракт №4 (GPOSS), основанный на рамочном контракте ENTR/05/066/IDABC/OSOR

[править] Информация

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

Европейская Комиссия не гарантирует точность информации, включённой в это исследование, и не несёт никакой ответственности в связи с её использованием.

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

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

Этот документ может быть скачан с сайта OSOR.eu: http://www.osor.eu/idabc-studies

© Европейские Сообщества, 2009, 2010 Воспроизведение разрешено, за исключением использования в коммерческих целях, при условии указания ссылки на источник.

[править] 1. Вступление

Европейское правительство всё чаще рассматривает использование ПО с открытым кодом (также известного как свободное ПО или FLOSS1 ) как средство снижения издержек, повышения прозрачности и устойчивости. Состоялось множество дебатов на тему издержек и выгоды от открытого ПО, и во множестве дискуссий вопрос рассматривался с точки зрения информационных технологий. Между тем, Европейская Комиссия открыла "Обсерваторию и репозиторий открытого ПО" (OSOR), с целью поддержки открытого ПО, и как воплощение инициативы совместной разработки открытого ПО в европейском госсекторе. В этом контексте авторы рассматривают открытое ПО не как технический элемент, но как часть вопроса о госзакупках. Авторы рассматривают процесс госзакупок, его принципы и требования; как происходят госзакупки ПО в государствах-членах ЕС, и как открытое ПО соотносится с процессом госзакупок. Авторы объясняют, как открытое ПО может быть наилучшим образом адресовано в процессе закупки, а также предоставляют руководство по получению открытого ПО с помощью публичных тендеров. Это документ является не обобщённым руководством по закупке ПО, но рекомендацией, разработанной специально для того, чтобы ясно и просто объяснить, как и почему государственные учреждения могут получить ПО с открытым исходным кодом. Это руководство основано на обширном правовом анализе, проведённом программой голландского правительства OSOSS, в результате которого было опубликовано руководство по открытым стандартам и открытому ПО в тендерах: «Открытые стандарты и открытое ПО и правила проведения тендеров» в 2005 году. За этим последовало ещё одно руководство2, опубликованное в 2007 году NoiV, организацией-преемником OSOSS3. Голландское руководство было подготовлено в контексте значительных политических дискуссий вокруг программного обеспечения с открытым исходным кодом. Голландский парламент поддержал (в 2003 г.) движение, призывающее к использованию открытого программного обеспечения и открытых стандартов в государственном секторе. Было проведено несколько исследований по вопросу использования открытых стандартов и открытого программного обеспечения в голландском государственном секторе. Наконец, в 2007 году голландское правительство приняло официальную политику обязательного использования открытых стандартов и предпочтительного использования открытого ПО. Таким образом, голландское руководство не нуждается в обосновании необходимости такой политики, т.к. это содержится в предыдущих исследованиях, а также коренится в самой голландской политике относительно открытого ПО и открытых стандартов. На общеевропейском уровне нет таких правил. Поэтому данное руководство стремится быть применимым в любом контексте в рамках ЕС, независимо от существования любых правил относительно открытого ПО и открытых стандартов. В действительности, целью данного руководства является его применимость для отдельных государственных учреждений на региональном, национальном или местном уровне в целях получения открытого ПО, даже если относительно этой темы не существует специальной политики. Можно было бы спросить: зачем нужна публикация этого руководства? С открытием OSOR у госучреждений появляется естественное желание попробовать открытое ПО, начиная с того, что опубликовано OSOR. У многих госучреждений нет чёткого понимания, как следует действовать в этой области, поэтому им просто необходимы советы и руководства. Одной из основных функций OSOR является быть местом для публикации советов и руководств на тему использования открытого ПО в госорганах. Таким образом, это руководство создано, потому что необходимо пользователям OSOR. Дополнительным обоснованием для создания данного руководства явилось широкое распространение "плохих практик" в области государственных закупок ПО, которые приводят к непрозрачному процессу и антиконкурентной дискриминации. Дискриминации в пользу проприетарного ПО, и как правило, в пользу конкретного ПО и его поставщиков. Это отчасти происходит и из-за того, что госучреждения не знают лучших способов и потому что они могут не знать о возможности получения открытого ПО, или о способах, как это сделать. Существует потребность в информации, и цель настоящего руководства состоит в удовлетворении этой потребности. Основная часть этого руководства, после этого введения, предназначена для широкого круга читателей. Она предназначена для оказания практической помощи политикам, ИТ-менеджерам и специалистам по закупкам на уровне национальных, региональных и местных органов власти. Поэтому является лёгким для чтения, без большого количества юридических тонкостей, и (относительно) коротким. Основная часть руководства может быть распространена и прочитана без дальнейших объяснений. Однако, дополнительные детали приводятся в двух Дополнениях: Дополнение А: "шаблоны" текста, который может быть легко адаптирован к реальным тендерам, которые призваны выражать предпочтения или требования по поставке открытого ПО или открытых стандартов. Дополнение B: юридическое руководство, обеспечивающее правовую основу практических руководств, предназначенное юристам и специалистам по закупкам, также доступное политикам и ИТ менеджерам. Это дополнение также может быть прочитано отдельно от основной части руководства.

Предупреждение: не является юридическим руководством! Это руководство стремится предоставить практическую информацию относительно закона, регулирующего процесс госзакупок. Однако, законы интерпретируются судами, и относительно госзакупок ПО европейская судебная практика невелика. Советы, перечисленные в руководстве, в том числе юридическое руководство в Дополнении B и тексты шаблонов в Дополнении А, не должны рассматриваться как полноценное юридическое руководство, или в качестве замены нормальных процедур юридической консультации, которые могут быть использованы в подготовке закупок, тендеров и контрактов.

[править] 2. Руководство по закупкам ПО с открытым кодом

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

[править] 2.1 Требования госсектора: прозрачность, устойчивость, рентабельность

Министры выразили обеспокоенность по поводу зависимости от одного поставщика и производителя ИТ услуг и призвали к усилению конкуренции. Министры [...] попросили Комиссию простимулировать разработку альтернативного открытого ПО, где это необходимо. Интероперабельность [...] и открытые стандарты совместно с "технологически нейтральным" регулированием являются жизненно важными. - Брюссельская Декларация Министров, 29 ноября 2001 Министры призвали их администрации пересмотреть системы и процессы, с тем чтобы лучше координировать действия на различных уровнях управления, используя открытые стандарты. Декларация Министров Комо, 7 июля 2003 Государства-члены ЕС будут способствовать информированности и принятию открытых стандартов в системе государственного управления Манчестерская Декларация Министров, 24 ноября 2005 Непрерывное внимание должно быть уделено определению и открытости технических стандартов и общедоступных спецификаций Лиссабонская Декларация Министров, 19 сентября 2007 "Контракты, заключаемые в государствах-членах ЕС от имени государства, [...] должны соблюдать принципы равного обращения, принцип недискриминации [...] и принцип прозрачности. Является целесообразным разработать положения Союза по координации национальных процедур оценок таких контрактов, основанных на таких принципах, с тем, чтобы обеспечить их эффект и гарантировать открытость госзакупок для конкуренции." Изложение 2, Директива 2004/18/EC Госсектор в качестве потребителя ПО обязан поддерживать взаимодействие, прозрачность и гибкость ПО, а также экономно использовать государственные финансовые ресурсы. Когда речь заходит о государственных закупках, правила, применяемые в госсекторе, должны обеспечивать (и, конечно, не создавать помех) принцип конкурсности с помощью их практики закупок. Госучреждения обязаны избегать всего, что может вредить конкуренции на рынке частных потребителей. Поэтому, они не должны требовать от граждан покупать или использовать системы от конкретных поставщиков для доступа к государственным услугам, так как это равносильно предоставлению таким поставщикам статуса государственной монополии. Они также обязаны убедиться в том, что ПО имеет наилучшее соотношение стоимости к уровню обслуживания в долгосрочной перспективе Эти принципы являются не только основой для директивных документов, таких, как European Interoperability Framework; они также вытекают из законодательных рамок, регулирующих государственные закупки, например, Директива 2004/18/ЕС о государственных контрактах на поставку и Директивы 2004/17/ЕС на коммунальные услуги, и Директивы 98/34/ЕС о предоставлении информации в области технических стандартов и регламентов. Открытые стандарты Хорошей практикой при оказании услуг электронного правительства является обеспечение доступа на основе открытых стандартов, и, в частности, правило никогда не требовать от граждан покупку или использование систем от конкретных поставщиков для доступа к государственным услугам: это равносильно предоставлению таким поставщикам статуса государственной монополии. Более того, эффективной практикой для органов государственной власти является использование ПО, основанного на открытых стандартах, так как это даёт экономический эффект в виде укрепления полностью конкурентного рынка5. Поддержка технологий без учета степени их открытости и их способности содействовать полностью конкурентному рынку вредит конкуренции, а также оказывает негативный эффект на социальное и экономическое благосостояние государства. Таким образом, несвободное и не основанное на открытых стандартах ПО обходится очень дорого в долгосрочной перспективе. Хотя ПО, основанное на открытых стандартах, не всегда доступно, госучреждения должны поощрять его развитие и подчёркивать свои предпочтения относительно такого ПО с помощью льготных условий на тендерах везде, где это возможно. Кроме того, государственные учреждения должны использовать открытые стандарты везде, где они поддерживается программным обеспечением, предпочитая их любым другим технологиям, которые поддерживаются используемым программным обеспечением. Главное преимущество открытых стандартов заключается в потенциале для взаимодействия с другими системами. Программы, основанные на открытых стандартах, полностью совместимы с любыми другими программами, использующими те же стандарты. В результате, покупатели ПО часто пытаются достичь независимости от поставщика, которая позволяет в будущем сменить ПО или поставщика без потери данных или значительной потери функциональности. Однако, эта цель может привести к конфликту с явными или неявными критериями закупки ПО, в частности - "является ли новое ПО совместимым с ранее приобретённым?". Покупатели, которые используют подобные критерии вместо общих требований к использованию открытых стандартов и независимости от поставщика в результате остаются привязанными к ранее закупленному ПО. Открытые стандарты были описаны выше с точки зрения их базовой эффективности; термин также был определён в European Interoperability Framework v1.0 таким образом: Ниже приведены минимальные характеристики, которые должны иметь спецификации и сопутствующие документы, чтобы считаться открытым стандартом: Стандарт принят и будет поддерживаться некоммерческой организацией, и его постоянное развитие происходит на основе открытой процедуры принятия решений, доступной для всех заинтересованных сторон (консенсуса или большинством голосов и т.д.). Стандарт был опубликован и документ с описанием стандарта доступен либо бесплатно либо по номинальной цене. Копирование, распространение и использование этого документа должно быть разрешено всем бесплатно или за номинальную плату. Интеллектуальная собственность, например, патенты, если они имеются - или права на части стандарта, сделана безвозвратно доступной на безвозмездной основе. Нет никаких ограничений на повторное использование стандарта. Есть ряд других определений, и, как отмечают авторы позже в данном руководстве, точное определение термина открытых стандартов является менее важным, чем ясное выражение причин, по которым открытые стандарты предпочтительны в первую очередь. Эти причины образуют часть требований для любой процедуры закупок. ПО с открытым исходным кодом ПО с открытым исходным кодом, свободное ПО, также называемое FLOSS, это такое ПО, которое пользователь может: 1. использовать для любых нужд 2. исследовать, изучая его исходный код 3. изменять и улучшать 4. распространять с изменениями или без Базовое определение FLOSS эквивалентно Четырём Свободам Фонда Свободного ПО (FSF, который официально определяет "свободное программное обеспечение") и Определению ПО с открытым исходным кодом, поддерживаемому Open Source Initiative (OSI). Открытое программное обеспечение защищено авторским правом и предоставляется в соответствии с лицензиями, которые обеспечивают свободы, требуемые определением, данным выше. Большинство лицензий для открытого и свободного ПО прошли формальный процесс утверждения Open Source Initiative и выложены на сайте OSI; эти лицензии сертифицированы OSI и им разрешено использовать марку "Open Source Initiative Approved License". Конечно, лицензии, которые отвечают условиям определения открытого ПО, но ещё не были официально обработаны OSI (и поэтому не перечислены на их сайте), также являются открытыми лицензиями. Отношение к принципам закупок и устойчивости И открытые стандарты и программное обеспечение с открытым кодом, как по отдельности описано выше, связаны с ранее упомянутыми принципами осуществления госзакупок. 1. прозрачность: открытое ПО доступно вместе с исходным кодом, который может быть изучен и модифицирован. Это может обеспечить безопасность ПО, т.к. оно может быть детально изучено. Это также позволяет заинтересованным сторонам понимать и отслеживать функционирование государственных процессов, реализованных в ПО — например, в системах голосования. 2. интероперабельность: являются ли реализованными в открытом ПО или проприетарном, открытые стандарты обеспечивают интероперабельность, способность систем от различных поставщиков полноценно функционировать друг с другом без каких-либо технических или юридических препятствий. Открытое ПО, в частности, обеспечивает дополнительную поддержку в плане интероперабельности, так как его процессы могут быть изучены и адаптированы для работы с другими системами. 3. независимость: прозрачность и интероперабельность позволяют совместно работать текущим и будущим поставщикам, адаптировать и поддерживать ПО, устраняя зависимость покупателей или третьих сторон, осуществляющих техподдержку от поставщиков оригинальных версий ПО. 4. гибкость: открытое ПО позволяет адаптировать и развивать системы с ростом потребностей пользователей. Оно позволяет делать это, не требуя от пользователя возвращаться к первоначальному поставщику — новые поставщики могут быть выбраны на конкурсной основе. Эти четыре свойства обеспечивают устойчивость открытого ПО. Устойчивость предполагает снижение затрат в долгосрочной перспективе, но, что более важно, снижает зависимость пользователей от оригинальных поставщиков ПО. Это означает, что критерии отбора, которые традиционно используются для обеспечения устойчивости программного обеспечения, а также для обеспечения устойчивости поставщиков (например, капитал, оборот или размер) могут не быть столь же важными и могут быть уменьшены при закупке открытого ПО. Если, например, поставщик банкротится, то пользователи могут утратить все инвестиции в проприетарное ПО этого поставщика. Однако, если поставляемое ПО является открытым, пользователь может найти другого поставщика услуг техподдержки без каких-либо правовых или технических препятствий.

[править] 2.1 Определение национальной / Европейской политики

На данный момент не существует всеобщей для Евросоюза политики в отношении закупок ПО с открытым исходным кодом. Есть ряд руководящих принципов и требований, связанных с закупками в целом, некоторые из которых касаются программного обеспечения. Как уже упоминалось ранее, существуют конкретные директивы ЕС, которые касаются госзакупок и технических стандартов. European Interoperability Framework (EIF) предоставляет руководящие принципы, касающиеся открытых стандартов и совместимости между администрациями; если не указано иное, данное руководство ссылается на версию 1.0 этого документа. Большинство государств-членов ЕС не имеют конкретной политики в отношении закупок ПО с открытым исходным кодом. В 2007 году правительство Нидерландов запустило в действие план6, согласно которому государство выражает явное "предпочтение ПО с открытым кодом в случае равной пригодности". Оно признало, что в процессе госзакупок недопустима дискриминация отдельных поставщиков. Исследования показали7, что на практике в большинстве тендеров наблюдается дискриминация поставщиков, как правило в пользу поставщиков конкретного собственнического ПО. Такая дискриминация отдельных поставщиков идёт против многочисленных правил и принципов закупок. Однако, предпочтение какой-то определённой бизнес-модели в рамках тендера является общепринятым и широко распространённым в ряде областей — например, когда предпочтение отдаётся лизингу, а не закупке оборудования. Предпочтение определённой бизнес-модели является разумным, если она лучше отвечает потребностям закупки. Конечно, это совсем не является предпочтением в смысле принципов недискриминации и равного обращения, т.к. любой субъект экономической деятельности, который готов удовлетворить потребности закупки, может участвовать в тендере. Таким образом, это лишь предпочтение для удовлетворения конкретных, четко определённых и оправданных потребностей закупающей организации. Это аргумент, использованный в марте 2008 в голландском правительственном руководстве, Получение (открытого) ПО, подготовленного в целях реализации голландской политики закупок. Голландское руководство, которое было взято авторами в качестве модели для данного руководства, объясняет, как специфические свойства открытого ПО могут быть определены и обоснованы в рамках функциональных требований государственной закупки. Предпочтение открытого ПО конкретной организацией, в процессе конкретной закупки, не реализуется путём приобретения конкретных приложений или с помощью выбора определённых поставщиков. Вместо этого, следуя данному руководству, оно реализуется с помощью функциональных требований и критериев выбора победителя на тендерах. Как и любые другие требования тендера, требования, которые присущи открытому ПО — такие, как право на изучение, модификацию и распространение ПО — должны быть оправданы. Процесс определения национальной или европейской политики является длительным и выходит за рамки настоящего руководства. Вместо этого, авторы считают, что по любой причине, будь то обоснованным национальной политикой, как в Нидерландах, или в связи с региональной политикой (как в Пьемонт, Италия8), или в связи с требованиями конкретных причин закупки, должно быть принято решение приобрести программное обеспечение с характеристиками открытого ПО, определёнными выше.

[править] 2.1.1 Коробочное или заказное ПО ?

Хотя точные данные для европейского госсектора недоступны, стоит отметить, что доля собственнического ПО в европейских расходах составляет только 19%. Гораздо больше тратится на заказное ПО (52%) и внутреннюю разработку ПО (29%).9 Как отмечено в исследовании Европейской Комиссии о влиянии СПО на инновации и конкурентноспособность европейского сектора ИТ, экономика заказного и разработанного внутри ПО, как правило, эквивалентна экономике СПО. То есть, пользователи, а не разработчики, контролируют права на ПО. В госсекторе большáя часть ПО является специализированной или разработанной внутри организации. Отчасти это происходит из-за того, что область применения ПО является характерной для госсектора — управление полицейскими данными не является областью, для которое есть большой рынок ПО. По данным другого исследования ЕС10 около 10% местных органов власти в ЕС были в состоянии выпустить ПО, которым владеют (специализированное или разработанное ими) как открытое ПО. Так как такое ПО, как правило, контролируется госорганизациями, использующими его, проблемы, связанные с открытыми ПО и стандартами, проще решить. Есть две проблемы. Первая: выбор платформы, инструментов, библиотек и других элементов, используемых для разработки ПО с открытым исходным кодом, или хотя бы основанных на открытых стандартах. Вторая: будет ли разрабатываемое ПО доступно в исходных текстах. Второй вопрос выходит за рамки этого руководства, т.к. не связан с процессом госзакупок. Однако существует несколько полезных документов и исследований на сайте OSOR, которые могут быть использованы государственными органами в процессе принятия решения следует ли делать разрабатываемое ПО доступным в исходных текстах (включая лицензию European Union Public Licence) Первую проблему можно решить с помощью критериев госзакупок, похожих на таковые, используемые при закупке коробочного ПО, что и является главным предметом данного руководства. Это руководство наиболее полезно в случаях имеющегося в наличии ПО, которое контролирует поставщик, а не пользователь. Таким образом, процедуры закупок более важны для того, чтобы помочь закупающей организации осуществлять своё управление и выбор.

[править] 2.1.2 "На равных условиях" или открытое ПО ?

Как отмечается во введении к этому руководству, используемые в данный момент практики госзакупок не предоставляют одинаковых условий. Они часто предвзяты в пользу проприетарного ПО, а также конкретных поставщиков. Европейский закон о государственных закупках может позволять такие отклонения при определенных, исключительно обоснованных случаях. На практике такое предвзятое отношение не является исключительным, а обоснования обычно не предоставляются. Предметной областью данного руководства является госзакупка ПО с открытым исходным кодом. Однако, многие из принципов и методов, описанных в данном руководстве, для закупки программного обеспечения - будь то основанного на открытых исходных текстах или на открытых стандартах - могут быть использованы просто для того, чтобы убедиться, что процесс закупки происходит в справедливых условиях. Как отмечено в соответствующих разделах ниже, любая закупка ПО должна быть основана на чётком определении ИТ архитектуры (раздел 2.2.1), объективном определении требований в функциональных, нежели связанных с поставщиком или торговой маркой, терминах (раздел 2.2.2) и полной, а не узкой или только в краткосрочной перспективе, оценкой затрат и выгод (раздел 2.2.3). Кроме того, методы, описанные для закупки ПО, основанного на открытых стандартах, могут быть полезны для закупок ПО вообще, с точки зрения оптимизации расходов (раздел 2.2.3). ПО, полученное таким образом, и с такими обоснованиями может быть закрытым, но в этом случае будет получена в результате правильной процедуры. ПО, полученное без использования такой процедуры, может быть получено неправильно и предвзято; если имело место явное предпочтение конкретных поставщиков, без обоснований исключительности обстоятельств, такое приобретение может являться даже нарушением правил госзакупок. Таким образом, данное руководство может быть полезно для закупки ПО вообще, даже для того, чтобы обеспечивать равные условия и совместимость с правилами закупок. Основное внимание в данном руководстве, уделяется, однако, закупке ПО в ситуациях, когда по уважительным причинам было признано необходимым отдать предпочтение ПО с некоторыми или всеми характеристиками открытого ПО.

[править] 2.2 Определение потребностей приобретения

Процесс госзакупок основан на определении потребностей, ИТ инфраструктуры, в которой эти потребности должны быть реализованы и трансформацию этой информации в требования и последующую оценку имеющихся вариантов на тендере. Интересно, что приобретение программного обеспечения с открытым кодом не обязательно требует использования процесса государственных закупок (например, тендеров), как этого обычно требует процесс закупки ПО и услуг. Этот частный случай также обсуждается ниже.

[править] 2.2.1 Определение ИТ-архитектуры

Информационные технологии служат для структуризации, управления процессами и достижения целей организации. Каждая организация имеет свою собственную архитектуру процессов и систем, направленную на достижение наибольшей эффективности в реализации своих целей. Архитектура ИТ транслирует эти организационные ограничения и предпочтения в набор взаимосвязанных информационных систем, что обеспечивает условия для гладкой интеграции конкретных ИТ-решений для конкретных организационных проблем. Госорганизации имеют архитектуру, которая может отличаться в некоторых отношениях от архитектуры частных организаций из-за различий в своих основных целях и принципах. Экономия расходов - это принцип, который может быть общим для государственных и частных организаций. Государственные организации могут отличаться тем, что они обязаны сокращать расходы на долговременной основе - так как они используют средства налогоплательщиков и не должны реагировать на краткосрочные экономические циклы. Однако, госорганизации часто имеют ограничения в виде бюджетов, которые установлены на относительно короткие сроки, и вынуждены обеспечивать баланс между краткосрочной и долгосрочной экономией. Кроме того, частные организации могут иметь различные, иногда более ограниченные цели в отношении прозрачности, что, напротив, является особенно важным принципом для общественных организаций. Не существует общего для ЕС стандарта на ИТ-архитектуру госорганизаций; но государства-члены имеют его, и European Interoperability Framework предоставляет высокоуровневую структуру для многих аспектов ИТ-архитектуры. Любые ИТ-решения должны разрабатываться так, чтобы вписаться в ИТ-архитектуру организации. Потребности ИТ-архитектуры организаций государственного сектора тесно связаны с функциональной совместимостью и открытыми стандартами. Как отмечается в "Белой книге Еврокомиссии по ИТ стандартизации"11, "Органы государственной власти должны быть в состоянии определить свои стратегии в области ИКТ и архитектур, включая взаимодействие между организациями, и будут закупать ИКТ системы\услуги, а также продукты и их компоненты, которые отвечают их требованиям". Государственные органы функционируют не в вакууме, и имеют особенно жесткие требования, предъявляемые к обмену данными: между различными ведомствами, различными организациями, различными уровнями власти и заинтересованными сторонами, такими как бизнес и граждане. Госорганизации также несут обязательства по созданию устойчивых и прозрачных систем. Влиянием этих обязательств на их ИТ-архитектуры является настоятельная необходимость в совместимости. Как заявлено в документе "European Interoperability Framework 2.0"12, существует необходимость в "стандартах интероперабельности" или "совместимости соглашений", которые определяют механизмы, регулирующие как именно осуществляется взаимодействие в рамках архитектуры государственных систем. EIF отмечает, что "эти механизмы взаимодействия на всех уровнях должны быть предметом для надлежащего стандартизированного подхода, который является систематическим, формальным, подробным и чётким". Такие механизмы взаимодействия при переводе в требования к ИТ-архитектуре обосновывают технические характеристики, основанные на открытых стандартах, как описано в следующем разделе. Необходимость обмена данными без барьеров и препятствий между гражданами и правительством, например, оформляется в требование прозрачности для этих данных. Это, в свою очередь, подразумевает требования прозрачности для ИТ-архитектур, процессов и систем, связанных с этими данными. Из этих требований следует необходимость в определённой архитектуре в терминах технических спецификаций, обоснование открытых стандартов интероперабельности, как подробнее изложено в следующем разделе. В дополнение к открытым стандартам, специфические нужны госорганизаций могут также позволять открытому ПО встраиваться в ИТ-архитектуру особенно интересными способами, как это описано ниже в разделе, посвящённом определению требований относительно открытого ПО.

[править] 2.2.2 Определение требований

Лучшие практики ИТ закупок основаны на определении чётких требований и поиске наиболее подходящего под них решения. Хотя процедуры закупок, такие как тендеры, на практике часто игнорируют этот принцип, просто указывая конкретные продукты или даже производителя, это не является хорошей практикой и может привести к нарушению подзаконных актов о закупках. Это также делает более трудным обоснование приобретения выбранных продуктов. Требования могут быть предоставлены в различных формах, как это кратко описано ниже. Это ни в коем случае не официальные категории и приведены здесь для иллюстрации. Функциональные Функциональные требования описывают цели, для которых требуется ИТ решение, и функциональность, которую это решение, как ожидается, обеспечит. Чёткие спецификации функциональных требований являются необходимым условием для того, чтобы обеспечить процессу закупок соответствие принципам транспарентности и независимости, поддержки развития конкуренции и экономической эффективности в долгосрочной перспективе. Примером функциональных требований будет подробное описание функциональных возможностей системы ведения учета имущества. Функциональные требования должны быть определены не только в терминах ИТ, но также и в терминах предметной области. Технические Технические требования также могут быть важны, если существуют определенные ограничения или потребности в области ИТ-архитектуры и технологий, с которым решения должны сопрягаться. Отметим, что совместимость с ранее закупленными решениями может казаться очень правильным техническим требованием, но также может быть и способом увековечения последствий предыдущих решений о покупке, увековечению выбора поставщика и предотвращения объективных закупок на основе реальных потребностей организации. Требования совместимости с открытыми стандартами и отсутствию собственнических элементов, т.е. полной совместимости между несколькими поставщиками и производителями, увеличивают свободу выбора будущих закупок. Когда совместимость с ранее приобретенными системами требует совместимости с проприетарными технологиям, это может работать против совместимости между поставщиками и производителями. Такое взаимодействие необходимо для устойчивости и долгосрочной экономической эффективности программного обеспечения. В сущности, критерий совместимости, когда есть привязка к ранее приобретённым собственническим решениям, замыкает покупателя на это решение на неопределённое время, делая одноразовую победу его поставщика победой на гораздо больший промежуток времени в процессе будущих закупок. Так как основной принцип государственных закупок заключается в том, что покупка не должна иметь последствий или ограничить выбор покупателя после первоначально планируемого срока эксплуатации после покупки, увековечение такой блокировки является плохой практикой закупок. При определённых условиях может быть допустимо, что предыдущие закупки приводят к будущим закупкам с ограниченным выбором поставщиков, даже с помощью переговоров вместо открытой процедуры. Однако, влияние первоначальной закупки на ограничение выбора в процессе будущих закупок никогда не должно растягиваться по времени за пределы последнего периода ассигнований, предусмотренного в первоначальной закупке. Решения о таких долгосрочных блокировках принимаются часто не в процессе закупок, в результате чего во многих тендерах запрашивается определённое ПО от определённых поставщиков. Действительно, Европейская Комиссия сама подтвердила, что "[согласно] правилам ЕС по госзакупкам, заказчики могут ссылаться на торговую марку, чтобы описать продукт только тогда, когда не существует других описаний, которые одинаково достаточно точны и понятны всем возможным участникам торгов" 13. В результате этого, не является возможным ссылаться на тип процессоров "Intel или его эквивалент" в тендерах. Бизнес-модель / модель обслуживания Потребности ИТ-архитектуры и организации определяют наилучшую форму, в которой ИТ решения должны быть структурированы, и это также включает в себя то, каким именно способом они должны быть оплачены и учтены. В результате, некоторые бизнес-модели и модели обслуживания естественным образом лучше подходят для определённого набора требований, которые определяются госорганом до процесса закупки. По сути это не отличается от других областей закупок. Госорган может принять решение, что он хочет купить автомобиль, или взять его в лизинг; оплатить строительство моста фиксированной суммой, или выбрать модель "строительство-эксплуатация-передача". Все эти варианты приводят к дискриминации части бизнес-моделей и предпочтению каких-то одних бизнес моделей по сравнению с другими - просто потому, что заданный набор требований лучше подходит для предприятий с определённой бизнес-моделью. Предприятия, которые используют бизнес-модели, неспособные удовлетворить потребности государственных органов, естественно проигрывают. Лизинговые компании проигрывают, если потребностям госорганизации соответствует покупка, а не аренда автомобилей. Это не противоречит принципам равного отношения и недискриминации. И наоборот, предпочтение в пользу какого-то определённого поставщика нарушает эти принципы. Определение для закупок требований, основанных на конкретных потребностях, однако, находится в полном соответствии с этими принципами, даже если эти потребности могут быть удовлетворены только с помощью определенных бизнес-моделей. Аналогичным образом, когда речь об ИТ, органы государственной власти свободны в выборе решений, которые отвечают их потребностям. Часто, такой выбор (и дискриминация) подразумевается по умолчанию. Например, тендер на приобретение лицензий на ПО является "дискриминационным" в отношении поставщиков, которые не предлагают ПО как продукт, который оплачивается в момент покупки через лицензирование. Тендер по закупке ПО, которое может быть изменено, адаптировано и распространено покупателем (СПО чётко подходит под описание) является "дискриминационным" относительно поставщиков, которые работают по модели лицензирования собственнического ПО для определённого количества компьютеров. Конечно, поставщики могут использовать множество различных бизнес-моделей и могут адаптировать свои модели для более полного удовлетворения потребностей клиентов. Со стороны госорганов не существует никаких обязательств адаптировать свои требования под бизнес-модели отдельных поставщиков. Открытые стандарты Открытые стандарты при приобретении ИТ услуг или ПО могут быть предпочтительными или обязательными. Как было сказано в предыдущем разделе, по этому вопросу нет единой политики на всей территории ЕС. Возможным исключением являются услуги электронного правительства, относительно которых есть несколько Деклараций Министров, содержащих призывы использовать открытые стандарты, чтобы граждане могли использовать услуги не будучи привязаны к конкретному поставщику. С чёткой политикой на национальном уровне, или без неё, открытые стандарты могут быть предпочтительными или требоваться согласно политики конкретных местных районов, или для отдельных категорий закупок. Открытые стандарты могут принимать форму функционального требования: например, одной из основных функций новой веб-службы электронного правительства может быть то, что все граждане имеют возможность в полной мере взаимодействовать с ним, без привязки к определённому поставщику программного или аппаратного обеспечения. Открытые стандарты могут принимать форму технических требований: например в случае, когда открытые стандарты уже используются и новое приобретение должно быть с ними совместимо. Открытые стандарты могут также принимать форму требований, которые влияют на бизнес-модели: например, государственный орган желает иметь полную свободу вечно пользоваться файлами данных, создаваемых новыми приложениями, без бессрочной привязки к поставщику программного обеспечения. Открытые стандарты могут иметь важное значение для совместимости продуктов и систем от нескольких поставщиков, и, таким образом, важное значение для ИТ-архитектуры, которая остается под контролем клиента. Это является причиной, по которой стоит акцентировать внимание на открытых стандартах, и, на более высоком уровне, соглашениями по интероперабельности в European Interoperability Framework.14 В то время, как требования открытых стандартов могут быть определены для тендеров в терминах их функциональных, технических или бизнес-потребностей, сами стандарты являются технически сложной сущностью, для которой определяемую ей функциональность может быть очень трудно описать. На практике при закупках проще ссылаться на стандарты по названию, или ссылаться на список стандартов, которые были рассмотрены и признаны подходящими под требования. Это является необходимым согласно Директиве По Техническим Стандартам и Правилам 98/34/ЕС (с изменениями от 98/48/EC) по техническим стандартам в целом (которые могут и не быть открытыми). Это также является практикой и в отношении открытых стандартов в Нидерландах, где правительство поддерживает список открытых стандартов. Однако, когда на местах не существует ни политики по отношению к открытым стандартам, ни списка стандартов, подходящих под определённые технические требования, может быть целесообразным предусмотреть некоторые детали, описывающие свойства стандарта (например, открытость) в функциональных требованиях и критериях определения победителя. Следует ещё раз подчеркнуть различие между открытыми стандартами и открытым ПО. Открытые стандарты могут быть одинаково хорошо реализованы и открытым и проприетарным ПО — и многое проприетарное ПО реализует многие открытые стандарты. Для целей этого руководства, главное свойство открытых стандартов заключается в том, что связанные права на интеллектуальную собственность (патенты, копирайты) лицензированы таким образом, что делают возможной открытую реализацию. Наконец, открытое ПО не подразумевает использование открытых стандартов; аналогично проприетарное ПО не подразумевает использования закрытых стандартов. Открытый код Как было сказано выше, не существует общеевропейской политики по вопросу закупки программного обеспечения с открытым исходным кодом. Существует несколько принципов функционирования государственных органов, которые могут оправдать требование программного обеспечения с открытым исходным кодом. Приобретение ПО с открытым исходным кодом может быть сделано на основе такого обоснования; в тендерах не рекомендуется вносить общее требование, что ПО должно быть с открытым исходным кодом. Как и в отношении открытых стандартов, приобретение ПО с открытым исходным кодом может быть обосновано с точки зрения функциональных требований, технических требований и требований бизнес-модели. Примеры, приведенные выше для открытых стандартов, в некоторой степени могут распространяется также и на ПО с открытым исходным кодом. Существуют обоснования, связанные именно с открытым исходным кодом. В качестве функционального требования, государственный орган, возможно, пожелает обеспечить прозрачность процессов управления. Многие из этих процессов - например, специфичные для системы голосования - реализованы в программном обеспечении, и единственным способом обеспечить его прозрачность может быть требование, что исходный код должен быть доступен для проверки общественностью. В качестве технических требований, государственный орган, возможно, пожелает иметь возможность модифицировать программное обеспечение (или дать возможность любой третьей стороне по своему выбору изменять его) в будущем для того, чтобы работать с другим программным обеспечением, или адаптировать его к будущим потребностям. В качестве бизнес-требования госорган, возможно, пожелает иметь возможность распространять ПО внутри организации или за пределами, отдельным лицам или учреждениям, с которыми он взаимодействует, без дополнительных расходов, основанных на количестве пользователей. Кроме того, госорган может иметь возможность вносить изменения в ПО (или перепоручать это выбранной им третьей стороне) перед распространением. Такие требования, если оправданы, совершенно законны, и могут быть эффективными требованиями в пользу открытого ПО. В случае, если возможность распространять ПО является требованием, госорган должен решить, хочет ли он иметь возможность перепоручать третьей стороне модифицировать и распространять ПО так, как если бы оно было собственническим. Это даст возможность определить тип лицензии, которая должна быть использована при распространении: разрешительный (в случае если решено, что модификации могут быть сделаны проприетарными) или эквивалентный (в случае, если будет решено, что любое распространяемое третьей стороной ПО должно оставаться модифицируемым и распространяемым). И наконец, особенно в случае, если госорган хочет распространять ПО, передавая его другим организациям, предприятиям или гражданам, законными являются требования защитить администрацию от ответственности, гарантийных обязательств и обязательств по техподдержке распространяемого ПО. Перечисленные выше требования, связанные с распространением, помогают определить требуемый тип лицензии. Как уже говорилось в разделе 2.4.1 «Определение требований», определение типа лицензии на раннем этапе (или диапазона возможных лицензий) имеет важное значение.

[править] 2.2.3 Изучение затрат и выгод

Госорганизации должны соблюдать общественный интерес, и в аспекте закупок это означает, что средства должны расходоваться максимально эффективно. Свободные от краткосрочных обязательств по сравнению с частным сектором, госорганизации также обязаны максимизировать эффективность в долгосрочной перспективе. Однако, имея ограничения в рамках бюджетных периодов, они должны находить хороший баланс между оптимизацией первоначальных инвестиций и оптимизацией общих расходов в долгосрочной перспективе. Несмотря на то, что это может быть трудно осуществить, всё же возможно оценить расходы в долгосрочной перспективе, чтобы убедиться, что налогоплательщики получат максимально возможный результат за свои деньги. Важно обеспечить, чтобы решения, которые хорошо выглядят в краткосрочной перспективе не привели к росту расходов и ограничению выбора в долгосрочной перспективе. Долгосрочные расходы Лицензии на открытое ПО могут быть доступны бесплатно. Конечно, это не означает, что владение открытым ПО является бесплатным. Некоторые расходы могут быть вовлечены в обеспечение работы ПО, включая расходы на аппаратное обеспечение, поддержку и обслуживание, обучение и другие услуги. "Стоимость выхода" также является важным фактором: затраты, понесённые при переходе на другую ИТ систему, должны учитываться не как расходы, включаемые в стоимость новой системы, но как расходы, включаемые в стоимость старой системы. В конце концов, если старая система была основана на открытых стандартах, миграция будет не слишком дорогой, таким образом, стоимость перехода накладывается на используемую, старую систему. Даже если лицензии на открытое ПО полностью бесплатны (и поэтому даже не требуют проведения тендера для их получения, т.к. могут быть просто скачаны госорганизациями: см. следующий раздел), эти побочные расходы необходимо оценить в долгосрочной перспективе. Аналогичные соображения могут быть приняты во внимание при оценке проприетарного ПО, которое также требует расходов на аппаратное обеспечение, поддержку, настройку, обучение и другие услуги. Кроме того, при расчёте затрат на проприетарное ПО должна учитываться частота и стоимость покупки обновлений. Обычно, в процессе закупки заявляется определённый период времени. Подразумевается, что все расходы, связанные с закупаемым ПО, которые будут понесены в течение этого периода, такие как расходы на обновление, будут приняты во внимание при оценке заявок. Основное предположение нормальной процедуры закупок заключается в том, что по окончанию заявленного периода госорганизация-покупатель не имеет договорных обязательств по отношению к поставщику. Когда закупается ПО, основанное на проприетарных стандартах и проприетарных интерфейсах, это предположение нарушается. Хотя по окончанию срока действия первоначального договора всякие договорные обязательства по отношению к поставщику перестают существовать , технические и финансовые затраты перехода на систему другого поставщика, или даже приобретение техподдержки от другого независимого поставщика, могут быть очень велики. ПО используется для создания документов, баз данных и программ, которые в госсекторе могут иметь время жизни, намного превышающий период времени, оговоренный в процедуре закупки. Если приобретённое ПО затрудняет использование созданных с его помощью документов, баз данных и программ с аналогичным ПО других производителей, то следует иметь в виду, что "цена выхода", то есть цена перехода с закупленного ПО на какое-то другое, очень высока. Проприетарное ПО подразумевает высокую стоимость перехода на ПО от другого поставщика. Таким образом, предположение о том, что все расходы и обязательства, связанные с закупкой, будут завершены после определённого в процессе закупки срока, является несостоятельным в отношении ПО. Договорные обязательства не распространяются за пределы срока первоначальной закупки ПО, но необходимость государственной организации в дальнейшем использовать данные и приложения означает, что в игру также вступают технические обязательства. Собственнические стандарты приводят к техническим обязательствам, а по сути, к договорным обязательствам - это объясняет тот факт, что многие госорганизации публикуют тендеры на ПО, описывающие предмет поставки с помощью определённой торговой марки. Они делают это потому, что рассчитанная "стоимость выхода" для них непозволительно высока. Поскольку важным принципом ИТ-систем госсектора является устойчивость и независимость, возможность смены поставщиков и систем в будущем очень важна, и цена такого перехода должна быть включена в цену закупаемого ПО. Отсюда и термин стоимость выхода, т.к. эти расходы в основном результат решений по техническим аспектам и аспектам, связанным с бизнес-моделями, принятыми поставщиком оригинального ПО. Первоначальный выбор проприетарного ПО, особенно если оно основано на проприетарных стандартах или реализует стандарты таким образом, что они несовместимы с ПО других поставщиков, может ограничивать будущий выбор ПО. Например, разовое, предположительно конкурентноспособное приобретение проприетарной системы для веб-сервера может привести к тому, что все дальнейшие дополнения функциональности веб-сайта должны быть сделаны на базе той же проприетарной системы. Это не только ограничивает дальнейший выбор госоргана, закупившего данное ПО, но также ограничивает и выбор граждан, предприятий и других будущих подрядчиков, разрабатывающих дополнения для сайта, вынуждая их быть клиентами поставщика оригинального программного обеспечения, которое приобретено госорганом. Такие долгосрочные издержки проприетарного ПО часто не учитываются в процессе оценки, но имеют важное значение для устойчивого, эффективного использования государственных средств. Короче говоря, долговременная зависимость от конкретного поставщика, распространяющаяся за пределы отдельных процедур закупок - это плохая практика, и, возможно, находится за рамками правил. Следует избегать любого решения, например, последующей закупки, усиливающей зависимость от конкретного поставщика, т.к. это влечёт только увеличение "стоимости выхода". Обратите внимание, что аргумент включения "цены выхода" в оценку общей стоимости предложения, единственно существенный для открытых стандартов, но не обязательно существенный для открытого ПО.15 Так как "цену выхода" может быть трудно рассчитать в момент закупки, выбор ПО, которое полностью совместимо с открытыми стандартами может быть путём для того, чтобы избежать эффекта привязки, о котором говорилось выше. Долгосрочные выгоды (устойчивость), дополнительные услуги Как и затраты, выгоды также должны оцениваться в долгосрочной перспективе. Закупка нового ПО на основании его совместимости с ранее приобретённым ПО может казаться более разумной с точки зрения экономии расходов на переход и обучение. Но если это ПО является проприетарным, и не полностью основано на стандартах и протоколах, полностью и бесплатно поддерживаемыми другими независимыми поставщиками, "цена выхода" и связанные с этим расходы могут значительно увеличиваться в долгосрочной перспективе. Зависимость организации от поставщика увеличивается. Таким образом, выгода в краткосрочной перспективе становится ничтожной, если её рассматривать в долгосрочной перспективе. Приобретение ПО, являющегося полностью открытым и поддерживаемым несколькими независимыми поставщиками, поначалу может казаться имеющим мало преимуществ, особенно если такая закупка требует детального изучения рынка (например, скачивания открытого ПО или определения открытых стандартов в случае, когда допускается возможность закупки проприетарного ПО). Это может потребовать более подробных спецификаций по закупке, таких как функциональные требования. Преимущества наличия независимости и устойчивости также не являются очевидными в краткосрочной перспективе. Однако, в долгосрочной перспективе возможность поменять поставщика на другого, не зависящего от первоначального поставщика, является ключом к устойчивости и независимости государственного органа и потому преимущества такого выбора с точки зрения долгосрочной перспективы являются намного большими. Исследование и оценка Совокупной стоимости владения (TCO). Совокупная стоимость владения (TCO) это термин, часто используемый в отношении процесса закупки ПО. Однако существует несколько различных методик, и лишь немногие из них включают все долгосрочные расходы, связанные с покупкой ПО, такие как расходы на необходимость регулярного обновления, или "цену выхода" или перехода на другое ПО. Поэтому достаточно сложно использовать исследования TCO, или даже сравнивать их. Более того, такие исследования редко измеряют что-то за пределами количественных оценок; преимущества гибкости, независимости и прозрачности, важные для госорганизации, очень трудно поддаются оценке. Таким образом, целесообразным является анализ затрат и выгод в долгосрочной перспективе, нежели использование исследований TCO.

[править] 2.2.4 Скачивать или покупать ?

Подзаконные акты о закупках, особенно Европейская Директива 2004/18/ЕС, предписывают, что приобретение чего-либо, в том числе ПО, должно происходить через публичный контракт, то есть формальный процесс закупок, например такой, как тендер. Как отмечается в правовом анализе Голландского Правительства, "Получение (открытого) ПО", получение открытого ПО может и не требовать тендера. Это касается ситуаций, когда такое ПО может быть получено бесплатно, т.е. не только без лицензионных платежей, но и без каких-либо обязательных платежей, таких как оплата документации, носителей или услуг. Таким образом, бесплатное скачивание открытого ПО из интернета является средством приобретения ПО, которое не требует публичного контракта. Это верно, даже если приобретающая организация хотела бы в будущем, отдельно приобретать платные услуги и поддержку. Для таких платных услуг, конечно, потребуется публичный контрактный процесс. Правила не требуют, чтобы приобретение ПО и услуг рассматривалось как единое целое (на что должен быть размещён тендер), если само ПО может быть получено бесплатно, и если данное приобретение является независимым и не требует приобретения тех услуг. Конечно же, ответственный госорган не будет просто скачивать ПО из интернета без оценки его пригодности под потребности организации. Выбор получения ПО с помощью скачивания и последующего после этого тендера о закупке обслуживания и поддержки является одним из многих вариантов, которые должны быть рассмотрены в процессе определения требований. В следующих двух разделах описываются два способа получения ПО с открытым кодом, когда было принято решение, что требования ПО с открытым исходным кодом соответствует потребностям организации, и был сделан выбор в отношении способа получения ПО: загрузка или закупка с помощью тендера. Разница между этими двумя подходами с точки зрения усилий, которые должны быть приложены организацией обобщена в приведённой ниже таблице, составленной на основе голландского руководства. Бесплатное скачивание Покупка Больший акцент на маркетинговые исследования Большее внимание спецификациям Организации требуются соответствующие знания для того, чтобы получить (скачать) подходящее ПО. Претенденты предоставляют некоторые знания, несмотря на то, что подготовка спецификаций тендера также может требовать значительных знаний Услуги должны закупаться на отдельных тендерах ПО и услуги могут быть включены в один тендер

[править] 2.3 Скачивание открытого ПО

Когда госорганизация решила, что требования открытого ПО в конкретном случае особенно важны, можно следовать процессу, описанному в данном разделе. Этот процесс завершится загрузкой госорганизацией ПО без каких-либо затрат. Коммерческие услуги по обслуживанию и поддержке, если потребуется, могут быть закуплены отдельно. Обратите внимание, что данный процесс может быть прерван в любой момент - например, если не удаётся найти или оценить ПО, или если после его скачивания оно определяется непригодным по какой-то причине. В этот момент можно пойти другим путём, описанным в следующем разделе, путём закупки открытого ПО на тендере. Более того, авторы рекомендуют метод скачивания открытого ПО как неотъемлемую процедуру получения такого ПО. Это не означает, что авторы рекомендуют отдельным сотрудникам организации скачивать всё, что угодно. Как часть процесса приобретения, скачивание ПО происходит после всех шагов, описанных выше, т.е. определения требований, и является просто альтернативой публикации тендера на поставку ПО. Оно не предлагается здесь в качестве альтернативы процессу управляемого, хорошо обоснованного и отслеживаемого процесса получения ПО. Отметим, что бесконтрольное скачивание ПО - открытого, или проприетарного - отдельными сотрудниками в рамках организации может привести к возникновению ряда рисков, как юридических (ответственность за нарушение авторских прав), так и технических (например, безопасность). Хорошо управляемый процесс скачивания открытого ПО, который предлагается здесь - это совершенно другой случай, т.к. является частью структурированного процесса получения ПО.

[править] 2.3.1 Источники ПО

Открытое ПО может распространяться кем угодно, поэтому существует много источников для скачивания большинства приложений с открытым кодом из интернета. Существует ряд вопросов, которые должны быть приняты во внимание. Хотя они и не очень отличаются от вопросов, которые необходимо учитывать при выборе проприетарного ПО, всё же стоит их рассмотреть. Сообщество и язык При выборе проприетарного ПО полезно узнавать о поставщике и сети поддержки ПО. Хотя оценка тендерных заявок производится на основе документов, предоставляемых с предложениями, государственным учреждениям, возможно, уже может быть известно о решениях, доступных на рынке благодаря взаимодействию с поставщиками, анализу статей в прессе, журналам, отчетам аналитиков и т.д. Для ПО с открытым исходным кодом процесс ознакомления схож, кроме того, что может быть более полезным общение с сообществом, стоящим за определённым открытым ПО, нежели с конкретным поставщиком. Так как открытое ПО может модифицироваться и распространяться, обычно каждое обладает сообществом, сформированным вокруг него, состоящим из отдельных людей, организаций и других субъектов - возможно, даже госорганизаций - предоставляющих обновления, обслуживание и поддержку. Часто существует сообщество пользователей и разработчиков, которые общаются друг с другом и предоставляют определённый уровень взаимной поддержки бесплатно. Действительно, одной из целей Обсерватории Открытого ПО ЕС (OSOR) является содействие таким сообществам, существующим вокруг ПО, имеющего особое значение для европейского госсектора - OSOR даже размещает на своих серверах некоторые сообщества. Похожие платформы для сотрудничества в области открытого ПО имеются в таких странах, как Франция, Италия, Испания, Швеция и др. Кроме того, большинство проектов открытого ПО предоставляют лёгкий доступ к своим сообществам, и очень часто во многих странах существуют местные сообщества. Открытое ПО особенно подходит под требования обеспечения многоязычной локализации, т.к. свобода вносить изменения и распространять ПО позволяет легко добавить поддержку языка в ПО людям, которые используют это ПО и владеют языком. Полезно изучать степень поддержки местных языков в ПО. Наконец, полезным является поиск и идентификация местных групп поддержки открытого ПО. Поддержка и надёжность Открытое ПО, как и любое другое ПО, различается по уровню доступной поддержки и надёжности. Для ПО с открытым кодом, в частности, сообщества могут предоставлять достаточно высокий уровень поддержки бесплатно. Это не может быть практичным вариантом, кроме как для самых небольших организаций (или, наоборот, крупных учреждений с большим багажом IT навыков). Однако, это означает, что ПО может быть скачано и протестировано, если потребуется, то с помощью сообщества, до того, как будут приняты любые решения за или против его развёртывания (и, возможно, закупке коммерческих услуг по техподдержке). Для многих открытых приложений получать техподдержку от сообщества можно на порядок быстрее, нежели поддержку удалённого поставщика. Кроме того, сообщество может предоставлять обновления программного обеспечения, что делает исправления ошибок гораздо более быстрым, чем это происходит для большинства проприетарных приложений. В действительности, даже коммерческие поставщики открытого ПО часто полагаются на бесплатную поддержку сообщества, сочетая её с собственным опытом. Есть также ряд моделей качества, в том числе полуавтоматические инструменты, которые обеспечивают различные метрики качества ПО с открытым кодом и его сообщества (например, скорость исправления ошибок, размер и скорость роста сообщества и т.д.)16. По причине открытости процесса разработки, такие показатели могут быть гораздо более объективными и верифицируемыми, чем аналогичные показатели качества для проприетарного ПО17. Тем не менее, авторы отмечают, что применение таких моделей является сложной задачей, и государственные учреждения редко тестируют проприетарное программного обеспечение с помощью моделей качества, так что тестирование с помощью них открытого ПО может не быть необходимым, даже несмотря на то, что для открытого ПО это проще сделать. Репозитории Открытое ПО на самом деле скачивается из репозиториев или каталогов, таких как freshmeat.net, sourceforge.org, opensourcexs.info и osalt.com. Сообщества часто располагаются на той же площадке, и привязаны к репозиторию. Важным аспектом портала OSOR является предоставление простого способа поиска и получения открытого ПО для различных нужд госорганизаций. OSOR обеспечивает доступ к проблемно-ориентированному ПО для европейского государственного сектора, а также к ограниченному количеству программ, размещенных в других хранилищах. Наличие сообществ коллег - ИТ персонала европейского госсектора и поставщиков, которые поддерживают их - делает OSOR очевидным источником для подхода "получение с помощью скачивания". Это также делает гораздо более простым процесс оценки ПО, так как мнения и опыт нескольких государственных ИТ специалистов могут быть доступны на сайте. Заметим, что эти задачи не обязательно должны быть выполнены в рамках самой организации. Они могут быть выполнены и на контрактной основе, как описано ниже.

[править] 2.3.2 Идентификация и выбор ПО

Когда несколько открытых приложений удовлетворяют потребности организации, можно произвести процедуру оценки и выбора. Это может служить и в качестве фильтра общей надёжности и качества, как описано выше, в том числе и по таким вопросам, как зрелость, размер сообщества, наличие коммерческой поддержки из различных источников, и т.д. И, наконец, выбор программного обеспечения основывается на его соответствию ранее определенным функциональным требованиям. Функциональные требования могут быть сопоставлены с документацией по программному обеспечению - сайту, руководству пользователя и т.д. Кроме того, открытое ПО может быть просто скачано и протестировано - без развёртывания, или в пробном развёртывании - для того, чтобы изучить, в какой мере оно отвечает функциональным требованиям18. Наконец, может быть выполнен анализ затрат на соответствие функциональных требований открытым ПО. Может быть выбрано решение, которое является наиболее экономически эффективным, с учетом всей совокупности критериев, о которых говорилось выше. Если решения, выбранные в рамках этого процесса являются неподходящими, то можно отказаться от процедуры получения ПО с помощью скачивания и вместо неё воспользоваться процедурой тендера по закупке открытого ПО, как это описано в следующем разделе. Заметим, что эти задачи не обязательно должны быть выполнены в рамках самой организации. Они могут быть выполнены и на контрактной основе, как описано ниже.

[править] 2.3.3 Тендеры для оценки, поддержки, настройки, услуг

Бесплатное скачивание ПО не означает, что не будет никаких связанных с ним расходов. Хотя в некоторых случаях организация сама может осуществлять поддержку ПО , часто может иметь смысл получить эту услугу по контракту. Естественно, это потребует процедуры тендера. Процесс идентификации, оценки и выбора ПО для скачивания необязательно должен быть полностью выполнен в рамках госорганизации. В зависимости от имеющихся навыков и ресурсов, может быть полезно заключить публичный договор для некоторых из этих задач. Условием такого тендера может быть требование исключить победителя из дальнейших контрактов (например, по услугам поддержки и обслуживания) связанных с ПО, выбранным при их участии, чтобы избежать конфликта интересов и обеспечить их роль в качестве честного оценщика доступных для скачивания вариантов ПО19. Конечно, новый конкурс не является необходимым для каждого отдельного случая выбора ПО. Эта помощь по оценке и выбору также может быть выполнена фирмой с уже существующим контрактом на предоставление таких консультационных услуг, хотя такие фирмы должны быть также исключены из списка поставщиков услуг, связанных с ПО, которое они помогут выбрать. Когда состоялся окончательный выбор варианта ПО для скачивания, с помощью или без помощи подрядчика, ПО должно быть установлено, а затем должно настраиваться и поддерживаться. Обратите внимание, что скачивание ПО без каких-либо контрактов является бесплатным, но это также означает, что ПО приходит без каких-либо гарантий. На практике, то же самое относится и к проприетарному ПО, особенно "коробочному", где в лицензии обычно присутствует отказ от гарантий. Как и с проприетарным ПО, заключение сервисного контракта, или контракта по обеспечению качества, является главным способом для госорганизации разделить часть ответственности по использованию открытого ПО. ПО может быть доработано - широчайшие возможности по доработке являются ключевым преимуществом открытого ПО, и возможность доработки может быть одной из основных причин, по которой госорганизация выбирает открытое ПО в первую очередь. Хотя какая-то бесплатная поддержка может быть получена от сообщества, включая специализированные сообщества, такие как OSOR, в случае ПО для госсектора, обычно выбирается оплачиваемый поставщик. Для выбора поставщиков всех дополнительных услуг должны использоваться открытые, конкурентные тендеры. В целях содействия сообществу разработчиков выбранного ПО, может быть полезным в качестве весомого критерия принимать в учёт уровень взаимодействия и вклад участника торгов в соответствующее сообщество. Ключевым свойством открытого ПО является то, что любой человек может оказывать поддержку и другие услуги, в зависимости от его квалификации. Таким образом, рынок полностью конкурентоспособен. Не существует собственнического контроля или преимущества у "владельца" или "спонсора" или их дилеров и агентов. В тендере на закупку проприетарного ПО или услуг, который работает против конкуренции на рынке и может привести к нарушению подзаконных актов о закупках, может участвовать только собственник или дилеры, обязательно от него зависящие. В тендере на поставку открытого ПО может участвовать любой поставщик. Разница тут такова, как между тендером на поставку автомобилей Пежо или услуг для автомобилей Пежо (в которых могут участвовать только фирмы, зависящие от Пежо) и тендером на поставку топлива и шиномонтажного сервиса для автомобилей (в котором может участвовать кто угодно, без привязки к определённому поставщику автомобилей). Тем не менее, возможны ситуации, в которых благодаря расположению, размеру рынка конкретного приложения с открытым кодом, или по другим причинам, существуют всего несколько поставщиков услуг. Если это так, и есть основания полагать, что конкурс на поставку таких услуг ограничен, государственная организация может организовать тендер в несколько этапов, разделённых во времени, что позволит дать время для развития конкурирующих поставщиков. Например, госорганизация может провести разные тендеры на оценку ПО, доработку, установку, периодические контракты по техподдержке, сопровождаемые или предпочтительно предшествующие публичной оглаской относительно предполагаемого использования этого ПО. Это дает больше шансов потенциальным поставщикам заранее подготовиться к поддержке этого ПО. Однако, если есть сомнения относительно конкурентного потенциала на поставку услуг для определённого ПО, то в этом случае лучше не скачивать это ПО; скорее и поставка этого ПО и связанные с ним услуги должны быть приобретены на тендере, как описано в следующем разделе.

[править] 2.4 Покупка ПО с открытым исходным кодом

Можно ли создавать тендер на поставку определённого открытого ПО ? Простой, практический ответ - да. Практика создания тендеров для конкретных проприетарных приложений широко распространена, хотя участие в таких тендерах возможно только для собственников такого ПО или их посредников. Это может быть вне правил, но тендер на поставку конкретного ПО с открытым кодом меньше нарушает эти правила, так как не ограничивает участие одним поставщиком и каждый может участвовать. Отметим, что тендер только на поставку (а не обслуживание) конкретного ПО с открытым кодом может быть бессмысленным, т.к. ПО может быть скачано бесплатно, но вышеуказанный аргумент также применим и к тендерам на поставку и установку, интеграцию и поддержку конкретных открытых продуктов. Это руководство о поощрении хороших практик, которые чётко отвечают правилам закупок и обеспечивают конкурентный и прозрачный процесс закупок. Поэтому авторы не рекомендуют открывать тендер на поставку и обслуживание конкретного открытого ПО. Авторы даже не рекомендуют открывать тендер на неопределённое заранее ПО, с “открытым кодом” в качестве одного из критериев выбора. Как уже говорилось в предыдущем разделе, авторы рекомендуют лучшие практики закупок на основе определения функциональных требований - которые могут включать в себя свойства, эквивалентные характеристикам ПО с открытым исходным кодом, или характеристикам открытых стандартов.

[править] 2.4.1 Определение требований

Тендер на поставку открытого ПО - как и любой другой тендер - должен быть основан на функциональных требованиях, а не на указании конкретных продуктов или поставщиков. Свойства открытых стандартов и открытого ПО могут быть частью этих требований - либо в качестве минимальных требований, или свойств, которые будут предпочтительными. Функциональные требования Авторы рекомендуют на тендере детально указывать функции ПО, чтобы убедиться в прозрачности и объективности процесса закупки. Предназначение закупаемого ПО и его основные атрибуты должны быть описаны нейтральным относительно поставщика образом. Это общий принцип госзакупок; здесь в центре внимания авторов дополнительные функциональные требования, связанные с основными свойствами открытого ПО и открытых стандартов. Важно различать открытые стандарты и открытое ПО. Тендер может требовать или предпочитать свойства, относящиеся либо к чему-то одному, либо и к тому и другому. Стандарты являются техническими спецификациями. У открытых стандартов также имеются и нетехнические свойства, связанные с тем, как эти стандарты контролируются и развиваются. Требования открытого ПО существенно нетехнические, связаны с условиями лицензирования, регулирующими использование ПО. Открытые стандарты Официальные европейские стандарты могут быть необходимыми как часть технической спецификации в тендере, также как и национальные стандарты в той области, где не существует европейских стандартов. Тендер также может включать технические характеристики желаемого стандарта. На практике, так как техническая сложность стандартов может быть очень высокой, на стандарты ссылаются по имени, даже если эти стандарты не являются официальными (как обстоит дело в случае с несколькими общими стандартами интернета, такими как HTML). При условии, что это оправдано требованиями обеспечения интероперабельности закупающей организации (смотрите в разделе 2.2 описание соглашений об интероперабельности и их влиянии на ИТ архитектуру), открытые стандарты могут быть необходимым условием, как и в целом стандарты. Требование открытых стандартов может быть выражено именем стандарта или ссылкой на официальный список открытых стандартов. Однако, если не существует определения стандартов, применимых к нуждам закупающего госоргана, или нет официального списка открытых стандартов, на который можно сослаться, стандарт может быть определен в терминах функциональных спецификаций. В этом случае может быть необходимым допускать к участию предложения, которые используют технологии, "эквивалентные" с технической точки зрения, но не имеющие желаемых свойств открытости. Поэтому эти свойства открытости могут быть включены в число спецификаций тендера. Таким образом, открытость стандартов может быть указана в виде предпочтения (указанием веса, придаваемого ей при расчёте итоговой оценки) или в виде требования (устанавливая её обязательность в спецификации). Открытость используемых стандартов может быть полезным выигрышным критерием там, где с технических требованиях не указаны конкретные стандарты - например, в случае, когда в тендере не указаны технические спецификации и ожидается, что они будут предоставлены участниками. В таких случаях могут быть представлены предложения, использующие разные технические стандарты, и обязательные или весовые критерии оценки относительно открытости предлагаемых технологий могут быть использованы для оценки соотношения цена/качество. Включить требования открытых стандартов или их предпочтений в описании тендера очень просто: могут быть описаны свойства открытых стандартов, и, если требуется, то вместе с обоснованием. Так как обоснование является частью основных потребностей, как определяется госорганизацией, специальное определение термина "открытые стандарты" полезно, но менее важно. Для ПО потребности госорганизации, как правило, могут требовать, чтобы: стандарт был реализуем всеми потенциальными поставщиками эквивалентных технологий, обеспечена устойчивость и полная соревновательность без каких-либо преимуществ для игроков, основанных на патентах или авторских вознаграждениях или ограниченной доступности технических спецификаций; кроме того, стандарт не должен дискриминировать решения на базе открытого кода20. развитие стандарта является открытым и прозрачным, что делает госорганизацию независимой от какой-либо стороны при будущем развитии стандарта, и даёт госорганизации возможность повлиять на его дальнейшее развитие нет ограничений на повторное использование, так что государственный орган может быть уверен, что другие государственные или частные организации могут использовать стандарт, и что использование стандарта в открытых решениях - которые часто несовместимы с ограничениями на повторное использование - возможно. Заметим, что типичные потребности госорганизации могут быть удовлетворены стандартами, которые подпадают под определение открытых стандартов, содержащееся в EIF и многих других источниках. Открытый код Как уже упоминалось в начале этого раздела, не является хорошей практикой всего лишь указывать, что ПО должно быть открытым. Напротив, свойства ПО с открытым исходным кодом должны быть описаны и обоснованы. Открытость кода не является неотъемлемой частью технических свойств ПО, она относится к условиям, на которых предоставляется ПО. Таким образом, заданные свойства открытого кода могут быть включены в виде обязательных требований в описание предмета контракта, или в контрактные документы (cahier de charges). Открытость кода может быть включена в виде пожелания, а не обязательного требования путём включения свойства открытости в виде весового критерия формулы определения победителя. Включение необходимости или предпочтения открытости в требования делается просто: могут быть описаны свойства открытого кода, и, если это требуется, вместе с обоснованием. Потребности госорганизации, как правило, могут включать в себя: собственность на ПО передается госорганизации, без каких-либо ограничений на то, что она может делать с этим ПО; ИЛИ:21 ПО может быть использовано для любых целей, так как госорганизация не хочет быть ограниченной в том, как она сама (или, с её позволения, другие) использует это ПО госорганизация или третье лицо, выбранное ей, могут изучать исходный код ПО, так как госорганизация хочет быть уверена в том, что ПО функционирует надлежащим образом; кроме того, госорганизация может потребовать, чтобы любой представитель общественности мог изучить исходный код, с тем, чтобы содействовать повышению транспарентности деятельности правительства, или чтобы дать возможность третьим сторонам оказывать поддержку и обучение, связанные с ПО. госорганизация или третье лицо по её выбору может изменить ПО, так как госорганизация не желает зависеть от оригинального поставщика при исправлении ошибок, адаптации и других модификациях госорганизация может распространять ПО с исходным кодом и модификациями кому угодно по её выбору и предоставлять получателям те же самые возможности использования, изучения, модификации и распространения, потому что госорганизация должна быть уверена, что граждане, компании и другие организации, которым доступны её услуги при использовании ПО или вариантов этого ПО не должны для этого становиться клиентами оригинального поставщика; например, национальная администрация может хотеть иметь возможность передавать ПО без дополнительных расходов другим администрациям на местном, региональном, национальном или европейском уровне. При поддержке официальной политики на европейском, национальном или местном уровне, такие требования не понадобится явное обосновывать в каждом тендере. Даже напротив, такие критерии должны обосновываться только тогда, когда, например, по этому поводу возникают вопросы, а не каждый раз. Но нет ничего плохого и в том, чтобы предоставлять явное обоснование и ссылки, так как это всегда является хорошей практикой (кратко) объяснить, почему присутствуют определенные критерии. Например, Голландское правительство объясняет предпочтения открытого ПО необходимостью "поощрения равных условий на рынке программного обеспечения и поощрения инноваций и экономии". Открытое ПО для распространения Как описано в разделе 2.2, "Определение требований", госорганизации может хотеть закупить ПО для дальнейшего распространения с другими программными компонентами. В этом случае важно уточнить условия распространения закупленных компонентов, чтобы убедиться, что госорганизации не столкнётся с проблемами лицензирования, сочетая эти отдельно приобретённые компоненты друг с другом для дальнейшего распространения. Для решения таких проблем Испания приняла Королевский Указ 4/2010, реализующий National Interoperability Framework, запланированный в законе об электронном правительстве от 11/200722. В соответствии со статьёй 16.1 этого закона, условия лицензирования приложений, принадлежащих Государственной Администрации, которые могут быть доступны для других администраций или для граждан, должны: позволять свободное использование / повторное использование этих приложений исключать присвоение этих приложений третьими сторонами защищать администрацию от любой ответственности, связанной с этими приложениями, в том числе по техподдержке и от гарантийных обязательств. Поэтому, если принято решение распространять ПО, распространение должно происходить по условиям открытого ПО (в сочетании с сильными условиями невозможности ограничения прав для предотвращения присвоения, которое может случиться если ПО способно стать собственническим) Это означает, что по умолчанию (и по выбору, когда это уместно), испанская администрация будет распространять свое ПО в соответствии с условиями лицензии European Union Public Licence (OSI утвердило эту лицензию, и она имеет одинаковое значение на 22 европейских языках)23.

[править] 2.4.2 Другие требования

В дополнение к техническим и функциональным требованиям и нетехническим свойствам открытого ПО и открытых стандартов, в тендере как правило имеются и другие критерии оценки победителя и определения правомерности их участия в тендере. Хотя большинство из этих критериев, таких как критерии, связанные с уголовными преступлениями, банкротством и так далее, не влияют на закупку открытого ПО, один дополнительный критерий в данном случае всё-таки важен. Таким свойством открытого ПО, которое отличает его от проприетарного ПО является то, что оно может быть предоставлено на равных условиях и маленькими инновационными компаниями, ограниченными только имеющимися в их распоряжении навыками и возможностями, а не их зависимостью от собственника ПО. Тем не менее, небольшие компании могут иметь трудности соответствия строгим критериям в отношении финансовой устойчивости. Выбор критериев финансовой устойчивости (минимальный оборот, капитал) должен быть пропорциональным объёму тендера24. Главным критерием финансовой устойчивости при выборе ПО является уверенность, что поставщик сможет обеспечить поддержку до тех пор, пока используется ПО. Когда речь идёт об открытом ПО, доступность исходного кода гарантирует совместимость и предотвращает зависимость от одного поставщика. Если первоначальный поставщик сворачивает деятельность, ПО может поддерживаться другими; если никто не поддерживает ПО, госорганизация может нанять третью сторону для осуществления поддержки. Эта повышенная устойчивость открытого ПО даёт основания для снижения требований финансовой устойчивости, или снижения их веса при отборе победителя открытого ПО на тендере. Оказание содействия и взаимодействие с сообществом Одним из основных преимуществ открытого ПО является то, что в процессе его разработки, в лучшем его виде, участвуют несколько фирм, частных лиц и других участников. Вклад не ограничивается написанием кода, и включает в себя, например, создание детальных отчётов о требованиях и ошибках. Будем надеяться, что получение открытого ПО будет поощрять госучреждения участвовать в этом процессе, платформа OSOR разработана для того, чтобы помочь в этом. Госорганизации могут оказывать косвенную поддержку сообществу, интересуясь у участников тендера на поставку открытого ПО и услуг для него об их участии и размере вклада в соответствующее сообщества, делая это частью процесса выбора, и/или как часть исполнения контракта. В любом случае, это может быть полезным способом определения уровня знаний открытого ПО и его сообщества участником тендера. Таким образом, может быть полезным учитывать уровень взаимодействия с сообществом и вклад, имеющийся у участника торгов, в качестве весового критерия в тендерах на поставку открытого ПО и/или услуг. Однако, этот критерий следует применять осторожно. Если известно, что только ограниченный круг фирм активно участвует в разработке какого-то открытого продукта, то необходимость поддержки сообщества с помощью поддержки его активных участников должна быть сбалансирована с необходимостью стимулирования конкуренции и многообразия участников; в таких случаях может быть предпочтительнее учитывать вклад в сообщество не в качестве весового критерия выбора, но как демонстрацию качества оказания услуг в процессе выполнения контракта.

[править] 2.4.3 Процесс выбора на тендере

На тендере все предложения должны быть оценены, и выбрано лучшее. Лучшие предложения могут определяться просто по самой низкой предложенной цене, или по лучшему соотношению цены и качества, где соотношение цены к качеству определяется с помощью весовых критериев. В случае льготной политики по отношению к открытому ПО - таких, как "предпочтение открытого ПО в случае равной пригодности" Голландского правительства, если предложения имеют одинаковую цену (в случае когда учитывается цена) или одинаковое соотношение цены и качества, выбирается открытое ПО. Заметим, что такие преференции должны быть обоснованы с точки зрения функциональных и технических спецификаций и не должны создавать препятствий для "открытости процесса госзакупок для конкуренции"25. Так как требования открытости вводятся в действие с целью обеспечения основных потребностей заявки и не приводят к благоприятствованию определённых поставщиков, в отличие от процедур закупки, где указываются конкретные названия или поставщики, в целом они увеличивают степень конкурентности процесса. Любые такие льготные политики, связанные с открытостью, на самом деле не влияют на тендерный процесс, описанный в данном разделе, так как вероятность одинаковых оценок по двум предложениям, вероятно, не высока. Более того, включение требований открытости в рамках тендера не зависит от любой политики относительно открытости ПО в госзакупках; оно не требует наличия каких-либо политик предпочтения и работает в рамках любой процедуры закупок.

[править] 2.5 Заключение

Это руководство объясняет, почему для госорганизаций может быть полезным приобретение ПО с открытым исходным кодом, и что более важно, как они это могут сделать в рамках имеющихся на данный момент положений о закупках, как только такое решение принято. Данное руководство также показывает, как открытое ПО может быть бесплатно скачано даже без проведения тендеров и предоставляет критерии, которые могут быть включены в условия тендера для обеспечения наилучших практик закупки ПО. Имеющаяся на данный момент практика госзакупок далека от "полностью равных условий" и широко распространённая политика размещения тендеров на поставку конкретного собственнического ПО является одним из обоснований того, зачем нужно это руководство. Приложение к документу предоставляет обзор правовых вопросов в сфере государственных закупок программного обеспечения и показывает, как процедуры, изложенные в данном руководстве, соответствуют требованиям законодательства. Наконец, приложение с "готовыми к употреблению" текстами для тендеров имеет целью упростить процесс перевода предложений, содержащихся в данном руководстве, в реальные тендеры. Это руководство о закупке ПО, но авторы отмечают, что одним из свойств открытого ПО является то, что оно способствует сотрудничеству и участию, нежели просто потреблению путем государственных закупок. Обсерватория Открытого ПО ЕС (OSOR) предоставляет платформу для сотрудничества для госорганизаций Европы: от поиска информации об открытом ПО; выбора, оценки и скачивания ПО; получения поддержки от коллег и поставщиков; и даже разработки и выпуска ПО. Авторы призывают к участию в сообществе OSOR на сайте OSOR.eu, чтобы сделать большинство ПО открытым.

[править] A. Шаблоны текстов для тендеров

Это краткое приложение предоставляет некоторые шаблоны текста, который могут быть использован при подготовке тендеров на закупку открытого ПО и ПО, основанного на открытых стандартах. Это приложение следует рассматривать как источник возможной реализации рекомендаций, приведённых в разделе 2.4 главного руководства "Закупка открытого ПО". Естественно, что может потребоваться некоторая адаптация этих текстов для включения их в тендеры, в зависимости от конкретной политики и требований, предъявляемых каждым государственным органом, и каждым тендером. Тексты предоставляются в таком виде, что это позволяет читателю объединять их по мере необходимости.

[править] A.1 Функциональные / технические спецификации

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

[править] A.2 Требования открытости

После функциональных спецификаций ПО, авторы рекомендуют размещать требования открытости, но не как часть функциональной спецификации, а в виде отдельных пунктов контрактных документов (cahier de charges) или предмета описания договора, если они являются обязательными, и как весовые критерии оценки победителя, если требования открытости являются предпочитаемыми, а не обязательными. Требования открытости Следующий тест может быть включён Право собственности на поставляемое программное обеспечение, включая все связанные с ним права интеллектуальной собственности, должны быть переданы организации-заказчику без ограничений на то, что именно организация-заказчик может с ним делать26, ИЛИ, ПО должно поставляться по следующим Условиям: 1. ПО может использоваться организацией для любых целей, которые организация сочтёт для себя нужными 2. поставщик предоставит исходные тексты и документацию в полном объёме, так что ПО может быть изучено закупающей организацией или любой третьей стороной по её выбору 3. ПО может быть изменено закупающей организацией или любой третьей стороной по её выбору 4. закупающая организация может распространять ПО с исходным кодом и модификациями, любой стороне по её выбору, под условиями, передающими этой стороне те же свободы, полученные закупающей организацией, как описано выше, использовать, изучать, модифицировать и распространять ПО. если поставляемое ПО должно быть открытым Требования открытости, как показано выше, должны быть включены в контрактные документы (cahier de charges) или в описание предмета договора в качестве обязательных требований. если государственный орган планирует распространять поставляемое ПО, как единое целое, либо в сочетании с другими компонентами программного обеспечения

Когда сложное ПО, состоящее из нескольких компонентов, распространяется в виде единого целого, может быть необходимым распространять его под единой лицензией, или потребуется, чтобы каждый компонент мог быть распространён под лицензией, которая позволяет его распространение в составе такого комбинированного ПО. Когда поставляемое ПО должно быть распространено как часть такой комбинированной поставки, широкие требования пункта 4, упомянутого выше, могут быть недостаточны. Указание определённой лицензии, или списка подходящих лицензий, может потребоваться для того, чтобы убедиться, что поставляемое ПО предоставляется под условиями, которые позволяют ему быть распространённым в качестве части большей работы — которая может включать в себя другие компоненты, поставляемые под другими условиями, что может повлечь потенциальную лицензионную несовместимость между компонентами, если не были предприняты шаги, чтобы избежать этого. Поэтому, в таких случаях, пункт 4 нужно заменить на: 4. организация, заключающая контракт, может распространять ПО с исходным кодом и модификациями, любой стороне по её выбору, в соответствии с условиями лицензии [ВСТАВИТЬ НАЗВАНИЕ ЛИЦЕНЗИИ / СПИСОК НАЗВАНИЙ / ССЫЛКА НА СПИСОК НАЗВАНИЙ]. Отметим, что недавно принятое законодательство в некоторых государствах-членах, таких как Испания и Мальта, рекомендует, и при определённых условиях требует использования European Union Public Licence (EUPL27) для распространяемого ПО, закупленного госорганами и предоставляет подробные спецификации лицензионных требований в случае, если не представляется возможным применение EUPL28. если поставляемое ПО предпочтительно (но не обязательно) должно являться открытым Требования открытости должны быть включены в качестве весового коэффициента. Должна использоваться система весов или скоринговая система. Вес критерия открытости должен быть установлен в соответствии с уровнем предпочтения открытого ПО, который будет сочтён целесообразным для тендера, в зависимости от обоснований и требований. Предположим, что вес критерия открытости установлен в 20%, и формула выбора победителя такова: общая оценка качества, поделённая на общую цену 1:1 цена:качество. В том случае, если имеются два конкурирующих предложения, одно для проприетарного ПО и одно для открытого ПО, точно соответствующие по качеству и другим критериям оценки победителя, предложение с открытым ПО будет выбрано, если проприетарное ПО не имеет цену на 20% меньше. В этом случае госорганизация считает, что значение свойства открытости для ПО равнозначно 20% скидке на цену тендера (например, в связи с предполагаемыми долгосрочными ценовыми преимуществами, которые не включены в цену тендерной заявки)

[править] A.3 Требования открытых стандартов

Наряду с функциональными спецификациями для ПО, в технической спецификации тендера должны быть описаны стандарты. Каждый стандарт должен быть определён путем указания ссылки (или имени), если он является официальным стандартом, таким, что допустимо ссылаться на него таким путём, либо широко известной спецификацией, которая не является официальным стандартом в европейском правовом смысле, но может быть описана по названию: TCP/IP, HTML, XML, SMTP и т.д. На момент подготовки тендера уже должно быть известно, соответствует ли любой именованный стандарт требованиям открытости, указанным в этом тендере. Таким образом, стандарты, которые не отвечают таким требованиям, могут быть просто не указаны в технической спецификации. Хотя и желательно указывать по имени конкретные открытые стандарты в технической спецификации, если технические интерфейсы, форматы и протоколы не могут быть названы - например, если не существует таких именованных стандартов - они должны быть определены в технических спецификациях. Каждый стандарт, определённый таким образом, должен быть четко определён в технических спецификациях, например, каждый определённый (но не названный) стандарт может быть пронумерован, с помощью такого текста: "Данная спецификация упоминается в этом тендере, как Открытый Стандарт № 1" Требования открытых стандартов Стандарты, которые перечислены по имени в функциональной спецификации, предположительно были проверены на предмет их свойств открытости до тендера. Возможно, это было сделано на европейском, национальном, региональном или местном уровне, или самой закупающей организацией. Таким образом, если используются только именованные стандарты, нет необходимости включать в описание тендера условия, определяющие открытость стандартов. Предполагается, что именованные стандарты удовлетворяют любым требованиям закупок. Если интерфейсы, протоколы и форматы определены в функциональных терминах в технических спецификациях, как описано выше, может быть нужно включить в описание тендера требования открытости с целью обеспечения открытости любой реализации. Это также может быть необходимо, если технические спецификации тендера не детализируют все стандарты, которые могут быть включены в закупаемое решение. Например, тендер может требовать от участников указывать все стандарты, которые они намерены использовать, и оценивать каждое предложение с точки зрения открытости предлагаемых технологий. В этом случае открытость может быть указана среди критериев оценки победителя. Не существует общепринятого определения открытых стандартов; это руководство использует определение из EIF 1.0. Однако, определение открытых стандартов не требуется для того, чтобы проводить тендеры с предпочтением открытых стандартов, если в описании каждого тендера фактически включены оправданные требования или критерии выигрышности за открытость стандартов. Здесь авторы предоставляют текст, соответствующий определению открытых стандартов, указанному в EIF v1.0, но этот текст может использоваться вне зависимости от любых внешних источников определений. Таким образом, следующие тексты могут быть включены в требования тендера или в качестве весовых коэффициентов. Если технические спецификации определяют не именованные, но пронумерованные протоколы, интерфейсы или форматы. Следующий текст может быть включён как часть требований к открытости стандартов: Поставляемое решение должно реализовывать технологии, упомянутые в Технических Спецификациях как Открытые Стандарты №1 (№2, №3 и т.д.). Каждая из этих технологий, как реализована в поставляемом решении, должна обладать следующими свойствами: Если технические характеристики не включают в себя стандарты, но позволяют претендентам предлагать различные технологии и стандарты в их предложениях Следующий текст могут быть включен как часть требований открытости стандартов: Поставляемое решение может реализовывать ряд стандартов, интерфейсов, протоколов или форматов, каждый из которых, как реализован в поставляемом ПО, должен обладать следующими свойствами: Свойства открытости стандартов Для любого из случаев, описанных выше, после предоставленного текста должно следовать описание свойств открытости открытых стандартов: 1. он может быть реализуем всеми потенциальными поставщиками эквивалентных технологий 2. прошлое и настоящее его разработки открыто и прозрачно 3. нет ограничений по повторному использованию Заметим, что требования открытости должны быть оправданы потребностями интероперабельности закупающей организации. Кроме того, если они не рассматриваются в качестве основных или оправданы в соответствии с определениями открытых стандартов в EIF v1.0, возможно использование некоторых из их свойств по отдельности, или разделение их на отдельные весовые коэффициенты оценки победителя, вместо комбинирования их в один. Таким образом, предложения, которые отвечают некоторым свойствам открытых стандартов, по-прежнему будут получать какие-то из весовых оценок, даже если они не отвечают всем свойствам. Если поставляемое ПО должно использовать открытые стандарты Требования открытости стандартов - или именованных, открытых стандартов, если указаны - должны быть включены в контрактные документы (cahier de charges) или в описание предмета договора в качестве обязательного требования. если поставляемое ПО предпочтительно (но не обязательно) должно реализовывать открытые стандарты Требования открытых стандартов, или именованных открытых стандартов если они указаны, должны быть включены в качестве весового коэффициента. Должна использоваться система весов или скоринговая система. Вес критерия открытости должен быть установлен в соответствии с уровнем предпочтения открытых стандартов, который будет сочтён целесообразным для тендера, в зависимости от обоснований и требований. Весовая/скоринговая система также может быть использована даже если не все свойства открытых стандартов будучи взятыми за основу критериев оценки являются одинаково важными или существенными. Например, если считается существенным что стандарты одинаково реализуемы всеми потенциальными поставщиками эквивалентных технологий, и что не существует ограничений по повторному использованию, но прозрачность разработки хотя и предпочитаема, но не существенна, атрибуты открытости могут быть указаны по раздельности, где №1 и №3 являются обязательными, а №2 взвешенным. B. Руководство по правовым вопросам Это приложение рекомендуется к прочтению юристами и специалистами по закупкам в госорганизациях и предназначено для внесения ясности по таким юридическим аспектам, связанным с получением открытого ПО, как: Соответствуют ли текущие практики закупок применимым нормам? Насколько процедуры закупок, рекомендованные в этом руководстве соответствуют нормам? Какие ещё специфические правовые вопросы должны быть приняты во внимание при приобретении ПО с открытым исходным кодом? Заметим, что это приложение не имеет целью предоставить подробные юридические консультации по вопросам ответственности и рисков госорганизациям, разрабатывающим или распространяющим открытое ПО. Оно сосредоточивается на правовые вопросах, связанных с приобретением ПО. Правовая основа для закупок: Директива 2004/18/EC Правовой основой для закупок в ЕС является Директива 2004/18/EC. В ней говорится, что закупки должны быть основаны на принципах, в частности, принципе равного обращения, недискриминации и транспарентности, и что процедуры должны гарантировать открытость государственных закупок для конкуренции29. Эти принципы и их применение проработаны далее в директиве. Их актуальность и применимость к закупкам ПО подробнее изложены в следующих разделах. Вкратце, эти принципы требуют, чтобы спецификации тендера и критерии определения победителя должны быть прозрачным, чтобы, в общем, любой потенциальный участник торгов мог понять их; и что технические спецификации и критерии не дискриминируют субъектов экономической деятельности. Данное руководство показывает, что некоторые распространённые практики закупок не могут следовать этим принципам, так как они благоприятствуют определённым проприетарным продуктам и их поставщикам. Это руководство показывает, как закупки открытого ПО могут быть произведены на базе прозрачных, недискриминационных функциональных спецификаций и критериев определения победителей, что позволяет всем субъектам экономической деятельности удовлетворять оправданные потребности государственных учреждений.

B.1 Текущая практика тендеров: соответствует ли правилам? Как показывают30 предыдущие исследования, ряд действий часто имеет место при закупке ПО: создание тендеров на покупку определённого ПО от определённых поставщиков, несмотря на использование "открытых" процедур закупки создание тендеров на покупку определённого ПО, как и выше, используя процедуры "переговоров" с единственным обоснованием для этих процедур, заключающемся в том, что определённая компания "владеет правами интеллектуальной собственности" на определённое ПО тендеров, которые не требуют поставки ПО конкретным поставщиком, но требуют совместимости с ранее приобретенными проприетарными системами (с проприетарным ПО или стандартами) В общем, ни одна из этих форм закупок не может быть рекомендована в качестве хорошей практики. Это очевидно, что они prima facie являются вредными для конкурентного и прозрачного, устойчивого и эффективного использования государственных средств, и обеспечивают государственное финансирование конкретных поставщиков. Причины избегать подобных практик аналогичны тем же самым причинам, по которым следует избегать подобных практик при закупке карандашей или автомобилей. Директива 2004/18/ЕС гласит, что "Технические спецификации должны обеспечивать равный доступ к торгам и не приводить к созданию неоправданных препятствий для конкуренции в открытых процедурах государственных закупок"31. Типы процедур закупок, показанные выше, очевидно, создают препятствия для конкуренции на торгах по госзакупкам; более того, они исключают конкуренцию. Вот почему такое ограничение конкуренции в процедурах закупок в частности, путем ссылки на конкретные продукты или источники, допускается по директиве, только если оно является "оправданным", в "порядке исключения, и только там, где предоставление достаточно точных и понятных описаний предмета договора [в функциональных терминах или со ссылкой на европейские стандарты] не представляется возможным"32. Хотя может потребоваться подробный анализ отдельных тендеров для определения, конфликтует ли конкретный тендер с требованиями закона о закупках, исследования показывают, что в значительной части тендеров на ПО были указаны торговые марки33. Это говорит о том, что использование ссылок на конкретные названия продуктов и поставщиков на самом деле не является исключительным. Более того, в большинстве случаев использования "плохих практик" при закупке ПО, обнаруженных авторами исследования (например, офисного ПО; инструментов для работы в Интернет; СУБД) является очевидным, что требования можно было бы описать в терминах функциональных требований, а не используя конкретные торговые марки. Возможно, одним из наиболее частых используемых "функциональных" требований является "совместимость с ПО X от поставщика Y", но это не является законным функциональным требованием согласно Директиве34. Вместо этого, хорошей практикой при закупках ПО являются требования совместимости исключительно на основе открытых стандартов. Между тем, авторы отмечают, что в тесно связанных областях компьютерной техники, в связи с тендерами ряда стран на поставку "Intel-совместимых" компьютеров, Европейская Комиссия заявила, что: "Ссылка на специфическую торговую марку, по мнению Еврокомиссии, будет представлять собой нарушение Директивы 93/36/EEC о государственных контрактах на поставку35, в то время как простое указание частоты процессора - чего недостаточно для оценки производительности компьютера - противоречило бы статье 28 Договора ЕС, которая запрещает любые барьеры для торговли внутри Сообщества". ЕС также отметил, что "власти в этих странах описывали технические характеристики компьютеров, которые они хотели бы приобрести, дискриминационным образом"36. Текущие практики электронных госзакупок Есть несколько случаев проведения тендеров, в которых от претендентов требовалось использовать проприетарное ПО от определённых поставщиков для того, чтобы получить доступ к электронным системам проведения торгов, чтобы отправить заявку, или чтобы получить документацию по тендеру. В Директиве 2004/18/EC Перечисление 12 говорится, что "Договаривающиеся органы могут использовать электронные методы покупки, обеспечивая, что такое использование соответствует правилам, составленным в соответствии с настоящей Директивой, и принципами равенства, недискриминации и транспарентности". Статья 42 (4) также указывает, что "инструменты, которые будут использоваться для связи с помощью электронных средств, а также их технические характеристики, должны носить недискриминационный характер, быть, как правило, доступными и полностью совместимыми с продуктами информационных и коммуникационных технологий, находящимися в общем пользовании". Хотя некоторые проприетарные продукты действительно могут считаться продуктами, "находящимися в общем пользовании", требование претендентам использовать продукты от конкретных поставщиков, безусловно является дискриминационным, и не обеспечивает равного отношения. Конечно, это касается электронных закупок в целом, и непосредственно не связано с закупкой ПО. Хорошие практики закупки ПО Хорошие практики закупки ПО (как и "железа") должны включать описание технических характеристик, которое не приводит к предпочтению определённых поставщиков. То есть, программное обеспечение должно быть описано с помощью функциональных спецификаций, как описано в основном тексте настоящего руководства. Данное руководство не является обобщённым путеводителем по хорошим практикам закупок программного обеспечения, но руководством по хорошим практикам закупок программного обеспечения с открытым исходным кодом. Тем не менее, авторам хотелось бы отметить, что тендеры, которые используют функциональные спецификации, вместо использования собственнических торговых марок, способствуют усилению конкуренции в сфере закупок. Кроме того, подзаконные акты о закупках предусматривают использование вариантов37, что позволяет участникам торгов предложить несколько решений по одним и тем же тендерам. Тендеры, позволяющие предоставление вариантов дают возможность участникам предлагать, например, решения с открытым исходным кодом или альтернативное проприетарное ПО. Варианты также могут включать различные модели ценообразования38, с ценой варианта с открытым ПО, основанной на сервисных платежах, а не на оплате лицензий. Использование функциональных спецификаций и разрешение использовать варианты даёт уверенность, что государственный орган обеспечивает более прозрачный и конкурентный процесс закупок, будь то конечный результат открытым или проприетарным ПО.

[править] B.2 Закупка открытого ПО: соответствует ли правилам?

Главным документом, регулирующим процессы госзакупок (в том числе и ПО) в ЕС является Европейская Директива 2004/18/EC. Она соответствует глобальным правилам, Соглашению о Госзакупках ВТО. В свою очередь, для соответствия Директиве производятся изменения в законодательствах государств-членов. Хорошей практикой госзакупок является определение требований к ПО в функциональных терминах, с использованием требований к производительности и функциональных требований, как это предусмотрено Директивой 2004/18/ЕС. Такие закупки не будут допускать дискриминации в пользу тех или иных компаний. Существуют запреты на закупки, которые приводят к получению преимуществ, или их утрате, отдельными компаниями. Однако, не существует запретов на закупки, соответствующих любым критериям, которые соответствуют требованиям госорганизаций, даже если такие требования приводят к утратам преимуществ компаниями, работающими по определённым бизнес-моделям. Поскольку одной из целей государственного регулирования закупок является "гарантия открытости государственных закупок для конкуренции", предпочтение конкретных бизнес-моделей, что снижает конкуренцию, может быть проблематичным. Но, бизнес-модель открытого ПО поддерживает конкуренцию, предоставляя неограниченному количеству независимых поставщиков равные возможности для оказания поддержки, адаптации и контроля одного и того же ПО. Таким образом, оказывается возможным удовлетворять требования, предъявляемые к госорганизациям, скачивая ПО и размещая на тендерах заявки на оказание услуг техподдержки, или, например, путём указания совместимых с открытым ПО условий в качестве критериев оценки победителя - до тех пор, пока это оправдано такими принципами проведения закупок, как прозрачность и открытость для конкуренции. Ниже рассматриваются правовые вопросы, характерные для каждой формы приобретения программного обеспечения с открытым исходным кодом.

[править] B.2.1 Получение открытого ПО без проведения тендеров

Государственные закупки товаров или услуг, как правило, должны осуществляться с помощью публичного процесса заключения контракта, как правило, через тендер. Получение ПО, однако, часто делается путём загрузки этого ПО из интернета. Особенно распространено это относительно ПО с открытым исходным кодом. Возникает очевидный вопрос - соответствует ли подзаконным актам о закупках такой способ получения ПО госорганизациями. Законодательство, касающееся государственных закупок, очень специфично. В Директиве 2004/18/ЕС также уделяется особое внимание термину "публичные контракты". В частности, в статье 28, которая определяет процедуры закупки говорится, что "[договаривающиеся стороны] должны заключать эти публичные контракты с применением открытых или ограниченных процедур"39. Процедуры закупок применимы только для вынесения решений по публичным контрактам. Директива 2004/18/EC Статья 1(2)(a) определяет термин "публичный контракт" как "контракты преследующие материальные интересы, заключённые в письменной форме между одним или несколькими экономическими субъектами и одним или несколькими заказчиками". Когда ПО скачано из интернета, оно может повлечь за собой заключение контрактов и платежи, и поэтому повлечь заключение «публичных контрактов». Когда ПО предоставляется для скачивания бесплатно на общедоступном веб-сайте, не может быть установлено никаких платежей за скачивание — это относится не только к ПО с открытым исходным кодом, но и к проприетарному ПО, когда оно может быть свободно скачано, например, несколько популярных программ для просмотра документов, медиа-плееров, браузеров. Не является контрактом ? Когда скачивание ПО требует принятия соглашения об условиях предоставления, например, с помощью щелчка мыши, это подразумевает заключение контракта, даже если плата не взимается. На случай, когда такого явного согласия не требуется, как в случае с открытым исходным кодом, в юридической литературе существует аргумент, что никакого контракта заключено не было. В некоторых юрисдикциях (например, США), является очевидным, что открытые лицензии предоставляют разрешительный грант в рамках закона об авторском праве, и договорные права в таком случае задействованы быть не могут. Однако в ЕС, ситуация менее чёткая40, т.к. любое соглашение, явное или неявное, часто порождает договорные отношения. Тем не менее, в одном из редких европейских дел, рассматривавших открытые лицензии, в 2004 году окружной суд Мюнхена постановил, что, в то время, как открытая лицензия (GPL) была контрактом, соблюдение лицензии осуществлялось средствами правовой защиты от нарушений авторских прав.41. Независимо от того, является или нет это контрактом, таким образом, необходим путь, освобождающий бесплатные скачивания открытого ПО от актов, регулирующих закупки. Вместо этого, авторы концентрируются на том, предполагает ли скачивание ПО материальную выгоду. Финансовая заинтересованность? Правовые рамки чётко исключают скачивание открытого ПО из определения "публичного договора поставки", которое включает в себя "покупку, аренду, аренду или покупку в рассрочку, с опционом или без опциона на покупку, продуктов". Тем не менее, европейская правовая практика показывает, что отсутствие оплаты за товар или услугу не может автоматически означать, что его приобретение не связано с публичным договором42. В случае скачивания открытого ПО, необходимо учитывать, была ли применена любая другая форма компенсации поставки ПО лицензиару43. Определение открытого ПО предотвращает требование компенсации за получение такого ПО, поэтому, если ПО действительно открытое, то такая компенсация не может существовать. Здесь может быть одно исключение, в случае лицензии44 которая требует, чтобы лицензиар получал автоматическую лицензию на любые изменения в ПО, произведённые госучреждением. Это можно рассматривать в качестве компенсации. Однако, это частный случай, применяемый только тогда, когда госорган намерен внести изменения в ПО, и не влияет на большинство открытых лицензий, таких, как популярная GPL45, которая требует, чтобы изменения были сделаны доступными всем под той же самой лицензией, но не чтобы изменения были доступны только Лицензиару. Если ПО является открытым, скорее всего есть места, где доступно его бесплатное скачивание. Однако, если требуется оплата скачивания ПО, то получение такого ПО чётко попадает под положение о "публичных контрактах". Тендеры на поставку услуг Как описано в руководстве, большинство случаев получения ПО с помощью скачивания влекут за собой закупку каких-либо услуг, таких как настройка ПО, доработка, интеграция с другим ПО, сопровождение и техподдержка. Руководство также говорит о том, что услуга по оценке возможных вариантов скачиваемого ПО тоже может быть осуществлена по договору, если это требуется, до скачивания. Любые такие услуги, оплачиваемые или нет, чётко подпадают под действие подзаконных актов о закупках, так как являются "публичными контрактами" согласно определению, данному в Директиве 2004/18/ЕС. Для приобретения проприетарного ПО госорганизация размещает тендер на заключение договора поставки и обслуживания; или отдельные контракты на поставку (лицензий на ПО) и услуг (поддержка, интеграция, и т.д.). В сценарии со скачиванием открытого ПО не существует контракта на поставку. Может ли это рассматриваться как нарушение запрета на "разделение" закупок в целях обхода актов, регулирующих закупки ? Директива 2004/18/ЕС, статья 9 (3) гласит, что "Нет проектных работ или предполагаемого к покупке какого-то количества материалов и/или услуг, которые могут быть разделены для того, чтобы избежать их подпадания под рамки этой Директивы". Является ли в этом смысле "разделением" комбинация бесплатного скачивания ПО с платным сервисом техподдержки? На самом деле запрет разделения действует в рамках Раздела 1 (пороговые значения) и относится к Статье 7, в которой говорится, что эта Директива применяется (обычно) к публичным контрактам с суммой выше 133000 Евро. Статья 9 определяет, как стоимость публичного контракта должна быть рассчитана для того, чтобы определить, выше ли сумма контракта определённых Директивой пороговых значений, и таким образом подпадает ли контракт под действие Директивы. Она запрещает разделение одного контракта, сумма которого подпадает под действие директивы, на несколько более мелких, сумма которых не подпадает под действие директивы. По определению, в этих нескольких контрактах должна быть указана ненулевая сумма, так как они являются "контрактами для извлечения материальной выгоды". Однако, даже если скачивание ПО было включено в контракт как часть услуг, оно не может добавлять стоимость в общую сумму, если само ПО поставляется бесплатно. Получение ПО с помощью бесплатного скачивания не добавляет стоимость - не является "контрактом для извлечения материальной выгоды" - и не является публичным контрактом во всех смыслах Директивы 2004/18/EC. Таким образом, оно не подпадает под запрет разделения. Авторы повторяют, что скачивание ПО должно быть полностью бесплатным, без каких либо скрытых платежей, чтобы не попадать под определение публичного договора. Например, если право на скачивание обуславливается только получением контракта на услуги, то скачивание явно не является бесплатным, и таким образом является публичным контрактом, и не может быть отделено от публичного контракта на услуги. Стоимость ПО и услуг должна быть рассчитана, и если их сумма выше порога, они должны быть закуплены в соответствии с положениями Директивы. (Если общая сумма контракта на ПО и услуги ниже пороговых значений, указанных в Директиве, они по-прежнему подпадают под национальные правила закупок.) В целом, однако, скачивание открытого ПО где-либо доступно без всяких условий - действительно, это является следствием определения открытого ПО46. Правило разделения также может быть важным если, условные связи между скачиванием и услугами не распространяются на источник ПО, но являются требованием приобретающей организации. Например, если организация может использовать ПО только после его модификации после скачивания, то может потребоваться объединить контракт на получение ПО с контрактом на его модификацию. Наконец, авторы отмечают, что многие услуги для скачанного ПО могут быть произведены в рамках текущих контрактов, и поэтому может не возникать необходимости для заключения новых контрактов с помощью тендеров. Это может относиться как к услугам, предшествующим скачиванию, таким как поиск или оценка ПО, так и к сервисам, последующим после скачивания, таким как настройка, установка, обслуживание и техподдержка. Дополнительные услуги и конкуренция Тендер на поставку услуг может быть размещён для любого ранее закупленного продукта. Ясно, это это способствует фирмам, предоставляющим услуги для данного продукта. Само по себе это не противоречит принципам госзакупок. Когда это происходит после закупки проприетарного ПО, это может иметь антиконкурентный эффект. Причиной является то, что многие услуги, связанные или зависящие от проприетарного ПО, ранее закупленного организацией, будут требовать, чтобы поставщик услуг состоял в отношениях зависимости от собственника этого ПО. У открытого ПО нет собственников, поэтому поставщики услуг не зависят от них. Может существовать несколько поставщиков услуг для определённого открытого ПО, и все они будут иметь одинаковый доступ к ПО. Открытое ПО способствует конкуренции. Таким образом, тендер на услуги по поддержке ранее приобретенных продуктов с открытым исходным кодом, как правило, не приводит к антиконкурентным эффектам. Однако, в конкретных случаях, может наличествовать ситуация ограниченной конкуренции на поставку услуг для открытого продукта, так как открытость определяется лицензией, а не реальной конкурентной ситуацией. Например, поставщик может принять решение о выпуске собственнического ПО под открытой лицензией на общедоступном веб-сайте, для того, чтобы поставлять его правительству. Если такое ПО сразу же получено госорганизацией с помощью скачивания, может оказаться, что оригинальный производитель или его дилеры или представители являются единственными поставщиками услуг. В такой ситуации тендер на поставку услуг может привести к тому, что хотя он и не нарушает принципы закупок, но по сути является антиконкурентным, таким же, как и тендер на поставку услуг для ранее приобретённого проприетарного ПО, по крайней мере, в краткосрочной перспективе. В таких случаях, госорганизация может получить ПО с помощью скачивания, и затем подождать какое-то время до того, как опубликовать тендер на поставку услуг, для того, чтобы дать возможность поставщикам услуг получить знания и компетенции относительно этого ПО. Если есть сомнения относительно возможности выбора среди нескольких компетентных поставщиков услуг для выбранного ПО, следует избегать метода получения ПО с помощью скачивания и закупить ПО вместе с услугами на тендере. Нормативы и практические процедуры Хотя, похоже на то, что нет проблем, обусловленных нормативами, со скачиванием открытого ПО из интернета без заключения публичного контракта, это не значит, что неконтролируемое скачивание является хорошей идеей. Скачивание ПО, как описано в данном руководстве, является частью формального процесса получения ИТ в государственной организации. Оно должно быть вариантом получения, но в рамках всего остального формального процесса. То есть, скачивание ПО должно происходить в рамках ИТ-решений, после определения требований и надлежащего рассмотрения всех вариантов - ПО, бизнес-моделей, и т.д. - так, чтобы оно представляло собой наиболее подходящее решение для нужд государственного органа.

[править] B.2.2 Тендеры, оговаривающие поставку открытого ПО или открытых стандартов

Как отмечалось в начале этого раздела, хотя может быть практически возможным опубликовать тендер, требующий поставки открытого ПО, так как это не хуже, и, возможно, менее антиконкурентно, чем обычная практика тендеров, требующих поставку конкретного собственнического ПО, это не рекомендуется делать. Хорошая практика требует, как это рекомендует руководство, чтобы было сделано надлежащее определение требований госорганизации, и переведено в функциональные спецификации для закупаемого ПО. В теории, есть две части тендера, где выбор открытого ПО может быть явно выражен: технические спецификации, и критерии определения победителя. Технические спецификации Технические характеристики регулируются статьёй 23 Директивы 2004/18/ЕС. Она указывает, что технические спецификации должны быть чётко описаны в тендере, и что они должны относиться к определённому набору европейских, национальных или международных стандартов47. Или же, спецификации могут быть определены в терминах, «достаточно точно» описывающих производительность или функциональные требования48. Для любого тендера является очевидной важность точного определения функциональных требований в технических спецификациях. Однако, требования открытого ПО здесь не совсем подходят. Требования открытых стандартов подходят в той мере, что открытые стандарты признаны в соответствии с действующими нормами и были определены в терминах функциональных требований в технических спецификациях. Но критерий открытости открытых стандартов не вписывается в технической спецификации. Если стандарты имеют названия и предварительно определены, они будут уже известными на момент подготовки предложения, если они отвечают критерию открытости, и поэтому этот критерий не должен быть перечислен в условиях тендера - именованные открытые стандарты просто включаются в технические спецификации. Если стандарты не названы в функциональных спецификациях, но определены в технических спецификациях тендера, критерий открытости не является техническим и не подходит здесь. Аналогичным образом, если стандарты не были перечислены или определены в функциональных терминах, но могут быть указаны участниками в их предложениях, любой критерий открытости, не являясь техническим, здесь не может быть применён. Когда интерфейсы, протоколы и форматы были функционально определены в технической спецификации, или претендентам было разрешено предлагать стандарты, интерфейсы, протоколы и форматы по собственному выбору, претендент может предоставить решение с использованием собственных стандартов. Технические характеристики четко относятся к функциям продукта, который поставляется, то есть функционированию программного обеспечения. "Открытые" свойства как открытого ПО, так и открытых стандартов, по существу, не являются техническими по природе. Они относятся к процессам разработки и условиям использования (т.е. лицензированию). Поэтому авторы рекомендуют указывать «открытость» ПО и, там, где это применимо, стандартов, в качестве отдельных требований в контрактных документах (cahier de charges) или описания предмета договора, если они являются обязательными, или в качестве весового критерия, если требования открытости являются скорее предпочтительными, чем обязательными. Контрактные документы и критерий определения победителя Как только удовлетворены технические спецификации, должен быть определён победитель тендера. Выбор должен быть основан либо на основе самой низкой цены предложения, либо должен быть "наиболее экономически выгодным с точки зрения заказчика"49. Второй метод используется, когда учитывается не только цена, но и качество как фактора принятия решения. Этот метод должен использоваться для того, чтобы использовать критерий открытости там, где наличие в предложении открытого ПО или открытых стандартов является предпочтительными, а не обязательным. Единственное ограничение в критериях, допустимое в дополнение к цене, для того, чтобы определить экономическую эффективность предложения - "связаны с предметом публичного контракта в вопросе". Несколько примеров таких критериев содержатся в Директиве: "качество, цена, технические достоинства, ... функциональные характеристики, эксплуатационные расходы, рентабельность, послепродажное сервисное и техническое обслуживание, дата поставки"50. Свойства открытости, такие как условия лицензирования ПО, как и другие условия использования, здесь чётко вписываются. Эти критерии, очевидно, связаны с предметом конкурса, а также оценкой экономического эффективности с точки зрения госорганизации-заказчика. Конечно, критерии должны быть оправданными - и это руководство указывает множество оправданий для различных свойств открытого ПО и открытых стандартов. Более того, авторы отмечают, что правила позволяют указывать в критериях "общественные потребности"51 в дополнение к экономическим и качественным требованиям, что позволяет вводить дальнейшие обоснования критериев, такие, как предоставление государственных услуг для всех граждан без принуждения их становиться клиентами конкретных поставщиков. В порядке обеспечения прозрачности является недостаточным указания что «открытость» ПО является критерием определения победителя. Критерий определения победителя должен быть детализирован с «необходимой прозрачностью, чтобы все участники тендера были достаточно информированы о критериях и договорённостях, которые будут применяться для определения наиболее выгодного с экономической точки зрения предложения» 52. В случае обязательных требований открытости, будь то для открытых стандартов (не именованных, и поэтому нуждающихся в критерии открытости) или открытого ПО, нет необходимости использовать критерии оценки победителя. Требования обязательности открытости могут быть включены в контрактные документы (cahier de charges). Как указывается в руководстве, критерий открытости может включать (некоторые или все) атрибуты открытого ПО, в идеале с объяснением представленных обоснований: право владения программным обеспечением переходит к госоргану53 ИЛИ: ПО может быть использовано для любых целей госорганизация или третья сторона по её выбору могут изучать исходный код госорганизация или третья сторона по её выбору могут вносить изменения в ПО госорганизация может распространять ПО, с исходным кодом и модификациями, кому угодно на её выбор и предоставлять получателям те же самые права использования, изучения и распространения Там, где эти требования являются необязательными, но предпочтительными и помещены в критерии определения победителя, эти критерии должны быть весовыми, чтобы участникам торгов было понятно, как будет определяться наибольшая экономическая выгода54. Более того, может быть установлен порог минимального количества баллов для каждого критерия или группы критериев, позволяющий исключать предложения, оценка которых падает ниже уровней, определённых с точки зрения веса для отдельных критериев. Таким образом, для государственных учреждений является возможным выражать предпочтение открытому ПО. Требование открытости ПО может быть выражено путём включения критерия открытости в контрактные документы (cahier de charges). Предпочтение открытого ПО (или некоторых его качеств) может быть выражено с помощью указания некоторых или всех его критериев весовыми. Например, всем критериям открытости может быть присвоен вес в 20%. Если формула, используемая для оценки тендеров - это общий взвешенный результат, поделённый на общую цену (в соотношении 1:1 для цены и качества), это может оценить предложение с открытым ПО на 20% больше, чем эквивалентное, одинаково оценённое предложение с проприетарным ПО. Делать ли открытое ПО требуемым по условиям тендера или только предпочтительным (с помощью придания более высокого веса оценке критерия открытости ПО) - это решение принимается каждой госорганизацией по каждому тендеру. Это зависит от обоснования, и в то время как европейская или национальная или региональная политика может быть приведена в качестве оправдания для предпочтения или требования открытого ПО, в этом руководстве показано, как такое обоснование может быть обеспечено даже тогда, когда не существует политики по этому вопросу, просто на уровне каждого тендера. Когда госорганизация намеревается распространять поставленную ей работу, продукт или приложение, рекомендуется, чтобы в тендерной документации была указана открытая лицензия (или список возможных открытых лицензий), которую организация намерена использовать для распространения. Это особенно важно в случае комбинированных работ (во избежание лицензионных конфликтов между компонентами, полученными под несовместимыми лицензиями). Вопросы, которые влияют на то, являются ли лицензии совместимыми включают в себя: желательность присвоения ПО третьими сторонами; как лицензия защищает госорган от ответственности и гарантийных обязательств; соответствие с действующим национальным законодательством; спецификация компетентного суда; действительность лицензии на всех применимых юридических языках55. Открытые стандарты также могут быть либо предпочитаемыми либо требуемыми с помощью указания критериев оценки победителя или включения в контрактные документы (cahier de charges). Это может быть сделано, когда стандарт не включён по имени в технические спецификации, но только с помощью функционального описания, или когда участники тендера имеют право предлагать свои предложения по стандартам, форматам, интерфейсам и протоколам56. Не существует общепринятого определения открытых стандартов; в этом руководство использовано определение из European Interoperability Framework версии 1.0. Однако, в то время как определение открытых стандартов требуется для того, чтобы определять политику, не требуется для того, чтобы на самом деле проводить тендеры, содержащие предпочтения или требующие открытых стандартов - это подход данного руководства. Это происходит потому, что, как и в случае с открытым ПО, недостаточно указать, что требуется открытый стандарт. Критерии должны быть четко и прозрачно определены. Таким образом, авторы рекомендуют включать желаемые свойства открытых стандартов - как обосновываемые требованиями интероперабельности госорганизации, в каждый тендер - в качестве критериев оценки победителя в тех тендерах, где открытость является предпочтением, или в контрактные документы (cahier de charges) в тех тендерах, где требование открытости является обязательным. Критерии, соответствующие определению открытых стандартов, приведённому в European Interoperability Framework (EIF) v1.0, приведены ниже57: стандарт(ы), используемый в ПО, реализуем всеми потенциальными поставщиками эквивалентных технологий процесс разработки стандарта(ов), используемого в ПО является открытым и прозрачным нет ограничений на повторное использование стандарта(ов) С помощью изменения весовых критериев и минимальных пороговых оценок госорганизация может определять уровень предпочтения - или требования - открытых стандартов для каждого тендера. Когда имеется в наличии политика (такая, как голландская политика обязательности открытых стандартов), это является простым обоснованием минимальных пороговых значений и критериев оценки победителя. При отсутствии такой политики, критерии предпочтения или необходимости открытых стандартов могут быть включены на уровне каждой организации, как того требует каждый отдельный тендер. Другие критерии В процессе тендера участникам часто бывает необходимо продемонстрировать свою финансовую, техническую или профессиональную дееспособность. Правила позволяют устанавливать минимальные уровни этих параметров58 - например, минимальный размер, оборот, капитал и т.д. Такие минимальные уровни могут устанавливаться, следуя принципам пропорциональности, отдельно по каждому тендеру. Естественно, в случае тендера с большой суммой, может быть разумным установить более высокий порог минимальных финансовых возможностей. Как указано в руководстве, основная причина определения минимальных финансовых возможностей для поставщиков ПО, в дополнение к определению способности поставщика удовлетворить требования тендера, заключается в том, чтобы убедиться, что поставщик будет в состоянии обеспечить поддержку в течение всего срока жизни программного обеспечения. Проприетарное программное обеспечение может стать неподдерживаемым - и непригодным к использованию - если собственник ПО обанкротится, или не будет иметь достаточных финансовых ресурсов для поддержки устаревшего ПО59. Однако, открытое ПО может поддерживаться любой компанией, имеющей соответствующие компетенции, а не только оригинальным поставщиком. Действительно, организация-поставщик ПО для госорганизации может не иметь никакого отношения к реальным создателям или сопровождающим открытого ПО. Таким образом, открытое ПО вполне может являться устойчивым за пределами жизненного цикла поставщика. Это оправдывает значительно более низкие требования по финансовым возможностям, предъявляемые на тендерах на поставку ПО, когда требуется, чтобы это ПО являлось открытым.

[править] C. Источники

Офис Программы Голландского Правительства NoiV, 2008 Получение ПО (с открытым исходным кодом). Доступно по адресу: http://www.ososs.nl/files/acquisition_of_open-source_software_-_text.pdf Директорат Европейской Комиссии по предпринимательству, 2006 г., Исследование экономического эффекта открытого ПО на инновации и конкурентоспособность информационных и коммуникационных технологий (ИКТ) в ЕС. Доступно в Интернете по адресу http://flossimpact.eu Директорат Европейской Комиссии по информационному обществу и СМИ, 2008, Исследование эффекта влияния на развитие информационного общества в результате разработки открытого ПО госорганами Доступно по адресу http://www.publicsectoross.info European Interoperability Framework for Pan-European eGovernment Services, v1.0. Европейская Комиссия, IDABC, Ноябрь 2004. Доступно по адресу http://ec.europa.eu/idabc/servlets/Doc?id=19529 European Interoperability Framework v2.0: Черновик для публичных комментариев - как основа для EIF 2.0 – 15/07/2008. Европейская Комиссия, IDABC, Июль 2008. Доступна по адресу http://ec.europa.eu/idabc/servlets/Doc?id=31597 Экономическая основа для открытых стандартов. Ghosh, R. A. 2005. проект FLOSSPOLS, Европейская Комиссия. http://www.flosspols.org/deliverables/FLOSSPOLS-D04-openstandards-v6.pdf Отчёт OFE по мониторингу: Дискриминация в процессе госзакупок ПО в государствах-членах ЕС, OpenForum Europe, Декабрь 2008, http://www.openforumeurope.org/library/procurement/ofe_procurement_monitoring_report_final_16_october_2008.pdf