📗 OSSライセンスを正しく理解するための本を読んだ感想

読んだ本

著者: 姉崎章博

ライセンスについてわかっていなかったので、ずばりなタイトルの本書を読んでみました。

疑問だったこと

自分がライセンスに関して疑問だったのは以下の点です

あるlibに依存すると自分とlibの作者の間にどういった法律関係が生じるのか
libの作者が日本国外に住んでいる場合にどちらの法律が適用されるのか
- 例えば、どうしてアメリカの法律(ルール)が日本にいる自分に適用されるのか、もしくは、日本の法律上OKということだけ考えれば良いのか
RustのprojectではMIR or Apatch 2.0のような表記をみかけるがライセンスを複数指定することは可能なのか

前提として著作権がまずある

まずlibの作者には著作権が発生している。
そして、そのlibに対して、特定の行為を実行すると作者の著作権を侵害してしまう。
ただし、作者がライセンスとして提示した約束事を履行すると、作者から著作権の行使が認められ、著作権の侵害とならない。という法律的な構成があることがわかりました。

そして、公益社団法人著作権情報センターの外国の著作物も保護されるの?という記事によると

著作物は、国境を越えて利用されるため、世界各国は、19世紀末以降、以下のような国際条約を結んで、著作物や実演・レコード・放送などを相互に保護し合っています。日本はいずれの条約にも加入しており、世界の大半の国と相互の保護関係があります。なお、著作物が利用される際の法律の適用に関しては、例えば、日本の著作物がアメリカで利用される場合にはアメリカの著作権法が、逆にアメリカの著作物が日本で利用される場合には日本の著作権法が適用されるのが原則です。

とあり、日本で開発するにあたっては、libの著者の国籍を意識することなく、日本の著作権を遵守しておけばよいことがわかりました。(厳密には関連する条約に加入しているか確認する必要があるかもしれませんが)

libの作者にはlibに対して著作権を有していることがわかったのでlibをどう利用するかも著作権の枠組みで考える必要があります。
所有権の場合、物に対して使用、収益、処分する権利があるので、人の物を勝手に使うと所有権の侵害になるのと同じで著作権の場合は、複製したり頒布する権利があります。
ただし、どうやら、著作権には"使用"と"利用"という区別があり、"使用"の範囲なら著作物たるlibを複製しても、著作権の侵害とならないというような線引きがあるみたいです。

例えば、cargo buildしたbinaryを社内で利用するだけなら、"利用"で著作権の侵害とならないが、これをcargo publishしたら、複製、頒布にあたり、ライセンスの条件を履行しないと著作権侵害になるというのが現状の自分の理解です。

Backendの場合

SaaSのサービスでaxumのようなhttp serverをapiとしてのみ公開している場合は、著作物の"利用"にあたらず、著作権を侵害しないらしいです。
ということは、開発者倫理はともかく、backendを開発するだけなら、ライセンス事項の履行は不要という結論になってしまうのでしょうか。

この点注意が必要なのは、GNU Affero GPLv3では

if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

というように、プログラムを改変して、ネットワーグを通してユーザと相互作用したら、ソースを公開する手段を講じる必要があることです。

Frontendの場合

プログラムの実行結果や、機能をネットワーク越しに提供するbackendと違い、frontend(js)の場合は、jsをユーザのbrowser上で実行しているので、これは著作権の"利用"にあたるというのが自分の理解です。
ということで、jsで機能を提供している場合は必ずライセンス事項の履行が必要となりそうです。　　

ライセンスごとに必要な事は違いますが、libのライセンスの表示が必要な場合は、libごとにライセンスをなんらかの方法で公開する必要があるということになると思います。
一般的にはSaaSの会社はソースをprivateにしていると思うので、どういった方法でこれを履行しているか気になっています。基本的には利用しているlibごとに対応が必要だと思うので、jsの場合は例えソースをprivate repositoryで管理していても、ライセンス事項の履行を通して依存しているlibは隠せないのかなと考えています。

ライセンス

libの作者はlibに対して著作権を有しており、このlibを特定の方法で利用すると、その著作権を侵害することになることがわかりました。そうするとlibを利用したい人は作者と個別に利用を許諾してもらう契約を結ぶのが原則となると思います。
それでは実用的でないので、作者が事前に利用条件を定め、これを履行した場合は著作権の行使を認めるのがライセンスです。
このように著作権の行使を認める条件を定めたものがライセンスとわかると、ライセンスがMIT or Apatch 2.0のような選択式になっていることも素直に理解できます。この場合は、libを利用したい開発者はMITかApatch 2.0の条件を履行すればよいわけです。　　

ライセンスの両立性

あるプログラムがlib Aとlib Bに依存しており、lib AのライセンスにはAを利用したプログラムの頒布に際して、A以外の制約を課さないという条件が付与していた場合、lib BのライセンスにAのライセンスにはない条件があると、両者を同時に履行できないという事態が生じます。
このようにライセンスによっては同時に依存できない場合があることがわかりました。

ライセンスに違反した場合

ライセンスに定められた事項を履行できない場合は著作権違反となる。
著作権法119条によりますと

著作権、を侵害する行為とみなされる行為を行つた者、は、10年以下の懲役若しくは1000万円以下の罰金に処し、又はこれを併科する。

とあり、刑罰が課されます。

また、124条によりますと

法人、その他の従業者が、その法人又は人の業務に関し、次の各号に掲げる規定の違反行為をしたときは、行為者を罰するほか、その法人に対して当該各号に定める罰金刑を、その人に対して各本条の罰金刑を科する。 1．第119条第１項若しくは第２項第３号若しくは第４号又は第122条の２第１項　３億円以下の罰金刑

とあり、業務でlibの著作権を侵害すると、会社にも罰金が課されるようです。

ライセンス事項を守らないことは著作権違反になるので、著作権表示等のライセンス事項の履行は誰かに言われてからやればよいという姿勢は、万引きをして、見つかったら金を払えばよいと言っているのと同じという説明が本書にありました。
また、GPLの訴訟リスクというような表現は窃盗行為には訴訟リスクがあると言っているのと同じという例えも印象的でした。

Rustでライセンスを守るには

自分で作っていて、cargo publishしているツールでは、特に依存libのライセンス事項を履行していませんでした。
これが著作権に違反しているとわかったので、対応しようと思いました。
いくつか候補があったのですが、cargo-bundle-licensesを利用しました。 cargo bundle-licenses --format toml --output THIRDPARTY.toml のように実行するとprojectの依存しているlibのライセンス本文を一つのfileとして生成してくれます。

CIで差分のチェックもできます

cargo bundle-licenses --format toml --output __CHECK --previous THIRDPARTY.toml --check-previous
try {rm __CHECK}

packageにbinary crateが含まれている場合、Cargo.tomlのincludeに生成されたfileを含めるべきかわかっていません。また、今回はworkspaceで一つのfileを生成しましたが、crateごとに生成すべきなのかもしれません。

まとめ

ライセンスの前提に著作権があるということがわかり、いろいろ疑問だったことが解消できました。
本記事では単にlibに依存しているとしましたが、本書ではlinkの仕方であったり、結合著作物という概念でライセンスの適用範囲の説明があります。また、ライセンスのタイプごとの解説やGPLのよくある誤解、フリーソフトウェアとの関係の説明も参考になりました。