Не класть его в код. Заодно - не закладывать заведомо левой архитектуры.

Никуда не класть. Заставлять вводить пользователя. Для сервисов - делать аутентификацию средствами ОС того пользователя, под которым работает сервис.

Пароль к embedded db - довольно странное понятие. Впрочем, для экономии времени предлагаю тебе подумать над следующим аспектом: как бы ты ни прятал пароль, никому не потребуется его выковыривать. Будет вполне достаточно декомпилировать твою программу, добавить в нее любую нужную функциональность и скомпилировать назад.

azzпрограмма будет обработана дефокусатором.
И что? Это, допустим, усложнит задачу "понять, как она работает". Но вставить свой код в нужное место от этого особо сложнее не станет.

azzВ дб будет лежать дата до которой программа оплачена.
Хакеры всего мира уже радуются. Столько вариантов справиться, что аж глаза разбегаются.

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

azzпроблема в том сто программа не продается насовсем а сдаётса
Это называется аренда. И я бы на твоем месте изучил вопрос - почему этот метод удивительно непопулярен у пользователей, даже Microsoft не удалось его протолкнуть. А единственные представители этого жанра обладают одной важной особенностью.

azz. т.е. дата будет менятся каждый месяц
Ну и рассылай новые ключи при каждом продлении.

azzэто конечно был бы вариант. Но мы расчитываем через постоянные обрашения к серверу вычислять не спер ли кто нашу прогу
Если программа вынуждена лезть к вашему серверу (вынуждена - не в смысле "вы так написали", а в смысле "это действительно нужно ей для работы"), это единственная стоящая защита из названных, о других и думать незачем.

Это отдельная тема, и изначально заданный вопрос не даст на нее ответа.

Этой задачи решать не доводилось. Сходу я бы назвал следующие пути, которые стоит как-то скомбинировать:

1. Поиск экземпляром других экземпляров в локальной сети.

2. Анализ временных пересечений - одновременно несколько сессий от одной программы.

3. Трассировка маршрутов от клиента к вашему серверу и их анализ.

4. Введение спонтанно меняющегося ключа, идентифицирующего клиента и меняющегося по команде с сервера. То есть: клиент идентифицировался как #1, мы на уровне протокола сказали, что отныне он называется #2, если кто-то после этого вновь сказал, что он #1 - разные экземпляры налицо.

Во многих случаях, имхо, хватит не пускать на сервер параллельные сессии. Это очень легко обосновать клиенту ("Да, Вы можете поставить программу и на работе, и дома, но не можете же Вы работать одновременно и там, и там"), это вполне удобно честному клиенту, который хочет сделать бэкаповскую копию итп, и это позволит очень недурно позабавиться, если новая сессия не будет отрубаться сама, а будет отрубать предыдущую - в этом случае эти 20 человек мигом передерутся за доступ.