論文紹介: The Evolution of C Programming Practices: A Study of the Unix Operating System 1973–2015
ICSE 2016勉強会に参加するために論文リストを確認していたら、40年間のC言語のプラクティスの変遷を追った論文がおもしろかったので紹介する。
対象の論文
- 論文: The Evolution of C Programming Practices: A Study of the Unix Operating System 1973–2015
- 論文中で使われれたデータ: https://github.com/dspinellis/unix-history-repo
要約
過去40年間のUnixのソースコードを分析し、コーディングスタイルの変化を調査した。その結果、以下のことが分かった。
分析対象
1972年以降にリリースされた計66個のUnixを対象とする。 これには以下のものが含まれる。
分析したリリースをタイムラインにまとめると以下のようになる。
(Figure 1: Timeline of indicative analyzed revisions and milestones. in Proc. of ICSE '16, p.754)
立てた仮説と結果
事前に立てた仮説と、分析によりその仮説が支持されたかどうかについて述べる。
なお以下に示すグラフは Figure 2: Long term evolution of programming practices. (Metrics appear in alphabetical order; the number following the metric name is adjusted R2). in Proc. of ICSE '16, p.755からの引用である。
H1: 技術の進歩によって、プログラミングプラクティスは変化する
画面解像度や通信速度などの向上にともない、識別子や行が長くなっていくと考えた。
分析の結果、以下の平均値が増加していることが分かった。
- ファイル行数 (FILINE)
- ファイル内のステートメント数 (FISTMT)
- 行の長さ(文字数) (LICHAR)
- 識別子の長さ (IDCHAR)
一方、関数の平均行数(FULINE)はこの仮説と関連しているが、途中から減少している。これは複雑になりすぎたことへの反応であると考えられる。これに関してはH6で議論する。
これらにより仮説は支持された。
H2: コードの規模とともにモジュール性が増す
コード規模が増えるにつれて、開発者はモジュール化を進めるのではないかと考えた。
分析の結果、可視性を制御するためのstatic(DSTATIC)が増加していき上限値に達していたことが分かった。最近、若干減少しているのは、カーネルモジュールや共有ライブラリといった言語外の仕組みが導入されたためと考えられる。
これらにより仮説は支持された。
H3: 新しい言語機能は一定数に達するまで使用が増加していく
unsignedキーワードといった新しい言語機能は、使用箇所が増えていき飽和点に達すると考えた。
分析した結果、以下のキーワードの使用は増加していることが分かった。
- const(DCONST)
- enum(DENUM)
- inline(DINL)
- unsigned(DUNS)
- void(DVOID)
- volatile(DVOL)
基本的に上昇傾向だが、 enumとinline は部分的に下降している。開発者が態度が変化した時期があると考えられる。
unsigned はここ数年で減少している。 これは以下の2つの要因が考えられる。
- size_t が導入され、それが使われる箇所が増えた。
- 64ビットアーキテクチャが導入され、扱える数値の幅を広げるために unsigned が使われることが減った
signed(DSIGN)はあまり使われていない。signedキーワードはchar型に符号付きの値を格納する際に利用できるが、現在では必要になることはない。
これらにより「その言語機能が便利ならば」という限定付きで仮説は支持された。
H4: 開発者はコンパイラのレジスタ割り当てを信頼している
コンパイラ技術が発展しレジスタ割り当てが改善するにつれて、開発者はコンパイラのレジスタ割り当てを信頼するようになっていったと考えた。
分析の結果、registerキーワードの使用(DREG)は1990年ごろから減少していることが分かった。
H5: コードの書き方は収束していく
Unixという一つのプロジェクトで作業してるため、共通のコーディングスタイルが採用され、コードベースは均一になっていくと考えた。
分析した結果、コードフォーマットのばらつき(FMINC)やインデントのばらつき(INDEV)は減少していったことが分かった。
これにより仮説は強く支持された。
H6: ソフトウェアの複雑性には自己修正機構が働く
ソフトウェアが進歩に複雑性は増し、人間の限界を越えてしまう。 そのため、成功したプロジェクトでは複雑性を減少させる自己修正機構が働くと考えた。
分析した結果、以下の項目が、いったん複雑性を増したのち減少に転じるというパターンを示した。
goto(DGOTO)についても同様のことが言える。 gotoは長期間減少しつづけていたが最近は増加している。 gotoの有用性に気付いたのかもしれない。
H7: コードの可読性は増す
開発者コミュニティで管理しやすくするために、可読性は増していくと考えた。
これを調べるために、以下の項目を分析した。
- インデントのためのスペースの平均値(INSPC)
- ステートメントの密度(DSTMT)
- コメントの文字数の密度(DCMCHAR)
- コメントの文字数の平均値(CMCHAR)
- コメントの密度(DCM)
- TODOコメントの密度(DKLUDGE)
コメントの密度とコメントの文字数の密度が増加したのち減少しているのは、より長い識別子が使えるようになって、自己文書化が進んだためと考えられる。
ステートメントの密度は減少傾向にあるが、2000年ごろから増加している。これはコメントのついていないステートメントが増えていることを示す。インデントのためのスペースの平均値も減少していたものの、最近は増加している。 そのため、Unixのソースコードの可読性が今も増加していることの確証は得られなかった。
まとめ
長年にわたるUnixの発展を追跡することで、Unixの開発者が以下のことを行なってきたことが分かった。
- ハードウェアの進歩にあわせてコーディングスタイルを変化させる
- 複雑度が増すにしたがいモジュール化を促進させる
- 価値のある新しい言語機能を採用する
- コンパイラにレジスタ割り当てをまかせる
- コードの書き方に関して合意に達する
また、ソフトウェアの複雑性と自己修復機構が関連していることと、文書によるコード構成の改善が頭打ちになっていることも発見した。
🍓 橘ありす分類器
GWに日光に開発合宿に行ってきた。
「機械学習で遊ぼう」をテーマにしたので、橘ありす分類器を@banjunと作成した。
成果物
m@gic-with-arisu from MIZUNO Hiroki on Vimeo.
ありすには青枠を、それ以外には赤枠を表示している。
宿
日光東照宮至近の炭火焼きの宿・ペンションはじめのいっぽに宿泊した。開発合宿に理解のある宿でよかった。ただ、理解があるあまり「昨日は成果でましたか?」と聞かれてつらい思いもした。 進捗を聞かれるより、成果を聞かれるほうが厳しい。
また旧型のiMacがあってよかった。起動したらバージョン1のSafariや、Mac版のIEが入ってて楽しかった。
ありすの調達
@banjunがデレステのガシャを引きまくって、SSRありすを調達した。
限定SSRというのは,やばい (いまここ)
— ばんじゅん(!!) (@banjun) 2016年4月30日
v えへへ‥SSR4枚も引けたから満足です‥ v pic.twitter.com/Sx5mHyaXic
— ばんじゅん(!!) (@banjun) 2016年4月30日
ありすはちょろ・・・クールだな! #デレステ pic.twitter.com/B0oG6ZXHWC
— ばんじゅん(!!) (@banjun) 2016年5月1日
学習データの作成
学習データとしてAngelBreezeとTulipのMVを撮影したのち、顔画像を切り出して学習データを作成した。
顔画像の切り出しはOpenCVによるアニメ顔検出ならlbpcascade_animeface.xml - デーを用いた。また毎フレームを切り出すと多くなりすぎるため、ある程度間引いている。
切り出した顔画像がありすかそうでないかを入力するために、専用のiPhoneアプリを作成した。データの更新や反映を容易にするようDropboxと連携できるようになっている。
ありす分類器がだいぶ洗練されてきた。 pic.twitter.com/jE7B2jcLIZ
— mzp (@mzp) 2016年5月4日
- 顔画像の切り出し: https://github.com/mzp/arisu-in-fact/blob/master/split.py
- 学習データの作成: https://github.com/banjun/arisu-in-fact
このタイミングで大量の顔画像が手に入って楽しかった。
学習
ありす画像が117枚、非ありす画像が107枚得られたので、機械学習によって分類器を作成した。このとき用いたモデルは4コマ漫画の画像管理✨ - みずぴー日記と同様のものである。
分類
学習に用いたMVとは別にM@GICのMVを撮影し、各フレームの各顔画像に対してありす・非ありすの分類を行なった。 そして得られた結果を元に、動画を合成した。
その他
see_no_evil
せっかくの日光なので🙈(:see_no_evil:)の実物を見て、闇のようなコードと戦う気持ちを新たにした。
🙉🙊🙈 pic.twitter.com/p6fPST6nyU
— mzp (@mzp) 2016年5月5日
いちご
ありすといえばいちご、ということで完成したあとにいちごを食べに行った。
より正確には、インターネットでいちごパフェを出している店を調べて向ったがすでに潰れたあとで、どうしようかなぁとふらふらしてたら、たまたまいちごを路上販売してたので買って食べた。
レポジトリ名の由来
iTerm2 + AquaSKK
要約
iTerm2のmasterにAquaSKK対応入った。l とかで英数に切り替えようとしたときなどに、文字が入力されてしまう問題への対処。デフォルトはOFFになってるので、Preferences -> AdvancedでAquaSKKと検索して、Yesに設定する必要がある。
— 武藤スナイパーカスタム (@__tai2__) May 15, 2016
経緯
iTerm2 + AquaSKKには、l/L/q/Qで入力モードを切り替えるとその文字も入力されてしまう問題がある。(参考: iTerm2/Apple TerminalでAquaSKKを使う - みずぴー日記)
これを修正するPull requestを @__tai2__が作ってくれたので、取り込むための各種議論に参加していた。
そのPull requestが本日(2016/5/15)masterに取り込まれたので、次回のNightly BuildsやTest Releasesとともにリリースされるはず。
闇
「このAppleのドキュメントには、キーが押されたらテキストが入力されるか、ショッートカットキーが発動するって書いてある」「こっちのドキュメントにはInputMethodにそんな制限は書いてないけら、どちらも呼ばないのもありのはずだ」という闇のような議論がはじまった
— mzp (@mzp) 2016年4月23日
OS XのTextEditでnを長押ししたときの挙動がInputMethodによって違うってマジかよ...。日本語入力の英数モードだとnがリピートされて、US配列モードだとñ や ń とかの選択肢がでる。 pic.twitter.com/KQhJZvBjXH
— mzp (@mzp) 2016年5月13日
🇯🇵 SJIS/EUC-JPのテキストファイルをQuick Lookする
QuickLook便利なんだけど、SJISやEUC-JPのテキストファイルが見れないのが面倒だな
— mzp (@mzp) 2016年5月7日
SJIS/EUC-JPのテキストファイルをQuick Lookできないのが不便なので、プラグインを書いた。
ダウンロード
https://github.com/mzp/qltext-jp
実装
Quick Lookされたときにエンコードの自動判定を行ない、その後の表示はシステムにまかせている。
実装は以下のプラグインを参考にした。
また文字コードの判定は以下のコードを用いている。
他の方法
xattr
xattr
で拡張属性を設定すれば特にプラグインをいれなくても、Quick Lookできる。(参考: Mac の Quick Look をちょっとだけ快適に – xattr 編 – (フェンリル | デベロッパーズブログ))
xattr -w com.apple.TextEncoding "SHIFT_JIS;2561" README.txt
が、毎回これをやるのは大変なので、Quick Lookプラグインを作成した。
quicklook-jptxt
GitHub - ento/quicklook-jptxt: Quick Look plugin for public.plain-text with better encoding handling. を使えば同等のことができる。文字コード判定が微妙に違うくらい。
これでダメな理由は特にないが、まあ作りかけてしまったので完成させてしまった。
その他
最近はSJISのファイルってあまりないよね。
sjisのファイルないけど
— ばんじゅん(!!) (@banjun) 2016年5月7日
AquaSKK 4.4.0: 互換性のための設定画面追加
AquaSKKが正しく動作しないアプリケーションのための設定画面を追加し、AquaSKK 4.4.0をリリースした。
ダウンロード
https://github.com/codefirst/aquaskk/releases/tag/4.4.0
変更点
一部のアプリケーションでは、l/Lによる入力モード切り替えが動作しないため、特別な回避策が必要となる。
これまでのバージョンでは、回避策を適用するアプリケーションリストをコード中に直接記述していた。 そのため、アプリケーションリストを更新するためにAquaSKK本体の更新が必要となっていた。
この対応がだんだんと厳しくなってきたので、設定画面からアプリケーションリストを更新できるようにした。
余談: 名称の由来
基本的に回避策は意味がよくわからないことをしているため、設定画面のラベル名を決めるのが大変だった。 最終的に結城(@hyuki)氏の案を採用した。
@mzp 露払後確定
— 結城浩 (@hyuki) April 23, 2016
余談: お願い
この設定はあくまで回避策なので、できる限りそのアプリケーション側にバグレポートを送信してほしい。 闇に闇を積み重ねるのはよくない。
SKK辞書の闇への対応状況
SKK-JISYO.lispで書いたようにSKKの辞書形式にはいくつかの闇(=歴史的経緯による複雑な仕様)を抱えている。
この闇に対して、SKKの各実装がどう対応をしているかを調べた。
調べた実装
- fcitx-skk 0.1.1-1.1 *1
- uim-skk 1.8.6-15
- eskk.vim e990b81
- CorvusSKK 2.3.3
- SKK日本語入力FEP β0+9i版
- SKK日本語入力FEP β0+9i版 + SKKGate β0+2i版
- AquaSKK 4.3.5
- FlickSKK 1.4.2
concatへの対応
SKK辞書の書式上、/
や;
を含む変換候補は登録できない。 そのため、L辞書には以下のようにconcatを用いて登録されている。
dosv /(concat "DOS\057V")/
対応済
concatによるエスケープを理解し、意図した変換結果を出力する。
未対応
変換結果に(concat ".....")
がそのままでてしまう。
/や;を含んだ単語の登録
ユーザが/
や;
を含んだ単語を登録した場合もconcatによるエスケープが必要である。
対応済
対応済?
以下のように独自の形式でエスケープを行なう。 単語登録は行なえるが、他のSKK実装とは互換性がない。
dosv /DOS[2f]V"/
- AquaSKK
- FlickSKK
未対応
/
や ;
をそのまま登録してしまう。単語を登録しても変換できない。
concat以外のEmacsLisp式
SKKの辞書は任意のEmacsLisp式を含めることができる。そのためlisp辞書には以下のようなエントリが登録されている。
time /(current-time-string)/
部分対応
pwdなどの一部のエントリには対応していないが、Lisp辞書の大半に対応している。
部分対応 その2
current-time-string、pwd、skk-versionの3つの関数のみに対応している。 CorvusSKK等に比べるとかなり限定的。
- fcitx-skk
未対応
数値エントリ
SKKの辞書は # を含む見出し語を特別扱いする。例えば、以下のエントリは「3かい」や「10かい」とマッチする。
#かい /#1回/#0回/#3回/#2回/
変換時、 #<n>
は以下のように変換される。
#0
: 半角数字。(例: 1024)#1
: 全角数字。(例: 1024)#2
: 漢数字で位取りあり。(例: 一〇二四)#3
: 漢数字で位取りなし。(例: 千二十四)#4
: 再変換。見出し語中の数字そのものをキーとして辞書を再検索する。*2#5
: 大字。(例: 壱阡弐拾四)#8
: 桁区切り。(例: 1,234) *3#9
: 将棋の棋譜入力用。(例: 8五)
詳細はSKK Manual: 数値変換に記載されている。
対応済
部分対応
未対応
数値エントリの変換に対応していない。
追記
@mzp corvusskkですが(current-time-string)と数値変換#9については一応使えるはずなので確認願えますでしょうか。作ってみて感じたのですが、下手に足を突っ込むと正に闇なのでconcatへの対応のみにしておくと精神安定上良いかなと思いました。
— Ν (@corvussolis) 2016年5月2日
CorvusSKKの対応状況に誤認があったので、修正した。
追記 その2
@mzp ご紹介ありがとうございます。SKK日本語入力FEPでは数値変換やLispに対応していないと書かれていますが、JavaScriptによる拡張モジュールを入れると変換できるようになります。簡易Lispエミュレータはlisp分離前のL辞書に入っていた候補に対応してます
— ガイアにcoがもっと輝けと囁いている (@coexe) 2016年5月2日
SKK日本語入力FEPの拡張機能のことを認識していなかったので、追記した。
所感
SKK-JISYO.lisp
NL名古屋 - connpassでSKK辞書の話をした。 要約すると、特定の文字をエスケープするだけでEmacsLispが必要になってつらいという話だった。
Transiruで発表したので、発表時の音声等はこちらで聞ける。終盤早口になってしまったので恥かしい。声優吹き替えオプションが欲しい。
原稿
前提
自己紹介
こんにちは。 mzpです。 タイトルにあるように日本語入力システムとLispについて話したいと思います。日本語のNと、LispのLでNLです。
何の話?
一言で日本語入力システムといってもたくさんの種類がありますし、Lispにもたくさんの種類がありますね。
ので、具体的に言うと、今日はSKKとEmacsLispの話をします。LispといってEmacsLispを持ちだすのは微妙な気がしますが、まあLispと名乗ってるわけですしOKでしょう。
SKKとは
このSKKについてですが、これはだいぶ独特な日本語入力システムです。通常の日本語入力システムがやるような作業を利用者におしつけることで、高速かつ高精度の日本語変換を実現しています。
入力例
分かりづらいと思うので、入力例を見てみます。例として「今日は雨です」と入力してみる場合です。
普通の日本語入力システムでは「きょうはあめです」と入力したのち、スペースを押して、変換候補を表示します。お馴染みですね。
SKKでは、漢字変換を始める前にShiftを押します。
Kyou
そして、複数の単語をまとめて変換することはできないので、ここでスペースをおして候補を表示します。
ひらがなはそのまま入力すればOKです。特に変換は必要ありません。
ha
また漢字なのでShiftを押します。
Ame
そして、スペースを押して候補を表示し、確定させます。
そして、またひらがなはそのまま入力します。
desu
SKKの特徴
このように
- 単語ごとでしか変換できない
- 漢字に変換するかどうかを自動で判断しない
といった特徴があります。
一見使いづらいだけのように見えますが、変換する単語を完全に自分で制御できるので、慣れれば離れられなくなる中毒性があります。
SKKの実装
中毒性が高いソフトウェアのため、現在では様々なプラットフォームで利用できます。
- Windows: SKKFEP、CorvusSKK
- Mac: AquaSKK
- iOS: FlickSKK
- Linux: iBus-SKK, UIM-SKK, SCIM-SKK
- Vim: skk.vim
- Emacs: ddskk
このAquaSKKとFlickSKKは僕がメンテしてます。
SKKの歴史
元となったSKK(通称: 本家SKK)は、1987年に、東北大学教授(当時)佐藤雅彦によって開発されました。
この本家SKKは、Emacs上のプログラムとして開発されました。 つまりEmacsLispを用いて開発されていました。
いやー、Emacsはすばらしいソフトウェアですね。 実にすばらしい。
辞書ファイル
とEmacsを十分に褒めたところでつらい話をはじめます。
ひらがなを漢字に変換するためには、ひらがなと漢字の対応表が必要になります。この対応表は辞書と呼んでいます。
そしてこの辞書ファイルが闇を貯めこんでいます。
辞書ファイルの書式
辞書ファイルはテキストファイルになっており、各行が以下のような書式になっています。
なごや /名古屋;愛知/那古屋/
左から順に「見出し語」「変換候補」「アノテーション(要するに補足情報)」となっています。変換候補間は/で区切られていて、アノテーションとは;で区切られています。
自然な感じがしますね。
エスケープ
しかし、この書式をじっと見てると、いくつか使えない文字があることが気づきます。そう、変換候補として「;」や「/」を含むことができないのです。
例えば「owata」の変換候補として「(^o^;)/」 とかを登録したい場合はどうしたらいいでしょう。
対応方法1: エスケープ
いくつかの対応方法が考えられます。 例えば、文字列リテラルのように\でエスケープすればよさそうですね。
owata /\\(^o^\;)\//
対応方法2: 別の文字への置換
あるいは別の文字に置換してしまうのもいいでしょう。
例えば、"[ASCIIコード]"のような記法を採用すると、;のASCIIコードは0x3b、/は0x2fなので以下のようになります。
owata /\(^o^[3b])[2f]/
対応方法3: 全角文字
あきらめてよく似た文字を使うことで誤魔化してもいいです(?)。
owata /\(^o^;)//
いやよくないでしょ...。
正解
みなさんだったらどうしますか?ちょっとだけ考えてみてください。
....
考えましたね。 ではSKKがどうしたかを見てみましょう。
owata /(concat "\(^o^\059)\057")/
S式の文字列リテラルを使ってエスケープする、が正解でした〜。
まじかよ...って感じですね。
その他の便利機能
日本語入力システムを使ってると、いろいろ便利な変換したくなってきます。
例えば、
- todayを今日の日付に変換したい
- nowを今の時刻に変換したい
- 5feetをメートルに変換したい
- 元号を変換したい
などです。
これらはすべてEmacsLispを使って実現できます! すごい!
まじかよ...って感じですね。
さらにすごいことに以下のような変換もEmacsLispで実現されています。
- 画面幅いっぱいの線
まじかよ...って感じですね。
実装
Lispの実装 これらの機能は使う分にはまだいいんですが、実装者としては悪夢です。
つまりSKKを実装するには、EmacsLisp処理系を実装しなければいけません。 より具体的に言うと、AquaSKKとFlickSKKはボクがメンテしていく上で、ボクがEmacsLisp処理系を実装しなければいけません。
まじかよ...って感じですね。
SKK-JISYO.lisp
なげいていてもしょうがないので、現実を確認してみましょう。
実は「今日の日付」のような複雑なEmacsLispの式を含む変換候補は、通常の辞書とは別で管理されています。余談ですが、この別に管理されている辞書はLisp辞書と呼ばれていますが、このLisp辞書って単語もだいぶ愉快ですね。
そのため通常の辞書だけを利用すると割り切ってしまえば、フルセットのEmacsを実装者するのは避けれます。通常の辞書に残っているEmacsLispの式はconcatによる文字のエスケープだけなので、これに対応するだけで十分です。
実装状況
SKKの各実装がこれにどのように対応しているか見てみましょう。
AquaSKK/FlickSKK
AquaSKK/FlickSKKは割り切った対応をしています。外部の辞書ファイルに含まれるconcatについては何もしません。つまり変換するとこんな変換結果がでてきます。(例: dosv)
そして、ユーザが入力した内容した結果については、別の文字列に置き換えることでエスケープしています。先ほど述べた別の文字への置換のような形式です。
owata /\(^o^[3b])[2f]/
後者はともかくconcatがでてくるのは微妙なので直したいとは思っています。
ibus-skk/scim-skk
ibus-skk/scim-skkは、concatのみの実装をしていてソツがない感じになっています。
CorvusSKK
一方、CorvusSKKはここの実装をがんばっていて、いくつかの関数もサポートしています。すごいです。
その他
Lispの話はこれくらいですが、実は辞書ファイルにはまだいくつかの闇が存在しています。
辞書の並び順
これまでは辞書の各行の話をしてきましたが、これらの行は見出し語をキーとしてソートされています。いわゆる辞書順です。辞書ですからね。
このときの比較関数としてはEmacsLispの string< が使われます。....またEmacsLispか。
そしてこのstring<は文字コード順で文字列を比較します。 はい、ぞわぞわしてきましたね。
なんの文字コードだよ、って感じですね。SKKでは伝統的にはEUC-JPが使われますが、最近はUTF-8を使うことも多いです。というかボクは使っています。
UTF-8の比較というとアレがありますね。 濁点問題です。NFCとNFDという2種類の形式があります。濁点を合成された文字としてもつか、分解された文字としてもつかの違いです。
世の中的にはNFCを使うことが多いんですが、ボクのメンテしているApple系のプラットフォームだとNFDが主に使われてたりします。
どちらが正しいとか優れているとかはありませんが、並び順には影響するので注意深く扱う必要があります。ボクはドハマりしました。
きっついですね。
辞書のライセンス
SKKの辞書ファイルはGPLで配布されています。 フリーなソフトウェア!! 自由!!
...こういうデータファイルがGPLっていうのはどういう扱いなんでしょう。
wikipediaから引用すると、GPLはおおむね以下のことを許諾するライセンスです。
- プログラムの実行
- プログラムの動作を調べ、それを改変すること(ソースコードへのアクセスは、その前提になる)
- 複製物の再頒布
- プログラムを改良し、改良を公衆にリリースする権利(ソースコードへのアクセスは、その前提になる)
改変の許可と再配布はいいとして、実行というのは何になるんでしょうね。 あとテキストを読み取ってアレコレするのは動的リンク扱いで派生物扱いになったりするんでしょうか。
謎です。
AquaSKK/FlickSKKのメンテナとしてのポジショントークは、同梱であってリンクではない。そのためGPLである辞書ファイルを読み取ってあれこれするプログラムはGPLである必要性はない、です。
別にアンチGPLというわけではなくて、AppleのAppStoreとGPLの相性が悪いので、俺の書いたコードはGPLではない、ということにしとかないと色々と都合が悪いんです。