О лицензиях

(и к сожалению почти только о них)

Я вынужден продолжить нашу дискуссию с Г.М. Ладыженским, начавшуюся с его статьи "Tuxedo System: разработка систем клиент-сервер". Я действительно сожалею об этом, ибо вместо обсуждения технических вопросов (а мы оба являемся прежде всего специалистами по СУБД) приходится возвращаться к вопросу о лицензировании. Я вынужден подтвердить мое утверждение о том, что, увы, в этом вопросе Г.М. Ладыженский - пусть неумышленно - но вводит читателей в заблуждение. Его рассуждения о лицензировании сервера Oracle, приведенные в реплике "О мониторах транзакций и не только о них" - опять-таки к сожалению - только усугубляют ситуацию.

Безусловно ни я, ни Г.М. Ладыженский не являемся юристами, чтобы дать полностью компетентный анализ положений, содержащихся в юридическом документе (а "Условия лицензирования" - это юридический документ). Тем не менее есть один основополагающий принцип, который всегда применяется в подобных случаях: трактовка должна быть такова, чтобы ее последователное применение не приводило к абсурду и полному выхолащиванию духа документа. Посмотрим с этой точки зрения, к чему приводит последовательное применение той концепциии, которую предлагает использовать (или во всяком случае допускает) Г.М. Ладыженский. Если подсчитывать "одновременные подключения к базе данных", понимаемые в смысле "одновременно обслуживаемые запросы" (как это собственно говоря и предлагается), то сразу встает вопрос: а почему тогда нужно рассматривать в качестве "атомарной обслуживаемой единицы" процесс приложения, а не процесс (или нить внутри процесса), который выделяется на самом сервере для обслуживания запроса? Логической разницы ведь никакой между ними нет (поскольку о процессах ничего не говорится в документе, то они не дифференцируются и следовательно юридически являются однородными). Но ведь в каждый конкретный момент времени сервер может одновременно выполнять количество процессов, заведомо не превышающее количество установленных на нем процессоров (такова архитектура Фон-Неймана, по которой строятся все массово производимые компьютеры). Следовательно получается, что и число одновременных пользователей не может превышать числа процессоров на сервере! Абсурд!

В действительности трактовка "спорных" предложений проста и однозначна. Посмотрим еще раз на них внимательно. В первом предложении говорится об "устройствах ввода" - а никак не о "пользовательских процессах" - но не обо всех, "с которых потенциально возможен одновременный доступ к мультиплексирующим устройствам", а конкретно о тех, которые одновременно работают с приложениями, осуществляющими доступ к БД (таков смысл первого предложения). При этом не важно, какие промежуточные аппаратно-программные средства (в т.ч. мультиплексирующие) используются для осуществления данного доступа (таков смысл второго предложения). И нету здесь никакого противоречия! Чтобы окончательно расставить точки над i, замечу, что указанная трактовка представляет собой не мое личное мнение, а официальную бизнес-практику корпорации Oracle.

К сожалению Г.М.Ладыженский допустил еще одну юридическую неточность в своей реплике. Экспорт технологий шифрования информации не запрещен безусловно законами США: речь идет только о технических ограничениях при таком экспорте. Именно поэтому, например, экспортная версия Oracle Advanced Networking Option обеспечивает шифрование 48-разрядными ключами, а не 64-разрядными, как "домашняя" версия. Соответственно и Российским законом (точнее указом президента) не запрещается безусловно импорт технологий шифрования.

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