平衡点

_ 次期安定版 Debian 7.0 "Wheezy" での TeX 環境(特に pTeX 環境)について

はじめに

この記事は Debian/Ubuntu JP Advent Calendar 2012 : ATND の 12/02(日) の記事です. 昨日は野首さん(@knok)による Debian Advent Calendar - cron-aptで常に最新状態を保つ | @knok blog でした.

今日のお題は Debian の次期安定版 Debian 7.0 "Wheezy" での TeX 環境(特に pTeX 環境)について, です. 実の所こういう, 話は 既に何度も書いているので, 食傷気味の方もいらっしゃるかもしれませんが, ご容赦下さい.

Wheezy の現状

パッケージの現状は Debian -- 'sid' のサブセクション tex に含まれるソフトウェアパッケージ をご覧下さい, ということになりますが, これだけだとアレですね.

Squeeze から Wheezy に移行した際の(pTeX関連での)大きな変更点は, teTeX から TeXLive への移行です. これまで Debian では, teTeX に pTeX 関連の patch を当てることで ptex-base, ptex-bin といったパッケージを作成/提供してきました. しかし e-pTeX が TeXLive (>= 2011) に取り込まれたことから, これらのパッケージはその役割を終えています.

• e-pTeX Wiki - SourceForge.JP
• Debian -- Package Search Results -- ptex-bin
• Debian -- Package Search Results -- ptex-base

上記リンク先を見てもらえればわかる通り, Wheezy から ptex-bin, ptex-base は texlive-lang-cjk= へ移行するための dummy package となっています.

$ dlocate /usr/bin/ptex
texlive-binaries: /usr/bin/ptex
$ dlocate /usr/bin/eptex
texlive-binaries: /usr/bin/eptex
$ dlocate /usr/bin/platex
texlive-lang-cjk: /usr/bin/platex
$ dlocate /usr/bin/platex
texlive-lang-cjk: /usr/bin/uplatex

e-TeX 拡張に対応した事で, 沢山のご利益があるのですが, UTF-8 で書かれたファイルをplatexで直接処理できる ことなんかもあります. 「Debian の TeX は UTF-8も使えないのかよ」みたいな人にも安心です (主に私が. というか, 単にファイルの文字コードだけの話なら nkf でも噛ませろよ, とか思ったりする訳ですが). レジスタ増えたので tikz でお絵描きとかも気軽にできますし.

問題は, 既存の(古い/重複している)パッケージの整理ができていないことでしょうか?

例えば

• Debian -- sid の dvipsk-ja パッケージに関する詳細
  • texlive-binaries の提供する /usr/bin/dvips には dvipsk-ja のパッチが既に当たっており, このパッケージは不要.
  • texlive-binaries 側で transitional dummy pakcage を提供する様にしてもらい, このパッケージは drop するのが筋
    • ただし現状でも動作に問題は無いので Wheezy+1, かな?
• NTT jTeX を提供するか?
  • メンテナの反応が無く/引き継ぎ手がなく, TeXFam は既に drop された. このまま手を上げる人がいない場合には, NTT jTeX は提供されなくなる
  • Debian -- sid の jtex-base パッケージに関する詳細
  • Debian -- sid の jtex-bin パッケージに関する詳細
• 日本語 BibTeX 関連
  • texlive-binaries において, UTF-8 サポート付きの pbibtex が提供されている.
  • NTT jTeX をサポートしないならば, 以下の二つは不要?
    • Debian -- sid の jbibtex-base パッケージに関する詳細
    • Debian -- sid の jbibtex-bin パッケージに関する詳細

などなど, です. そのうち改善されます/します. 逆に言えば, こんぐらいですかね.

Squeeze からのアップグレード

手元で試した感じでは特に困ることはありませんでした. 安心して dist-upgrade して下さい.

• フォントの設定方法が変わっています(後述).
• 既存の資源をコンパイルする際には注意が必要です. 文字コードを指定する必要があります. 自動判別の仕組みはまだパッケージに入っていません.
  • platex --kanji=euc, pbibtex --kanji=euc といった感じで
• METAPOST に関しては pmpost を使って下さい. jmpost は提供されません.
  • と思ったら, まだあるみたい. これ動くの? 誰か試してる?

Wheezy での新規 install

% sudo apt-get install texlive-lang-cjk

以上. viewer とか, class ファイルなんかも必要に応じて install して下さい. ちなみに奥村先生の新ドキュメントクラス okumura-clsfiles は既に texlive-lang-cjk に含まれています

• Debian -- Package Search Results -- okumura-clsfiles
  • これも drop すべきパッケージですね...
• PDF の viewer は Evince, Okular などを適当なのをお使い下さい. これら二つは SyncTeX をサポートしています.
• 佐々木は最近 Zathura を愛用しています. 残念ながら Wheezy の Zathura は SyncTeX をサポートしていませんが...
  • Debian -- Package Search Results -- zathura
• xdvi の viewer である xdvik-ja は まだ TeXLive に同梱されていないため, 単独パッケージとして提供されます.
  • というか 「 pxdvi は Debian では提供されていないため... 」とか言われて 結構悔しい思いをしていたり.
  • 提供しているからね!! pxdvi 使いたい人は xdvik-ja パッケージを install してね.

インストール後/アップグレード後に必要な作業

個人的には texlive-lang-cjk の hook なんかで対応できたら良いのですが...

/usr/share/texmf/web2c/texmf.cnf を編集して

shell_escape_commands = \
bibtex,bibtex8,bibtexu,pbibtex,upbibtex,biber,\
kpsewhich,\
makeindex,mendex,texindy,\
mpost,pmpost,\
repstopdf,epspdf,extractbb,\

という風に bibtexu, pbibtex, upbibtex, biber, mendex, texindy, pmpost, epspdf, extarctbb を追加しておくと良いでしょう (何をしているのかわからない人は, おまじないだと思って).

コマンド引数として --shell-escape を毎度追加しても良いと思いますが,

フォント制御

使用するフォントの指定やフォント埋め込みの制御は updmap-setup-kanji{,-sys} で一括管理されます.

埋め込まない場合

% sudo updmap-setup-kanji-sys nofont    <-- システム全体で有効化
% updmap-setup-kanji nofont             <-- ~/.texmf-config 以下で設定

これで

• platex → dvipdfmx
• platex → dvips → ps2pdfwr

によって, フォントが埋め込まれていない ps とか pdf が生成できます. dvips で PDF を生成する際のフォントに関しては Ghostscript の管轄です. これは後述.

埋め込む場合

埋め込み用のマップファイルとして IPAフォント, IPAexフォント, ヒラギノフォント, 小塚フォントの マップファイルが提供されています. ヒラギノと小塚は売り物なので, 購入しなければ使えませんが, IPA{,ex}フォントは apt-get でインストールしておけば使えます.

% sudo updmap-setup-kanji-sys ipa    <-- システム全体で有効化
% updmap-setup-kanji ipa             <-- ~/.texmf-config 以下で設定

といった塩梅で.

この設定で dvips を使うと, PostScript に IPAフォントの名前が埋め込 まれます. PostScript から ps2pdfwr で PDF を生成する際のフォント埋め込みの制御は Ghostscript の範疇ですね. ここで好みのフォントを使用したい場合には cidfmap の設定が必要です. Ghostscript - TeX Wiki なんかを参考に, /etc/ghostscript/cidfmap.d/ 以下に必要なファイル片を置いてから

% sudo update-gsfontmap

して下さい.

ヒラギノや小塚を使ったり, 売り物のフォントを使用したい場合には ヒラギノフォントを /usr/local/shate/texmf/fonts/opentype/ あたりに置いて

% sudo mktexlsr
% sudo updmap-setup-kanji-sys hiragino

とかやると良いと思います. 実際に置くフォントのファイル名は /usr/share/texlive/texmf-dist/fonts/map/dvipdfmx/jfontmaps/ 以下の map ファイルを眺めて下さい.

Ubuntu

TeXLive 関連は universe ですね. LTS 12.04 は, Squeeze 相当なので, Quanal Quetzal か Raring Ringtail を使うと, Wheezy/Sid 相当の TeXLive が導入されます(多分).

12.04 の場合は...

• tlmgr (TeXLive のパッケージマネージャ)
• tlptexlive (外部リポジトリ, pxdvi, pmpost を提供)

を使うことになりますかね.

これについてはそのうち書きます(というか, 書く必要があるので...).

まとめ...?

というわけで, Wheezy での TeX 関連のお話でした. パッケージの整理が今後の課題…なのかな? あ, そういえば NTT jTeX のメンテナを募集しています . Debian と NTT jTeX に愛のある方, ご連絡下さい.

明日は岩松さん(@iwamatsu) による記事の予定です.

_ Ubuntu 12.04/Debian Squeeze での TeXLive (>=2012) 環境

この記事は TeX & LaTeX Advent Calendar の 12/08 の記事です. 昨日は黒木さん(@kuroky_plus)の「TUG2013への参加のすすめ」でした.

「何か書きます。多分。」とか, 書いておきながらネタで悩んでしまいました. 今日のお話は前回のお話 に続いて, Ubuntu 12.04 LTS での TeX 環境のお話です.

Ubuntu 12.04 LTS (もしくは Debian squeeze) の TeX 環境

以前, ～師範、組版システム「TeX」について教えてください！～ 行っとけ! Ubuntu 道場, 第60回 でもちょっと触れましたが, Ubuntu 12.04 LTS のパッケージで提供されている TeX 環境は Debian Squeeze 相当, つまり TeXLive 2009 と teTeX + pTeX patch です. ですので, このままでは 「Ubuntu の TeX は UTF-8 のファイルを処理できないかよ, (　｀д´) ケッ!」みたいな人に 「まあ, 落ち着けよ. nkf でも使えよ」という返答をし続けなければなりません(何度か書いてますが, かなりアレな気分になってるわけです).

そこで, TeXLive のインストーラ/マネージャを使用して最新の TeXLive 環境を導入すれば良いですね, となります.

その前に equivs で仮想パッケージを作りましょう

tlmgr を使った TeXLive 環境の構築については後で触れますが, その前に equivs についてちょっと触れておきます.

equivs って何?

Debian/Ubuntu で提供されているパッケージのうち, texlive に依存するパッケージはかなり沢山あります. tlmgr で最新の TeXLive 環境を導入して幸せになっていたつもりが, 他のパッケージの依存関係に引きづられて, 古い(パッケージで提供されている)TeX環境も導入され, 気がついたらどっちを実行しているのか良くわからなくなった, なんて事もあるかもしれません.

そこで, 依存関係を解消するため だけ のダミーパッケージを作成しましょう. そのために使用するのが equivs です.

で, どうするの?

equivs を使ったダミーパッケージの作成については TeXLive 本家の TeX Live and Debian/Ubuntu に書かれています. ここでは, それを抜粋します. また, ファイルの編集を省くために(簡単のため)上記ページに置かれている サンプル をそのまま使うことにします.

$ sudo apt-get install equivs
$ wget http://www.tug.org/texlive/files/debian-control-ex.txt
$ equivs-build debian-control-ex.txt
$ sudo dpkg -i texlive-local_2011-1~1_all.deb

以上で, 依存関係を解決するためだけのダミーパッケージ texlive-local が導入されました. このパッケージは実際には何のファイルも提供していませんが, 他のパッケージを導入する際の依存関係を解消してくれます.

tlmgr で TeXLive 環境を導入

tcl/tk で書かれた, TeXLive 用のパッケージマネージャである tlmgr で 最新の TeXLive 環境を導入しましょう.

$ wget http://ftp.naist.jp/pub/CTAN/systems/texlive/tlnet/install-tl-unx.tar.gz
$ tar xvf install-tl-unx.tar.gz
$ cd install-tl-YYYYMMDD       <-- 日付のディレクトリができます.
$ sudo ./install-tl \
  --repository http://ftp.naist.jp/pub/CTAN/systems/texlive/tlnet/

実行すると, 幾つかデフォルトの設定が表示されます. デフォルトのままで良いので I を押して install を開始しましょう.

...
Actions:
<I> start installation to hard disk
<H> help
<Q> quit

それなりに時間がかかるので, 気長にまちましょう.

インストールが終わったら path を更新します.

• 32bit 環境の場合

  $ sudo /usr/local/texlive/2012/bin/i386-linux/tlmgr path add

• 64bit 環境の場合

  $ sudo /usr/local/texlive/2012/bin/x86_64-linux/tlmgr path add

終わったら tlmgr を一度実行して, 状況を眺めてみるのも良いかもしれません.

続いて, 日本語化された xdvi(pxdvi), metapost(pmetapost) を tlptexliveリポジトリ からインストールします.

$ sudo tlmgr update --self --all
$ sudo tlmgr repository add http://www.tug.org/~preining/tlptexlive/ tlptexlive
$ sudo touch /usr/local/texlive/texmf-local/tlpkg/pinning.txt
$ echo 'tlptexlive:pxdvi*,pmetapost*' | sudo tee -a /usr/local/texlive/texmf-local/tlpkg/pinning.txt
$ sudo tlmgr install pxdvi pmetapost
$ sudo tlmgr path add

以上で, Debian/Ubuntu のパッケージシステムの依存関係を解消しつつ, 最新の TeXLive 環境を導入することができました.

インストール先は

$ /usr/local/texlive/2012

以下になります. tlmgr path add によって, /usr/local/bin 以下に 実行ファイルのシンボリックリンクが作成されていますので, 実行の際に path を追加する, といった作業は必要ありません.

注意点

ディストリビューションのアップグレードの場合 (Squeeze -> Wheezy, 12.04 -> 12.10) の場合には, 一度

$ sudo tlmgr remove path
$ sudo dpkg --purge texlive-local

によって,

• tlmgr によって導入された TeXLive のシンボリックリンクを削除
• equivs によって作成/導入した texlive-local の削除

を行なってから, アップグレード -> TeX 環境の(パッケージからの)新規インストールを 行なった方が良いと思います.

試していませんが, 祟りがあるかも...

まとめ

書いた後に TeX Wiki - Linux/Ubuntu を見たら, TeX Live Backports PPA がありますね (てか, equivs 以外は, かなりしっかり書かれていて, この記事の存在意義がががが).

ただし, PPA はサイズ制限がある (TeXLive 関連のパッケージを全部提供するのは無理)ので, pTeX 関連までは提供できていないみたいです. もし真面目に(全ての TeX 関連のパッケージの) PPA を提供するのであれば, チームを組んでサイズ上限について Canonical と交渉することになるのかもしれません. 誰か気力のある人がいらっしゃるなら, 協力します. ご連絡下さい.

明日(もう今日かな?)は吉村優さん(@yoshimura_yuu)の予定です.

_ fortran 95/2003 explained

注文したのがようやく届いたので, ちまちまと眺めている.

Fortran 95/2003 Explained (Numerical Mathematics and Scientific Computation)
Metcalf, Michael, Oxford Univ Pr, ￥2,392

_ 陰陽座 - 絶界演舞

遅れ馳せながら, 購入したのが届いた.

絶界演舞(完全限定プレス盤) [DVD]
陰陽座, キングレコード, ￥4,500

_ .gem から .deb へ 〜 gem2deb の紹介

はじめに

この記事は Debian/Ubuntu JP Advent Calendar 2012 : ATND の 12/10(月) の記事です(しかし, これを書いているのは 12/11 である, という...). 昨日はあかべさん(@vbkaisetsu)による nmudiff の使い方 でした.

今日のお題は Debian(>=Wheezy)/Ubunut(>=Precise) で「.gem をお手軽に .deb に」というお話です. 実際にお手軽にできるかは, その .gem の依存関係によりますが...

.gem って? .deb って?

Ruby 用のパッケージシステム RubyGems で使われるファイルの拡張子が .gem です. 実態は tar の archive で, これを展開すると data.tar.gz{,.sig}, metadata.gz{,.sig} が入っています. gem コマンドは metadata の内容に従って, .gem を処理しています.

Debian における配布パッケージの拡張子が .deb です. 中身は ar の archive で, debian-binary, control.tar.gz, data.tar.gz からなります. apt-get などでファイルを取得した後に, 下層で dpkg が動いて, .deb を処理します.

gem2deb って?

そのものズバリ, .gem を .deb に変換するコマンドです.

RubyGems 自体がパッケージシステムですので, 別にわざわざ面倒な作業をしなくても良いじゃないか, という話もありますがパッケージシステムは一つの方が嬉しい (こともあります)よね, ということで.

ちなみに Perl の場合, CPAN で配布されているモジュールを .deb に変換する dh-make-perl なんてものが用意されています. gem2deb はこの Ruby 版だと思って下さい.

gem2deb ってどう使うの?

とりあえず

$ sudo apt-get install gem2deb

してから,

$ gem fetch hogehoge

で .gem をダウンロードして下さい. その後, おもむろに

$ gem2deb hogehoge.gem

とします. うまく行けばこれで ruby-hogehoge という Debian パッケージ(.deb)ができます. その後おもむろに

$ sudo dpkg -i ruby-hogehoge*.deb

とすると, Debian パッケージとして導入されます.

.deb ができなかった Yo!!

残念ですね. なんででしょうか? 多くの場合は test に失敗したから だと思いますが, 如何でしょうか?

理由は幾つか考えられます.

test/spec に使う Ruby ライブラリが導入されていない

metadata や .gemspec を見て, 必要な環境を整えましょう. 一応, Gemfile, metadata, .gemspec を見て, test/spec の実行に必要そうなライブラリは debian/control ファイル内の Build-Depends フィールドに 列挙されています. これを確認してみましょう.

test/spec が特定のディレクトリ構造やRuby 以外の環境に依存していて =gem2deb= が提供している test-runner ではそもそもtest/spec が実行できない

必要に応じて patch 書きましょう. もしくは debian/rules 内の IGNORE から始まる行を有効にするのが良いと思います.

• test/ 以下で実行されることを前提として, 相対パスで必要なライブラリを読み込んでいたりする gem とか?
• .git を参照して spec を実行する gem もあったり(当然 .git は配布物の中には含まれておりません).
  • まあ, gem として配布する際には test 走らせることは無いのかな...

ruby1.8 では動かない, もしくは ruby (>= 1.9) では動かない

現状, Debian Ruby Extra チームでは 「複数の ruby 実装で動作すること」を目標にしています. /usr/bin/ruby は, alternatives で提供されていて, 使いたい ruby の実装を切り変えられるようになっています.

• とはいえ, JRuby は Java チームの管轄なので, まだ上記範疇には入っていないですし, rubinius は(ITP されて進展していますが)まだ Debian パッケージには なっていません.

とりあえず debian/control 内の XS-Ruby-Version を適宜弄りましょう. デフォルトでは all になっているでしょうから, これを ruby1.8 とか ruby1.9.1 に変えると良いと思います.

そういや以前(関西闇Rubyかな?), 「Ruby 1.9.3 なのに実行バイナリの名前が ruby1.9.1 なのはなんで?」 とか聞かれましたが, soname 変わってないから, ですね.

$ ruby1.9.1 -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

うーん...

まとめ

というわけで, あんまり gem2deb が知られていないようなので, 「こういうモノもあるよ?」というお話を書いてみました.

Teams/Ruby/Packaging には, 現在 Teams/Ruby が行なっている「 gem2deb によるパッケージ作成」の ノウハウがまとまっていますので, Debian パッケージ作成に興味があって, Ruby への愛に溢れている人は, 是非一度眺めてみて下さい (ついでに, 一緒に Debian パッケージを作成/管理しませんか?).

あと gem を配布している/作成している方は 一度 Teams/Ruby/RubyExtras/UpstreamDevelopers なんかを眺めてみて下さると幸いです. ディストリビューションのパッケージメンテナってこんな事気にしてんのかよ, とか, そういう.

最後に一言. gem の配布物って dependency hell 多過ぎじゃない?

明日も罰ゲームで私の予定です.

_ live-build による Live システムの作成

始めに

この記事は Debian/Ubuntu JP Advent Calendar 2012 : ATND の 12/11(月) の記事です. 昨日の分も私が書きましたが, 「.gem から .deb へ 〜 gem2deb の紹介」でした.

live-build は, Debian/Ubuntu のライブシステム(DVD, USB, PXEブートなどで動く, インストールせずに使う環境)を作るための bash スクリプト群です. version 1.x 系列では live-helper という名前でしたが, version 2.x になってから live-build と名前が変わっています.

live-build に関しては, のがたさん(@nogajun)による Debian Liveメモ とか, 同じくのがたさんの 第113回　Debian Liveのlive-helperを使ってUbuntu Liveを作成する：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社 にかなりまとまっているので, 特に記事にすることも無いかと思っていましたが, 最近の live-build は version 3.x になっていて, パラメータやディレクトリ構成が大きく変わっています.

以下では, これをごく簡単に紹介します(きっとのがたさんが補完してくれる, はず).

live-build を導入する

先ずお手元に 作りたい CPU ターゲット の wheezy/sid 環境を用意して, live-build の最新版をインストールしましょう. モノは bash スクリプト群なので, 依存関係で困る事は(多分)無いと思います.

$ git clone git://live.debian.net/git/live-build.git
$ cd live-build
$ debuild -rfakeroot -uc -us
...
$ cd ..
$ sudo dpkg -i live-build_3.0*_all.deb

これで live-build が導入できたと思います.

live-build でライブイメージを作成する.

i386 環境で作業すると i386 のイメージが, amd64 環境で作業すると amd64 のイメージが作成されます. 環境が用意できない場合には KVM or QEMU で仮想環境を作ると良いと思います (ちなみに, 以前 VirtualBox 上で試したら, 途中で転びました. なんでかな?. KVM/QEMU では, 特に問題無くイメージが作成できました).

作業ディレクトリ(以下では ~/work としています)に移動して

$ lb config
$ sudo -s
# lb build

と唱えましょう. ちょっと時間がかかりますが, 最小限の live イメージが作成されます(イメージをライブ用に squashfs に圧縮するのにそれなりに時間がかかります).

カスタマイズ

$ man lb config

で沢山オプションが表示されます. これを参考に, いろいろ弄って行きます.

auto ディレクトリ

先ず, auto というディレクトリを作成し, その下に config という sh スクリプトを置き, 実行権限を与えます. このファイルが lb config の際に実行されます. config の中で常に有効にする設定をしておくと, いろいろ捗るでしょう.

同様に build とか clean などを置くと, lb build や, lb clean の際に, それらの sh スクリプトが実行されます.

config ディレクトリ

ライブシステムの設定は config ディレクトリで行ないます. 例えば

• config/package-lists というディレクトリを作成し,
• 拡張子 .chroot で適当なファイル名を作成し,
• そのファイル内に, インストールしておきたいパッケージ名を書いておく

なんてすると, lb build 時に必要なパッケージを導入してくれたりします.

具体例

例えば

• live-systems.org Gitweb - debian-gnome-desktop.git/summary
• live-systems.org Gitweb - debian-xfce-desktop.git/summary

なんか如何でしょうか?

これに付け加えて,

• lb config 実行時に,

  $ lb config \
    --bootappend-live \
      "boot=live config locales=ja_JP.UTF-8 keyboard-layouts=jp

とする(もしくは auto/config に書いておく).

• config/package-lists/japanese-desktop.chroot なんてファイルを用意して 中身に

  task-japanese
  task-japanese-desktop

なんて書いておく

• lb build でイメージ作成

なんてすると, 日本語 Gnome/Xfce 環境のライブシステムができます.

まとめ

live-build は開発が活発で, 結構頻繁に機能が追加/変更/削除されています (互換性は残して欲しい, とか思ったりもしたりして). 興味のある方は Debian Live Project の ML を眺めたり, ここで公開されている Debian Live Manual なんかを参照して下さい.

live-installer を有効にしてから バリバリに気合入れてカスタマイズしてライブを作成しておくと, 自分好みの素敵環境を一瞬で構築できるインストーラに早変りしたりします (複数台の計算機に install する際にかなり重宝しました).

そんなこんなで.

明日は...誰?

_ mikutterのライセンスとか.

はじめに

この記事は mikutterアドベントカレンダー の 12/18 日分の記事です. ネタ以外のなんでもありません. 昨日は @iorivur の mikutterアドベントカレンダー17日め でした.

まあ, 昨日のうちにサーバに上げてはいたんだが, 公開設定忘れていたよ, みたいな. 順調に「ておくれ」ています.

普段 twitter は atig.rb : Another Twitter Irc Gateway と WeeChat, the extensible chat client から閲覧/更新しているので, mikutter は ネタとしてしか 使っていません. まあ, twitter のガイドラインも変更になった事ですし, そのうちコマンドラインから使えるようにゴニョゴニョして使うように なるかもしれません(し, しないかもしれません).

以前から手元で使うために mikutter の svn head を Debian パッケージにして使っていました. 最近Debian Developerである @dai_lxr さんが, mikutterを, Debianの公式パッケージにしようと, 作業して, いらっしゃるわけですが.

こういうソフトウェアをディストリビュータとして配布できる形にするのは とっても大変ですよね, みたいな気持です. それはそれとして.

ライセンス?

本家で「GPL3で浄化されています」とあります.

• vendor 以下には別ライセンスのソフトウェアが幾つかあります. 見てませんが, これらが矛盾していないなら, 全体として GPL-3?
• core/skin/data/icon.png は, アイコンでしょうか? 初音ミクさんおよびその派生物は CC BY-NC と PCL(ピアプロ・キャラクターライセンス) の デュアルライセンスですね.
• core/skin/data/twitter-bird.png は twitter のロゴですね. 詳細は Twitter / ロゴとブランド にあります.

…ええっと...浄化, されてるのかな...?

「カタイこと言うなや」って?

そういう問題ではありません.

なんでこんな事をわざわざ書いたん?

初音ミクさんが CC BY-NC と PCL(ピアプロ・キャラクターライセンス) のデュアルライセンスになったと聞いて.

実のところ, 「大丈夫なん?」と何度か会話しているわけですが. こうして指摘しておくとナイスガイ @toshi_a によって 綺麗に浄化されるに違いないと思います.

まとめ

以上, まとまってませんが. 皆さん楽しい mikutter life を.

明日 12/19 はたくみんさん(@uho_www)の予定です.