Лицензирование SLES в рамках OES

[Константин Ошмян]

Отрывок из лицензионного соглашения на OES11sp2:

Linux Platform Deployment. You must acquire a User license for each User. Each person who accesses or uses the Software must have at least one user object uniquely assigned to that person and access the Software through the user object.

Provided that You comply with the requirements in this paragraph and elsewhere in this Agreement, You are authorized to use an unlimited number of copies of the SUSE® Linux Enterprise Server portion of the Software (SLES®) to run OES services for licensed OES Users. In addition, You may use an unlimited number of copies of SLES in support of any other software product You elect to use to service, support, secure or manage OES services for licensed OES Users. However, the foregoing license grants do not permit You to use SLES (or any updates thereto provided in connection with Your OES licenses) to run any software application or appliance that does not service, support, secure or manage OES services. By way of example, line of business applications and high performance computing applications do not qualify for use with the SLES licenses granted herein. Use of the Software deployed on the Linux platform may be on a physical server or a virtual server environment and is limited to use on the x86 and x86-64 architectures.

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

С одной стороны, в предыдущем предложении есть формулировка: "the SUSE® Linux Enterprise Server portion of the Software (SLES®)", которую можно трактовать как то, что под SLES®-ом можно понимать только "portion of the Software", т.е. тот SLES, который входит в состав продукта (в OES 11sp2 входит SLES11sp3).

С другой стороны, эта фраза явно относится к другой мысли (лицензирование по пользователям), после чего идёт: "In addition", - т.е. "кроме того", после чего ещё зачем-то явно оговаривается платформа ("the x86 and x86-64 architectures"), хотя в состав 11-го OES-а входит SLES только на одной платформе (x86-64).

Словом, вопрос: могу ли я сейчас для сервера мониторинга использовать, скажем, SLES12sp1? Не будет ли это нарушением лицензии? (доступ к обновлениям на SLES12 у меня есть, т.к. есть несколько лицензированных серверов именно под SLES, без OES-а).

Ivan L.?

[Иван Левшин aka Ivan L.]

Умеешь ты, Костя, вопросы задавать Насколько я помню - здесь речь идет о том, что ты можешь использовать входящий в состав поставки OES SLES для сервисов, которые требуют его наличия. Иными словами - эта лицензия не подразумевает использования SLES-серверов без OES. Переводя на русский - ты можешь использовать сервера для мониторинга, но они будут считаться серверами OES, а не SLES. В модели лицензирования OES лицензирование по серверам не используется, т.е. у тебя их может быть хоть миллион. Важно количество объектов User, а число серверов. В OES2015, кстати, изменили условия, при которых неактивные пользователи (и, соответственно, число активных лицензий) считаются.
У меня подобные заковыристые случаи в прошлом были - тогда они решались именно так. Изменилось ли что-нибудь - уточню и сообщу. Если вдруг забуду - напомни, плз. В личку или почту, ОК?

[Константин Ошмян]

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

В данный момент меня интересует именно то, что я отметил синим ("in addition" к OES-серверам, которые лицензируются по пользователям). Чтобы было понятнее, приведу конкретные примеры.

Пример 1.
Для централизованного выкачивания OES-овских обновлений установлен сервер SMT (Subscription Managament Server). На этом сервере никакие службы OES не крутятся и никакие пользователи (кроме встроенного root-а) к нему не ходят. Он, по сути, является прокси между всеми серверами OES, расположенными в нашей внутренней сети, и сервером NCC (Novell Customer Center) для выкачивания обновлений и пересылки данных о зарегистрированных серверах. Нужен не только для оптимизации трафика (чтобы не заставлять каждый OES-сервер выкачивать те же самые патчи), но и для безопасности (доступ наружу идёт только через прокси, жёстко контролируется, а для серверов OES вообще запрещён).
Согласно букве лицензионного соглашения, я считаю, что могу использовать SLES, входящий в состав OES-а, для работы этого SMT-сервера, поскольку используется он именно "to service, support, secure or manage OES services" и так далее. Причём SMT-сервер у меня исторически работает на 32-битном SLES-е (хотя в состав нынешнего OES-а входит только 64-битный), и я при этом ничего не нарушаю. Так ведь?

Пример 2.
Для мониторинга всего хозяйства установлен сервер Zabbix. Справедливости ради, мониторит он не только OES-овские серверы; но ведь и их тоже, поэтому вполне попадает под то же определение "to service, support, secure or manage OES services". Это аппаратный сервер, работающий под управлением SLES11 64-bit. Опять же - я ничего не нарушаю, поскольку процитированная часть лицензионного соглашения на OES мне явно разрешает ставить сколько угодно таких серверов. Так ведь?

Пример 3.
Вот теперь, собственно, то, к чему подвожу. Вышла новая версия сервера Zabbix - 3.x. И системные требования у неё такие, что поставить на SLES11 без плясок с бубном не получится: для некоторых из требуемых пакетов (в частности - PHP и библиотек для шифрования) нужны версии более новые, чем те, которые входят в состав 11-го SLES-а. Напрашивается установка более новой версии операционки (SLES12sp1 на данный момент), в которой всё необходимое есть. Но 12-й SLES нельзя обновлять через NCC (как минимум, сейчас, пока не вышла версия OES на базе SLES12).
Как я говорил, у меня есть несколько подписок на SLES12 и отдельный сервер SMT, "нацеленный" на SCC (Suse Customer Center). Технически, для нового сервера Zabbix 3.x я могу поставить SLES12sp1 и ходить к обновлениям через этот второй сервер SMT. Но вот насколько такое решение будет легальным? Могу ли я в таком случае считать, что 12-й SLES для Zabbix-а всё так же покрывается же лицензией на OES?

[Ковалев Артем]

Константин, если я правильно помню лицензионную политику Novell, то там так:
- SLES сервера бесплатные вообще.
- Первые 60 дней использования такого сервера у вас есть вся поддержка (патчи и т.д.). Потом - фигушки, надо покупать.

То есть вы законно ставите SLES12SP1, законно (в течении 60 дней) его обновляете до хруста, а потом SMT (который перед обновлением проверяет валидность сервера в SCC) должен этот конкретный сервер забанить в обновлении (по крайней мере SMT через NCC делает именно так). Работать он будет и дальше, а вот обновляться - нет.

Или вам критично именно получать обновления?

[Константин Ошмян]

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

Насчёт врЕменной работы обновлений - не знаю, не уверен. У меня так работало, когда я в своё время ставил сервер с ознакомительным ключом активизации и он сам с этим ключом регистрировался в NCC и ходил туда. Но с тех пор, как был поднят SMT, все серверы регистрируются через него и у них для этого вообще никаких ключей активации не спрашивают. Соответственно, и обновления доступны для них всех. Подозреваю, это потому что купленный на контору продукт - именно OES, который лицензируется по пользователям и дозволяет ставить любое количество серверов.

Сейчас поставили второй сервер SMT, который "смотрит" на SCC (я об этом писал в соседней теме). 12-е SLES-ы так же спокойно регистрируются и ходят за обновлениями через этот новый SMT, не спрашивая никаких ключей активации. Подозреваю, что вряд ли их количество жёстко контролируется, и тем более вряд ли SMT-сервер будет кого-то из них ограничивать (откуда он знает, который из серверов надо резать?).

Но вопрос остаётся, т.к., повторюсь, лицензионная чистота и возможность обращения в техсаппорт - критичны.

[Ковалев Артем]

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

[Константин Ошмян]

Странно, как-то наши серверы SMT по отношению к NCC ведут себя противоположным образом.
Я при начальном конфигурировании SMT указывал данные, полученные с NCC через пункт "Mirror Credentials". Насколько я понимаю, эти данные относятся не ко мне лично, а к моей конторе, которая купила лицензии и с тех пор платит за саппорт. Даже если и вбивался тогда какой-либо ключ актитации для конкретной подписки, то он всё равно уже истёк за прошедшие несколько лет. Никаких ключей активации при регистрации конкретных серверов на этом SMT-сервере вводить не надо, всё регистрируется итак и все обновления доступны.

А как проуцедура регистрации сервера SLES на SMT-сервере проходила в вашем случае? Требовались ли какие-то ключи активации? Что происходило, если ничего не указать?

[Иван Левшин aka Ivan L.]

Коллеги, вы путаете теплое с мягким SLES - GPL-продукт, на минуточку. Т.е. использовать в production любой SLES вы можете совершенно невозбранно - оно реально бесплатно. Платной является только подписка на обновления и техподдержка - т.е. в течение trial-периода вы имеет право и на то, и на другое. Потом - надо куплять. Именно поэтому феномен "лицензия на SLES" в природе отсутствует как вид и класс, если "подписка SLES".

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

Костя, думается мне, что ответ я дал - однако после праздников уточню еще раз (на всякий случай). Вчера только из командировки вернулся, там с интернетом все было невесело.

[Константин Ошмян]

Иван, спасибо!
По твоим словам получается, что даже не будь у нас купленного OES-а, мы вполне можем использовать SLES 12 для любых целей (в том числе под Zabbix), никаких претензий к нам при каких-либо аудитах не будет. Правда, мы не будем иметь возможности обратиться в SUSE-шную техподдержку, если что.

Не очень понятно, правда, даст ли нам право обращения в техподдержку (например, относительно совместимости kernel-modules с конкретным "железом", у нас был прецендент) факт наличия у нас купленного OES-а.

однако после праздников уточню еще раз (на всякий случай).

Уточни, пожалуйста.

[Иван Левшин aka Ivan L.]

Обращение в поддержку осуществляется в рамках подписки (maintenance). Насчет багов точно не помню - вроде бы в случае, если баг обнаружен и подтвержден, у заказчика есть право на патч. Но все усилия по обнаружению и доказыванию - за счет заказчика.

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

[Иван Левшин aka Ivan L.]

Прочел SUSE Terms and Conditions - не нашел там расхождений с тем, что уже было сказано. По поводу OES и SLES - лицензии на OES не подразумевают использования SLES в рамках этих лицензий отдельно от серверов OES. Переводя на язык родных осин: ставить отдельные SLES-сервера и получать на них всякие плюшки в рамках лицензии OES не получится. В то же время поставить отдельно стоящий самостоятельный SLES - не вопрос. Если не покупаем подписку - никаких обновлений и поддержки, но использовать его можно. Нельзя использовать триальную подписку в production и для коммерческих целей, в остальном ограничений я не нашел.

[Константин Ошмян]

Иван, спасибо!