「DVDコンバータ with DivX PRO」ソースコード公開、でも不十分? 105
完全かつ機械で読み取り可能なソースコードを配布すべし 部門より
ramsy曰く、"GPL違反が疑惑から確定になった『DVDコンバータ with DivX PRO』ですが、
2003/02/12付けでソースコードが公開されました。
で・す・が、「また、公開中のソースコードをそのままコンパイルいたしましても、製品と同等の機能を利用できるわけではございません。」なーんてことがしれっと書いてあります。GPL準拠であることを認めた以上、外部DLL(この場合DivX Pro等)で読み込んでいる部分は除き、すべてをGPLとして提供する義務があるはずです。当然、本体バイナリ埋め込みになっているであろう、体験版の制限を仕掛けている部位も、です。
また、MPEG2,AC3,MP3等のパテントに関しても「ライセンス上問題ありません」と書かれていますが、何を根拠として「問題ない」と言い放っているかが不透明なままです。上記3パテントに関しては正規ライセンシーを受けていれば、明記されなければならないはずです。まだまだ、GPLにちゃんと従っているとは言い難いのでは…"
経緯その1とその2。もとの(GPLな)バイナリと同等のものを再現できるだけのソースコードでなければいけないのは、プロジーが遅れて選択したGPLの3b項に明記してある。ごまかそうとしているのか、それとも単に無知なのかは分からないが、何度も軌道修正しつつ、正しい方向にむかってきているのは確かだ。
この件で「GPL恐い」とか「コミュニティは暴徒みたいだ」なんて間違った認識が(更に)広まらなければいいのだが。GPLは明確的に独占的なソフトウェアへの転用を防止する意図をもって書かれたライセンスだ。ならば、GPLなソフトウェアを流用して開発するならば、ルールを守ればいいだけの話なのだ。ルールさえ守っていれば、恐れることはなにもない。例えば、3項でaを選択していれば、バイナリ受領者以外がソースを請求してきても渡す必要がないことは企業にもユーザにもあまり知られていない。ゲームのルールを知ろうとしなかったり、破ろうとするから火傷をするのだ。
正しい方向というからには (スコア:2, おもしろおかしい)
Re:正しい方向というからには (スコア:1)
明らかに変だもんね。
とゆうか小出し小出しな手口がかっこ悪いと思うのはオイラだけ?
As it goes, so it is.
Re:正しい方向というからには (スコア:1, 参考になる)
これは国産と偽った輸入食品を販売していることを認めた会社が、それをそのまま売り続けているという、消費者としては言語道断な状態、ということになります。
これとは別に、経営的に考えると、すぐにはクレ-ムしか来ないGPLよりも、単独で提訴に踏み切れるパテントへの対策のほうが、より急を要するように思うんですけど…
同社サイトにドルビ-マ-クが表示されるのはいつでしょうね?
Re:正しい方向というからには (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
main()をGPLにしたら? (スコア:2, 興味深い)
それ以降に出現した全てのバイナリに対して「GPL違反だからソースを公開せよ」という事は出来るのでしょうか?
*BSDなソースから持ってきたことにすれば大丈夫な気がするのですが、誰かがこんな事を言い出す可能性は無いとは言えないので気になります。
Re:main()をGPLにしたら? (スコア:1, 参考になる)
Re:main()をGPLにしたら? (スコア:1)
# GPLじゃないけど。
権利者は私 [srad.jp]です。使用料を払ってください。
Re:main()をGPLにしたら? (スコア:1)
Copyright (C) 2003 limbo
Cもoもpも・・・すでに著作物の中で既出ですが。
Re:main()をGPLにしたら? (スコア:1)
既にそれは著作権が切れています。
なぜなら、70年以上前の書物に出ていることが示されているからです。
Re:main()をGPLにしたら? (スコア:1, おもしろおかしい)
Re:main()をGPLにしたら? (スコア:1)
> とつですので、著作権がない場合、ライセンス条件を決定することも出来ません。
著作権って、少なくとも日本では、主張云々に限らず自然に発生する権利(自然権、無法式主義) [osaka-u.ac.jp]という見解が多いみたいだけど。
だから、どんなに粗末なものでも著作権は存在する、はず。
もっとも、電子的な著作物に関してはわからないんだけど……。
Re:main()をGPLにしたら? (スコア:1)
以上から考えると、少なくとも(2)には該当せず著作物としては認められないかと思われます。
また火塚さんの著作権コラム第三回 [d51.net]内にある「ファイアーエンブレムシリーズが著作物にあたると言えるのか」と具体的に著作物であるかどうか判定している辺りが参考になるかと思います。
Re:main()をGPLにしたら? (スコア:1)
電子的な著作物の場合データが小さい場合は偶然同じものができることがある。だから main() だけのファイルに著作権を主張されたとしても「いや、私もつくったんだけど偶然同じものができちゃったね」ってことになるんだと思う。電子的に同一のものでも、制作の上で模倣したものでなければ、著作権は同時に存在できるはず。
# それは電子的なものに限らず、文章についてもそうだったと思うけど。
もちろん、そこに書いてあるソースを取ってきたら著作権の侵害になるわけだけど。自分がゼロから作れば問題はない。
Re:main()をGPLにしたら? (スコア:1)
著作権は、自分がものを作れば必ず発生する。ので、「発生する場合に相当するかどうか」といわれれば、発生する。
http://cozylaw.com/copy/kihon10/no-6.htm
Re:main()をGPLにしたら? (スコア:1)
そのオリジナリティを証明できるかどうかが問題だ。
あまりにも簡単なプログラムであれば、
すでに似ているものが存在している かもしれないので、
しっぺ返しを食らうかも
両方とも同じリンク… (スコア:1)
「その1」のほうはこっち [srad.jp]かな?
Re:両方とも同じリンク… (スコア:3, 参考になる)
Re:dll (スコア:2, 参考になる)
ただし、DLLを動的ローディングする限りにおいては適用外です。(GPL source codeを使わなくてもAPIで呼び出せるので)
windows においてDLLを使う方法には2種類あって、
# BSD系とかは知りませんが、同様のはず。
# rm -rf ./.
Re:dll (スコア:2, 興味深い)
もっというと、GPLなコードにわずかな修正を施し(当然そのコードは公開する)て独立したプロセスで動作させ、本体プロセスから
socket, pipe, shared memory等で通信して処理をさせる場合はどうなるのでしょうか?
後者もそうであれば、apacheをサーバとして運用しているサイトにアクセスするプログラムのコードは全て公開しないといけなくなって、
(できるだけソースを公開したくないと思われる通常の企業にとっては)問題になる気がします。
Re:dll (スコア:2, 参考になる)
一般には別プロセスならだいたい大丈夫だけれど、 本来ライブラリにすべきなくらい緊密な動作を 無理矢理別プロセスにしたくらいだとまずいかもしれない。 下の項目の5番目のパラグラフを参照。
http://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation [gnu.org]
Re:dll (スコア:1, 参考になる)
逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズムです。ですからそれらがコミュニケーションのために使われるときには、モジュールは通常別々のプログラムです。しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。
Re:dll (スコア:1)
うおお、すんません。
問題の本質は、GPLなコードを何らかの方法で非GPLなコードから呼んだ場合はどういう扱いになるのか、という事です。
GPLなコードをリンクして同一の実行ファイルにさえしなければ、後は何をやってもOKになってしまうのでしょうか?
だとすると回避手段がいくらでも出来てしまいますね。
>> しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。
ここの線引が難しい気がします。結局は非GPLなコードを書いた(または書くように指示した)人の倫理に因ってしまうのかな。
Re:dll (スコア:1)
その当たりをMSがFUD [neweb.ne.jp]として宣伝すると、Linux用のプロプライエタリなアプリを作っている/作ろうとしているベンダは逃げてMSやSolaris等のプロプライエタリな側に付いてしまうもしれませんね。
それによって、プロプライエタリなアプリに匹敵するGPLなアプリが数多く出現して使いやすくなれば万々歳なのですが、逆にベンダから見放されて発展が遅れてしまうかもしれませんね。
情報元は失念してしまったのですが、無線LANのドライバをGPLにすると勝手に出力や周波数等が変更されて電波法違反になるのでGPLで公開できない、というような問題もあるようですし、難しいですね。
Re:dll (スコア:1)
>ジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、それらが一つのプログラムに
>結合されているのはほぼ間違いないでしょう。
>逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズ
(以下略)
それって、C的というかUnix的というかの、そっち方面で伝統的な解釈ですよね。
でも、それ以外の環境だとどう解釈すればいいんだろう?という疑問が、どうにも消えません。
Javaみたいな奴は動的リンクなのか否か?…
Javaじゃシグネチャがコンパイル時に確定するから静的だろ、と言われるならば、
じゃあJVMを使って(笑)もうちょっと動的な言語を作った場合はどうなのか?…
JavaOS(笑)みたいにプロセスという概念が無い(スレッドは有るが)ならばどうなのか?…
完全にプロセス的なものが無いとDoSに対して弱くなるんで、プロセスの壁は無いが
quota(ってのか)みたいなものは有る、というOSも有るらしいが、それだとどうなのか?…
LispOSだとどうなのか?…
Smalltalkみたいに動的に全部やれる環境で、ただし「お約束」としてシグネチャを縛る場合は、
静的と呼ぶのか否か?…
コンポーネント間をTCPで接続する(それこそGNOMEとか?)ようなアーキテクチャのOSの類はどうなのか?…
Interface定義がオプションで(笑)用意されてるような環境だと、Interfaceをオマケで書いた瞬間に
GPLが波及するようになるのか?…
GPLは、この辺の「新しい(?)技術」について、何も語ってくれていないような気がするんですが、
どうなんでしょうか?
GPLの効き目をはっきりさせる「ため」に古典技術だけを使う、なんていう本末転倒が生じないことを祈るので、G7。
リンクという概念の定義自体が、技術の進展に伴って、どんどん変化していくんだと思う。
#RMS的には、「なんでもいーから際限なく波及してほしい」という心的衝動が、きっと有るに違いない。
#だからこそわざと不明瞭にしている…んだったりするまいな?
Re:dll (スコア:1)
unix(的なOS)でも共有ライブラリが出てきて破綻してます。
新しい技術に限らす、
組み込みなど「プロセス」の概念のないOSの場合は?
初期RAM(ROM)DISKをカーネルに「スタティックリンク」する場合は?
ROMやCD=ROM起動等静的媒体において、LGPLの「ユーザがLGPL部分を差し替え可能にする」には?
OSやコンパイラ付属のライブラリが肥大化していっても、全部「主要なコンポーネント」?
Re:dll (スコア:1)
つまり、静的ローディングで問題になるのは、 .lib及び.hをバイナリの一部として取り込むからです。
動的ローディングの場合、GPLなソースを流用しないので回避できる、となるわけです。
# rm -rf ./.
Re:dll (スコア:1, 参考になる)
現在のフリーソフトウェアのコミニティにおける一般的な解釈が知りたいです。GPL の特殊な抜け道に関する議論はそれはそれで有益だとは思うのですが、分けて議論した方が良いかと。
大元の質問を整理したいと思います。
Re:dll (スコア:1)
QT互換ツールキットはHarmonyプロジェクトですね。
その辺の問題の経緯に関するRMSの見解はこちら [neweb.ne.jp]に出てます。
Re:dll (スコア:2, 参考になる)
が、今回の場合、winLAMEのコードが一行も公開されたコードの中に含まれてないのが問題のような気がします(日記 [srad.jp]にも書きましたが・・・)。DVDxのほうはちゃんとソースと改変部分の説明があるのに。
まあ、winLAME はまったく改変せずに使ってるから、ホームページのURLも書いてあるし、そこからソースを取って来い、ということなのかもしれません。が、とはいえちょっとひどくないっすかね。少なくとも、どのバージョンの winLAME の、どのあたりをどう使ったか、というのを記してないのはGPL的にまずい気がしないでも無いです。そうでないと、誰がそのコードの著作者か結局わからないので裁判に持ち込もうにも持ち込めない(苦笑)。
で、なんか個人的にはふざけんなと言う気分ではありますが、この程度では裁判までやろうという元気は起きません。インターウェアのときは完全にLAMEのパクリだったにもかかわらず、でっちあげのChangeLogをつけてたり、メールでは謝罪したくせにウェブでは謝罪せずとか、余りの相手の対応に超絶激怒炸裂状態になって裁判でも殴りこみでもしてやるという気分でしたけどね(冷静を失っていただけと言う話もありますが)。
-- Takehiro TOMINAGA // may the source be with you!
このFSFの例では (スコア:2, 参考になる)
つまり非GPLなアプリのPluginをGPLで作った場合はどうなるのかということです。
ramsy さんの説明通りなら、動的リンクされる側を先に作ろうが後に作ろうが同一の見解になりますが、FSFの例をあてはめるべきとなると利用するI/F用のDLLが複数あった場合にその中に一つでもGPLなものがあると呼び出し元もソース公開の義務を負いかねないという解釈になってしまいますが。
このFSFの例ではプロセスを形成しているメインの機能がGPLライセンスのものであり、その延長上にPluginが位置する事からGPLであるべきと言っているだけでGPLなDLLを動的ローディングする限りにおいては適用外だという解釈は間違っていないと思います。
Re:このFSFの例では (スコア:2, 参考になる)
動作するためにGPLなDLLが必須ならGPLの影響を受けると思いたい。
そうじゃないとあとづけでGPLな互換ライブラリをつっこむだけでGPLで乗っ取れてしまう。
このへんのことちゃんとしておかないとGPLは公序良俗に反するけしからんライセンスと攻撃されてもしかたないんじゃなかろうか
Re:このFSFの例では (スコア:1)
ライブラリのライセンスに例外がちゃんと記述されてなければ後づけのライブラリ開発者がライセンス違反ですね。
で、ふと思ったのですが既存のライブラリが後からGPLになったケースや、ソースコードレベルで複数のOS間で互換性があるがそのうち一部のOSのみがGPLなライブラリを使用するケースでソースコードのみを非GPLなライセンスで配布した場合はGPLはどう適用されるんでしょう?
Re:このFSFの例では (スコア:1)
>ライブラリのライセンスに例外がちゃんと記述されてなければ後づけのライブラリ開発者がライセンス違反ですね。
ライブラリ開発者が違反してるライセンスというのはきっと無くて、例外に書き忘れた呼び出し元ソフトがGPLでないと矛盾してるようなライセンスをライブラリに付けてしまった、ということですね。で、この場合のGPLはライセンスとして無効で、そのライブラリがGPLでないものとして(著作権法等に反しない範囲で)勝手に使われても文句言えない?
>で、ふと思ったのですが既存のライブラリが後からGPLになったケースや、ソースコードレベルで複数のOS間で互換性があるがそのうち一部のOSのみがGPLなライブラリを使用するケースでソースコードのみを非GPLなライセンスで配布した場合はGPLはどう適用されるんでしょう?
というわけで前者は勝手に使われるかも。後者は問題の所在がわかりませんでした。すみません。
リンク & GPL おさらい (スコア:1)
実行形式が実行されるオペレーティングシステムの主要なコンポーネント (コンパイラやカーネル等)を除いて単体配布できないから、 そういうライブラリやプラグインはGPLで配布できないとか、例外を規定する 必要があるとか、LGPLやRuntime GPLを使うとか、 という提案がされてきたのが、 この話題の主要な流れのひとつであったと思います。 この例外についても、もともと曖昧であった上に、 技術の高度化・多様化でますます訳がわからなくなっている、 という主張も多く見られました。
一方貴方のように、インタフェイス依存にすぎないから 単体配布可能とする主張もいくつかありました。 こちらの方が曖昧な点が少ないし、心情的には支持したいのですが、 各々単体で配布されているソフトを一ヶ所に集めることさえできれば、 ユーザにとっては同じコトになってしまいますね。 仮にそのような行為自体が不当だとしても、防御は困難でしょう。
書き忘れ (スコア:1)
Re:書き忘れ (スコア:1)
Javaみたいに(に限らないが)、ぜんぶ.classで「対等な」ライブラリファイルが
うじゃうじゃ集まってるだけのものだと、結構悩むんじゃないでしょうかね。
極端な話、それらのうちの「複数の」Classにmainメソッドを持たせて
ユーザーがゲッターロボみたいにどれを今mainとして使うかを好きに選べるなら、
もう主従関係自体が静的に決まらなくなりかねない。
(それに対してDLLやsoだと主従関係自体は動的に決まらず必ずexeが主ですよね)
主従関係や依存関係の定義も、システムの仕組みに依存しますよね。どうするんだGPL?
Re:このFSFの例では (スコア:1)
例えば画像を扱うSusie [digitalpad.co.jp]というソフトがありますが、このソフトのPluginとしてGPLライセンスのPluginを作った場合、Susieまでソースを公開の義務が生じるという事になってしまいます。
逆にこのPlugin I/Fを利用するクローズドソースなアプリもありますが、それらもソース公開の義務を負う事になってしまいます。
それこそMSじゃないですがウィルス的なライセンスになってしまいます。
ですからこのFSFの例とは逆のケースではこのまま適用出来ないと考えています。
Re:このFSFの例では (スコア:1)
が、そんなのつけてるソフトやプラグインみたことありません。
いちいち特例で指定する場合、同じ仕様のpluginをサポートしたfugaが出てきても、それで使うことはライセンスされてない、とゆーことになってしまいます
Re:このFSFの例では (スコア:1)
適用すべきではないと思いますけど。
その I/F を利用する GPL なアプリとその I/F を利用する GPL な Plugin とセットで出してというようなパターンもありますし。
私の挙げた例とは違いますが、GPL な Windows プログラムが呼び出す Windows API も DLL で実現されているんですけどね。
Re:このFSFの例では (スコア:1, 参考になる)
GPLにはOSとコンパイラのコンポーネントは除外するとある
でしょ。だからGPLなものは原則としてGPLと非互換な
ライセンスのソフトウェアと一体となって動くかたちで配布
してはならないの。
別にGPL なpluginを作ったからといってSusieがGPLになるわけじゃない。だけど、GPLなpluginはOSでもコンパイラでもない
susieという独占的プログラムに依存するのでGPLを満たせない。
だから配布はできないというのに無理がありますか?
Re:このFSFの例では (スコア:1)
Re:このFSFの例では (スコア:1)
すっかり忘れてました。
>だからGPLなものは原則としてGPLと非互換な
>ライセンスのソフトウェアと一体となって動くかたちで配布
>してはならないの。
これは理解してます。
>だけど、GPLなpluginはOSでもコンパイラでもない
>susieという独占的プログラムに依存するのでGPLを満たせない。
>だから配布はできないというのに無理がありますか?
そういえば独占的プログラムに依存するものにGPLを適用出来ないという条項も確かありましたね。
一応その Plugin I/F を利用する GPL なアプリと GPL な Plugin という形で満たす手段はありますが、その場合は組み合わせる人の問題だという事ですか。
納得です。
Re:このFSFの例では (スコア:1)
利用することが可能ですから依存していないのでは?
依存しているのはインターフェース。
GPL詳しくないんで合ってるか知りませんがこれで逃げれないんですか?
Re:このFSFの例では (スコア:1)
ところで、OSやアプリやプラグインやライブラリの定義もまた(^^;、システムの仕組みに依存しますよね。
というか、Unixの「アプリ」だって、考えてみれば、OSというプログラムの上で動く「プラグイン」なんですよね。
main(笑)を始めとする各種APIの作法に則って作られ(だって則ってないアプリは動かないでしょ?)、
ユーザーが後付けでシステムに追加することが出来て、システムを機能拡張してくれる、「プラグイン」です。
GPLのような興味深い性質を持たされているライセンスが、OSとかライブラリとかいう
状況依存性の強い語(!)で説明される(FSF自身もそう説明してるんだったよね?)のは、
ちょっと残念です。
Re:このFSFの例では (スコア:1)
Re:このFSFの例では (スコア:1, 興味深い)
ただ特例を設けないといけないと認識している人は いろいろと問題のでるGPLを使わないと思います。
Re:このFSFの例では (スコア:2, おもしろおかしい)
Re:dll (スコア:1)
クローズドなソフトウェアに依存するフリーソフトウェアってのは問題ないんじゃないでしょうか?
# OSF的な用語をよく知らん… クローズド → 独占的?
Re:結局あれだろ。 (スコア:1, 興味深い)
Re:結局あれだろ。 (スコア:1, 興味深い)
ま、その時は著作権法や各種パテントとフリーソフトウェアが正面からぶつかる事になりますが。
それはそれで「知の解放」と言う側面が出て来るので良い事ではあると思いますが。
そもそもアルゴリズムの独占やスクランブル解除の禁止って後出しに近い物がありますからね。
おおよそ万国著作権条約などの基本理念(文化や学術の発展)に相容れない物を、利権構造から無理矢理突っ込んだが故の矛盾を明らかにして改める意味でもがんばって欲しいと思います。