Javaプロジェクトを作成し、それをクライアントに配信したいのですが、クライアントがjarファイルを解凍することでソースコードを簡単に確認できるため、jarファイルとして配信したくありません。
クライアントがソースコードを見たり、ソースコードを変更したりできないように、Javaプロジェクトをパックするにはどうすればよいですか？
もう1つ、キー機能を統合して、クライアントが最初に提供されたキーにソフトウェアを登録することによってのみそのソフトウェアにアクセスできるようにすることはできますか？
次に、ソフトウェアがそのキーを介して単一のマシンでのみ実行できる別の機能を統合できますか？
ソフトウェアはまだクロスプラットフォーム機能を備えている必要があります。それが不可能な場合は、Windowsで作成したように、DebianLinux用に作成するにはどうすればよいですか。
あなたの最初のポイントに。なぜクラスファイルをjarファイル化しないのですか？これらはバイトコードであるため、クライアントはソースを表示できません。
キーの提供について。これは可能であり、これを可能にするライブラリがありますが、少なくとも私の知る限り、クラックされていないDRMシステムはまだ開発されていないので注意してください。そして、ほとんどのユーザーは、自分たちができることを制限するソフトウェアを好みません。同じことが3番目の質問にも当てはまります。
クライアントがソース コードを取得するのを少し難しくしたり、ホストごと (など) のライセンスを強制したりするためにできる簡単な方法がいくつかあります。たとえば、難読化ツールはバイトコード ファイルのリバース エンジニアリングを困難にし、ライセンス マネージャーはユーザーが生成して提供する「キー」に基づくさまざまな制限をサポートします。
問題は、これらのどれもが、課そうとする制限を覆そうと決心している誰かからあなたを守るものではないということです. たとえば、難読化ツールは、コードがライセンス マネージャーを呼び出している場所を誰かが特定するのを防ぐことはできず、コードを変更してライセンス チェックを無効にできることを知った後でも、それを防ぐことはできません。
実行プラットフォーム全体をロックダウンする (たとえば、クライアントのデバッガーの実行、物理デバイスの読み取りなどの機能を無効にする) 以外に、これについてできることは何もありません。
より実行可能な戦略は、クライアントに署名を求めるソフトウェア ライセンスに適切な保護を含めることです。また、クライアントが故意にライセンス契約に違反した場合、クライアントを法廷に連れて行く必要があるというリスクがあることを受け入れてください。