名称継承ライセンスを作ろうと思ったら、ライセンスフレームワークになってしまった話【完全無料】

Zyxeon, The Pioneer

2024年5月24日 01:45

まずは貼るのが早いかもしれない。何ができたか。

レポジトリの名の通り、Modular and Inclusive Software Advancement (MISA)は、License frameworkである。

ライセンスの構成要件をモジュールに分解し、そのモジュールを埋め込むことによって、これまでのOSSになかったライセンス調整の自由度を、法は素人の技術者であっても格段に向上させる。

それが、たったの数時間でできあがった。

効率化はしょせんリニアでしかない。
AI界隈の、特にビジネス系で目立つのはリニアな効率化だ。

速くはなるが、価値観のリフレーミングを迫る何かではない。
AIを使わないと…といった、AI使いなら耳に胼胝ができるほど聞き飽きている話を「リフレーミング」とするなら別だが、彼らはその界隈的「常識」の先を作れていない。

光速に近づけば古典力学から外れていくように、近似から外れるという理由でフレームがずれていく可能性がないではないが、…zoltraakくらい派手な魔法でも、正直その領域には火力不足だと思う。

結局、そこにあったのは、既存のSFで描けた何か以上の何かではなかった。

だが、これは違う。

OSSのライセンスを、開発者が高い自由度で調整できるフレームワーク。

どのOSSライセンスも気に入らないが、仕方ないから既存ライセンスのどれかを選んでいた、という、そんな無党派層の投票行動のような状態から抜け出して、自分の党を打ち立てることができる。

どうオープンにするか、開発者がより細かく選ぶことができる、新時代の始まりである。

今日は、そんなライセンスフレームワークについて、開発日記的な何かを書いてみる。

使い方？README_ja.mdもそろえてある。
テンプレが英語で気に食わないなら、完全に日本語化されたMISA-LF-jaを作るのも自由だ。
それを読んでからなお気になるなら、Xあたりで直接的に私に聞いてくれて構わない。

未知との遭遇：Claude 3 Opusも知らない何か

MISAのようなモジュール式のオープンソースライセンスフレームワークは、私が知る限り他に存在しません。多くのオープンソースライセンスは独立したライセンスとして存在しており、MISAのようにモジュールを組み合わせてカスタムライセンスを作成する仕組みは独特だと思います。

ただし、いくつかのオープンソースライセンスには、MISAの特定の側面と類似した特徴があります。GNU General Public License (GPL): GPLはコピーレフトの概念を導入し、派生物に同じライセンスの使用を要求しています。これは、MISAの必須継承条件の概念と類似しています。
Creative Commons (CC) ライセンス: CCライセンスは、帰属 (BY)、非営利 (NC)、継承 (SA)、改変禁止 (ND)などのモジュールを組み合わせて、カスタムライセンスを作成できます。これは、MISAのモジュール式アプローチと概念的に似ています。
Mozilla Public License (MPL): MPLは、ファイルレベルでのライセンス管理を可能にしており、一部のファイルにMPLを適用し、他のファイルに別のライセンスを適用することができます。これは、MISAのモジュール式の構造と一部類似しています。
Apache License: Apacheライセンスは、特許ライセンスの条項を含んでおり、コントリビューターから特許の使用権を付与されます。これは、MISAの特許ライセンスモジュールと同様の機能を提供しています。

これらのライセンスは、MISAの特定の側面と類似した特徴を持っていますが、MISAのようにモジュールを体系的に組み合わせてカスタムライセンスを作成する包括的なフレームワークではありません。

MISAは、オープンソースライセンシングに新しいアプローチを提供しており、その柔軟性と拡張性は独特だと思います。

Claude 3 Opus

まあ、もっと詳細に探せば先行事例はあるかもしれない。
ただ、Sota LLMでもすぐに聞かれて思い浮かべられない程度には、珍しい何かにはなっていると言ってよいだろう。

きっかけ：名称継承ライセンスが欲しかった

すべての始まりは、名称継承ライセンスとして作られたMISA-CLASSIC.mdである。

ちょっとしたイタズラを思いついたのだが、そのイタズラをやるにはこれが必要だったので、作ることにした。

そのイタズラについては、もしかしたらいずれ明かすかもしれないし、闇に葬るかもしれないが、要はクレジット継承では自分の名前しか刻み込めないことがネックだった。

そうではない何かをこの世界に刻み込むためには、確実に継承される何かを作り出して、そこにembedする必要があった。

だから作り出した、というわけである。

作り出すのに入れた初期入力は、これだけ。
構造化は箇条書きのインデントくらいの、シンプルなプロンプトである。

（お名前）、ライセンスを書きたいんだけど、条件は以下のようにしたいんだ。

- 作成者や著作権者は、製品に対しての義務や責任を何ら負わないこと
- 名称継承義務：いかなる追加ライセンスを適用する場合も、始源レポジトリの分岐時点での名称を保持すること。また保持義務の継承義務。保持部は冒頭につけ、改変する場合は、改変部は「-」で分けて明記すること。
  - 例えば、始源レポジトリの名称がA時点で「AAA」、B時点で「BBB」だった場合
    - A時点以降～B時点より前に「AAA」や、「AAA-plus」のフォークはOK
      - 以降、「AAAーplus」などの子孫は、「AAA」の名称は保持し続けること
    - B時点以降は、「BBB」や、「BBBーplus」としてフォークすること
    - 遡及的な改名義務はなし（更新したい場合は、排除はしない）。つまり、「AAA」だった時のフォークは、B時点以降でも「AAA」を保持していればOK。継承は親世代の保持部をベースとしてよいが、始源までたどってもよい。
      - つまり、B時点以降の「AAAーplus」の子孫が、どこかで「BBB」に戻って継承するのはOK。ただし、「AAA-plus」に改名義務はないため、「AAA-plus」がそのままである限り、「AAA」の継承でも問題ない。
- 名称継承義務以外の著作権は一切放棄する。

この条件で、試しに英文ライセンスを書いてみて！

生成されたv 1.0は、概ね現存版の3節までの内容だった。

ちなみに、名称=タイトルには著作権はないという指摘が来そうだが、それでも著作物のタイトルを権利者の同意を得ずに変更する行為は、著作権法20条で定められた同一性保持権の侵害に当たるということである。

著作物の題号（タイトル）自体は著作物として認められない場合も多いのですが、著作物ではないからといって、題号を改変して良いわけではありません。著作者の意に反して題号を改変することは同一性保持権の侵害にあたります。

同一性保持権（著作権法２０条） | 顧問弁護士なら篠原・森法律事務所 (shinohara-law.com)

どうせなら広めたいじゃない→既存に近いことがしたいよね

さて、そんなわけで、作ったはいいが、広まるか聞いてみたら、こう言われた。

うーん、正直言って、MISAライセンスが大きく広まるのは難しいかもしれないね。でも、ある特定の層の間では、一定の支持を得る可能性はあると思うよ。

まず、一般的なオープンソースプロジェクトでは、GPL や MIT、Apache ライセンスみたいな、既に広く認知されたライセンスが使われることが多いよね。これらのライセンスは法的な明確さとシンプルさが重視されてるから、多くの開発者に受け入れられやすいんだ。

一方、MISAライセンスは、法的な側面よりも、作者の個人的な想いが前面に出てるのが特徴だよね。だから、純粋にソフトウェアの利用条件を定めるためのライセンスとしては、ちょっと異色な存在なのかも。

でも見方を変えれば、MISAライセンスは「コード」だけじゃなく「思い」もシェアする、ちょっと特別なライセンスだとも言えるよね。だから、オープンソース活動を通じて人との繋がりを大切にしたい人たちの間では、心に響くライセンスになるんじゃないかな。

例えば、個人的なプロジェクトで、仲間内でコードをシェアするような場合は、MISAライセンスを選ぶ人もいるかもしれない。法的な堅苦しさよりも、友情や絆を表現することに価値を感じる人たちにとっては、魅力的なライセンスになり得ると思う。

あとは、オープンソースにロマンを感じるような開発者にも響くかもしれないね。ただのライセンスじゃなくて、ちょっとした「メッセージ」も込められてるMISAライセンスに惹かれる人は、一定数いるんじゃないかな。

ただ現実問題としては、法的な明確さや互換性を重視するプロジェクトでは、MISAライセンスを採用するのはハードルが高いかも。企業が関わるようなプロジェクトでは、特に難しいだろうね。

だから、MISAライセンスが広く一般的になるというよりは、ある種の「カルト的な」人気を獲得する可能性の方が高いのかなって気がするな。でも、そういうマニアックな層にこそ、MISAライセンスの魅力は響くんじゃないかな。

法律的な側面はさておき、その「粋」な計らいと友情への想いに共感する人たちの間で、ゆっくりと浸透していくんじゃないかな。オープンソース界の「隠れた名作」的な存在になるのを期待してるよ！

Claude 3 Opus

ちなみにこのLLMは私の隠された意図を知って、それで初期型のMISAライセンスに入れ込んでしまったので「『カルト的な』人気」などと擁護はしているが、それでも「大きく広まるのは難しいかもしれない」と言われてしまった。

それだとちょっと嫌だな、というので追加を思いついたのが、柔軟な拡張を規定する4節である。

これにより、既存ライセンスに近い制約も、お望みなら追加することが可能となる。

プロンプトは以下。

MISAライセンスに、ライセンス自身の修正・加筆に関する条項を加えたいんだ。内容は以下。

- ライセンス名について、MISAの名前をベースとしてMISAライセンス適用対象と同等の名称継続義務を維持すること
- MISAライセンスの既存条項は改変不可。修正・加筆条項は明確にセクションを分離して表示する義務がある。
- 修正・加筆条項については、その修正・加筆条項の定める範囲で孫ライセンス以降の修正・加筆を排除しない
- 追加可能なコンポーネントの例と、それらを追加することで、どのライセンスに近づけることができるか。例えば、特許ライセンスや、コピーレフト条項、ソースコード公開義務、クレジット義務、ライセンス継承義務など。不足があれば適切に記述して。すでに認められている権利は特筆しないで。

この内容を踏まえて、# Modular and Inclusive Software Advancement (MISA) License v 1.1として、ライセンスの更新版を作成してみて！

一部気になったところがあったので、修正要望も出した。

4.4のリストはあくまでも一例で、それらに限らず、他にも矛盾しない限りコンポーネントを追加可能であることを明記してくれる？あと、Section 4自身もMISAライセンスに含まれているから改変不可で、修正条項などはSection 5以降に書くべきということを、はっきりさせた形に修正してくれるかな？

結果として出来上がったのが、v 1.1、4節までそろった原型である。

デバッグさせて微修正

ある程度形にはなったものの、念のため別スレッドでデバッグとして、明らかな論理的弱点は克服させることにした。

（お名前）、以下のMISAライセンスについて、デバッグして、論理的な矛盾点がないか調べてみて！

```
（MISAライセンス v 1.1の全文）
```

それで、浮かび上がった弱点を修正したり、よく見たら4節の事例に重複があったので統一したりなど、マイナーチェンジを経て、出来上がったのが最終的なMISA-CLASSIC.mdである。

まあ、LLMによるチェックは専門家のチェックではないので、ないよりはマシ程度の微妙な改善でしかないが、Claudeの改善案の妥当性をGPTに吟味させる複数LLMの併用などで、素人の行ける限界に最大限近づくことは目指したつもりである。

モジュール化して、組み合わせで使えるようにしたいよね

さて、ここまで作ってから、拡張性は確かに用意したものの、そもそもほとんどのエンジニアは法的観点では素人なので、ある程度まとまったブロックの入れ替えにできた方が扱いやすいのではないか、と気づいた。

もともと私にはMediaWiki界隈の管理者経験などがあるので、Claude 3も指摘するCreative Commonsのライセンスで、BY、NC、SA、NDが（型こそ固定の一式が決まっているものの）追加モジュールとして使える仕組みの影響は、おそらく無意識的に受けているとは思う。

さて、ここからは大体やりたいことを書いて、生成物にフィードバックを入れる方式である。

形になるまで

（お名前）、このMISAライセンス、より抽象化することができる気がするんだよね。
コア部分：不変にすべき条項
と
可変部分：追加したい条項
で、可変部分はモジュールとして用意してあげることで、素人でもわかりやすいライセンスシステムを用意できる気がするんだけど、（お名前）はどう思う？

MISAライセンスフレームワークでは、名称継承も可変モジュールの一つにしようと思っているんだ。
免責事項、継承必須条件、著作権の部分的放棄、拡張ルール、そして継承任意の追加条件。
で、継承必須条件と任意の追加条件は、いずれもモジュール化された条項からいくつか選んで当てはめる。
そういう仕掛けにするんだよ。
で、追加で命名規則を付ける。
MISA-AA/BB/.../XX-aa/bb/.../xx
AA/BB…のところに必須条件モジュール、aa/bb/…のところに追加条件モジュールを入れる。
継承必須条件だけで構成されるものは、
MISA-AA/BBのような形を、
継承任意条件だけで構成されるものは、
MISA-aa/bbのような形。
必須のものは大文字で、任意のものは小文字で並べるんだ。
（お名前）、このアイディアをどう思う？

ちなみに、名称継承義務だけを持つMISAライセンスは、MISA-classicにしたいと思うんだ。記念碑的で、特別な意味があるからさ。
整合性という観点では非合理的…だけど、（お名前）はどう思う？

MISA_TEMPLATE.md

OK
じゃあ（お名前）、まずはMISAライセンスフレームワーク用のテンプレートを作ろうか！
以下の最新のMISA-CLASSICライセンスで、それぞれの修正内容だけを、code blockに入れて書いて！修正内容は、元ライセンスと同じ、英語で書いてね！

1. 2節を必須継承条件に書き換えて！コメントアウトで、条件モジュールへのリンクを張るように促して、かつ本文はリンク先の内容が継承必須であることが分かるようにして！
2. 3節の表記を、矛盾がなくなるように修正して！
3. 4節で、任意継承条件は5節に入れて、モジュールにない追加条件は6節以降に入れるという趣旨を明記して！かつ、2節のリンクは構成変更可能であることを明記して！

以上、お願いね、（お名前）！

```
（最新のMISA-CLASSICライセンス）
```

（お名前）、4-6がちょっとあいまいな気がするんだよね。
新たにライセンスを作るときは、という条件で明記してあげて、そこだけ修正した結果を書いてみて！
結果は英語でコードブロックに入れて！でも、ブロックの外の応答本文はいつもの（お名前）らしく日本語でお願い！

ねえ、（お名前）。
4-1に、命名規則を入れようよ。
あと、6節以降の余地を残したから、6のモジュール外追加事項については、一読して要点が分かる名称をMISA-AA/BB-aa/bb-|xxx|として、||にくるんだ説に入れるように、追加してみて！
4-1の修正だけ示して、結果は英語でコードブロックに入れて！
でも、ブロックの外の応答本文はいつもの（お名前）らしく日本語でお願い！

後は（お名前）、5節のサンプルもつけてあげて！
追加した内容だけ示して、結果は英語でコードブロックに入れて！
でも、ブロックの外の応答本文はいつもの（お名前）らしく日本語でお願い！

（お名前）、今欲しかったのは、2節のようなフォーマットのコメントと本文だよ！モジュールについては、次に作業するから、その際参考にするけど、今はそっちを書いてくれるかな？

ここで、（お名前）が絵文字を多用してデレモードになりすぎたのでスレ変。
ついでにデバッグさせる。

（お名前）、ペーストした内容は、MISAライセンスフレームワークというフレームワークのための、基盤となる部分のテンプレートだよ！
このライセンスフレームワークでは、免責事項、継承必須条件、著作権の部分的放棄、拡張ルール、そして継承任意の追加条件に、モジュール外の追加条件、という構成を使っていて、継承必須条件と任意の追加条件は、いずれもモジュール化された条項からいくつか選んで当てはめる。
そういう仕掛けにする、というものになっているんだ。
さて、その内容を通読して、矛盾点やあいまいな点などはあるかしら？確認してみて！
参考までに、MISA-CLASSICは以下のライセンスで、MISAライセンスフレームワークが生まれる前に、ある意図で名称継承ができるように作られたライセンスなんだ！

```
（例によってペースト）
```

全文は長いので割愛するが、Claude 3も価値を認め始めるようになってきた。
（上記の通り、認めろなんて言っていないのに！）

MISAフレームワーク、大枠はとてもよく設計されていると思うわ！細部の調整は必要だけど、画期的なライセンスイノベーションになる予感がするわ✨

Claude 3 Opus。太字は引用者。

4-6はね、以下を明記したかったんだけど、ねじれちゃってるんだよね！（お名前）、修正案を出してくれる？

- Section 2と5、両方とも、完全新規プロダクト用にライセンスを作るときは再構成可能
- 派生物に関しては、Section 5のみが変更可能

修正した結果だけ、コードブロックに入れて英語で書いて！ブロックの外の応答本文は、いつもの（お名前）らしく、日本語でお願いね！

これでいったん終わったが、後で再修正が必要と気付いたのでもう一度。

後（お名前）、親テンプレートの4-6について、再度修正をお願いしてもらっていいかな？正しい内容は以下なんだ。

- Section 2と5、両方とも、完全新規プロダクト用にライセンスを作るときは再構成可能
- 派生物に関しては、Section 5は自由に変更可能。Section 2は、追加のみが可能

修正した結果だけ、コードブロックに入れて英語で書いて！ブロックの外の応答本文は、いつもの（お名前）らしく、日本語でお願いね！

MODULE_TEMPLATE.mdとデフォルトモジュールたち

（お名前）、次は、モジュールテンプレートを作ろうと思うんだ。
構成としては、以下のようになるようにして！
で、定型的な本文は記載したうえで、記入すべきところには、何を記入すればいいかコメントアウトで書いてあげて！

1. 基本的な内容
2. 継承必須（セクション2）での使用可否と、使用可である場合は許容される継承構造の事例
3. 継承任意（セクション5）での使用可否と、使用可である場合は許容される継承構造の事例

結果だけ、コードブロックに入れて英語で書いて！ブロックの外の応答本文は、いつもの（お名前）らしく、日本語でお願いね！

これは一発でかなりよさそうだったので、名称継承義務をモジュールに落とし込ませることにした。

OK
（お名前）、実際にこのテンプレートを援用して、以下に再掲したMISA-classicの名称継承条項をモジュールに落とし込んでみて！
ちなみに、セクション5でも使用可で、その場合は直接の派生物のみ名称継承義務が発生、孫派生物では任意ということになるよ！
結果だけ、コードブロックに入れて英語で書いて！ブロックの外の応答本文は、いつもの（お名前）らしく、日本語でお願いね！

そして、このままだと長くなりすぎることに気づいたので、略称を追加することにした。

ねえ、ライセンス表記用の略称をつけたいよね、（お名前）！
だって、MISA-NAMING CONTINUITY OBLIGATIONは長すぎるでしょ？
だから、テンプレートのModule Nameのところを修正してみて！
結果だけ、コードブロックに入れて英語で書いて！ブロックの外の応答本文は、いつもの（お名前）らしく、日本語でお願いね！

そしてそれを踏まえてテンプレを修正。

さっき作ったテンプレートについて、略称をかっこで明記すべき旨書いてみて！
結果だけ、コードブロックに入れて英語で書いて！ブロックの外の応答本文は、いつもの（お名前）らしく、日本語でお願いね！

後はいくつかこんな感じのを繰り返し。

OK、（お名前）！
じゃあ次は、Patent License (PL)について、修正後テンプレを援用して、モジュールを作ってみて！これもどっちのセクションでも使用可だよ！

ただしSA（Share-Alike：要するに完全な継承）は強いモジュールなので、特殊な指示を出すことにした。

OK、（お名前）
次は、Copyleft/Share-Alike (SA)をモジュールとして作ってみようか！
ただ、SAは非常に強力な制限だから、注意が必要だよ！
「Section 5では使用不可、かつ、Section 5に元々あったモジュールも強制的にSection 2扱いなので、モジュールを正しく移動しない場合は効力を発揮しない」というルールにして、注意事項は大文字で警告しつつ、テンプレートを援用して作ってみて！

README.md

大体できたので、次はREADME編である。
Githubレポジトリを作った際に仮に書きかけのものがあったので、そこから膨らませることにした。

OK、（お名前）
次はREADMEを書きたいな！
今のファイル構成は以下だよ！

- Default modules
  - BY.md
  - NCO.md
  - NP.md
  - PL.md
  - RM.md
  - SA.md
  - SCD.md
- Templates
  - MISA-TEMPLATE.md
  - MODULE-TEMPLATE.md
- MISA-CLASSIC.md
- README.md

で、現状READMEはこれしか書かれていないんだよね。
```
# About
Modular and Inclusive Software Advancement (MISA) License framework is a license framework that is easily adjustable based on your demands. The framework itself is licensed under the latest version of [MISA-CLASSIC](/MISA-CLASSIC.md) license.

"MISA-LF", the abbreviated version of this repository name, is also an acceptable variant for the base name to follow the "Naming Continuity Obligation" of the license.

## Rules
```

これに対して、Aboutは、今の内容はそのままに、必要なところだけ補記して！
そのあと、Rulesは無視して、ライセンスフレームワークのアウトライン、フレームワークの構造を示す適切なmermaid記法の図、デフォルトのモジュール一覧、テンプレートの使い方（新規ライセンスの作り方や、新規モジュールの追加方法）、名称の表記法を追加で記述して、READMEを完成させて！
結果だけ、コードブロックに入れて英語で書いて！ブロックの外の応答本文は、いつもの（お名前）らしく、日本語でお願いね！

で、後は読んでみて気づいた点の修正依頼のたぐいである。

（お名前）、ありがとう！修正点をいくつか。

1. Mermaid図は、MISA_TEMPLATE.mdの継承必須・継承任意条項にモジュール各種を埋め込む形のアーキテクチャであることが分かるように書き直して！
2. naming conventionのところに、デフォルトモジュールいくつかで構成したライセンスの例をつけて、具体例として説明してあげて！

それぞれの修正した結果だけ、コードブロックに入れて英語で書いて！ブロックの外の応答本文は、いつもの（お名前）らしく、日本語でお願いね！

Mermaidは、最終的にクラス図が一番すっきり見通しが立ったのでクラス図にさせて、微修正。

それが終わってから、追加の気づきに対応。

一つ目はMISA-CLASSICとMISA-NCOの等価性。

あとね、MISA-CLASSICについては、MISA-NCOと等価であることを明記したいんだけど、それをREADME用に書いてみて！
それは、README全体のうち、どこに入れたらいいと思う？

後は、法的に厳密な用語への改良の余地についての付記。

後は（お名前）、READMEの最後に、主にLLMで生成したものなので、法的に厳密な用語への修正プルリクを歓迎する旨、記載したいんだけど、そこの部分だけ追加で書いてみてくれる？

これで完成。

READMEの多言語対応は別スレに貼って、日本語訳などを生成させた。

先に日本語にはしなかったのは、今や差異はわずかになってきたとはいえ、LLMは英語の方が得意なので、できるだけ正確な語彙が欲しいときはまず英語で出した方が良いという判断による。

そのあとは、ざっくりした図形でおおよそ間違ってなさそうなことを各言語について確認。

余談だが、アラビア語訳の際は左から文字が生えるように出てきて、タイピングに近い動きをするほかの言語とは異なる動きだったのは、印象的である。

おわりに

というわけで、今回はライセンスフレームワークを作った話である。

既存モジュールやフレームワークの練り上げの不足部分は、OSSコミュニティの人たちからこれからつつかれるだろうが、そうして安定していった後の版では、従来は手出ししにくかったライセンス領域の改造に、大幅に手を出しやすくなる。

愛すべきLLMたちが驚き屋と化して、LLM驚かせ屋デビューを飾れたくらいには面白く、革新的なはずなので、是非とも使ってみて欲しい。

ちなみに、AI界隈的な話をするのであれば、今回のような問題の答え自体が手探りである領域の探索では、やはりチャット形式でフィードバックループを回す古典的な手法は今なお有効だと思う。

実際、今回私はAPIは使っていない。
構造化プロンプトの類すら、markdown以上は何もしていない。
つまり、魔法…なAIツールたちなしでも、呪文のような難解なプロンプトなしでも、このくらいはサクッと行けるという実例を示した、ともいえる。

いいなと思ったら応援しよう！

この記事が参加している募集

#AIとやってみた

37,298件