https://github.com/kisaragieffective/machine-readable-license-collection-movement
機械可読なライセンスを提供し、法務の手間を減らしましょう。
https://github.com/kisaragieffective/machine-readable-license-collection-movement
license-checking license-management purpose
Last synced: 4 months ago
JSON representation
機械可読なライセンスを提供し、法務の手間を減らしましょう。
- Host: GitHub
- URL: https://github.com/kisaragieffective/machine-readable-license-collection-movement
- Owner: KisaragiEffective
- License: cc0-1.0
- Created: 2022-08-12T06:56:47.000Z (almost 4 years ago)
- Default Branch: master
- Last Pushed: 2022-08-12T09:05:01.000Z (almost 4 years ago)
- Last Synced: 2025-03-01T03:46:25.741Z (over 1 year ago)
- Topics: license-checking, license-management, purpose
- Homepage:
- Size: 8.79 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# machine-readable-license-collection-movement
機械可読なライセンスを提供し、ライセンス解釈にかかる手間を減らし、その活用範囲のラインをはっきりさせましょう。
* 筆者: [`@KisaragiEffective`](https://github.com/KisaragiEffective)
## 免責
* 適当に書いたものなのでいろいろおかしいかもしれません。ご容赦ください。
* このファイルは、有料無料問わず、著作者による一次配布を目的として公開されたコンポーネントのライセンスとそのコンポーネントの活用についての筆者の見解を述べています。
* いわゆる「ワンオフアバター」などはここでは言及しないため、それらについての見解をお求めの方はお引取りください。
* 以下に示された筆者の見解を真実であると信頼した直接的または間接的な結果として、何らかの物理的、社会的、その他あらゆる形態の損害を招いたとしても、筆者は責任を負いません。
* すっ飛ばしたい方は[§機械可読ライセンスコレクション運動](#機械可読ライセンスコレクション運動)へ
----
## ライセンス
世の中には様々なライセンスがあります。筆者がよく見かけるのは、次の3通りのライセンスです。
* All Rights Reserved[^1] (すべての著作権が留保されたコンポーネント。プロプライエタリもここに含まれる)
* FLOSSライセンス (MIT、Apache-2.0、GPLv3、etc)
* Creative Commons (CC-BY、CC-BY-SA、etc)
* そのコンポーネント独自のライセンス
[^1]: ライセンスというものは本来利用許諾を指すものなので、ここに含めるのはおかしいかもしれませんが、便宜上ここに含めます。
## ライセンスの非互換性
筆者はすべてを自分で作っているわけではなく、当然外部のベンダーが開発したコンポーネント[^2]に依存することがあります。そして、それを配布するとなったとき、依存先のコンポーネントのライセンスを考慮してライセンスを設定することは簡単でしょうか？
**いいえ。**
少なくとも私はそうは思いません。
例えば、世の中にはリンク先のコンポーネントに対して同じライセンスで利用可能にすることを要求するライセンスがあり、その代表格として[GPLv3](https://www.gnu.org/licenses/quick-guide-gplv3.ja.html)があります。あなたは依存先のコンポーネントのいずれかがGPLv3ではないという確証はありますか？ないのであれば、このタブを閉じて今すぐ見直しましょう。幸いなことに、いくつかのプラットフォームはライセンスをチェックするツールが提供されています。Rustというプログラミング言語では、cargoというツールチェインに機能を追加する形で提供されている[`cargo-license`](https://github.com/onur/cargo-license)があります。
他にも厄介な点があります。ベンダーが、彼らが開発したコンポーネントに独自の利用規約を設定していた場合、それらをベンダーが意図したところに沿って「正しく」解釈することは困難であることがあります。代表例として、「反社会的勢力による利用の禁止条項」があります。その「反社会的勢力」の定義がライセンスの本文中によって全く与えられておらず、いわゆる日本の[^3]社会的通念[^4]的な定義を採用しているのか書かれていない場合、ベンダーが想定する「反社会的勢力」と日本の社会的通念によって暗黙のうちに定義される「反社会的勢力」とが異なることが考えられます[^5]、ライセンス中の疑問点は、懸念へと繋がります。筆者は、当該条項を設けるのであれば、その定義をあやふやなままにするべきではなく、[VN3ライセンス](https://www.vn3.org/) v1.10の第7条第1項ぐらい厳密にやってほしいと思います。特に、対応コストがかかるとして、そのライセンスに関する問い合わせを一切合切受け付けない場合は、なおさら重要です。
利便性のために、VN3ライセンスの当該条項を下記に引用します。
> 第７条（反社会的勢力の排除）
> 1. ユーザーは（法人の場合はその役員または従業員に関して）、反社会的勢力（暴力団、暴力団員、暴力団員でなくなった時から5年を経過しない者、暴力団準構成員、暴力団関係企業、総会屋等、社会運動等標ぼうゴロまたは特殊知能暴力集団等、その他これらに準ずる者をいいます、以下同じ）に該当しないこと、また暴力的行為、詐術・脅迫行為、業務妨害行為等違法行為を行わないことを、将来にわたっても表明し、保証するものとします。
他の制限条項としては、コンポーネント同士を組み合わせたり、コンポーネントをパート[^6]に分解することを制限するライセンス、
そして、そのような制限条項はOSIが提唱する[FLOSSライセンスの定義](https://opensource.org/docs/osd)の「8. License Must Not Be Specific to a Product」に反します。筆者は、Booth上において公開されているコンポーネント
また、コンポーネントのライセンスで定められた利用許諾条件が衝突する[^8]ことによって、自分でそれらを組み合わせた「より大きな」コンポーネントに配布や活用の制限がかかったり、事実上配布できなくなったりします。
まとめ: 上記のような様々なコンポーネントにつけられた様々なライセンスが乱立することによって、その検証・活用コストは **飛躍的に** 増加します[^7]。
[^2]: npmやcrates.ioやmavenレポジトリを通じて参照できる外部ライブラリ、Creative Commonsでライセンスされたメディアファイル、その他諸々。
[^3]: 海外の事情は存じ上げません。
[^4]: ここでの社会的通念とは、[暴力団対策法](https://elaws.e-gov.go.jp/document?lawid=403AC0000000077)などをベースに構成されているものと考えられます。最も、反社会的勢力はコレだけに限らないと考えることもできますが、社会的通念によって解釈されるところでは「反社会的勢力」＝「暴力団」という方程式が成り立っていると筆者は考えます。
[^5]: 現実的なシチュエーションでは、その可能性は限りなく小さいですが、異ならないとは限りません。
[^6]: 例: `*.unitypackage`に含まれるモデル、実行可能ファイルに埋め込まれたマルチメディア
[^7]: 独自ライセンスを使用しているコンポーネントを`n`個、独自ライセンスの解釈及び遵守に務めるためにかかるコストを`C`とすると、`n × C`かかります。
[^8]: 例: コンポーネントを使用した場合はその組み合わせた「より大きな」コンポーネント全体を制限なくアクセスできるようにしなければならない vs コンポーネントの再配布禁止
### 解決に向けて
「ではどうすればよいのか」とおっしゃる読者の方もおられると思います。筆者は、これを解決するために以下の排他的ではない方法があると考えています。
1. コンポーネントを開発することをやめる
2. 新しくライセンスを書くことを完全に止める
3. 共通のライセンスを用いる
4. 機械に解釈させる
まず、1は間違いなく生産的ではありません。それは将来、同じような状況に陥ったときに同じようなコンポーネントの再開発を招くだけだと考えます。
2は現実的ではありません。筆者は好ましく思いませんが、ベンダーによってはそのコンポーネントに独自のライセンスを設定したいと思うでしょう。特に、バーチャル空間上のアセットを有償販売する場合、再配布やパーツへの分解を禁止したいと考えるかもしれません。筆者は、「せーの」ですべての人がそれを止めるとは微塵も考えていません。
3は現実的な選択肢のうちに入ってくるでしょう。FLOSSライセンス、Creative Commonsといった、グローバルに活用されているライセンスの他、先程言及した[VN3ライセンス](https://www.vn3.org/terms)や[UVライセンス](https://uv-license.com/ja/uvl)を活用するのも良いでしょう。
4が今回、筆者が提唱するアプローチです。
## 機械可読ライセンスコレクション運動
機械可読ライセンスコレクション運動 (以下、MRLCM) は機械可読な形式でコンポーネントのライセンスを格納することを目標としています。
### 目標 (goals)
* 機械可読なライセンスの統一されたスキーマを曖昧な部分がないよう定義し、広く使われているシリアライズ形式で相互にやり取りできるようにする
* 人がライセンスの解釈をする手間を減らす
* 人がコンポーネントの組み合わせ可否を判断するコストを減らす
### Non-goals
* すべてのコンポーネントを格納するコレクションをメンテナンスする
* 独自のシリアライズ形式の定義
### 形式
* 形式は以下の二通りを想定する(なお、今後の比較によって変わる可能性があることに注意)：
* 人が書きやすいJSON形式
* 配布するときにサイズ面で大幅なメリットがあるBSON形式
### スキーマ
このスキーマのバージョンは`0.1.0`です。
#### スキーマ型の定義
スキーマを定義するにあたって、以下の型を定義します。
1. `SemanticVersion`: [セマンティックバージョニング 2.0.0](https://semver.org/lang/ja/)で定義されるバージョン形式
2. `URI`: RFC3986 §3によって定義されるURI
3. `string`: Unicode書記素クラスタの0回以上の繰り返しのみによって構成される任意長の文字の並び
#### スキーマの用語定義
スキーマを定義するにあたって、以下の用語を定義します。
1. MUST: RFC 2119によって解釈される単語
2. MUST NOT: RFC 2119によって解釈される単語
3. SHOULD: RFC 2119によって解釈される単語
4. SHOULD NOT: RFC 2119によって解釈される単語
5. MAY: RFC 2119によって解釈される単語
#### 例
```json
```
## 参考文献
* https://www.vn3.org/terms