上川純
一
![]() |
今 回 の 事 前 課 題 は 以 下 か ら 自 由 に 選 択 し て 200-800 文 字 で 回 答 す る と い う も の で し た。
この課題に対して提出いただいた内容は以下です。
2.1 堀内寛己僕が好きなソフトウェアライセンスは GPL です。 理由は、 ストールマンが好きだからです。 僕がストールマンのことを知ったのは、 20 年以上前、 東大の和田英一先生の講義をもぐって聞いたときのことです。 先生は、 MIT ハッカーズの堕落と、 そ の中で孤軍奮闘しているストールマンの話をされました。 「でもストールマンは変わりませんねえ。 グニューって知ってますか? みんなタダなんですよ」 先生 が英語の微妙なニュアンスを聞き分けられないわけがないので、 当時のストールマン自身が、 free の 2 つの意味を混同していたらしいことがわかります。 当然 そのころ、 GPL なんてありませんでした。 僕は幸い、 入社まもなく GNU Emacs を使う幸運に恵まれ、 ストールマンへの敬意は確固たるものになり、 その まま GPL のことなど知らずに gcc-2 の make をやったものです。 僕が GPL とその恐るべき意図について知ったのは、 だいぶ後のことです。 Microsoft がこ れをウィルス呼ばわりしたのほ、 さらにその後のことです。 僕は、 ウィルスという表現は、 GPL についての最高の褒め言葉だと思ってい ます。 2.2 山本ひろゆき「データだけのパッケージでできること」 インタープリタ依存のスクリプトパッケージなんかができますかね?今抱えている ITP を片付けたら、 kita2 (ruby スクリプト) を ITP しようかと迷っています。 パッケージング自体はできますが、 ruby を知らないものでメンテナンスが心配。 誰か教 えて! 「ソフトウェアのライセンスで不自由したこと」 某巨大掲示板発祥の開発プロジェクトあたりだと、 有用なソフトウェアだが、 ライセンスは明記されていな く開発者も匿名で確認しようがないということもあります。 「好 き な ソ フ ト ウ ェア ラ イ セ ン ス と そ の 理 由 」 GPL とか BSD ライセンスとか。 DFSG 万歳! 2.3 Suguru Sekine「好きなソフトウェアライセンスとその理由」 [BSD ライセンス] 自由であり続けるために「自由でなければならない」 という制約がない、 かつソースコードの公開を拒む自由があるためである。 私はソフトウェアは自由 であるべきだと考えている。 また、 自由であるための協力もできる限りの協力を行うつもりである。 しかし、 自分が考えている事を他の人に強要したり、 また は強要されたりすることがどうしても我慢できない。 以上のことから自由であることを強要されない点から BSD ライセンスをを評価しているという結論に 至る。 2.4 Yamane Toshiaki「データだけのパッケージでできること」 データだけのパッケージというものが例えばフォントパケジ等を指すという理解で文章を書いてみます。 できること、 ではないかもし れませんが、 自分が使いたいものを選択する自由があると考えます。 あるいは X と xfont なパッケージのようにアプリケーション とデータがそれぞれ互いに依存していない関係にする事ができるのではないか、 と考えます。 データだけのパッケージとそのデータ を使うパッケージ間を疎結合な関係にしておくことによって、 保守とか拡張などの対応を柔軟に行なう事ができるのではないでしょ うか。 2.5 沖中ライセンス的に配布が難しいデータは、 自分でパッケージすることになると思いますが、 データだけのパッケージと言えばフォントが代表的だと思います。 辞 書データもフリーの物が少ないので自分でパッケージ化できたら便利ですね。 それ以外の使い方としては、 Web サイトのドキュメントをパッケージ化して管 理できないか考えています。 そうなるとデータだけとはいきませんが、 スクリプトだとビルド不要なのでデータと同じように扱えるのではと思って ます。 2.6 山根秀樹ソフトウェアのライセンスで不自由したこと 今まさに不自由してます。 いわゆる「フリーフォント」 が巷にはたくさんあるのですが、 みんな「自分で規定しましたライセンス」 が多くて、 二次利用 などがしづらいですね。 作者の方々は善意で策定したんでしょうけど、 「悪いことに使っちゃダメ」 ライセンス みたいなのは勘弁して欲しいです(線引き が曖昧だし、 そもそも悪いことしようとする 人がライセンスを気にすることなんぞ無いわけで、 そんな規定作ること自体が意味ない んで すが…) 。 あとは最近あったのが PHP プロダクトで PHP ライセンスのものとか。 PHP の名称を 使うことをそもそも想定していないんだから、 別のライセンス の方が扱いやすいんですが、 「PHP 使ってるから PHP ライセンス」 なんでしょうかねぇ。 2.7 satoken好きなソフトウェアライセンスとその理由 GPL。 やはり、 ソースが有るっちゅうのは良いもんです。 頑張れば移植もできるし。 でも、 Debian に浸ってからあんまりコンパイルしなくなりまし た。 apt-get install で済んでしまうところが楽なんだけど堕落の始まりかもしれない。 2.8 Hisashi MORITA「データだけのパッケージでできること」 すぐに思いつく例はドキュメント、 辞書、 フォント、 アイコンなど。 あと XML の DTD などもローカルにあると役立ちます(ネットワークアクセスを避け られる) 。 「ソフトウェアのライセンスで不自由したこと」 プロプライエタリなソフトウェアが不自由というのはよくある話ですが、 GNU GPL なソフトウェアで、 CD-ROM に収まらなかったのでバイナリとソー スを別々に配布しようとしたら結構大変だったことがあります(3-b 参照) 。 一緒に配布するのが楽ですね。 「好きなソフトウェアライセンスとその理由」 今は X/MIT スタイルが好みです。 短いので。 2.9 Kobayashi Noritada「ソフトウェアのライセンスで不自由したこと」 開発者が FLOSS の世界に通じており、 開発環境として Debian のようにライセンスに煩いものを用いていると、 広く採用されているライセンスを使用し てもらえるので楽なのですが、 FLOSS の世界に通じていない人が作成したソフトウェアはいい加減なオレオレライセンスになりがちで、 パッケー ジ化しようとしても困るときがあります。 特にフォントなどは必ずしも FLOSS の世界に通じていない人でも作れてしまうので、 こ のような傾向が顕著な気がします。 また、 FLOSS の世界に通じていない人だと、 改変・再配布の自由まではあまり認めたくないとい う人が多く、 パッケージ化の点からは不自由なライセンスを採用しがちな気がします。 そのような意味では、 DFSG-free なライセン スの認知度を高めること、 そして FLOSS の開発の理念を広めることは大切で、 その点で Debian の果たす役割は重要だと考えてい ます。 「好きなソフトウェアライセンスとその理由」 基本的に、 広く採用されていて DFSG-free だと分かっているライセンスが好きです。 その理由としては、 もちろん Debian の公式パッケージにしやすいこ ともありますが、 自分で細かくレビューする必要がないというのが大きいです。 自分で物を公開する場合にも他人の物を使用する場合にも、 その物のライセン スのコンセプトを把握しておかなければなりませんが、 ライセンス文の法的な用語や法的な思考は慣れていないと難しいものです。 そんなときに、 広 く レ ビ ュー さ れ 吟 味 さ れ て い る ラ イ セ ン ス だ と 、 コ ン セ プ ト が 分 か って い る の で 、 自 分 で 細 か い 点 ま で 理 解 し な く て も 安 心 し て 使 え ます。 2.10 Noriaki Sato「好きなソフトウェアライセンスとその理由」 好きなソフトウェアライセンス: GPL その理由: RMS 信者だから その昔、 大学の研究室に配属されて初めて Unix を触って、 emacs (当時は mule2 でした) も初めて使ったのですが、 先輩に借りた emacs の本で GPL とか copyleft の事、 そして RMS の名前を知りました。 「何て素晴らしいんだ!」 そう思っていた時期が私にもありました。 というわけで、 私は GPL が好きなのです。 2.11 鈴木「データだけのパッケージでできること」 フォントとか設定ファイルだけを提供するパッケージかな。 今日の勉強会で学びます。 「ソフトウェアのライセンスで不自由したこと」 ライセンスを語る前にソフトを作ることから離脱しました。 よかったのは、 Tex のクヌース先生のパスカルを読んで、 真似して C で作りました。 あの時は、 そんなこと意識せずにソースが見れたのがよかった。 自分のソースを見られるのが嫌なソフト屋が多かったですね。 ライセンスにあまり関係なくて、 すみま せん。 2.12 藤崎祥見好きなソフトウェアライセンスとその理由 ソフトウェアライセンスはわかりやすいものが好きです。 もし自分が適用するならば、 一般に広く知られているものかわかりやすい条文のものにします。 そ の方が、 配布者・利用者ともにハッピーだと思うからです。 たとえば、 ライセンスを読んだ人が理解できずに質問をする・それに回答するという 労力を、 上記のソフトウェアライセンスを適用することによって避けられます。 ソフトウェアライセンスは理解されてこそ最大の効 力を発揮するので、 理解しやすい・または理解されているものを選ぶというのは優先順位が高い条件ではないでしょうか。 というこ とで、 私は Ruby ライセンスが好きです。 Ruby ライセンスは GPL と Artistic 類似の独自ライセンスのデュアルライセンスです。 この独自ライセンスの条文はやさしく理解しやすいものになっています。 利用者が GPL を理解しているなら GPL を適用すればよ いし、 GPL が難しくてわからない場合でも理解しやすい独自ライセンスの元で利用すれば OK です。 ですが、 松本さんは Matz 日 記で、 Ruby のライセンスがあれなのは
と いう理由ですから、 そういう事情のないソフトウェアがRubyライセンスを適用する必然性はほとんどないと思います。 ということで、 自分のソフトウェアに 安易に Ruby ライセンスを適用しないように。 と書いてらっしゃるので、 今のところ自分が適用するなら X11 かなぁ。 といいつつ 1 年後には変わっているかもしれません。 2.13 CCG「好きなソフトウェアライセンスとその理由」 NYSL。 「煮るなり焼くなり好きなようにしろ」 ライセンスです。 日本の法律では著作権を放棄できないため、 public domain という概念 を適用できないということを聞いたことがあるのですが、 心意気がとても伝わってくるところがたまりません。 NYSL 以外では、 世 に言う修正 BSDL が私の心にあっています (と書くと大袈裟ですね・・・)。 職業プログラマですが、 プログラマとしての最大の喜びは 沢山の人に自分の書いたプログラムを使ってもらえる事、 少しでも便利に生活を送ってもらえる事と考えています。 GPL でもそれは 達成できるかもしれませんが、 書き換えたものの公開を強制することを理由に使うことをためらわれるのであれば、 修正 BSDL にし て (場合によっては LGPL にして) 使ってもらう事を望みます。 好みとは関係ないですが GPL と MPL と CDDL の違いが分かりま せん・・・ 2.14 野村タイトル:「好きなソフトウェアライセンスとその理由」 私が好きなライセンスは BSD ライセンスである。 はじめに断っておくが、 決して GPL が嫌いなわけではない。 私の会社では、 PC に無償のソフトウェアをインストールする際には、 そのソフトウェアのライセンス、 脆弱性について上司に報告し承認をもらう必要があ る (今は面倒なので報告せずに勝手にインストールしているが、 入社したてのころは真面目に報告していた)。 このとき、 オープンソースに明るい上司であれば、 BSD ライセンス/GPL/Apache Software License のソフトは、 「オープンソース系のライセンスです」 と報告すれば一発で許可をもらえるが、 オープンソースに疎い上司だと、 GPL 等に対して変な勘違いをしている場合があり、 「業務で使っても問題ないのか? 個人の使用は無償でも、 業務で使うとお金がかかるとかではないのか?」 といった質問をされたことがある。 恐らく、 どこかで GPL のコピーレフトの仕組み の 説 明 を 見 た 際 に 、 き ち ん と 読 ま ず に 早 と ち り し て し ま い 、 間 違 った 解 釈 を し て い た も の と 思 わ れ る が 、 GPL の説明をゼロからやらされた私にとってはいい 迷惑である。 その点、 BSD ライセンスであれば、 「基本的にどうやって使っても自由です。 ほら、 そう書いてあるでしょう」 と言えば済むので、 GPL よりは説明が楽で ある。 以上が、 私が BSD ライセンスを好む理由である。 2.15 吉田@板橋お題:好きなソフトウェアライセンスとその理由 昨年末に「世界初 (多分) の GPLv3 本」 を発行@コミケしたのもあって GPLv3 が好き... というわけでもありませんが、 いままでは自分が作ったものは、 修正 BSD ライセンスで放流することが多かったのですが、 調べてみると GPLv3 でも悪くは無いと思いました。 (以下、 本一冊分略) さすがにあれだ け話題になっただけあってかなり考えられて作られていますね。 特に、 やりようによっては Apache License 2.0 等の修正 BSD 系 のライセンスからコードを取り込むこともできるようになったのはいい点だと思います。 ついでに、 GPLv2 との互換が無いのが素敵 です。 2.16 前田耕平「データだけのパッケージでできること」 1。 自分で管理しているサイトの構築や運用に必要なスクリプトの配布。 公式パッケージだけでは、 やはりどうしても細かい部分までは行き届かないので、 構築時や運用改善でスクリプトを書きます。 一台二台ならそれを scp など で配布してしまえば良いですが、 台数が増えるとそれが面倒なので、 パッケージにしてしまえと。 各種設定ファイルのパラメータ変更もスクリプト書いて、 パッケージで配布してガツガツ書き換え、 というのも、 小規模なら良いかもしれませんが、 そういうのは寧ろ Puppet などの導入を考えたほうが良いで すね。 2。 複数のアーキテクチャが混在した環境への配布。 1も結局はアーキテクチャに依存しない、 というメリットがあるので作ったスクリプトを違う環境(x86, ppc, arm などなど) でもそのまま使えるのが、 データだけのパッケージの最大のメリットかと。 2.17 Seiji Kurodaソフトウェアのライセンスで不自由したこと 十数年前、 仕事で半年ほどアメリカのボストンに滞在していました。 当時、 現地のレンタルショップで自宅用としてパソコンを借りていました。 実際には plain text でメールの下書きや会社で読みきれない資料を読むくらいでしたので、 もともと入っていた Windows を消して、 日本から持っていったJ−DO SやOS/2のJに入れ替えて使っていました。 しかし、 ノーブランドに近いパソコンのためか、 ハングアップやダウンはしょっちゅうで した。 やむを得ず、 現地のパソコンショップで、 MS DOSのアップグレード版を買ったのですが、 ライセンスがないと売れないというので、 J−DOSのディ スクとライセンス証書(日本語) を持って、 UPGRADE版を売れと迫りました。 ライセンス証書は日本語だったはずで相手が読めるはずもなく、 随分と僕 のほうが無茶な要求をしたものです。 ただ通い始めて三日目に店員が僕の粘りにあきれて、 MS DOSのアップグレード版を売ってくれま した。 いまならこんなことにはならないと、 でも必死になれない英語で粘ったのは、 懐かしい思い出です。 2.18 原田 一範「好きなソフトウェアライセンスとその理由」 好きなソフトウェアライセンスは GPL です。 GPL の「すべてのソフトウェアは自由であるべき」 と言う考え方がシンプルだから好きです。 私はソフト ウェアライセンスには、 できるだけ改変の自由を保証してほしいと思っています。 改変の自由が保証されていれば、 便利な機能を付け加えたり、 改良したりす る際にライセンスによって邪魔されず、 短時間で作業できると考えられるからです。 また、 ソースコードが開示されていれば、 そのソースを参考に新 たなソフトウェアを作ることが可能だし、 初学者がそこから多くのことを学ぶことも可能です。 GPL ならば、 GPL が適用されたソ フトウェアの派生ソフトウェアまで GPL が適用されるため、 改変の自由が保証され続けるという意味で、 良いライセンスだと思い ます。 GPL は自由に関して厳格であるため、 もし自分がライセンスを使用するような状況になったら、 もっと緩いライセンスを使用するかもしれません。 しかし、 GPL のような、 ソフトウェアを使用するユーザーの自由を保証するライセンスは必ず必要だと思うので、 好きなソフトウェアライセンスに GPL を挙げま した。 2.19 日比野啓データだけのパッケージでできること プログラムを含んだパッケージを作ることが多いので、 データだけのパッケージといわれるとあんまりネタが無いんですが、 作ったことがある中で、 大きめのもの は gnujdoc*1 で しょうか。 autoconf, binutils, bison, cvs, diff, emacs, flex, gdb, libtool といった、 GNU のツール群のドキュメントの日本語訳が含まれています。 全部ビルドす ると 60 個以上のパッケージになったりとか、 makeinfo 日本語まわりが変だったことがあったりとか、 なかなか面倒だった記憶があり ます。 ライセンス関係のことをきちんと勉強できていないので、 今回の発表を聞いて勉強させてもらいます。 よろしくお願いします。 2.20 濱野データだけのパッケージでできること 主要な RFC や仕様書がパッケージになっているとぱっと参照するのに便利でしょうか。 辞書データ、 Micropolis(SimCity) の街データ、 そういえばオープ ンソースで開発されたファミコン ROM って在るのかな。 好きなソフトウェアライセンスとその理由 Beerware License とかカッコイイですね、 いつかこのライセンスで当たり障りのないソフトウェアを書いてみたいです。 # debian の main カテゴリには入らないようですね、 残念。 派生ソフトウェアに関する記述が無いからでしょうか。 2.21 奥野由紀ソフトウェアのライセンスで不自由したこと 私がソフトウェアのライセンスで不自由したことといえば、 他にも同じ事を述べられる方がいらっしゃるかもしれませんが、 Microsoft をはじめとする、 プ ロプラエタリなソフトのライセンスです。 Windows は XP からアクティベーションを導入したため、 自作 PC 派にはやりづらいことになってます。 Vista になって一段と再アクティベーションを要 求される条件が厳しくなったそうです。 また、 先日とあるソフトを業務で使用することになったのですが、 一つ前のバージョンまでアクティベーションはありませんでしたが、 最新バージョンに なってからアクティベーションが導入されていました。 ソフトウェアメーカー側としては、 利益の確保のためには止むを得ないことなのでしょうが、 正規ライセンス所持者にも使い勝手が悪くなり ます。 また、 メーカーによっては業務用のボリュームライセンス制度があるところもありますが、 これがまたどのライセンスを選べば良いのかが、 一目見て分かり づらいものが多いです。 以上が、 私がソフトウェアのライセンスで不自由したことです。 2.22 Osamu Matsumotoソフトウェアライセンスについては、 正直あまり真面目に気をつかってコードを書いた事がありません。 GPL2 で公開されていたツールキット をサブセットに分解して GPL2 で公開するといった経験ぐらいです。 特に好きなライセンスはありません(正確には知りません...) が、 Creative Commons Lisence はライセンスに精通していないユーザでも、 目的に合ったライセンスを選択できる点で良いと思い ます。 「データだけのパッケージでできる事」 ですが、 現在の理解ではデータを置く事しかできないんじゃないかと思っちゃいました。 font とか document とか なのかな。 当日、 勉強して帰ります。 2.23 ake「データだけのパッケージでできること」 どういうものがあるのか考えてみました。 とりあえず思いつくままに
こ うやって改めて考えるとデータだけのパッケージって結構重要というか、 無いと困るものがありますね。 で、 「できること」 というと設定に関するものであれ ば何かと重宝するものが作れそうです。 「ソフトウェアのライセンスで不自由したこと」 CAL の数がどうとか、 プロダクトキーがこうとか、 管理するのに手間のかかるライセンスはお金に換算できない (しにくい) コストが掛かるので、 よっぽど 必要なもので無い限り関わりたくないです。 「好きなソフトウェアライセンスとその理由」 フリーなものは大抵大好きです。 無料か有料かではなくて、 自由ってことが重要だと考えますので Debian のライセンスは大好きなものの1つ です。 2.24 キタハラデータだけのパッケージでできること 昔は、 今ほど通信回線が速くなく、 費用も高かったので、 クライアント・サーバ型のシステムでプログラムとは別に、 データをクライアントに配置し、 定期的に更新するシステムなんてのが結構ありました。 当時のマシンでパッケージが使えたら、 バージョン管理もできるし、 便利だっでしょうね。 (業務で 使うには、 別の問題が発生するかもしれませんが・・・。 ) 今でも設定ファイル等、 クライアントに配布したいデータは幾つかあるのですが、 OSがほとんど某窓になってしまったので、 今のところ出番がないで すね。 あとはサーバかな。 設定ファイル等をパッケージにしておくと、 サーバが多数ある場合や、 一から作り直す場合は楽になるかな?どうだ ろう? 2.25 Osamu KimuraYacc や Lex といったパーサジェネレータはソースコードを出力するという性質をもつため、 パーサジェネレータを利用したソフトウェアは使用するパーサ ジェネレータのライセンスに影響される可能性がある。 世の中には Yacc の上位互換ソフトとして byacc と bison というものがある。 実はこの2つは同じ作者(Robert Corbett さん) によって作成されたもの である。 byacc はパブリックドメイン、 bison は GPL である。 (ちなみに byacc の方が後に作成された) だから、 ライセンス問題を動機として (byacc は) 作 成されたのではないかと思われる。 にも関わらずこの2つのソフトウェアは微妙に動きが違ったりする。 オプションの数が違ったり、 出力ファイル名が違った りしている。 ソフトウェアの中にはある環境では byacc を使い、 ある環境では bison を使うという事をしているものがある。 これで何が問題かというと、 自分の使って る OS には Ports とか Package が無いソフトウェアを移植する時に問題が起きる。 こういう問題はマイナーな環境のマイナーな処理系などでは起こったりす るので、 面倒くさい。 私がこの問題に遭遇したのは Cygwin に Fortran 用プリプロセッサ fpp をインストールしようとしたときだ。 FreeBSD の Ports から対応するパッケージ をダウンロードして、 ビルドをかけた時に、 Bison がエラーを出しまくったと言う事があった。 この時は Makefile のパーサを Bison から byacc に変えて解 決した。 2.26 Shi「データだけのパッケージでできること」 自作の音楽や画像、 小説の配布が可能だろうと思います。 コミックマーケットの創作ジャンルなどでは、 印刷費を払って本を制作し、 それを無償配布してい るような人が多数みられます。 従来、 こうしたデータの無償配布は、 Web 上での公開が主ですが、 Web の規模が大きくなった現在、 必ずしも検索エンジンだ けでは追い切れない現状があると思います。 apt 等のパッケージングシステムは、 データに特化したサーバを用意することで、 極めて高効率で データの再配布を可能にすると思います。 最初は壁紙や、 効果音など、 GUI 環境を提供する一環として開始されたら面白いかと思い ます。 2.27 市川憲人データだけのパッケージであっても、 データの中にソースを埋めこむことを許可すれば、 基本的にはプログラムをからなるパッケージができることならばな んでも可能たらしめることができるはずである。 データの中のソースをコンパイラに食わせてプログラムを作成すれば基本的になんでもできるからである。 データとプログラムの境界はないといってよい。 どのようなデータであってもそのデータを解釈する主体が必要であり、 それはプログラムであったり解釈す る機能の一部を人間が担う場合があったりするが、 どのような場合であってもデー タは何らかの目的があって解釈されるはずであり、 その結果は何らかの形 の実行となって帰ってくる。 したがって、 人間を含む実行環境の中において、 およそ全てのデータは実行されるプログラムと考えることがで きる。 |
第
38 回東京エリア Debian 勉強会 2008 年 3 月
____________________________________________________________________________________________