Мы как-то исследовали Оракл на проде, правда strace, смотрели вызовы dbwriter'a, и это никак не поломало базу.
А вот JIT в Соколе остановился полностью.

Если "сейчас внутри ядра используется JIT для внутренних запросов по обслуживанию словаря/кэша.", в таком случае

не получается, что "- LLVM - это опция, она не формирует СУБД и не является обязательным компонентом в архитектуре",

а получается что база не работает без LLVM, она формирует СУБД и является обязательным компонентом в архитектуре.

А вот что мне пишет ИИ по поводу лицензий:

При статической линковке «Сокол» и LLVM превращаются в единый бинарный файл. В этом случае исключение («LLVM Exception») не освобождает от базовых требований Apache 2.0, так как вы распространяете саму библиотеку внутри своего кода.

Компания обязана предоставить информацию в следующем объеме:
Текст лицензии Apache 2.0: Он должен быть включен в состав дистрибутива (например, в файле THIRD-PARTY-NOTICES или LICENSE).
Copyright Notice: Сохранение строки вида: Copyright (c) 2003-2019 University of Illinois at Urbana-Champaign. All rights reserved. и упоминание LLVM Release License.
Атрибуция: Указание, что продукт содержит программное обеспечение, разработанное проектом LLVM (LLVM Project).

Почему это важно для коммерческой СУБД:

Статическая линковка делает компоненты LLVM неотъемлемой частью «Сокола». С точки зрения лицензионного аудита (особенно при сертификации во ФСТЭК или включении в реестр отечественного ПО), отсутствие упоминания стороннего кода может быть расценено как нарушение условий лицензирования open-source компонента.

Требуемый объем документации:
Обычно это одна страница в PDF-документе «Формуляр» или «Руководство администратора» со списком заимствованных компонентов и полным текстом их лицензий.

Мой вопрос ИИ: в каких случаях идет освобождение от LLVM Exception ?
Ответ ИИ:

Исключение LLVM Exception (официально оно называется LLVM Exceptions to the Apache 2.0 License) работает не как «обязанность», а как льгота. Оно не «освобождает» вас от чего-то плохого, а наоборот — освобождает от строгих требований основной лицензии Apache 2.0.
Вы перестаете попадать под действие этого исключения (и на вас накладываются полные требования Apache 2.0) в следующих случаях:
1. Распространение исходного кода (Source Code)
Исключение создано специально для бинарных файлов (скомпилированного кода). Если вы берете исходники LLVM, модифицируете их и распространяете именно как исходный код, вы обязаны соблюдать все правила Apache 2.0: сохранять все уведомления, помечать измененные файлы и прилагать текст лицензии. Исключение здесь не работает.
2. Использование LLVM как библиотеки (Ваш случай с СУБД)
Это самый тонкий момент. Исключение было написано, чтобы защитить пользователей компилятора (чтобы обычный программист, написав "Hello World" на C++, не был обязан писать «Copyright Apple/LLVM» в своей программе).
Когда льгота работает: Когда код LLVM попал в ваш бинарник автоматически (как вспомогательный рантайм-код, например libgcc или части libcxx).
Когда льгота НЕ работает: Когда вы осознанно берете LLVM как инструментарий (framework), линкуете его библиотеки (статически или динамически) для реализации функций своего продукта (как JIT в СУБД Сокол). В этом случае вы распространяете производный продукт, и вы обязаны предоставить атрибуцию (упоминание лицензии).
3. Нарушение условий Apache 2.0
Если вы удаляете файлы LICENSE или NOTICE из дистрибутива или пытаетесь выдать код LLVM за свой собственный, вы теряете право на использование лицензии в целом, включая и её «льготную» часть (Exceptions).

Короткий итог:
Разработчики СУБД Сокол не освобождаются от упоминания LLVM, потому что:
Они используют LLVM как основной функциональный модуль (движок JIT), а не просто как «невидимый» побочный продукт компиляции.
Статическая линковка делает их продукт Derivative Work (производным произведением).

ltrace не вредит базе Оракл, а у Сокол перестают работать JIT-запросы.

akorotchenko [игнорируется] 

Я сделал ролик с проблемой, где видно что под ltrace запрос без JIT выполняется, а запрос с JIT висит.
(Он отработал только после киляния ltrace).
Считаете здесь все нормально, и он "просто тормозит"?

С этим надо было разбираться в 2022 году при подаче заявления в Реестр ПО Минцифры. По факту Вы присвоили себе масштабные американские программные разработки и много лет выдаете их как свои собственные.

Запрос, который не укладывается в полагающееся ему время - это НЕРАБОТАЮЩИЙ запрос.
И никто не будет ждать пока он отработает за несколько часок/суток/дней/недель/месяцев/лет. А тем более ПРОМЫШЛЕННАЯ система.
Я всего лишь показал, что любой JIT-запрос, даже такой элементарный как SELECT 1+1; легко остановить в СУБД, т.е. превратить в абсолютно НЕРАБОТАЮЩИЙ. Причем это можно сделать абсолютно штатными линуксовыми утилитами.
К чему Вы прикладываете эти все выкладки?
Это объяснения ДБА будет показывать своему руководству при таких сбоях?

Эксперты Реестра ПО Минцифры всегда задают вопрос о компонентах (и их правообладателях), присутствующих в программном обеспечении.
Здесь было заявление о наличии LLVM и ее американских правообладателях?
Если это не было сделано - это предоставление недостоверной информации.
Если это было сделано - тогда фраза "СУБД не основана на продуктах с отрытым исходным кодом и не использует стороннее программное обеспечение." не соответствует действительности, и должна быть исправлена. А так же должны быть добавлены лицензии LLVM в поставку СУБД Сокол и в ее документацию.
Только и всего.
Вы согласны с этим?

Это тема с обсуждением не КТО Я, а КТО ВЫ и ЧТО из себя представляет СУБД СОКОЛ.

Вопрос к ИИ:
Какая лицензия на библиотеку unixodbc? Какие требования лицензии к коммерческим закрытым проектам, которые распространяют бинарники?

Ответ ИИ:
Библиотека unixODBC использует модель двойного лицензирования, разделяя компоненты проекта на разные типы прав:
- Библиотеки (драйвер-менеджер и основные библиотеки): Распространяются под лицензией GNU LGPL (Lesser General Public License) версии 2.1 или выше.
- Программы и утилиты (например, isql, odbcinst): Распространяются под лицензией GNU GPL версии 2.0 или выше.

Требования к коммерческим закрытым проектам (LGPL)

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

Метод линковки:

Динамическая линковка (рекомендуется):

Вы должны подключать unixODBC как общую библиотеку (например, .so файл). Это позволяет конечному пользователю заменить версию unixODBC на свою собственную без пересборки вашего приложения.

Статическая линковка:

Если вы включаете код библиотеки непосредственно в исполняемый файл, вы обязаны предоставить пользователю возможность перелинковки. Обычно это требует предоставления объектных файлов (.o) вашего приложения или использования других механизмов, позволяющих заменить код библиотеки.

Сохранение уведомлений:

В документации или сопроводительных материалах необходимо указать, что используется unixODBC, и включить текст лицензии LGPL и уведомления об авторских правах.

Изменения в самой библиотеке:

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

Предоставление исходников библиотеки:

Вы должны предоставить пользователям способ получить исходный код той версии unixODBC, которую вы используете (например, ссылкой на официальный репозиторий или включением архива в поставку).

Вопрос к ИИ:
Какая лицензия на библиотеку icu? Какие требования лицензии к коммерческим закрытым проектам, которые распространяют бинарники?

Ответ ИИ:
libicu (ICU) использует крайне либеральную лицензию ICU License (начиная с версии 58 — Unicode License), которая по своей сути идентична лицензии MIT.

Требования к коммерческим закрытым проектам:

Лицензия ICU — одна из самых «дружелюбных» для бизнеса. Если вы распространяете бинарные файлы (исполняемые файлы вашего приложения вместе с ICU), требования следующие:

Сохранение уведомлений:

Вы обязаны включить текст лицензии и уведомление об авторских правах (copyright notice) в сопроводительную документацию или экран «О программе».

Отсутствие ответственности:

Вы не можете предъявлять претензии авторам ICU, если библиотека что-то сломает. ПО поставляется «как есть».
Никакого копилефта: В отличие от LGPL (как у unixODBC), лицензия ICU не требует:
Предоставлять возможность замены библиотеки пользователем.
Раскрывать исходный код ваших модификаций самой библиотеки ICU.
Использовать динамическую линковку (статическая линковка разрешена без условий).

Вопрос к ИИ:
Какая лицензия на библиотеку libfabric? Какие требования лицензии к коммерческим закрытым проектам, которые распространяют бинарники?

Ответ ИИ:
Библиотека libfabric (Open Fabrics Interfaces) распространяется под двойной лицензией: вы можете выбрать либо BSD (2-clause), либо GNU GPL версии 2.
Для коммерческих закрытых проектов наиболее выгодным является выбор лицензии BSD, так как она накладывает минимальные ограничения и не требует открытия вашего исходного кода.

Требования при распространении бинарников (по лицензии BSD):

Если вы включаете скомпилированную библиотеку libfabric в свой закрытый продукт, вам необходимо выполнить следующие условия:

Сохранение уведомлений:

Вы обязаны включить оригинальное уведомление об авторских правах libfabric, список условий лицензии и отказ от гарантий в документацию или другие материалы, сопровождающие поставку (например, в файл LEGAL, LICENSE или раздел «О программе»).

Метод линковки:

В отличие от LGPL, лицензия BSD не делает различий между статической и динамической линковкой. Вы можете линковать библиотеку любым способом (включая статический), не раскрывая код своего приложения.

Изменения в библиотеке:

Если вы изменили сам код libfabric, вы не обязаны публиковать эти изменения (при выборе лицензии BSD), хотя сообщество приветствует это. Вы можете оставить свои правки внутри библиотеки закрытыми.

Использование имени:

Вы не можете использовать названия проекта (libfabric, OpenFabrics Alliance) или имена его авторов для рекламы своего продукта без специального письменного разрешения.

Резюме для бизнеса:

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