アカウント名:
パスワード:
たとえばGNU GPLでカバーされたとあるプログラムを例にとろう。 これに別なソース・ファイルを新規に追加し、そのファイルに
という、ある意味、「修正の自由」の制限された、簡単な許可告知(ライセンスといってもかまわないが、そんな大げさなものでなくてよい)を設定して、新しい別プログラムとしてリリースしたとしよう。
この新しいファイルの許可条件は、前のプログラムをカバーしているGNU GPLと矛盾しないか?
しない
単に間違っているという指摘をするだけでは 読み手にとって(少なくとも私にとって)有益 ではないと思いますが。
同感です。失礼しました。 私が指摘したかったのは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と矛盾しないか?
しない
iida
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 さんの記事を見て