Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069494
Тема сообщения
Замечание к КД
Тип сообщения
Замечание к КД
Поставщик
Kaz Trade
Представитель поставщика
ТАЛГАРОВ ЕРНАР ЕРКИНҰЛЫ
Дата и время отправки сообщения
2026-10-04 19:42:30
Текст сообщения
1. В пунктах 5.1 и 5.2 технической спецификации установлено обязательное требование о представлении потенциальным поставщиком в составе конкурсной заявки авторизационного письма от правообладателя и/или официального дистрибьютора.
2. При этом письмо должно быть не общим документом, подтверждающим легальность канала поставки программного обеспечения, а специально оформленным на имя конкретного Заказчика с обязательным указанием номера объявления и номера лота.
3. Считаем указанное условие требующим исключения либо существенной корректировки, поскольку оно не характеризует функциональные, технические, качественные либо эксплуатационные свойства предлагаемого товара.
4. Наличие или отсутствие индивидуального авторизационного письма не изменяет характеристики программного обеспечения, его лицензионность, информационную безопасность, совместимость, функциональность либо возможность законного использования.
5. Такое письмо характеризует исключительно наличие договорных или коммерческих отношений участника с конкретным правообладателем либо выбранным им официальным дистрибьютором.
6. Фактически возможность потенциального поставщика принять участие в закупке ставится в зависимость от волеизъявления третьего коммерческого лица, которое не является ни Заказчиком, ни организатором государственных закупок.
7. Правообладатель или дистрибьютор объективно вправе выдать такое письмо одному поставщику и отказать другому, несмотря на способность второго участника законно приобрести и поставить тот же лицензионный программный продукт.
8. Следовательно, доступ к закупке потенциально контролируется не только условиями конкурсной документации, но и третьей стороной.
9. Особенно ограничивающим является требование адресного письма с указанием номера объявления и лота.
10. Наличие обычного партнерского статуса, дистрибьюторского договора, лицензионного соглашения, счета, договора поставки либо возможности приобрести легальную лицензию оказывается недостаточным.
11. Участник должен дополнительно получить индивидуальный документ именно под данную закупку.
12. Это создает преимущество поставщикам, уже имеющим прямые договоренности с соответствующим правообладателем или его дистрибьютором.
13. Потенциальный поставщик, способный приобрести лицензию через официальный канал после признания победителем, может быть фактически лишен возможности участвовать только по причине отсутствия предварительно выданного адресного письма.
14. Требование является особенно существенным с учетом того, что закупается одна лицензия ПО 5.1 и одна лицензия ПО 5.2 в составе общего комплекта кабинета визуального искусства.
15. Объем закупаемого программного обеспечения не свидетельствует о необходимости предварительной индивидуальной авторизации поставщика правообладателем.
16. Заказчик вправе требовать поставку легального программного обеспечения и подтверждение правомерности его использования.
17. Однако данная цель может быть достигнута менее ограничивающими способами.
18. Например, предоставлением лицензионного сертификата.
19. Электронного лицензионного ключа.
20. Документа о приобретении лицензии через законный канал.
21. Лицензионного соглашения.
22. Счета или договора поставки.
23. Подтверждения регистрации лицензии.
24. Документа производителя или правообладателя непосредственно при поставке.
25. Таким образом, обязательное адресное авторизационное письмо не является единственным возможным средством подтверждения легальности программного продукта.
26. Дополнительно обращаем внимание на содержание примечания к самой технической спецификации, согласно которому установление квалификационных требований, предъявляемых к потенциальному поставщику, в технической спецификации не допускается.
27. Требование представить письмо от правообладателя/официального дистрибьютора фактически относится не столько к товару, сколько к статусу и взаимоотношениям самого участника с третьим лицом.
28. Следовательно, имеется внутренняя коллизия между примечанием ТС и требованиями пунктов 5.1 и 5.2.
29. Просим Заказчика пояснить, каким образом требование о персональном письме именно потенциальному поставщику не является дополнительным требованием к его коммерческому статусу.
30. Помимо письма, пункт 5.1 требует одновременного наличия сертификата соответствия требованиям СТ РК ISO/IEC 15408-3 с оценочным уровнем доверия не ниже 5.
31. Одновременно решение должно быть включено в реестр доверенного программного обеспечения и продукции электронной промышленности.
32. Одновременно ПО должно представлять собой кроссплатформенное решение.
33. Оно должно функционировать на персональных компьютерах и иных мобильных устройствах.
34. Должно поддерживать казахский и русский интерфейсы.
35. Должно иметь встроенный антивирус.
36. Лицензия должна быть бессрочной.
37. Должна обеспечиваться серверная проверка файлов с использованием криптографической системы безопасности, расположенной на территории Республики Казахстан.
38. Предусмотрены анализ поведения файлов, машинное обучение, обновляемые вирусные сигнатуры, двухпанельный режим и иные подробно описанные признаки.
39. Каждое из перечисленных условий отдельно может иметь техническое объяснение.
40. Однако их совокупность с реестром, уровнем доверия и обязательным адресным письмом существенно сокращает количество потенциально соответствующих решений.
41. Просим Заказчика подтвердить наличие на рынке как минимум трех независимых программных продуктов разных правообладателей, соответствующих всей совокупности требований пункта 5.1.
42. Аналогичная ситуация имеется по пункту 5.2.
43. Требуется специализированный драйвер доверенной загрузки.
44. Он должен иметь оценочный уровень доверия не ниже 5+.
45. Он должен быть интегрирован в UEFI.
46. Должен работать как DXE-драйвер.
47. Должен предотвращать неавторизованную загрузку ОС с внешних носителей.
48. Должен проверять цифровую подпись компонентов загрузочной цепочки.
49. Должен обеспечивать идентификацию, аутентификацию и авторизацию до загрузки операционной системы.
50. Должен вести и хранить журналы безопасности.
51. Решение также должно быть включено в реестр доверенного программного обеспечения.
52. И по нему также необходимо отдельное авторизационное письмо с номером объявления и лота.
53. Совокупность настолько конкретных архитектурных и документарных требований имеет признаки описания ограниченного круга решений.
54. Особое внимание обращаем на различие уровней доверия: по пункту 5.1 требуется не ниже 5, а по пункту 5.2 — не ниже 5+.
55. Просим указать функциональное обоснование необходимости именно данных уровней для кабинета визуального искусства/арт-терапии.
56. Из предмета закупки не следует, что моноблок предназначается для обработки государственной тайны, критической информационной инфраструктуры либо иной информации, объективно требующей столь специализированного комплекса доверенной загрузки.
57. Если такие задачи действительно имеются, они должны быть прямо раскрыты в технической спецификации.
58. В противном случае возникает вопрос о соразмерности указанных требований фактическому назначению кабинета.
59. Объединение обычного моноблока для учебного кабинета с двумя специализированными средствами информационной безопасности дополнительно сужает рынок поставщиков.
60. Поставщик мебели, художественных материалов и учебных принадлежностей одновременно должен иметь доступ к специализированному правообладателю ПО и получить от него адресные авторизационные письма.
61. Такое комплектование создает ограничение уже не только на уровне товара, но и на уровне структуры рынка потенциальных участников.
62. Просим исключить обязательное предоставление авторизационных писем из состава конкурсной заявки.
63. Альтернативно просим разрешить подтверждать законность поставки любым документом, свидетельствующим о легальном происхождении лицензии.
64. При необходимости письмо правообладателя может предоставляться победителем непосредственно при поставке программного обеспечения, а не использоваться как условие допуска к конкурсу.
65. Просим также исключить требование о персональном оформлении письма на Заказчика с указанием конкретного объявления и лота.
66. Если Заказчик считает письмо безусловно необходимым, просим привести конкретное обоснование, почему обычные документы легального приобретения лицензии не обеспечивают ту же цель.
67. Просим указать не менее трех правообладателей, которые без дискриминационного отбора потенциальных поставщиков готовы выдавать соответствующие письма всем участникам закупки на равных условиях.
68. Просим указать срок выдачи такого письма и порядок его получения.
69. Просим подтвердить отсутствие каких-либо требований правообладателя к участнику для выдачи письма, включая партнерский статус, объем закупки, регистрацию в партнерской программе либо предварительное коммерческое согласование.
70. Если такие дополнительные условия существуют, они фактически превращаются в скрытые условия допуска к государственной закупке.
71. Это особенно недопустимо, поскольку такие условия отсутствуют непосредственно в конкурсной документации и определяются третьей организацией.
72. В конечной редакции ТС должны оставаться требования к функционалу и безопасности программного обеспечения, но не требования о наличии у участника заранее сформированных коммерческих отношений с конкретным правообладателем.
73. Просим переработать пункты 5.1 и 5.2 в функционально нейтральной форме, обеспечить возможность предложения альтернативных решений и исключить положения, способные необоснованно ограничивать конкуренцию.
2. При этом письмо должно быть не общим документом, подтверждающим легальность канала поставки программного обеспечения, а специально оформленным на имя конкретного Заказчика с обязательным указанием номера объявления и номера лота.
3. Считаем указанное условие требующим исключения либо существенной корректировки, поскольку оно не характеризует функциональные, технические, качественные либо эксплуатационные свойства предлагаемого товара.
4. Наличие или отсутствие индивидуального авторизационного письма не изменяет характеристики программного обеспечения, его лицензионность, информационную безопасность, совместимость, функциональность либо возможность законного использования.
5. Такое письмо характеризует исключительно наличие договорных или коммерческих отношений участника с конкретным правообладателем либо выбранным им официальным дистрибьютором.
6. Фактически возможность потенциального поставщика принять участие в закупке ставится в зависимость от волеизъявления третьего коммерческого лица, которое не является ни Заказчиком, ни организатором государственных закупок.
7. Правообладатель или дистрибьютор объективно вправе выдать такое письмо одному поставщику и отказать другому, несмотря на способность второго участника законно приобрести и поставить тот же лицензионный программный продукт.
8. Следовательно, доступ к закупке потенциально контролируется не только условиями конкурсной документации, но и третьей стороной.
9. Особенно ограничивающим является требование адресного письма с указанием номера объявления и лота.
10. Наличие обычного партнерского статуса, дистрибьюторского договора, лицензионного соглашения, счета, договора поставки либо возможности приобрести легальную лицензию оказывается недостаточным.
11. Участник должен дополнительно получить индивидуальный документ именно под данную закупку.
12. Это создает преимущество поставщикам, уже имеющим прямые договоренности с соответствующим правообладателем или его дистрибьютором.
13. Потенциальный поставщик, способный приобрести лицензию через официальный канал после признания победителем, может быть фактически лишен возможности участвовать только по причине отсутствия предварительно выданного адресного письма.
14. Требование является особенно существенным с учетом того, что закупается одна лицензия ПО 5.1 и одна лицензия ПО 5.2 в составе общего комплекта кабинета визуального искусства.
15. Объем закупаемого программного обеспечения не свидетельствует о необходимости предварительной индивидуальной авторизации поставщика правообладателем.
16. Заказчик вправе требовать поставку легального программного обеспечения и подтверждение правомерности его использования.
17. Однако данная цель может быть достигнута менее ограничивающими способами.
18. Например, предоставлением лицензионного сертификата.
19. Электронного лицензионного ключа.
20. Документа о приобретении лицензии через законный канал.
21. Лицензионного соглашения.
22. Счета или договора поставки.
23. Подтверждения регистрации лицензии.
24. Документа производителя или правообладателя непосредственно при поставке.
25. Таким образом, обязательное адресное авторизационное письмо не является единственным возможным средством подтверждения легальности программного продукта.
26. Дополнительно обращаем внимание на содержание примечания к самой технической спецификации, согласно которому установление квалификационных требований, предъявляемых к потенциальному поставщику, в технической спецификации не допускается.
27. Требование представить письмо от правообладателя/официального дистрибьютора фактически относится не столько к товару, сколько к статусу и взаимоотношениям самого участника с третьим лицом.
28. Следовательно, имеется внутренняя коллизия между примечанием ТС и требованиями пунктов 5.1 и 5.2.
29. Просим Заказчика пояснить, каким образом требование о персональном письме именно потенциальному поставщику не является дополнительным требованием к его коммерческому статусу.
30. Помимо письма, пункт 5.1 требует одновременного наличия сертификата соответствия требованиям СТ РК ISO/IEC 15408-3 с оценочным уровнем доверия не ниже 5.
31. Одновременно решение должно быть включено в реестр доверенного программного обеспечения и продукции электронной промышленности.
32. Одновременно ПО должно представлять собой кроссплатформенное решение.
33. Оно должно функционировать на персональных компьютерах и иных мобильных устройствах.
34. Должно поддерживать казахский и русский интерфейсы.
35. Должно иметь встроенный антивирус.
36. Лицензия должна быть бессрочной.
37. Должна обеспечиваться серверная проверка файлов с использованием криптографической системы безопасности, расположенной на территории Республики Казахстан.
38. Предусмотрены анализ поведения файлов, машинное обучение, обновляемые вирусные сигнатуры, двухпанельный режим и иные подробно описанные признаки.
39. Каждое из перечисленных условий отдельно может иметь техническое объяснение.
40. Однако их совокупность с реестром, уровнем доверия и обязательным адресным письмом существенно сокращает количество потенциально соответствующих решений.
41. Просим Заказчика подтвердить наличие на рынке как минимум трех независимых программных продуктов разных правообладателей, соответствующих всей совокупности требований пункта 5.1.
42. Аналогичная ситуация имеется по пункту 5.2.
43. Требуется специализированный драйвер доверенной загрузки.
44. Он должен иметь оценочный уровень доверия не ниже 5+.
45. Он должен быть интегрирован в UEFI.
46. Должен работать как DXE-драйвер.
47. Должен предотвращать неавторизованную загрузку ОС с внешних носителей.
48. Должен проверять цифровую подпись компонентов загрузочной цепочки.
49. Должен обеспечивать идентификацию, аутентификацию и авторизацию до загрузки операционной системы.
50. Должен вести и хранить журналы безопасности.
51. Решение также должно быть включено в реестр доверенного программного обеспечения.
52. И по нему также необходимо отдельное авторизационное письмо с номером объявления и лота.
53. Совокупность настолько конкретных архитектурных и документарных требований имеет признаки описания ограниченного круга решений.
54. Особое внимание обращаем на различие уровней доверия: по пункту 5.1 требуется не ниже 5, а по пункту 5.2 — не ниже 5+.
55. Просим указать функциональное обоснование необходимости именно данных уровней для кабинета визуального искусства/арт-терапии.
56. Из предмета закупки не следует, что моноблок предназначается для обработки государственной тайны, критической информационной инфраструктуры либо иной информации, объективно требующей столь специализированного комплекса доверенной загрузки.
57. Если такие задачи действительно имеются, они должны быть прямо раскрыты в технической спецификации.
58. В противном случае возникает вопрос о соразмерности указанных требований фактическому назначению кабинета.
59. Объединение обычного моноблока для учебного кабинета с двумя специализированными средствами информационной безопасности дополнительно сужает рынок поставщиков.
60. Поставщик мебели, художественных материалов и учебных принадлежностей одновременно должен иметь доступ к специализированному правообладателю ПО и получить от него адресные авторизационные письма.
61. Такое комплектование создает ограничение уже не только на уровне товара, но и на уровне структуры рынка потенциальных участников.
62. Просим исключить обязательное предоставление авторизационных писем из состава конкурсной заявки.
63. Альтернативно просим разрешить подтверждать законность поставки любым документом, свидетельствующим о легальном происхождении лицензии.
64. При необходимости письмо правообладателя может предоставляться победителем непосредственно при поставке программного обеспечения, а не использоваться как условие допуска к конкурсу.
65. Просим также исключить требование о персональном оформлении письма на Заказчика с указанием конкретного объявления и лота.
66. Если Заказчик считает письмо безусловно необходимым, просим привести конкретное обоснование, почему обычные документы легального приобретения лицензии не обеспечивают ту же цель.
67. Просим указать не менее трех правообладателей, которые без дискриминационного отбора потенциальных поставщиков готовы выдавать соответствующие письма всем участникам закупки на равных условиях.
68. Просим указать срок выдачи такого письма и порядок его получения.
69. Просим подтвердить отсутствие каких-либо требований правообладателя к участнику для выдачи письма, включая партнерский статус, объем закупки, регистрацию в партнерской программе либо предварительное коммерческое согласование.
70. Если такие дополнительные условия существуют, они фактически превращаются в скрытые условия допуска к государственной закупке.
71. Это особенно недопустимо, поскольку такие условия отсутствуют непосредственно в конкурсной документации и определяются третьей организацией.
72. В конечной редакции ТС должны оставаться требования к функционалу и безопасности программного обеспечения, но не требования о наличии у участника заранее сформированных коммерческих отношений с конкретным правообладателем.
73. Просим переработать пункты 5.1 и 5.2 в функционально нейтральной форме, обеспечить возможность предложения альтернативных решений и исключить положения, способные необоснованно ограничивать конкуренцию.
