... но приоритет у нее низкий и пока нет планов ее реализации даже в следующем релизе Guardant SDK ...

Печально

Поэтому гибким должен быть наш продукт. Я уже писал свое мнение - мне кажется, было бы здорово, если в настройках ограничения работы по сети был бы пункт ""Не ограничивать". Пусть автозащита/API обращаются к ключу, но не занимают лицензию.
Готов стать испытательным полигоном для данной опции  ("выдайте" хоть пре-альфу, писанную на коленке ).

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

App1 нужно запускать на тех же рабочих станциях, что и App2, либо App2 переносить на сервер терминалов.

App1 и App2 (есть еще и App3, которое в данном обсуждении не рассматривается) - сторонний софт, который интегрируется посредством наших dll.

App1 в частном случае - это 1С. Я сомневаюсь что небольшие фирмы ради интеграции будут менять технологию работы с 1С (работа с файловой базой на терминальном сервере или работа с клиент-серверной базой), т.к. это требует немалых дополнительных расходов (железо, софт, услуги по переходу, дальнейшая поддержка - за SQL надо "ухаживать",  Сервер 1С:Предприятия тоже иногда внимания к себе требует).

App2 не будет работать в терминальной сессии.

Поэтому гибким должен быть наш продукт. Я уже писал свое мнение - мне кажется, было бы здорово, если в настройках ограничения работы по сети был бы пункт ""Не ограничивать". Пусть автозащита/API обращаются к ключу, но не занимают лицензию.
Готов стать испытательным полигоном для данной опции  ("выдайте" хоть пре-альфу, писанную на коленке ).

1. Юзер1 включает ПК, в автозагрузке висит App2, которое подгружает dll2 - минус одна лицензия из общего ресурса ключа.
2. Юзер2 включает ПК, в автозагрузке висит App2, которое подгружает dll2 - минус одна лицензия из общего ресурса ключа.
Итого 0 свободных лицензий в общем ресурсе.
3. Юзер1 заходит на терминал, запускает App1, которое пытается загрузить dll1,  и видит сообщение об отсутствии ресурсов...
Напомню, App1 основное приложение,  а App2 вспомогательное, которое в некоторых компаниях может и не использоваться.

Тогда работает корректно. Как я уже писал ранее - терминальные сессии отслеживаются и даже для одного пользователя, открывшего несколько сессий (между собой разделяются даже локальные и RDP сеансы), на каждую из них потребуется отдельная лицензия.

Так в данном примере, для ключа с общим сетевым ресурсом в две лицензии, в первом случае обе лицензии занимаются приложением App2, запускаемом на двух локальных рабочих станциях, а для терминальных сессий (им нужны дополнительные лицензии) лицензий уже нет. И наоборот - для App1, запускаемом в двух терминальных сессиях, выделяются обе лицензии, а для App2 лицензий не хватает. Тут либо App1 нужно запускать на тех же рабочих станциях, что и App2, либо App2 переносить на сервер терминалов.

trh пишет:

Если делать наоборот (выкинем из автозагрузки App2) - зашли в терминал, запустили App1, переключились на свой рабочий стол, запустили App2, переключились в терминал, то работает.

Тут не совсем понятно сколько ПК учавствует в тестировании: один ПК + терминальная сессия или два ПК + две терминальные сессии? Какой компьютер выступает в роли сервера терминалов: отдельный или один из пользовательских?

Поторопился с "наоборот" - тоже не работает, для dll2 на клиентских ПК нет ресурсов на ключе.

Если делать наоборот (выкинем из автозагрузки App2) - зашли в терминал, запустили App1, переключились на свой рабочий стол, запустили App2, переключились в терминал, то работает.

Тут не совсем понятно сколько ПК учавствует в тестировании: один ПК + терминальная сессия или два ПК + две терминальные сессии? Какой компьютер выступает в роли сервера терминалов: отдельный или один из пользовательских?

В таком случае достаточно защищать и лицензировать dll_2 "по рабочим станциям" без использования таблицы лицензий (параметр dwModuleLMS задается как "-1").

dll_1 следует лицензировать "по рабочим станциям" с использованием таблицы лицензий, чтобы при логине лицензия выделялась из нужного LMS-модуля.

Попробовал. Не работает ваша схема. Пошагово ...

SignNet:  общий ресурс ключа = 2; Модуль №1 = 2.

Обфускатор:
/INIT /CFO=хх /SO /SE ... /ATR=1 /GN3S=0:х:ххх /UN=0x2 /MN=0 /LOGIN_MODE=S "dll1.dll" /ATR=1 /GN3S=0:x:xxx /LOGIN_MODE=S "dll2.dll"

Протектер:
/GN3S=0:x:xxx /ATR=1 /PER=xx /UN=0x2 ... /EXCEPT /LOGIN_MODE=S /MN=0 /Q "dll1.dll"
/GN3S=0:x:xxx /ATR=1 /PER=xx /LOGIN_MODE=S /Q "dll2.dll"

1. Юзер1 включает ПК, в автозагрузке висит App2, которое подгружает dll2 - минус одна лицензия из общего ресурса ключа.
2. Юзер2 включает ПК, в автозагрузке висит App2, которое подгружает dll2 - минус одна лицензия из общего ресурса ключа.

Итого 0 свободных лицензий в общем ресурсе.

3. Юзер1 заходит на терминал, запускает App1, которое пытается загрузить dll1,  и видит сообщение об отсутствии ресурсов...
Напомню, App1 основное приложение,  а App2 вспомогательное, которое в некоторых компаниях может и не использоваться.

Если делать наоборот (выкинем из автозагрузки App2) - зашли в терминал, запустили App1, переключились на свой рабочий стол, запустили App2, переключились в терминал, то работает. Но, согласитесь, как-то это не решение, а костыль.

dll_2 необходимо защитить, но чтобы она не захватывала лицензию

В таком случае достаточно защищать и лицензировать dll_2 "по рабочим станциям" без использования таблицы лицензий (параметр dwModuleLMS задается как "-1").

dll_1 следует лицензировать "по рабочим станциям" с использованием таблицы лицензий, чтобы при логине лицензия выделялась из нужного LMS-модуля.

Верно ли то, что App_2 и dll_2 не будут защищаться?

Нет неверно.
App_1 и App_2 это сторонние приложения (приложения других разработчиков)
dll_2 необходимо защитить, но чтобы она не захватывала лицензию

1. А если в настройках терминала нет ограничения на количество сессий для пользователя?

Не влияет.

Верно ли то, что App_2 и dll_2 не будут защищаться?

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

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

1. А если в настройках терминала нет ограничения на количество сессий для пользователя?
2. dll_2 на клиентском ПК все равно будет занимать еще одну лицензию

Да. Это факт, т.к. некоторые внедрения проходят непосредственно через нас.

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

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

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

Да. Это факт, т.к. некоторые внедрения проходят непосредственно через нас.

Уточните, пожалуйста, верно ли то, что за основной фактор, который "мешает" применять лицензирование по рабочим станциям, принята вероятность установки защищенного приложения на сервере терминалов?

Упрощу задачу.
Если я разобью библиотеку dll_3 на две  - dll_3 и dll_4, dll_3 будет использоваться только в dll_1, а dll_4 только в dll_2. Тогда я смогу полноценно защитить dll_1 и dll_3 через LicenseWizard. Но остается открытым вопрос о защите dll_2 и dll_4 таким образом, чтобы не захватывалась еще одна лицензия при использовании dll_2.

Все таки нужен пункт "Не ограничивать" в настройке "Ограничивать запуск по сети" (/LOGIN_MODE=H | S | P | N ).

Напишу по вашему совету запрос на hotline.