「フリー」なドキュメントとは何か？ 43
ストーリー by Oliver
free-as-in-DSFG-free 部門より
free-as-in-DSFG-free 部門より
k3c 曰く、 "japan.linux.comに掲載された八田真行氏の『多元化する「フリー」』という記事によると、GNU FDL 1.2が「フリー」なライセンスであるか否かを巡って、FSFとDebian Projectの間で論争が繰り広げられた(というか現在も進行中)なのだそうです。事の経緯をごく大雑把に略すと、FDLではCover Text(著作権表示など)とInvariant Section(本文中の改変禁止部分)を指定して、これらの部分の改変・削除を明示的に禁止できるようになっていることについて、FSFが「ドキュメントの扱いはプログラムとは違う基準が適用されるべき」と主張しているのに対して、Debian Project側は「改変を許さない部分を含むドキュメントはフリーじゃない」、従って「FDL 1.2はフリーなライセンスではない」と主張しているようです。詳しくは件の記事とdebian-legalの該当するスレッドを読んで下さい。ちなみにワタシはdebian-legalは拾い読みしただけなので、論争をきちんと追いかけているヒトのフォローがあるとありがたいです。
八田氏は記事の中で「Debian側の論理に軍配が上がる」と述べています。ワタシもそう思いますが、しかし、何もかも改変しちまって原型を留めなくなっても元のドキュメントの改訂版を名乗っていいのか、ということにもなり…これはなかなか難しい問題ではないでしょうか。「フリー」なドキュメントとは何なんでしょうか？"
軍配というならば、ものいい (スコア:2, すばらしい洞察)
理念を示すものというより、協同作業を行う上での実際的なもので、
ディストリビューションをつくる立場から、開発者、利用者、CDの配布をする人、FTP サイトを用意する人のために、線引きをまとめたものではなかったか。
理念は、"社会契約" の方だよね。
フリーソフトウェアガイドラインは、ソフトウェアに対してのもので、それを文書に適用して行くことならば、それは違う話だと、僕は考える。
文書の配布に関しての運用の不備を認識し、ディストリビューションとしてのガイドラインを起こすというのであれば分かる。そうであるべきだろう。
これまで、文書の配布条件などに関しては特に詳しく考え無しに、ディストリビューションの開発と配布は進んで来たのが事実ではないだろうか。もし、文書の改変とその配布をガイドラインとするならば、これまでは、そうではないものをずっと配布して来た、見逃して来たということなのか。
改変が可能であるところを明示する GNU FDL でさえ、
認められないというのであれば、例えば、
GNU Manifesto, Debian 社会契約、Linux Gagdet などの文章を拒絶し、ディストリビューションとして配布はしないとする線引きとなるのであろうか。これまで配布して来たのは間違いだったのか。
あまりにも、観念的な話ではないだろうか。
そんなDebianはいらない (スコア:1)
つられて、観念的な話になりそうなので、修正。
実際の話として、GNU Project の文章がついてこない GNU Emacs が配布されるような、そんなディストリビューションがあったら、そんなものは願い下げだ。
マニュアルの多くもついてこなくなる、そんなディストリビューションは、いらない。
Debian の理念とその活動は、そんな馬鹿げたものではなく、社会の利益に有用で自由なものであるはずだ。これまでも、そしてこれからも。
ドキュメントが改変自由だと (スコア:1)
それとプログラムのソースコードは、プログラムの機能を記述する物ですが、ドキュメントは仕様や機能説明の他にライセンスや作成者の思想が記述されています。
仕様や機能を自由に変更されることはGPLの目的に叶いますが、ライセンスや思想まで改変（というか改竄？）されることはどうなのでしょうか？
GPLじゃなくとも (スコア:0)
Re:ドキュメントが改変自由だと (スコア:0)
日刊アスキーLinux の記事 (スコア:1)
Stallman氏の立教大学での講演が掲載されていますが、
そこでの氏が考える（ソフトウェアに対する）「自由」とは、以下の４つを含んでいるとあります。
0、実行する自由
1、自分で修正したり研究したりする自由
2、隣人を助ける自由
3、自分のコミュニティを作る自由
ソフトウェアとドキュメントとでは厳密な意味では同一では無いのかもしれませんが、
自然言語によるプログラミングとか、ソースコードのドキュメント性などを考えると、
全く異質のものとも言い切れない気がします。
そう考えると、自分のコントロール下におく自由が無い、という意味で、
２、の考えに反すると言う点では、
「フリーじゃない」と言うのが、Stallman氏的な解釈と言う事になるのでは無いでしょうか。
オリジンの境界線 (スコア:1, 興味深い)
TCP/IP関連だとRFCが絶対で、それ以外は解釈文でしかないかと。
どこまでがオリジンでどこからがオリジンでないかの境界線って悩ましいなとよく思います、モノカキのハシクレとして。 オフトピなのでAC
Re:オリジンの境界線 (スコア:0)
難しいのはライセンスとしてきれいに線引きできるかどうかっていうところですよね。個人的にはドキュメント系には
文章＝バイナリ (スコア:1, 参考になる)
で、ソースコード（発想やイメージそのもの）は配布できないから、それをコンパイル（文章化）したバイナリコード（文章）だけを配布して、受け取った人がそれを逆アセンブル（読解）して理解をすると。
こう考えると、ソースコードの利用は最初から自由なわけで、あとはバイナリの入手や利用が自由であれば*十分に*自由と言えるのではないでしょうか。
ここで問題になるのは、たとえばある技術についての解説を複数切り張りして総合的な解説書を作るといった場合に、ライセンス条項が利用の妨げになるかどうかといったことでしょうが、文章を切り張りしなくても、自分が理解している内容をまとめて新たに文章を書くこと（ソースの改変＋再コンパイル）はすでに認められているはず（元の文章をただ要約しただけの場合は翻案権の問題に引っかかりますが）なので、実用上問題になるのはバイナリの利用や翻案に関する部分だけのような気がします。
再コンパイル（翻案や切抜きや校正）だけを行った場合についての扱いは難しいところですが、自由な利用を認めたいのであれば、何も修正禁止部分を指定しなくても、通常の出展表記だけで十分なように思います。というよりも、ここを認めないと*完全に*フリーなドキュメントとは言えないような気がします（ということでDevian側の言い分に賛成です）。
# 技術的な解説書などがパブリックドメインのドキュメント（民話や
# 神話の類、ほとんどの古典文学などがこれに当てはまるでしょう）
# のように有機的に「成長」していくという可能性を考えると、
# Devian流のフリードキュメントは画期的な考えだと思います。
ただ、最初に述べた理由（文章の場合ソースコードの利用はもとから自由だし、ソースコードだけを配布することは原理的に不可能）から、GPL的なフリーよりもBSD的なフリー（もっと言えば、現在認められているフェアユースの範囲を拡大するような形でのフリー）の方が馴染みやすいような気がします。
# 最近署名ありのACが増えてきたようでなんとなく仲間意識を
# 感じてみたり。
### ID持ってないのでAC ###
書き忘れ (スコア:0)
謝辞などをそのまま転載することを強要してしまうと、再利用を重ねるうちに（修正前のBSDライセンスにおける広告条項のように）どんどん肥大化してしまうという可能性もあるんじゃないでしょうか。
# ライセンスの条項ちゃんと読み込んでないので
# 見当はずれだったらごめんなさい。
### ID持ってないのでAC ###
不完全性定理 (スコア:1)
Debianプロジェクトの論理を支持する人って, ゲーデルの不完全性定理を考慮しているのかな? 改変可能な文書自体で改変可能性を規定するのは, どうしても自己言及になっちゃいますよね? 普通はメタな規定を入れないと論理として成り立たないと思うのですが.
Re:不完全性定理 (スコア:0)
Re:不完全性定理 (スコア:0)
ライセンス良く嫁 (スコア:0)
野分
GPL と GFDL (スコア:1)
コンパイル言語はソース(元となるもの)とバイナリ(実効果を持つもの)が別々に
なっていますね。スクリプト言語はバイナリが存在せず、ソース=実効果を持つものです。
// ソース=バイナリだという言い方もあるでしょうが、結局は同じ事です。
単純に、上記の性質だけを考えると、ドキュメントもスクリプト言語も同じです。
そして、多くのスクリプトが GPL で配布されています。
GFDL には、GPL を補足するものだ(It complements the GNU General Public License)と
書かれていますが、GFDL に書かれている内容はどれも GPL から容易に導き出せる結論のように見えます。
にも関わらず、あえてドキュメントだけの為に違うランセンスを設ける理由はあるのですか？
もしあるのなら、なぜ GFSL(GNU Free Script License) は無いのでしょう？
// GPL の勉強するために何かドキュメントが欲しいなぁ…。周りに詳しい人いないし…。
// ML を追っかけたりするしかないのかな？
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:GPL と GFDL (スコア:0)
野分
Re:GPL と GFDL (スコア:1)
// ゼミで勉強会でもやろっかなぁ…。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
ドキュメントに限らない (スコア:0)
確かにこれもある種の「制限」ではあるのですが、利用の上での問題とはならないような部分である上に個人的には開発者の署名部分を残してあげたいというのも人情としてとてもよく理解できます。しかし、このあたりの曖昧さのためにときどき著作権表示を故意に外してサイトに利用しているユーザーはかなりたくさんいます。
CGIなどもそうですが、この手のプログラムもドキュメントと同じような問題を抱えています。その辺りについていろんな人に意見を聞いてみたいです。
オフトピック気味ですが (スコア:1)
PHP-Nuke 商用ライセンス [lovemorgue.org]
アレな実例で考える (スコア:0)
「ソースコード内にあるMandrakeという“プログラム”の表記を
nihonLinux”に変更する事を最初のステップとする」 [nihonlinux.jp] と
いうてますが、 Debian Project 的にはＯＫなのでしょうか？
Re:アレな実例で考える (スコア:1)
Re:アレな実例で考える (スコア:0)
ネタニマジレスカコワルイ
#308770とは別AC
Re:アレな実例で考える (スコア:0)
ネタだといわれてもねえ…
「フリー」、「修正の自由」、「入手可能なソース」 (スコア: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]のあたり。
改変版 (スコア:0)
Debian フリーソフトウェアガイドライン [debian.org]によると、「改変版は名前を変更しなければならない」というライセンス条項は、同ガイドラインに反するものではありません。
Debian フリーソフトウェアガイドライン自身は、ライセンスではなく、ライセンスを分類するための条件（いわばメタライセンス）ですので、それ自身が「何もかも...名乗っていいのか」に「いい」「だめ」という答えを与えるものではありません。が、「いい」とするライセンスを持つソフトウェアやドキュメントも、「だめ」とするライセンスを持つソフトウェアやドキュメントも、Debian 的には「フリー」に分類されることになります。
ノンフリーな社会のコンテクストの中で考える (スコア:0)
なってしまうんですが、GPLなりGFDLなりのみを取りあげて自由か
不自由かを議論してもあんまり稔りは得られないのではないでしょうか。
FSFのあれこれって、フリーを体現しているライセンスが
目的なのではなくて、まぁ、不自由な社会とのインターコースの
中で相対的によりましなフリーを獲得するための手段としてある
わけですよね？
とすると自由か不自由かではなくて、よりましな自由の獲得の
ための戦略として優れているかどうかという点を考えないと、
抽象的な自由の理念をめぐる不毛な教義論争にしかならない、と
少なくともDebian vs. FSFという間柄の中ではいえるんじゃないでしょうか？
リンク先のあれこれを拝見している限りでいえば、どうも
教義論争的な不毛に陥っていやしないか、覚束ない感じがします。
そういうところでは、論理的ではなく理論的にはFSFの主張に
理があると私は考えます。
;; イマイチ自分でも整理しきれてないのでAC。
Re:ノンフリーな社会のコンテクストの中で考える (スコア:0)
しかし、FDL にある、部分的な変更禁止条項が、なぜ「非フリー」な世界とたたかうことになるのか、よく理解できません。
FDL の部分的変更禁止は、たんに、ひとの意見をまげて伝えることを禁止しようという意図だと思います。たとえば、ある文章の「yes」と「no」を逆転させるという変更を加えた文章を配布したら、それはまずいでしょう。rmsじゃなくても怒ると思います。しかし、GPL [opensource.jp]
Re:ノンフリーな社会のコンテクストの中で考える (スコア:0)
おっしゃることはおっしゃることでよく理解できるつもりです。
ただ、改変のみが文書における自由なのか、
自由というのが改変を認めることで守られるのか、という
疑問が出てくるように思います。とくに文書という思想表現とも
結びつくものにおいて。
少数者が自分たちの利益を、主張として込めつつ、
有益なマニュアルを書いたとして、
多数者がその主張をフィルタにかけて少数者の利益を無視した
マニュアルに改変してしまったとしたらば、
そういうことを許すライ
ユーザー本位のライセンス (スコア:0)
その反動として、プログラマ／配布者にとっては七面倒臭い決まりごとの多いライセンスとなっているが、それはユーザーの自由を尊重するためにプログラマ／配布者が譲歩している（させられる）ためで、意味もなく制限しているわけではない。
当然、同一人物でも、ユーザーとしての立場の時の自由とプログラマ／配布者の時の自由が異なるので、『自由だけど不自由な』（ある意味奇妙な）ライセンスになっている。
多分、Debian Projectも「ユーザーの自由」という観点をある程度意識していると思う（議論を追いきれていないので何ともいえないけど……）
で、「ユーザーの自由」という観点からFDLを見てみると、『GPLほどは自由じゃ無いよね』というのが実際のところでしょうな。Cover Textはともかく、Invariant Sectionを（再配布時に）変更／削除できないのは、それを受け取るユーザーにとって不自由な／不便なものになる可能性がある。
実例としては、PDA等に収録するためにコンパクトなチュートリアルをユーザーが受け取るケースが考えられる。コンパクトにするため、Cover Text／Invariant Sectionを変更／削除した場合、FDLのライセンス下では配布することができない。もちろん、ユーザーが自分で削除してチュートリアルを完成させることは可能だが、（GPLにはあった）ユーザーの『すぐに利用できるものを受け取る自由』が無くなっていることには変わりはない。
結局、FDLはGPLよりも著作者側に自由の軸足をシフトした（ユーザーに不自由な）ものということができる……と思う。
＃元々FSFはWebページの記載からして「ドキュメントは自由じゃないぞ」と主張しているんだから矛盾してはいないんだけどさ……
乱文失礼
野分