納品物にOSSを使うときのライセンスの注意点｜義務の違いと契約での扱い

OSS（オープンソースソフトウェア）は、無償で使えてもライセンスの条件を守ることが前提のソフトウェアです。納品物に組み込むときに確かめたいのは、ライセンスの種類と課される義務、発注者がOSSの利用をどこまで認めているか、契約書の保証や権利の条項と食い違わないかの3点です。

実務では、使ったOSSの名称・バージョン・ライセンスを一覧にして、納品前に発注者と共有しておくと、後から問題になりにくくなります。成果物の著作権全体の考え方は成果物の著作権の記事に任せ、ここではOSSに絞って整理します（2026年10月時点）。

OSSは「条件付きで使ってよい」ソフトウェア

Open Source Initiative（OSI）の「The Open Source Definition」は、オープンソースと呼べるライセンスの条件として、自由な再頒布、ソースコードの入手、派生物の作成の許可、特定の人や利用分野を差別しないことなど10項目を挙げています。

大切なのは、OSSの著作権は作った人や団体に残っていて、利用者はライセンスで許された範囲で使っている、という点です。ライセンスの条件を守らない利用は、許諾の範囲外の利用になるおそれがあります。発注者に「成果物の著作権をすべて譲渡する」と約束しても、OSSの部分は自分のものではないので譲渡できません。この点の扱いは、著作権の記事のよくある質問でも触れています。

ライセンスの型と主な義務

OSSのライセンスは数多くありますが、義務の重さで大きく2つの型に分けると整理しやすくなります。

どのライセンスも、ソフトウェアを「現状のまま（AS IS）」提供し、保証をしないと定めています。Apache License 2.0は、貢献者からの特許ライセンスを定め、特許訴訟を起こした場合にそのライセンスが終了する仕組みも持っています。

「頒布」するかどうかで義務が変わる

GPL v3では、他者が複製物を作ったり受け取ったりできるようにする行為を「convey（頒布）」と定義し、コピーの移転を伴わず、ネットワーク越しにやり取りするだけでは頒布に当たらないとしています。一方、AGPL v3は第13条で、改変したプログラムをネットワーク越しに利用者に使わせる場合にも、ソースコードを提供する義務を課しています。

つまり、同じGPLのソフトウェアでも、スマホアプリやパッケージとして利用者に配る場合と、発注者の社内サーバーだけで動かす場合とでは、求められることが変わりえます。納品物がどのような形で使われるのかを、発注者から聞いておくことが判断の前提になります。具体的なケースでどの義務が生じるかは、ライセンスの全文と使い方によって変わるため、判断に迷う場合は専門家にご相談ください。

契約書と食い違いやすい3つの条項

1. 成果物の権利の条項

「納入物の著作権はすべて発注者に移転する」とだけ書かれていると、OSSの部分まで移るように読めてしまいます。「第三者が権利を持つもの（OSSを含む）は除く」と明記してもらうのが基本です。

2. 保証の条項

「成果物が第三者の権利を侵害しないことを保証する」「成果物に不具合がないことを保証する」といった条項は、OSSの無保証と食い違います。自分で管理できないOSSの中身まで保証する形になっていないかを確かめます。

情報処理推進機構（IPA）の「情報システム・モデル取引・契約書（第二版）」は、OSSの利用について、ベンダーが選ぶ場合とユーザーが選ぶ場合の2つの案を用意しています。ベンダーが選ぶ案では、ベンダーがライセンスの条件や機能上の制限などの情報を書面で示して利用を提案し、ユーザーが自分の責任で採否を決めるとしています。そのうえで、ベンダーはOSSに権利侵害や不具合がないことを保証せず、提案時に問題を知りながら、または重大な過失で知らずに告げなかった場合を除き、責任を負わないという形です。知的財産権の侵害の責任を定めた条項でも、OSSに起因する場合はベンダーの責任の対象から外す形がとられています。

3. 契約不適合の条項

請負の契約で、OSSに起因する不具合が見つかった場合の扱いも確かめておきます。OSSのバージョンアップで直せるものか、自分の組み込み方の問題かによって、対応が変わります。責任の範囲と期間の考え方は契約不適合責任の記事で解説しています。

納品前に作っておきたいOSSの一覧

納品物に含まれるOSSを、次の項目で一覧にしておくと、発注者への説明や将来の保守で役立ちます。

パッケージ管理ツールの依存関係の情報を出発点にすると、作業を減らせます。直接使ったライブラリだけでなく、そのライブラリが依存しているもののライセンスも対象になる点に注意します。

あわせて、発注者に次の点を聞いておくと、選ぶ段階で迷いにくくなります。

• 使ってはいけないライセンスの種類があるか（社内規程で禁止しているものなど）
• 採否を誰が決めるか。事前の承認が必要か
• 納品物をどう使うか（社内だけか、顧客や利用者に配るか、ネットワーク越しに提供するか）

自分で公開しているOSSを案件で使うとき

自作のライブラリをOSSとして公開していて、それを案件でも使いたい場合は、二重の注意が要ります。自分が著作者なので使うこと自体はできますが、成果物の著作権を発注者に移す契約だと、その部分まで移ると読まれるおそれがあります。

この場合は、参画前に「従前から保有するもの」として一覧に挙げ、譲渡の対象から外すよう相談します。案件の中で自作ライブラリに加えた改良を、後から公開してよいかどうかも、秘密保持や権利の条項とあわせて確かめておきましょう。公開しているコードを実績として示す方法はポートフォリオやGitHubの記事で解説しています。

よくある質問

発注者から「OSSは使わないでほしい」と言われたら？

方針として禁止しているのか、特定のライセンスだけを避けたいのかを確かめます。フレームワークや言語の標準ライブラリなど、OSSを使わずに開発するのが難しい場面も多いため、使う予定のものと理由を一覧にして、承認を得る形を相談するのが現実的です。

社内システムでしか使わないなら、ライセンスを気にしなくてよいですか？

社内だけで使う場合でも、ライセンスの条件が全くかからないとは限りません。たとえばAGPL v3は、改変版をネットワーク越しに使わせる場合のソースコード提供を定めています。また、今は社内向けでも、後から外部に提供する計画があるかもしれません。ライセンスの確認と一覧の作成は、使い方にかかわらず行っておきましょう。

OSSが原因の不具合で損害賠償を求められることはありますか？

契約の定め方によります。OSSに起因する不具合や権利侵害を責任の対象から外す条項があるか、OSSを選んだのが自分か発注者か、利用の提案時に情報を示したかなどが関わります。上限の考え方は損害賠償の記事を参考にし、個別の判断は弁護士などの専門家にご相談ください。