アカウント名:
パスワード:
たとえばGNU GPLでカバーされたとあるプログラムを例にとろう。 これに別なソース・ファイルを新規に追加し、そのファイルに
この新しいファイルの許可条件は、前のプログラムをカバーしているGNU GPLと矛盾しないか?
しないのだ。
GNU GPLは、プログラムの残り全部のソースが入手できることを要請するのは、皆さんご存じのとおり。しかし、GNU GPLは、プログラムの残り全部がGNU GPLであることまでは、要請していない。
GNU GPLは、あるプログラムがずっとフリー・ソフトウェアであり続けるようにするためにつくられたライセンスだ。しかし、プログラムの全体、つまりプログラムの他の部分全部もフリー・ソフトウェアでなければならないのかというと、必ずしもそうではないのだ。ソースが入手可能なだけでよい。
で、ソースが入手可能、というのは、必ずしも「フリーソフトウェアの定義」を満たすかというと、そうではない。
「フリーソフトウェアの定義」では、「変更できること」が条件にあるが、「ソースが入手可能」でも「変更禁止」と両立できてしまう。
GNU GPLを適用したプログラムでさえこうなのだ。他のライセンスについては何をかいわんやであろう。
このことを「『フリー』なドキュメント」にあてはめてみよう。
ここで大事なのは、プログラムは、ひとつのソース・ファイルからなることもあるけれど、多数のいろいろなソース・ファイルからなることが多くて、ソース・ファイルのそれぞれに許可告知やライセンスが設定される。その一方で、ドキュメントの場合、許可告知やライセンスは、ドキュメント全体にたいして適用されることが多いのではないだろうか。
私はここに、GNU FDLでいう「不変部分」の大きな意義があるとみた。いかがであろうか。
一般論としては、そうだと思いますけど、GPL な部分と「非フリー (GPL な観点から言って)」な部分とを持つような一体のソフトウェア/文書、というのは、GPL に違反してますから、それは自分で自分のやってることを理解していない、ということになると思います。
ちなみに、FSF vs Debian 論争は、べつに FDL がライ
単に間違っているという指摘をするだけでは 読み手にとって(少なくとも私にとって)有益 ではないと思いますが。
同感です。失礼しました。 私が指摘したかったのはGPLのごく基本的な部分でしたので(^^;;
プログラムの他の部分全部もフリー・ソフトウェアでなければならないのかというと、必ずしもそうではない
その変更版の或る部分が「プログラム」の派生物ではなく、しかもそれ自体独立で異なる作成物だと合理的に考えられる場合、あなたがそれらを別の作成物として頒布した時は、本使用許諾とその条項はそれらの部分には適用されません。しかし、それらを「プログラム生成物」の一部として頒布する場合は、全体が本使用許諾の条項に従って頒布されなければならず、使用許諾を受ける他の全ての者に対する許諾もプログラム全体にわたって与えられなければならず、結果として、誰が書いたかにかかわらず、全ての部分 に本使用許諾が適用されなければなりません。
独立していると判断できる追加ならよいわけですよね。 同じパッケージに入れてしまったらアウトですが、 「これこれのファイルを別途入手してください」は OK ってことでしょうか。
独立しているか否かは、同じパッケージになっているか否かとは関係ありません。独立しているか否かはプログラムの構造によります。GPL FAQの単なる集積と二つのモジュール~ [gnu.org]を参考にして下さい。パッケージというのは、何を想定しているのかわかりませんが、tarやlzhなどで一緒にアーカイブしても、それぞれが独立しているならば、GPLの影響は受けません。
二つのモジュールを結合する場合、「別途入手してください」でGPLと矛盾するライセンスで配布するのは駄目です。
後者の場合で、自分が配布するものに、GPLでライセンスされる他人の著作物が含まれるときには、その他人のライセンス(GPL)に対して違反していることになります。
そもそもGPLがGPLな著作物から派生した著作物に対してもGPLにすることを強制するのは著作権法第二十八条「二次的著作物の利用に関する原著作者の権利」に由来します。配布しようとするものが二次的著作物になるかが、GPLにしなければならないかの決め手になります。
# ところで iida 氏は iida@gnu.org を名乗っていらっしゃいますが # もし間違いを広めているのだとするとけっこーな問題のような
/.Jでは、実在しない適当なメールアドレスを表示させる方法があるのだと思います(私はやり方を知りませんが)。
私も元コメントは「変だな」と思った1人ですが…
GPL FAQの単なる集積と二つのモジュール~ [gnu.org]を参考にして下さい。パッケージというのは、何を想定しているのかわかりませんが、tarやlzhなどで一緒にアーカイブしても、それぞれが独立しているならば、GPLの影響は受けません。
(snip)
著作権法で根拠条文を探したとき、われわれは直感的に28条の問題だと考えます。しかし、私は28条の問題ではなく、21条=複製権に由来しうると考えています。どういうことかというと、GPLを適用しないパッケージを配布するような人に対しては、そもそも複製権を許諾しない(=使っちゃダメ)、という法律構成ができるのです。
ところでぐぐってみましたか? アドレスは実在するようです。(もちろんメールの発信者も偽れますが、意味のあるメッセージを発信しているアドレスが「実在しない」ことに、どれほどの意味があるか…)
っていうか日本語の使い方が間違っている。
iida さんの記事を見て
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
「フリー」、「修正の自由」、「入手可能なソース」 (スコア:0, 余計なもの)
たとえばGNU GPLでカバーされたとあるプログラムを例にとろう。 これに別なソース・ファイルを新規に追加し、そのファイルに
この新しいファイルの許可条件は、前のプログラムをカバーしているGNU GPLと矛盾しないか?
しないのだ。
GNU GPLは、プログラムの残り全部のソースが入手できることを要請するのは、皆さんご存じのとおり。しかし、GNU GPLは、プログラムの残り全部がGNU GPLであることまでは、要請していない。
GNU GPLは、あるプログラムがずっとフリー・ソフトウェアであり続けるようにするためにつくられたライセンスだ。しかし、プログラムの全体、つまりプログラムの他の部分全部もフリー・ソフトウェアでなければならないのかというと、必ずしもそうではないのだ。ソースが入手可能なだけでよい。
で、ソースが入手可能、というのは、必ずしも「フリーソフトウェアの定義」を満たすかというと、そうではない。
「フリーソフトウェアの定義」では、「変更できること」が条件にあるが、「ソースが入手可能」でも「変更禁止」と両立できてしまう。
GNU GPLを適用したプログラムでさえこうなのだ。他のライセンスについては何をかいわんやであろう。
このことを「『フリー』なドキュメント」にあてはめてみよう。
ここで大事なのは、プログラムは、ひとつのソース・ファイルからなることもあるけれど、多数のいろいろなソース・ファイルからなることが多くて、ソース・ファイルのそれぞれに許可告知やライセンスが設定される。その一方で、ドキュメントの場合、許可告知やライセンスは、ドキュメント全体にたいして適用されることが多いのではないだろうか。
私はここに、GNU FDLでいう「不変部分」の大きな意義があるとみた。いかがであろうか。
iida
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:1)
プログラムの残り全部がGNU GPLであることを要請される
のではないでしょうか?
ただし、本体と追加部分との著作権者が同一の場合は、
おっしゃるように部分ごとにライセンスを適用できますね。たぶん。
つまり、そうした場合は、フリーな部分と、非フリーな部分の混合になると。
FDLの「不変部分」は、ただ単にこの「非フリーな部分」に当たるだけじゃないだろうか?
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:0)
> おっしゃるように部分ごとにライセンスを適用できますね。たぶん。
一般論としては、そうだと思いますけど、GPL な部分と「非フリー (GPL な観点から言って)」な部分とを持つような一体のソフトウェア/文書、というのは、GPL に違反してますから、それは自分で自分のやってることを理解していない、ということになると思います。
ちなみに、FSF vs Debian 論争は、べつに FDL がライ
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:1)
商売として、追加機能の部分はプロプラにする、などということを、
意識的に行うことはあるのではないでしょうか?
>「不変部分」は「非フリーな部分」との解釈ですから、つまり全体としての著作物も「非フリー」である、とするものでしょうか?
自明かなっと思って書かなかったのですが、
「非フリー」部分があれば、
もちろん、全体としては非フリーということになると思っています。
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:1, 興味深い)
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:0)
もしくは、「間違った情報」とか。
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:1)
こーゆーのを見て、また勘違いする人が現れるのでしょう。
もうすこし気を付けて書いて欲しいです。
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:0)
具体的にどこがどう間違っているのでしょうか?
単に間違っているという指摘をするだけでは
読み手にとって(少なくとも私にとって)有益
ではないと思いますが。
# と言う自分は ID がないので AC だけど
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:1)
同感です。失礼しました。
間違いです。GPL日本語訳では以下のように書かれています。私が指摘したかったのはGPLのごく基本的な部分でしたので(^^;;
よーするに、自分で書いたソースを追加したら、それもGPLになるということです。
よって、「ソースが入手可能」でも「変更禁止」と両立できてしまう。などということ絶対にありません。
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:0)
>> その変更版の或る部分が「プログラム」の派生物ではなく、しかもそれ
>> 自体独立で異なる作成物だと合理的に考えられる場合、あなたがそれら
>> を別の作成物として頒布した時は、本使用許諾とその条項はそれらの部
>> 分には適用されません。しかし、それらを「プログラム生成物」の一部
>> として頒布する場合は、全体が本使用許諾の条項に従って頒布されなけ
>> ればならず、使用許諾を受ける他の全ての者に対する許諾もプログラム
>> 全体にわたって与えられなければならず、結果として、誰が書いたかに
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:1, 参考になる)
独立しているか否かは、同じパッケージになっているか否かとは関係ありません。独立しているか否かはプログラムの構造によります。GPL FAQの単なる集積と二つのモジュール~ [gnu.org]を参考にして下さい。パッケージというのは、何を想定しているのかわかりませんが、tarやlzhなどで一緒にアーカイブしても、それぞれが独立しているならば、GPLの影響は受けません。
二つのモジュールを結合する場合、「別途入手してください」でGPLと矛盾するライセンスで配布するのは駄目です。
後者の場合で、自分が配布するものに、GPLでライセンスされる他人の著作物が含まれるときには、その他人のライセンス(GPL)に対して違反していることになります。
そもそもGPLがGPLな著作物から派生した著作物に対してもGPLにすることを強制するのは著作権法第二十八条「二次的著作物の利用に関する原著作者の権利」に由来します。配布しようとするものが二次的著作物になるかが、GPLにしなければならないかの決め手になります。
/.Jでは、実在しない適当なメールアドレスを表示させる方法があるのだと思います(私はやり方を知りませんが)。
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:1)
私も元コメントは「変だな」と思った1人ですが…
(snip)
著作権法で根拠条文を探したとき、われわれは直感的に28条の問題だと考えます。しかし、私は28条の問題ではなく、21条=複製権に由来しうると考えています。どういうことかというと、GPLを適用しないパッケージを配布するような人に対しては、そもそも複製権を許諾しない(=使っちゃダメ)、という法律構成ができるのです。
ところでぐぐってみましたか? アドレスは実在するようです。(もちろんメールの発信者も偽れますが、意味のあるメッセージを発信しているアドレスが「実在しない」ことに、どれほどの意味があるか…)
日本/アメリカ (スコア:0)
アメリカの場合は二次著作への一次著作者の権利が明確化されているのかしらん?103条のあたりは怪しそうですが。
cric(面倒なのでリンクせず)のアメリカ法令の翻訳を読んでもわからず
(だからGPLはあんな面倒なライセンスなのかもね) 野分
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:0)
っていうか日本語の使い方が間違っている。
iida さんの記事を見て
Re:「フリー」、「修正の自由」、「入手可能なソース (スコア:0)
GNU GPLのFAQ [gnu.org]を再読することをお勧めします。
特に追加モジュールのライセンス [gnu.org]やGPLプログラムとのリンク [gnu.org]のあたり。