По идее ты можешь пытаться защищать только метаданные: структуру таблиц, бизнес-логику.
Сами данные - это собственность пользователя и нельзя запрещать ему делать что-то с этими данными.
У нас выполнена защита от переноса только клиентских приложений. Привязка к оборудованию. Мысль ты уловил уже эту.
Одно время мы и ключами защищались, но потом отказались, т.к. страдала оперативность при расширении состава АРМ на объектах (при использовании локальных ключей).
Были инциденты, что особо продвинутые вписывали и использовали собственные процедуры. Не запрещаем. Но при апгрейдах не следим за этим - вычищаем разностным скриптом всё не своё.

Dimitry Sibiryakovo_v_aПо идее ты можешь пытаться защищать только метаданные: структуру таблиц,
бизнес-логику.
Но лучше этого не делать. Ибо нет в них никакой "rocket science".

Мы тоже по жизни не страдаем от открытости метаданных.

Dimitry Sibiryakovo_v_aУ нас выполнена защита от переноса только клиентских приложений. Привязка к
оборудованию. Мысль ты уловил уже эту.
Для его поделки скорее всего хватит написать в лицензионном договоре "если ваш ключ
всплывёт где-то ещё - попадёте конкретно на бабки". Ну и раздать пользователям именные
ключи даже без привязки к железу.

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

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

Есть множество ресурсов, посвящённых оценкам рисков взлома ПО. Прежде, чем закладываться на что-то серьёзное, оцените трудоёмкость создания системы, трудоёмкость её взлома и потенциальный профит, который получит взломщик.

Например, при стоимости программы в 10-20 у.е. при продажах 5 копий в месяц никто в здравом уме её и ломать не будет, а за популярный продукт в несколько сотен копий в месяц пусть и при такой цене возьмутся охотнее.
Другое дело - системы стоимостью тысячи у.е.
Нашу систему во времена MS-DOS успешно, к примеру, тиражировали без нашего ведома. В рамках одной организации система как-то была растиражирована по объектам.
Но после серьёзной переработки нашего ПО при очередных апгрейдах постепенно идёт процесс легализации этих копий, т.к. данные - они ценнее всего. И отказ от инструмента пускает под откос весь техпроцесс этой организации с тысячей сотрудников и десятками подразделений. И только разработчики могут обеспечить преемственность и перенос данных между старой и новой версией системы.

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