Java のクラスファイルみたいのほしい(インデントつき）
以前RHGに投稿した文書が、インデント抜けてしまっていたので、ちょっと修正して投稿。
本文の前に用語の説明
ＴＯＣ
提案
ねらい
動機と前提
想定される問題
問題解決に必要なもの
問題解決に必要でないもの
この議論から外れる話
その他の話題いろいろ
提案
- ISEQ をファイルとして生成可能にする
- ISEQ をファイルからロード可能にする
# 最初は experimental だったり、本流に取り込まれない拡張のような形で
# もいいかなと思います。
ねらい
・ビジネスユースの場でもRubyを使いやすく
動機と前提
Ruby を他者に勧めたいと思った場合、障害になる点が言語仕様以外の面で
一点ありました。
・ソースコードの隠蔽をして納品ができない
尚、僕は現在は顧客向けの開発を行っていないのでこの機能が実現しても、
僕が利用することはあまりないでしょう。社会的に利用機会が増えればいい
な、というのが動機です。
何について障害になるか
ビジネスユースの場合です。僕は以前顧客を持ち、開発に携わっていまし
たがその感覚からすると特にパッケージ販売の時に障害になります。
実際に、PHP の場合ですが顧客にソースコードを流用されたため PHP
Encoder を導入した、という事例を当事者から聞いたことがあります。
（パッケージ販売だったかは確認していません）
PHP Encoder に対応するような機能が、現状 Ruby にはありません。
想定される問題
1. 機能の解読
2. ソースコードの流用
3. クラス・モジュールの流用
4. 改造しての流用
繰り返しになりますが、あくまでビジネスユースでの問題点です。
問題解決に必要なもの
解決策
提案に同じ。
- ISEQ をファイルとして生成可能にする
- ISEQ をファイルからをロード可能にする
視点
以下の解決策は、「企業はコストに見合わない作業は行わない」という視
点に立っています。
つまり、解読・流用を行うためのコストが一から作るコストを上回るなら
それを行いません。企業は利益を追求するものだからです。
想定
ビジネスユースには許容可能なリスクがあることを想定しています。
ISEQファイルをロード可能にしても、それでも解読/流用しようとする主
体がいるかもしれません。ここで考慮しなければならない要素は以下だと
思います。
1. コストをかけてまで解読する価値のある機能
2. 解読を実行可能な主体
3. 解読のコストをかけてまで実現しようとする機能
それぞれ 2割以下と考えると（実際はもっと少ないでしょうけれど）これ
らの条件が揃うのは 0.2 * 0.2 * 0.2 = 0.008 ということで 0.8 % とな
ります。
これが「流用されるかもしれないプロダクト」の製作者にとって、許容で
きないリスクかどうか評価したとき、プロダクトを製作・販売する利益に
たいする期待のほうが、大体において上回るため、通常許容可能であると
想定しています。
解決策に期待する効果
1. ソースコードの流用に対する障害設定
問題 2 を解消します。
ISEQ ファイルにすることで「気軽な copy & paste 」は不可能となり
ます。これを行おうとする人の大多数は、この時点であきらめることを
期待しています。
2. 解読するためのコスト増加
問題 1, 3 を解消します。
Ruby プログラムが ISEQ ファイル化されれば解読のためのコストは跳
ね上がります。よって、コストは実現可能だと考えます。
3. 改造のハードル追加
問題 4 を解消します。
解読するためのコストをと直結します。また、改造のためにはより精度
の高い解読が必要であるため、よりハードルが高くなると考えていま
す。
問題解決に必要でないもの
難読化
ISEQファイルを解読するための簡易で高速な手段がない現状では必要あり
ません。
もし必要になったとして、そもそも ISEQ がロード可能にならないと難読
化という機能は実現し難い。（と思っているのですがどうでしょう）
ISEQをファイルにすることに拠る高速化（この話題では）
動機・目的がそもそも高速化を狙っていないので必要ありません。うれし
いですけどｗ
この議論から外れる話
- Ruby の機能向上
- OSS の理念w
その他の話題いろいろ
拡張子について
Instruction Sequence という名前があるなら .rbi がいいんじゃないかなぁ。
JITとは競合しない（たぶん）
JIT が高速化を狙っているなら、ですが。
改ざんされたら SEGV 等のリスクがある件
先ず改ざんされるリスクについては他のバイナリ（rpmとか）やソースコ
ードと同等です。信頼できるソース/バイナリのみ利用するのはこの件に
限らず必須です。というわけで他と同等という意味では問題ないと思って
います。
なので、 verifyer の件は単に Ruby の信頼性の観点からのみ考えるべき
話だと考えます。
