アカウント名:
パスワード:
GPL の dll をクローズドからリンクする場合と、逆にクローズドの dll を GPL コードからリンクする場合、それぞれのライセンスの波及のしかたについてどなたか詳しい方教えていただけないでしょうか?
少なくとも前者に
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
dll (スコア:0)
GPL の dll をクローズドからリンクする場合と、逆にクローズドの dll を GPL コードからリンクする場合、それぞれのライセンスの波及のしかたについてどなたか詳しい方教えていただけないでしょうか?
少なくとも前者に
Re:dll (スコア:2, 参考になる)
ただし、DLLを動的ローディングする限りにおいては適用外です。(GPL source codeを使わなくてもAPIで呼び出せるので)
windows においてDLLを使う方法には2種類あって、
# rm -rf ./.
Re:dll (スコア:2, 興味深い)
もっというと、GPLなコードにわずかな修正を施し(当然そのコードは公開する)て独立したプロセスで動作させ、本体プロセスから
socket, pipe, shared memory等で通信して処理をさせる場合はどうなるのでしょうか?
Re:dll (スコア:1, 参考になる)
逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラム
Re:dll (スコア:1)
>ジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、それらが一つのプログラムに
>結合されているのはほぼ間違いないでしょう。
>逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズ
(以下略)
それって、C的というかUnix的というかの、そっち方面で伝統的な解釈ですよね。
でも、それ以外の環境だとどう解釈すればいいんだろう?という疑問が、
Re:dll (スコア:1)
unix(的なOS)でも共有ライブラリが出てきて破綻してます。
新しい技術に限らす、
組み込みなど「プロセス」の概念のないOSの場合は?
初期RAM(ROM)DISKをカーネルに「スタティックリンク」する場合は?
ROMやCD=ROM起動等静的媒体において、LGPLの「ユーザがLGPL部分を差し替え可能にする」には?
OSやコンパイラ付属のライブラリが肥大化していっても、全部「主要なコンポーネント」?