全てのプログラマが理解すべき171語の文章

MITライセンス は、最も有名なオープンソースソフトウェアのライセンスです。この記事では、その内容を一行一行読んでいきます。

ライセンスを読む

オープンソースソフトウェアを利用しているものの、これまでライセンス全文（原文：171語）を読む機会がなかった方は、大した量ではないので、今すぐ読んでください。あなたにとってライセンスが身近なものでないなら尚更です。理解できない箇所などがあれば、その部分は心に留めておき、明確にするようにしてください。これから背景や解説とともに、全文を分割して順番に紹介していきますが、大事なことは全容を頭に入れておくことです。

MITライセンス（MIT）

Copyright (c) \<年> \<著作権保持者>

本ソフトウェアおよび関連文書ファイル（以下「ソフトウェア」）のコピーを入手する全ての人に対し、それらに関する無償のライセンスを、ここにおいて許諾します。ソフトウェアの扱いは無制限で、コピーの使用、複製、変更、統合、公開、配布、サブライセンス、および／または複製物を販売する権利が含まれますが、これに限定されません。また、ソフトウェアが提供された相手に対しても同様の権利を許諾します。ただし、以下を条件とします。

上記の著作権表示ならびに同意表示を、ソフトウェアの全ての複製または本体部分に記載するものとします。

本ソフトウェアは「現状のままで」で提供され、明示的/暗黙的かどうかに拘らずあらゆる保証はないものとします。ここでの保証とは、市販性、特定用途への適合性、権利の侵害がないことなどを含みますが、これらに限定されません。作成者または著作権保持者は、契約行為、不正行為、またはそれ以外の行為において、本ソフトウェアに起因または関連する事項、本ソフトウェアの使用、またはその扱いによって生じる一切の請求、損害、その他の義務について責任を負わないものとします。

MITライセンスの全文は5つの段落で構成されていますが、論理的に分解すると以下のようになります。

• ヘッダ
  • ライセンス名： “MITライセンス”
  • 著作権表示： “Copyright (c)～”
• ライセンス許諾： “本ソフトウェアおよび～”
  • 許諾範囲： “ソフトウェアの扱いは～”
  • 条件： “ただし、以下を条件とします”
  • 帰属ならびに公示： “上記の～記載するものとします”
  • 保証責任の排除： “ソフトウェアは「現状のまま」～”
  • 賠償責任の制限： “作成者または～”

では細かく見ていきましょう。

ヘッダ

ライセンス名

MITライセンス （MIT）

“MITライセンス”は単独のライセンスではなく、ライセンス形式の一群で、マサチューセッツ工科大学が公開用に作成した言語に端を発しています。ここ何年かで、このライセンスを使用した元のプロジェクトや他のプロジェクトに使用したモデルにも、多くの変更が見られます。Fedoraプロジェクトでは、ホルムアルデヒドの解剖標本のように平文で書かれた味気ないスタイルの 様々なMITライセンス を保持しており、予測不可能な進化を遂げたMITライセンスの足跡をたどることができます。

幸運なことに、 Open Source Initiative や Software Package Data Exchange (SPDX) グループは、一般的なMITスタイルのライセンス形式を”MITライセンス”として標準化しています。OSIも同様にSPDXの標準化した 文字列の識別子 を共通オープンソースライセンスに採用しており、 MIT は標準形式”MITライセンス”と明確に示しています。もし新規のプロジェクトにMITスタイルの表現を用いたいようであれば、 標準形式 を使用してください。

LICENSE ファイルに”MITライセンス”や”SPDX:MIT”と記入したとしても、責任あるレビュワーは、念のため標準形式と文言の比較を行うでしょう。”MITライセンス”とうたわれている様々なライセンス形式の違いは些細である上に、”MITライセンス”の制限が緩いために、厄介な”カスタマイズ”をしようとする作成者が出てくるのです。邪悪で全く役に立たず、ひどいライセンスの例が JSONライセンス です。これはMITライセンスの一種で、「このソフトウェアは良いことに使われるべきで、悪いことには使えない」と記されています。こういったことは「実にCrockford（プログラマ）らしい」と言えるでしょう。これは非常に不快なことであり、弁護士への冗談だったのかもしれませんが、彼ら自身は儲かり過ぎて笑いが止まらない状態でした。

この話の教訓は、”MITライセンス”そのものは曖昧だということです。恐らく、多くの人がその意図を理解すると思いますが、プロジェクトに標準MITライセンス形式の文言を記載することでのみ、あなた自身も含め皆の無駄な時間を節約できるのです。パッケージマネージャのメタデータファイルにある license プロパティといったメタデータを使用するのであれば、 LICENSE ファイルやその他のヘッダコメントに標準形式の文言を使用するようにしてください。これら全ては 自動化 することができます。

著作権表示

Copyright (c) \<年> \<著作権保持者>

1976年著作権法が制定されるまで、米国の著作権法は、クリエイティブな仕事における著作権を守るために、”手続き”と呼ばれる特定の作業が必要でした。これらの手続きに従わなかった場合、他の者を無断使用で訴える権利が制限されてしまい、敗訴となることはよくあることでした。これらの手続きの1つが”表示”で、プロジェクトに記号を記載することで、あなたが市場に対して著作権を主張していることを知らせていることになります。©マークは、著作権を有するプロジェクトであることを示す標準的な記号で、著作権を有していることを意味します。ASCII文字コードには©記号がありませんが、 Copyright (c) と記載することで同等の意味です。

1976年制定の著作権法には、国際条約であるベルヌ条約の要件が多く”適用”されており、著作権を保護するための手続きが排除されています。少なくとも米国では、著作権保持者は著作権侵害で訴える前に、または著しい侵害の可能性がある場合は侵害される前に、著作権を有するプロジェクトを登録する必要があります。実際のところ、多くの著作権保持者は、特定の相手に対して訴訟を起こす直前に著作権の登録を行っています。著作権は、表示や登録、米国議会図書館への複製の送信などを怠っただけで失われることはありません。

以前のように、著作権表示は必ずしも必要ではありませんが、表示することで多くの利点があることは確かです。作成した年や著作権が誰に属しているのかを明記することは、いつその著作権が失効し、公有に属することになるのかを知らせることになります。作成者を明らかにしておくこともまた、有益です。米国の法律では、著作権の条件は作成者が個人または”法人”なのかで異なるべきと考えられています。特にビジネス向けに使用する場合、ライセンス条項が寛容な許可であるにせよ、企業は当然のように、知名度の高い競合他社のソフトウェアを使用することもあるからです。もし、あなた個人が他の誰かに自分のプロジェクトを見てもらって、ライセンスを取得してもらいたいと思うのであれば、著作権表示はその役目を果たしていると言えます。

“著作権保持者”に関してはどうかと言うと、全ての標準化されたライセンス形式にそれを記載する箇所があるわけではありません。 Apache 2.0 や GPL 3.0 といった最近のライセンス形式は、著作権が誰に帰属していて誰に対してライセンスが与えられるかが、ヘッダのコメントや個別のファイルなどに明記されるようになっていて、一字一句同じ LICENSE 文書が発行されています。この方法であれば、偶然または意図的にかかわらず、”標準”の文言が変更されてしまうことをうまく阻止することができ、また自動ライセンス認証の信頼性をより上げることにもなります。

MITライセンスは、機関によって公開されるコード用に書かれた言語に由来します。機関が公開をする場合、その機関が”著作権保持者”として明記されています。著作権保持者を”MIT”と置き換えているような、ライセンスを複製している他の機関の場合は、それは結果的に私たちが現在使用している標準形式ということになります。この過程は、時代を追うごとに機関の略式的なライセンスにも何度となく繰り返されてきました。とりわけ、カリフォルニア大学バークレー校が策定した 旧四条項BSDライセンス は現在、修正版の 三条項 や 二条項 が使用されていますし、MITを修正したInternet systems Consortium策定の ISCライセンス も同様です。

どちらの場合も、 職務著作物 という、著作権を所有する権利に基づき、機関の名称が著作権保持者として記載されています。つまり、従業員や業者は、雇用者または依頼者の代わりに業務を行ったということになります。通常この規定は、複数の協力者によって自発的に提供されたコードには適用されません。そのため、Apache FoundationやEclipse Foundationといった、様々な貢献者から協力を得てプロジェクトを行うような団体には支障が生じます。今のところ、通常の団体は、貢献者から権利を得るために、 Apache CLAs や Eclipse CLAs といった貢献者ライセンス同意書で保護することで、 Apache 2.0 や Eclipse 1.0 のように単独の著作権保持者を記載するライセンス体系を取っています。1箇所から著作権の所有権を得ることは、GPLといったライセンスにある”コピーレフト”が更に重要になってきます。コピーレフトとは、ソフトウェアを自由に宣伝するために、著作権保持者に対してライセンスの条件を制限させないためのものです。

最近では、機関や企業の管理下におかれない多くのプロジェクトでMITスタイルのライセンス条項が使われています。SPDXやOSIでは、こうした使用をサポートするため、特定のビジネス組織あるいは機関の著作権保持者に触れることのないMITやISCなどのライセンス形式を標準化してきました。これらの形式により、現在ではプロジェクトの作成者たちが初期の段階から自分たちの名前を著作権表示に明示することが一般的となっており、その表示は後年になって改変することも可能です。しかし、少なくとも米国の著作権法においては、こうした著作権表示はその全体像を表すものとは考えられていません。

ソフトウェアを開発した元の所有者は自分の制作物に対する所有権を保持しますが、MITスタイルのライセンス条項は、そのソフトウェアに追加や変更を加え、法で言うところの”派生物”を作る権利を第三者に与えています。その一方で、第三者が行った貢献の著作権を所有する権利は元の所有者には与えられていません。では、既存のコードを土台に改変された 差分成果物 の著作権はどうなるのかというと、それぞれの貢献者が保持することになります。

こういったプロジェクトでは、著作権割り当ての取り決めは言うまでもなく、貢献者ライセンス契約を結ぶというようなこともほとんどありません。これは厳密さには欠けますがさほど不都合でもないでしょう。新参オープンソース開発者の「GitHub上でプルリクエストを送信した場合、貢献部分の配布に関するライセンスは”自動的に”プロジェクトの既存のライセンス条項に則るだろう」という想定に反して、米国の法律はそのようなルールを認めていないからです。一方的利用を許すライセンスではなく強力な著作権の 保護 、これが基本です。

「法的に有効な形で十分に文書化された、貢献の権利付与」と「何の記録もない付与」との間のギャップを埋めるため、一部のプロジェクトでは Developer Certificate of Origin（開発者オリジナル証明） を採用しています。これは、貢献者がGitのコミットで Signed-Off-By メタデータタグを使っていることを示唆する標準的なステートメントです。Developer Certificate of OriginはLinuxカーネルの開発用として考案されたもので、発表されたのは、「Linuxの一部のコードがSCOの所有するUnixのソースから派生している」と主張したあの悪名高いSCOの訴訟の後です。Developer Certificate of Originは、Linuxの各行が貢献者によるものだということを示す記録作成の方法としては最適と言えます。Developer Certificate of Origin自体はライセンスではありませんが、提出したコードがプロジェクトに対してそのコードを配布するように求めていること、そして第三者に対してはカーネルの既存ライセンス条項の下でそのコードを使用するよう求めていることを示す十分なエビデンスを提供します。また、カーネルは、貢献者の名前、所属、貢献領域およびその他のメタデータを含む機械可読な CREDITS ファイルを管理しています。こちらのリンクは、カーネルの開発フローを使わないプロジェクト用のアプローチを適用させる ある 実験 です。

ライセンス許諾

本ソフトウェアおよび関連文書ファイル（以下「ソフトウェア」）のコピーを入手する全ての人に対し、それらに関する無償のライセンスを、ここにおいて許諾します。（Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”),）

MITライセンスの骨子は、皆さんの想像どおり、使用許諾です。ライセンスを平たく言えば、一個人あるいは法的な組織（「使用許諾者」）が、別の個人や組織（「被許諾者」）に対して、あることをする許可を与えるというものです。その許可がないまま、そのあることをしてしまうと法の下で訴えられる可能性もありますが、MITライセンスは訴えないことを約束しています。

法律は、ライセンスを与えることに際して許諾と約束を区別することがあります。誰かがライセンス許諾の約束を破った場合、そのことで相手を訴えることはできるかもしれませんが、結果的にライセンスを得ることにはつながらないでしょう。ここで、弁護士が必ず使う古風な響きの陳腐な言葉が”ここにおいて（hereby）”です。この言葉を使うことにより、ライセンスの文書が単なる約束ではなく、その文書において許諾することを示しているわけです。法的な IIFE（即時関数） と言えますね。

一般的な使用許諾は指名された特定の被許諾者に対して与えられますが、MITライセンスは”公有の使用許諾”です。公有使用許諾は、社会全般、つまり全ての人に対して与えられます。これはオープンソースライセンスが持つ3つの素晴らしい特徴の1つです。MITライセンスはこの公有という特徴を導入し、”本ソフトウェア…のコピーを入手する全ての人に対し（to any person obtaining a copy of … the Software）”ライセンスを許諾しています。後ほど触れますが、このライセンスを得るには、他の人にもそれぞれの許諾について周知させるという条件もあります。

丸括弧と鉤括弧で囲まれている用語（「定義」）は、特定の文章の内容を略称したものです。それ以降、文書内では、その文章を繰り返す代わりに括弧内の定義が使用されます（参考までに、アメリカでは(a “Definition”)という形で、定義される用語の頭文字が大文字になり、その大文字を見てそれが略称であることを判断しています）。

許諾範囲

ソフトウェアの扱いは無制限で、（to deal in the Software without restriction,）

被許諾者から見ると、MITライセンスの中には7つの重要なフレーズがあります。念頭に置くべき法的な懸念は、著作権侵害で訴えられること、そして特許侵害で訴えられることです。著作権法でも特許法でも、”扱い（to deal in）”という用語は、法廷では特に具体的な内容を意味しないため、使われていません。ということは、使用許諾者と被許諾者間の紛争が法廷に持ち込まれた際には、この用語が何を意味し、当事者間にどういった共通認識があるのかが争点になるでしょう。裁判所は恐らく、この用語を意図的に広義かつ不定形な意味にしたと捉えると思います。仮に使用許諾者が、 そのような ソフトウェアの使い方を被許諾者に認めていないと訴えたとしても、あるいは、そうした思考がライセンス許諾時に両当事者の間になかったとしても、被許諾者はこの用語により、相手方の訴えと争える大きな論拠を持ち得るわけです。

コピーの使用、複製、変更、統合、公開、配布、サブライセンス、および／または複製物を販売する権利が含まれますが、これに限定されません。また、ソフトウェアが提供された相手に対しても同様の権利を許諾します。（including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,）

完璧で”過不足なく意味が伝わり”、明確で間違いのない法的文書などはありません。それがあると言ってはばからない人には気を付けてください。上記の文章はMITライセンスの中でも最も完成度の低い部分でしょう。大きく分けて3つの問題があります。

まず”～が含まれますが、これに限定されません。（including without limitation）”は法的には不適切なパターンで、いろんな解釈ができます。

• “限定がなく、含む”
• “前述の項目の一般性を限定することなく、含む”
• “～を含むが、これに限定されない”
• その他、無意味な多くのバリエーション

上記は全て同じ意味を志向していますが、どれも確実なゴールにはたどり着けていません。基本的に、これらの表現を使う起草者は、複数のことを詰め込みたいのだと思います。MITライセンスにおいては、”ソフトウェアの扱い”の具体例、つまり”コピーの使用、複製、変更…”の導入がそれです。しかしここには、被許諾者のアクションが”扱い”と見なされるには所与の例のようなものでなければならない、といった示唆はありません。問題なのは、結果的にライセンスの用語を解釈し再検討する裁判になったとしても、裁判所の方では両当事者が争っている内容を、言葉の意味合いから判断しなければならないことです。もし裁判所が”扱い”の意味を決定する必要が生じた場合でも具体例が邪魔になりますし、それを無視しろと言っても”見過ごせる”ものではありません。解釈する被許諾者側にしてみれば”ソフトウェアの扱いが制限されることはありません”とした方がいいと思いますし、文章も短くて済みます。

2つ目の問題は、”扱い”の例として出されている動詞が寄せ集めだということです。一部の動詞は著作権法や特許法の下で具体的な意味を持っていますが、不十分なものや全く具体的な意味を持っていないものもあります

• 使用（use） は、 米国特許法271章（a） 、許可なしの活動に対して特許権者がどのように訴えることができるかという特許法のリストに掲載。

• 複製（copy） は、 米国著作権法106章（a） 、許可なしの活動に対して著作権者がどのように訴えることができるかという著作権法のリストに掲載。

• 変更(modify） は、米国著作権法、米国特許法のいずれにも非掲載。著作権法の下での”派生物を準備（prepare derivative works）”するという意味が恐らく近いと思いますが、改善あるいは派生的な発明についての含意もあるかもしれません。

• 統合(merge） は、米国著作権法、米国特許法のいずれにも非掲載。”混同（Merger）”は著作権では特定の意味を有していますが、それはこの文脈で意図されるものではないでしょう。それよりも、裁判所では”統合”を、恐らく”コードをマージする”のような産業界の意味に従って解釈すると思います。

• 公開（publish） は、米国著作権法、米国特許法のいずれにも非掲載。公開されるのは「ソフトウェア」なので、恐らく 米国著作権法 における”配布（distribute）”が最も近いと思います。米国著作権法では、”公的に（publicly）”パフォーマンスをし、作品を展示する権利についてもカバーしていますが、それらの権利については演劇や録音音楽、映画など、特定の著作物にしか該当しません。

• 配布（distribute） は、 米国著作権法 に掲載。

• サブライセンス（sublicense） は、米国知的財産法の一般的な用語。サブライセンス権とは、ある人が許諾された権利の全部または一部を、他の人にライセンス許諾する権利のことです。MITライセンスのサブライセンス権はオープンソースライセンス界でも比較的珍しく、その規範はHeather Meekerが”direct licensing（直接的ライセンス許諾）”と称したアプローチで、ソフトウェアとそのライセンス条項を持つ全ての人が、所有権を持つオーナーから直接的ライセンスを得るというものです。MITライセンスの下でサブライセンスを取得する人は往々にして、ライセンスのコピーを入手することで、最終的には直接的ライセンスを持つことになります。

• 複製物を販売（sell copies of） は、複合語。 米国特許法 における”販売の申し出（offer to sell）”および”販売（sell）”に近いですが、”複製物（copies）”という言葉は著作権の概念に触れています。著作権の側から見ると”配布（distribute）”が近そうですが、 米国著作権法 には、販売についての記載はありません。

• ソフトウェアを提供された相手に対しても同様の権利を許諾（permit persons to whom the Software is furnished to do so） は、”サブライセンス（sublicense）”の冗長表現に見えます。複製物を取得した人が直接的ライセンスを得ることに関して、この表現は不必要でしょう。

3つ目の問題は、法律、産業界、一般的な知的財産、および一般的な使用条項の寄せ集めの結果、MITライセンスが特許ライセンスを含んでいるかどうかが不明となっていることです。汎用単語の”扱い”、そして例として挙がっている一部の動詞、特に”使用”は、その意味が非常に不明確ですが、位置付けとしては特許ライセンス寄りの考えを示しています。一方で、ソフトウェアの発明において特許権を持つにしろ持たないにしろ、ライセンスが 著作権者 から来るという事実、また例として挙がっているほとんどの動詞や”ソフトウェア（the “Software”）”の定義自体は、著しく著作権ライセンス寄りと言わざるを得ません。 Apache 2.0 のような、より最近の伝播性のないオープンソースライセンスでは、著作権や特許、それに商標でさえも個別かつ厳密に扱われています。

ライセンスの3つの条件

以下に定める条件に従います。

注意すべきことは常にあります！MITの場合は3つ！

MITライセンスの条件に従わない場合は、ライセンスが提供する許諾を得られません。従って、規定している内容を最低でも理論的に守らないと、訴訟、おそらくは著作権の訴訟を起こされやすくなります。

たとえ被許諾者がライセンスに関心のない場合でも、ライセンスのためにソフトウェアの価値を利用して条件を守らせるよう仕向けるのが、オープンソースライセンスの2つ目の優れた考え方です。最後にあるのは、MITライセンスには存在しないもので、ライセンスの条件から切り離されています。 GNU Public License のような”コピーレフト”では、ライセンスの条件を使って、改変したソフトウェアへのライセンスの付与や変更後のバージョンの配布を可能とする方法を管理しています。

表示の条件

上記の著作権表示および本許諾表示は、ソフトウェアの全てまたは主要な部分に記載されるものとします。 （The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.）

複製したソフトウェアを他人に譲渡する場合には、ライセンスの文章とあらゆる著作権表示を含めなくてはなりません。これにはいくつかの重要な目的があります。

1. パブリックライセンスの下でソフトウェアの使用許諾が与えられていることを他人に表明。これはダイレクトライセンスのモデルで鍵となる部分で、これによってユーザは著作権者から直接ライセンスを得ることになります。

2. ソフトウェアの作成者を明示。これによって作成者は賞賛や栄光、現金の寄贈を受けることができます。

3. ソフトウェアに関する保証の排除や責任制限（以下で説明）を確保。複製されたソフトウェアを得る人は、使用許諾者への保護も同様に得るべきです。

ソフトウェアの複製、あるいはソースコードなしのコンパイル済みの複製でも、課金して配布することに障害はありません。しかし、そうすることで、自分のソフトウェアがMITの規定に適しているとか、他のライセンスの下で供給されているとかを装うことはできません。複製を得た人は、自分の権利が”パブリックライセンス”の下にあると分かるようになっています。

率直に言って、こういった規定の遵守は細分化されています。ほとんど全てのオープンソースのライセンスに同じような”帰属”条項があります。システムやインストールされたソフトウェアの作成者は多くの場合、自分の作ったソフトウェアをリリースするたびに、ライブラリやコンポーネント用のライセンスの文書を伴った告知のファイルや”ライセンス情報”画面のコンパイルが必要なものだと考えています。プロジェクト管理者がベースになった開発は、こういった仕事を教えるのに役立ちました。しかし、Webの開発者は、概してメモを残してきませんでした。ツールがないという言い逃れは通りません。多くのツールが存在していますし、他にもnpm等のリポジトリにはモジュラー性の高いパッケージが存在しており、それらを利用することでライセンス情報用にメタデータのフォーマットを統一的に標準化できるのです。優れたJavaScriptのminifierにはどれも、ライセンスのヘッダのコメントを維持するためのコマンドラインのフラグがあります。他のツールはパッケージ階層から LICENCE のファイルへつながります。言い訳は成り立ちません。

保証責任の排除

本ソフトウェアは「現状のままで」で提供され、明示的/暗黙的かどうかに拘らずあらゆる保証はないものとします。ここでの保証とは、市販性、特定用途への適合性、権利の侵害がないことなどを含みますが、これらに限定されません。 （The Software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement.）

アメリカ合衆国のほとんどの州で、商取引の監督するためのモデル法である統一商事法典（UCC）を下敷きにした州法を制定しています。UCC第2条、カリフォルニア州で言えば”Division 2″では物品販売について、中古車販売から工場プラントへ送る工業用化学品の大型の出荷まで規定しています。

売買契約に関するUCCの規定の一部は必須条項です。これらの規定は購入者、販売者が好むか好まざるかに関わらず、常に適用されます。それ以外はただの”デフォルト”です。買主、売主がオプトアウトを記載しない限り、UCCの条文にある基本規定を彼らの取引に適用することを黙示しています。デフォルトの規定の中では、売主から買主に対する、販売商品の品質やユーザビリティの”保証”、または約束が暗示されています。

MITライセンスのようなパブリックライセンスが、契約（使用許諾者と被許諾者間の強制力ある合意）なのか、あるいは、一方通行ながら条件付きの場合があるライセンスなのかは、大きな論争の種です。ソフトウェアが、UCCの規定の適用される”商品”とみなされるかどうかという議論はそれほど進んでいません。賠償責任に至っては、使用許諾者の中で話にも上がっていません。つまり彼らは、無償で公開したソフトウェアが壊れたり、問題を起こしたり、動かなかったり、そうでなくてもトラブルの種になった場合に、多額の訴訟を起こされたくないのです。それは”黙示的保証”のために3つのデフォルト規定が示していることとは正反対です。

1. UCC 第2-314条 において、”商品性”の黙示的保証は、”商品”である「ソフトウェア」が、少なくとも平均的質であり、適切に包装され、かつラベル表示されており、使用される通常の目的に適合するという約束です。この保証はソフトウェアを譲渡した者が”商人”である場合にのみ適用されます。つまり、彼らがソフトウェアを取引する者で、ソフトウェアの知識があることを示している場合です。

1. UCC 第2-315条 において、”特定の目的への整合性”の黙示的保証は、買主が商品を特定の目的のために供給されることを売主に期待し、そのことを売主が知っている場合に有効です。商品は実際にその目的に対して”整合性”がなければなりません。

2. “非侵害”の黙示的保証に関する記載はUCCにはありませんが、一般の契約法が共通して持つ特徴です。これは、受け取った商品が誰か別人の知的所有権を侵害していることが分かった場合に、買主を守る暗示的な約束です。MITライセンス下のソフトウェアが、それに対して許諾をしようとしている人物に実際は属していなかった場合、あるいは、誰か別人がその特許を持っていた場合に該当します。

UCC 第2-316条（3） では、商品性の黙示的保証と通常の目的に対する適合性をオプトアウト、”排除”するためには、そのことを顕著に示す文言の記載を義務付けるとしています。ここでの”顕著”とは、そのことに注意喚起すべく書面で示すことを意味し、不用心な消費者が見過ごすような微細な文字の但し書きとは対極です。州法が、非侵害の免責について、類似の注意喚起を義務付けていることもあります。

法律家たちは長く、全て大文字で( ALL-CAPS )記しさえすれば、顕著にする義務を満たしているとする拡大解釈に苦しめられてきました。それは間違っています。法廷は、その解釈に安住する法曹界を非難してきました。また、全て大文字の文章では、注意喚起されるどころか、より読む気を削がれるということに誰もが合意するでしょう。同様に、オープンソースライセンスフォームの多くは免責事項を全て大文字で記しています。プレーンテキストの LICENSE ファイル上で、文字を目立たせる唯一の方法だから、というのがひとつの理由です。私はアスタリスクやその他のASCIIアートを使うほうが好きですが、今となっては後の祭りです。

責任制限

作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとします。 （In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the Software or the use or other dealings in the Software.）

MITライセンスはソフトウェアに”無償”の許諾を付与しましたが、法は、無償でライセンスを受けた人々が、何か間違いが起こった場合に訴える権利があり、使用許諾者に責任を求めることを放棄する仮定はしていません。”責任制限”は、”損害の除外”と対になっていることが多く、訴訟を起こさないという約束として、むしろライセンスのように機能します。しかし、これらは 被許諾者 による訴訟の相手となる 使用許諾者 への保護です。

一般的に、法廷は責任制限と損害の除外を注意深く解釈します。莫大なリスクを一方から反対側へ移せるからです。人々に法廷での過ちを是正する手段を与える中で、コミュニティの重大な利益を守るため、彼らは責任を制限する文言を”厳密に解釈”し、可能な限り、それによって守られる人に反対する立場から読みます。責任制限に説得力を持たせるには具体的でなければなりません。特に”消費者”契約や、訴訟する権利を放棄した人々が知識や交渉力を欠いているような状況では、法廷は、埋もれて見つけにくい文言の受け入れを拒否する場合もあります。一部はそのため、また一部は慣例上、法律家もまた、説明責任を全て大文字にしがちです。

少し掘り下げると、”責任制限”部分は、被許諾者が請求できる賠償金額の上限です。オープンソースライセンスでは、その制限は常に、全く賠償なしの$0、”責任なし”です。反対に、商用ライセンスでは、先の12か月間に支払われたライセンス料金の倍であることが多いのですが、ほぼ交渉にかけられます。

“除外”のリストは、具体的には使用許諾者が使用することのできない、法的な要求（損害に対して訴える根拠）のようなものです。巷の夥しい法的書式と違わず、MITライセンスは（契約違反のための）”契約行為”と、”不法行為”について述べています。不法行為規定は、過失、または悪意を持って他者に害を及ぼすことに対する一般的な規定です。運転中に携帯電話をいじって誰かをはねれば、不法行為を行なったことになります。会社が欠陥のあるヘッドフォンを販売して人々の耳に火傷を負わせたなら、その会社は不法行為を行なっています。契約が具体的に損害の訴えを除外していない場合、法廷は契約のみが請求の範囲になるのを避けるために排除の文言を解釈することがあります。おまけに、MITライセンスは”またはそれ以外であろうと”を付け加えるなど、あまり人目にふれない海事法のようなエキゾチックな法的権利にならっています。

“起因または関連し”、”使用またはその他の扱いによって生じる”という言い回しは、法律の草案執筆者の習性によって繰り返されてきている症状です。ポイントは、ソフトウェアに関わるいかなる訴訟も制限と除外の範囲であるということです。万一、何かが”〜によって”や”関連して”ではなく、”起因して”生じた場合を考えると、3つ全てを書式に入れたほうが安心できるので、全部詰め込んでしまうのです。書式のこの部分にこだわるような判事は、それぞれに異なる意味を見出しても気にすることはありません。プロの草案執筆者が、この行で同じ内容を意味するのに別の言葉を使うことはないと言ってよいでしょう。訴訟手続きにおいて、判事がはじめから不利な制限に難色を示すかもしれませんが、いずれにしても彼らは範囲を縮めて解釈していきますので、気にしても仕方ありません。話がそれましたが、同じ文言は文字どおり何百万もの契約で見られるものです。

まとめ

こうして一語一句にあれこれ難癖をつけるのは、教会への道々ガムを吐き出して歩くようなものです。MITライセンスは法律の傑作です。MITライセンスは役に立つのです。もちろん、数10年前から存在するあらゆるソフトウェアIPの病、とりわけソフトウェアの特許の惨状に対する万能薬であるとは言えません。しかし、MITスタイルのライセンスは、ニッチな目的に見事に力を発揮してきました。著作権、売買、契約法などのややこしいデフォルトの規則を、最小限の法律ツールの慎重な組み合わせで覆したのです。より大きなコンピューティングの文脈において、その寿命の長さは驚異的です。MITライセンスはこれまで生き延びて、さらに今後も、そのライセンス下にある大多数のソフトウェアよりも長く使われ続けるでしょう。私たちにできるのは、信頼できる法的サービスがついに支持を失うのは、何10年先の話だろうかと思いめぐらすことだけです。MITライセンスは、自前で弁護士を雇えない人々にとって特に寛大であり続けています。

今日私たちがなじんでいるMITライセンスが、いかに具体的で標準的な用語のセットであるか、そして、組織によってバラバラで、場当たり的なバリエーションばかりのカオスに、それがやっとのことで秩序をもたらした過程を見てきました。

また、どのように知的所有権管理の手続きを学業界、スタンダード、商用、そして設立組織に伝えてきたのか、属性と著作権告知に対するアプローチについても説明しました。

MITライセンスがいかにして、ソフトウェアの許諾を全ての人に対して無償で認め、使用許諾者を保証と責任から守る条件を備えているかも、読み取ってきました。

無愛想で冗長、弁護士的な気取りを装っているにもかかわらず、この171ワードは呆れるほど膨大な法的処理を片付け、知的所有権と契約の深いやぶを切り開き、オープンソースソフトウェアへの道を解放したのです。

この長い投稿を読み、役に立ったと知らせてくれたり、手直しの助言をくれたりした全ての人たちに感謝します。いつものように、 e-mail 、 Twitter 、 GitHub にコメントしてくださると嬉しいです。

もっと知りたい、GNU Public Licenseや、Apache 2.0ライセンスなど、他のライセンスの概要はどこで読めるかという質問をたくさんいただきました。興味の切り口は様々であっても、全ての人に私は次の文献をおすすめします。

• Andrew M. St. Laurent著、 Understanding Open Source & Free Software Licensing 、O’Reilly刊。

一番に挙げたのは、やや古びているものの、そのアプローチは上記の1行1行読み解く手法に近いからです。O’Reillyは オンライン でも公開しています。

• Heather Meeker著、 Open (Source) for Business

個人的には、GNU Public Licenseとコピーレフトについてより一般的に書かれたものでは最も良いと考えています。この本は歴史、様々なライセンス、その発展過程と共に、互換性とコンプライアンスについても網羅しています。GPLを検討したり扱ったりするクライアントに貸しています。

• Larry Rosen著、 Open Source Licensing 、Prentice Hall刊。

最初に手に取りたい本。 オンライン でも無料で入手できます。プログラマを対象にオープンソース被許諾者ングと関係法についてゼロから説明する優れた手引き書です。これも細かい点では古いところもあるのですが、Larryはオープンソースビジネスモデルのライセンスを簡潔な概要で分類しており、それは時代を選びません。

以上の3冊から、オープンソース被許諾者の弁護士として非常に重要なことを学びました。著者は皆、私のプロフェッショナルヒーローです。ぜひ読んでみてください。 – K.E.M

私はこの記事を Creative Commons Attribution-ShareAlike 4.0 ライセンス の下、使用を許諾しています。