11

私が働いている会社は、クローズド ソースのカーネル モジュール (.ko ファイル) を開発しています。このモジュールは、gpl2 モジュールに含まれている関数を呼び出す必要があります。基本的に、次のような状況があります。

// GPL 2 kernel module  (gpl.c -> gpl.ko)
void a_function(void)
{
// ...
}
EXPORT_SYMBOL(a_function)


// Closed Source module (closed.c -> closed.ko)
a_function();

これは合法ですか？この例では GPL2 ライセンスに違反していますか? closed.c には gpl2 ヘッダー ファイルが含まれていないことに注意してください。

4

5 に答える 5

8

GPL_ONLY非 GPL モジュール内で使用してはならないモジュールのフラグがあります。したがって、話しているモジュールがそうでない場合はGPL_ONLY、それを使用できます。

しかし、これらは 2.6.23 で可能なユーザー空間GPL_ONLYドライバー経由でアクセスすれば使用できます。それがまさに USB サブシステムに起こったことです。http://www.linux-magazine.com/online/news/linux_2_6_25_without_closed_source_usb_drivers

法的な問題に正確に対処しているわけではありませんが、いくつかのアイデアが得られます: http://www.cyberciti.biz/tips/linus-rejects-the-idea-of-non-gpl-kernel-modules.html

于 2009-04-10T08:15:08.337 に答える
4

一部の主要なカーネル開発者（Linus自身ではない）は、GPLを使用していないモジュールはカーネルのライセンスに違反しているという意見があります。

一部の開発者がLinksysルーターからBelkinドライバーをリッピングし、リバースエンジニアリングして結果を公開したとき、このライセンスの解釈を弁護として法廷に持ち込むという逆の脅威のため、Belkinはそれらを止めることができませんでした。

于 2009-04-15T19:18:01.147 に答える
4

1つ目：これについて弁護士に相談する必要があります。おそらくあなたの会社の法務部門です。

2番目: 重要な問題は、どのコードがどのコードから派生したものかということです。

残念ながら、この質問に対する答えはほとんどありません。

すべてのカーネルモジュールはカーネルの派生作品であり、ヘッダーのインクルードに関係なくGPL化する必要があると考える人もいます。

または、クローズド モジュールは GPL モジュールから派生し、GPL モジュールはカーネルから派生するため、クローズド モジュールも GPL である必要があります。

于 2009-04-10T08:02:05.900 に答える
4

他の無数のドライバーは、オープンソースの「シム」を使用して、クローズド ソースのオブジェクト ファイルをオープンソースのカーネルにブリッジしています。これは、ほとんどのカーネル開発者が、少なくとも精神的には GPL に違反していると考えています。

私の意見では、ソフトウェアを配布するかどうかによって異なります。これを純粋にサービスとしてのソフトウェアで実行している場合は、許可する必要があります。組み込みデバイスまたはボックス製品を配布している場合、それはノーノーです。

必要な機能をカーネルから移動するか、カーネル コンポーネントをオープン ソース化します。それは他のすべての人 (正直なところ) がすることであり、カーネル空間の「知的財産」を大量に持っている人は、ビジネスモデルが悪いか、エンジニアリングチームが無能であるため、一般的にはそれほどトリッキーではありません。

※以上は私見です※

于 2009-04-15T19:22:19.313 に答える