Аудит и лицензирование
РИСКИ ПРИ ЗАВЕРШЕНИИ ULA ORACLE
Иван Бакланов
CEO
Многие Заказчики заключают безлимитное соглашение с компанией Oracle, пребывая в уверенности, что теперь им не о чем беспокоиться, поскольку таким образом они снизили все риски, связанные с лицензированием ПО Oracle, насколько это возможно.

Но насколько такой подход оправдан?

В этой статье мы сделаем обзор самых распространённых факторов и связанных с ними проблем, с которыми может столкнуться предприятие, заключившее ULA с компанией Oracle.

Юридические лица

Безлимитное лицензионное соглашение (ULA, Unlimited License Agreement) ограничено по количеству юридических лиц, включённых в его текст. Как правило, это дочерние предприятия, в которых Ваше предприятие обладает контрольным пакетом (majority owned), но также лицензионное соглашение может включать дочерние предприятия, в которых у Вашего предприятия нет контрольного пакета (minority owned) акций, совместные предприятия (joint ventures) или юридические лица, в которых у вас есть право голоса. Это ограничение описано в Соглашении в разделе «Определение Пользователя» (Customer Definition).
Покупка юридических лиц
Если Вы приобретаете юридические лица в течение срока действия Вашего Соглашения ULA, эти предприятия НЕ ИМЕЮТ права устанавливать программы - для этого предприятие должно быть включено в ULA. В случае если такая покупка юридического лица приводит к увеличению количества сотрудников или дохода не более чем на 10%, Вы можете попросить Oracle включить эти юридические лица в Ваше Соглашение. Oracle, как правило, удовлетворяет такие просьбы, но Ваше обращение должно получить одобрение внутри Oracle. В случае, если Oracle согласует для Вас такое дополнение к Соглашению ULA, Oracle потребует от Вас объединить лицензии приобретённого предприятия с Вашими лицензиями и соответствующая им стоимость поддержки будет добавлена к текущей стоимости поддержки лицензий, входящих в ULA. Это значит, что те лицензии, которые были у приобретаемого предприятия до его поглощения, будут аннулированы после этого поглощения, поскольку сотрудники этого предприятия смогут пользоваться продуктами Oracle в рамках ULA. Стоимость поддержки, которую приобретаемое предприятие платило за свои лицензии, будет добавлена к стоимости поддержки, которую Вы платили по Соглашению ULA до этого приобретения. Однако, если Oracle не одобрит такое «дополнение», приобретённая компания должна лицензировать используемые программы отдельно от Вашего основного предприятия, как она делала до поглощения.
Продажа юридического лица
Если Вы решите продать юридическое лицо в течение срока действия договора ULA, то продаваемое предприятие, как правило, имеет право продолжать пользоваться правом неограниченного использования программ Oracle, включённых в ULA, в течение шести месяцев после даты продажи, при условии, что окончание этого шестимесячного периода не выходит за рамки срока действия самого ULA. По окончании этого периода продаваемая компания должна будет лицензировать использование ПО Oracle самостоятельно. Как конечному пользователю, Вам следует обратить внимание на то на то, что наличие этого «льготного периода» должно быть отражено в Вашем Соглашении. Что делать, если этот период не гарантирован Соглашением? Продаваемая компания должна иметь на момент продажи свои собственные лицензии в достаточном количестве, поскольку эта компания больше не имеет к Вам отношения.
Риски, порожденные Вашей организационно-правовой структурой
В процессе сертификации ULA установка и\или использование программ Oracle должно быть оценено для всех юридических лиц, входящих в Определение конечного пользователя (Customer Definition), с целью получить полный и тщательный отчёт, содержащий количество лицензий, используемых на момент окончания проверки. Это и будет тем количеством, которое будет закреплено за Вами по результатам сертификации ULA. Вынужденная спешка при проведении сертификации, а также плохое понимание текста соглашения могут привести к тому, что в сертификацию ULA будут включены только самые важные юридические лица. Это, в свою очередь, означает, что немедленно по окончании сертификации те предприятия, которые Вы забыли включить в процесс сертификации, лишатся своего права на использование лицензий и, значит, любое использование ими ПО Oracle станет незаконным. Использование ПО без достаточного набора лицензий может привести к гигантским юридическим и финансовым рискам.

Дата проведения сертификации и длительность соглашения

Соглашение ULA обычно ограничено по времени. Как правило, срок действия соглашения составляет 2, 3 или 4 года. По условиям Соглашения, чаще всего, Вам нужно в течение 30-и дней после окончания ULA сертифицировать (то есть, подсчитать и оформить результаты этого подсчёта в виде официального документа определённого вида) количество используемых лицензий в метрике Processor для тех программ, которые были включены в ULA. Представитель руководства компании (C-Level) должен подписать упомянутый документ для того, чтобы удостоверить правильность проведённой сертификации. Если документ о сертификации, подписанный представителем руководства компании содержит в себе некорректные данные, это считается мошенничеством, согласно законам о правах интеллектуальной собственности (IP rights law), действующим в большинстве стран. Резюмируя, можно сказать, что права на использование ПО Oracle будут ограничены тем количеством, которое закреплено в сертификационном документе.
Каким образом дата проведения сертификации ULA и условия договора могут порождать риски
Нельзя недооценивать риски, связанные со временем, необходимым для подготовки и проведения сертификации ULA. По нашему опыту, если Вы хотите, чтобы сертификация по ULA прошла без ошибок, подготовка к ней должна начинаться за 3-6 месяцев до даты окончания контракта. Оптимизация использования ПО Oracle с целью получения максимальной выгоды от Вашего контракта ULA должна начинаться как минимум за 1-1,5 года до окончания срока действия ULA. Проведение сертификации ULA в условиях жёстких ограничений по времени увеличивает риск совершения ошибок в этом процессе, что может привести:

1) к «недо-сертификации» ("under certification"), что, в свою очередь, ведёт к нехватке лицензий и использованию нелицензированного ПО Oracle после проведения сертификации, или

2) к «пере-лицензированию» ("over certification"), что может быт расценено Вендором как мошенничество.

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

Все ли ПО Oracle включено?

Несмотря на своё название, Неограниченное Лицензионное Соглашение (ULA) на самом деле ограничено по количеству включённых в него программных продуктов. Многие организации понимают это Соглашение как право на неограниченную установку всех программ Oracle или всех программ, объединённых в некую группу (например, программы, имеющие отношение к Базам данных Oracle). Это ошибка. Только программы, явно перечисленные в Соглашении, могут быть использованы без ограничений.

Чтобы сделать ситуацию ещё более запутанной, Oracle часто поставляет своё ПО, в состав которого входят разнообразные функции, требующие отдельного лицензирования, в то время как внутри данного ПО нет технических ограничений по использованию этих функций, а для них у Вас, возможно, отсутствуют лицензии. Рассмотрим следующий пример. Предположим, что у Вас заключено Соглашение ULA, в которое включены следующие продукты: Oracle Database Enterprise Edition, Partitioning, Diagnostics Pack и Tuning Pack. Можете ли Вы поручиться, что каждый сотрудник в Вашей организации осведомлён о том, что нельзя использовать ещё приблизительно 20 других функций, которые поставляются вместе с БД Oracle Enterprise Edition, которые встроены внутрь этой СУБД и которые нужно лицензировать отдельно?

Все ли среды и центры хранения данных включены?

Соглашение ULA, как правило, предоставляет право на неограниченное использование определённого программного обеспечения для ВСЕХ ваших сред, включая среды разработки (development), приёмки (acceptance), тестирования (test), промышленной эксплуатации (production), аварийного восстановления (disaster recovery) и пр. Вы ответственны за то, что в конце срока действия Соглашения Вы самостоятельно должны сертифицировать количество лицензий в метрике Processor для всех этих сред. Вынужденная спешка при проведении сертификации, а также плохое понимание текста Соглашения, приводят к отсутствию актуальной, полной и достоверной инвентарной описи программного и аппаратного обеспечения, используемого в разных средах. Во многих случаях не все среды принимаются во внимание в процессе сертификации ULA.

Например, Вы можете включить только Ваши системы, находящиеся в промышленной эксплуатации, и забыть включить среды разработки (development), приёмки (acceptance), тестирования (test), аварийного восстановления (disaster recovery). Или Вы можете включить только Ваши самые большие дата-центры, и забыть меньшие ЦОДы, или те центры хранения данных, которые находятся за границей или на аутсорсинге. Включение не всех Ваших серверов и\или дата-центров может привести к тому, что эти среды окажется нелицензированными немедленно по окончании процедуры сертификации.
Как исключение некоторых сред и\или дата-центров может представлять собой риск?
Неправильный подсчёт лицензий, необходимых для лицензирования определённых сред может привести к огромным финансовым потерям и прочим неприятным последствиям. Например, упущение из расчётов всего одного сервера, нуждающегося в 4-х лицензиях метрики Processor для Oracle Database Enterprise Edition может привести к недолицензированию на сумму 190 000 USD (в ценах прайс-листа). Обращение в компанию, специализирующуюся на лицензионном консалтинге, которая могла бы помочь Вам в проведении внутреннего аудита программного и аппаратного обеспечения – это разумная инвестиция, объём которой существенно ниже тех рисков, в их денежном выражении, с которыми Вы можете столкнуться, если забудете включить в сертификацию ULA какие-либо среды или дата-центры.

Подсчёт произведён в соответствии с определением лицензионной метрики?

Программное обеспечение, включённое в Соглашение, нужно сертифицировать по количеству лицензий в определённых лицензионных метриках. Для Баз данных Oracle, программного обеспечения промежуточного слоя (Middleware) или программ бизнес-аналитики (Business Intelligence), этой лицензионной метрикой обычно является Processor.
Подсчёт лицензий в метрике "Processor"
Метрика Processor имеет своё определение в Соглашении, причём это определение содержит много факторов, которые могут повлиять на способ подсчёта лицензий, включая:

  • Количество процессоров;
  • Количество ядер в каждом процессоре;
  • Архитектура процессора;
  • Дата закупки сервера;
  • Конфигурация самого сервера, например, виртуализация или логическое разбиение (logical partitioning).

Незнание правильной методологии, правил лицензирования и подсчёта количества процессорных лицензий может привести к неправильной сертификации ULA и, таким образом, к большим проблемам с нормативно-правовым регулированием (compliance).

Например, представим, что у Вас есть 50 серверов, каждый из которых содержит один одноядерный процессор. На каждом сервере установлена программа Oracle Database Enterprise Edition. Для этих процессоров Вы можете применить понижающий коэффициент Oracle Processor Core Factor, равный 0,5 для процессоров Intel. Таким образом, Вам нужно сертифицировать:

50 серверов x 1 процессор х 1 ядро х 0,5 = 25 лицензий в метрике Processor.

Однако, поскольку эти серверы используют одноядерные процессоры, Вам нужно применить Oracle Processor Core Factor, равный 1.0, вместо коэффициента 0,5, который применим только к многоядерным процессорам. Таким образом, Вам нужно сертифицировать:

50 серверов x 1 процессор х 1 ядро х 1,0 = 50 лицензий в метрике Processor.

Неправильное применение всего только одного параметра Core Factor может привести (после окончания сертификации ULA) к нехватке 25 лицензий для Oracle Database Enterprise Edition в метрике Processor. В денежном выражении эта недостача равна 1,187,500 USD в ценах прайс-листа.

Установлено и запущено (Installed and running)
Параграф в соглашении ULA, относящийся к сертификации, утверждает, что все процессоры в серверах, на которых установлено И запущено (installed AND running) программное обеспечение, необходимо включать в сертификацию. В то же время, стандартное определение лицензионной метрики Processor использует выражение «установлено И\ИЛИ запущено» ("installed AND\OR running"). Используя выражение «установлено И запущено», Oracle стремится обезопасить себя от ситуации, когда Заказчик будут устанавливать большое количество ПО на настольные компьютеры\портативные компьютеры\серверы с целью увеличить количество лицензий, которые они могут использовать для сертификации в конце срока Соглашения. Но как определить, что только установлено, а что в действительности используется? Например, если Вы видите внутри Вашей БД таблицу с именем Sales (Продажи) или Costs (Затраты), чьим владельцем (owner) является пользователь с именем SH, который использовал опцию БД под названием Partitioning. Можете ли Вы заключить из этого, что Вы используете опцию Partitioning и Вам необходимо сертифицировать это использование? Ответ – НЕТ. Sales и Costs – стандартные примеры схем в БД Oracle, использующие Partitioning по умолчанию (by default). Ввиду этого это «использование» не требует лицензирования для опции Partitioning и, следовательно, не должно включаться в сертификацию Вашего ULA.
Серверная виртуализация
Использование виртуализации может сделать процесс сертификации ещё более сложным и один-единственный неверно сделанный шаг может привести к гигантским рискам. Oracle подразделяет разные виды виртуализации на Soft Partitioning (например VMware) и на Hard Partitioning (например, IBM LPAR).

Представим себе, например, кластер VMware, который Вы используете в том числе и для ПО Oracle. Знаете ли Вы, как подсчитывать количество процессоров, которые Вам нужно сертифицировать в этом случае? Все физические процессоры и\или ядра физических машин, которые являются частью этого кластера VMware, необходимо лицензировать. НО каждую из 23-х отдельно лицензируемых опций БД и управляющих пакетов management packs, которые Вы можете использовать совместно со своей БД в этом виртуализированном окружении, тоже нужно лицензировать отдельно в том же количестве и в тех же лицензионных метриках, что и Базу данных. Нередко мы видим Заказчиков, сертифицирующих большое количество процессорных лицензий для БД Oracle Database Enterprise Edition, не понимая, что непредумышленное использование ими опции БД (например, Advanced Compression) требует лицензировать эту опцию отдельно и в том же количестве процессорных лицензий, которое они использовали для БД Oracle Database Enterprise Edition в целях проведения сертификации ULA.

Другой пример, который приходит на ум, это использование логической технологии виртуализации IBM LPAR в связке с ПО Oracle.

Знаете ли Вы, как подсчитывать количество процессоров, которые Вам нужно сертифицировать в случае, если Вы используете такие функции этой технологии, как "dedicated capacity" или "shared resource pool"? И знаете ли Вы, что для вида виртуализации "capped Solaris Containers" количество ядер, нуждающихся в сертификации/лицензировании вычисляется по формуле:

(ncpus или pset.max)/(number of threads per core) = cores (ядра, нуждающиеся в лицензировании).

А что Вам нужно делать, если Вы используете услуги хостинга от компаний, наподобие Amazon? Нужно ли Вам так же включать эти лицензии в сертификацию?

Заключение

Соглашение ULA может быть превосходным выбором для Вашей организации, предоставляющим огромные преимущества, если Вы осведомлены обо всех упомянутых в этом документе важных деталях и о тех особенностях, которые остались за пределами этой небольшой статьи. И если Вы знаете, как управлять рисками, связанными с упомянутыми особенностями. Консалтинговые компании, специализирующиеся на лицензировании ПО Oracle, поддержат Вас в Вашем стремлении извлечь максимум выгоды из Вашего Соглашения ULA.
Функции СУБД
Например, опции БД (database options) или управляющие пакеты (Enterprise management packs)
Вопросы?
Если Вам что-то не ясно или Вы не нашли ответа на свой вопрос в нашей статье, свяжитесь с нами, мы постараемся максимально оперативно ответить Вам.
Свяжитесь с нами