ITパスポート 2017年 春期 問93
問題文
OSS (Open Source Software)を利用した自社の社内システムの開発に関する行為として、適切でないものはどれか。
選択肢
ア:自社でOSSを導入した際のノウハウを生かし、他社のOSS導入作業のサポートを有償で提供した。
イ:自社で改造したOSSを、元のOSSのライセンス条件に同業他社での利用禁止を追加してOSSとして公開した。(正解)
ウ:自社で収集したOSSをDVDに複写して他社向けに販売した。
エ:利用したOSSでは期待する性能が得られなかったので、OSSを独自に改造して性能を改善した。
🔒 解説は解答すると表示されます
OSSを利用した社内システムの開発に関する行為について【ITパスポート 解説】
正解の理由
まず用語の確認です。OSS(Open Source Software:ソースコードが公開され、誰でも利用・改変・再配布できるソフトウェア)です。OSSには「どこまで自由に扱ってよいか」を定めたライセンスが付きます。
選択肢の中で適切でないのは、イです。理由は単純です。元のOSSのライセンスは、そのソフトウェアに対する権利(利用・改変・再配布の可否や条件)を定めています。これに反して「同業他社での利用禁止」のような追加の制限を付けることは、ライセンスの趣旨と矛盾します。多くのOSSライセンスは、元の著作権表示やライセンス文を保持することを条件に再配布を認めますが、既存のライセンスに追加して利用を禁止するような新しい制約を付けることは認められません。つまり、勝手に「このOSSは同業他社で使ってはいけない」と制限を付けて公開するのはルール違反であり不適切です。
解法ステップ
- 問題文で扱う対象(OSS)を確認する。OSS=Open Source Software(ソースが公開され自由に使える)と理解する。
- 「OSSに対する行為」がライセンスに反するかを考える。ポイントは「配布・改変・再配布時のライセンス遵守」。
- 各選択肢について、「ライセンス上許されるか」「条件付きで許されるか」「明確に禁止されるか」を当てはめる。
- 明確に禁止されるのが イ(元のライセンスに追加の制限を付ける行為)であると判断する。
選択肢別の誤答解説
-
ア: 自社でOSSを導入したノウハウを生かして有償でサポートを提供する。
→ 許容されます。OSS自体は無料(=無償)で利用できることが多いですが、知識や作業を有償で提供すること(サポートビジネス)は問題ありません。ライセンス上も通常は制約されません。 -
イ: 自社で改造したOSSを、元のOSSのライセンス条件に「同業他社での利用禁止」を追加してOSSとして公開した。
→ 不適切(問題の解答)。元のライセンスに反する追加制約を付けることは基本的にできません。特にコピーレフト(後述)系のライセンスでは、派生物にも同じライセンスを適用することが求められるため、利用を禁止するような制限は許されません。 -
ウ: 自社で収集したOSSをDVDに複写して他社向けに販売した。
→ 原則許容されます。多くのOSSライセンスは再配布や販売を許可しています(販売しても良い)。ただし、配布時にライセンス文や著作権表示を添える、ソースコード提供義務がある場合はそれを守る、などの条件があります。条件を守れば問題ありません。 -
エ: 利用したOSSで性能が不十分だったので、独自に改造して性能を改善した。
→ 許容されます。OSSの大きな利点の一つは改変可能な点です。改造自体は自由ですが、改造したものを配布・公開する際は元のライセンスの条項(例:元の著作権表示、同じライセンスで配布など)を遵守する必要があります。
よくある誤解
-
「OSSは何でも自由にできる(自由=無制限)」
→ 誤り。OSSは自由に使えるが、ライセンスに従う必要があります。ライセンスは「何を守るか」を決めています。 -
「OSSは配布・販売できない」
→ 誤り。多くのOSSライセンスは配布や販売を許可します。ただしライセンス条件(ソースの提供やライセンス表示の保持など)を満たす必要があります。 -
「改造したら勝手に自社独自ライセンスにできる」
→ 誤り。MIT/BSDのような寛容(パーミッシブ)ライセンスは比較的自由ですが、GPLのようなコピーレフト(派生物に同じライセンスを要求する)ライセンスでは、派生物に同じ条件を適用する必要があります。いずれにせよ、元のライセンス条項は尊重しなければなりません。
補足コラム — 主要なOSSライセンスの違い(簡単に)
-
GPL(GNU General Public License:GNU 一般公衆利用許諾契約)
→ 強いコピーレフト。改変・再配布する場合、同じGPLで配布し、ソースコードを提供する義務が生じます。 -
AGPL(Affero General Public License)
→ GPLに似ていますが、ネットワーク越しにサービスとして提供した場合でもソース提供義務がある点が特徴です。 -
MITライセンス / BSDライセンス
→ パーミッシブ(寛容)。再配布や商用利用、独自ライセンスの適用が比較的自由です。ただし元の著作権表示や免責条項を残す必要があります。
企業でOSSを使う際の簡単なチェックリスト
- 使用しているOSSのライセンスを特定する。
- ライセンス条項(再配布、商用利用、ソース提供義務など)を確認する。
- サードパーティコードのライセンスが混在する場合は互換性を確認する。
- 社内ポリシーや法務に相談し、コンプライアンスを整備する。
FAQ
Q. OSSを改造して社内だけで使う場合、ライセンスは気にしなくてよいですか?
A. 社内で「配布しない」限定なら、多くのライセンスは内部利用を制限しません。しかし、将来的に配布や外注する可能性があるなら、最初から遵守体制を整えておくのが安全です。
A. 社内で「配布しない」限定なら、多くのライセンスは内部利用を制限しません。しかし、将来的に配布や外注する可能性があるなら、最初から遵守体制を整えておくのが安全です。
Q. OSSを使って作ったプログラムを有料で販売してよいですか?
A. 多くの場合は可能です。ただし、GPL等では配布時にソースコードの提供や同じライセンスでの配布が要求されることがあります。販売自体はライセンスが禁じていることは少ないですが、条件を守る必要があります。
A. 多くの場合は可能です。ただし、GPL等では配布時にソースコードの提供や同じライセンスでの配布が要求されることがあります。販売自体はライセンスが禁じていることは少ないですが、条件を守る必要があります。
Q. ライセンスが不明なOSSを見つけたらどうする?
A. 使わないか、ライセンスを確認できるまで保留にする。可能なら開発元に確認し、法務と相談してください。
A. 使わないか、ライセンスを確認できるまで保留にする。可能なら開発元に確認し、法務と相談してください。
Q. どうやってライセンスを確認する?
A. プロジェクトのリポジトリ(例:GitHub)のLICENSEファイルやREADME、公式サイトを確認します。分からなければ開発元へ問い合わせるか、社内の担当(法務・知財)に相談してください。
A. プロジェクトのリポジトリ(例:GitHub)のLICENSEファイルやREADME、公式サイトを確認します。分からなければ開発元へ問い合わせるか、社内の担当(法務・知財)に相談してください。
関連キーワード: OSS, オープンソース, ライセンス, GPL, MITライセンス, BSD, ソースコード提供, 再配布, 著作権, コンプライアンス

\ せっかくなら /
ITパスポートを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

