💡 【検証環境・個人研究（PoC）に関する注記】
本記事は、筆者個人の自宅検証環境（ホームラボ／仮想環境）において、公開情報およびOSS（オープンソースソフトウェア）を用いて独自に構築・検証した個人研究（PoC）の記録です。特定の企業・団体の実環境や業務上の非公開情報とは一切関係ありません。
はじめに：何気ない pip install が自作コードを全滅させる？
個人開発したツールが好評で、「これを有料SaaSやオンプレミス製品として販売してみよう」と考えたことはないでしょうか？
筆者もLAN内の脆弱性・資産管理ツールを開発し、いざ商用化（有償販売）のライセンス監査を行ったとき、背筋が凍るような事実に直面しました。
Pythonでネットワークスキャンを自動化する際、誰もが一度は使う超定番ライブラリ python-nmap。
しかし、このライブラリのライセンスは GPL-3.0（General Public License） です。
もしこのコードをそのままパッケージ化して顧客に配布・販売した場合、GPLの強力な「感染（伝播）条項」により、自分が汗水流して書いた独自のアルゴリズムやWebバックエンド全体のソースコードを、購入者全員に完全無償で開示・公開する法的義務が発生してしまいます。
「クローズドソースで販売したい」「自分のコア知財を守りたい」と考えている開発者にとって、これは製品寿命の終わりを意味します。
本記事では、このGPL汚染危機をどのように検出し、自作コードの権利を守りながら合法的プロプライエタリ製品として成立させたかの実務手順を公開します。
1. 監査で判明した全OSSライセンスの危険度判定
まず、プロジェクト内の全コンポーネント（Pythonライブラリ、OSバイナリ、Dockerイメージ）を棚卸しし、ライセンスの商用リスクを以下のように仕分けしました。
| コンポーネント | ライセンス | リスク判定 | 理由と対策 |
|---|---|---|---|
python-nmap |
GPL-3.0 | 🔴 致命的 | 自作コードへの直接感染源。即座に完全撤廃。 |
nmap (バイナリ) |
NPSL / GPL | 🟡 注意 | バイナリの無断同梱販売はライセンス抵触の恐れ。コンテナから外し、顧客環境で動的取得させる。 |
snipe-it |
AGPL-3.0 | 🟡 要監視 | ネットワーク経由でも感染する強力なAGPL。未改造公式イメージのまま別コンテナで動かし、REST APIでのみ通信（疎結合） することで自作コードへの感染を遮断。 |
paramiko |
LGPL-2.1 | 🟢 安全 | 動的リンク（import）で無改造利用するため、自作コードの開示義務は発生しない。 |
fastapi, uvicorn |
MIT / BSD | 🟢 安全 | 非常に寛容。著作権表示の保持のみで商用クローズド販売OK。 |
2. 脱 python-nmap：標準ライブラリだけでNmapを安全に動かす
python-nmap を削除しても、Nmapによる詳細スキャンは諦める必要はありません。
Python標準の subprocess と xml.etree.ElementTree を使えば、ライブラリ依存ゼロで、しかも公式ライブラリより高速にXML結果をパースできます。
改善後の安全なコード (Python標準ライブラリのみ・商用完全安全)
アーキテクチャ詳細、処理フロー図、中核ロジックのコード抜粋（PoC）、およびパラメータ解説・トラブルシューティング手順は、GitHubリポジトリ（詳細技術リファレンス）にて管理・随時アップデートしています。
設計の全体像や要点スニペットの確認は以下のリンクをご参照ください。
👉 GitHubで詳細技術リファレンス・処理フローを見る (QIITA_ARTICLE_DETAIL_7.md)
このコードであれば、**一切の外部ライブラリを介さずOSの標準コマンドとしてNmapを呼び出しているだけ（プロセス間通信）**となるため、著作権法上「派生著作物」とは見なされず、自作コードの知的財産を100%保護できます。
3. Nmapバイナリ自体の同梱回避（IaC動的プロビジョニング）
Nmapのバイナリ本体も、最新版では独自の「NPSLライセンス」が適用されており、商用製品のDockerイメージ内に勝手に固めて再配布（同梱販売）するとライセンス料の請求リスクがあります。
そこで、Dockerイメージ内へのNmap静的組み込みを廃止し、顧客環境での初回起動スクリプト（IaC）でOS公式リポジトリから動的に apt install させる方式に改修しました。
アーキテクチャ詳細、処理フロー図、中核ロジックのコード抜粋（PoC）、およびパラメータ解説・トラブルシューティング手順は、GitHubリポジトリ（詳細技術リファレンス）にて管理・随時アップデートしています。
設計の全体像や要点スニペットの確認は以下のリンクをご参照ください。
👉 GitHubで詳細技術リファレンス・処理フローを見る (QIITA_ARTICLE_DETAIL_7.md)
製品提供元は「インストールスクリプト」を配っているだけであり、バイナリそのものを再配布していないため、再配布条項の法的制約を完全に回避できます。
4. AGPL（Snipe-IT）を安全に利用するための「コンテナ境界」
オープンソースのIT資産管理システムである Snipe-IT は AGPL-3.0 です。
AGPLは「ネットワーク越しに利用させた場合でもソースコードの公開義務が発生する」という非常に強力な条項を持っています。
しかし、以下の原則を徹底することで安全に共存させています。
- Snipe-ITのソースコードを1行も改変しない（Docker Hubの公式イメージをそのまま利用）
- データベースを直接共有せず、公開されたHTTP REST API経由でのみ通信する
- 独立した別コンテナとして稼働させ、ネットワーク的に完全疎結合を保つ
これにより、自作のFastAPIバックエンドは「独立したAPIクライアント」として法的に成立し、AGPLの伝播を受けずに済みます。
まとめ：リリース前のOSSライセンス監査はエンジニアの義務
「動いたからヨシ！」でリリースしてしまうと、後からライセンス違反で製品の公開停止や損害賠償、あるいは苦労して書いたソースコードの公開を迫られる悲劇が起きます。
requirements.txtの中身をライセンスチェッカー（pip-licenses等）で総点検する- GPLライブラリは、標準モジュール（
subprocessやurllib等）で代替できないか徹底的に検討する - AGPL/GPLの強力なOSSは、自作コードと直接結合せず「API経由の別コンテナ」に隔離する
この防衛策を押さえておくことで、安心して自分のプロダクトを世の中に送り出すことができます。個人開発者やスタートアップの皆さんの参考になれば幸いです！
📚 さらに詳しい本番実装・トラブルシューティングについて
本記事は現場運用のエッセンスを凝縮したサマリー版です。
本番導入に向けた 「深層メカニズム解説」「完全パラメータ表」「現場アンチパターン」「トラブルシューティング対応表」「運用チェックリスト」 は、以下のGitHub完全技術リファレンスにて全網羅して公開しています。
⭐ 全14層・200パターンの自立型インフラ＆オンプレAIリファレンスを順次公開予定です。役に立った・面白かったと感じていただけましたら、ぜひリポジトリへの Star (★) をお願いいたします！
👉 GitHub リポジトリ: ojisan-arsenal