エンドユーザーが名目上ソースコードを持っている（または可能である）（UNIXベースの）ソフトウェア製品にライセンスキーの適用または同時ユーザー制限の適用を追加する方法についての提案に感謝します。おそらく、それを実行しているサーバーは彼らの敷地内にあるなどので、比較的簡単に入手できます。
明らかに、私は、そうする意欲の高い人や、そのような優れた1337h4x0rsによって回避できない技術を求めたり期待したりしていません。このような著作権侵害対策メカニズムのポイントは、ユーザーが本当にやりたいことをするのを妨げることではなく、単にお金を払うだけの比較的簡単なことと比較して、面倒なことをする価値がないことを十分に煩わしくすることです。別の（安価な）ライセンス-少なくとも、単なる平均的な能力のエンドユーザー向け。
それには、隠すことによる単なるセキュリティよりも洗練されたものが必要です（これは、設定を変更する意図がなくても、偶然に遭遇する可能性のあるユーザーに笑われることもあります）が、ミサイルサイロを保護するために必要なものに近いものはありません。「はい、この製品は実際にあなたが購入したものに使用を制限します」と言うのに十分です。名声と幸運を求める人がそれをクラックする方法についてブログエントリを投稿するように動機付けるのに十分興味深いものであってはなりませんが、理想的には、製品がどれほどニッチで安価であるかを考えると、それはそうではないと思います懸念。
私が考えることができる唯一の実際のテクニックは、プログラムの残りの部分に機能的に不可欠ないくつかのルーチンを静的または動的なバイナリのリロード可能なオブジェクトにコンパイルし、それとともにチェックを含めることです。ルーチンは、その特定の条件を人為的にチェックするのではなく、切り離せない点で重要である必要があります。そうしないと、ユーザーは関数の呼び出しを無効にすることができます。関数の呼び出しを無効にすると、他の魅力のない結果も生じるという考え方です。
これは、賢いハッカーが分解できないことではありません。明らかに、関数が他の目的のないバイナリに組み込むのに十分なほど些細なものである場合、その関数の外部でも再実装するのに十分なほど簡単です。しかし、それは典型的なエンドユーザーがわざわざ経験するよりも多くの努力です。そしてもちろん、要点は著作権侵害を機械的に阻止することではなく、製品が純粋に名誉システムで機能しないように少し制限を設けることですが、多くの企業バイヤーにとってはそれで十分だと確信しています米国で。
これは一般的なアプローチですか？より良いものはありますか？