著作権をプログラムに限定して考えてみる。
結論も何もなく、今まで学んだ事の一部をつらつらと書いてみる。
作者が著作物を創造した瞬間、作者に著作権が発生する。
この時点では、著作物の使用は誰でも自由。利用することができるのは、著作権を持つ作者のみ。つまり、著作権とは「作品を利用する権利」。
そんな訳で、本を読んだり音楽を聴いたりする行為（使用）には権利は不要であるが、プログラムの実行（使用）に関しては、実行するにあたりインストール（HDDへの複製）やロード（メモリへの複製）*1、つまり「利用」が必要になる為、実行する場合は複製権（の一部）が必要になる？
その「著作権」は大きく、著作人格権と著作財産権に分けられる。
- 著作人格権：日本法上では、放棄・譲渡できない。
- 公表権
- 氏名表示権
- 同一性保持件
- 著作財産権：放棄・譲渡可能。
これらの権利は、創造の時点で作者がごっそり握っている。というわけで、著作物の使用は誰でも可能で、著作物の利用が作者に限られている。
そこで第三者に対してライセンスを発行する。
作者は、契約（民法）によって、第三者に著作財産権を譲渡したり、使用の制限する事ができる*2。ただ、前述の通り著作人格権は放棄・譲渡できないので「不行使宣言」をすることにより、第三者が安心して利用できるようになる。
- 無条件で全ての著作財産権（一部または全部）の行使を認める。
- 全ての著作財産権を好きに使っていいよ → NYSL
- 条件付きで、著作財産権（一部または全部）の行使を認める。
- 使用の自由を制限する事と引き替えに、一部の著作財産権の行使を認める。
- 逆コンパイル（使用）しちゃだめ、その他色々（使用）しちゃだめ、その代り、一台だけに限りインストール（利用）して使っていいよ → 商用ライセンス
つまり、ライセンス契約は、第三者が使用・利用できる範囲を変える働きがある。という訳で、ライセンスは下記2項目の集合体と考える事ができる。
- 第三者に認める「利用」行為の内容（どの権利をどの範囲で認めるか）
- 上記行為を認める代りに、従わなくてはならない条件(1)
- 上記行為を認める代りに、従わなくてはならない条件(2) …
*1:プログラム等の実行時におけるRAMへの読み込みは著作権法上の複製には当たらないというのが日本における一般的な解釈。しかし、複製に当たるとするのがむしろ世界的には主流。ただ、適法な所有者によるそのような行為はプログラムの使用に必要な場合は許諾を要しないとする。参考：http://www.wincons.or.jp/view/vol23/page8.html
*2:「使用」の制限、というのがポイント。本来自由に使用できるはずの部分を制限する事と引き替えに、「利用」を認めることができたりする。「利用」に関しては制限するのではなく、認めなければ制限されっぱなしになる。はず。
具体的に色々なライセンスを考えてみる。
制限が緩いと思われる順に。あと、下記内容は日本語訳を読み取って、同時通訳のようにまとめただけです。うまく読み取れていない部分も多いと思う。内容の正確さはかなり低いと思ってください。
参考：http://opentechpress.jp/docs/licenses/
パブリックドメインを考えてみる。
パブリックドメインとは、作者が著作権を完全に「公衆（≒全ての人）」に譲渡し、放棄した状態。正確には「ライセンス」ではない。誰もが「自分の物と同じように使用できる状態」。
日本では、著作人格権を放棄できないので、日本法の上では「パブリックドメイン」という状態はあり得ない、というのが一般的な解釈。ただ、人格権を行使しないと宣言することによって、擬似的なパブリックドメイン状態を作り出すことはできると思う。
MITライセンスを見てみる。
- 使用
- 複製
- 再配布（販売可能）
- 改変（結合）
- 改変物の頒布（有償・無償問わず）
- 著作権表示および本許諾表示を同梱（オリジナル部分に関してのライセンスとして）
修正BSDライセンスを見てみる。
- 使用（use）
- 再配布（redistribution）
- 原著作者の著作権を表示する
- 本条件書を含める
- 保証の否認声明を含める
- 派生物の宣伝目的で原著作者名を使用してはならない。
著作権は法律によって保証されるもの。よくあるライセンスは米国法に準拠しており、それを日本法で解釈しようとする時点で、微妙な判断を迫られる事が多い。
ここで「使用」を許可されているのだが、使用は日本法上では元から自由であるはず。これは、プログラムの使用にあたって必要となるインストール（＝複製＝利用）を許可しているのか、それとも米国法では使用も制限されているのか…。わからない。
っつーか、そもそも「再配布および使用」が認められているけど、二次著作物の創造は認められているのか？（一般的には、認められているとして扱われているので、認められているのであろう。） それが「使用」なのか？ つまり「利用」の事なのか？ 誤訳？ というか日本人でさえ使用と利用の区別できてないもんねぇー。ひー。
という「単語の解釈」の問題に入り込んできます。どうなんだ、これ。
Apache Licence v2を見てみる。
Common Public License v1を見てみる。
GPLv2を見てみる。
他のライセンスも同様に見てみたいのだが、いかんせん長いｗ
*1:明示的に許可されていないけど、何らかの理由でOKなはず。
プログラム化が難しい
あーー、ちょっと無理っぽ感が漂ってきた。非常に悔しい。法律ってのは、なんでこう難しいんだ…。
意外に☆が集まったのは嬉しかったが、出来ないんじゃしょーがねーじゃん、俺。コミットしたら誰かヘルプ入れてくれますかｗ
追記
なんか、このプログラム化を考えているウチに、自分だけライセンスに明るくなってしまった。周囲の人にも同様に明るくなってもらえるように、プログラム化して還元できればな、と思っていたのに自己完結気味。俺、ずるーい(笑)
へっへーんだ。
煮るなり焼くなり好きにして下さい。つか、調理してください…。
というわけで、もー煮詰まったからCodeReposに投げちゃったよーだ（半分ヤケ）。
設計からして甘々なハズなので、直してください…。煮詰まったので、閃くか、動きがあるまで放置っぽいですよ。
http://svn.coderepos.org/share/lang/java/misc/license-simulator
ライセンスシミュレータ
というわけで、ちょっと考えてみた訳だが。現実をオブジェクト指向で落とし込もうとするとハマると聞いたことがあるが、やっぱしなかなか大変なモンですね。
とりあえず、Person(権利主体)、Product(著作物)、License(許諾内容)があればいけるのかな。あと、enum Actionで「活動」を示して…。
// 登場人物 Person author = new Person(); Person user = new Person(); // GPL著作物創造 Product program = author.create(Program.class); program.setLicense(new GPLv2()); // そのままの形で再配布可能 user.action(Action.DISTRIBUTE, program); // 派生物の作成 Product derivative = user.createDerivative(Program.class, program); derivative.setLicense(new ApacheLicense()); // 派生物はApacheLicenseで配布できない（UngrantableExceptionが飛ぶ） user.action(Action.DISTRIBUTE, derivative); derivative.setLicense(new GPLv2()); // 派生物はGPLv2で配布できる（例外飛ばず） user.action(Action.DISTRIBUTE, derivative);
んー？ Product#setLicense(License l) よりも、Person#setLicenseTo(Product p, License l) のがいいのか？ この辺り、自分のオブジェクト脳の甘いところ(笑)
あー、なんかオモシロイようなオモシロクナイような…。なんかプログラム化してるウチに、自分自身がライセンスを深く理解し出したからなのか。
CodeReposに投げてしまおうかとも思うが、こんなゴミ突っ込むのも気が引けるorz このエントリーに☆がいっぱいついたらCodeReposに突っ込ませてもらおうかなｗ
ライセンスのプログラム化
ライセンスってのは、ある意味法典・規約、すなわち code です。そしてプログラムも code。どちらも、あるinputに対して、曖昧な点なくoutputを得られる事を期待されるもの。
我々エンジニアは、後者のcodeを読み書きすることが出来る訳ですが、前者のcode、法律用語には疎く、理解に苦しむケースが多い。じゃあ、ライセンスを後者のcode化することはできないだろうか、なんて思ってみた。
このライセンスが適用されたあるソフトウェア(Object)に対して、こういった事は可能か？こうするとどうなる？という問い合わせをすると、結果を返してくれる。
まぁ、ライセンスは原文が法的効力を持つ物であって、例えば日本語訳しただけでも参考扱いにしかならない訳だが、「参考訳」と共に、そんな「参考プログラム」があっても良いんじゃないかな、と。また、法典codeはプログラムcodeよりも曖昧な点が多く、きちっとしたプログラムcodeに翻訳することは難しいかもしれない。
だけどまぁ、そんな時はひとまず「微妙Exception」を投げ返しても良いではないか。ハッキリしている約束事を確認でき、判断が難しい事柄は「判断が難しい」と知る事が出来るだけでも、有用ではないか。
そんなことをふと考えてみた。もし結果だけでなく、その結論に至った過程を知りたいのであれば、プログラムcodeを（参考までに）読んでみる。そうすれば、理屈を理解する助けにもなると思う。
さーて、出来るかな。挫折するかな(笑)
オープンソースWebサービス提供ビジネス
Webアプリは、Desktopアプリのように配布するケースと、自らがWebアプリを運用してサービスを提供するケースが考えられます。前者を「Webアプリ配布」、後者を「Webサービス提供」と表現することにします。
Windowsタイプ
さて、プロプライエタリなDesktopアプリは、「それ自体の使用権を販売する」というビジネスモデルで成り立って来ました。最近は「ユーザコミュニティを醸成し、有償サポートや書籍販売など」というビジネスモデルもメジャーになってきているかもしれませんが、未だ主たるビジネスは販売なんじゃないかな。
サイボウズOfficeタイプ
そして、プロプライエタリなWebアプリ配布。これもMicrosoft型と同じビジネスモデルが成立します。プロプライエタリな使用権販売ビジネスでは、DesktopもWebも差はありません。
Googleタイプ
次に、プロプライエタリなWebサービス提供というのは、サービス自体を販売する、つまり「使用料を取る」というモデルがあり得ますが、成り立たせるのが容易ではない。というわけで主になっているのは「コミュニティを醸成し、ユーザのアテンションを広告主に売る」というモデル。
Linuxタイプ
そしてオープンなDesktopアプリは、「ユーザコミュニティを醸成し、有償サポートや書籍販売など」のビジネスモデルを中心に据えています。使用権販売はできませんので。
？？タイプ
さて。今まで見た事がないのだがオープンなWebサービス提供というものを考えてみよう。実は、「今まで見た事がない」が故に、個人的に結構興味があるパターンです。オープンなWebサービス提供って、実はオモシロイんじゃね？ なんて事を考えてます。
既にあったりして。てへっ。
まとめ
ソフトウェアに関するビジネスモデルは、大きく下記の4つがあると思います*1。
- 使用・利用権:そのプログラムを使用・利用する権利を販売するビジネスモデル。
- サポート:有償サポートや関連書籍販売などのビジネスモデル。
- アテンション:ユーザのアテンションを広告主に販売するビジネスモデル。
そこで、各々のタイプのビジネスモデル可能性を考えてみます。
| 使用・利用権 | サポート | アテンション | |
|---|---|---|---|
| Windows・サイボウズOfficeタイプ | ◎ | ○ | △ |
| Googleタイプ | △ | ○ | ◎ |
| Linux・XOOPSタイプ | × | ◎ | △ |
| ？？タイプ | × | △ | △ |
- 凡例
- ◎:主たるビジネスモデル
- ○:売ってる場合もある
- △:情勢的に困難 or ハイリスク
- ×:不可能
……いつの間にか、ライセンス研究からビジネスモデル研究に視点がシフトしていることに気づいた。いや、「オープンなWebサービス提供」って、(見たこと)ねぇなぁ、と思って。うん。次から軌道修正する(笑)
*1:他にもあったらご指摘下さい
