LGPLv2.0ライセンスのXSLTスタイルシートをApachev2.0ライセンスのnodejsパッケージに含めることはできますか？
XMLをJavaコードに変換する）作業を行うためにいくつかのXSLTスタイルシートを活用するオープンソースツールを作成しています。使用したいスタイルシートの1つは、LGPLv2でライセンスされています。 .0。私のツールはApacheLicensev2.0でライセンスされます。
ApacheライセンスのプログラムをLGPLライブラリに動的にリンクすれば、問題ないことをどこかで読みました。プログラムとスタイルシートの間のリンクはファイル名にのみ依存し、単一のファイルを置き換えることで別のスタイルシートに簡単に置き換えることができるため、動的であると思います。
これから、LGPL XSLTスタイルシートを使用しても問題ないと推測できますか、それともここでの判断に誤りがありますか？
ファイルはnodejsパッケージプロジェクトディレクトリに含まれます
- パッケージは npmjs.org を通じて配布されます。
- 私自身のソースファイルは
lib/（例：lib/transform.js）にあり、ASLv2.0でライセンスされています。 - スタイルシートは、元のライセンス（この場合はLGPLv2.0）でライセンスされた
xslt/' (e.g.xslt/Java/xml-to-Java.xslt`）にあります。 - プログラムは使用されているスタイルシートを変更するためのインターフェースを提供しませんが、ユーザーはファイルシステムにアクセスし、パッケージのインストールディレクトリを探し、必要に応じて手動でファイルを別のファイルに置き換える必要があります。
このファイルは、プログラムに不可欠な機能を提供します
- 私自身のスタイルシートは、このスタイルシートが理解できる形式に変換されます
- それがなければ、同じ動作（同じ入力形式、同じ出力形式）のスタイルシートを提供する必要があります。
- したがって、基本的に、私のプログラムは、私のプログラムの動作の一部である最後の変換フェーズを委任します。
明確にするために、パッケージに含めようとしているファイルは元のライセンスを保持している可能性があります。プログラムにその機能を追加することにのみ関心があります。ファイルがないと、プログラムの機能が大幅に失われ、使用できなくなります。私がこの質問をしている理由は、ツールをプロジェクトと一緒に配布したいからです。ボックスでは、開発者のWebサイトとは別にxsltをユーザーにダウンロードさせないでください。
LGPLでは、プログラムのユーザーがLGPLライセンスのパーツを自分のバージョンに置き換えても、機能するプログラムを使用できる必要があります（新しいバージョンがインターフェイスと互換性がある場合）。
プログラムが実行時にLGPLXSLTスタイルシートを外部ファイルとして読み取る場合（XSLTファイルは別のファイルとして配布される場合のように）、ユーザーの置換可能性の要件が満たされています。
さらに、プログラムが特定のフォルダーにファイル「foo.xslt」が存在することだけを要求する場合、XSLTスタイルシートは実際にはプログラムの一部ではなく単なるデータであると主張することさえできます。その場合、アプリケーションとスタイルシートは著作権の目的で無関係であると見なされます。
それらを一緒に配布するということは、複数の独立した作品の集合体を配布しているということです。
私は弁護士ではありません。法的な問題の可能性が心配な場合は、入手する必要があります。
そのスタイルシートが何をするのか、そしてそれがパッケージのどこに保存されるのかはまったく関係ありません。重要な質問は、GNU LGPLでカバーされているものをApacheLicensev2でカバーされているパッケージに含めることの意味です。
つまり、そのXSLTを含むパッケージ全体が ASLv2 の下にある必要があるということですか？次にno、それはパーツがどのように組み合わされているかに関係なく絶対に不可能です：静的、動的、たとえそれらがまったく相互作用せず、何らかの理由で一緒にパッケージ化されたとしても。基本的に、取得したよりも多くの権利をライセンシーに付与したいと考えています。
または、ASLv2を your の作品に割り当てたいだけです。これには、GNUライセンスの下で他の誰かの作品が組み込まれています。それなら私にはわかりません、なぜあなたは何もないところから問題を探しているのですか：間違いなくはい、そのGNUライセンスがそうだとしてもあなたはそれをすることができます 通常のGPL であり、Lesserではありません。
Copyleft of GNU（L）GPLは フリー/リブレソフトウェア が追加の制限に拘束されて独占的になることから保護します。必要に応じて、自分の作業の一部単独 GNU GPL互換ライセンスのいずれかに自由に申請できます。 、実際には、サブライセンスを禁止しない①より寛容なもの、またはGNU（L）GPLの下で明示的に再ライセンスを許可する②のいずれかです。 ASLv2は前者のカテゴリにあります 。
次に、特定のライセンスのバージョンに固有の問題について説明します。あなたはスタイルシートが GNU LGPLv2. の下にあると述べました。 GNUライセンスでは、適用時にバージョンの上限を制限できますが、実際にそれを行う人はほとんどいません。ただし、著作権表示の「またはそれ以降のバージョン」の条項を not 見落としたとします。 ASLv2は not 廃止された GNU GPLv2 と互換性があり、最新のGPLv3とのみ互換性があるため、これは質問をより興味深いものにします。
ただし、GNU Library/Lesser GPL 2.xでは、 sub-ではなく re-）を再ライセンスできます。 LGPLのバージョンをバンプすることが許可されているかどうかに関係なく、同じまたはそれ以降のバージョンの通常のGNU GPL。
したがって、間違いなく行うことができるのは、スタイルシートを取得して著作権表示を変更し、GNU LGPLv2.0 =ではなくGNU GPLv3 +を参照するようにすることです。次に、それをASLv2の下にあるあなたの仕事と組み合わせます。しかし、「このパッケージ全体としては何という用語ですか？」という質問に対する唯一の答えは「GNUGPLv3 +」¹です。
¹ちなみに、それはGNU（L）GPLやコピーレフトに固有のものではありません。たとえば、 -clause BSDL の対象となるソフトウェアとApache Licenseを組み合わせて、単一のライセンスの下で全体として配布したい場合は、実際には同じことをする必要があります-それらの許容度の低いものを選択してください。 e。 Apacheライセンス。
コピーレフトが適用されるかどうかを判断するには、次のことを自問してください。
XSLTスタイルシートはアプリケーションの不可欠な部分ですか？アプリケーションはそれなしで動作しますか？
独立企業間で（ファイル/開くコマンド、バッチファイルなどを介して）通信していますか？
これらの質問のいずれかに対する答えが「いいえ」の場合、あなたの質問に対する答えは「いいえ」です。
LGPLには、独自のソースを開かなくてもライブラリをプログラムに簡単に組み込むことができるリンク例外があることに注意してください。ただし、ライブラリのソースに加えた変更を配布する必要があります。