![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
[[higashi]] *TITLE: ライセンス特定のためのルール自動生成を目的としたライセンス記述パターン抽出手法 [#l3ab357b] *AUTHORS: Yunosuke Higashi and Yuki Manabe [#e90108a6] **PAPER: 11 [#z679c2e8] **FOSE 2016 PAPER: 11 [#z679c2e8] **REVIEW 1 [#of0e0d65] -独自性: 4 (good) -妥当性: 3 (fair) -有用性: 4 (good) -可読性: 3 (fair) ***査読コメント[#s9465482] 本論文では，ライセンスルール自動生成手法構築のため，ライセンス記述のクラスタから，ライセンス記述パターンを抽出する手法を提案している． Debian v7.8.0のソフトウェアパッケージを対象としたケーススタディを行っている．その結果，371個のライセンス記述パターンを抽出し，そのうち276個のライセンス記述パターンは，変更を加えずにライセンスルールとして使えるパターンであることを示している． OSSのライセンスというとても興味深い問題を扱っており，FOSEにおいてディスカッションを盛り上げてくれる研究テーマであると感じます．その一方で，論文の章構成に一部問題があり，どの部分が提案手法で，どの部分が既存手法なのかわかりにくい部分がありました．また，わかりづらい／冗長な文章が散見されます． ■ 章構成について - 2章のタイトルが「技術的課題」にもかかわらず，Step 1-3までは，既存のライセンスルール作成手順を示しています． - 3章の「パターン抽出手法」と提案手法を述べる章にもかかわらず，3.1 は既存手法の説明です． - 課題が2つに対して，提案手法のステップは3つ（各クラスタの外れ値となるライセンス記述の除去，各クラスタにおける系列パターン抽出，系列パターンからのライセンス記述パターンの作成）あります．それぞれのステップがどの課題と関連するのか記述して下さい． ■ ライセンス記述の特定のワークフロー，ならびに，既存手法（Ninka, Higashiら）の手法がどの部分を対象とし，本研究手法がどの部分を対象としているかを示す図があれば，読者は全体像をとらえやすくなると思います．また図の追加に併せて，上記「章構成について」で述べている章タイトルに沿っていないコンテンツを整理することで論文が構造的になります． ■ 課題2の評価実験: 外れ値除去前のクラスタに対して，ライセンス記述の抽出を系列パターン，また，マージを行った場合の結果を示すことで，外れ値除去の効果をより示せるのではないでしょうか？ ■ 表3で述べられているメトリクス（Metrics）は，評価指標（Criteria）のほうが表現として適しています． ■ 課題1の表現について 「このようなライセンスルールはライセンス特定に適さない」に対しては，なぜ？と思いました．また，「 [...] クラスタに異なるライセンスのライセンス記述の混入を防ぐことは難しい」とありますが，なぜ難しいのか，そして難しいことが何で問題であるのかわかりませんでした． ■ その他 - 図1は読者の理解向上にはあまり役に立たなさそうです． - 4.1: 第一段落では12,725のソフトウェアパッケージ，と述べていますが，第二段落では12,725のソースファイルと述べており，表記がぶれています． - 4.1: *誰が*手作業で確認したのでしょうか？ **REVIEW 2 [#be70865c] --独自性: 4 (good) --妥当性: 4 (good) --有用性: 5 (excellent) --可読性: 2 (poor) ***査読コメント[#i6651faf] 本論文は，オープンソースソフトウェアのプログラム中に記載されるソフトウェアライセンスの特定を自動化するためのアプローチを提案している．著者らはこれまでにライセンスの記述内容によってファイルをクラスタリングする手法を提案しており，本論文では，クラスタリング後に，各クラスタに頻出するライセンスの記述パターンを自動抽出する手法を提案している．ライセンスの記述パターンを抽出するための課題が明確に示されており，対象以外のシステムにおいても応用できる提案手法と考えます． 4.3.2節の実験でBIDE適用時の支持度を2に設定されていますが，その根拠が示されていません．この値により，多くのノイズが含まれることは表2の説明から想像できます．対象とするDebianのシステムを調査した経験から得られたものであるのなら，他のプロジェクトを対象とするときにもそれと同様の検討をする必要があるため，支持度の決定方法についても議論する必要があると考えます． ケーススタディでは，提案手法の評価のためにDebian v7.8.0のシステムを対象とし，Ninkaが特定できなかったライセンスを特定するためのライセンス記述パターンを抽出していますが，Ninka，また，提案手法が特定できるライセンスに偏りがないのかを明確にするべきです．まずは，ケーススタディで対象とするシステムが取り扱っているライセンスを明確にし，その中で，特定できるライセンスを示すことで，本研究の有効性がより明確にされると考えます．また，議論2にもあるように，OSIに登録されていないライセンスも特定できるのであれば，特定できるライセンスに加え，特定が難しいライセンスも同時に示せるのと考えます． 読みづらい文章が散見しています．以下にいくつか挙げますが，他にもあると思いますので，再度読み直し，読み易い文章に修正してください． - 4.2.1節「課題1の評価項目」の最終行: 文章中のかかり受けが不自然です． - 4.2.1節「課題2の評価項目」最終行: ライセンスルールにかかる労力を軽減するためにライセンス記述パターンを正規表現化するところは理解できますが，その後の文章が理解できませんでした． - 4.3.1節3段落目: 接続詞「ただし」が不適切．「ただし」を使う場合は，どういう条件の場合取り除けないのかを明確に書く必要があると考えます． **REVIEW 3 [#c1a3f267] PAPER: 11 TITLE: ライセンス特定のためのルール自動生成を目的としたライセンス記述パターン抽出手法 AUTHORS: Yunosuke Higashi and Yuki Manabe -独自性: 4 (good) -妥当性: 4 (good) -有用性: 3 (fair) -可読性: 3 (fair) ***査読コメント[#zb883b3c] 評価できる点 ライセンス特定ツールであるNinkaにはライセンスルールが必要であり，Ninkaから出力される未知のラインセスからライセンスルールを抽出することで，Ninkaによるライセンス特定精度を向上させる事にはアプローチは評価でき，また実際に提案手法によって371個の新たなライセンス記述パターンが抽出でき，そのうち276個はそのままライセンスルールに適用できるとの結果が出ている点は評価できる． 問題点 １．本論文ではNinkaから出力される未知のライセンスを更にライセンスを特定するための手法でありますが，評価がクラスタリング結果だけを述べている傾向があります．もちろん，それらの評価は重要であると思いますが，重要なのは抽出されたライセンス記述パターンをライセンスルールに追加し，データセットとして利用している未知のライセンスパターンを何個明確にできたかが重要であると思います． ２．提案する手法では２つのライセンスの類似度を計測し，その結果に基づいて外れ値を計算していると思いますが，今回の外れ値の決定に関し，クラスタリング結果内容についても詳細に調べる必要があると思います．特に閾値を利用していますので，閾値94%が妥当かの検証を行う事も兼ねて，本来外れ値としてクラスタから除外されている要素（本文中ではSEと表記）がクラスタに含む必要がある，またはクラスタに含んではいけない要素が含まれていないかなどの調査が必要に思えます． ３．本提案ですが，非常に小さな問題点に着目しすぎているような気がします，理由として，本提案では，Ninkaが未知のライセンスとして吐き出す対象だけを実験対象としているため，今回は偶然結果がよかっただけとも取れます．もし，今後の発展をお考えならば，未知のライセンスに固執せずに，実験対象のソースコードすべてを対象にクラスタリングを実施し，その結果，現在Ninkaで利用しているライセンスルールとどのような差分があるかの実験を行った方が良いと思われます． ４．本論文では「ライセンス記述」や「ライセンス記述パターン」，「ライセンスルール」等類似の言葉が様々出てきており，非常にわかりにくくなっています．どこかで節を設け，これらについてまとめた内容を記述したほうが良いと思います． ５．本提案では系列パターンマイニングアルゴリズム，BIDEを用いて系列パターンを抽出しているようですが，原稿の読みやすさを考えるとBIDEについて述べる必要があると思います．また，本提案は著者等が過去に提案する手法の発展であり，且つ本提案でも過去の提案を利用しているのであれば，過去に提案したクラスタリング内容を記載すべきかと思います． ６．本文中の表5と表6の出現する順番が逆のように思えます．
