MITライセンス。 MIT ライセンスと GPL の比較
MIT ライセンスは、オープン ソース ソフトウェアの最も人気のあるライセンスです。 以下は彼女の朗読の 1 つであり、行ごとの分析が含まれています。
ライセンスを読む
あなたがオープンソース開発者で、このライセンスを詳しく読んでいないのであれば、このライセンスは 171 ワードしかありませんが、読むべきです。 特に日常的にライセンスを扱っていない場合はそうです。 理解できないものにはマークを付けてください。 そして、これらすべての言葉を、文脈やコメントとともに、順番に、少しずつ繰り返していきます。 同時に全体を想像することも大切です。
MIT ライセンス (MIT)
著作権許可は、本ソフトウェアおよび関連ドキュメント ファイル (以下「ソフトウェア」) のコピーを入手した人に無償で付与され、使用、コピー、変更、編集する権利を含むがこれらに限定されず、制限なくソフトウェアを取り扱うことができます。以下の条件に従って、ソフトウェアのコピーをマージ、公開、配布、サブライセンス、および/または販売すること、およびソフトウェアが提供される人にそれらを許可すること。
上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは主要部分に含まれるものとします。
ソフトウェアは「現状のまま」提供され、明示的か黙示的かを問わず、商品性、特定目的への適合性、および非侵害の保証を含むがこれらに限定されない、いかなる種類の保証も行われません。 いかなる場合においても、作者または著作権所有者は、契約行為、不法行為、またはその他の行為であるかどうかにかかわらず、ソフトウェアまたはソフトウェアの使用またはその他の取引に起因または関連して生じる、いかなる請求、損害、またはその他の責任に対しても責任を負わないものとします。ソフトウェア。
MITライセンス
著作権<год> <владельцы прав>
このライセンスは、このライセンスのコピーを取得する人に許可します。 ソフトウェアおよび付属のドキュメント (以下「ソフトウェア」といいます) を含む、ソフトウェアのコピーを無制限に使用、コピー、変更、結合、公開、配布、サブライセンスおよび/または販売する権利を含む、制限なくソフトウェアを無料で使用します。また、次の条件に従って本ソフトウェアが提供される人にも適用されます。
ソフトウェアは「現状のまま」提供され、明示的または黙示的を問わず、商品性、特定目的への適合性、および非侵害の保証を含むがこれらに限定されない、いかなる種類の保証も行われません。 いかなる場合においても、作者または著作権所有者は、ソフトウェアの使用またはソフトウェアに関連するその他のことから生じる、契約上、不法行為またはその他によるものを含め、いかなる請求、損害、またはその他の請求に対しても責任を負いません。
ライセンスは 5 つの段落に分かれていますが、論理的には次のように分かれています。
- 見出し
- 名前
- 著作権
- 許可
- 範囲
- 条件
- ライセンスの譲渡
- 保証の否認
- 免責事項
見出し
名前
MITライセンス
「MIT ライセンス」は 1 つのライセンスではなく、マサチューセッツ工科大学が製造する製品に採用されているスタイルの影響を受けた一連のライセンス形式です。 最初にそれを使用したプロジェクトでも、他のプロジェクトのモデルとしても、長年にわたって頻繁に変更されてきました。 Fedora プロジェクトは、興味深いライセンス オプションのアーカイブを維持しており、ライセンス オプションが保存されています。 平文でまるでホルムアルデヒドの解剖学的驚異のように、進化の過程を示しています。
幸いなことに、オープンソースの取り組みは オープンソース Initiative と Software Package Data eXchange グループは、MIT ライセンスの一般的な形式を標準化し、それを「MIT ライセンス」と呼びました。 OSI は共通ライセンスに文字列識別子を採用しました オープンソース SPDX からのものであり、MIT という略語は明らかに「MIT ライセンス」を意味します。 MIT 条件に基づいて製品を配布する必要がある場合は、標準の MIT ライセンス フォームを使用してください。
ただし、LICENSE ファイルに「The MIT License」または「SPDX:MIT」という行を含めたとしても、念のため、責任ある読者がテキストを標準形式と照合してチェックします。 多くの異なる形式のライセンスが自らを「MIT ライセンス」と呼んでいますが、詳細は異なります。また、「MIT ライセンス」の概念があまりにも曖昧であるため、多くの作成者がテキストに独自のひねりを加えたいという誘惑に駆られてきました。 このようなひどい、ひどい、嫌な変更の典型的な例は、MIT ライセンスに「プログラムは悪い目的ではなく、良い目的で使用しなければならない」を追加する JSON ライセンスです。 このトリックはまさにクロックフォードの精神に基づいています。 ひどい頭痛。 弁護士を揶揄しているのかもしれない。 彼らは銀行までずっと笑いました。
教訓は、単に「MIT ライセンス」と書くだけでは曖昧だということです。 通常、人々はあなたが何を意味するのか理解するでしょうが、MIT 標準ライセンスのテキストをプロジェクトにコピーすることで、全員と自分自身の時間を節約するだけです。
著作権
著作権<год> <владельцы прав>
1976 年の著作権法が米国で制定される前は、著作権の存続を確保するために特別な手順「形式要件」が必要でした。 そして、それらに従わなかった場合、自分の作品の違法使用に対して訴訟を起こす権利は制限され、場合によっては消滅することもありました。 正式な要件の 1 つは、いわゆるものでした。 「通知」: 作品にマークを付けること、および権利の主張を市場に通知するために必要なその他の行為。 アイコンはこのための標準シンボルです。 ASCII にはそのようなアイコンがなかったため、同じ目的で組み合わせが使用されました。
1976 年の著作権法により、手続きの必要性がなくなりました。 米国では、権利所有者は依然として法的手続きの前に作品を登録する必要がありますが、実際にはこれは裁判所自体で直接行われます。 単に宣言、登録、米国議会図書館へのコピーの送付などを忘れただけであれば、著作権を失うことはありません。
ただし、これらのステートメントが不要になったとしても、依然として非常に便利です。 特定の作品が作成された年とその権利を示すことで、これらの権利がいつ期限切れになり、作品がパブリック ドメインになるかがすぐにわかります。 著者の身元情報も役に立ちます。米国では、法律によって個人の著者と著者のグループが異なって扱われます。 ビジネスにおいて、企業は、たとえライセンスで許可されているとしても、ライバルのソフトウェアを使用する前によく考えます。 他の人が自分の作品に注目してライセンスを取得したい場合は、著作権者に関する情報も役に立ちます。
すべてのライセンスに著作権所有者の立場が存在するわけではありません。 Apache 2.0 や GPL 3.0 などの最新のライセンスでは、LICENSE テキストが公開されており、それをそのままコピーし、コメントやコメントにコピーする必要があります。 個別のファイルすでに作品の所有者を示しています。 このアプローチにより、ライセンス テキストへの変更が不要になり、自動処理が簡素化されます。
MIT ライセンスは、さまざまな機関によって実行されるコード リリースから得られます。 このようなリリースの場合、権利の所有者はコードをリリースした研究所のみでした。 他の機関はこれらのライセンスを採用し、MIT を独自の名前に置き換え、汎用ライセンスが存在するようになりました。 他のライセンスもこのプロセスを経ています。たとえば、カリフォルニア大学の BSD ライセンス (当初は 4 条項ライセンスでしたが、現在は 3 条項および 2 条項の変形で使用されています) や、インターネット システム コンソーシアムの ISC ライセンスなどです。 MITライセンスの一種。
いずれの場合も、組織は自らが権利の所有者であることを明らかにし、従業員や請負業者が行う作業に対する権利を保持できる「雇用労働」機能を利用しました。 これらの規則は通常、従業員や請負業者が自主的に行う作業には適用されません。 また、コードをボランティアで共同作業する人々の分散グループにも適用されません。 Apache Foundation や Eclipse Foundation など、さまざまなソースからコードを受け入れるプロジェクトを管理する財団にとって、これは問題となります。 ファンドは通常、単一の権利所有者 (Apache CLA と Eclipse CLA) を主張するハウス ライセンスを使用して資金提供者から権利を取得することで、この問題に対処してきました。 権利を 1 か所に収集することは、フリー ソフトウェアの価値を広める責任を著作権所有者に移す GPL など、あらゆる種類の「コピーレフト」ライセンスにとってさらに重要です。
現在、複数のコード ベンダーを管理していないプロジェクトであっても、多くのプロジェクトが MIT ライセンスを使用しています。 SPDX と OSI は、権利を保有する特定の個人やグループに言及しないライセンス形式を標準化することでこれに貢献しました。 その結果、ほとんどの著者は著作権表示に自分の名前を書くだけで、場合によっては年も含めます。
コードの元の所有者は、その作品に対する権利を保持します。 しかし、MIT のようなライセンスは、ソフトウェアを構築したり変更したりして、いわゆる「派生作品」を作成する権利を他人に与えますが、オリジナルの作成者に他人が作成したものを所有する権利を与えません。 貢献した人は全員、既存のコードに基づいて実行された作業の一部に対する権利を保持します。
ほとんどのプロジェクトは、参加者にライセンスへの同意を求めることをわざわざしませんし、ましてや権利の分配に関する文書に署名することはありません。 これは素朴ですが、理解できます。 開発者は、GitHub にプル リクエストを送信すると、ライセンスの記載に従ってプロジェクトを配布する特定の権利を自動的に取得できると想定していますが、米国にはそのような規則はありません。 デフォルトでは、ライセンス転送許可ではなく著作権保護が設定されています。
合法化され文書化された権利譲渡と書類手続きの不在との間のギャップを埋めるために、一部のプロジェクトでは、開発者が Signed-Off-By メタ タグを使用して参照する標準的なステートメントである開発者の原産地証明書を受け入れます。DCO は、Linux カーネルを開発するために設計されました。 DCO は、SCO が所有する Unix カーネルから発展したもので、Linux の各ラインがそれに貢献した人々によって誕生したプロセスをうまく文書化しています。また、それはライセンスではありませんが、多くの利点を提供します。プロジェクトにコードを提出した人は、コードがプロジェクトとともに配布されること、およびユーザーが既存のカーネル ライセンスに基づいてコードを使用することを意図していたことがわかります。また、カーネルでは、すべてをリストした人間が読める CREDITS ファイルが維持されます。貢献した人々、名前、メンバーシップ、貢献分野、その他のデータ。
許可
このライセンスは、このソフトウェアおよび付属ドキュメント (以下「ソフトウェア」といいます) のコピーを入手した人に、以下のことを許可します。
MIT ライセンスのポイントは、ご想像のとおり、それがライセンスであるということです。 一般に、ライセンスは 1 人の個人または 実在物– ライセンサー – 別の – ライセンシー – が、法廷で異議を申し立てられる可能性のある行為を行うことを許可します。 MITライセンスは訴訟を起こさないという約束です。
場合によっては、法律によってライセンスとライセンスの譲渡における約束が分離されることがあります。 誰かがあなたにライセンスを与えるという約束を破った場合、約束を破ったとして訴訟を起こすことはできますが、ライセンスを取得できない可能性があります。 この文では [ 英語版では、これは古風な「hereby」を使用して行われます。 翻訳] は、このライセンスの本文自体がすでにライセンスを付与しており、単にライセンスを譲渡することを約束するものではないことを明確にしています。
また、多くのライセンスは特定の名前付きライセンスに対して許可を与えますが、MIT ライセンスは「パブリック ライセンス」です。 公的ライセンス全員に許可を与える、つまり – 社会へ。 これは、オープンソース ライセンスの背後にある 3 つの優れたアイデアの 1 つです。 MIT ライセンスはこの考えを利用して、「ソフトウェアのコピーを入手した人」全員にライセンスを提供します。
括弧と引用符で囲まれた概念の指定 (「定義」) – 標準的な方法条件を与える 一定の値法的文書の中で。 当事者は法廷手続きにおいてこれらの規約を使用することができます。
範囲
ソフトウェアを制限なく無料で使用します。
これらの単語は、ライセンシーの観点から見ると、MIT ライセンスのすべての単語の中で最も重要です。 権利に関する主な問題は、著作権侵害や特許侵害で起訴される可能性があることです。 これらの法律分野では「自由使用」という言葉は使用されていません。 その結果、裁判所は必然的にこの定義が何を意味するのかを尋ねることになります。 裁判所は、この説明が意図的に広範すぎ、無制限であると認定するでしょう。 これにより、ライセンシーは、ソフトウェアの特定の使用について許可を与えていないというライセンサーの主張に抵抗することができます。
これには、ソフトウェアのコピーを使用、コピー、変更、マージ、公開、配布、サブライセンスおよび/または販売する無制限の権利、およびソフトウェアが提供される人物が含まれます。
完全に曖昧さのない、または完全に理解できる完璧な法文は存在しません。 誰かが違うことを言っても信じないでください。 ライセンスのこの部分は最も高度ではありません。
まず、「無制限の権利を含む」は、法文を書かない例です。 この定式化にはバリエーションがあります。
以下を含みますがこれに限定されません。
上記の一般化を含みますが、これに限定されません。
含むがこれらに限定されません;その他。
それらはすべて 1 つの目的のために書かれており、どれもそれを達成しません。 魚を利用する弁護士らは、座礁したくないので魚を食べたいと考えている。 MIT ライセンスでは、これらは「ソフトウェアの使用」の特定の例 (「使用、コピー、変更」など) を提供する試みを意味しますが、ソフトウェアがリストされた方法の 1 つでのみ使用できることを意味するものではありません。 問題は、そのようなライセンスが法廷に提示された場合、裁判所はライセンスを理解するためにこれらの用語の意味を判断する必要があることです。 裁判所が「ソフトウェアを使用する」ということが何を意味するかを理解したいとしても、ライセンスに指定されている使用例を「見る」ことはできません。 ライセンスには「ソフトウェアを制限なく使用する」と書くのがベストだと思います。 それも短いです。
第二に、リストされている用語はごちゃ混ぜです。 これらの中には、著作権法および特許法で保護されているものとそうでないものがあります。
使用アメリカ合衆国法典第 35 条第 271 項 (a) に記載されており、後者が特許権者の許可なしに訴訟を起こすことができるもののリストに含まれています。
コピー著作権法のリストの第 17 条、第 106 項に記載されています。
変更、公開、マージ著作権法にも特許法にも記載されていません。
配布する著作権法に記載されています。
サブライセンス知的財産法の総称です。 これは、他人が自分のライセンスを部分的または部分的に譲渡する権利を意味します。 完全なリストあなたが彼らにやらせていること。 この条項はオープン ライセンスでは異例です。 通常のアプローチは直接的で、ソフトウェアのコピーを受け取る全員が所有者から直接ライセンスを受け取ります。
売る- この言葉はハイブリッドです。 特許法でいう販売と似ていますが、著作権法と同様にコピーの販売を指します。 著作権用語では「頒布」に近いですが、著作権法では販売については触れられていません。
本ソフトウェアの提供を受ける者だけでなく、– このフレーズは「サブライセンス」を不必要に繰り返すように思えます。 また、ソフトウェアのコピーを受け取った人が直ちにライセンスを受け取る限り、これは必要ありません。最後に、法律、製造、知的財産、共通言語が混在しているため、MIT ライセンスに特許許可が含まれているかどうかは不明です。 「使用」は特許を暗示していますが、あまり明確ではありません。 ライセンスが、ソフトウェアに対する特許権を持っている場合も持っていない場合もある著作権所有者からのものであるという事実、および使用されている動詞の例のほとんどとソフトウェア自体の定義は、著作権ライセンスを示しています。 Apache 2.0 などの新しいライセンスでは、著作権、特許、さらには商標についても具体的かつ明示的に言及しています。
3つのライセンス条件
以下の条件に従います
常に落とし穴があります。MIT にも落とし穴が 3 つあります。
条件をお守りいただけない場合は許可が得られません。 したがって、理論的には、この場合、おそらく著作権法に基づいて訴えられる可能性があります。
ライセンス料を支払わなかった場合でも、ソフトウェアの価値を利用してライセンシーに準拠するよう動機付けることは、オープンソース ソフトウェアの 2 番目の優れたアイデアです。 後者は、MIT ライセンスには含まれていませんでしたが、ライセンス条件に基づいています。GNU Public License のようなライセンスでは、変更者がライセンスを取得し、変更されたバージョンを配布する方法を制御するために条件が使用されます。
ライセンスの譲渡
ソフトウェアのコピーを誰かに渡す場合は、そのコピーにライセンス テキストを含める必要があり、著作権表示を追加することができます。 これにはいくつかの目的があります。
1. パブリック ライセンス ソフトウェアに対する権限を持っていることを他の人に伝えます。 これ 主要な機能直接ライセンス モデル。各ユーザーは権利所有者から直接ライセンスを受け取ります。
2. ソフトウェアの作者についてのアイデアを提供するため、誰に賞賛、名声、寄付が浴びせられる必要があるかが明確になります。
3. 保証の否認と責任の制限を規定します。コピーを配布するためにお金を請求したり、ソースコードなしでコンパイルされた形式でコピーを作成したりすることを誰も止めません。 ただしこの場合、コードが自分のものであるか、または他のライセンスの下にあると偽ることはできません。 製品の受信者は、自分の「パブリック ライセンス」権利を認識する必要があります。
残念ながら、これらの条件はほとんど満たされていません。 ほぼすべてのオープンソース ライセンスにはそのような条件があります。 システムおよびインストール可能なソフトウェアの作成者は、ライセンス情報を含むファイルを画面に表示し、ライセンスのコピーをライブラリやコンポーネントに含める必要があることに気づくことがよくあります。 プロジェクトを管理する基金は、これらの実践を教えています。 しかし、ウェブ開発者には通知されていなかったようだ。 彼らには許しがありません。
保証の否認
ソフトウェアは「現状のまま」提供され、明示的または黙示的を問わず、商品性、特定目的への適合性、および非侵害の保証を含むがこれらに限定されない、いかなる種類の保証も行われません。
米国のほぼすべての州は、商取引を管理する一連の法律である統一商法に従うことが法律で義務付けられています。 UCC の第 2 条は、オークションで購入した中古車から工場への工業薬品の供給に至るまで、物品の販売に関する契約を扱います。
特定の UCC ルールは必須であり、常に適用されます。 売り手と買い手が契約書に別のことを書かない限り、「デフォルト」状態のみを説明するものもあります。 これらの「デフォルト」ルールの中には、保証、つまり製品の品質と使用に対する適合性に関する売り手から買い手への約束があります。
MIT のような公的ライセンスが契約、つまりライセンシーとライセンサーに強制できる契約であるのか、それとも単に条件を付すことができるライセンスなのかについては議論があります。 ソフトウェアが製品であるかどうか、したがって UCC の管轄の対象となるかどうかについては、あまり議論がありません。 しかし、ライセンサーは責任については異論を認めません。配布したソフトウェアが壊れたり、問題を引き起こしたり、動作しなかったり、その他の形でマイナスに現れた場合に訴訟を起こされることを誰も望んでいません。 これは、次の 3 つのデフォルト保証ルールで説明されている内容とはまったく逆です。
1. セクション 2-314 によると、商品性とは、製品 (ソフトウェア) が少なくとも平均的な品質であり、適切にパッケージ化され、ラベルが貼られていて、通常の使用に適していることを約束するものです。 この規則は、ソフトウェア ディーラー、つまりソフトウェアを販売し、自らをこの分野の専門家であると考えている業者にのみ適用されます。
2. セクション 2-315 で定義されている特定の目的への適合性は、商品が特定の目的に適合することを買い手が期待していることを売り手が知っている場合に適用されます。
3. 特許上の障害がない - UCC には含まれていませんが、契約法で一般的に使用されています。 購入した製品が他人の知的権利を侵害していることが判明した場合に、購入者を保護します。セクション 2-316(3) では、これらの保証を除外するライセンス文言を、目立つ方法で、つまり、細かい文字で隠すのではなく、注意を喚起することによって行うことを義務付けています。 最後のページ契約。 州法では、特許障壁がないことの宣言にも同様のことが求められる場合があります。
弁護士は長い間、文章を大文字で書くことで目立ちやすさの要件を満たしていると誤解してきました。 これは間違っています。 大文字多くの場合、読者の注意を引く代わりに反発してしまいます。 しかし、ほとんどのオープンソース ライセンスでは、この部分が大文字で書かれています。 明白な方法文章をシンプルにする テキストファイル目立つ。 アスタリスクやその他の ASCII アートを使用したかったのですが、その電車はすでに出発してしまいました。
免責事項
いかなる場合においても、作者または著作権所有者は、ソフトウェアの使用またはソフトウェアに関連するその他のことから生じる、契約上、不法行為またはその他によるものを含め、いかなる請求、損害、またはその他の請求に対しても責任を負いません。
MIT ライセンスはソフトウェアを無料で配布しますが、法律は、ソフトウェアを受け取った人がソフトウェアを無償で配布することを意味するものではありません。 無料ライセンス何か問題が発生し、ライセンサーが有罪となった場合、人々は裁判を受ける権利を失います。 ライセンスと同様、責任の制限も法廷に行かないという約束として機能します。この場合に限り、ライセンサーをライセンシーから保護します。
通常、裁判所は保証の免責条項を注意深く読みます。これは、一方の当事者から他方の当事者にリスクを移転するのに役立つ可能性があるためです。 あらゆる事態において国民に自らを守る機会を与えること 考えられるケース裁判所は、これらの権利放棄を保護対象者に対して不利に解釈します。 そのような条件が契約書の奥深くにあり、強調されていない場合、裁判所はそれらの条件を考慮することを拒否することがよくあります。 したがって、弁護士は大文字で書くことに慣れています。
責任の制限などにより、ライセンシーが訴訟を起こされる金額も制限されます。 オープン ライセンスの場合、この制限は常にゼロです。 商用ライセンスには、過去 12 か月間に支払ったライセンス料金の倍数の金額が含まれることがよくあります。
このセクションでは、ライセンサーが使用できない種類の法的追求をリストします。 多くの法的形式と同様に、このライセンスには契約違反と不法行為について言及されています。 不法行為の規則は、損害賠償を引き起こす行為の実行を指します。 メール送信中に道路で人を轢いた場合、不法行為を犯したことになります。 あなたの会社が人の耳を火傷するような欠陥のあるヘッドフォンを販売した場合、その会社は不法行為を犯したことになります。 契約書が不法行為の請求を明示的に排除していない場合、裁判所はそれを利用することがあります。 MIT ライセンスには、特殊な要件を除外するために「他の要件による」と記載されています。
フレーズ " ソフトウェアの使用またはソフトウェアを使用したその他の行為から生じる「」は、弁護士が自分の安全に対する後天的な恐怖の特徴である神経質なチックです。重要なのは、このソフトウェアに関連するあらゆる請求は制限と例外によってカバーされるということです。ただし、ソフトウェアの使用は、ソフトウェアの「その他の行為」に完全に含まれます。 。[ 元のライセンスでは、イベントの「発生」、「に関連して」、「使用」の 3 つのオプションが指定されています。つまり、「から発生」、「に関連して」、および「使用時」ですが、実際には相互に重複しています。 、これは記事の著者からの苦情を引き起こします-約。 翻訳] しかし、そのような文言は他の何百万ものライセンスで使用されています。
結論
しかし、これらの主張はどれも大したものではありません。 MIT ライセンスは法律上の古典です。 彼女が働く。 これは、すべてのソフトウェアの問題、特に特許紛争に対する万能薬ではありません。 しかし、そのようなライセンスは十分に機能しており、最小限の法的ツールで著作権、販売、契約における不都合なデフォルトルールの廃止という特定の目的を果たしています。 コンピュータの話題という文脈で言えば、そのバイタリティは驚くべきものです。 これは、その下でライセンスされていたほとんどのソフトウェアよりも存続しており、今後も存続します。 それが何十年機能し続けるかは推測することしかできません。 これは、弁護士を雇う余裕がない人にとっては特に有益です。
MIT ライセンスは、さまざまな組織によって採用されているライセンスのランダムなバリエーションによる混乱に秩序をもたらす、一連の定義および標準化された定義であることがわかりました。
ライセンサーを保証や責任から保護する条件の下で、ソフトウェアの権利を誰にでも無料で与える仕組みを見ていきました。
少しぎこちない冗長さと法的なマナーにもかかわらず、これらの 171 の単語が大きな目的を達成していることがわかりました。 法務そして、知的財産と契約の密集した藪の中からオープンソース ソフトウェアへの道を切り開きます。
Free Software Foundation によると、MIT は過去に多くのライセンスを使用しており、現在の形式では X Window System 用に作成されているため、このライセンスはより正確には X11 ライセンスと呼ばれています。
MIT ライセンスのソフトウェアには、Expat、Metakit、PuTTY、Bitcoin-Qt、Mono、Ruby on Rails、Twisted、JQuery、Prototype、そしてもちろん、そのソフトウェアが作成された X Window System (X11) が含まれます。
ライセンステキスト
著作権 (c)<год> <владельцы прав>
このライセンスは、ソフトウェアおよび付属ドキュメント (以下「ソフトウェア」といいます) のコピーを入手した人に、無制限の使用、コピー、変更、結合、公開、配布する権利を含む、ソフトウェアの使用を許可します。 、以下の条件に従って、本ソフトウェアのコピーのサブライセンスおよび/または販売、および本ソフトウェアの提供を受ける人への販売は認められません。
ソフトウェアは「現状のまま」提供され、明示的または黙示的を問わず、商品性、特定目的への適合性、および非侵害の保証を含むがこれらに限定されない、いかなる種類の保証も行われません。 いかなる場合においても、作者または著作権所有者は、ソフトウェアの使用またはソフトウェアに関連するその他のことから生じる、契約上、不法行為またはその他によるものを含め、いかなる請求、損害、またはその他の請求に対しても責任を負いません。
原文（英語）
著作権 (c)
本ソフトウェアおよび関連ドキュメント ファイル (以下「ソフトウェア」) のコピーを入手した人には、使用、コピー、変更、マージする権利を含むがこれらに限定されない、制限なくソフトウェアを取り扱う許可が、ここに無償で与えられます。 、以下の条件を条件として、本ソフトウェアのコピーを出版、配布、サブライセンス、および/または販売すること、および本ソフトウェアが提供される人物にそのことを許可すること。
上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは主要部分に含まれるものとします。
ソフトウェアは「現状のまま」提供され、明示的か黙示的かを問わず、商品性、特定目的への適合性、および非侵害の保証を含むがこれらに限定されない、いかなる種類の保証も行われません。 いかなる場合においても、作者または著作権所有者は、契約行為、不法行為、またはその他の行為であるかどうかにかかわらず、ソフトウェアまたはソフトウェアの使用またはその他の取引に起因または関連して生じる、いかなる請求、損害、またはその他の責任に対しても責任を負わないものとします。ソフトウェア。
- （英語） 。 - MIT ライセンス テンプレート。 公式テキスト。 2010 年 7 月 7 日に取得。
ライセンスの使用
同時に、他のグループは製品のデュアル ライセンスを好みます。 たとえば、cURL ライブラリの古いバージョンでは、Mozilla Public License または MIT ライセンスの使用を選択できました。
Free Software Foundation のリストによると、上記の MIT ライセンスは、MIT の名前の下にあまりにも多くのライセンスがあり、別のライセンスとして X11 ライセンスがあるため、より正確には Expat ライセンスと呼ばれます。 ただし、Expat は Expat ライセンスを MIT ライセンスと呼び、X11 ライセンスをまったく持っていませんが、作成者が放棄した同様の X.Net ライセンスを持っています。
他のライセンスとの比較
MIT ライセンスは、3 条項からなる BSD ライセンスに最もよく似ていますが、使用を禁止する条項のみが異なります。 いい名前広告における著作権の所有者。 4 条項 BSD ライセンスにも、次のことを要求する同様の条項が含まれています。 全て販促資料には、MIT ライセンスではなくこのライセンスが表示されます。 後者では、使用、コピー、変更、他のものに組み込む権利など、エンド ユーザーの権利についてもより明確に述べています。 ソース、ライセンスされたソフトウェアの出版、配布、サブライセンスおよび/または販売。
Apple Computer WebCore ライセンス (ただし、ほとんどの WebCore は LGPL に基づいてライセンスされています) のような、2 条項からなる BSD に似たライセンスも、「広告」条項を含まない MIT ライセンスと実質的に同一とみなされます。
このライセンスは学術ライセンスとみなされます。つまり、科学開発の分野での使用に適していると認められます。
記事「MITライセンス」のレビューを書く
ノート
文学
- リチャード・ストールマン、トランス。 セルゲイ・コロップ。(1999 年 6 月 10 日)。 2010 年 7 月 7 日に取得。
- リチャード・ストールマン。（英語） 。 各種ライセンス とコメント彼らについて. .
- アンドリュー・M・セント ローラン。。 - 2004年。 - 207ページ。
リンク
- パブロフ M.(ロシア語) 。 LicenseIt.ru。 - ロシア語でのライセンスの説明とテキスト。 2010 年 7 月 7 日に取得。
|
||||||||||||||||||||||||||||||
MIT ライセンスの説明の抜粋
「法廷のあるところに真実はありません」と小男が口を挟んだ。- ここには、どのくらいの期間いますか？ – 最後のジャガイモを噛みながらピエールが尋ねた。
- それは私ですか？ その日曜日、彼らは私をモスクワの病院から連れて行きました。
-兵士よ、あなたは誰ですか？
- アブシェロン連隊の兵士。 彼は熱で死にかけていた。 彼らは私たちに何も言いませんでした。 私たち約20人がそこに横たわっていました。 そして彼らは考えもせず、推測もしませんでした。
- さて、ここでは退屈ですか？ ピエールは尋ねた。
- 退屈じゃないよ、ハヤブサ。 プラトンと呼んでください。 「カラタエフのニックネーム」と彼は付け加えたが、これは明らかにピエールが彼に呼びかけやすいようにするためだった。 - 奉仕では彼をファルコンと呼んでいました。 退屈しないようにね、ハヤブサ！ モスクワ、彼女は都市の母です。 これを見て退屈しない方法。 はい、虫はキャベツをかじりますが、その前にあなたは消えてしまいます。老人たちがよく言っていたことです」と彼はすぐに付け加えた。
- どうやって、どうやって言いましたか？ ピエールは尋ねた。
- それは私ですか？ –カラタエフは尋ねた。 「私は言います。私たちの心ではなく、神の判断によるのです」と彼は言い、自分が言われたことを繰り返していると思った。 そして彼はすぐにこう続けました。「ご主人様、どうして領地をお持ちなのですか？」 そして家はありますか？ したがって、カップはいっぱいです！ そしてホステスはいますか？ あなたの年老いた両親はまだ生きていますか？ ピエールは暗闇で何も見えなかったが、これを尋ねている間、兵士の唇が愛情の抑制された微笑でしわを寄せているのを感じた。 彼はピエールに両親、特に母親がいないことに腹を立てていたようだ。
「妻は相談役、義母は挨拶役、自分の母親ほど大切なものはない！」 - 彼は言った。 - それで、子供はいますか？ ――彼は続けて尋ねた。 ピエールの否定的な答えが再び彼を動揺させたようで、彼は急いでこう付け加えた。 議会に住めたらなぁ…
「今は関係ないよ」とピエールは思わず言った。
「ええと、あなたは大切な人ですね」とプラトンは反論した。 - お金や刑務所を決して放棄しないでください。 「彼はよく座り、咳払いをし、長い話の準備をしているようだった。 「それで、親愛なる友人、私はまだ家に住んでいたのです」と彼は始めた。 「私たちの財産は豊かで、土地もたくさんあり、人々は元気に暮らしており、私たちの家もあります、神に感謝します。」 司祭自ら草刈りに出掛けた。 私たちは元気に暮らしていました。 彼らは本物のクリスチャンでした。 それは起こりました... - そして、プラトン・カラタエフは、どのようにして森の裏にある他人の木立に行って警備員に捕らえられたか、どのように鞭打たれ、裁判にかけられ、兵士に引き渡されたかについて長い話をしました。 「そうですね、ハヤブサは」と笑顔で声を変えながら言った、「彼らは悲しみを考えていたのに、喜びを感じたのです！」 私の罪がなかったら、私の兄弟は行くべきです。 そして弟には 5 人の男の子がいます - そしてほら、私には兵士が 1 人しか残っていないのです。 女の子がいましたが、彼女が兵士になる前から神は彼女の面倒を見ていました。 休暇を取って来たので、教えておきます。 彼らが以前よりも良く暮らしているのが分かります。 庭はお腹でいっぱいで、女性たちは家にいて、二人の兄弟は仕事中です。 家にいるのは末っ子のミハイロだけ。 父親はこう言います。「子供たちは皆、私と平等です。どの指を噛んでも、すべてが痛いのです。」 あのときプラトンの髭が剃られていなかったら、ミハイルは去っていただろう。」 彼は私たち全員に電話をかけました - 信じてください - 彼は私たちを像の前に置きました。 ミハイロは、ここに来て彼の足元に礼をしなさい、そうすれば女性であるあなたも礼をし、そしてあなたの孫たちも礼をします、と彼は言います。 わかった？ 話す。 それで、親愛なる友人。 ロックは頭を探しています。 そして、私たちはすべてを判断します。それは良くないこともあれば、大丈夫ではないこともあります。 友人よ、私たちの幸福は錯乱した水のようなものです。引っ張れば膨らみますが、引き抜いても何もありません。 となることによって。 - そしてプラトンはわらの上に座った。
しばらく沈黙した後、プラトンは立ち上がった。
- お茶があるから寝ますか？ -彼はそう言ってすぐに自分自身を交差させ始め、こう言いました。
- 主イエス・キリスト、聖者ニコラ、フローラとラヴラ、主イエス・キリスト、聖者ニコラ！ フロルとラヴラ、主イエス・キリストよ、憐れんで私たちを救ってください！ -彼はそう結論付け、地面に頭を下げ、立ち上がり、ため息をつきながらわらの上に座った。 - それでおしまい。 「神よ、小石のようにそれを下ろし、ボールのように持ち上げてください」と言って、彼はグレートコートを引っ張りながら横になりました。
-どんな祈りを読んでいましたか？ ピエールは尋ねた。
- お尻？ - プラトンは言いました（彼はすでに眠りに落ちていました）。 - 何を読みますか？ 私は神に祈りました。 祈ったこともありませんか？
「いいえ、私は祈ります」とピエールは言った。 - でも、フロルとラブラって何て言いましたか？
「しかし、どうでしょうか」プラトンはすぐに答えました、「馬の祭りです」。 そして私たちは家畜たちに同情しなければなりません」とカラタエフさんは語った。 - ほら、悪党が丸まってるよ。 暖かくなった、雌犬の息子だ」と彼は足元に犬の気配を感じながら言い、再び振り返ってすぐに眠りに落ちた。
外では、遠くのどこかで泣き声と悲鳴が聞こえ、ブースの隙間から火が見えました。 しかしブースの中は静かで暗かった。 ピエールは長い間眠らず、目を開けて暗闇の中でその場所に横たわり、隣に横たわるプラトンの測定されたいびきを聞いて、以前に破壊された世界が今彼の魂の中で構築されているのを感じました新しい美しさ、そして新しく揺るぎない基盤の上に。
ピエールが入って4週間滞在したブースには、捕虜となった兵士23名、士官3名、役人2名がいた。
そのとき、彼ら全員が霧の中のようにピエールに現れましたが、プラトン・カラタエフは、最も強く最愛の思い出であり、ロシアのすべてのもの、親切で丸いものの擬人化としてピエールの魂に永遠に残りました。 翌日の夜明け、ピエールが隣人を見たとき、何か丸いという第一印象が完全に裏付けられた。ロープでベルトを締めたフランス製の外套を着て、帽子と靭皮靴を履いたプラトンの姿は全体的に丸く、頭は丸かった。完全に丸くて、背中、胸、肩、そしていつも何かを抱きしめているかのように抱えている手さえも丸かった。 心地よい笑顔と大きな茶色の優しい瞳が丸かった。
プラトン・カラタエフは、長年軍人として参加した作戦についての話から判断すると、50歳を超えていたに違いない。 彼自身は自分が何歳なのか全く知りませんでしたし、判断することもできませんでした。 しかし、彼の歯は白くて丈夫で、笑うと（彼はよくそうしていた）二つの半円を描き続け、すべて良好で無傷だった。 ひげにも髪にも白髪は一本もなく、全身が柔軟性、特に硬さと耐久力を備えているように見えました。
彼の顔には、小さな丸いしわがあるにもかかわらず、無邪気で若々しい表情がありました。 彼の声は心地よくてメロディアスだった。 しかし 主な特徴彼のスピーチは自発性と議論で構成されていました。 彼は明らかに、自分が何を言ったのか、何を言うのかなど考えたこともなかった。 そのため、彼のイントネーションのスピードと忠実さには、抗いがたい特別な説得力がありました。
彼の体力と敏捷性は、最初の捕虜の間では疲労と病気が何であるかを理解していないように見えたほどでした。 毎日、朝と夕方、横になるとき、彼はこう言いました。「主よ、小石のようにそれを置き、ボールに持ち上げてください」。 朝起きて、いつも同じように肩をすくめながら、彼はこう言った。「横になって丸まって、起き上がって体を震わせた。」 そして実際、彼は横になるとすぐに石のように眠りに落ち、体を震わせるとすぐに、一秒も間を置かずにすぐに、子供のように立ち上がっておもちゃを手に取るように、何かの仕事に取り掛かりました。 。 彼はすべてのやり方を知っていましたが、あまり上手ではありませんでしたが、下手でもありませんでした。 彼は焼いたり、蒸したり、縫ったり、かんなをかけたり、ブーツを作ったりしました。 彼はいつも忙しく、大好きな会話や歌を許されるのは夜だけでした。 彼は、歌を聴いていることを知っているソングライターが歌うようにではなく、鳥が歌うように歌を歌いました。 そしてそれらの音はいつも繊細で、優しく、ほとんど女性的で、悲しげで、同時に彼の顔はとても真剣でした。
SLY_G 2016 年 9 月 25 日、午後 7 時 24 分
MIT ライセンスの行ごとの分析
- IT 分野の法規制
- 翻訳
プログラマが理解しておくべき171の単語
MIT ライセンスは、オープン ソース ソフトウェアの最も人気のあるライセンスです。 以下は彼女の朗読の 1 つであり、行ごとの分析が含まれています。ライセンスを読む
あなたがオープンソース開発者で、このライセンスを詳しく読んでいないのであれば、このライセンスは 171 ワードしかありませんが、読むべきです。 特に日常的にライセンスを扱っていない場合はそうです。 理解できないものにはマークを付けてください。 そして、これらすべての言葉を、文脈やコメントとともに、順番に、少しずつ繰り返していきます。 同時に全体を想像することも大切です。MIT ライセンス (MIT)著作権「年」「著作権者」
本ソフトウェアおよび関連ドキュメント ファイル (以下「ソフトウェア」) のコピーを入手した人には、使用、コピー、変更、マージする権利を含むがこれらに限定されない、制限なくソフトウェアを取り扱う許可が、ここに無償で与えられます。 、以下の条件を条件として、本ソフトウェアのコピーを出版、配布、サブライセンス、および/または販売すること、および本ソフトウェアが提供される人物にそれを許可すること。
上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは主要部分に含まれるものとします。
ソフトウェアは「現状のまま」提供され、明示的か黙示的かを問わず、商品性、特定目的への適合性、および非侵害の保証を含むがこれらに限定されない、いかなる種類の保証も行われません。 いかなる場合においても、作者または著作権所有者は、契約行為、不法行為、またはその他の行為であるかどうかにかかわらず、ソフトウェアまたはソフトウェアの使用またはその他の取引に起因または関連して生じる、いかなる請求、損害、またはその他の責任に対しても責任を負わないものとします。ソフトウェア。
MITライセンス著作権「年」「権利者」
このライセンスは、ソフトウェアおよび付属ドキュメント (以下「ソフトウェア」といいます) のコピーを入手した人に、無制限の使用、コピー、変更、結合、公開、配布する権利を含む、ソフトウェアの使用を許可します。 、以下の条件に従って、本ソフトウェアのコピーのサブライセンスおよび/または販売、および本ソフトウェアの提供を受ける人への販売は認められません。
ソフトウェアは「現状のまま」提供され、明示的または黙示的を問わず、商品性、特定目的への適合性、および非侵害の保証を含むがこれらに限定されない、いかなる種類の保証も行われません。 いかなる場合においても、作者または著作権所有者は、ソフトウェアの使用またはソフトウェアに関連するその他のことから生じる、契約上、不法行為またはその他によるものを含め、いかなる請求、損害、またはその他の請求に対しても責任を負いません。
ライセンスは 5 つの段落に分かれていますが、論理的には次のように分かれています。
- 見出し
- 名前
- 著作権
- 許可
- 範囲
- 条件
- ライセンスの譲渡
- 保証の否認
- 免責事項
見出し
名前
「MIT ライセンス」は 1 つのライセンスではなく、マサチューセッツ工科大学が製造する製品に採用されているスタイルの影響を受けた一連のライセンス形式です。 最初にそれを使用したプロジェクトでも、他のプロジェクトのモデルとしても、長年にわたって頻繁に変更されてきました。 Fedora プロジェクトは、興味深いライセンス オプションのアーカイブを維持しています。ライセンス オプションは、ホルムアルデヒドの解剖学的珍品のように、プレーン テキストで保存されており、進化の進歩を示しています。
幸いなことに、Open Source Initiative と Software Package Data eXchange グループは MIT ライセンスの一般的な形式を標準化し、それを「MIT ライセンス」と呼んでいます。 OSI は SPDX から一般的なオープン ソース ライセンスの文字列識別子を採用しており、頭字語 MIT は明示的に「MIT ライセンス」を暗示しています。 MIT 条件に基づいて製品を配布する必要がある場合は、標準の MIT ライセンス フォームを使用してください。
ただし、LICENSE ファイルに「The MIT License」または「SPDX:MIT」という行を含めたとしても、念のため、責任ある読者がテキストを標準形式と照合してチェックします。 多くの異なる形式のライセンスが自らを「MIT ライセンス」と呼んでいますが、詳細は異なります。また、「MIT ライセンス」の概念があまりにも曖昧であるため、多くの作成者がテキストに独自のひねりを加えたいという誘惑に駆られてきました。 このようなひどい、ひどい、嫌な変更の典型的な例は、MIT ライセンスに「プログラムは悪い目的ではなく、良い目的で使用しなければならない」を追加する JSON ライセンスです。 このトリックはまさにクロックフォードの精神に基づいています。 ひどい頭痛。 弁護士を揶揄しているのかもしれない。 彼らは銀行までずっと笑いました。
教訓は、単に「MIT ライセンス」と書くだけでは曖昧だということです。 通常、人々はあなたが何を意味するのか理解するでしょうが、MIT 標準ライセンスのテキストをプロジェクトにコピーすることで、全員と自分自身の時間を節約するだけです。
著作権
著作権<год> <владельцы прав>
1976 年の著作権法が米国で制定される前は、著作権の存続を確保するために特別な手順「形式要件」が必要でした。 そして、それらに従わなかった場合、自分の作品の違法使用に対して訴訟を起こす権利は制限され、場合によっては消滅することもありました。 正式な要件の 1 つは、いわゆるものでした。 「通知」: 作品にマークを付けること、および権利の主張を市場に通知するために必要なその他の行為。 アイコンはこのための標準シンボルです。 ASCII にはそのようなアイコンがなかったため、同じ目的で組み合わせが使用されました。
1976 年の著作権法により、手続きの必要性がなくなりました。 米国では、権利所有者は依然として法的手続きの前に作品を登録する必要がありますが、実際にはこれは裁判所自体で直接行われます。 単に宣言、登録、米国議会図書館へのコピーの送付などを忘れただけであれば、著作権を失うことはありません。
ただし、これらのステートメントが不要になったとしても、依然として非常に便利です。 特定の作品が作成された年とその権利を示すことで、これらの権利がいつ期限切れになり、作品がパブリック ドメインになるかがすぐにわかります。 著者の身元情報も役に立ちます。米国では、法律によって個人の著者と著者のグループが異なって扱われます。 ビジネスにおいて、企業は、たとえライセンスで許可されているとしても、ライバルのソフトウェアを使用する前によく考えます。 他の人が自分の作品に注目してライセンスを取得したい場合は、著作権者に関する情報も役に立ちます。
すべてのライセンスに著作権所有者の立場が存在するわけではありません。 Apache 2.0 や GPL 3.0 などの最新のライセンスでは、LICENSE テキストが公開されており、それをそのままコピーする必要があり、その後、作品の所有者をコメントや別のファイルで示す必要があります。 このアプローチにより、ライセンス テキストへの変更が不要になり、自動処理が簡素化されます。
MIT ライセンスは、さまざまな機関によって実行されるコード リリースから得られます。 このようなリリースの場合、権利の所有者はコードをリリースした研究所のみでした。 他の機関はこれらのライセンスを採用し、MIT を独自の名前に置き換え、汎用ライセンスが存在するようになりました。 他のライセンスもこのプロセスを経ています。たとえば、カリフォルニア大学の BSD ライセンス (当初は 4 条項ライセンスでしたが、現在は 3 条項および 2 条項の変形で使用されています) や、インターネット システム コンソーシアムの ISC ライセンスなどです。 MITライセンスの一種。
いずれの場合も、組織は自らが権利の所有者であることを明らかにし、従業員や請負業者が行う作業に対する権利を保持できる「雇用労働」機能を利用しました。 これらの規則は通常、従業員や請負業者が自主的に行う作業には適用されません。 また、コードをボランティアで共同作業する人々の分散グループにも適用されません。 Apache Foundation や Eclipse Foundation など、さまざまなソースからコードを受け入れるプロジェクトを管理する財団にとって、これは問題となります。 ファンドは通常、単一の権利所有者 (Apache CLA と Eclipse CLA) を主張するハウス ライセンスを使用して資金提供者から権利を取得することで、この問題に対処してきました。 権利を 1 か所に収集することは、フリー ソフトウェアの価値を広める責任を著作権所有者に移す GPL など、あらゆる種類の「コピーレフト」ライセンスにとってさらに重要です。
現在、複数のコード ベンダーを管理していないプロジェクトであっても、多くのプロジェクトが MIT ライセンスを使用しています。 SPDX と OSI は、権利を保有する特定の個人やグループに言及しないライセンス形式を標準化することでこれに貢献しました。 その結果、ほとんどの著者は著作権表示に自分の名前を書くだけで、場合によっては年も含めます。
コードの元の所有者は、その作品に対する権利を保持します。 しかし、MIT のようなライセンスは、ソフトウェアを構築したり変更したりして、いわゆる「派生作品」を作成する権利を他人に与えますが、オリジナルの作成者に他人が作成したものを所有する権利を与えません。 貢献した人は全員、既存のコードに基づいて実行された作業の一部に対する権利を保持します。
ほとんどのプロジェクトは、参加者にライセンスへの同意を求めることをわざわざしませんし、ましてや権利の分配に関する文書に署名することはありません。 これは素朴ですが、理解できます。 開発者は、GitHub にプル リクエストを送信すると、ライセンスの記載に従ってプロジェクトを配布する特定の権利を自動的に取得できると想定していますが、米国にはそのような規則はありません。 デフォルトでは、ライセンス転送許可ではなく著作権保護が設定されています。
合法化され文書化された権利譲渡と書類手続きの不在との間のギャップを埋めるために、一部のプロジェクトでは、開発者が Signed-Off-By メタ タグを使用して参照する標準的なステートメントである開発者の原産地証明書を受け入れます。DCO は、Linux カーネルを開発するために設計されました。 DCO は、SCO が所有する Unix カーネルから発展したもので、Linux の各ラインがそれに貢献した人々によって誕生したプロセスをうまく文書化しています。また、それはライセンスではありませんが、多くの利点を提供します。プロジェクトにコードを提出した人は、コードがプロジェクトとともに配布されること、およびユーザーが既存のカーネル ライセンスに基づいてコードを使用することを意図していたことがわかります。また、カーネルでは、すべてをリストした人間が読める CREDITS ファイルが維持されます。貢献した人々、名前、メンバーシップ、貢献分野、その他のデータ。
許可
このライセンスは、このソフトウェアおよび付属ドキュメント (以下「ソフトウェア」といいます) のコピーを入手した人に、以下のことを許可します。
MIT ライセンスのポイントは、ご想像のとおり、それがライセンスであるということです。 一般に、ライセンスとは、ある個人または団体 (ライセンサー) が、別の個人または団体 (ライセンサー) に、法廷で異議を申し立てられる可能性があることを行うことを許可する許可です。 MITライセンスは訴訟を起こさないという約束です。
場合によっては、法律によってライセンスとライセンスの譲渡における約束が分離されることがあります。 誰かがあなたにライセンスを与えるという約束を破った場合、約束を破ったとして訴訟を起こすことはできますが、ライセンスを取得できない可能性があります。 この文では [ 英語版では、これは古風な「hereby」を使用して行われます。 翻訳] は、このライセンスの本文自体がすでにライセンスを付与しており、単にライセンスを譲渡することを約束するものではないことを明確にしています。
また、多くのライセンスは特定の名前付きライセンスに対して許可を与えますが、MIT ライセンスは「パブリック ライセンス」です。 パブリックライセンスは全員に許可を与えます。つまり、 – 社会へ。 これは、オープンソース ライセンスの背後にある 3 つの優れたアイデアの 1 つです。 MIT ライセンスはこの考えを利用して、「ソフトウェアのコピーを入手した人」全員にライセンスを提供します。
括弧と引用符で概念を特定すること (「定義」) は、法律文書で用語に特定の意味を与える標準的な方法です。 当事者は法廷手続きにおいてこれらの規約を使用することができます。
範囲
ソフトウェアを制限なく無料で使用します。
これらの単語は、ライセンシーの観点から見ると、MIT ライセンスのすべての単語の中で最も重要です。 権利に関する主な問題は、著作権侵害や特許侵害で起訴される可能性があることです。 これらの法律分野では「自由使用」という言葉は使用されていません。 その結果、裁判所は必然的にこの定義が何を意味するのかを尋ねることになります。 裁判所は、この説明が意図的に広範すぎ、無制限であると認定するでしょう。 これにより、ライセンシーは、ソフトウェアの特定の使用について許可を与えていないというライセンサーの主張に抵抗することができます。
これには、ソフトウェアのコピーを使用、コピー、変更、マージ、公開、配布、サブライセンスおよび/または販売する無制限の権利、およびソフトウェアが提供される人物が含まれます。
完全に曖昧さのない、または完全に理解できる完璧な法文は存在しません。 誰かが違うことを言っても信じないでください。 ライセンスのこの部分は最も高度ではありません。
まず、「無制限の権利を含む」は、法文を書かない例です。 この定式化にはバリエーションがあります。
- 以下を含みますがこれに限定されません。
- 上記の一般化を含みますが、これに限定されません。
- 含むがこれらに限定されません;
それらはすべて 1 つの目的のために書かれており、どれもそれを達成しません。 魚を利用する弁護士らは、座礁したくないので魚を食べたいと考えている。 MIT ライセンスでは、これらは「ソフトウェアの使用」の特定の例 (「使用、コピー、変更」など) を提供する試みを意味しますが、ソフトウェアがリストされた方法の 1 つでのみ使用できることを意味するものではありません。 問題は、そのようなライセンスが法廷に提示された場合、裁判所はライセンスを理解するためにこれらの用語の意味を判断する必要があることです。 裁判所が「ソフトウェアを使用する」ということが何を意味するかを理解したいとしても、ライセンスに指定されている使用例を「見る」ことはできません。 ライセンスには「ソフトウェアを制限なく使用する」と書くのがベストだと思います。 それも短いです。
第二に、リストされている用語はごちゃ混ぜです。 これらの中には、著作権法および特許法で保護されているものとそうでないものがあります。
- 使用アメリカ合衆国法典第 35 条第 271 項 (a) に記載されており、後者が特許権者の許可なしに訴訟を起こすことができるもののリストに含まれています。
- コピー著作権法のリストの第 17 条、第 106 項に記載されています。
- 変更、公開、マージ著作権法にも特許法にも記載されていません。
- 配布する著作権法に記載されています。
- サブライセンス知的財産法の総称です。 これは、あなたが許可したことの一部または全部について、他の人が自分のライセンスを譲渡する権利を意味します。 この条項はオープン ライセンスでは異例です。 通常のアプローチは直接的で、ソフトウェアのコピーを受け取る全員が所有者から直接ライセンスを受け取ります。
- 売る- この言葉はハイブリッドです。 特許法でいう販売と似ていますが、著作権法と同様にコピーの販売を指します。 著作権用語では「頒布」に近いですが、著作権法では販売については触れられていません。
- 本ソフトウェアの提供を受ける者だけでなく、– このフレーズは「サブライセンス」を不必要に繰り返すように思えます。 また、ソフトウェアのコピーを受け取った人が直ちにライセンスを受け取る限り、これは必要ありません。
3つのライセンス条件
以下の条件に従います
常に落とし穴があります。MIT にも落とし穴が 3 つあります。
条件をお守りいただけない場合は許可が得られません。 したがって、理論的には、この場合、おそらく著作権法に基づいて訴えられる可能性があります。
ライセンス料を支払わなかった場合でも、ソフトウェアの価値を利用してライセンシーに準拠するよう動機付けることは、オープンソース ソフトウェアの 2 番目の優れたアイデアです。 後者は、MIT ライセンスには含まれていませんでしたが、ライセンス条件に基づいています。GNU Public License のようなライセンスでは、変更者がライセンスを取得し、変更されたバージョンを配布する方法を制御するために条件が使用されます。
ライセンスの譲渡
上記の著作権表示およびこれらの利用規約は、ソフトウェアのすべてのコピーまたは重要な部分に含める必要があります。
ソフトウェアのコピーを誰かに渡す場合は、そのコピーにライセンス テキストを含める必要があり、著作権表示を追加することができます。 これにはいくつかの目的があります。
- パブリック ライセンス ソフトウェアに対するアクセス許可を持っていることを他の人に伝えます。 これは、各ユーザーが権利所有者から直接ライセンスを受け取る直接ライセンス モデルの重要な機能です。
- ソフトウェアの作者についてのアイデアを提供するので、誰に賛辞、名声、寄付が浴びせられるべきかが明確になります。
- 保証の否認と責任の制限を規定します。
残念ながら、これらの条件はほとんど満たされていません。 ほぼすべてのオープンソース ライセンスにはそのような条件があります。 システムおよびインストール可能なソフトウェアの作成者は、ライセンス情報を含むファイルを画面に表示し、ライセンスのコピーをライブラリやコンポーネントに含める必要があることに気づくことがよくあります。 プロジェクトを管理する基金は、これらの実践を教えています。 しかし、ウェブ開発者には通知されていなかったようだ。 彼らには許しがありません。
保証の否認
ソフトウェアは「現状のまま」提供され、明示的または黙示的を問わず、商品性、特定目的への適合性、および非侵害の保証を含むがこれらに限定されない、いかなる種類の保証も行われません。
米国のほぼすべての州は、商取引を管理する一連の法律である統一商法に従うことが法律で義務付けられています。 UCC の第 2 条は、オークションで購入した中古車から工場への工業薬品の供給に至るまで、物品の販売に関する契約を扱います。
特定の UCC ルールは必須であり、常に適用されます。 売り手と買い手が契約書に別のことを書かない限り、「デフォルト」状態のみを説明するものもあります。 これらの「デフォルト」ルールの中には、保証、つまり製品の品質と使用に対する適合性に関する売り手から買い手への約束があります。
MIT のような公的ライセンスが契約、つまりライセンシーとライセンサーに強制できる契約であるのか、それとも単に条件を付すことができるライセンスなのかについては議論があります。 ソフトウェアが製品であるかどうか、したがって UCC の管轄の対象となるかどうかについては、あまり議論がありません。 しかし、ライセンサーは責任については異論を認めません。配布したソフトウェアが壊れたり、問題を引き起こしたり、動作しなかったり、その他の形でマイナスに現れた場合に訴訟を起こされることを誰も望んでいません。 これは、次の 3 つのデフォルト保証ルールで説明されている内容とはまったく逆です。
- セクション 2-314 によると、商品性とは、製品 (ソフトウェア) が少なくとも平均的な品質であり、適切にパッケージ化され、ラベルが貼られていて、通常の使用に適していることを約束するものです。 この規則は、ソフトウェア ディーラー、つまりソフトウェアを販売し、自らをこの分野の専門家であると考えている業者にのみ適用されます。
- 第 2-315 条に基づく特定の目的への適合性は、商品が特定の目的に適合することを買い手が期待していることを売り手が知っている場合に適用されます。
- 特許障害なし – UCC には含まれていませんが、契約法で一般的に使用されています。 購入した製品が他人の知的権利を侵害していることが判明した場合に、購入者を保護します。
弁護士は長い間、文章を大文字で書くことで目立ちやすさの要件を満たしていると誤解してきました。 これは間違っています。 大文字は、読者の注意を引くのではなく、遠ざけてしまうことがよくあります。 しかし、ほとんどのオープン ソース ライセンスでは、この部分が大文字で表記されています。これは、プレーン テキスト ファイル内のテキストを目立たせる最も明白な方法であるためです。 アスタリスクやその他の ASCII アートを使用したかったのですが、その電車はすでに出発してしまいました。
免責事項
いかなる場合においても、作者または著作権所有者は、ソフトウェアの使用またはソフトウェアに関連するその他のことから生じる、契約上、不法行為またはその他によるものを含め、いかなる請求、損害、またはその他の請求に対しても責任を負いません。
MIT ライセンスはソフトウェアを無料で提供しますが、この法律は、何か問題が発生してライセンサーが有罪となった場合に、無料ライセンスを受け取った人が裁判を受ける権利を失うことを意味するものではありません。 ライセンスと同様、責任の制限も法廷に行かないという約束として機能します。この場合に限り、ライセンサーをライセンシーから保護します。
通常、裁判所は保証の免責条項を注意深く読みます。これは、一方の当事者から他方の当事者にリスクを移転するのに役立つ可能性があるためです。 可能な限り国民に弁護の機会を与えるため、裁判所はこれらの権利放棄を、保護対象者に対して解釈することになります。 そのような条件が契約書の奥深くにあり、強調されていない場合、裁判所はそれらの条件を考慮することを拒否することがよくあります。 したがって、弁護士は大文字で書くことに慣れています。
責任の制限などにより、ライセンシーが訴訟を起こされる金額も制限されます。 オープン ライセンスの場合、この制限は常にゼロです。 商用ライセンスには、過去 12 か月間に支払ったライセンス料金の倍数の金額が含まれることがよくあります。
このセクションでは、ライセンサーが使用できない種類の法的追求をリストします。 多くの法的形式と同様に、このライセンスには契約違反と不法行為について言及されています。 不法行為の規則は、損害賠償を引き起こす行為の実行を指します。 メール送信中に道路で人を轢いた場合、不法行為を犯したことになります。 あなたの会社が人の耳を火傷するような欠陥のあるヘッドフォンを販売した場合、その会社は不法行為を犯したことになります。 契約書が不法行為の請求を明示的に排除していない場合、裁判所はそれを利用することがあります。 MIT ライセンスには、特殊な要件を除外するために「他の要件による」と記載されています。
フレーズ " ソフトウェアの使用またはソフトウェアを使用したその他の行為から生じる「」は、弁護士が自分の安全に対する後天的な恐怖の特徴である神経質なチックです。重要なのは、このソフトウェアに関連するあらゆる請求は制限と例外によってカバーされるということです。ただし、ソフトウェアの使用は、ソフトウェアの「その他の行為」に完全に含まれます。 。[ 元のライセンスでは、イベントの「発生」、「に関連して」、「使用」の 3 つのオプションが指定されています。つまり、「から発生」、「に関連して」、および「使用時」ですが、実際には相互に重複しています。 、これは記事の著者からの苦情を引き起こします-約。 翻訳] しかし、そのような文言は他の何百万ものライセンスで使用されています。
結論
しかし、これらの主張はどれも大したものではありません。 MIT ライセンスは法律上の古典です。 彼女が働く。 これは、すべてのソフトウェアの問題、特に特許紛争に対する万能薬ではありません。 しかし、そのようなライセンスは十分に機能しており、最小限の法的ツールで著作権、販売、契約における不都合なデフォルトルールの廃止という特定の目的を果たしています。 コンピュータの話題という文脈で言えば、そのバイタリティは驚くべきものです。 これは、その下でライセンスされていたほとんどのソフトウェアよりも存続しており、今後も存続します。 それが何十年機能し続けるかは推測することしかできません。 これは、弁護士を雇う余裕がない人にとっては特に有益です。MIT ライセンスは、さまざまな組織によって採用されているライセンスのランダムなバリエーションによる混乱に秩序をもたらす、一連の定義および標準化された定義であることがわかりました。
私たちは、帰属と著作権の問題に対する彼女のアプローチが、学術団体や商業団体における財産権管理の実践にどのような影響を与えているかを見てきました。
タグを追加して開く
MITライセンス
GNU 未満一般大衆 Li
Mozilla パブリック ライセンス
(略称MPL)
共通公衆ライセンス
CDDL (共通開発および
ライセンス配布)ZLib ライセンス GPL BSD ライセンス
Apache ソフトウェア ライセンス共有ソース プロジェクト
サンパブリックライセンス (SPL)
GPL は改訂され、1991 年 6 月にバージョン 2 がリリースされ、現在でも標準となっています。 GPLv3 は 2007 年 6 月 29 日に公開されました
GNU GPL の目的は、ユーザーにコピー、変更、配布する権利を与えることです。
GPL: GNU 基本的自由
- プログラムを実行する自由、
あらゆる目的のために。
- プログラムがどのように機能するのか、そしてその仕組みを学ぶ自由
変更 (その前提条件はソース コードへのアクセスです);
- コピーを配布する自由。
GNUのロゴ
プログラムを改良し、改良版を一般に公開する自由（暫定版）
この条件はソース コードへのアクセスです)。
バークレー ソフトウェア ライセンス (BSD ライセンス) は、 ライセンス契約、最初は UNIX に似た BSD オペレーティング システムを配布するために使用されました。
BSD ライセンスは、最も人気のあるフリー ソフトウェア ライセンスの 1 つであり、(BSD ライセンスが最初に作成された UNIX の BSD バージョンを除く) 多くのプログラムに使用されています。
このライセンスのテキストには 3 つのバージョンがあります。
1. オリジナルの BSD ライセンスまたは 4 条項 BSD ライセンス。
2. 変更された BSD ライセンス (OSI Web サイトの「新しい BSD ライセンス」)。
3. インテル社のライセンス「BSD+特許ライセンス」
非常に最初の BSD ライセンスは 4 つの条項で構成されていました。
1. ソース コードを再配布する場合は、上記の著作権表示、この条件リスト、および次の免責事項を保持する必要があります。
2. 再配布する場合 バイナリコード上記の著作権表示、この条件リスト、および以下の免責事項は、配布物に付属して提供されるドキュメントおよび/またはその他の資料に複製する必要があります。
3. このプログラムの機能または使用について言及するすべての広告資料には、次の通知を含める必要があります。「この製品には、カリフォルニア大学バークレー校およびその貢献者によって開発されたソフトウェアが含まれています。」
4. 事前の書面による許可なしに、大学の名前もその従業員の名前も、このソフトウェアに基づく製品の推奨または宣伝として使用することはできません。
BSD ライセンスにより、ソフトウェアの独自の商用使用が許可されます。 このライセンスに基づいてリリースされたソフトウェアは、独自のソフトウェアに組み込まれる場合があります。 市販品。 このようなソフトウェアをベースにした作品は、独自のライセンスの下で配布される場合もあります (ただし、ライセンス要件に準拠する必要があります)。 このようなプログラムの最も注目すべき例は、Microsoft 製品での BSD ネットワーク コードの使用と、Microsoft 製品での多くの FreeBSD コンポーネントの使用です。 オペレーティング·システム Mac OS X
MITライセンス は、フリー ソフトウェアの配布のためにマサチューセッツ工科大学によって開発されたライセンスのグループです。
このライセンスは、このソフトウェアおよび付属文書のコピーを入手した人に、コピーを無制限に使用、コピー、変更、追加、公開、配布、サブライセンスおよび/または販売する権利を含む、ソフトウェアを無制限に使用することを無料で許可します。ソフトウェアの。
Apache Software Foundation のフリー ソフトウェア ライセンス。
他のフリー ソフトウェア ライセンスと同様に、Apache ライセンスはユーザーにソフトウェアをあらゆる目的で使用し、自由に再配布、変更、および変更されたコピーを配布する権利を与えます。
CDDL に基づいてライセンスされたファイルは、他のオープン ライセンスまたは独自ライセンスに基づいたファイルと組み合わせることができます。 Free Software Foundation は、CDDL は GNU General Public License (GPL) と互換性がないと考えています。 CDDL は、2005 年 1 月 14 日にオープン ソース イニシアティブ (OSI) 理事会によって承認されました。 これは、9 つの最も人気のあるオープンソース ライセンスの 1 つと考えられています。
Sun がオープンソース プロジェクトに使用していた以前のライセンスは Sun Public License (SPL) で、これも Mozilla Public License から派生したものです。
CDDL を使用する製品の例:
OpenSolaris (DTrace および ZFS を含む)、NetBeans IDE、GlassFish、JWSDP、DReaM プロジェクト
これはフリー ソフトウェア ライセンスの 1 つです。 バージョン 1.0 は、Netscape Communications Corporation の弁護士時代に Mitchell Baker によって開発されました。 バージョン 1.1 は Mozilla Foundation によって開発されました。 MPL が使用されるのは、
Mozilla Suite、Mozilla Firefox、 モジラ・サンダーバード Mozilla によって開発されたその他のプログラム。 また、他の開発者、特に Sun Microsystems によって、Solaris のオープン ソース バージョンである OpenSolaris の共通開発および配布ライセンスとして採用されています。 Free Software Foundation は、MPL を純粋な形式で、つまり GPL または互換ライセンスと組み合わせて複数のライセンスを使用せずに使用することを推奨していません。
同時に、他のグループは製品のデュアル ライセンスを好みます。 たとえば、cURL ライブラリの古いバージョンでは、Mozilla Public License または MIT ライセンスの使用を選択できました。
Free Software Foundation のリストによると、上記の MIT ライセンスは、MIT の名前の下にあまりにも多くのライセンスがあり、別のライセンスとして X11 ライセンスがあるため、より正確には Expat ライセンスと呼ばれます。 ただし、Expat は Expat ライセンスを MIT ライセンスと呼び、X11 ライセンスをまったく持っていませんが、作成者が放棄した同様の X.Net ライセンスを持っています。
他のライセンスとの比較
MIT ライセンスは、3 条項からなる BSD ライセンスに最もよく似ていますが、使用を禁止する条項のみが異なります。 いい名前広告における著作権の所有者。 4 条項 BSD ライセンスにも、次のことを要求する同様の条項が含まれています。 全て販促資料には、MIT ライセンスではなくこのライセンスが表示されます。 後者では、ライセンスされたソフトウェアを使用、コピー、変更、他のソース コードに組み込み、公開、配布、サブライセンスおよび/または販売する権利を含む、エンド ユーザーの権利についてもより明確に述べています。
Apple Computer WebCore ライセンス (ただし、ほとんどの WebCore は LGPL に基づいてライセンスされています) のような、2 条項からなる BSD に似たライセンスも、「広告」条項を含まない MIT ライセンスと実質的に同一とみなされます。
このライセンスは学術ライセンスとみなされます。つまり、科学開発の分野での使用に適していると認められます。
こちらも参照
リンク
- リチャード・ストールマン、トランス。 セルゲイ・コロプ X Window System のトラップ (1999 年 10 月 6 日)。 アーカイブ済み
- パブロフ M.ロシア語 (ロシア語) のソフトウェア ライセンスに関するポータル。 LicenseIt.ru。 - ロシア語でのライセンスの説明とテキスト。 2012 年 2 月 16 日のオリジナルからアーカイブ。2010 年 7 月 7 日閲覧。
ウィキメディア財団。 2010年。