MagicLock vs Nuitka & Cython — ネイティブコンパイルにライセンスを加える

Nuitka と Cython は、Python を C とネイティブ機械語へコンパイルする、傑出したオープンソースプロジェクトです。Nuitka はアプリケーション全体をコンパイルでき（スタンドアロンビルドを含む）、Cython は科学技術系 Python スタック全体で C 拡張の性能改善を支える主力です。どちらも、自らが目指したことにおいて非常に優れています — そしてどちらも、保護やライセンスの製品であろうとはしていません。このページが扱うのはその隙間であって、コンパイラそのものではありません。

Nuitka と Cython の優れている点

• 本物の性能向上と C レベルの統合 — とりわけ Cython は数値計算 Python エコシステムの基盤です。
• ネイティブバイナリはカジュアルな盗み読みへの本物の障壁です: 逆コンパイルできるバイトコードは存在せず、リバースエンジニアリングすべき機械語だけがあります。
• 成熟し、無料で、オープンソースで、コミュニティも活発です。

コンパイルだけでは答えられないこと

コンパイル済みのバイナリは、手にした人なら誰でも、いつまでも実行できます。許可されたマシン、有効期限、シート、失効といった概念はありません — それは単に、コンパイラの仕事ではないからです。そしてバイナリの隣にある資産 — モデルの重み、データセット、設定 — は、自前で暗号化の仕組みを組まない限り、平文のまま出荷されます。

保護のためにコンパイルするチームは、やがてまだ答えるべき問いが残っていることに気づきます: これを顧客ごとにどうライセンスするか？ 10 台目のマシンで動くコピーをどう止めるか？ バイナリの隣の .onnx が持ち去られるのをどう防ぐか？ それらこそ、MagicLock が存在する理由となる問いです。

MagicLock のコンパイル版はコンパイルの上に築かれている

magiclock build もネイティブコンパイルを使います — この部分の物語は共通です。違いは、何をコンパイルするかにあります: MagicLock はまず、エントリポイントから到達可能なすべてのモジュールにライセンスゲートのチェックを織り込み、その結果をコンパイルします。出力は、見つけてパッチで外せる単一のチェックが存在しないネイティブ機械語であり、しかもデバイス固定です: 毎回の実行時に、そのマシンのライセンスを完全オフラインで検証します。

下記の日付時点の公開ドキュメントに基づきます。ライセンス要件のない純粋な性能目的の作業なら、オープンソースのコンパイラこそが正しい道具です。

Nuitka や Cython 単体のほうが合う場合

• 目的が速度や C との連携であり、バイナリを手にした人は誰でも実行して構わない。
• 社内配布やオープンソースで、ライセンス強制がそもそも目標でない。

MagicLock のほうが合う場合

• ネイティブコードによる強化に加えて、「誰が、いつまで、どのマシンで実行してよいか」への答えが必要。
• バイナリの隣に、デバイスごとに暗号化されたままであるべきモデルの重みやデータを同梱して出荷している。
• 有効期限、シート、顧客ポータル、そして（任意で）遠隔停止スイッチが欲しい — そのどれも自分で作り込むことなく。

すでにコンパイルが気に入っているなら、MagicLock のコンパイル版は馴染みやすく感じられるはずです — コンパイラが意図的に扱わないままにしているライセンス層を加えるものだからです。ビルド版の仕組みをご覧いただくか、料金ページから 48 時間無料でお試しください。