これは「探しものは何ですか？」の補足です。

その中で、「誰がlinkタグに新しい rel 属性値を定めることができるの？？？」というのが謎だったのですが、これ実は答えがあります。それは、HTML 4.01 規格で決められ、XHTML 1.0 に引き継がれて現在も有効なのですが、

head タグの profile 属性が、

head要素内のmeta要素のname属性値やlink要素のrel/rev属性値の意味を定義するメタデータプロファイルの場所をURIで指定します。ただし、User Agent（ブラウザ）は必ずしもprofile属性値で指定されたメタデータプロファイルを読み込む必要は無く、メタデータプロファイルのフォーマットも特に決められていません。

複数のURIを空白で区切って指定することもできます。ただし、有効となるのは最初のURIだけです。

 とのことです。とはいえ、これはそういう非常にいい加減な決めで、しかもどうやら全然利用されていないです。私もこのやり方を初めて聞いたくらいですから、認知もされていない...ということなんですね。要するに現在は無法地帯...ということです。勝手に rel 属性の値を作ってしまって、誰も文句は付けれない、というのが結論です。

このブログのネタは今時のことで、XML ネタが非常に多いです...というわけで、ちょっと気になったことがあって、昔買ったとある技術ムックを久々に読み直しました。そのムックはですね、

月間ジャバワールド特別編集「XML WORLD」第１弾、第２弾（アイ・ディー・ジー・ジャパン発行、2001年５月＆１１月）

です。コレは結構売れた特集ですから、お持ちの方もいるのでは？などと思います。

要するにこのムックが出た時というのは、「XML...勉強しなくては！」と皆が思い出した頃のわけです。そういう意味でタイムリーな企画だったわけで、私もそれにノせられて勉強しちゃったわけですね（苦笑）。

歳月は流れ、今や「XML...当たり前じゃん」という時代です。言い換えると、XMLというのは、典型的な「勝ち組」な技術のわけです。とはいえ、さすがにこの本の内容というと「なつかしい...」技術の解説が山盛りになる、というのは「ドッグイヤー」とでも申しましょうか。

読み直した最大の印象は、「熱いねぇ！」というものです。勿論この時点では、XML の応用として、RSS もまだ注目されていませんし、「ブログ」なんてコトバもまだありません。しかし、「XML ボキャブラリをどう作るのか？」というあたりの議論が「熱い」わけです。考えてみれば、XML の応用としては、「各種アプリの設定ファイル言語」をともかくとすれば、「セマンティックWeb」という面での XHTML のブログを通じた普及と、RSS の普及が、やはり最大の貢献をしたと言っても過言ではないでしょう。一応「XML」というコトバが出来たのが、実質 1998年の W3C の勧告から起算すればもう８年になるわけで、やはり現在の隆盛に至るまで、というか真の意味での「普及」まで、もっとも革新的で影響の大きかった XML であってさえ、やはり５年（弱）程度は要する必要があった、ということになるのではないのでしょうか。

着想から、それが多くの人に受け入れられて、規格として整理され、規格に基づいた実装ツールが作られ、それがフリーなツールとして普及し...という段階を経て、ごく常識的な「ユーティリティ」となるには、やはりそれだけの「時間」が必要だったりするのかもしれません。その陰には一時はもてはやされても今では使われない応用ツールもあります（典型は Cocoon かなぁ）し、当初注目されてもひと時沈滞し、さらに別な視点から改めて注目されるなどという複雑な経緯を辿る技術（XSLT なんてそういう気配が）もあります。また当初からあったけど、良いオープンソース実装が長らくなかったために、今ひとつ認知度に欠けていたけども、大手のオープンソース・プロジェクトが取り上げたために認知度が上がりつつある技術（典型例は XML データベース？）のようなスロースターターもあるわけです。そういう意味では「技術にもそれぞれの『人生』みたいなものがある」と言えるのかもしれませんね。

（このネタ面白いので続きます...）

さて、昨日アップしたものを見直していると、

やっぱ長い.....

というのが正直な感想でした。いわゆる「ブログ文化」というものが実在するとすれば、

１エントリ１ネタ。中身は簡潔に。議論を大展開せずに、外部ページを参照させる。

が、「暗黙ルール」になっている...というあたりでしょう。

実はあの投稿は、２月頭くらいに資料が集まってきたので書き出して、どうも気に入らなくて...で、草稿のまま書き直し、書き直ししていたものを、「あまり展開せずにサマリ風にする」というアイデアでリライトしたものだったりします。逆にそういう風に「がんばって書いちゃう」あたりが、ブログ風じゃないです。

まあ、「ブログ」と名がついていても、これ要するに「掲示板の進化形」に過ぎません。掲示板に長大な大論文を載せたりすれば、他の利用者から文句が出たりとか...という感覚を、「個人利用に特化した掲示板であるブログ」も、引き継いでいる、というわけでしょう。

そもそも「ブログ」という名称自体、「Web Log」が基ですから、もともと、「日々ウェブを見ていて、面白い！と思ったページについて、リンク中心にメモっていく」というものだ、という風に普及段階で説明されていた記憶があります。逆に言えば、「素のホームページ」がなくなって、ブログばっかりになってしまったら、「ブログで書くべき内容がない...」なんてことに、本来はなっていたかも知れません（勿論冗談です）。

私の傾向としては、どうしても「大展開」しちゃうタチなので、「ブログ」自体との相性はそうそう良くないのかもしれませんが、まあ、懲りずにやっていきます。

（そういや私って、日記が続かないタイプなんですね....苦笑）

探しものはなんですか？...って懐かしい表現ですが（年がバレます）、ＨＴＭＬの上で関連する情報を、主としてロボットがゲットする手段が、内容もやり方もいろいろとあります。よくこんな機能のことを、「AutoDiscovery」と呼びますよね。ちょっと面白がって調べたのですが、いろいろある上に、まとめたサイトとか特にないので、ちょっと書きましょう。

一番良く見かけるタイプのものは、ヘッダ部に link タグで書くものです。たとえば、このページ自体にだって、

<link rel="alternate" type="application/rss+xml"
   title="RSS 2.0" href="/blog/index.xml" />

というかたちで、RSS2.0 形式の RSS が埋め込まれているわけです。だから、ここで href 属性に書かれている http://blog.pasonatech.co.jp/index.xmlにアクセスすれば、RSS を見ることができるわけです。万事この調子、です。ですから、こういう link タグの使い方はご存知の方が多いのでは？とも思います。たとえば、

<link rel="alternate" type="application/x.atom+xml"
  title="Atom" href="/blog/atom.xml" />
<link rel="alternate" type="application/rss+xml"
  title="RSS 1.0" href="/blog/index.rdf" />
<link rel="alternate" type="application/rss+xml"
  title="RSS 2.0" href="/blog/index.xml" />
<link rel="EditURI" type="application/rsd+xml"
  title="RSD" href="/blog/rsd.xml" />

のようにして、Atom 形式のフィード・RSS1.0形式のフィード・RSS2.0形式のフィードの在り処をロボットに教えてやることができるわけです。最後の RSD は少し特殊なもので、これがポイントする rsd.xml は、XML-RPC や ATOM API に対して、そのサービス・ポイントや必須属性を教えるための、決まった XML です。（詳細は「APIを自動判定しちゃう」をご覧あれ。）

今挙げた例は「FEED のさまざまなタイプ」がどこにあるか...でしたが、RSD のようなサービスポイント提供型（よくサービスポイントのURIを「口」なんて呼びますが....）の場合は、ATOM API を中心に、次のようなかたちでサポートされます。

<link rel="service.post" type="application/x.atom+xml"
  title="ブログタイトル" href="/blog/atomapi/default/"/>

これは、このブログの default ブログに対して、新規投稿をするための、ATOM API のアクセスポイントを href 属性で教えることになります。その他の情報は、ATOM API は REST 原理に従っているために、たとえば「ブログを特定する情報」なども URI として畳み込まれているので、RSD のように別フォーマットにする必要がないわけです。

ATOM API というと、現状使われているのは「エントリの新規投稿」がメインのようですが、実はいろいろな「サービスURI」に、REST 原理に従って PUT すれば更新、DELETE すれば削除...というように動作するものであるとされています。ということは、ATOM フィード内でこれが定義されている場合だけではなくて、個別のブログのHTMLエントリを取得した時にだって、

<link rel="service.edit" type="application/x.atom+xml"
  title="記事タイトルの編集URI" href="/blog/atomapi/default/kiji/記事タイトル"/>

とでも見つかれば、その href 属性が ATOM API の編集用のサービス提供URI と考えてもいいでしょう。同様に、まだあまり実装がないようですが、Atom Publishing Protocol では、UploadURI（たとえば画像ファイルをアップロードする）、CategoryURI（カテゴリを編集する）があるようなので、これらもそのうち、

<link rel="service.upload" type="application/x.atom+xml"
  title="ブログ用画像アップロード" href="/blog/upload/default/"/>
<link rel="service.category" type="application/x.atom+xml"
  title="ブログカテゴリ編集" href="/blog/category/default/"/>

のように、あたりまえに挿入されるようになるのかもしれません。

このように link タグを使う AutoDiscovery には、その他に CommentAPI という RSS形式でコメントを投稿する API のものが、

<link rel="service.comment" type="text/xml"
  href="/blog/commentapi/permalink" />

のかたちで CommentAPI を受け付ける「口」を教えてくれるし、あと、それほどには使われていませんが、Trackback の代替のような位置づけの Pingback 仕様が、こういう AutoDiscovery を使います。これは通常 XML-RPC で呼びますので、xmlrpc の「口」と同じことが多いでしょうが、permalink で Pingback 対象になるエントリを特定してもＯＫな使用になっています。

<link rel="pingback" href="/blog/xmlrpc/permalink" />

また、自己紹介データの形式である FOAF(Friend of a Friend)という XML文書がありますが、これもやはり AutoDiscovery があり、

<link rel="meta" type="application/rdf+xml"
  title="FOAF" href="/foaf.rdf"/>

というかたちで在処を記述します。

この機構はキレイに整理されていて、良いものだとは思うのですが、実は別なやり方（みたいなもの）もあるわけです。このやり方の弱点、みたいなものというと、rel 属性の値で種別を決めて、href 属性で URI を指示する、というだけですから、その他の情報が必要な場合、それを与えることができない、ということにあります。あと、rel 属性の値が「サービス種別を特定する」ということになりますから、「誰が新しい rel 属性値を定めることができるの？？？」という、マイクロフォーマットみたいな問題がないわけではありません。

そのため、「AutoDiscovery」系のやり方が別にあったりします。たとえば、ある特定のブログページに対するトラックバック先を見つけ出すための機構として、「Trackback AutoDiscovery」という仕組みがあるわけですが、これは発想がそもそも違います。

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:trackback="；http://madskills.com/public/xml/rss/module/trackback/">
  <rdf:Description rdf:about="http://myblog.jp/blog/2007/02/mydoc.html"
      trackback:ping="http://myblog.jp/blog/trackback/2007/02/mydoc.html"
      dc:title="Trackback Auto Discovery"
      dc:identifier="http://myblog.jp/blog/2007/02/mydoc.html" />
</rdf:RDF>

のような XML を HTML 自体の中に埋め込んでしまいます。とはいえ、この書き方は XHTML の DTD に違反しちゃうことになります。ですから、XHTML に対する検証（validation）をすると、勿論アウトです。ですから、これをコメントでくくって挿入することが多いようです。とはいえこれなら、RDF ベースで適当に好きなように、属性の使いかたを決めてやれば「新しい AutoDiscovery」として使えるようになるわけですよね。

同様なもので「ブログとは別に運営しているホームページから、自分のブログを指し示させるためにはどうすれば...」という問題から、主として「はてな」利用者の間で Account Auto-Discovery が話題になっていたことがあります。これは RDF に FOAF（Friend of a Friend）フォーマットを流用して、

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:foaf="http://xmlns.com/foaf/0.1/">
<rdf:Description rdf:about="http://www.hatena.ne.jp/info/perl/autodiscovery/test">
  <dc:creator>
    <foaf:Person>
      <foaf:holdsAccount>
        <foaf:OnlineAccount foaf:accountName="hatena">
          <foaf:accountServiceHomepage rdf:resource="http://www.hatena.ne.jp/"/>
        </foaf:OnlineAccount>
      </foaf:holdsAccount>
    </foaf:Person>
  </dc:creator>
</rdf:Description>
</rdf:RDF>

なものになってしまったことが、マイクロフォーマットとの関連で批判されたり..とか、いろいろあったようです。こういう具合に「自動で探す(AutoDiscovery)」は、ホントにいろいろなものが利用されていますね。

皆さんは「DRY原理」ってご存知ですか？これは「クールでドライな...」原理かもしれませんよ（苦笑）。要するに、「Don't Repeat Yourself!」の略なんですね。日本語で言い換えると、「情報は１箇所に集中すべし！」という大原則のことです。

これをよりプログラマ的に言い換えるならば、「何かの情報を定義した文書が、複数のフォーマットで必要ならば、オリジナルの完全な情報を持ったソースから、変換して使うべきである」ということになります。そうすれば、情報に変更があった時も、「ただ１ソースのみ」を修正するだけで、辻褄の合った修正が他の派生的なソースにも波及し、「修正落ちなど考えられない」という大きなメリットがあるわけです。

XML革命が起きてもう随分になりますから、プログラマは日常的にXMLを書いているわけですね。その時に、「情報定義が必要だから、ちょっと新しいボキャブラリを作って、新規のXMLファイルを作ろうか...」とついついいろいろなXMLを作ってしまいます...実は、これは少し見直した方がよさそうです。

たとえば、XML から情報を抜き出して、HTML で表示する...などという処理はごくフツーになされるところですが、これを逆に考えて、XHTML で「CSSサポートなしで、ちゃんとブラウザで見えるような、正しい HTML としての情報」の中に、必要な情報を仕込んでやる...というのもアイデアだったりします。実例で言うと、たとえば次のようなありふれた XML 文書を、

<mytable>
 <record>
  <name>名前１</name><value>値１</value>
 </record>
 <record>
  <name>名前２</name><value>値２</value>
 </record>
</mytable>

と作らずに、HTML の中に埋め込んで、

<table class="mytable">
 <tr class="record">
   <td class="name">名前１</td>
   <td class="value">値１</td>
 </tr>
 <tr class="record">
   <td class="name">名前２</td>
   <td class="value">値２</td>
 </tr>
</table>

というように作ってやる...という考え方は、アリなんですね。

勿論、XSLT を使って変換してやれば、XHTML の定義から、最初の XML っぽい XML に変換してやることも簡単です。これを「情報」という面で捉えれば、「情報の多いものから、一部分を抽出して簡単なものにする」操作と、「単純な情報に、場合に応じていろいろと付け加える」という操作を比較したら、やはり「多い→少ない」変換の方が、操作が単純でメンテしやすいものになる傾向があるでしょう。そうなら、最初から XHTML に、特別に定めた属性によるマークアップをした方が、いろいろと使い勝手が良いことになります。

実際今私が研究している Ajax プログラムだと、XML-RPC のリクエストのXMLスケルトンと、それのユーザインターフェイスを、同期して管理する必要が出ます。ブラウザにも XSLT が付いている今のご時世では、ここらへんをうまく活用すると、サーバサイドの変換はまったくなしで、うまくクライアントサイドだけで仕事をさせることが出来てしまいます。そういう面で、「ムリに新規の XML ボキャブラリを作らずに、既存の XHTML ボキャブラリに目的とする属性を与えることで、HTML 兼 XML として振舞わせる」というのが、意外に最近狙い目になってきているような雰囲気があります。

まあ、こういう考え方に近いのが、最近流行の兆しが見えた「マイクロフォーマット」だったりするわけです。これも「RSS だとエントリの話題が何なのか、内容をパースしないと判らない...」ということから、「ブログ内容の XHTML のタグの中に、決まった属性を与えることで、たとえば『レビュー情報』であるとか、『コンタクト情報』であるとか、そういうことを判定する手がかりを与える」という考え方のわけです。

そうしてみると、「どうせ変換すれば『何でも同じ』なのだから、より情報の多いオリジナルのXHTMLに、属性による情報を付加して、再利用可能なものに仕立て直す」という戦略に、有効性を認める...というように流れが変わってきたような印象を受けています。

タグを作るのではなくて、既存のタグに再利用可能な属性を決めて使う...というこのアプローチは、意外に汎用的なようですね。これも、XHTML → RSS という情報の重複を避ける、DRY原理の最近の現れかもしれません。

研究で書いている API-launcher という Ajax のプログラムがあるのですが、ちょっと面白い現象に遭遇しています。皆さんもこれはご関心があるのでは？と思い、報告しましょう。

今やっていることの最大の問題点は、次のことでした。

XML-RPC の結果を、XSLT で単純な XML に変換して、それを JavaScript 上で操作する。

....まあ、コレ自体は、ありふれた操作に近いようなもののようにも思うのですが、ブラウザの互換性に関して、ちょっと問題があります。それは、

FireFox では、XSLT の変換結果は DOM オブジェクトだが、IE では XSLT の変換結果はテキストである！

よく見かける XSLT サンプルでは、IE では innerHTML に変換結果を格納して表示させ、FireFox では DOM 操作でぶらさげる...というものです。が、ここで、その変換結果を操作したい...となると、やっかいな問題があります。それは、

IE の場合、JavaScript 上で「XML の文字列表現」になっているものを、DOM に変換することが難しい！（ＨＴＭＬの場合は簡単ですけどね）

ということです。DOM に直さないと、操作がやりにくいようなややこしいことをしようとすると、「FireFoxでは出来ても、IE だとできない！」ということになってしまうのです。

まあ、これは変換する XSLT に問題がある....ということです。ブラウザによって、「どう XSLT で変換するか？」が気難しいことになるわけですね。

でまあ、これを解決するのに、簡単なのは XSLT の変換を HTML で変換する、という手はあるのですが、ここは流行に沿って、JSON でやる、というのも面白いか？と思い、それでやってみました。

XSLT だと、出力は３通り選べます。

1. XML <xsl:output method="xml" />


2. HTML <xsl:output method="html" />


3. テキスト <xsl:output method="text" />

なのは当たり前ですが、そのうちテキスト変換を使えば、XML → JSON 表現、というのができるわけです。問題の XSLT では、metaWeblog.getRecentPosts() の結果（最近投稿一覧）XML から、link と postId だけを抽出して使う...ということをしたいのですが、特に getRecentPosts() は、複雑に入れ子になった XML です。だから、レスポンスを DOM として受け取って、それを解析する...というのは、かなりややこしいことになります。もう少しJavaScript での処理を単純にしたくなります。そこで、たとえば１枚 XSLT での変換をカマせて、「より単純になったレスポンス結果」を JavaScript での処理に投入する...というシナリオなんですね。ですから、これを今回、JSON でやってみるわけですから、受け取りが JavaScript のオブジェクト（今回オブジェクトの配列）になり、ごく自然に扱えるようになるわけです。その変換XSLTは次のようになります。

<?xml version='1.0' >
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="text" />
<xsl:template match="/" >[<xsl:apply-templates select="methodResponse/params/param/value/array/data/value"/>]</xsl:template>
<xsl:template match="value" >{link:&quot;<xsl:value-of select="struct/member[name='link']/value/string"/>&quot;,postId:&quot;<xsl:value-of select="struct/member[name='postid']/value/string"/>&quot;},</xsl:template>
</xsl:stylesheet>

まあこうやって１枚変換をするようにすれば、ややこしい XMLレスポンス結果がいろいろあったとしても、JavaScript の複雑性を抑えることができるようになるわけです。metaWeblog.getRecentPosts() の結果XMLを、これで変換すると、出力はたとえばこんな感じなります。

[{link:"http://www.nurs.or.jp/~sug/testblog/archives/2007/02/test_form_ie.html",postId:"141"},{link:"http://www.nurs.or.jp/~sug/testblog/archives/2007/02/test.html",postId:"140"},]

問題を避けるために、出力を改行なしで出すようにしてますから、ちょっと見づらいのはごめんなさい。この XSLT を、JavaScript の上で、

// 一般的な xslt 変換の実行
function applyXslt( xml, xsltUrl ) {
    var result, xslt;
    if( window.XMLHttpRequest ) {
        browser_type = BROWSER_MOZILLA;
        var xslt = document.implementation.createDocument("","",null);
        xslt.async = false;
        xslt.load( xsltUrl );
        var xsltProc = new XSLTProcessor();
        xsltProc.importStylesheet(xslt);
        var frag = document.implementation.createDocument("","",null);
        return makeText( xsltProc.transformToFragment(xml,frag) );
    } else if( window.ActiveXObject ) {
       browser_type = BROWSER_IE;
       xslt = new ActiveXObject( "Microsoft.XMLDOM" );
       xslt.async = false;
       xslt.load( xsltUrl );
       return xml.transformNode(xslt);
    } else {
       browser_type = BROWSER_OLD;
    }
    return null;
}

// 特に JSON 変換に特化
function applyJsonXslt( xml, url ) {
    var ret = applyXslt( xml, url );
    if( window.XMLHttpRequest ) { 
       ret = ret.childNodes[0].nodeValue;

    } else if( window.ActiveXObject ) {
    } else {
        return null;
    }
    // 配列なので eval でよし
    return eval(ret);
}

// PostId自動取得API の結果処理
function procRecentPosts( form, xml, html ) {
   document.showForm.debug.value = html;
   var ret = applyJsonXslt( xml, selfUrl + "getPostByJson.xsl" );
   var at, radio;
   // target は操作対象のDOM
   var target = document.getElementById("target").childNodes[0]; // div
   target = target.childNodes[1]; // ol 
   var length;
  // JSON 表現の最後に 「,」 がついているので、これのカウントの仕方がIEとFireFoxで少し違う。
   if( getType() == BROWSER_IE ) {
     length = ret.length - 1;
   } else {
     length = ret.length;
   }
   // 以下は任意の処理
   for( var i = 0; i < length; i++ ) {
      if( ret[i].link != null ) {
        var at = ret[i];
        for( var j = 0; j < target.childNodes.length; j++ ) {
           radio = target.childNodes[j].childNodes[0];
           if( radio.value == at.link ) {
              radio.id = at.postId;
              radio.disabled = false;
              break;
          }
      }
     }
   }
}

のように処理してやれば、互換性問題を回避できることになるわけです。

こんな具合に、意外に JSON と XSLT の相性もよさそうですね！

この土日で、結構研究しちゃいました。内容は Blojsom の XML-RPC について...ということですが、MovableType とはいろいろ違います。で、作ったページが、

http://www.nurs.or.jp/~sug/homep/blojsom/xmlrpc.htm

というＵＲＬですので、ぜひぜひ。

一番の違い、っていうと、やはり「Perl で書かれている？」か「Java で書かれているか？」の違い...というのが意外でした。あれぇ？ Web2.0 時代だってのに、「何で開発したプログラムか？？」で挙動が違うんだっけ？？？

それはですね、XML-RPC を受け付けるCGI or Servlet のAPIメソッド仕様なんですね。言い換えると、Perl で書かれたAPI受付メソッドの場合、データ型があいまいなPerl だったら、XML-RPC のリクエストで型を省略して、「すべてString型」みたいにリクエストを発行しても通っちゃうけど、Java の Servlet でAPI受付ハンドラを実装した Blojsom の場合、リフレクションで該当メソッドを引き出すことになっていて、これが「正しい型が指定されていないと、リフレクションが失敗する！」ということになっちゃうわけです。ちょっと意外な結果でしょ。

まあ、Web2.0 の理想めいたもの、というと、「何で開発されているか、誰が開発したか、は不問で、正しく（最低でも準）公的な規格に従ったＡＰＩを実装すれば、どれもこれも同じように動く！」ということにあるわけです。まあ、それは今のところ、「単なる理想」に近い..というのが現実のところなのですが、開発言語が「型付き言語」か「型チェックなし言語」かで、製品の挙動が違うというのが、ちょっと「意外」ポイントだったので、面白いでしょう？

 

さて、たまにはビジネスな話でもしましょうか。とはいえ、オープンソース系開発者のビジネスの話です。

MovableType のライセンスというと、いわゆる「デュアル・ライセンス」というかたちのものです。いいかえると、個人非営利のユーザのライセンスと、商用利用のライセンスがそもそも「別」という考え方で、個人利用の場合は無償だけども、商用は有償、というやり方をしているわけです。とはいえ、個人利用のケースもハック出来る可能性を前提とした、いわゆる「LGPL」ではありません。ですから、ハックを SixApart は歓迎しない、というスタンスです。まあ、しかし、そもそもインタプリタ言語である Perl で書かれているわけですから、個人利用ケースでの改造を本質的に止めることはできませんから、「改変ソースの配布禁止」で改造をウリにしたビジネスを禁止することになるわけです。

 こういう現象というのは、「スクリプト言語による商用見込みのソフト」が登場した、という目立たないけども意外に重要かもしれない変化？とも思われます。今までの商用ソフトのほとんどがコンパイラ言語で書かれた、バイナリ配布のソフトだったわけですから、そもそもソース自体が「秘匿」されているわけですね。ですから、改造問題が生じるのは、かなり稀なケースということになるわけです（リバース・エンジニアリングになっちゃいますね）。

そういうわけで、「デュアル・ライセンス」というライセンス形態が結構重宝されることになりそうです。競合製品に対して優位を示し、広く使われることで知名度をアップし、シェアを取る、という目的で、「個人利用の場合は無償で使えます」というのは大きなアドバンテージがあるために、採用したくなるところです。とはいえ、本質がビジネス、ということであれば、「商用利用の場合は...」とおいしいポイントは外したくありませんね。

そこで、最近のスクリプト言語系商用見込みソフトのライセンスは、ＬＧＰＬを併用する...というケースがあるようです。Ajax 技術を利用して HTML 上のＵＩコンポーネントを提供する JavaScript ライブラリとして有名なものに、ActiveWidgets などがありますが、ここらへん「デュアル・ライセンス（個人非商用はLGPL）」のものが多いです。まあ、これも JavaScript ですから、ソースの秘匿のしようがありません（それでもソースの改行をなくして読みづらくしているケースがあります。苦笑）。

とはいえ、私なんかは LGPL をこういうかたちで使うのは、少し抵抗感がないわけではないです。ストールマンのアナキズム的理想主義から考案された GPL の、「劣後版」という位置づけ（最初はライブラリ版でしたけどね）の LGPL を、商用ソフトの個人利用の場合...のライセンスにする、というのは少々ストールマンの理想に対して、失敬な気がしないでもないですね。

まあ、そういうわけで結論とかあるわけじゃないです。私が個人的に好きなライセンス形態？は、「完全オープンソース、しかし、開発者作成のドキュメント別売」というものです。この類型には JBoss とか、Log4J とか、かなりメジャーなものがありますね。私が最近触ったグラフ作成ライブラリの JFreeChart もこのタイプです。これは面白いです。よく出来た利用サンプル(JWS配布)があり、これのソースが有料のドキュメントに付属...ということになってます。「ハックできるならハックしてみろ！」並みの大量のクラスですし、ちょいとドキュメントが有料であっても欲しくなるような仕組みになってます。こういうのには、正直「負け」ますね（苦笑）。カッコイイです。