Лицензионный и / или одновременный механизм принудительного использования для довольно открытого продукта UNIX?
Я был бы признателен за любые предложения о том, как добавить принудительное применение лицензионного ключа или одновременного принудительного ограничения пользователей к программному продукту (на основе UNIX), который - хотя и не является явно открытым исходным кодом - конечный пользователь номинально имеет исходный код или может, возможно, получить с относительной легкостью, потому что серверы, на которых он работает, расположены на их территории и т. д.
Очевидно, я не ищу и не ожидаю технику, которая не может быть обойдена кем-то, кто сильно мотивирован на это, и / или 1337 h4x0rs, которые просто так хороши. Смысл таких механизмов борьбы с пиратством состоит не в том, чтобы помешать пользователю делать то, что он действительно хочет сделать, а просто в том, чтобы сделать его достаточно раздражающим для того, чтобы это не стоило хлопот по сравнению с относительной простотой просто оплаты за другая (дешевая) лицензия - по крайней мере, для конечного пользователя со средними способностями.
Это требует чего-то более изощренного, чем просто безопасность от неясности (что также заставит вас смеяться над пользователями, которые могут натолкнуться на это, даже непреднамеренно без намерения изменить настройку), но ничего похожего на то, что требуется для защиты ракетного бункера. Достаточно, чтобы сказать: "Да, этот продукт действительно ограничивает использование того, что вы купили". Не должно быть ничего достаточно интересного, чтобы мотивировать того, кто ищет славу и удачу, опубликовать в блоге запись о том, как взломать его, в идеале, хотя, учитывая, насколько нишевым является продукт и насколько он недорог, я не вижу в этом беспокойство.
Единственный реальный метод, который я могу придумать, - это скомпилировать некоторые подпрограммы, которые являются функционально необходимыми для остальной части программы, в статический или динамический двоичный перезагружаемый объект и, вместе с ним, включить проверки. Необходимо, чтобы подпрограмма была критичной в некотором неразрывном отношении, а не искусственной проверкой только для этого конкретного условия, иначе пользователь мог бы просто пойти и отключить вызов функции. Идея состоит в том, что отключение вызова функции имеет и другие непривлекательные последствия.
Это ничего, что умный хакер не может дизассемблировать, и, очевидно, если функция достаточно тривиальна, чтобы встроить ее в бесполезный в противном случае двоичный файл, она достаточно тривиальна и для переопределения вне ее. Но это больше усилий, чем обычный конечный пользователь мог бы пережить. И, конечно, опять же, смысл не в том, чтобы механически остановить пиратство, а просто в том, чтобы установить небольшой предел, чтобы продукт не работал исключительно по системе чести, хотя я уверен, что этого достаточно для многих корпоративных покупателей. в США.
Это общий подход? Есть ли лучшие?
1 ответ
Все, что это сделает, это разозлит ваших честных пользователей, в то время как любой пират, достойный его соли, взломает это через пять минут - не делайте этого