仕上げは AI との協働でやっています。事実と表現は著者本人が確認しています。
研修で著作権の章を説明した後、必ず受講者から出てくる質問があります。「OSSのライセンスって、著作権とは別物なんですか?」という質問です。テキストでは別の章で扱われていることが多いので、「別物」のように見えますが、実際にはライセンスは著作権を前提に成立している仕組みで、著作権の理解なしには扱えません。
ここを整理しないまま実務に出ると、「MIT ライセンスのコードを使ったから著作権は関係ない」のような誤解が出てきます。今回はこの「著作権とライセンスの関係」を、受講者によく聞かれる順で整理します。
著作権 × GPL の話題に踏み込んだ事例ベースのものは、 過去に among us 界隈の問題から見るソフトウェアの取り扱い で扱いました。 本記事はそれより手前の 「著作権とライセンスの関係を整理する」 ところに絞ります。
観察してきた誤解の典型例
研修で受講者が引っかかる順に並べると、以下になります。
| 誤解の種類 | 具体例 |
|---|---|
| ライセンスは著作権の対義語 | 「OSS だからライセンスはあるが、著作権はない」 |
| ライセンス = 使用許諾 = 著作権の放棄 | 「MIT ライセンスのコードは著作権がないので自由に使える」 |
| Copyleft = 著作権放棄 | 「GPL のコードは作者が著作権を放棄したから自由に使える」 |
| パブリックドメインと OSS の混同 | 「OSS はパブリックドメインだから何をしても良い」 |
これらは全て事実と違います。ライセンスは著作権を前提にした、著作権者からの「使用条件付きの許諾」です。著作権を放棄しているわけではなく、むしろ著作権を持っているから条件を付けられる、という構造になっています。
著作権とライセンスの関係 (図にすると)
文章で説明するとややこしいので、構造で見ます。
[ 著作物 (= ソフトウェアコード) ]
|
| 創作した瞬間に発生
↓
[ 著作権 ] = 作者が独占的に持つ権利
|
| 作者が他者にどう使わせるかを決められる
↓
[ ライセンス ] =「以下の条件を守れば使ってよい」という許諾
|
| 種類によって条件が違う
↓
[ MIT / Apache 2.0 / GPL / BSD / etc. ]
著作権はコードを書いた瞬間に発生します。申請も登録も不要です (これを「無方式主義」と言って、ベルヌ条約に基づく日本の著作権法の特徴です)。ライセンスは、その著作権を持っている作者が、他人にどう使わせるかを宣言したものです。
「MIT ライセンス」と書いてあるコードは、著作権者が「MITの条件を守るなら使って良い」と宣言している状態であって、著作権が放棄されているわけではありません。MIT の条件 (= 著作権表示を残す等) を守らないと、著作権侵害になります。
主要なライセンスを「条件の厳しさ」で並べる
OSSライセンスを「使用条件の厳しさ」で並べると整理しやすいです。
| ライセンス | 制約の強さ | 主な条件 |
|---|---|---|
| パブリックドメイン (CC0等) | なし | 何もしなくて良い |
| MIT / BSD 2-clause | 弱い | 著作権表示を残す |
| Apache 2.0 | 中 | 著作権表示 + 変更箇所の明示 + 特許の利用許諾 |
| LGPL | 強い | LGPL コードを変更した場合は同じライセンスで公開 |
| GPL v2 / v3 | 強い | GPL コードを使った成果物全体を GPL で公開 |
| AGPL | 最も強い | サーバーで動かすだけでもソース公開義務 |
「Copyleft (コピーレフト)」という言葉は、GPL系のライセンスが持つ「派生物も同じライセンスにせよ」という条件を指します。著作権 (Copyright) と対比して名付けられていますが、これも著作権を放棄しているのではなく、著作権を使って「派生物も同じ条件にせよ」と強制している 仕組みです。
実務での落とし穴
研修受講者が後で困りそうな場面を3つ挙げておきます。
1. GPL ライブラリをプロプライエタリ製品に組み込んだ
GPL のコードを自社製品に組み込むと、自社製品全体を GPL で公開する義務が発生する可能性があります。「リンクすればOK」とか「動的リンクならOK」のような議論が長く続いていて、ケースバイケースで判断する必要があります。自社製品で GPL を使う場合は、法務確認が必須です。
2. 著作権表示を消した
MIT や Apache 2.0 でも、著作権表示を消すと条件違反になります。「シンプルなコードだから著作権ないでしょ」と消してしまうと、著作権侵害です。README やソースコード冒頭の Copyright (c) ... の行は残す必要があります。
3. AI 生成コードの扱い
生成 AI が出力したコードの著作権がどこに帰属するかは、まだ法的に確定していない論点です。各社の利用規約で「出力物の権利は利用者に帰属」としているケースが多いですが、学習元のコードが GPL だった場合に派生物扱いになるか、など議論が続いています。業務利用するなら、自社の法務とポリシーを擦り合わせておく必要があります。
ITパスポートの試験で押さえるべき範囲
ITパスポートでは法務章の中で、著作権 + ライセンス + 個人情報保護 + 不正競争防止法、あたりが出題範囲です。受講者が混ざりやすい場所は2か所あります。
著作権の保護期間
| 対象 | 保護期間 |
|---|---|
| 個人の著作物 | 著作者の死後 70年 |
| 法人著作物 | 公表後 70年 |
| 共同著作物 | 最後の著作者の死後 70年 |
「死後 50年」と覚えている人がいたら、2018年の TPP関連法整備で 70年に延長されているので注意です。試験では 70年で出題されます。
著作権が発生しないもの
法律の条文、判決、国の告示、アイデアそのもの、などは著作物として保護されません。アイデアと表現の区別は、試験でも実務でも論点になります。「同じアイデアでも別の表現で書けば別の著作物」という原則を覚えておくと、設問で迷いません。
振り返って
著作権とライセンスの関係を「別物」として覚えてしまうと、OSS の扱いで事故を起こします。「ライセンスは著作権を前提にした使用許諾」という関係を一度押さえておくと、試験対策にもなりますし、実務で OSS を使う時の判断基準にもなると思います。
研修で説明してきた中で、ここを丁寧に押さえた人ほど後の実務で迷わずに済んでいる印象があります。試験のために覚えるのではなく、後で使う知識として位置付けると、法務章の意味が変わってくるのではないかと思います。