« 2010年11月 | トップページ | 2011年1月 »

2010年12月31日 (金)

シェルスクリプトの最大の弱点

それはDBとの接続インターフェースが無いこと。
ストアドプロシージャを使うことでレコード単位の処理は可能になるが、
それだとDB内に閉じているため、外部リソースとの連携が難しくなる。
同じことはPL/SQLについても言えるが、こちらの場合はパッケージという
仕組みで豊富な機能が用意されている。
仮にストアドを使わないでパイプによってDBからの出力を処理するとしても、
それはテキスト処理となってしまい出力のフォーマット形式に大きく依存
してしまうという欠点を持っている。
SELECTの結果は複雑なテキスト形式のため、それらの形式の違いを全て
シェルによって吸収できなくてはならない。
しかも吸収できたかどうかは人間によって確認するしかない。
無論それはDBベンダー毎に異なるし、DBバージョン毎に異なるだろう。
またダブルバイト文字の有無によってもことなるだろうし、最悪はOS毎に
よっても異なるだろう。

| | コメント (0) | トラックバック (0)

GPLの問題とその検証法

よくGPLのコードを流用するとそれを組み込んだソースコード全体を
公開する義務が生じるから使わない、という主張を見る。

またそれに反してそれはGPLに対する誤解であり、必ずしも公開は義務
ではないという意見もある。

結論は不明であり、結局安全策を取ってGPLコードを使用しないという
流れになるケースが多い。

しかしこれは簡単に検証することが出来るだろう。

意図的にGPLコードを使用してクローズコードの製品としてソフトウェア
をリリースしてみればいいのだ。

それで公開の要求に対して拒否をして見て裁判で白黒を付ければいい。

予めグレーなケースを複数想定して極めて簡単な製品を作ればいい。

そうすれば前例ができてGPLの問題は少なくとも解消の方向に向かう。

手順はこうだ。

1.最低2人の人間が必要。
2.簡単なコードをGPLとして公開する。
3.GPLコードを組み込んだ簡単な製品をリリースする。
4.コードの公開要求を出して拒否する。
5.裁判を起こして白黒付ける。

この手順を複数のケースに対して起こす。

裁判費用と弁護士費用がかかるだろう。

しかしこれはやってみる価値があると思う。

オープンソースの世界に対して根本的な影響を与えるだろう。

逆になぜこれが行われてこなかったのかが謎である。

| | コメント (0) | トラックバック (0)

« 2010年11月 | トップページ | 2011年1月 »