アドベントカレンダーの1人フルマラソンに挑戦中です😃
翌日はこちら：ソフトウェアの不正利用は社内窓口に通報できる？Docker Desktop有料化【公益通報者保護法】
前日はこちら：ミームLGTM画像や推しキャラアイコンの社内利用は？フェアユースって？【著作権法】
OSSライセンスとコピーレフトと著作権
「コピーレフト」は偉大な発明です。
名前も秀逸。著作権を表す Copyright（右） ではなく Copyleft（左）とは、洒落が利いていますね。
コピーレフトの発明がなければ、現代のOSSも生まれませんでした。しかし、多くのエンジニアがコピーレフトに関して最初に耳にする言葉は、「コピーレフトやGPLは危険なので利用は避けよ」ではないでしょうか？ OSSの生みの親とも言える（？）コピーレフトは、なぜ逆に落とし穴扱いされてしまうのでしょうか。
コピーレフト発明の経緯
著作物と著作権の関係状態を（やや乱暴に）２つに分けると以下のようになります。
- 著作権により保護されている著作物（≒プロプライエタリ）
- 著作権により保護されていない著作物（≒パブリックドメイン）
２つの状態の間には極めて重要なルールが存在します。
2（パブリックドメイン） を複製して拡張したものは、2（パブリックドメイン） ではなく 1（プロプライエタリ）になる
この前提で起こる 問題 を理解するため、１つの事例を挙げます。
あるエンジニアが自作ソフトウェアを作成、公開していました。
↓
ある会社がそのソフトウェアを気に入り、自社でさらに拡張（改善）するため、エンジニアに対しソースコードの提供を申込みました。
↓
エンジニアは自作ソフトウェアのうち一部のソースコードを パブリックドメイン とし、会社に提供しました。
↓
その後、会社はソースコードを拡張（改善）し、より良いソフトウェアを作成しました。
↓
エンジニアは会社がソースコードを拡張した部分（プロプライエタリ）について、開示を申し込みました。
↓
会社は拡張した部分のソースコードがプロプライエタリであることを理由に、開示を拒否しました。
この事例はエンジニアであり「コピーレフト」の発明者の リチャード・ストールマン氏が実際に体験したとされていることです。一連の流れは著作権法に照らすと何ら問題なく、ごく自然なことです。
しかしながら、元の著作者であるストールマン氏は会社によって拡張された部分のソースコードについて、フィードバックを得ることも、あるいは好奇心を満たすこともできません。拡張された部分には、元のソースコードに潜んでいた重大なバグの修正が含まれていたかもしれません。（ソフトウェアを入手した）他のエンジニアも同様にフィードバックを得られません。同じバグに悩み、同じ修正を余儀なくされるかもしれず、「車輪の再発明」的な非効率を強いられます。まさにプロプライエタリが抱えている問題を包含してしまいます。
つまり、ソースコードをパブリックドメイン化して提供するだけでは、ソースコード利用の輪の広がりに自ずと制限がつきます。
コピーレフトの概念
上記の 問題 を解消する手段（hack）として、コピーレフトというライセンス形態が発明されました。概ね次のことを規定しています。
- コピーレフトなソースコードを含むソフトウェアを頒布する場合、著作権者はソフトウェアの使用者に対し、ソースコードを公開/複製/改造可能にする義務を負います
- コピーレフトなソースコードを含むソフトウェアを改造して(再)頒布する場合、改造ソフトウェアの著作権者に対しても、やはりコピーレフトの義務が強制されます
これらの規定によって、元の著作者や第三者も含めて拡張されたソースコードからのフィードバックを得られることが担保されます。
コピーレフトを継承した個別のライセンス（GPL等）とそのバージョンによって細かい違いはありますが、本記事では触れません。
コピーレフトは契約
著作権法には、著作(権)者の権利を守るための規定があります。一方で「コピーレフト」に関しては規定がありません。そこで、一般に「コピーレフト」というライセンス形態は、著作権者と利用者の間の「契約」またはその雛形として解釈されます。
ただし、「コピーレフト」は著作権法と競合する場合があります。たとえば、コピーレフトはソースコードを公開し、複製可能にすること義務付けています。一方で、著作権法による「原則、複製禁止」は「強行規定」です。強行規定とは、契約や紳士協定等で上書きのできないことが予め決まっている法規定のことです。コピーレフトはあくまで契約なので、法律の「原則複製禁止」を禁止できないという矛盾を抱えています。よって、コピーレフト（の契約）は無効であると解釈することもできてしまいます。
この矛盾は、コピーレフトライセンス違反を 取り締まる 団体 「Software Freedom Conservancy（SFC）」が、違反者に対して訴訟を起こす場合、団体にとって不利に働く可能性があります。とはいえ、２０２２年現在コピーレフトはソースコード以外の著作物についても適用され始めていて、一般的な「商慣習」の一つと認知されているため、そのことは紛争において考慮されるでしょう。
個人的には、矛盾や曖昧さが無くなるように特例法等の法整備が必要と考えています。
コピーレフトが創り出した「落とし穴」とされているもの
ある会社でプロプライエタリなソフトウェアを作成して販売（配布）する場合に、そのソフトウェアにコピーレフトなソースコードを利用したライブラリ等を含めていたら、ソフトウェア全体のソースコードを公開しなければなりません。これは、会社の商品の付加価値の秘密（営業秘密）を公開するのと同じことで、営利事業の目的と相容れません。ソースコードだけではビルドしてソフトウェアとして実使用することは難しいかもしれませんが、コピーレフトでは実使用するための具体的な手順等の公開も求められます。
すでに書いたコピーレフトの発明の経緯や概念を理解していれば、コピーレフトなソースコードを商用ソフトウェアに利用すること自体が、（原則として）間違いであることにすぐ気づくでしょう。ストールマン氏がコピーレフトを発明した目的に「商用ソフトウェアにコピーレフトを使わせないこと」は含まれないはずですが（禁止されていないため）、おそらくメインの目的だった「拡張されたソースコードからフィードバックを得る」を担保するためには、やむを得ない副作用となります。
さて、会社のソフトウェア開発プロジェクトチームに、コピーレフトについて理解のないエンジニアが参画した場合（私も最初はそうでした）、先輩としてはコピーレフトライセンス違反のリスクを負わ（せ）ないように 「落とし穴」「罠」「功罪」「GPLはヤバい」などのわかり易い言葉で忠告しておくのが一番楽ですね。個人的には、コピーレフトが「落とし穴」扱いされる主な理由はこれだと考えています😑
社内でのコピーレフト利用のすすめ
まず、コピーレフトに関する「利用」と「使用」の言葉の定義は以下のとおりです。
- 利用： ソースコードを複製・改変・拡張・リンクすること
- 使用： ソースコードを使ったソフトウェアをユーザとして扱うこと
ここでは会社内において、以下の条件下でコピーレフトなソフトウェアの「利用」をお勧めします。
- サーバサイド（WEBバックエンドサーバやバッチサーバ等）でGPL2.0ライセンスを含むソフトウェアを動作させる
- 社内のローカルPCでコピーレフトなソフトウェアを動作させる。
いずれもコピーレフトの義務を負わないようです。ただし詳細は一次情報（ライセンス条項）や専門家、またはSFC等の団体にご確認されることをお勧めします。
社内で責任者にコピーレフト導入を説得する際は、この記事を見せていただければと思います。なお、この記事はコピーレフトではないので、記事本文をConfluence等へ「複製」することはお控えください（引用の条件を満たせばOK）。
まとめ
コピーレフトの利用率は過去１０年で劇的に下がってしまったようで残念ですが、名誉は挽回されると嬉しいです。
あなたはコピーレフトについてどんな立場（利用者, 使用者, 著作権者等）で、どう思いますか？
是非コメントください。