Вот эти вопросы, и наши ответы на них.

Когда Вы устанавливаете программное обеспечение Oracle, как физическое лицо или как компания, Вы принимаете условия лицензионного соглашения. Раньше это соглашение называлось OLSA (Oracle License and Services Agreements) сейчас же оно называется OMA (Oracle Master Agreement). Такие соглашения определяют, в соответствии с какими положениями и условиями Вы можете использовать программное обеспечение Oracle, а также предоставляют разрешение Oracle на проведение аудита.

Oracle's License Management Services (LMS) является подразделением Oracle, которое проводит аудит от имени корпорации Oracle. Также существует практика привлечения третьей стороны (партнеров LMS), которые могут выполнять аудит от имени Oracle LMS.

Oracle LMS была создана для выполнения лицензионных аудитов конечных пользователей и партнеров.

Однако, в ряде стран, местные менеджеры по продажам (sales representative) начинают лицензионный аудит (проверку лицензий) сами по себе, обычно пытаясь «продать» его конечному пользователю как оптимизацию лицензий или проверку бизнеса, проводя аудит самостоятельно.

В течение аудита необходимо заполнить таблицу Excel (Oracle Server Worksheet) с подробной информацией о Вашей ИТ-инфраструктуры. Дополнительно, Вам может быть предложено, запустить скрипты на Ваших серверах или выполнить разнообразные команды в различных компьютерных программах. Заполненную таблицу и файлы журналов работы программ необходимо отослать в Oracle для анализа. В итоге результаты сводятся в заключительный отчёт, в котором Oracle информирует Вас об уровне лицензированности ПО Oracle на Вашем предприятии. Если Вы соглашаетесь оплатить необходимые лицензии для устранения выявленных недостатков, то на этом процесс аудита обычно заканчивается.

Если Вы игнорируете запрос на проверку лицензий или лицензионный аудит, то этот вопрос может быть передан в Oracle LMS (в случае, если инициатива исходила от менеджера по продажам), либо в юридический отдел Oracle (Oracle's Legal Department). Отказ от сотрудничества с Oracle в проведении аудита рассматривается как существенное нарушение лицензионного соглашения, влекущее преследование в судебном порядке со стороны Oracle.

По сути, разницы нет.
Самое время дать нашим читателям пояснение относительно перевода на русский язык терминов Oracle License Review и Oracle License Audit. В английском языке термин Audit (аудит) звучит несколько более сурово, чем Review (проверка). В русском языке всё обстоит с точностью наоборот. Слово «аудит» звучит достаточно буднично для русского уха, в то время как современные реалии связывают слово «проверка» в сознании обывателя с повышенной угрозой и, возможно, с некими силовыми акциями. Поэтому при выработке русской терминологии на самой заре создания Oracle LMS в России было принято решение переводить выражение «License Review» как «лицензионный аудит», а «License Audit» переводить как «лицензионная проверка».

Oracle LMS говорит «аудит» вместо «проверка», чтобы получить сотрудничество от конечного пользователя, потому что это звучит дружелюбнее. Однако, аудит по-прежнему относится к оценке и анализу Вашего использования ПО для определения соответствия по лицензиям. И в итоге будет произведена проверка Вашего использования лицензий. Из-за использования слов «лицензионный аудит» конечный пользователь зачастую пребывает в замешательстве и непонимании, что лицензионный аудит то же самое, что и проверка лицензий. В дополнение стоит указать, что этот факт и является причиной, почему в уведомительном письме по лицензионному аудиту обычно имеется ссылка на один особенный пункт соглашения. На пункт про лицензионную проверку.

Oracle License Management Services (LMS) – это подразделение Oracle, которое было создано для защиты прав контрактной и интеллектуальной собственности Oracle путем выполнения лицензионных аудитов у пользователей программного обеспечения Oracle и партнеров. Oracle LMS является частью Финансового блока Oracle (Oracle's Finance), подразделения Oracle, и насчитывает пару сотен сотрудников, присутствующих почти в каждой стране. Хотя другие сотрудники Oracle (например, менеджеры по продажам) выполняют подобные действия, проводя «аудит бизнеса», LMS является единственным подразделением, которое было официально образовано для выполнения аудита от лица Oracle Corporation.

Дополнительную информацию об LMS Вы можете получить, перейдя по ссылке: http://www.oracle.com/us/corporate/license-management-services/index.html

Аудит начинается, когда Вы получаете письмо с уведомлением, что Вы были выбраны для проведения лицензионного аудита или лицензионной проверки. В письме будет указан сотрудник LMS, который будет проводить аудит, либо партнер LMS, выделенный для аудита.

Обычно в письме указываются юридические лица и перечень программного обеспечения Oracle, которые включаются в аудит. Письмо отправляется в адрес CIO[1] и/или CFO[2] вашей организации. Это письмо отправляется в адрес CIO и CFO для того, чтобы быть уверенным в том, что аудиту уделяется наибольшее внимание в рамках организации, и на этих лиц можно эскалировать проблемы, в случае если Oracle увидит, что Ваша организация не сотрудничает при аудите. Вам предложат назначить контактное лицо, которое будет единой «точкой входа» и будет выполнять функцию координации при аудите со стороны Вашей организации. Этот человек должен координировать работу различных ИТ-специалистов для предоставления запрашиваемой информации.

В начале аудита проводится вводное совещание, на котором аудиторы объясняют план проведения аудита. Одной из целей совещания, является обсуждение и согласование контрольных точек и дат, когда будет предоставлена требуемая информация. Предлагаемая методология требует от Вас заполнить таблицу Excel - шаблон (называемый Oracle Server Worksheet), содержащий перечень сведений, описывающих Вашу IT-инфраструктуру. Дополнительно, аудиторы обычно просят установить и запустить различные скрипты, которые собирают информацию по установке программного обеспечения Oracle и/или его использовании. Эту информацию, как правило, могут предоставить Ваши штатные (или внештатные) IT-сотрудники, Администратор(ы) Баз Данных и Менеджеры бизнес-приложений. Как только все данные будут предоставлены в распоряжение Oracle, они будут подвергнуты анализу. В результате анализа будет сформирован список дополнительных проверок и/или контрольных вопросов. Вам придется отвечать на все эти вопросы до тех пор, пока не будут полностью выяснены все подробности относительно установки и/или использования программного обеспечения Oracle. Затем выводы этого анализа объединяются в официальном отчете, фиксирующем нехватку/избыток лицензий в Вашей организации. Конечные пользователи не подписывают и не согласовывают этот отчет - это формальное уведомление от Oracle о выявленных нарушениях Вашего текущего лицензионного соглашения (если такое имеется). Разъяснение представленных результатов Вы получите на следующей, запланированной встрече. Итоговый отчет затем передается Вашему персональному менеджеру по продажам и Вам предлагается в течение 30 дней устранить выявленные несоответствия путем покупки лицензий.
[1] ИТ-директор
[2] Финансовый директор

В стандартном договоре указано: «Oracle может начать проверку использования программного обеспечения через 45 дней после письменного уведомления».

Если конечные пользователи полно и достоверно ведут отчеты по использованию их ПО, то 45 дней вполне достаточно для приведения ПО в соответствие с требованиями аудита. Однако, нередко аудиторы Oracle пытаются начать проверку ранее (до истечения 45 дней со дня получения письменного уведомления). А также, конечные пользователи обычно плохо понимают какое ПО развернуто в их организации и как оно используется. Поэтому, как правило, 45-ти дней недостаточно для того, чтобы Пользователи могли полностью подготовиться к аудиту. У конечного пользователя обычно нет всех необходимых знаний и опыта, чтобы оценить последствия аудита.

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

Наша практика показывает, что каждый конечный пользователь проверяется компанией Oracle или его LMS партнерами в среднем раз в 3-4 года. Oracle установил этот период, после того, как выяснилось, что конечные пользователи обновляют аппаратное обеспечение в среднем раз в 3-4 года. Поскольку количество лицензий, требуемое для лицензирования ПО Oracle, в большой степени зависит от аппаратного обеспечения, на котором устанавливается ПО (особенно базы данных и ПО среднего слоя), применяется этот промежуток (3-4 года). Очевидно, что этот интервал может уменьшиться, если Oracle предполагает нарушение условий Соглашения или в случае, если предыдущий аудит был ограничен частью ПО, развернутого в организации. Кроме того, этот период, естественно, зависит от количества аудиторов и их загруженности.

Обычно аудиторы отвечают, что Ваша компания была выбрана случайно. Но на самом деле есть как минимум два подразделения Oracle, которые могут выбрать Вашу компанию для проведения аудита: отдел продаж (Oracle's Sales organization) или департамент LMS. В случае если Ваш персональный менеджер по продажам получит какие-либо сведения о возможном нарушении соглашения, то он может предложить провести аудит в Вашей компании. LMS далее оценивает возможную стоимость недостающих лицензий, после чего они решают проводить аудит либо отклонить этот запрос. Также LMS регулярно самостоятельно отбирает компании для аудита. При этом учитываются критерии, по которым оценивается риск нелицензионного использования ПО конечным пользователем и возможные финансовые потери, с которыми может столкнуться Oracle.

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

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

Устаревшие лицензионные метрики (такие как Named User, Concurrent Device, Universal Power Unit) не используются при продажах уже несколько лет, соответственно они не могут быть применены для определения текущего использования ПО Oracle. Таким образом, конечные пользователи, имеющие соглашения в старых лицензионных метриках, находятся в зоне самого высокого риска нелицензионности и часто выбираются для аудита.

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

Да, Вы должны беспокоиться!

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

Во-вторых, потому что лицензирование ПО Oracle почти всегда в значительной степени зависит от конфигурации аппаратных серверов, на которых оно установлено. Далее, если конечный пользователь решает отдать его IT на поддержку третьей стороне, то именно она определяет аппаратную платформу (включая системы виртуализации, сервера) для развертывания ПО Oracle. Сервисное соглашение об уровне оказания услуг (SLA) между конечным пользователем и сервисной компанией содержит ключевой показатель «производительность». Для достижения заданной производительности сервисная компания обычно использует более мощные серверы или более гибкую аппаратную инфраструктуру. Но с другой стороны, большее количество серверов, или более мощный сервер, или более гибкая инфраструктура (например, виртуализация VMware) требуют от конечного пользователя закупки дополнительных лицензий.

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

В условиях лицензионного соглашения Вы несете ответственность за Ваши расходы по проведению аудита. Некоторые вендоры заявляют, что если Ваша организация использует на 5% или 10% лицензий больше, чем приобрела, то Вы будете обязаны отплатить стоимость работы аудиторов вендора. У Oracle иной подход. Oracle сам оплачивает работу своих аудиторов. Однако, за время и деньги, потребляемые Вашими внутренними ресурсами (закупки, IT сотрудники и др.) и Вашими сервисными компаниями, финансово отвечает Ваша компания.

В случае, если Вы обнаруживаете нелицензионную установку и/или использование ПО Oracle, Вы должны будете оплатить стоимость использования этих программ. В такой ситуации Oracle будет требовать приобретения необходимых лицензий и соответствующей поддержки в срок до 30 дней, ссылаясь на его лицензионную политику (Compliance policy) и соглашение с Вами.

На такие закупки, как правило, не распространяются какие-либо скидки. В случае, если у Вас есть соглашение о фиксации цены с Oracle («price hold») с определенным уровнем скидки на ПО, по которому обнаружено недолицензирование, то «price hold» обычно применяется. Значительная скидка может быть предоставлена в том случае, если Вы охотно соглашаетесь заплатить за дополнительные лицензии с целью будущего масштабирования ПО Oracle.

Отдельно от приобретаемых лицензий и поддержки Вы должны будете оплатить поддержку за предшествующий период, которую Oracle называет «Back Support». «Back Support» - это счет за стоимость поддержки, которую Oracle «потерял» за период, в который использовалось нелицензированное программное обеспечение. Ее стоимость вычисляется как 22% от стоимости лицензий считая с даты, когда пользователь начал использовать ПО Oracle, без необходимых лицензий.

Пример:

Если конечный пользователь имеет 2 Процессорные лицензии Oracle Database Enterprise Edition и было обнаружено использование 3-х Процессорных лицензий Oracle Database Enterprise Edition за период 6 лет, то конечный пользователь должен будет заплатить:

Стоимость лицензии: 47,500$
Стоимость поддержки: 10,450$
Стандартная скидка: 10%
Стоимость лицензии со скидкой: 42,750$
Стоимость поддержки со скидкой: 9,495$
«Back support» на 6 лет: 6*9,405 = 56,430$
Итого, счет на: 42,750+9,405+56,430=108,585$

Нет, не будет. Согласно Вашему соглашению и Oracle's Compliance Policy, если конечный пользователь имеет лицензированное программное обеспечение, то это означает, что на конечном пользователе лежит обязанность обеспечить использование этих лицензий в соответствии с условиями лицензионного соглашения. Поэтому обязанностью конечного пользователя является понимание лицензионных правил (лицензионные политики, политики поддержки, программная документация и т.д.) и их соблюдение.

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

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

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

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

Нет. Скрипты только собирают информацию об установленном и/или использованном ПО Oracle в виде предварительных данных. Оценка результатов работы скриптов требует экспертных знаний от компании Oracle или специализированных фирм для анализа данных и сопоставления их с текущими контрактами и для определения степени соответствия текущего использования и имеющихся лицензий.

Кроме того, как правило это не один скрипт, а несколько. Разные скрипты запускаются для разных программ Oracle. Например, для получения информации по Oracle Database используется скрипт с запросами к базе данных Oracle и скрипт, собирающий информацию об оборудовании, где установлена Oracle Database. Oracle WebLogic требует других скриптов, которые исполняются на серверах, где обнаружена эта программа; Oracle Siebel требует другого набора скриптов; Oracle E-Business Suite требует также отдельного набора скриптов и т.д.

Oracle LMS верифицировал множество инструментария других вендоров, включая BDNA, Easyteam, Flexera Software, Hewlett-Packard, iQuate, Lime Software и Nova Ratio. Решение от Oracle LMS по верификации инструментария этих вендоров было достаточно разумным. В случае, если конечный пользователь выполняет аудит при использовании какого-либо из этих инструментов, то он не сможет заявить, что процесс требует очень много времени и трудозатрат, т.к. этот инструмент уже установлен в его инфраструктуре.

Конечные пользователи зачастую думают, что с того момента, как они установили такой инструментарий, они полностью контролируют ПО Oracle. Однако они забывают, что никто не говорил, а они и не проверяли, что делают эти инструменты. А эти инструменты просто собирают первичные данные по Oracle Database и опциям Oracle Database также как скрипты от LMS. Но, эти инструменты не собирают первичные данные для тысяч остальных программ Oracle. В добавок, предоставляемые сторонними инструментами параметры оборудования, на котором установлено программное обеспечение, не верифицированы LMS. Следовательно, при проведении аудита LMS будет требовать от Вас запуска их скрипта CPU для сбора параметров оборудования.

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

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

Перечень программ Oracle достаточно обширен, в частности из-за большого количества приобретений (например, BEA Systems, Siebel Systems, PeopleSoft, JD Edwards и т.п.). Некоторые из этих, приобретенных компанией Oracle программ, могут быть предметом для аудита, особенно, если имеется высокий риск по недолицензированию.

Команда аудита Oracle обычно фокусируется на определенном наборе программ Oracle, из-за того, что большое количество конечных пользователей используют эти программы и существует большая вероятность их недолицензирования. Аудиторы Oracle обычно обращают пристальное внимание на: Oracle Database (включая Database Option и Database Enterprise Management Packs), Oracle Application Server, WebLogic и Tuxedo, SOA, E-Business Suite, Siebel и JD Edwards. В таких странах, как США, дополнительное внимание привлекает программы Agile/Autovue, тогда как в регионе EMEA [1] обращают внимание на Primavera.

[1] Europe, Middle East, Africa

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

Вы можете предполагать, что такая организация как Oracle, должна быть в состоянии предоставить Вам полный и точный список Ваших лицензий. Однако, Вы можете, заплатить за лишние лицензии, если Вы не выполните проверку. Почему? Во многих случаях, когда независимые аудиторы проводили сверку списка лицензий, предоставленного Oracle, с текущими соглашениями, то обнаруживалось множество несоответствий. Например, лицензионные метрики не были корректно отражены во внутренних системах Oracle (в частности после поглощений компанией Oracle других производителей ПО); были применены текущие, а не договорные лицензионные метрики; программы и компоненты, покрываемые определенными лицензиями, не были учтены аудиторами, и т.п. Все эти расхождения, которые могут быть выявлены в процессе последующего аудита, должны быть задокументированы и учтены по его завершении.

Поэтому важно получить все Ordering Documents, License Agreements (Software License & Services Agreements (SLSA), Oracle License & Service Agreement (OLSA) или Oracle Master Agreements (OMA)), Support Maintenance Renewals, Partner Ordering Forms, Partner Agreements и соответствующую программную документацию, являющуюся частью лицензионного соглашения, и любые другие документы (счета, заказы на поставку (PO), коммерческие предложения, письма и т.д.). Это все обеспечивает правильное понимание приобретенных лицензий и прав на поддержку.

Система класса Software Asset Management (SAM) может быть хорошей отправной точкой для всесторонней оценки использования программного обеспечения. Но потребуется приложить дополнительные усилия, чтобы получить полную и точную оценку использования учитываемого ПО. Большинство этих систем не способны подсчитать количество физических лиц, авторизованных как пользователи программ в мультиплексирующем окружении, и они не способны выявить дублирующиеся учетные записи или предоставить (без привлечения экспертов со специальными знаниями) точную и четкую информацию, относительно того, действительно ли установленные программы используются и требуют отдельного лицензирования.

Выполнение надлежащей сверки продуктов или компонентов, для которых были приобретены лицензии, и установленных и/или используемых продуктов или компонентов практически невозможно выполнить на 100% любой из имеющихся SAM – программ. В качестве одного из множества примеров приведем случай установки Oracle Application Server Enterprise Edition. Инструментарий сканирования обнаружит установленный Oracle Application Server, а также Oracle Database. Как только инструмент обнаружит эти две программы, он сообщит, что Вы должны лицензировать обе программы по отдельности. Однако лицензии на Oracle Application Server Enterprise Edition включают в себя право ограниченного использования Oracle Database для хранения инфраструктурных и конфигурационных данных. Так как программа SAM не учитывает эту информацию об ограниченном использовании, то многие компании лицензируют продукты дважды, предварительно не убедившись, что уже получили права на установку отдельных продуктов в рамках других лицензий.

Есть одна вещь, относительно которой Вам надо договориться с Oracle во время решения вопросов, связанных с выявленным нелицензированным ПО Oracle, — это получение письменного подтверждения («Close letter») от Oracle LMS. Это письмо должно подтверждать, что Oracle освобождает Вашу организацию от всякого вида обязательств, долгов, претензий, перспектив, штрафов, начисления процентов, оплат услуг адвокатов, и вообще всех видов ущерба и характера (включая, но не ограничиваясь оплатой за лицензии, оплатой за поддержку, штрафов за нарушения, прямых и косвенных убытков, штрафных санкций, известных или неизвестных, заявленных и не заявленных) возникающих вследствие выявленных несоответствий по использованию лицензий. В случае судебного преследования это подтверждение может быть предано огласке и это может быть более значимым, чем сами нарушения или штрафы.

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

1. Перечень оборудования:

• Аппаратная конфигурация (модель сервера, кол-во процессоров, кол-во ядер на процессор, тип процессора и т.п.).
• Используемая виртуальная технология (VMware, LPAR, Solaris Containers и т.п.).
• Конфигурация виртуализации (VMware cluster, Capped/Uncapped LPARs, и т.п.).
• Соответствующие сервера для обеспечения отказоустойчивости (отказоустойчивый кластер, синхронизируемые базы, зеркалирование и т.п.).

2. Перечень признаков установки программного обеспечения:

• Каталог установки.
• Основные выполняемые файлы.
• Запущенные процессы.
• Используемые порты.

3. Конфигурация программного обеспечения:

• Версии (редакции) установленного программного обеспечения (standard edition, enterprise edition и т.п.).
• Установленные и/или использованные компоненты (например, DB Option, DB Packs).
• Компоненты среднего слоя (например, Coherence, Weblogic clustering и т.п.).

4. Использование программ:

• Кто авторизован для использования конкретных программ?
• Какие программы и оборудование авторизованы для использования конкретных программ?
• Что является мультиплексирующим внешним интерфейсом (multiplexing front end) этих программ?
• Какие бизнес-приложения связаны с приложениями среднего слоя и какое программное обеспечение среднего слоя связано с базами данных?

5. Юридические вопросы:

• Какие юридические лица используют программное обеспечение?
• Какие функциональные подразделения используют программное обеспечение?
• Каково географическое расположение установленного программного обеспечения?
• Используется ли программное обеспечение другими юридическими лицами (хостинг)?

Большинство компаний полагаются на IT инструментарий, чтобы убедиться в правильном использовании лицензий. Но физические пользователи могут не знать, что права в отношении ПО и устройств, зачастую не контролируются IT инструментарием. Представим, например, внешних сотрудников или агентов, которые работают с Вашей организацией от Вашего имени или специалистов, работающих в аутсорсинговой компании, поддерживающей Вашу IT-инфраструктуру. Думаете, они все знают, какое программное обеспечение они могут устанавливать и/или использовать? Программное обеспечение Oracle не имеет каких-либо технических ограничений (подобных программным ключам) и может быть легко скачено и получено для работы с ним. Как эти люди определят, что они могут делать или что они не должны делать? Это важный и часто недооцененный аспект SAM, состоящий в том, что сотрудники и пользователи программного обеспечения должны быть хорошо обучены определенным правилам, и эти правила должны быть ими поняты. Обучение должно быть постоянным процессом в Вашей компании, чтобы предотвратить возникновение неприятных ситуаций по некорректному использованию лицензий Oracle, которые могут дорого обойтись Вашей компании.

Основываясь на нашем опыте работы и опыте наших партнеров, мы определили примерно 50-60 областей, о которых компании сообщали при прохождении аудита.

Вот часть этих областей:

• Ошибка в определении исторических прав (продукт был приобретен от 3 до 9 лет назад), которая не дает возможность сократить количество недостающих лицензий.
• Применение неправильных лицензионных метрик, несоответствующих прописанным в контракте и условиям и положениям соглашения.
• Лицензии, наследуемые от присоединяемых и покупаемых компаний, которые могли бы быть использованы для сокращения количества недостающих лицензий.
• Неполное и/или неточное понимание по продуктам/компонентам, являющихся частью определенных лицензий Oracle, и которые могли бы быть использованы для сокращения количества недостающих лицензий (например, Oracle Database Enterprise Edition с условием ограниченного использования покрывается лицензией на Oracle Internet Application Server Enterprise Edition; Oracle Coherence покрывается лицензиями Oracle WebLogic Suite и так далее).
• Неполное и/или недостаточное понимание всех потоков данных между программами Oracle и мультиплексирующим внешним интерфейсом (multiplexing front end) и не понимание, что имеет ввиду Oracle под словами «подсчет количества пользователей на мультиплексирующем внешнем интерфейсе».
• Некорректное вычисление количества лицензий, необходимых для виртуальной инфраструктуры, которое зависит от технологий виртуализации и их конфигураций (таких как IBM LPar, VMware VSphere, Solaris Capped Containers, Oracle VM и т.п.).
• Некорректное лицензирование программ Oracle, установленных на инфраструктуре обеспечения отказоустойчивости.
• Ошибка при вычислении минимального количества требуемых лицензий на процессор для всех серверов, где установлено программное обеспечение Oracle, включая среды тестирования, разработки и приемки.
• Неполное и/или неточное понимание установленных и/или использованных компонентов и/или функций и/или модулей (таких как Database Options и/или Database Enterprise Management Packs, Human Resources, Financials и т.п.).
• Некорректный подсчет количества пользователей, не учитывающий дублирование учетных записей пользователей.
• Учет системных пользователей и/или неактивных пользователей, созданных программами.

Все определения лицензионных метрик Oracle содержат утверждение, что программное обеспечение Oracle требует лицензирования, если оно было установлено и/или запущено. Это означает, что пусковой механизм лицензирования срабатывает, когда программное обеспечение установлено, независимо от того насколько активно оно использовалось. За исключением случая с кластером отказоустойчивости (Failover), Oracle требует лицензирования программ, установленных в целях аварийного восстановления.

Есть ли тут еще исключения? Да, есть одно исключение, относящиеся к развертыванию и использованию Database Enterprise Edition Options и/или Database Enterprise Management Packs. Почему? Oracle Database Enterprise Edition поставляется с различными Database Options и Database Management Packs (или если Database Enterprise Edition была скачена, Database Options и Management Packs были скачены вместе с программой Database Enterprise Edition).

Конечный пользователь устанавливает Database Enterprise Edition Options и Management Packs, и в результате часто начинает использовать лицензируемые отдельно Database Enterprise Edition Options и Management Packs. В случае, если в процессе проведения лицензионного аудита было выявлено, что Database Enterprise Edition Options и Management Packs только установлены, но не использовались, конечный пользователь обычно получает возможность написать письмо «Certificate of Non Use». В этом письме (которое Oracle должен предложить, но не всегда это делает) конечный пользователь подтверждает и гарантирует, что он не использовал Database Enterprise Edition Options и/или Management Packs и гарантирует своей подписью, что он не будет никоим образом использовать Database Enterprise Edition Options и/или Management Packs пока не приобретет соответствующие лицензии.