プログラマーが理解すべき171の言葉

MITライセンスは、最も人気のあるオープンソースライセンスです。 これは、行ごとの解析を使用した彼女の読書の1つです。

ライセンスを読む

もしあなたがオープンソースソフトウェアを開発していて、このライセンスを詳細に読んでいないなら-そしてそれがたった171単語で構成されているなら-あなたはこれをする必要がある。 特に、日常的にライセンスを扱わない場合。 理解していないことをすべて確認してください。 そして、これらすべての言葉を、順番に、断片的に、文脈とコメントとともに繰り返します。 全体を想像することが重要です。

MITライセンス（MIT）



著作権©「年」「著作権者」



これにより、このソフトウェアおよび関連ドキュメントファイル（「ソフトウェア」）のコピーを取得するすべての人に、使用、コピー、変更、マージの権利を含むがこれらに限定されないソフトウェアを処理する許可が無料で付与されます。ソフトウェアのコピーを発行、配布、サブライセンス、および/または販売し、以下の条件に従って、ソフトウェアの提供先にソフトウェアの提供を許可します。



上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは大部分に含まれるものとします。



本ソフトウェアは、商品性、特定の目的への適合性および権利の非侵害の保証を含め、明示または黙示を問わず、いかなる種類の保証もなしに「現状のまま」提供されます。 いかなる場合でも、作者または著作権者は、契約、不法行為、またはその他の行為、ソフトウェアまたは使用またはその他の取引に起因する、または関連するいかなる請求、損害またはその他の責任についても責任を負わないものとしますソフトウェア。

MITライセンス



著作権©「年」「権利所有者」



このライセンスにより、このソフトウェアおよび関連ドキュメント（以下「ソフトウェア」と呼びます）のコピーを受け取った個人は、制限なしでソフトウェアを無料で使用できます。これには、使用、コピー、変更、マージ、公開、配布、サブライセンス、および/または以下の条件を条件として、本ソフトウェアのコピーの販売、および本ソフトウェアの提供者への販売



上記の著作権表示およびこれらの条件は、このソフトウェアのすべてのコピーまたは重要な部分に含まれている必要があります。



このソフトウェアは、いかなる種類の保証も含め、明示的または黙示的な保証なしに「現状のまま」提供されます。 いかなる場合においても、作者または権利所有者は、契約、配達、またはその他の責任への対応を含め、いかなる請求、損害、またはその他の要件に対して責任を負いません。

ライセンスは5つのセクションに分かれていますが、論理的には次のように分かれています。

• 見出し
  
  
  
  
  • 役職
  • 著作権
  
  
  
• 許可
  
  
  
  
  • 範囲
  • 条件
    
    
    
    
    • ライセンス譲渡
    • 保証の否認
    • 責任の制限

行こう

見出し

役職

MITライセンス

「MITライセンス」は単一のライセンスではなく、マサチューセッツ工科大学で製造された製品に採用されているスタイルの影響を受けて形成された一連のライセンスフォームです。 長年にわたって、最初に使用したプロジェクトと他のプロジェクトのモデルの両方で、しばしば変更されました。 Fedora Projectは、興味深いライセンスオプションのアーカイブを維持しており、ライセンスオプションはプレーンテキストで保存されています。まるでホルムアルデヒドの解剖学的な好奇心が進化を示しているかのようです。



幸いなことに、Open Source InitiativeとSoftware Package Data eXchangeグループは、MITライセンスの全体的な外観を標準化し、「MITライセンス」と呼んでいます。 OSIは、一般的に使用されるSPDXのオープンソースライセンスに文字列識別子を採用しており、略語MITは明示的に「MITライセンス」を意味します。 MITの条件で製品を配布する必要がある場合は、標準のMITライセンスフォームを使用してください。



ただし、LICENSEファイルに「MITライセンス」または「SPDX：MIT」の行を含めても、責任を負う読者は安全のために標準形式でテキストをチェックします。 多くの異なる形式のライセンスは、「MITライセンス」と呼ばれ、詳細が異なります。また、「MITライセンス」という曖昧な概念のため、多くの著者は、テキストに何かを追加する誘惑に抵抗できませんでした。 このようなひどくひどい嫌な変更の標準的な例は、JSONライセンスです。これにより、MITライセンスに「プログラムは悪いものではなく、良いものに使用されるべきです」という目標が追加されます。 このトリックはクロックフォードの精神にとても忠実です。 ひどい頭痛。 たぶんこれは弁護士のm笑だ。 彼らは銀行までずっと笑った。



教訓は次のとおりです。「MITライセンス」と書くだけではあいまいになります。 原則として、人々はあなたが考えていたことを理解しますが、標準のMITライセンスのテキストをプロジェクトにコピーするだけで、全員と自分の時間を節約できます。

著作権

著作権©<年> <権利の所有者>

米国で1976年著作権法が施行される前は、著作権が確実に保持されるようにするために、「正式な要件」という特別な措置が必要でした。 そして、あなたがそれらに従わなかった場合、あなたの作品の違法使用を訴えるあなたの権利は限られており、時には姿を消しさえしました。 正式な要件の1つは、いわゆる 「通知」：作品へのマークの掲示、および権利の主張を市場に通知するために必要なその他のアクション。 アイコンはこのための標準的なシンボルです。 ASCIIにはこのようなアイコンがなかったため、同じ目的で©の組み合わせが使用されました。



1976年著作権法は、手続きの必要性を排除しました。 米国では、権利所有者はまだ訴訟前に作品を登録する必要がありますが、実際にはこれは裁判所自体の直前に行われます。 宣言、登録、米国議会図書館へのコピーの送信などを忘れても著作権は失われません。



しかし、これらのステートメントが不要になったとしても、それらは非常に有用です。 特定の作業が行われた年とその権利を示すことにより、これらの権利が失効し、その作品が公有財産になる時期をすぐに明確にすることができます。 著者の性格も有用です。米国では、法律は個々の著者と著者グループに異なる方法で適用されます。 ビジネスでは、ライセンスが許可していても、ライバルのソフトウェアを使用する前に、会社はよく考えます。 他の人があなたの作品に気づき、あなたからライセンスを取得したい場合、著作権者に関する情報も役立ちます。



著作権の所有者にとって、場所はすべてのライセンスにはありません。 Apache 2.0やGPL 3.0などのより新しいライセンスは、そのままコピーする必要のあるライセンステキストを公開し、コメントと別のファイルで既に作品の所有者を示しています。 このアプローチにより、ライセンステキストの変更が不要になり、ライセンスの自動処理が簡素化されます。



MITライセンスは、さまざまな機関によって実行されるコードリリースから派生しています。 そのようなリリースでは、権利の所有者はコード発行機関のみでした。 他の機関はこれらのライセンスを採用し、MITをその名前に置き換え、一般ライセンスの存在に至りました。 他のライセンスはこのプロセスの対象でした。たとえば、カリフォルニア大学のBSDライセンスは当初4ポイントで構成されていましたが、現在は3ポイントと2ポイントのバージョンで使用されています。また、MITライセンスのバリアントであるInternet Systems ConsortiumのISCライセンスも使用されています。



いずれの場合も、組織は自らを権利の所有者として示し、従業員や請負業者によって行われた仕事の権利を保持できる「雇用のために行われた仕事」の機会を利用しました。 これらの規則は、通常、従業員と請負業者が自分のイニシアチブで行う作業には適用されません。 また、コードを自発的に提供する共同作業する人々の分散グループには適用されません。 Apache FoundationやEclipse Foundationなど、さまざまなソースからのコードを受け入れるプロジェクト管理基金にとって、これは問題です。 資金は通常、1人の権利保有者（Apache CLAとEclipse CLA）を主張するホームライセンスを使用してこれを処理し、スポンサーの権利を取得します。 1か所で権利を収集することは、GPLなどのあらゆるコピーレフトライセンスにとってさらに重要であり、フリーソフトウェアの価値を著作権所有者に配布する責任を移します。



今日、いくつかのコードプロバイダーの作業を管理することさえしない多くのプロジェクトがMITライセンスを使用しています。 SPDXおよびOSIは、特定の個人または権利を持つ個人のグループを参照しないライセンスフォームを標準化することでこれに貢献しました。 その結果、ほとんどの著者は単に著作権所有者の通知に自分の名前を入力し、場合によっては年を挿入することさえあります。



コードの元の所有者は、彼らの作品に対する権利を保持します。 しかし、MITのようなライセンスは、「派生作業」と呼ばれるものを作成するアドオンソフトウェアを変更する権利を他の人に与えますが、元の作者に他の人が作成したものを所有する機会を与えません。 各貢献者は、既存のコードに基づいて実行される作業の彼の部分に対する権利を保持します。



ほとんどのプロジェクトは、権利の分配に関する文書への署名は言うまでもなく、ライセンスから参加者から同意を集めることを気にしません。 これは単純ですが、理解できます。 開発者は、プールリクエストをGitHubに送信することで、ライセンスの文字に従ってプロジェクトを配布する権利を自動的に取得すると仮定していますが、米国ではそのようなルールはありません。 デフォルトでは、著作権保護が保護されており、ライセンスを転送する許可はありません。



権利の合法化と文書化された移転と書類の不在の間のギャップを埋めるために、一部のプロジェクトでは、開発者の原産地証明書、開発者からの原産地証明書、開発者がSigned-Off-Byメタタグを使用して参照する標準ステートメントを採用しています。 DCOは、SCO所有のUnixカーネルから生まれたLinuxカーネルを開発するために設計されました。 DCOは、Linuxの各ラインが貢献者からもたらされるプロセスを文書化するのに優れた仕事をしています。 これはライセンスではありませんが、プロジェクトにコードを送信した人がプロジェクトと共に配布されることを意味し、ユーザーがカーネルの既存のライセンスに従ってそれを使用することを示す多くの良い証拠を提供します。 カーネルは、人間が読めるCREDITSファイルもサポートしています。このファイルには、貢献したすべての人々が名前、メンバーシップ、貢献エリア、およびその他のデータとともにリストされています。

許可

このライセンスは、このソフトウェアのコピーおよび関連ドキュメント（以下「ソフトウェア」と呼びます）を受け取った個人を許可します。

MITからのライセンスの本質は、ご想像のとおり、ライセンスであるということです。 一般に、ライセンスとは、一方の個人または法人（ライセンサー）が他方（ライセンシー）に法廷で異議を申し立てることができることを許可する許可です。 MITライセンスは訴えない約束です。



法律は、ライセンスとライセンスの譲渡の約束を共有する場合があります。 誰かがあなたにライセンスを与えるという約束を破った場合、あなたは約束を破ったとして彼を訴えることができますが、あなたはまだライセンスを取得できないかもしれません。 この文では[ 英語版のアーキズム「ここで」がこれに役立つ-約。 perev。 ]このライセンスのテキスト自体は既にライセンスを付与しているものであり、それを譲渡するだけの約束ではないと説明されています。



多くのライセンスは特定の名前付きライセンスに許可を与えますが、MITライセンスは「パブリックライセンス」です。 パブリックライセンスはすべての人に許可を与えます。 -社会へ。 これは、オープンソースライセンスの背後にある3つの素晴らしいアイデアの1つです。 MITライセンスは、すべての「このソフトウェアのコピーを受け取った個人」にライセンスを提供することにより、このアイデアを活用しています。



括弧と引用符（「定義」）での概念の表記は、法律文書で用語に特定の意味を与える標準的な方法です。 当事者は、裁判所の手続においてこれらの条件を使用できます。

範囲

制限なしのソフトウェアの無料使用、

ライセンシーの観点から、これらの言葉は、MITライセンスのすべての言葉の中で最も重要です。 権利に関連する主な問題は、著作権侵害および特許侵害で訴追される可能性です。 これらの法律分野では、「無料で使用する」という言葉を使用していません。 その結果、裁判所は必然的にこの定義の意味を尋ねます。 裁判所は、この説明が意図的に広すぎてオープンであると判断します。 ライセンシーは、ソフトウェアの特定の使用について許可を与えなかったという事実に関するライセンサーの主張に抵抗することができます。

本ソフトウェアのコピーを使用、コピー、変更、マージ、公開、配布、サブライセンス、および/または販売する無制限の権利、および本ソフトウェアを提供された人に、

完全に明確な、または完全に理解可能な完全な法的文書はありません。 誰かがあなたにそうでないと言っても信じないでください。 ライセンスのこの部分は、最も完璧ではありません。



第一に、「無制限の法律を含む」は、法的文書を書く必要がない方法の例です。 この定式化にはバリエーションがあります。

• 含むが、これに限定されない。
• 上記の一般化を含むがこれらに限定されない。
• 含むが、これに限定されない。

その他。



それらのすべては1つの目的のために書かれており、それらのどれもそれに到達しません。 それらを使用する弁護士は魚を食べることを望み、座礁しません。 MITライセンスでは、「使用、コピー、変更」など、「ソフトウェアの使用」の特定の例を提供しようとする試みを意味します。このソフトウェアは、リストされている方法の1つだけで使用できることに注意してください。 問題は、そのようなライセンスを法廷で提出した場合、法廷はライセンスを理解するためにこれらの条件の意味を判断しなければならないことです。 裁判所が「ソフトウェアを使用する」の意味を理解したい場合、ライセンスに示されているユースケースを「見る」ことはできません。 ライセンスに「制限なしでソフトウェアを使用する」と書くのが最善だと思います。 それも短いです



第二に、これらの用語はごまかしです。 これらのいくつかは、著作権法および特許法で説明されていますが、そうでないものもあります。

• 使用法は、米国特許法第35条第271項（a）に記載されており、特許所有者の許可なしに、特許出願人が訴えることができる出願の理由のリスト
• 著作権法のリストにあるArt.17 p.106のコードにあるコピー
• 変更、公開、マージは 、著作権法でも特許法でも見つかりません。
• 著作権法で認められた再配布 。
• サブライセンスは、知的財産法の一般的な用語です。 それは、あなたが他の人に許可したことの一部または完全なリストに自分のライセンスを与える権利を意味します。 この項目は、オープンソースライセンスでは珍しいものです。 ソフトウェアのコピーを受け取るすべての人が所有者から直接ライセンスを受け取る場合、通常のアプローチは直接です。
• sellはハイブリッドな言葉です。 特許法で言及されている販売と似ていますが、著作権法のようにコピーの販売を指します。 著作権の観点からは、「配布」に近いが、著作権に関する法律は販売について言及していない。
• このソフトウェアを提供されている人々と同様に、このフレーズは「サブライセンス」の不必要な繰り返しのように見えます。 また、ソフトウェアのコピーを受け取った人がすぐにライセンスを受け取る限り、それは必要ありません。

そして最後に、法的、産業的、知的財産、および一般的な用語のこの混合により、MITライセンスに特許許可が含まれているかどうかは明確ではありません。 「使用」は特許を暗示しますが、あまり明確ではありません。 ライセンスがソフトウェアの特許権を持っているかどうかに関係なく、著作権所有者から得られるという事実、および使用例とソフトウェア自体の定義に示されているほとんどの動詞は、著作権ライセンスを示しています。 Apache 2.0などの新しいライセンスは、著作権、特許、さらには商標を個別に明示的に言及しています。

3つのライセンス条項

次の条件の対象

常にキャッチがあります-そして、MITには3つあります！



条件を満たさない場合、許可は得られません。 したがって、理論的にはこの場合、著作権法に基づいて訴えられる可能性が最も高くなります。



条件を満たそうとするライセンシーの動機としてソフトウェアの価値を使うことは、彼がライセンス料を支払わなかったが、オープンソースソフトウェアの2番目の素晴らしいアイデアです。 後者は、MITライセンスで場所を見つけられませんでしたが、ライセンスの条件に基づいています-GNUパブリックライセンスなどのライセンスは、変更を行う人々が変更されたバージョンをライセンスおよび配布する方法を制御する条件を使用します。

ライセンス譲渡

上記の著作権表示およびこれらの条件は、このソフトウェアのすべてのコピーまたは重要な部分に含まれている必要があります。

誰かにソフトウェアのコピーを渡した場合は、その中にライセンステキストを含める必要があり、著作権表示を追加できます。 これにはいくつかの目的があります。

1. パブリックライセンスの下でソフトウェアに対する許可を持っていることを他の人に伝えます。 これは、各ユーザーが権利の所有者から直接ライセンスを受け取るときに、ライセンスを直接発行するモデルの重要な機能です。
   
   
   
   
2. 誰が賛辞、名声、寄付で水をまく必要があるかが明確になるように、それはソフトウェア作者の概念を与えます。
   
   
   
   
3. 保証の否認および責任の制限を提供します。

ソースコードなしで、コピーの配布のためにお金を取ること、またはコンパイルされた形式でコピーを作成することさえ禁止しません。 ただし、この場合、コードが自分のものであるふりをしたり、他のライセンスの下で渡したりすることはできません。 製品の受領者は、「パブリックライセンス」に基づく権利を知っている必要があります。



残念ながら、これらの条件は十分に満たされていません。 ほとんどすべてのオープンソースライセンスにはこれらの条件があります。 システムおよびインストールされたソフトウェアの作成者は、多くの場合、ライセンス情報を含むファイルを画面に表示し、ライブラリおよびコンポーネントにライセンスのコピーを含める必要があることを認識しています。 プロジェクト管理基金はこれらの実践を教えます。 しかし、Web開発者は通知を受け取っていないようです。 彼らには許しはありません。

保証の否認

このソフトウェアは、いかなる種類の保証も含め、明示的または黙示的な保証なしに「現状のまま」提供されます。

ほとんどすべての米国の州では、法律は、商取引を管理する法律のセットである統一商法のバージョンに従うことを要求しています。 UCCの2番目の記事では、オークションで購入した中古車から工業用化学品の生産まで、商品の販売契約を扱っています。



一部のUCCルールは拘束力があり、常に適用されます。 その他は、デフォルトの状態のみを記述します-売り手と買い手が契約で他に何かを書かない限り。 これらのルールには、デフォルトで保証があります。つまり、製品を使用するための品質と適合性について、売り手が顧客に約束するものです。



MITのようなパブリックライセンスは、契約（ライセンシーとライセンサーを強制できる契約）なのか、それとも条件を付加できる単なるライセンスなのか、という議論があります。 ソフトウェアが製品であるかどうか、したがってUCCの管轄に含まれているかどうかについては、少し議論が少なくなります。 しかし、ライセンサーの責任について争いはありません。配布するソフトウェアが故障したり、問題を引き起こしたり、機能しなかったり、何らかの形で否定的に現れたとしても、誰も訴えられません。 これは、3つのデフォルトの保証ルールで説明されている内容とは正反対です。

1. セクション2-314によると、市場性は、製品（ソフトウェア）が少なくとも平均品質であり、適切にパッケージ化およびラベル付けされ、通常の使用に適しているという約束です。 このルールは、ソフトウェアディーラーにのみ適用されます。つまり、ソフトウェアディーラーを販売し、自分自身をこの分野の専門家と見なす人にのみ適用されます。
   
   
   
   
2. セクション2-315によると、特定の目的への適合性は、製品が特定の方法での使用に適していると買い手が期待していることを売り手が知っている場合に適用されます。
   
   
   
   
3. 特許の障壁はありません-UCCの一部ではありませんが、契約法で一般的に使用されています。 購入した製品が他人の知的財産権を侵害していることが判明した場合に、購入者を保護します。

セクション2-316（3）では、これらの保証を除くライセンステキストで、目立った方法で、つまり契約の最後のページに小さな活字で隠すのではなく、自分自身に注意を引くことでこれを行う必要があります。 特許侵害通知を宣言するために州法で同じことが要求される場合があります。



弁護士は、大文字でテキストを書くと、可視性の要件を満たしていると誤解されてきました。 そうではありません。 大文字は多くの場合、読者の注意を引くのではなく、読者をはじきます。 しかし、ほとんどのオープンソースライセンスは、この部分を大文字で記述します。これは、プレーンテキストファイルのテキストを目立たせる最も明白な方法だからです。 私はアスタリスクまたは他のASCIIアートを使用したいと思いますが、この列車はすでに去っています。

責任の制限

いかなる場合においても、作者または権利所有者は、契約、配達、またはその他の責任への対応を含め、いかなる請求、損害、またはその他の要件に対して責任を負いません。

MITライセンスはソフトウェアを無料で配布しますが、法律は、何かがうまくいかず、ライセンサーが有罪であると判断された場合、無料ライセンスを受け取った人々が裁判所の権利を失うことを意味しません。 ライセンスのような責任の制限も、法廷に行かないという約束として機能します-この場合に限り、ライセンサーをライセンシーから保護します。



裁判所は通常、保証の免責事項を注意深く読みます。これは、リスクを一方から他方にシフトするのに役立つ可能性があるためです。人々に自分自身を守る機会を与えるために、すべての可能な場合において、裁判所はこれらの拒否を彼らが擁護するものに対して解釈します。そのような条件が契約の後ろのどこかにあり、割り当てられていない場合、裁判所はしばしばそれらを考慮することを拒否します。したがって、弁護士は大文字で書くことに慣れています。



責任の制限は、とりわけ、ライセンシーを訴えることができる金額を制限します。オープンライセンスの場合、この制限は常にゼロです。商用ライセンスには、過去12か月間に支払われた複数のライセンス料金が含まれることがよくあります。



このセクションでは、ライセンサーが使用できない法的手続きの種類を示します。多くの法的形式と同様に、このライセンスには契約違反と不法行為が記載されています。不法行為の規則は、損害賠償を伴う行為の委任に関するものです。 SMSを送信して道路上の誰かを押しつぶした場合、不法行為を犯したことになります。あなたの会社が、人々の耳を燃やす欠陥のあるヘッドフォンを販売した場合、彼女は不法行為を犯しました。契約が不法行為の要件の除外を明示的に述べていない場合、裁判所はこれを利用することがあります。 MITライセンスには、すべての特殊な要件を除外するための「その他の要件」が記載されています。



「ソフトウェアの使用またはソフトウェアでのその他の行為から生じる」というフレーズは、弁護士からの安全に対する後天的な恐怖の特徴である神経質なチックです。重要なのは、このソフトウェアに関連する訴訟は制限と例外の対象になっているということです。ただし、ソフトウェアの使用は、ソフトウェアの「その他のアクション」に完全に含まれます。 [元のライセンスは、「発生」、「接続」、「使用」の3つのバージョンのイベントを示します。つまり、「発生」、「接続」、および「使用時」であり、本質的に、記事の著者への苦情を引き起こす-約。 perev。 ]ただし、このような言語は、他の何百万ものライセンスで使用されています。

おわりに

しかし、これらすべての主張はあまり大きくありません。 MITライセンスは古典的な法学です。彼女は働いています。ソフトウェアのすべての病気、特に特許紛争の万能薬ではありません。しかし、そのようなライセンスはうまく機能しており、著作権、販売、契約でデフォルトで採用されている不便なルールの廃止という特定の目的に、最小限の法的手段を提供しています。コンピューターのトピックの文脈では、その生存性は驚くべきものです。彼女は生き残りましたが、彼女のためにライセンスされたソフトウェアの大部分は生き残ります。それが何十年はまだ機能するかを推測することしかできません。これは、弁護士を雇う余裕のない人にとって特に便利です。



MITライセンスは、さまざまな組織で受け入れられているライセンスのランダムバージョンに混乱をもたらす、定義済みの標準化された定義のセットであることがわかりました。



著者および著作権の問題を特定する彼女のアプローチが、学術および商業組織における財産権の管理の実践にどのように影響するかを見ました。



ライセンサーを保証と責任の実行から保護する条件で、どのようにしてすべての人に無料でソフトウェアに権利を与えるかを見ました。



難解な冗長性と法的方法にもかかわらず、この171語は多くの法的作業を行い、知的財産と契約の密集した茂みを通したオープンソースソフトウェアの道筋を明確にしていることがわかりました。