パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

「DVDコンバータ with DivX PRO」ソースコード公開、でも不十分?」記事へのコメント

  • by Anonymous Coward

    GPL の dll をクローズドからリンクする場合と、逆にクローズドの dll を GPL コードからリンクする場合、それぞれのライセンスの波及のしかたについてどなたか詳しい方教えていただけないでしょうか?

    少なくとも前者に

    • Re:dll (スコア:2, 参考になる)

      by ramsy (8353) on 2003年02月13日 18時44分 (#257854) ホームページ 日記
      前者を解決するのがLGPLです。
      ただし、DLLを動的ローディングする限りにおいては適用外です。(GPL source codeを使わなくてもAPIで呼び出せるので)
      windows においてDLLを使う方法には2種類あって、
      • .dllをロードするAPIを叩いて自分のコードポイントに取り込む(動的ローディング)
      • .dllと対になる.libをリンクし、コードの方でヘッダファイルをインクルードする(静的ローディング)
      これについてはLinux/Windowsで大筋に大差はありません。
      # BSD系とかは知りませんが、同様のはず。
      --
      # rm -rf ./.
      親コメント
      • Re:dll (スコア:2, 興味深い)

        by bull2 (7718) on 2003年02月13日 18時59分 (#257863)
        dlopen(3)やLoadLibrary(Win32)してGPLなコードを呼んだ場合はソースを公開する必要は無いのでしょうか?
        もっというと、GPLなコードにわずかな修正を施し(当然そのコードは公開する)て独立したプロセスで動作させ、本体プロセスから
        socket, pipe, shared memory等で通信して処理をさせる場合はどうなるのでしょうか?
        後者もそうであれば、apacheをサーバとして運用しているサイトにアクセスするプログラムのコードは全て公開しないといけなくなって、
        (できるだけソースを公開したくないと思われる通常の企業にとっては)問題になる気がします。
        親コメント
        • Re:dll (スコア:2, 参考になる)

          by (((((lambda))))) (3568) on 2003年02月13日 19時36分 (#257886) ホームページ

          一般には別プロセスならだいたい大丈夫だけれど、 本来ライブラリにすべきなくらい緊密な動作を 無理矢理別プロセスにしたくらいだとまずいかもしれない。 下の項目の5番目のパラグラフを参照。

          http://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation [gnu.org]

          親コメント
        • Re:dll (スコア:1, 参考になる)

          by Anonymous Coward on 2003年02月13日 19時32分 (#257883)
          モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく一つのプログラムに結合されています。もしモジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、それらが一つのプログラムに結合されているのはほぼ間違いないでしょう。

          逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズムです。ですからそれらがコミュニケーションのために使われるときには、モジュールは通常別々のプログラムです。しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。
          親コメント
          • by bull2 (7718) on 2003年02月13日 19時38分 (#257887)
            >> ApacheはGPLではありませんが?

            うおお、すんません。
            問題の本質は、GPLなコードを何らかの方法で非GPLなコードから呼んだ場合はどういう扱いになるのか、という事です。
            GPLなコードをリンクして同一の実行ファイルにさえしなければ、後は何をやってもOKになってしまうのでしょうか?
            だとすると回避手段がいくらでも出来てしまいますね。

            >> しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。

            ここの線引が難しい気がします。結局は非GPLなコードを書いた(または書くように指示した)人の倫理に因ってしまうのかな。
            親コメント
            • by Anonymous Coward
              >> 問題の本質は、GPLなコードを何らかの方法で非GPLなコードから呼んだ場合はどういう扱いになるのか、という事です。

              極端な例ですが、Linuxの場合はkernelがGPLなので、デバイスやメモリなどにアクセスする時点でLinux上の全てのプロセスはGPLなコードを経由しない限りは動けないとも言えます。ですから、それらの機能を使ってるLinux上のライブラリは全てGPL、それらのライブラリをリンクしてるソフトもGPL、っていう主張をする人もいるかもしれません。(いや、いねーよ>俺)ま、実際は「Linuxのシステムコールを呼んでるからGPLね」って理屈にはならないでしょ
              • by bull2 (7718) on 2003年02月14日 1時20分 (#258189)
                >> それらの機能を使ってるLinux上のライブラリは全てGPL、それらのライブラリをリンクしてるソフトもGPL、っていう主張をする人もいるかもしれません

                その当たりをMSがFUD [neweb.ne.jp]として宣伝すると、Linux用のプロプライエタリなアプリを作っている/作ろうとしているベンダは逃げてMSやSolaris等のプロプライエタリな側に付いてしまうもしれませんね。
                それによって、プロプライエタリなアプリに匹敵するGPLなアプリが数多く出現して使いやすくなれば万々歳なのですが、逆にベンダから見放されて発展が遅れてしまうかもしれませんね。

                情報元は失念してしまったのですが、無線LANのドライバをGPLにすると勝手に出力や周波数等が変更されて電波法違反になるのでGPLで公開できない、というような問題もあるようですし、難しいですね。
                親コメント
          • by G7 (3009) on 2003年02月14日 0時34分 (#258140)
            >モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく一つのプログラムに結合されています。もしモ
            >ジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、それらが一つのプログラムに
            >結合されているのはほぼ間違いないでしょう。
            >逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズ
            (以下略)

            それって、C的というかUnix的というかの、そっち方面で伝統的な解釈ですよね。
            でも、それ以外の環境だとどう解釈すればいいんだろう?という疑問が、どうにも消えません。

            Javaみたいな奴は動的リンクなのか否か?…

            Javaじゃシグネチャがコンパイル時に確定するから静的だろ、と言われるならば、
            じゃあJVMを使って(笑)もうちょっと動的な言語を作った場合はどうなのか?…

            JavaOS(笑)みたいにプロセスという概念が無い(スレッドは有るが)ならばどうなのか?…
            完全にプロセス的なものが無いとDoSに対して弱くなるんで、プロセスの壁は無いが
            quota(ってのか)みたいなものは有る、というOSも有るらしいが、それだとどうなのか?…

            LispOSだとどうなのか?…
            Smalltalkみたいに動的に全部やれる環境で、ただし「お約束」としてシグネチャを縛る場合は、
            静的と呼ぶのか否か?…

            コンポーネント間をTCPで接続する(それこそGNOMEとか?)ようなアーキテクチャのOSの類はどうなのか?…
            Interface定義がオプションで(笑)用意されてるような環境だと、Interfaceをオマケで書いた瞬間に
            GPLが波及するようになるのか?…

            GPLは、この辺の「新しい(?)技術」について、何も語ってくれていないような気がするんですが、
            どうなんでしょうか?

            GPLの効き目をはっきりさせる「ため」に古典技術だけを使う、なんていう本末転倒が生じないことを祈るので、G7。
            リンクという概念の定義自体が、技術の進展に伴って、どんどん変化していくんだと思う。

            #RMS的には、「なんでもいーから際限なく波及してほしい」という心的衝動が、きっと有るに違いない。
            #だからこそわざと不明瞭にしている…んだったりするまいな?
            親コメント
            • by bero (5057) on 2003年02月14日 4時46分 (#258252) 日記
              同感です。GPLは古いunix(的なOS)しか想定していなかったように思います。
              unix(的なOS)でも共有ライブラリが出てきて破綻してます。

              新しい技術に限らす、

              組み込みなど「プロセス」の概念のないOSの場合は?

              初期RAM(ROM)DISKをカーネルに「スタティックリンク」する場合は?

              ROMやCD=ROM起動等静的媒体において、LGPLの「ユーザがLGPL部分を差し替え可能にする」には?

              OSやコンパイラ付属のライブラリが肥大化していっても、全部「主要なコンポーネント」?
              親コメント
        • by Anonymous Coward
          > apacheをサーバとして運用しているサイトにアクセスするプログラムのコードは全て公開しないといけなくなって、

          ApacheはGPLではありませんが?
      • by ramsy (8353) on 2003年02月13日 18時54分 (#257860) ホームページ 日記
        ああ、書き忘れ。
        つまり、静的ローディングで問題になるのは、 .lib及び.hをバイナリの一部として取り込むからです。
        動的ローディングの場合、GPLなソースを流用しないので回避できる、となるわけです。
        --
        # rm -rf ./.
        親コメント
        • Re:dll (スコア:1, 参考になる)

          by Anonymous Coward on 2003年02月13日 20時02分 (#257903)

          現在のフリーソフトウェアのコミニティにおける一般的な解釈が知りたいです。GPL の特殊な抜け道に関する議論はそれはそれで有益だとは思うのですが、分けて議論した方が良いかと。

          大元の質問を整理したいと思います。

          1. windows のライブラリの仕組みは Linux のそれと同様と考えてさしつかえないか?
          2. windows のダイナミックリンクを介して GPL のライブラリを使用する場合、呼び出す側に GPL の効果は波及しないという解釈は一般的か?
          3. GPL 非互換のライブラリを GPL コードから呼び出すことは、そのライブラリが「OS に含まれる主要なコンポーネント」でなくとも可能であるという解釈は一般的か?
          親コメント
          • by Anonymous Coward

            質問者本人です。

            3. について調べたのですが、GNU の解釈では「法的に安全にリンクするには GPL に例外条項を追加する必要がある」とのことでした。 GPL の FAQ [gnu.org] を参照してください。

            ただしダイナミックリンクをどう解釈するかについてまでは

          • by Anonymous Coward
            >> GPL 非互換のライブラリを GPL コードから呼び出すことは、そのライブラリが「OS に含まれる主要なコンポーネント」でなくとも可能であるという解釈は一般的か?

            初期のKDEがまさにこの状態でしたね。KDE自体は最初からGPLでしたが、昔のQTはGPLじゃなかったです。ソースは公開されていましたが、たしか「非商用であれば無料で使っていいけど、商用ソフトの開発に使う場合は金を出して買え」「非商用版の再配布は不可」「パッチの配布も不可。もしbug fixのパッチなどを作った場合には、Trolltechに報告すべし」とかいう感じで、いろいろ条件があった気が
            • by tuneo (2938) on 2003年02月14日 9時17分 (#258298) ホームページ 日記
              >そんなにQTが使いたけりゃ、QT互換なライブラリを作りゃいいんだろ
              QT互換ツールキットはHarmonyプロジェクトですね。

              その辺の問題の経緯に関するRMSの見解はこちら [neweb.ne.jp]に出てます。
              親コメント
            • by Anonymous Coward

              >以上のように、FSF教的に正しい道かどうかは別として、「可能かどうか」という話しで言えば「可能」ですね

              質問者本人です。思い出しました!

              たしか QT のライセンス問題が持ち上がったとき Debian は厳密に解釈して KDE を収録しなか

            • by Anonymous Coward
              可能かどうかは法がどう判断するかでしょう。
              GPLが適用されるかどうかは、ソフトウェアとは
              どこまで派生した著作物といえるのかってことだから。
              動的リンクや共有ライブラリはもとのコードを含まな
              いから派生物でないとなるか、FSFの言うように派生物に
              • Re:dll (スコア:2, 参考になる)

                by tt (2867) on 2003年02月14日 0時24分 (#258134) 日記
                指名ありがとう。が、とりあえず私じゃなくても出来る人はいっぱいいます。国内法が確実に適用できる範囲ということで日本人の著者だけに絞っても、LAMEそのものの関係者として柴田さん、いわささんあたりはCommitterなんだし、小規模なパッチをなげたcontributorならば他にもいっぱいおられます。またLAMEは午後のこ~だのコードもぱくって、じゃない改変して使用させていただいてますから、あちらの開発グループの皆様も関係してきます。

                が、今回の場合、winLAMEのコードが一行も公開されたコードの中に含まれてないのが問題のような気がします(日記 [srad.jp]にも書きましたが・・・)。DVDxのほうはちゃんとソースと改変部分の説明があるのに。

                まあ、winLAME はまったく改変せずに使ってるから、ホームページのURLも書いてあるし、そこからソースを取って来い、ということなのかもしれません。が、とはいえちょっとひどくないっすかね。少なくとも、どのバージョンの winLAME の、どのあたりをどう使ったか、というのを記してないのはGPL的にまずい気がしないでも無いです。そうでないと、誰がそのコードの著作者か結局わからないので裁判に持ち込もうにも持ち込めない(苦笑)。

                で、なんか個人的にはふざけんなと言う気分ではありますが、この程度では裁判までやろうという元気は起きません。インターウェアのときは完全にLAMEのパクリだったにもかかわらず、でっちあげのChangeLogをつけてたり、メールでは謝罪したくせにウェブでは謝罪せずとか、余りの相手の対応に超絶激怒炸裂状態になって裁判でも殴りこみでもしてやるという気分でしたけどね(冷静を失っていただけと言う話もありますが)。

                --
                -- Takehiro TOMINAGA // may the source be with you!
                親コメント
        • by Anonymous Coward
          あれ? LGPLにおいては、アルゴリズムを含まないヘッダファイル
          (宣言、構造体、定数、小さなマクロ) のリンクに関しては除外されるはず。正しくは、「定義されてはいない」ですが。
          5章の後半かな?
      • by Anonymous Coward
        > ただし、DLLを動的ローディングする限りにおいては適用外です。

        ダウト。少なくとも FSF はそれもダメだと言ってます。
        ほれ [gnu.org]

        > .dllをロードするAPIを叩いて自分のコードポイントに取り込む(動的ローディング)
        > .dllと対になる.libをリンクし、コードの方でヘッダファイルをインクルードする(静的ローディング)

        もしかしたらそういう言葉の定義の仕方もあるのかもしれませんが、
        普通はこれらは両方とも動的ローディングと呼びます。
        • このFSFの例では (スコア:2, 参考になる)

          by SAY (54) on 2003年02月13日 20時27分 (#257908) 日記
          今回のとは逆の説明をしているけど、今回のケースをそのままこのFSFの例に当てはめると今ひとつ相容れない条件があり得ますよね。

          つまり非GPLなアプリのPluginをGPLで作った場合はどうなるのかということです。
          ramsy さんの説明通りなら、動的リンクされる側を先に作ろうが後に作ろうが同一の見解になりますが、FSFの例をあてはめるべきとなると利用するI/F用のDLLが複数あった場合にその中に一つでもGPLなものがあると呼び出し元もソース公開の義務を負いかねないという解釈になってしまいますが。

          このFSFの例ではプロセスを形成しているメインの機能がGPLライセンスのものであり、その延長上にPluginが位置する事からGPLであるべきと言っているだけでGPLなDLLを動的ローディングする限りにおいては適用外だという解釈は間違っていないと思います。
          親コメント
          • by johndoe (3028) on 2003年02月13日 21時13分 (#257925) 日記
            GPLなDLLが存在しなくても正常動作可能なら別物。
            動作するためにGPLなDLLが必須ならGPLの影響を受けると思いたい。
            そうじゃないとあとづけでGPLな互換ライブラリをつっこむだけでGPLで乗っ取れてしまう。

            このへんのことちゃんとしておかないとGPLは公序良俗に反するけしからんライセンスと攻撃されてもしかたないんじゃなかろうか
            親コメント
            • by Anonymous Coward

              GPL互換ライブラリをつっこむことが可能なのはソフトウェア配布者だけなのでは?

              乗っ取ろうとした人間本人が後付けで GPL ライブラリをつけて配布したとしても、ライセンス違反を問われるのはそいつだけなのだし

              • by johndoe (3028) on 2003年02月14日 22時18分 (#259107) 日記
                例外の部分を見落としてました。
                ライブラリのライセンスに例外がちゃんと記述されてなければ後づけのライブラリ開発者がライセンス違反ですね。

                で、ふと思ったのですが既存のライブラリが後からGPLになったケースや、ソースコードレベルで複数のOS間で互換性があるがそのうち一部のOSのみがGPLなライブラリを使用するケースでソースコードのみを非GPLなライセンスで配布した場合はGPLはどう適用されるんでしょう?
                親コメント
              • by Anonymous Coward
                プログラムの作者が自由な(アーカイブの内容を変えるなど)再配布を許可しているとして、
                第三者がGPLなプラグインを同梱して配布した場合はどうなるのでしょう?

                この場合もGPL感染するのならば、
                プログラムの作者は配布形態に関するライセンスに注意しなければいけませんね。
              • by Anonymous Coward

                GPL プラグインを同梱した二次配布者(==第三者)がライセンス違反に問われると思います。しかしあくまで一次配布者には責任は及びません。

                二次配布者が GPL プラグインを同梱して配布することを想定するのであれば、作者はそのソフトウェアのライセンスに GPL 互換ライセンスを採用するべきでしょう。 逆に GPL のプラグインを使

              • by tsuya (14020) on 2003年02月15日 1時58分 (#259291) 日記

                >ライブラリのライセンスに例外がちゃんと記述されてなければ後づけのライブラリ開発者がライセンス違反ですね。

                ライブラリ開発者が違反してるライセンスというのはきっと無くて、例外に書き忘れた呼び出し元ソフトがGPLでないと矛盾してるようなライセンスをライブラリに付けてしまった、ということですね。で、この場合のGPLはライセンスとして無効で、そのライブラリがGPLでないものとして(著作権法等に反しない範囲で)勝手に使われても文句言えない?

                >で、ふと思ったのですが既存のライブラリが後からGPLになったケースや、ソースコードレベルで複数のOS間で互換性があるがそのうち一部のOSのみがGPLなライブラリを使用するケースでソースコードのみを非GPLなライセンスで配布した場合はGPLはどう適用されるんでしょう?

                というわけで前者は勝手に使われるかも。後者は問題の所在がわかりませんでした。すみません。

                親コメント
              • by tsuya (14020) on 2003年02月15日 17時02分 (#259605) 日記

                実行形式が実行されるオペレーティングシステムの主要なコンポーネント (コンパイラやカーネル等)を除いて単体配布できないから、 そういうライブラリやプラグインはGPLで配布できないとか、例外を規定する 必要があるとか、LGPLやRuntime GPLを使うとか、 という提案がされてきたのが、 この話題の主要な流れのひとつであったと思います。 この例外についても、もともと曖昧であった上に、 技術の高度化・多様化でますます訳がわからなくなっている、 という主張も多く見られました。

                一方貴方のように、インタフェイス依存にすぎないから 単体配布可能とする主張もいくつかありました。 こちらの方が曖昧な点が少ないし、心情的には支持したいのですが、 各々単体で配布されているソフトを一ヶ所に集めることさえできれば、 ユーザにとっては同じコトになってしまいますね。 仮にそのような行為自体が不当だとしても、防御は困難でしょう。

                親コメント
              • >ここの意味がよくわかりませんでした。

                ここはGPLと他のコメントの部分引用です。リンクは大変なのでご勘弁を。

                >それとも再配布をしないエンドユーザーの行為を問題にしているのでしょうか。

                その意味で書きました。

                例外を除いて、関連するインターフェース定義ファイルのすべてとライブラリのコンパイルやインストールを制御するために使われるスクリプトをも加えたものを含まないといけない、とGPLに書いてあるわけです。 それがないとコンパイルできない、ということのほかに、「このソースの任意の追加や書き換えを許すから、そのかわり出来たものもGPLにしてね」という約束をもとにGPLワールドを単調拡大させていく、というGPLの目的が、ライブラリ等の形態を介することで止まらないようにしていると思われます。 それなのに、単体配布物を集めてコンパイルすればGPLと非GPLを混ぜて使える、ということが知れ渡ったら、そもそもGPLの意味がない、と。

                >slashdot のトピックは数日で流れてしまいますので残念ながらこのへんでキリになってしまいそうですが。 議論の蓄積できる場所があればいいのにね・・・

                引きずりすぎないからこそ新しい話題に対応できるのも確かですから。 アーカイブは残るので、いつか新しいタレコミの中で、いいタイミングで蒸し返してください。

                親コメント
          • by SAY (54) on 2003年02月13日 20時33分 (#257910) 日記
            GPLなDLLの機能がそのプロセスの主な機能と解釈出来る場合には呼び出し元もGPLで公開されるべきでしょうね。
            親コメント
            • by G7 (3009) on 2003年02月14日 0時41分 (#258149)
              どっちが主でどっちが従か、がはっきり区別しやすいのも、伝統的なシステムの特徴っすね。

              Javaみたいに(に限らないが)、ぜんぶ.classで「対等な」ライブラリファイルが
              うじゃうじゃ集まってるだけのものだと、結構悩むんじゃないでしょうかね。

              極端な話、それらのうちの「複数の」Classにmainメソッドを持たせて
              ユーザーがゲッターロボみたいにどれを今mainとして使うかを好きに選べるなら、
              もう主従関係自体が静的に決まらなくなりかねない。
              (それに対してDLLやsoだと主従関係自体は動的に決まらず必ずexeが主ですよね)

              主従関係や依存関係の定義も、システムの仕組みに依存しますよね。どうするんだGPL?
              親コメント
            • by SAY (54) on 2003年02月13日 21時18分 (#257931) 日記
              動的リンクも単一プログラムとしてみなされると書いてあるのをはっきりと認識したうえで自分としてはあの見解です。

              例えば画像を扱うSusie [digitalpad.co.jp]というソフトがありますが、このソフトのPluginとしてGPLライセンスのPluginを作った場合、Susieまでソースを公開の義務が生じるという事になってしまいます。
              逆にこのPlugin I/Fを利用するクローズドソースなアプリもありますが、それらもソース公開の義務を負う事になってしまいます。

              それこそMSじゃないですがウィルス的なライセンスになってしまいます。

              ですからこのFSFの例とは逆のケースではこのまま適用出来ないと考えています。
              親コメント
              • by bero (5057) on 2003年02月14日 4時58分 (#258253) 日記
                GPL FAQでは、(作者がプラグインを公開するときに)GPLそのままでなく、「hogeとの(動的)リンクを許可する」とゆー特例をつけろ、といってます。
                が、そんなのつけてるソフトやプラグインみたことありません。

                いちいち特例で指定する場合、同じ仕様のpluginをサポートしたfugaが出てきても、それで使うことはライセンスされてない、とゆーことになってしまいます
                親コメント
              • by Anonymous Coward
                >GPLライセンスのPluginを作った場合、Susieまでソースを公開の義務が生じるという事になってしまいます。

                なんでこうなるのでしょう。単にそのようなPluginはGPLの下で配布できないというだけでは?

                世の中にはGPLを適用できるものとできないものとがあり、あなたが例に挙げたPluginは後者に属するというだけのことでしょう。
              • by Anonymous Coward
                GPL FAQにあるように特例としてSusieに対してはGPLを
                適用しないと入れればいいだけですよね。
              • by SAY (54) on 2003年02月13日 22時29分 (#258001) 日記
                私が挙げた例においてGPLを適用できないと強制する事はできないように思いますが。

                適用すべきではないと思いますけど。

                その I/F を利用する GPL なアプリとその I/F を利用する GPL な Plugin とセットで出してというようなパターンもありますし。

                私の挙げた例とは違いますが、GPL な Windows プログラムが呼び出す Windows API も DLL で実現されているんですけどね。
                親コメント
              • by Anonymous Coward on 2003年02月13日 22時47分 (#258018)
                本当にGPLを読んでんの?
                GPLにはOSとコンパイラのコンポーネントは除外するとある
                でしょ。だからGPLなものは原則としてGPLと非互換な
                ライセンスのソフトウェアと一体となって動くかたちで配布
                してはならないの。
                別にGPL なpluginを作ったからといってSusieがGPLになるわけじゃない。だけど、GPLなpluginはOSでもコンパイラでもない
                susieという独占的プログラムに依存するのでGPLを満たせない。
                だから配布はできないというのに無理がありますか?
                親コメント
              • だがしかし、Susieプラグインを使えるソフトはSusie以外にも沢山ある罠。
                親コメント
              • by SAY (54) on 2003年02月13日 23時43分 (#258063) 日記
                >GPLにはOSとコンパイラのコンポーネントは除外するとある

                すっかり忘れてました。

                >だからGPLなものは原則としてGPLと非互換な
                >ライセンスのソフトウェアと一体となって動くかたちで配布
                >してはならないの。

                これは理解してます。

                >だけど、GPLなpluginはOSでもコンパイラでもない
                >susieという独占的プログラムに依存するのでGPLを満たせない。
                >だから配布はできないというのに無理がありますか?

                そういえば独占的プログラムに依存するものにGPLを適用出来ないという条項も確かありましたね。

                一応その Plugin I/F を利用する GPL なアプリと GPL な Plugin という形で満たす手段はありますが、その場合は組み合わせる人の問題だという事ですか。

                納得です。
                親コメント
              • by Anonymous Coward
                このプラグインを外部アプリから動的にリンクしても外部アプリにはGPLの対象としませんとすればいい。
                (LGPLとほとんど変わらないけど。)
              • by kicchy (4711) on 2003年02月13日 23時52分 (#258085)
                Susieプラグインは、Susie以外のアプリケーションからも
                利用することが可能ですから依存していないのでは?

                依存しているのはインターフェース。

                GPL詳しくないんで合ってるか知りませんがこれで逃げれないんですか?
                親コメント
              • by G7 (3009) on 2003年02月14日 0時47分 (#258155)
                >だけど、GPLなpluginはOSでもコンパイラでもない susieという独占的プログラムに依存するのでGPLを満たせない。

                ところで、OSやアプリやプラグインやライブラリの定義もまた(^^;、システムの仕組みに依存しますよね。

                というか、Unixの「アプリ」だって、考えてみれば、OSというプログラムの上で動く「プラグイン」なんですよね。
                main(笑)を始めとする各種APIの作法に則って作られ(だって則ってないアプリは動かないでしょ?)、
                ユーザーが後付けでシステムに追加することが出来て、システムを機能拡張してくれる、「プラグイン」です。

                GPLのような興味深い性質を持たされているライセンスが、OSとかライブラリとかいう
                状況依存性の強い語(!)で説明される(FSF自身もそう説明してるんだったよね?)のは、
                ちょっと残念です。
                親コメント
              • by Anonymous Coward
                "だけど、GPLなpluginはOSでもコンパイラでもない"と書いたACです。
                Susieはアプリケーションなのは確実なのでGPLから
                引っ張った際に「主要なコンポーネント」っていうのをはずし
                ていました。

                >GPLのような興味深い性質を持たされているライセンスが、OSとかライブラリとかいう
                >状況依存性の強い語(!)で説明される(FSF自身
              • by Anonymous Coward
                spiってdllの拡張子変えたものだしねぇ。
                この場合どうなるんでしょ?
                普通のDLLをGPLで公開するのはアリなのに
                拡張子を変更するとGPLにはできないってこと?
              • by Ying (4319) on 2003年02月14日 1時19分 (#258185)
                ちなみにGPLと互換性のないソフトウェアのプラグインをGPLで公開してしまっている例として、in_mpg123.dll(Winamp用)なんてのがありますね。
                親コメント
              • by Anonymous Coward on 2003年02月14日 5時35分 (#258257)
                私がしっている広く使われているGPLの例外としては Runtime GPL [gnu.org] がありますが、pluginにはこいつを使っていれば問題ないかと 思います。
                ただ特例を設けないといけないと認識している人は いろいろと問題のでるGPLを使わないと思います。
                親コメント
            • >フリーではないプログラム向けのプラグインにGPLを適用することはできますか?
              >に動的リンクも単一プログラムとしてみなされると書いてある。

              確かにその通りなんですが,これってGPL本文には明記されていないん
              ですよね。FAQは単にFSFの主張を述べているだけであって,何ら法的
              拘束力を持たない。ですから,
          • by Anonymous Coward

            つまり非GPLなアプリのPluginをGPLで作った場合はどうなるのかということです。
            ramsy さんの説明通りなら、動的リンクされる側を先に作ろうが後に作ろうが同一の見解になりますが、FSFの例をあてはめるべきとなると利用するI/F用のDLLが複数あった場合にその中に一つでもGPL

アレゲは一日にしてならず -- アレゲ見習い

処理中...