Лицензионный и / или одновременный механизм принудительного использования для довольно открытого продукта UNIX - PullRequest
1 голос
/ 19 июля 2009

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

Очевидно, я не ищу и не ожидаю техник, которые не могут быть обойдены кем-то, кто сильно мотивирован на это, и / или 1337 h4x0rs, которые просто так хороши. Смысл таких механизмов борьбы с пиратством состоит не в том, чтобы помешать пользователю делать то, что он действительно хочет сделать, а просто в том, чтобы сделать его достаточно раздражающим, чтобы сделать это действительно не стоит хлопот по сравнению с относительной легкостью просто платить за другая (дешевая) лицензия - по крайней мере, для конечного пользователя со средними способностями.

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

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

Это ничего, что умный хакер не может разобрать, и, очевидно, если функция достаточно тривиальна, чтобы встроить ее в другой бесполезный двоичный файл, она достаточно тривиальна и для переопределения вне ее. Но это больше усилий, чем обычный конечный пользователь мог бы пережить. И, конечно же, опять же, смысл не в том, чтобы механически остановить пиратство, а просто в том, чтобы установить небольшой предел, чтобы продукт не работал чисто в системе чести, хотя я уверен этого достаточно для многих корпоративных покупателей в США.

Это общий подход? Есть ли лучшие?

1 Ответ

1 голос
/ 19 июля 2009

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

...