オーストラリアの海岸線はキューバの海岸線よりも長いということは、誰もが同意するでしょう。同様に、日本の海岸線はオーストラリアの海岸線よりも長いです。ちょっと待って...どういうこと？CIAがそう言っているので、きっと本当でしょう。さらに、海岸線の長さは、測定方法によって異なることが判明しています。
ライセンスとどう関係があるのでしょうか？サードパーティのライセンスに関する質問のほとんどは、次の形式です。
ASFプロジェクト「A」は、「D」としてライセンスされている「C」を使用して「B」を実行できますか？
答えは、単純なルールと大まかな近似値が、多くの場合、両方の場合において正しい答えを与えるということです。たとえば、キューバとオーストラリアを比較する場合のように。しかし、場合によっては、そのようなルールと近似値は間違った答えを与えます。そして、まれに、答え自体が質問のされ方によって異なります。
これは、複雑でしばしば議論の的となる主題への、気楽で時には横道にそれる導入となることを意図しています。
サードパーティライセンスポリシーの最初の近似は、ASFはApacheプロジェクト内で作成された作品をApacheライセンスバージョン2のみに基づいて配布できる必要があるということです。さらに、そのような作品が持つ可能性のある依存関係は、同様の条件でライセンスされている必要があります。これは非常に望ましい理想ですが、少なくとも再帰的な依存関係を考慮すると、完全には100％一貫して満たされているわけではありません。
この近似では、唯一の決定要因は上記のステートメントのライセンス（「D」）であり、「同様の」条件とは何かという疑問が生じます。
私はこのように見ています。Apacheタイプのライセンスは普遍的なドナーです。そのようなコードは誰にでも提供できます。GPLタイプのライセンスは、少なくともオープンソースのドメイン内では、普遍的なレシピエントに近いものです。そのようなコードは、幅広いオープンソースコードと組み合わせることができます。
FSFは、これについて優れた視覚資料を提供しています。すべての矢印が一方向であることに注意してください。
普遍的なドナーであり続けるためには、当社の製品は抗原を含まないままでなければなりません。これは当然、カテゴリA：承認されたライセンスの定義につながります。
最初の近似は多くの良い答えを与えますが、いくつかの間違った答えも与えます。まず、抗原はすべて悪いわけではありません。Apacheライセンスバージョン2には、特許終了条項があります。その条項とコントリビューターライセンス契約は、血液供給を他の危険から安全に保つためのより大きな戦略の一部です。
これは、カテゴリAのライセンスは少量であれば完全に許容されますが、そのようなライセンスに基づいて利用可能になった作品への大きな依存は、ASFがライセンスポリシーに慎重に組み込んだ特許責任の制限を希釈することを意味します。
この逆もまた真です。カテゴリA以外のライセンスは、*使用方法*によっては完全に許容される場合があります。お気づきでないかもしれませんが、それは上記のステートメントの「B」です。抽出するのが難しい方法でコア機能を実装するために作品を組み込むことは、別の製品との統合を可能にするオプションのプラグインを持つこととは大きく異なります。その製品が除外されたライセンスに基づいて利用可能になった場合でも、それは変わりません。または、独自の非オープンソースの製品でさえも。
この具体的な例は、Jakarta NTサービスです。JBOSSデプロイヤーもそうです。法律の別の側面からフレーズを借りれば、これらのプラグインなしで実質的な非侵害使用がある限り、これらの使用は問題ないだけでなく、普遍的なドナーであるという目標と積極的に一致しています。もちろん、これがどのように行われるかを文書化する際には、注意が必要です。
したがって、2番目の近似はマトリックスです。行はライセンスです。列は用途です。最初はマトリックスはまばらですが、時間の経過とともに「常にOK」と「決してOKではない」で埋められます。いくつかの答えにはアスタリスクが付いています。このように整理すると、一部のライセンスは不活性ガスであり、他のライセンスは明らかに放射性であり、カテゴリが出現し始めることがわかります。
そして、あなたがこれを理解できると考えたちょうどその時、人々は新しいライセンス、新しい条項、そして新しい除外を発明します。そして新しい用途。
アスタリスクについては上記で述べました。いくつかのライセンスと用途では、アスタリスクはタンポポのように増殖するように見えます。例：幅広い用途で無料で配布される独自の製品へのハードな依存関係を扱う列。そして、クラスパスまたはライブラリとしての使用の例外を含むGPLベースのライセンスを扱う行。
JavaとC＃は代表的な例です。
最初は、これを使用法の種類の観点から定義しようとすると魅力的です。しかし、ますます、許容される使用法と許容されない使用法をこの方法で区別することが難しいことがわかります。最終的には、許容される製品を単純に列挙する方が簡単であることがわかります。それが上記の記述の「C」です。
際立った特徴は、ライセンスの範囲外であり、私たちの制御の及ばない何かである傾向があります。*遍在性*や*標準*などの属性を扱う特性。製品は、ターゲット環境にすでにインストールされていると想定できるほど遍在していますか？ASFコードは、「標準」インターフェースを使用してこの製品と対話していますか？これは、ASF製品が実行しようとしていることを可能にするために明示的に設計されていますか？注：この質問は、ASFが特定の標準化団体を承認するかどうかを理解しようとすることなく調査する必要があるため、「標準」をかぎかっこで囲みました。これらの目的のために、アーキテクチャされたインターフェースであれば何でも構いません。もっと簡単に言えば、私たちは意図された方法で製品を使用または拡張していますか？
したがって、Javaに依存するlog4jは明らかに問題ありません。それは明確にそのようにマークされています。
Hibernateをシステムの依存関係と見なすことができるかどうかという問題に直面したとき、インキュベーターは、RollerがHibernateをバンドルして出荷することはできないと単純に述べました。これは、この問題につながりました。これは、Rollerのターゲットオーディエンスの多くがHibernateをすでにインストールしておらず、単にRollerをサポートするためにインストールすることに関心があるという観察に基づいています。
言うまでもなく、これらのタイプの議論と決定は、関係者全員にとって困難です。そして、PMCからの具体的な要求に基づいてのみ再開する必要があります。
パターンがわかれば、残りの文字は1つだけです。「A」です。ここではすべてASFプロジェクトであることを考えると、2つのASF製品が同じ製品（明らかに同じライセンスで）を同じ方法で使用したい場合、一方ではOKで、他方ではOKではないという答えになることはありませんよね？ 実際、まれですが、可能です。
Lucene.Netは、Microsoft.NET Frameworkに大きく依存しています。上記で説明したように、それはまったく問題ありません。繰り返しますが、依存関係は明確にマークされているため、このポッドリングに関心のない人は単に参加しません。
一方、httpdを同様の依存関係を使用するように変更すると、フォークが発生する可能性があります。しばらくの間、Open Officeは同様の論争に直面し、それがメールマージコンポーネントがPythonで書き直されることにつながり、最終的にはOpenJDKの結成にわずかながら貢献した可能性があります。
そして、明らかに、Tomcatはまさにそのような「フォーク」の1つです。非常にうまくいっているものです。ここでのポイントは、サードパーティのライブラリを使用*しない*オプションを保護することは、サードパーティのライブラリを使用*する*オプションを保護することと同じくらい重要になる場合があるということです。
さて、文字数が尽きてしまいましたが、まだすべてがうまく収まっているわけではありません。Santuarioは、著作権、特許、あるいはライセンスにすら関連しない規制に対処しなければなりません。HTTPDは別々のダウンロードを提供することで同様の状況に対処してきました。
このドキュメントの冒頭のタイトルは、ニュートン力学が一般相対性理論に取って代わられる原因となった観測現象に敬意を表したものです。いわば醜い事実です。ニュートン力学は、今でも幅広い用途で非常に有用な答えを生み出すため、今日でも教えられていますが、一般相対性理論が提供する答えがニュートン力学の答えと異なる場合、前者のほうが正しいことが多々あります。
さて、私はこのつまらない考えが、一般相対性理論の重要性に少しでも匹敵すると考えているわけではありません。正直に言うと、私は単に、そうでなければ退屈な話題にスパイスを加えるために、そして、ある視点からは常識に反するように見えることが、全く異なる視点からは実際には唯一の賢明な立場である可能性があるという考えに信憑性を与えるために、科学的なメタファーを散りばめただけです。
そしてその話題に関して、ニュートンの重力はニュートン力学の「崩壊」でしたが、量子力学は相対性理論に革命を起こす可能性があります。量子力学では、観測者の役割が観測対象の性質に影響を与えることがよくあります。ASFがJavaとXMLを採用するという決定は、これらの両方に大きな影響を与えました。（私たちが望んでいたほどではないかもしれませんが、それでもかなりのものです）。これは、時折、上記のすべての基準に反する、慎重に選択されたイニシアチブを追求することを許容すべきであることを意味します。
上記の免責事項があっても、このとりとめのない話は、私の好みにはあまりにも大げさです。私が本当にやりたいことは、このリストの質問に素早く対処することです。そのためには、「Javaベースのプロジェクトはこちらへようこそ」とか、「Rubyで書かれ、Rubyライセンスで利用可能なものは、Rubyで書かれたプロジェクトの依存関係としてOK」と言える柔軟性を持つ必要があると考えています。
そうしたい理由は単純です。Rubyランタイムの一部であるものとそうでないものの境界は曖昧であり、そのようなGemの作者の意図は明確であり、率直に言って、そのような声明はRubyコードのライセンシーが期待するものと非常に一致しています。そのような声明はまた、JavaまたはRubyライセンスを既存のカテゴリのいずれかに適合させようとする労力（あるいは、ぞっとすることに、Rubyに対応するために1つ以上のカテゴリの定義を変更する）を費やすことを避け、これはRubyライセンスの下でライセンスされているTCLコードをどのように扱うべきかを決定しようとすることに等しいでしょう。
高度な近似において、このページで説明されているアプローチは、サードパーティライセンスポリシードラフトと一致します。主な違い
このページには、「1年または2つのメジャーリリースのいずれか早い方までに削除する必要がある」といったフレーズが一切ありません。既存のプロジェクトが、貢献者またはライセンシーからの重大な異議なしに長期間にわたってリリースを行ってきた場合、介入する理由はないと感じています。
このページには、カテゴリBまたはサードパーティスクリプトの処理方法に関する具体的な記述がありません。これらの問題について合意を宣言する準備はできていません。また、これらのケースを処理する適切な方法は、状況によって異なる可能性があります。
このページでは、すべてのプロジェクトおよびすべての時間にわたって決定が一貫していない可能性があることを明示的に認めていますが、同時に、これが発生する可能性のある回数を最小限に抑え、制限しようとしています。
overriding goalは、普遍的なドナーであり続けることです。PMCは開発者とライセンシーのニーズのバランスをとることが期待されますが、サードパーティのライセンスに関する問題では、法務委員会は、最もリスク回避的な企業からフリーソフトウェア運動の最も活動的なメンバーまで、ライセンシーのニーズ全体が満たされるようにすることに重点を置きます。
ASFはすべて自発的な貢献に基づいており、著作物を再配布する際には著作権者の表明する制約に従うことを意図しています。
すべての決定は公開され、掲示されます。
可能な限り、すべては法務委員会の合意によって決定されますが、怠惰な合意による場合もあります。合意に達することができない場合は、決定は議長に委ねられ、議長は理事会にそのような問題を報告します。
PMCは具体的な質問をするように推奨されます。上記のような形式の質問は、「ここに問題があります。解決してください」といった種類の自由回答形式の質問よりも優先されます。
サードパーティのライセンスポリシーの重要な部分は、NOTICE、LICENSE、およびREADMEファイルの具体的なポリシーの確立と監視です。
