PDF　千夜一夜

2008年04月15日

日本語ワープロやエディタのビジネスは成立するのだろうか？続き

昨日のブログを、今、読み返してみますと、タイトルと本文の記述内容が随分と食い違っていたようです。

エルゴソフトの沿革を見てみますと、EGwordは本当にすばらしい評価を得ていますね。残念ながら私は足元にも及びません。脱帽するしかありません。

しかし、エルゴソフトは、ワープロ事業を終了してしまったわけです。これは一体なぜなのか？どうしたら良かったのでしょうか？

少し前になりますが、2月7日～14日にかけて「コンピュータ組版の奇跡２」についてお話しましたときも、同じようなことを考えました。

アンテナハウスは、XSL-FOとかPDFとか、ワープロなどと比較的近い分野のビジネスが中心ですので、この問題は、実は、ほとんど毎日のように自問自答している課題なのですが、なかなか、簡単な回答を出すことはできません。

市場ということで言いますと、1990年代後半から、ワープロなどの汎用ソフトウェアの市場は世界がフラットになっています。これにはさまざまな要因がありますが、日本語ワープロという観点では、Unicodeが普及したことがかなり大きな要因ではないでしょうか。

例えば、UnicodeのBIDIという仕様を実装すれば、アラビア語、英語、日本語の混在した組版を、アラビア語についてなにも知らなくてもある程度の品質の組版ができます。現実に、弊社のXSL Formatterは、そうやってアラビア語の組版を実装しており、世界中のユーザがこれを使用しています。

別の例では、今、W3Cのタスクフォースで日本語組版規則の要求事項を英文にまとめているわけですが、こういうドキュメントができることで、世界中の誰でも、ある程度の品質の日本語組版ソフトを作ることができるようになります。

ですので、ワープロや組版というような、印刷文化にかなり密着している分野でも、世界中のほとんど全てのソフトハウスにとって、同じ条件のソフトウエアを作る競争になっており、世界中から競争相手がでてくる可能性があるということです。

その中で、生き残るのは、ほとんどオリンピックに出場して表彰台にあがるくらいに難しいと思います。オリンピックは、参加することに意義があるかもしれません。しかし、ビジネスでは勝ち続けなければ生き残ることができません。そうしますと、私達の戦いは、オリンピックで表彰台にあがるのよりもむしろ難しいといえるかもしれません。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年04月06日

Webは修理が必要だ — Javascriptのセキュリティ問題

前回に続き、Ajax World East2008におけるDouglas Crockford氏の「Webを修理できるか」のスライドの続きをご紹介します。

※前回はこちらです。
2008年04月03日 Webは修理が必要だ — Turducken問題

１８．Webを修理するための三又戦略 — Javascriptの安全な部分集合（本要約19～22項）、ブラウザの小さな改善（本要約23項）、ブラウザの強力な改善(本要約24～25項)（スライド３３）
１９．Javascriptを小さくして、セキュアでない部分を削除する（スライド３４～３７）
　JSLint　　http://JSLint.com/は、HTMLとJavascriptの安全な部分集合を定義している。
　ADSafeでは、グローバル変数・関数は定義されない。 ADSAFE オブジェクト以外にグローバル変数・関数がアクセスされることはない、など。Google's Caja/CajitaもJavascriptの安全な部分集合。
２０．Ecmascriptとその実装には未発見の危険があるかもしれず、ブラウザの実装が変化して新しい脆弱性を導入しているかもれない。DOMラッパは完璧でなければならない。（スライド３８）
２１．クロスサイトデータアクセスは、他のサイトからデータを取得してマッシュアップするのに有用だ。しかし、スクリプトタグを巧妙に改変されると非常に危険。（スライド４０～４２）
２２．安全なデータ交換のためのJSONRequestを提案した。ブラウザに実装して欲しい。（スライド４３）
　JSONRequest

２３．HTMLはモジュール化を提供していない。Google Gear, Adobe AIRは、通信のための入れ物を提供するが、重いしXSS攻撃からは安全でない。<iframe> は解決策ではない。（スライド４４～４７）
２４．JavascriptとDOMを置き換える必要がある。ADsafeからスタートして注意深く機能を強化する。（スライド４９～６３）
２５．Javascriptをより安全な言語で置き換え、HTMLとDOMを安全なアプリケーション配布システムで置き換えねばならない。しかし、現在のHTML5の提案はそうなっていない。（スライド６７）
２６．Webはかつては革新の駆動車だったが、今は革新の障害だ。Webの時間は昔は”速い”を意味した。2000年には全てのブラウザでAjaxが可能になった。2005年にJesse James Garrett がAjaxを発見した。なぜ、5年も掛かったのだろうか？（スライド６９～７３）
２７．ブラウザの新しいバージョンが普及するのに長い時間が掛かるためだ。（スライド７４～７５）
２８．人類は10年で人間を月に送ったが、10年でWebを修理できるだろうか？（スライド７６）
２９．Webを置き換えようとする３つの競争 —　Silverlight、AIR、JavaFXがある。これはWebの終わりを意味する。（スライド７７～７８）
３０．私は、以前は、ブラウザは最も不適切なプログラム環境と言っていたものだが、それはモバイルを発見する前のこと。（スライド７９）
３１．モバイルへ向かう。もし、PCベースのブラウザがモバイルのペースに追いつけないなら、モバイルがPCを廃れたものとしてしまうだろう。（スライド８０～８２）
３２．さしあたり、ブラウザを信用しないこと。コーディング衛生学が必須だ。品質の高いコードを書け。JSLintでチェックせよ。（スライド８３～８６）
３３．Webの標準化は敗れている。W3C、ECMA、ブラウザ・ベンダに圧力を掛けるべき。彼らは、君達を危険にさらしている。（スライド８８）

プレゼンは、以上です。

モバイルも良いですが、PDFを表示するには、14インチディスプレイ付きのモバイルが必要なのが困りますね。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年03月22日

普通のやつらの上を行け (Paul Graham)

先日、Paul Graham氏の「もうひとつの未来への道」をご紹介しましたが、続いて、「普通のやつらの上を行け」をご紹介します。

原文：Beating the Averages
http://practical-scheme.net/trans/beating-the-averages-j.html

これは要するにプログラム言語Lispが如何に優れているかという話ですが、概略を紹介します。

１．ソフトウェア・ビジネスは競争がとりわけ激しい。ある会社が他の会社よりも良いソフトウェアを早く書いたら、他の会社がいずれ潰れる。（他の条件が同じとして）。だから間違った技術を選択したら致命傷になる。
２．C++やPerlを大勢の人が知っていることは、その言語を選択する理由にならない。
３．デスクトップのソフトウエアを書くときは、OSがサポートする言語を選択するのが良い。しかし、Webベースのアプリケーションならどんな言語でも選択できる。
４．ViawebはLisp言語を選択したが、Lispはソフトウェアを素早く書くのに向いている。競争相手は20～30社に及んだが、CGIスクリプトを使っていた。Viawebは機能的には競争相手の遥か先へ行っていたし、競争相手が新しい機能を付けても1日2日で追いつくことができた。これはLispで誰よりも早くソフトウェアを開発できたからだ。

５．Lispは今ある言語の中で、最もパワフルだ。では、Lispがそんなに良いなら、なぜ、誰も使わないのか？
６．プログラム言語はその力において差がある。全ての言語は、機械語から最も力のある言語までの連続したスペクトル線の上にある。一般的にはアプリケーションを書くなら手に入る最も力の強い言語を使うべきだ。
７．ある年齢に達すると、プログラマは自分から言語を変えることはほとんどなくなる。何を使っていてもこれで十分だと思ってしまう。スペクトル線で自分が使っている言語位置の下を見下すことができても、上を理解できないからだ。
８．Lispがもっとも上位に来る理由は、マクロ機能である。Lispのコードはパーサで読むとデータ構造になる。他の言語ではコンパイラが生成する構文木をLispでは直接プログラムとして書く。この構文木を操作するプログラム、いわばプログラムを生成するプログラムがマクロだ。Viawebエディタの20-25%はマクロであり、ライバルのソフトウェアではできないものすごく難しいことをやっていた。これで、ライバルのソフトウェアにはできないことができたのだ。
９．プログラミング言語の変化は遅い。その理由はプログラマがそれを道具として思考するものだから。半分技術だけれども半分は宗教だ。
１０．1960年代にLispによって導入されたガベージコレクションは、近年ようやく良い技術として認められるようになった。しかし、1960年代にLispが導入したマクロはまだ未知の世界だ。
---ここまで---

著者がLispのハッカーであることを割り引くにしても、一考を要する文章ではありますね。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年03月19日

もうひとつの未来への道 (2)

昨日の続きです。

２３．Webベースアプリケーションの顧客は、個人や小さな会社。大企業は遅くなる。
２４．セキュリティに関する反論がある。しかし、個別企業でセキュリティ管理するよりは、運営に特化したベンチャの方が安全だろう。
２５．Webベースアプリケーションは、ITのアウトソースに相当するが、社内のシステム管理者に、競争の圧力を掛ける意味でも、アウトソースをするのが良いのではないか。
２６．大企業にものを売り込むには、それだけでお金が掛かる。だから、イントラネット・ソフトは生き残る。
２７．サーバでソフトを動かすのはメインフレーム時代からあった。しかし、デスクトップに変わったのは、小さな会社が新しいソフトを作ったからである。メインフレームでは固定費が高くてベンチャ企業はソフトを書けない。だからベンチャ企業はApple IIでソフトを書いた。

２８．デスクトップ・コンピュータ時代は、新しいソフトウエアの台頭で成立した。例えば、VisiCalcがその例。
２９．現代は、コンピュータが安くなり、サーバベース・ソフトウエアが有利だ。また、Webサイトがあればソフトが売れる。
３０．デスクトップ・ソフトを書くのはつまらなくなっている。マイクロソフトの土俵に上がらねばならず、さらに、売れたら、マイクロソフトにとって代わられてしまう。Winowsは、ハッカーに人気がない。
３１．Webベースアプリケーションは、ちょうど25年前のPCと同じ。
３２．デスクトップPCのユーザがコンピュータを理解しなければならないのは、マイクロソフトの問題である。Webベースアプリケーションにはマイクロソフトの場所はない。マイクロソフトはかつてのIBMと同じになる。
３３．しばらくの間、Webベースアプリケーションには支配者は現れないだろう。しかし、Webベースアプリケーションを作って運営するのは大変。開発者は机の下で眠らねければならず、責任も重くなる。デスクトップ・ソフトでは、開発者はリリースしたら休むことができるが、Webベースアプリケーションでは、ユーザが使い始めたら、リリースする前よりも大変になる。
３４．WebページはUIとして貧弱だが、とりあえずは使える。これも昔のPCと同じだ。そして、どのブラウザでも使えるソフトはそれだけで大きな意味がある。
３５．Webベースアプリケーションは、クライアントに関しては何も仮定しないので、Webが動作すればどこでも動作する。
３６．クライアント側で次に何が起こるかは予測できない。しかし、ブラウザが使える限り、Webベースアプリケーションは生き残る。
３６．安価に開発できて、もっとも小さなベンチャ企業でも公開できる。ユーザが気に入るものを作り、使った金より多くの収入が得られればやって行ける。
－－－ここまで－－－

Webベースアプリケーションで成功した先駆者の言葉らしく、開発者に挑戦を呼びかける結末になっています。デスクトップ・ソフトウエア業界は、マイクロソフトやアドビなど上位の企業に寡占化してきていますが、デスクトップPCからWebベースになって、新しいフロンティアが開けたということが良くわかります。

現在は、Paul Graham氏がこの話をしてから既に7年後となります。この間、Webベースアプリケーションが着実に増えているのは確かです。が、重厚長大なデスクトップアプリと、Webベースアプリケーションとのせめぎ合いはまだ決着が付いていないと思います。

今後はどうなるのでしょうか？AIRのようなRIAの登場で、また、少し、図式が変わるかも知れません。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年03月18日

もうひとつの未来への道

たまたま、会社の中の論敵から、Paul Grahamの

もうひとつの未来への道 ---The Other Road Ahead
http://practical-scheme.net/trans/road-j.html

というのを紹介されたので、読んでみたところ、これは大変面白ものでした。

主題は一言で言いますと、「25年前、デスクトップ・コンピュータが登場して、それが主流になっていたが、今後はWebベースのアプリケーション：ASPが主流になるだろう。」ということですが、実際にベンチャ企業を立ち上げて、WebベースのViawebというショッピング・サイト用のサービス（Yahooに売却してYahoo Storeとなった）を作った人の話です。

2001年に行われた講演の記録ですので、主題は、いまでは、ありふれたもののように見えますし、もはや新しいとは言えませんが、やはり先駆者だけあって、さまざまなところに、教訓になりそうな鋭い洞察が盛り込まれています。

まだお読みになっていない方は、ぜひ、目を通されると良いと思います。

とりあえず、時間を節約したい人のために要旨をメモしておきます。

１．デスクトップ・コンピュータを持つと、いやが応でもその動作を学ばねばならない。しかし、普通のユーザにその動作を学ばせるのはおかしい。
２．Webベースアプリケーションは、Webサーバで走り、Webページをユーザ・インターフェイスにする。ソフトウエアを使うのにコンピュータを学ぶ必要はない。
３．純粋なWebベースアプリケーションに必要なのは、インターネットに接続されたWebブラウザだけあれば良い。
４．私のコンピュータという概念はなくなる。クライアントにデータを保存するべきではない。アプリケーションのインストールもしない。
５．複数のユーザから同時に使える。ディスクのクラッシュもないので、データはより安全。
６．開発者にとっては、Webベースのアプリケーションは、ひとつのコードの塊ではない。違ったタイプのプログラムの集合になる。
７．ハードウエアを追加することで新しい機能を追加できる。
８．望みのどんなコンピュータ言語でも使うことができる。
９．ソフトウエアのリリースは、爆発的なものではなく、段階的な変更の連続になる。時には、1日3～5回。ソフトウエアは徐々に連続的に変化する。
１０．バージョン番号は、宣伝のために存在するだけで、意味が無くなる。
１１．バグを手元で再現できる。小さな変更だけでリリースするので、複合バグが出にくくなる。バグが出ても新鮮なので解決しやすい。
１２．関数的プログラミング手法を使いやすい。
１３．サポートのやり方も変わる。ユーザからのフィードバックが大歓迎になる。
１４．バグをその場で修正するので、サポート部門と開発者が密接になる。
１５．ソフトウエアを直ちにリリースできるので、アイデアを直ぐ実装して反映できる。
１６．信頼できる少数のプログラマしか必要としない。グループが小さくなればなるほど、開発の生産性が上がる。但し、プログラマがシステム管理者にもならないといけない。
１７．全てのユーザが行う全ての振る舞いを観察することができる。ユーザを見ることで、設計上の指針も得られる。どこで困っているかも分かる。
１８．サーバあたり何人のユーザをサポートできるかでコストが決まるので、効率が重要だ。
１９．試用サイトでユーザを獲得する。試用サイトのユーザのクリックを調べて改善する。
２０．サブスクリプション形式が自然な課金方法だ。
２１．定常的な収益が得られる。海賊版も出ない。
２２．ISPをリセラーとして販売するのは悪いアイデア。自分でサーバを管理すべきだ。それで、ソフトとハードを常に改良できる。
---続く--

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年03月11日

Web時代の出版・マーケティング　DRMを見直す

日経エレクトロニクスの3月10日号に「コピーに自由を生まれ変わるDRM」という特集がでているとのこと。

まだ、紹介記事や関連の記事を読んだだけですが、大変面白そうです。

ここに編集長のテレビPRが出ています。
http://bptv.nikkeibp.co.jp/article/080306/080306152.html

「YouTubeで世界へ」，角川グループがYouTubeの積極活用に踏み切る
によりますと、角川グループは、YouTubeの映像認識技術をつかって、動画による収入を著作権者にも分配する仕組みを作ろうと考えているようです。

■インタビュー記事
角川デジックス 代表取締役社長 福田正氏インタビュー「Googleと組んだのは黒船だから」（前編）
角川デジックス 代表取締役社長 福田正氏インタビュー「Googleと組んだのは黒船だから」（後編）

PDFでもAdobeのLiveCycleのような本格的なDRMがあります。しかし、販売を目的とするコンテンツの場合、DRMを使うと、DRMを使わないときよりも売り上げは減ってしまうと聞きます。つまり、DRMの不便さがユーザを逆にコンテンツから遠ざけてしまうということらしいです。

そうなりますと、これはコンテンツを販売したい人、そのコンテンツを利用したいユーザの両方にとってデメリットになってしまいます。ですので、多くを売りたいと考えた場合は、DRMなしで販売するほうが恐らく売上が増えるわけですが、そうなりますと著作権の保護ができないというジレンマがあります。

情報を紙で販売している時代には、紙を複写する手間とかコストの問題があり、これが複製の抑止力として働きました。しかし、電子文書は、複製の手間やコストはほとんどゼロですので、複製を抑止するものがなくなります。しかも、何回複写しても完全にオリジナルと同等です。

そういう時代に、どうやって情報を出版するビジネスを展開するか、これは、デジタルTVや動画の世界でも大きな問題ですが、PDFによる情報の販売でも、まったく同じ課題を抱えています。

投稿者 koba : 22:00 | コメント (0) | トラックバック

2008年03月06日

PDF：商用ソフト、フリーソフト、オープンソース　続き

昨日の続きですが、要するにフリーソフトとは無料で使えるソフトということです。もうひとつ、オープンソースという言葉があります。オープンソースも概念がややこしいですが、これにつきましては、以前にブログで詳しくお話しましたし、それを次のところにまとめてあります。

オープンソース・ビジネスについて考える

オープンソースは、平たく言えば、プログラムのソースが公開されていて、かつ、改変・再配布・再頒布が許諾されているものということができます。このためオープンソースは、無償になりがちですが、RedHat Linux, MySQLのように複雑な（トリッキーな）利用契約を交わすことで、実質的にかなり高額な利用料を取っている場合もあります。

そうえば、MySQLは、最近Sunが買収しました。MySQL社にはベンチャ投資家がかなり投資していたようです。MySQL社が単体の会社経営としてどうなっていたかは分かりませんが、少なくとも投資家にとっては、オープンソースへの投資の成功例になったのだろうと思います。

「オープンソース・ビジネスについて考える」でも、オープンソースが投資家の対象になり始めていると指摘しましたが、こうした成功例により、今後は、オープン・ソースへの投資が増えることになりそうです。

で、まとめですが。フリーソフト＝無償ソフトと定義しますと、

・個人や有志のソフトウエア作者(達)が作って、無償で世に公開するソフトには、良いものが沢山あります。コンシューマ向けの雑誌で、こういうのを紹介するのはそれなりに有意義だし、必然性があると思います。商用ソフト側からは、そういうソフトとの共存関係を築くようにしていくべきだろうと思います。

・インターネット・エクスプローラのように、Microsoftのような大きな会社が開発して、無償で出すソフトについては、かなりな脅威になります。これは、独占禁止法などの観点から対策が必要でしょう。そういえば、NorwayのOpera Software社が、昨年12月にMicrosoftをEU独占禁止法で訴えました。事情はあまり詳しく分かりませんが、この訴訟の行方には注目が必要ですね。以前に、ネットスケープの訴訟でMicrosoftがUSで企業分割寸前まで行ったのですが、その再現になるかどうか？まあ、欧州での出来事ですが、今後の世界は欧州中心になりつつありますし、眼を離せない話です。

・プロプライエタリな商用ソフトにとっては、オープンソースはなかなか大きな脅威です。企業システム用のオープンソースの開発者は、現在は、既に個人や有志ではなく、企業に所属するプロの集団になりつつあります。そういう意味では、オープンソースは、商用ソフト開発の新事業形態になってきているということであり、オープンソースは、生半可な商用ソフトに勝る機能を備えるようになってきています。そうなりますと、オープンソースと競合したとき、どうやってそれと戦うか？これは相当に知恵を絞らねばなりませんね。でも、XSL Formatterは、50万円なんですが、無償のオープンソースFOPと同じ市場で競争して、少なくとも過去数年間は十分なお金を稼ぐことができました。ですので、無償のソフトと競合しても、商用ソフトが生き延びる方法があるということは言えます。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年03月02日

電子文書と紙文書　— 電子署名の目的と電子文書の状態

さて、電子文書は、紙文書とちがって、データの生成から可視化されるまでに複雑な過程を経過することを昨日お話しました。

電子文書を可視化する過程について考えていて、「電子文書の可視化過程と、電子署名の関係はどうなんだろう？」と疑問を持ちました。

電子署名自体は、デジタルデータであれば何にでも付与することができます。しかし、電子署名の使用用途によって、署名対象文書の種類が変わってくるはずです。

電子署名のプリミティブな役割は、署名対象文書が、署名後に改竄されたことを検出することです。電子署名を、この用途で用いるならば、どのような電子文書を対象に電子署名しても意味があると思います。この場合は、人間は介在せず、コンピュータのみで計算・処理することができますし、どのような電子データであれ、署名の付与と、署名検証のアルゴリズムは同等の意味をもつからです。

これに対して、電子署名を、署名者である人間が内容を確認して、確かに承認したことを証明する場合、すなわち署名者の意思を保証するために用いる場合は、事情が変わってきます。

この用途では、XML文書やバイナリの電子文書に人間が署名することは意味をなさない場合があるだろう、と思われます。

なぜかと言いますと、XML文書の場合は、レイアウト指定（スタイルシート）、バイナリデータの場合はアプリケーションによって、可視化され、表示される情報の意味が変わる危険があるからです。

極端な例ですが、「この色は、確かに、自分の指示した色です。」と言って承認しても、モノクロのディスプレイで見る人と、カラーディスプレイで見る人では異なった色を見ていることになります。同じカラーディスプレイでも、カラーがデバイス依存になることがあります。

そうしますと、XML文書やバイナリ文書に、人間の承認を証明する用途の電子署名をすることに意味があるかどうかは、かなり慎重に検討を要することになります。

では、PDFに電子署名することは、どうなのでしょうか？次回はこれを考えて見ます。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年03月01日

電子文書と紙文書　考

昨日、「紙文書と電子文書を同列に並べて議論するのは、本質的に違うものを比較しようとしているのではないか。」と申し上げましたが、このことについて、もう少し考えてみました。

人間が紙に文字を書くのは、脳や手の中はともかく、大変単純な行為だと思います。これに対して、デジタルデータが紙に可視化される過程は、かなり複雑です。次の絵をご覧ください。

これは、テキスト中心のデジタル・データ（以下、これを「電子文書」と総称します）が可視化されるまでの流れを大雑把に書いたものです。

まず、電子文書には大きく分けると3種類があると思います。
１．ワープロの文書、DTPソフトのデータのようにアプリケーションと不可分、コンテンツとレイアウト(書式）情報が渾然一体となったバイナリ形式のデータ
２．レイアウト情報をもたないデータ。XML、CSV、あるいは、EDIの中を流れる取引データなど。
３．PDF、XPS。デジタルの紙ともいえる可視化された状態を電子ファイル化したもの。

１～３によって可視化の処理がかなり異なります。

まず、ワープロやDTPのバイナリデータですが、これはアプリケーションと不可分になっているため、可視化するには、その電子文書を作成したアプリケーションが必要です。元のアプリケーションがなければ、正しく可視化できません。場合によっては、アプリケーションのバージョンが異なると可視化した結果が異なってしまいます。例えば、Microsoft Wordでは、異なるバージョンで作成した電子文書を読むと、文書のレイアウトが崩れてしまうことがあります。これは、実際に経験された方も多いと思います。

次に、レイアウト情報をもたない内容だけの情報。これを可視化するには、外部からレイアウト定義情報を与える必要があります。例えば、XMLにレイアウト指定を与える標準的方法として、XSL-FOとかCSSがあります。CSVのような情報では、なんらかの定義を与えて、可視化する必要があります。このような電子文書は、アプリケーションからは独立ですが、レイアウト定義によって、可視化結果が異なるということになります。

PDFやXPSは、プリンタ装置を使って紙に可視化するプログラム（手続き）を電子ファイル化したものということができます。このプログラム言語をPDL(Page Description Language）と言います。その手続き（PDL仕様）が、標準として公開されていれば、比較的標準的な可視化ソフト(ビューア）を作ることができます。しかし、DocuWorksのように、非公開のものもあります。

このように、電子文書というのは非常に幅広い概念であり、多くの場合、電子文書の見え方はそれを可視化するアプリケーションや装置に依存している、ということに注意しなければなりせん。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月23日

筋肉質の決算書を作る その４

土地・建物・設備機械などの有形固定資産も不良資産化する危険は常にあります。しかし、販売用ソフトウエアの開発に要した費用を、無形固定資産として計上した場合、それが不良資産化する危険は、土地・建物・設備などが不良資産化する可能性とは比較にならないほど大きいものです。

ソフトウエア会社の経営者は、もし健全な経営をしたいと考えるならば、「販売目的用のソフトウエアの開発費を、内容を問わず無形固定資産に計上することは、行ってはならない。」と思います。

これについては、企業経営審議会「研究開発費等に係る会計基準研究開発費等に係る会計基準の設定に関する意見書」でも、次のようになっています。

--------ここから------　　　
「市場販売目的のソフトウェア
ソフトウェアを市場で販売する場合には、製品マスター（複写可能な完成品）を制作し、これを複写したものを販売することとなる。　　　　　 　　　　
製品マスターの制作過程には、通常、研究開発に該当する部分と製品の製造に相当する部分とがあり、研究開発の終了時点の決定及びそれ以降のソフトウェア制作費の取扱いが問題となる。　　　　　　　　　　　　　　
イ．研究開発の終了時点　　　　　　　　　　　　　　　　　　　　　　　
新しい知識を具体化するまでの過程が研究開発である。したがって、ソフトウェアの制作過程においては、製品番号を付すこと等により販売の意思が明らかにされた製品マスター、すなわち「最初に製品化された製品マスター」が完成するまでの制作活動が研究開発と考えられる。　
これは、製品マスターの完成は、工業製品の研究開発における量産品の設計完了に相当するものと考えられるためである。
　　　　　　　　　
ロ．研究開発終了後のソフトウェア制作費の取扱い　　　　　　　　　　　
製品マスター又は購入したソフトウェアの機能の改良・強化を行う制作活動のための費用は、著しい改良と認められない限り、資産に計上しなければならない。　　　　　　　　　　　　　　　　　　　　　　　
なお、バグ取り等、機能維持に要した費用は、機能の改良・強化を行う制作活動には該当せず、発生時に費用として処理することとなる。　　
製品マスターは、それ自体が販売の対象物ではなく、機械装置等と同様にこれを利用（複写）して製品を作成すること、製品マスターは法的権利（著作権）を有していること及び適正な原価計算により取得原価を明確化できることから、当該取得原価を無形固定資産として計上することとした。
---------------------------------------------------------------------
三 研究開発費に係る会計処理
研究開発費は、すべて発生時に費用として処理しなければならない。 なお、ソフトウェア制作費のうち、研究開発に該当する部分も研究開発費として費用処理する。
---------------------------------------------------------------------
２ 市場販売目的のソフトウェアに係る会計処理
市場販売目的のソフトウェアである製品マスターの制作費は、研究開発費に該当する部分を除き、資産として計上しなければならない。ただし、製品マスターの機能維持に要した費用は、資産として計上してはならない。
---------------------------------------------------------------------
５ ソフトウェアの減価償却方法
無形固定資産として計上したソフトウェアの取得原価は、当該ソフトウェアの性格に応じて、見込販売数量に基づく償却方法その他合理的な方法により償却しなければならない。
ただし、毎期の償却額は、残存有効期間に基づく均等配分額を下回ってはならない。
--------ここまで------

これを受けて、公認会計士協会も「販売目的用のソフトウエアの開発費を、内容を問わず無形固定資産に計上することは、行ってはならない。」としています。
・研究開発費及びソフトウェアの会計処理に関する実務指針について（日本公認会計士協会）

しかし、国税庁の通達があるため、税務上は無形固定資産扱いをせざるを得ない部分が出てしまいます。このため、会社法上の決算と税務上の申告書に乖離が生じ、ここに大きなリスクが入り込む危険があります。

一般に、会計事務所・税理士は、国税庁側の立場で決算書・申告書を作成する傾向があります。上場会社については、監査法人がつきますので、多少は中立的になると思いますが、非公開企業の場合、経営者自身が細心の注意を払わねばなりません。

国税庁は、多くの有識者が「販売目的用のソフトウエアの開発費を、内容を問わず無形固定資産に計上することは、行ってはならない。」と述べているにも係わらず、なぜ、これを無視して、手前勝手な通達を出すのでしょうか？

これによって、ソフトウエア会社の経営が、非常な危険をはらんだものになり、従業員、投資家、取引先に対しても大きな迷惑を及ぼす結果になる可能性を生み出すことを考えていないのでしょうか？

■参考資料
・「研究開発費及びソフトウェアの会計処理に関する実務指針について」

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月22日

筋肉質の決算書を作る その３

過去に2回お話しましたように、ソフトウエアの開発費の取り扱いに関する国税庁の通達には、ソフトウエア製品を開発販売している業界にとって、死活問題といえるほどの大きな問題があります。昔からずっと考えていたのですが、ちょうどこの機会に、そのことを整理しておきたいと思います。

１．無形固定資産の額が大きくなること

国税庁の通達通り、ソフトウエア開発費を無形固定資産として計上し、3年間で償却するとします。そうしますと、どれだけの無形固定資産がつみあがるのでしょうか？

分かりやすく、2005年から毎年3千万円のソフトウエア開発費を掛けて製品を作り続けているとします。そうしますと、無形固定資産の残高は、2006年には5千万円、2006年以降は6千万円となります（次の図を参照）。

この図で分かりますように、常時、自社製品を開発している会社は、毎年度末に2年分の取得額に相当する無形固定資産を抱えることになります。

２．資産には税金負担が発生する

取得時に経費処理できれば、納税負担額はありません。しかし、3年に分けて経費として発生させることになりますので、初年度に税負担が発生し、2年目から減価償却費に対応する税金が、支払うべき税金から減免されるかたちとなります。

上述の例で、どの位の税負担が発生するかを計算してみました。

4年目から新規に発生する税負担額はゼロになりますが、初年度から3年目までに累積で2700万円（6000万円*0.45）の税負担が発生します。4年目からは眼に見えなくなりますが、常時、累積2700万円の税金を過払いになっている状態となります。なお、これは、ソフトウエア資産に限らず、減価償却資産に共通の問題であって、ソフトウエア業界特有の問題ということではありません。

※実効税率は45%で計算。ちなみに、アンテナハウスの2007年度分の申告所得は2億923万円、これに対する納税額（法人税＋事業税＋都道府県民税＋市町村民税の合計額）は、9,470万円です。従って、税率は45.2%となっています。

【問題点】
○不良資産を抱える危険性

ソフトウエアの開発費を構成する費用の大部分はエンジニアの人件費です。無形固定資産と言っても、その実態は、支払ってしまった人件費です。

以前にもお話しましたが、ソフトウエア製品は売れない可能性も大きいので、開発した製品が売れない場合は、人件費が不良資産に化けてしまうのです。

これをそのまま企業の決算書とすれば、その企業の決算書はほとんど粉飾決算であると言っても過言ではありません。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月20日

筋肉質の決算書を作る 続き

昨日は、「税務上の処理の要求は、企業経営のために正しい決算を行うという観点から適切ではない。」ということをお話しました。

一応、国税庁の通達を上げておきます。

【法人税法上の取り扱いについて】
○「法人税基本通達等の一部改正について」課法2－19　平成12年11月20日

http://blog.homu.jp/?cid=30621によりますと、この古いバージョンがあるようですが、国税庁のWebで検索しても出てきません。

○No.5461　ソフトウエアの取得価額と耐用年数
http://www.nta.go.jp/taxanswer/hojin/5461.htm

販売用ソフトウエアの原本の償却は3年となっています。

一方、企業会計上では、次のような処理が推奨されています。

【企業会計審議会】
研究開発費等に係る会計基準研究開発費等に係る会計基準の設定に関する意見書

この解説：
ソフトウエア会計基準 とは

会社の正しい姿を把握するためには、正しい決算書を作成することが非常に重要です。そういう観点では、この企業会計審議会の意見は、経営実務上にも納得できる内容となっています。
昨日の、税務上の取り扱いと比較して示しますと次の表のようになります。

開発フェーズ		税務上の処理		企業会計審議会
		税務上の分類項目	税務上認められる償却方法	分類	処理
自社開発	製品化前(プロトタイプ開発費)	無形固定資産	研究開発費・任意償却	発生時経費
自社開発	V1.0	無形固定資産	3年で償却	研究開発に分類。発生時経費
自社開発	V1.0超（次バージョン開発費）	無形固定資産	3年で償却	無形固定資産	合理的な方法で償却。但し、残存有効期間に基づく均等配分を下回らないこと
自社開発	発売後の製品保守	経費		経費
外注	製品化前(プロトタイプの作成)	無形固定資産	研究開発費・任意償却	発生時経費
外注	V1.0	無形固定資産	3年で償却	研究開発に分類。発生時経費
外注	V1.0超（次バージョン開発費）	無形固定資産	3年で償却	無形固定資産	合理的な方法で償却。但し、残存有効期間に基づく均等配分を下回らないこと
外注	発売後の製品保守費	経費		経費

このように企業会計上は、妥当と思われる基準があるのに、税法上の取り扱い通達が、現実離れしているのです。

このために、企業の決算書と納税申告書の作成において、その調整を行わなければなりません。このあたりに毎年、この時期に頭を悩ます問題が発生する理由があります。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月19日

筋肉質の決算書を作る

アンテナハウスは12月決算です。2月末には、決算を完了して申告をださねばなりません。弊社の決算と申告で、毎年、一番最後までもめるのが、ソフトウエアの開発に要した費用の処理の問題です。昨日は、怒り心頭に発して、会計事務所の担当者を怒鳴り散らしてしまいました（ご愁傷様です）。

弊社の会社法に基づく決算では、ソフトウエアの開発に要した費用は、できる限り経費として処理しています。しかし、税務上の取り扱いでは、必ずしもそれは認められません。

この問題について、少し、考えてみたいと思います。弊社の場合は、受託開発はあまりなくて、自社製品の開発がほとんどとなります。その場合、開発に要した費用毎に、その税務上の処理は次のようになると理解しています。

開発者	フェーズ	税務上の分類項目	税務上認められる償却方法
自社開発	製品化前(プロトタイプ開発費)	無形固定資産	研究開発費・任意償却
自社開発	V1.0	無形固定資産	3年で償却
自社開発	V1.0超（次バージョン開発費）	無形固定資産	3年で償却
自社開発	発売後の製品保守	経費
外注	製品化前(プロトタイプの作成)	無形固定資産	研究開発費・任意償却
外注	V1.0	無形固定資産	3年で償却
外注	V1.0超（次バージョン開発費）	無形固定資産	3年で償却
外注	発売後の製品保守費	経費

この税務上で要求される処理は、ソフトウエア製品を開発して販売する会社として、妥当で正しい決算処理と言えるのでしょうか？何が妥当で、正しいかということを判断するのは難しいものですが、まず、これを考えてみたいと思います。

販売用のソフトウエアの開発費を無形固定資産として計上し、それを3年で償却する、という考え方の根拠は、発生する費用と収益を対応させるという考えだろうと思います。これは、一般論としては妥当な考え方でしょう。

つまり、建物を建てたとして、その建物が30年間使用できるものならば、その建築費を最初の年に一括で経費として処理するのではなく、建築費を30年で分割して毎年30分の1を経費として処理する考え方を取ることになります。所謂、減価償却の考え方となります。建物の建築費の場合は、そのような考え方をとらないと、建物が完成する毎に大赤字になるということにもなり、投資もできないことになります。
※建物の償却期間は、構造分類毎に決まっていますので、30年は仮定の話です。ご注意ください。

では、販売用のソフトウエアと建物や機械設備と同じ考えで良いのでしょうか。

この二つには、同じ考えを適用できない、非常に大きな溝があります。

・建物や設備は経営上効果を発揮する確度が高い。建築したは良いが、使えないという建物はほとんどないと言って良いでしょう。しかし、販売用ソフトウエアは作ったけれども売れないということが頻繁に起こります。つまり、リスクがまったく違うことになります。
・建物や設備は、作ってしまうと、保守費用というのは、比較的少ないコストになります。それに対して、販売用のソフトウエアの保守費用は非常に大きなウエイトを占めます。場合によっては、開発費よりも保守費の方が多くなることがあるといっても過言ではありません。こうなりますと、開発費は資産で保守費は経費というのは首尾一貫しないことになります。
・建物や設備は成長しません。しかし、販売用のソフトウエアは子供と同じで、成長させないとたちまち陳腐化して市場で死んでしまいます。競争相手と競いあって、毎日毎日改良しないといけないものなのです。また製品ジャンルにもよるとは思いますが、一般的には常に新鮮に保たないとお客さんは購入しません。また、販売用ソフトウエアの技術環境は非常に変化が激しいですから、放置すればたちまち陳腐化してしまいます。3年分割で償却するというのは、市場の実態から完全に乖離していると思います。
・市場で販売する製品の価格は、市場で決まるものであって外部要因で大きく変動します。それに対して、建物や機械類の価値は自社で利用する価値です。市場が価値を決めるものと、社内の利用価値で決まるものを取得価額で資産計上するという同じ考え方を取るのはおかしいでしょう。

こうしたことを鑑みますと、私は、販売用ソフトウエアを、建物・機械類と同じような固定資産に計上するという税務処理の要求は、経営的には妥当ではないと考えます。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月15日

XML10周年

今年は、XMLが制定されてから10周年です。

W3Cは、XML10周年の記念祝典をいろいろなところでやろうとしています。

W3C XML is Ten!
Community Invited to Celebrate XML Everywhere

日本でもXMLコンソーシアム主催の祝賀会が予定されています。

名称：XML1.0勧告10周年記念イベント『XML Today & Tomorrow』
主催：XMLコンソーシアム　http://www.xmlconsortium.org/
日時：2008年3月5日（水） 10:00～19:00
場所：慶應義塾大学　三田キャンパス 北館2階ホール
参加費：XMLコンソーシアム会員、パートナー（後援団体）会員、学生＝無料
　　　　非会員＝2,000円

詳細情報は、こちらでご確認ください。
http://www.xmlconsortium.org/

10周年。長いやら短いやら。

XMLのお陰で、アンテナハウスは、昔からの念願であった世界市場での製品販売ができるようになりました。XMLがUnicodeを基本としていたことと、それから、国際性ということがさまざまに考慮された設計になっていることがその大きな要因だったと思います。XMLを処理するアプリケーションは、多言語処理をしやすくなりますし、また、XMLを利用した国際標準をサポートすれば、世界共通で使えるものになり、世界の市場で販売することができる製品になります。

3月5日は、私は、ボストンのAIIMに参加する予定ですので、参加できませんが、考えて見ますと、ボストンのAIIMに参加できることもXMLのお陰ということなんですね。人間（会社）の運命は分からないものです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月14日

Page2008 トークショウ「コンピュータ組版の軌跡2」（5）

さて、最後にフォントについての話題を整理しておきます。コンピュータ組版を構成する最大の要素のひとつに、アウトライン・フォントがあります。

写研といえば、組版システムと同時にその高品質なフォントが非常に高く評価されている会社です。

1970年代から1980年代は、文字を出力する技術が光学式出力からレーザ出力（レーザ）とディスプレイへの表示へと変化を遂げた時代です。小野沢氏のお話では、1980年代前半には写研では、雑誌・新聞などのためのレイアウト装置を開発したが、ドットフォントではWYSIWYGにならなかった。しかし、1985年にアウトライン・フォントをバッチ処理組版で使った、とのことでしたので、1985年頃が印刷業界での、ドットフォントからアウトライン・フォントへの移行の端境期だったのではないでしょうか？

現在は、Adobe、Apple、Microsoftの3社が、アウトライン・フォントのベース部分を押さえているように思います。しかし、調べてみますと、写研もCフォントというアウトライン・フォントを1983年に発表しています。

Cフォント(Wikipedia）

ですので、1980年代初めにおいては、決して米国勢に遅れをとっていたわけではないように思います。
1986年に、アドビが写研を訪問して、フォントの提供交渉をしたが断られ、結局、モリサワがアドビにフォントを提供するようになったのは有名な話です。

なぜ写研が、アドビへのフォント提供を断ったか、詳しいことは分からないようですが、島袋氏の推測では、写研は、同社の機器の顧客である中小の印刷会社を守ろうとしたのではないかということです。すなわち、写研フォントをDTPソフトで使うことができるようにしてしまえば、これまで多額の設備投資をして写研のシステムを導入した、印刷会社の仕事が、編集者や制作会社に流れてしまうことになりますので、それを防止しようとしたのではないか？とのこと。

初期においては、モリサワからアドビに提供したフォントは、基本的な明朝・ゴシックのみのようでした。

その後、Windowsには、リョービのフォントを元にMS明朝、MSゴシックが作成されて搭載されるようになり、パソコンでアウトラインフォントが自由に使えるようになってきて、現在では、一般のユーザでも基本的なフォントを使った文書であればWYSIWYGで作成できるようになっています。しかし、まだ印刷会社が使うような高品質なフォントを誰でも使えるという状況にはなっていません。

一方、写研のフォントは、だんだん伝説化しつつあるといったら言い過ぎでしょうか。少なくとも、一般の人が写研のフォントを使って制作した印刷物を目にする機会はだんだん減っているのは間違いないところでしょう。

この間、現在までに約20年を経過しています。しかし、いつでもどこでも高品質フォントを使って、文書を可視化できるという状況ではありません。Web時代を迎えた現在では、フォントに対する要求はさらに強まっていると思います。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月13日

Page2008 トークショウ「コンピュータ組版の軌跡2」（4）

さて、トークショウの続きで、組版システムの話をもう少し。

小野沢さんのお話では、1970年代から1980年代の写研の組版システムの話がいろいろ出てきましたが、正直言って機械の名称を聞いても違いが理解できませんでした。大体理解できましたのは、1970年代から1980年代には写研もかなり挑戦的・アグレッシブに、組版システムの開発を行っていたということです。1970年代後半から1980年代には、東南アジアを中心にシステムの輸出も行ったとのこと。

しかし、なぜ、写研が、QuarkXPressなどのDTPシステムに取って代わられてしまったのでしょうか？やはり、コストが高かったということなのでしょうか？

しかし、機械のコストだけの問題であれば、ハードウェアをパソコンに乗り換えて安くするとか、コストダウンするという対策は、いろいろありそうに思います。コストが高かったというのは、極論すればコストを下げようと努力しなかった結果に過ぎないともいえます。

また、コストだけが全てであるとすると、例えば、XSL Formatterは、オープン・ソースの無償ソフトであるFOPには絶対に勝てないことになります。しかし、現実には、無償のソフトがあったとしても、有償ソフトで商売できるのです。こういう例を見ましても、単にコストが高いというだけで、物事が決定してしまうということはないはずなので、本当は他に理由があるのかもしれません。

さて、日本製の組版ソフトといえば、ジャストシステムの「大地」の話も出ましたが、もはや「大地」を知っている人は少ないでしょう。

凸版印刷も1980年代には、研究所で組版システム製品を開発して販売していたそうです。やはり、1980年代の終わりには、DTPの波が押し寄せて、日本でも日本製DTPを作ろうという小さな波があったということ？

CTSにせよ、写研の組版システム、凸版の組版システム、大地など、日本のコンピュータ組版が華々しい脚光を浴びたのは1970年～2000年のわずか30年程度。2000年頃までには、欧米製パソコン上のDTPソフトに、その主役の座を譲ってしまいました。

私は、印刷業界にはあまり詳しくないのですが、このあたりの歴史のうつろいには感慨を覚えますし、業界の盛衰記としてまとめられると興味深いように思います。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月11日

Page2008 トークショウ「コンピュータ組版の軌跡2」（3）

前回は、コンピュータ組版からマークアップ言語の歴史の話に、脱線してしまいました。このブログを読まれている皆さんは、「マークアップ言語などあまり関心がもてないなあ」、と感じておられるかもしれません。

しかし、いま、お読みいただいているブログも、また、Webページも、マークアップ言語の応用であるHTMLで記述されているのですから、60年代に生まれたマークアップ言語こそが、現在のインターネットの興隆の一大要因になっていると言っても過言ではないでしょう。

ますます、脱線してしまいましたが、話を元に戻しますと。

小野沢氏はGenCodeを印刷のための共通入力形式に利用できないかと考えたとのことですが、それはその後の「SGML懇談会」でSGMLを共通データフォーマットとして利用する研究に繋がったとのことです。そして、その活動の中から、最初のJIS X4051（日本語文書の組版方法）が生まれました。

JIS X4051は、日本語の組版をするための規則をJIS化したもので、大きな成果だと思いますが、残念ながらその規格を実際の製品に反映したのは、マイクロソフトのWordや、最近ではアドビのInDesignなど米国のメーカになっているようです。しかし、最近では、XSL FormatterもJIS X4051を（部分的に）実装していますし、次のバージョンでは、よりJIS X4051の実装レベルをあげようとしていますので、弊社にとっても大きな効果をいただいています。

いづれにしても、従来は、編集者や印刷の専門化の頭の中、あるいは、出版者のハウスルールとしてばらばらになっていた情報がJISの形で体系化されたことは後世のためにも大きな功績と思います。

現在は、このJIS X4051をベースとして、Webブラウザなどのための組版の要求をまとめる作業が、W3Cのタスクフォースとして行われています。

1980年代終わり頃から始まった、マークアップ言語の研究が、現在まで作業として続いているということになります。

さて、1980年代の組版システム製品として、島袋氏から富士通のIPSの話がありました。富士通のIPS(富士通統合印刷システム)は、800ユーザ、1200システムの実績があったとのことですので、すごいものです。凸版印刷の営業としては、出版社にシステムを持ち込み、出版社の中でレイアウトし、その場でOKをとるというやり方だったらしいです。これは印刷会社の人が入力やレイアウト作業をしたのでしょうが、コスト的に高くついてしまい、その後はDTPに取って代わられたようです。

なお、IPSは、印刷会社よりもむしろ新聞業界に沢山はいったという話もありました。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月10日

コンポーネントは、.NETが旬

昨日のコンポーネント・ソース社のベストセラー製品トップ100を見ますと、売れているコンポーネントの大勢が、.NET用になっていることに驚かされます。

上から見ていきますと、
１．NetAdvantage for .NET (.NET）
２．ActiveReports for .NET（.NET）
３．DXperience （Visual Studio .NET component）
４．ComponentOne Studio Enterprise（ .NET, ASP.NET ( AJAX ready), ActiveX, and Mobile Devices）
５．Installshield 2008 Professional（Windows汎用）
６．Janus WinForms Controls Suite （.NET managed code component）
７．Telerik RadControls for ASP.NET
８．.Spread for Windows Forms （Windows汎用）
９．Altova® XMLSpy 2008 Professional Edition（Windows汎用）
１０．TX Text Control .NET

上位のうち、Windowsネイティブは、おそらく3種類、Javaはゼロです。7割が.NETです。

これらのコンポーネントは、サーバサイドというよりもクライアントサイドのリッチなアプリケーションを簡単に作るためのものが多いので、Windowsの上では、どうしても.NETになるのでしょう。

このベストセラーの傾向は、世界の開発者が.NETに完全にシフトしたことを雄弁に物語っていると思います。

但し、11位以降になりますと、JAVAも現れます。
１１．Dundas Chart for ASP.NET
１２．Pcl2pdf （Windows　DLL、C++？）
１３．InstallAnywhere （JAVA）
１４．.Janus Web ASP.NET Server Controls Suite
１５．ActiveReports(ActiveXフレームワーク）
１６．GTP.NET
１７．Spread （MFC）
１８．LEADTOOLS Raster Imaging （MFC）
１９．RadControls for ASP.NET + WinForms + Reporting
２０．NetAdvantage for .NET + WPF
２１．Chart FX (.NET)
２２．Spread for Web Forms (.NET）
２３．Wise Installation Studio（Windows汎用）
２４．Wise Package Studio （Windows汎用）
２５．Codejock Xtreme ToolkitPro（MFC)

これを見ますと、MFCなどで作っているC++のコンポーネントが.NETに次いで多いですが、JAVAは25位までに１件しか現れません。

数年前は、コンポーネント・ソースのカタログ誌に掲載されている製品はJAVAと.NETが半々だったように記憶していますが、最近は、カタログに掲載されている製品でもJAVAは少数派になったようです。

世界の開発者の潮流は完全にJAVAを離れた、と言ったら言いすぎでしょうか？

投稿者 koba : 08:00 | コメント (1) | トラックバック

2008年02月08日

Page2008 トークショウ「コンピュータ組版の軌跡2」（2）

1970年代のコンピュータ組版の話を読みますと、コンピュータの計算能力が足りないのと、ディスプレイや出力機などの適切な周辺機器がなかったことで、大変な苦労をしていることが良くわかります。

1980年代になって、ビットマップディスプレイやレーザプリンタが登場したことで、コンピュータ組版はがらっと様変わりしたようです。

次は、組版言語の進歩です。
【凸版印刷におけるCTS開発】
　　http://www.jagat.or.jp/story_memo_view.asp?StoryID=10739　

には、凸版印刷で、TCL（Toppan Composition Language）を作ったという話が出ています。詳細は知りませんが、組版用の言語ということは、今のXSL-FOの先駆けのようなものでしょうか？

小野沢さんのお話では、1986年のTechDocコンファレンスで、GenCodeというSGMLの前身のマークアップ言語が出ていたとのことです。

1980年代に、PostScritのようなページ記述言語（PDL）が登場する一方で、マークアップ言語で、コンテンツとレイアウトを分離する技術が登場してきているのが面白いことです。

GenCodeという名前は、私は初めて聞きました。そこで、少し調べてみました。以下は、 トークショウとのお話ではありませんが。

GenCodeという名前は、SGMLの歴史の中にちょっと出てきます。
http://xml.coverpages.org/sgmlhist0.html

1960年代の終わりに、Stanley Riceというニューヨークの本のデザイナが、パラメータ化した編集構造タグという概念をだし、それに注目したGCA（現在は、Idealliance）のNorman Scharpfが、組版委員会の中に、一般化コーディング（GenCode）プロジェクトを起こしたのだそうです。

この委員会で、異なる種類の文書に異なる種類の一般コードが必要であり、小さな文書を組み合わせて大きな文書を作るということをGenCodeという概念にまとめたとのこと。それにしても1986年まではずいぶん時間がかかっています。

WikiPediaにも出てきます。
Markup language
William W. Tunnicliffe が"generic coding"を1967年の会議で提唱したと。

1960年代にマークアップ言語の源流が生まれたようですね。

マークアップ言語でドキュメントをマークアップすれば、今度は、それを整形・組版するソフトが必要になるのは、あたかも男と女がいて初めて、人類が繁殖するようなもの（？）。

マークアップ言語はGenCode-->SGML-->XMLと発展してきたことになりますが、組版レイアウト指定言語の方は、SGML時代のDSSSLからXML時代のXSL-FOという発展になるのでしょう。DSSSL以前はどうなっていたのか？これはまたそのうち調べてみよう。

1980年代半ばは、DTPが生まれて、1990年代を経て、現在はDTP全盛ともいえますが、その一方で、マークアップ言語による組版も平行して発展しています。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年02月07日

Page2008 トークショウ「コンピュータ組版の軌跡2」（１）

昨日から池袋でPage2008が始まりました。初日は、レセプションに代えて　「コンピュータ組版の軌跡2」という題で島袋徹、澤田善彦、小野沢賢三３氏によるトークショウがありました。
　・コンピュータ組版を中心とした過去の変革を総括し、次世代に何を伝えていくか？
　・昨年、取り上げた「コンピュータ組版の黎明期、1970年代」に続き、
ということで、80年代以降のコンピュータ組版、デジタルフォントについての議論がなされました。

これから先の未来に思いをはせながら、業界の先輩の思い出話を楽しくお聞きすることができました。先輩方の過去のお話を伺っている中に、未来への課題も幾つか見つかります。未来への課題につきましては、私たち、現役世代としては、実践の中で回答を出していかねばならないと気を引き締めているところです。

さて、お話の内容ですが、1970年代はコンピュータ組版の黎明期、ということですが、1980年代はいよいよコンピュータ組版が実用になってきた時代ということです。コンピュータ組版と一言で言いましても、次のようないろいろな技術があります。

１．文字の入力
２．印刷のための出力機
３．画面表示
４．組版指定・組版ルールを指定し、実行するプログラム
５．フォント技術
６．組版規則

文字の入力、ということについては、1970年代はタブレット入力から、80年代にはかな漢字変換に代わったのが大きな変化です。さらには、小野沢氏からは、ワープロ専用機でデータを入力し、その結果を写研のシステムに変換するようになってきて、写研側ではクレームが多くなって困ったという発言もありました。

アンテナハウスでも、1980年代はワープロ専用機で作成した原稿を、印刷会社が電算写植機のデータに変換するためのコンバータで大いに商売をさせてもらいました。但し、弊社の製品は、MS-DOSテキスト・ファイルへの変換であり、写研へのコンバータは開発していませんでしたので、小野沢氏にご迷惑をお掛けすることはなかったと思います。

次の出力機という点では、1970年代は光学式の時代でしたが、1970年代後半から1980年代にかけてレーザによる出力の時代に変わったということになります。また、表示装置も、1980年代には、画面で構成できるディスプレイ付きの組版機となり、さらには、ビットマップ・ディスプレイで出力と同等内容を画面で確認できるようになってきました。

　（※参考記事）
　【凸版印刷におけるCTS開発】
　　http://www.jagat.or.jp/story_memo_view.asp?StoryID=10739　

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年01月30日

サーバ製品の価格設定基準

昨日、PDF Libの6から7で値上げしたと書きましたら、ライセンスを数えるときの基準が変わっているのだそうです。そこまで深く考えませんでした。失礼しました。

サーバ製品の価格設定について、時々、お問い合わせをいただきますが、説明したり比較するのはなかなか難しいものがあります。サーバ用の開発ツールのライセンス料金の計算で、注意すべきことを次に整理しておきます。

１．開発用ライブラリーでは、CAL（クライアントアクセス・ライセンス）を設定しているものは少ないようですが、まず、CALがあるかどうかは大きな違いです。

２．どこまで再配布可能かどうか。
(1)アンテナハウスでは、現状、すべての製品についてOEM契約なしの再頒布は認めていません。
(2)他社のPDF関係の製品を見ますと、ABCpdfという英国製の開発ツールは、企業内、または、製品単位の無制限再配布を認めるライセンスもあります。
(3)一方でランタイムを再頒布することを認めている製品も多く見られます。但し、PDF関係でランタイムを再頒布可能という方式をとっているものは知りません。

３．それから、今回出てきましたライセンスをカウントする基準
(1)CPU単位でライセンスを計算するとき、厳密には、コア単位かそれともソケット単位かの区別が必要です。
　　マルチコアというときは、CPUコアは二つあってもソケットは1個になっているものが多いですね。
　　ですので、コア単位かソケット単位かで数倍の差がでてきます。
　　ちなみに、アンテナハウスはソケット単位としています。
ちなみに、PDFLibでは台数といっていますが、台数とソケット単位は、おそらく同じではないでしょうか。

最近ややこしいのは、VMｗａｒｅなどで仮想化したシステムの場合ですね。この場合、物理的なCPUと仮想化ソフトウェアの上でカウントするCPUの数が違ってきます。

(2)CPU数あるいはPCの数は問わずに、１つのシステムを単位にして価格を設定する方式もあるようです。

４．サーバとはなにか？この定義も結構ややこしいですね。
この間、セミナーのあとで、お客さんに、「Webサーバと接続したPCにFormatterを載せて動かしている場合、Formatterが動いているPCは、Webサーバ１台としかつながっていない。ですので、それはサーバじゃないと考えて良いのでは？」という、質問をいただきました。

「つながっている台数は関係なくて、ネットワークを経由して他のPCに機能を提供するとき、サーバと言います」、と答えましたが、なかなか納得していただけなくて困りました。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年01月20日

天才詐欺師か大経営者か？

『検察を支配する「悪魔」』（田原総一朗・田中森一著、講談社刊）を読みました。本の主題である「検察が、国策捜査の名の下に、国家権力を濫用して冤罪を作る」という話も空恐ろしいものですが、まじめな会社経営という観点からも参考になる箇所がいろいろありました。

例えば、バブルの時代、総額二兆円を食い尽くしたといわれる許永中ですが、田中氏は、許永中は、「もの凄い企画者、プロデューサー」だと言っています。例えば、大阪にオリンピックを招致しようとして考えて、大阪帝国ホテルのタワー棟の高階層を上から三フロア借り切って、そこにつくった「アメリカンクラブ」という社交場なんて、なかなか凄いアイデアだと思います。私などはそういう壮大なアイデアは考えつけません。

松下幸之助の本には、「芸術家がキャンバスの上に絵を描くのと同じように、経営者は経営資源を使って新しいものを想像する存在である」という話が載っていたように記憶しています。

また、稲盛塾長は、「未来進行形で考えること。いま出来ないことでも、未来の時点でできるようになる。そういう人間の能力を信じて、今はできないことでも注文をとってきて約束した納期までに完成させる。」と言っています。

こうなりますと、会社の経営で大成功するには、許永中のような側面が必要ということになります。最初に構想した大きな絵を実現できれば成功した大経営者として尊敬され、実現できなければ天才詐欺師として塀の中ということになるのでしょうか？

それから、政界のタニマチ、中岡信栄。拓銀系列のノンバンク、エスコリースから2000億円の融資を引き出して焦げ付かせ、拓銀破綻の原因を作った男。彼が、金をだれかれ構わず金をばら撒くのはタニマチ心理がよく説明されていて理解できました。このタニマチ心理は、OASISやW3Cなどの、必ずしもならなくても良いコンソーシアムのスポンサーになる企業経営者の心理と似ている部分があるように思いました。使う金の桁が数億倍位違うけれども。

使った金を売上で回収できればビジネス行為、しかし、使った金の回収を期待しなければタニマチ。しかし、広告宣伝費なんて効果があるかどうかは全然予測できませんし、終わった後でもわからないことが多いものです。このようにビジネス行為とタニマチの境界にはなかなか難しいものがあります。

今月は、確かPDF製品だけで数百万円以上の雑誌広告費を使っているはず。多分、今月はアドビ・ジャパンよりPDF関連の雑誌広告費は多いでしょう。しかし、今月のPDF製品売上は幾らになるか今のところ予想もできません！？パソコン雑誌のタニマチになろうとしているわけでないことは確かなんですけどね。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年01月19日

2008年・PDFビジネス売上50%増宣言！

アンテナハウスは、この数年間、デスクトップ製品よりもシステム製品に力を入れてきました。その結果、昨年(2007年)は、システム製品の売上が、2006年に比べて倍増になりました。

2000年頃は、いまよりも遥かに利益が出ていましたが、言ってみれば、一発ヒットを出して儲けているというハイリスク・ハイリターンそのものでしたが、この6,7年で会社のビジネスの内容も代わり、ヒット商品への依存度が減りました。

国内ビジネスは、デスクトップ製品、システム製品、OEMと3つの柱ができ、それに海外ビジネスを加えますと、４つの柱ができた状態です。会社の規模は小さいですが、2000年頃と比べて、かなり経営の安定性が出てきたと思います。

そんなことで、2008年からは、いよいよ、会社を成長へ向けて駆動させなければなりません。今年は、とにかく、売上35%増！特にPDFビジネスは、5割増を必達目標として掲げています。

「有言実行」は、「不言実行」より遥かに難しい！だから、「有言実行」で、自分を追い込んで絶対目標を達成せざるべからずで取り組むべき、とは、盛和塾の稲盛塾長がよくおっしゃっていること。

ということで、今年は、売上35%増！（PDFは50%増！）をここに宣言したいと思います。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年01月16日

官庁PDFは、なぜ、セキュリティが設定されている？

15日の朝のニュースで、「12月の景気ウォッチャー、36.6に低下」というニュースがありました。いよいよ不景気がやってきたかと、詳しく見たいと思いました。

内閣府の「景気ウォッチャー調査」の報告ですが、この報告書の内容抜粋はHTMLで、詳細資料はPDFで公開されています。

景気ウオッチャー調査>景気ウオッチャー統計表一覧>2007年12月
「景気ウォッチャー調査　平成19 年12 月調査結果」

このPDFをダウンロードしてみますと、しおりもリンクもないため、非常にナビゲーションがしにくいものとなっています。しおりでページをたどったり、目次から本文へのリンクもしたいのですができません。結局、このままでは、紙に印刷して読むのが一番読みやすいようです。

そこで、ナビゲーションし易くするため、自分でしおりをつけようと思って、PDF編集ソフトを使っても、しおりをつけたり、リンクをつけることができません。

「編集禁止」になっているからです。但し、内容のコピーと印刷は許可になっています。ですので印刷はOK。

それにしても、内閣府は、こんな調査報告書まで、なぜ、編集禁止にしているのでしょうか？内容のコピーは許可になっていますので、コンテンツを取り出して利用することは可能です。このことから見ますと、再利用をさせたくないということでもないようです。

改竄させたくない、ということなのだろうか？しかし、調査資料PDF自体が公開されているのだから、だれだって原典にあたることができるので、改竄のすること自体、徒労のように思うのですが。

このPDFに限らず、Webで公開されている官庁系のPDFは、どうも不必要に編集禁止などのセキュリティをつけているケースが多いようです。折角、資料を公開するのなら、電子的に閲覧しやすくして欲しいし、そこまでは手間がかかるというのならば、ユーザがしおりやリンクを設定するなどの編集を許可にして欲しいものです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年01月08日

昨日は、ブログサーバのダウンでご迷惑をお掛けしました。

1昨日（1月6日夜）から昨日（1月7日朝10時頃まで）ブログサーバが、ハードウエア（電源の故障）でダウンしました。

正月早々のダウンでご迷惑をお掛けし、申し訳けありませんでした。

「PDF千夜一夜」ブログサーバのダウンは、2005年10月開始以来2回目です。最初は、昨年の初め（2007年2月17日）です。その時はハードディスクの故障でした。このためバックアップのない部分のデータ復旧に、頭の中のサルベージも必要でかなり時間がかかりました。

今回は、正月休みの間、システム管理担当者がお休みでバックアップがなかったので、「ハードディスクが壊れてたら、正月休みの間に書いた内容を全部思い出せそうもない。どうしよう。マーフィーの法則じゃあるまいし、一番都合の悪いときに不幸がやってくるなんて。」と不安に駆られましたが、今回は、ハードディスクはなんともなかったようで、不幸中の幸いでした。

それにしても、ハードウエアが1年前後で、壊れてしまうなんて、近頃のPCハードウエアの弱さにはちょっとあきれてしまいます。「ブログサーバは、経営の根幹にはあまり関係ないのでダウンしたところで、生き死にの問題はない。」と高をくくっていますが、本心、冷や汗タラタラです。

「ソフトウエア屋としては、ハードウエア屋さんに、もっとしっかり作ってよ！」と言いたいです。
（もしかしたら、もっと頑丈なハードを買えよ！と反論されたりして。しかし、そういう反論は許されませんよね）。

いづれにしてもPCはバックアップ必須なことを再度痛感しました次第です。皆様もご注意ください。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2008年01月01日

明けましておめでとうございます。

いよいよ、今日から2008年が始まります。今年は一体どんな年になるのでしょうか？

振り返ってみますと、昨年はWindows Vistaの登場とOffice 2007という大きな出来事があり、弊社も昨年の冒頭はWindows Vista対応で忙しかったことを思い出します。今年は、サーバサイドではWindowsサーバ2008のリリースがありますね。

「PDF千夜一夜」も、既に、800日を過ぎ、第4コーナーを回って最後の直線！

アンテナハウスは、2008年が会社設立25期目になります。1990年代までは「リッチテキスト・コンバータ」が主力製品でした。2000年代に入って「リッチテキスト・コンバータ」の売上が急激に減少するなかで、それに代わる主力製品の育成に力を入れてきました。ここにきて漸く、XSL FormatterやPDF関連製品の売上が増えてきて、主力製品の入れ替え完了の宣言ができる状態となりました。

今年は再び発展を目指すことができそうで楽しみです。

ところで、正月ということで、昔の経営計画を振り返って捲って見ましたが、弊社では2000年の経営計画からずっと、欧米で売れる製品を出したいということを重要テーマにしていました。そうしますと、もう満7年になるのですが、2007年は日米連結の売上の約30%弱を欧米市場で販売できました。

やはり、「思念は実現する」ということを改めて実感します。毎年、目標を設けて何が何でも、これを達成しようと努力を続けていけば、だんだんとそれが現実になるということです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年12月03日

石の上にも三年

「石の上にも三年」という諺があります。

「冷たい石も三年座り続ければ、暖かくなる」という意味から、「どんなに苦しくても大変でも、じっと辛抱すれば必ず報われる。」という風に使われるようです。

「千夜一夜」の1000日というのも大体3年に相当します。もしかして、「アラビアンナイト」も石の上にも三年派？

ところで、アンテナハウスは12月決算なので、あと1ヶ月で2007年の成績が決まります。今年を振り返ってみますと、「サーバベース・コンバータ」など2004年に開発を始め、2005年に発売した製品が2007年の今年になって、だいぶ売上が増えてきました。ようやく製品・ビジネスとして成立する見通しが付いたと言ってもよさそうです。

昔からビジネスは3年位で目処をつけると言われていました。1年目、2年目は投資期間、3年目で収支均衡させ、4年目から利益を出す。5年位で累積黒字とする、というようなビジネスプランを立てたら良い、という意味です。そうしてみますと、インターネット時代になって、情報の流通速度が飛躍的に速くなって、世の中の動きが早くなったように見える今日でも、やはり3年がひとつの区切りになるという状況は変わっていないのでしょうか？

「アンテナハウスPDF」は、2005年8月自社ブランドPDF製品として参入しました。大体2年強を経過したところです。丁度3年目のこれから1年間が勝負どころになりそうです。

今月、12月に「リッチテキストPDF4」、「書けまっせ!!PDF3」を発表する予定ですが、今度のバージョンで、ひと勝負！

今度の「書けまっせ!!PDF3」はお勧めです！10万本もいけそう！！いやいや、英語版も出しますから、これで100万本いきましょう！！初夢はきっと100万本売って50億円。来年が楽しみです。（この部分は、ホラです。お間違えのないよう。）

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年11月29日

PDFと署名(49) — PDFの電子署名問題

PDFと署名(48) — PDFの電子署名とタイムスタンプの相互運用性で、PDF電子署名とタイムスタンプに相互運用性が必要だと申し上げました。これに関連して、次のような意見をいただきました。

「アドビの仕様以外の各社の独自仕様は各社のツールが検証できるようにするだけで良いのでは？」

これは、たぶん、電子署名を昔からやってきて、Acrobat上に独自仕様のプラグインを開発して提供している人たちの共通の考えだと思います。

この件について、少し詳しく説明してみます。これは、問題の例としてアドビ以外のツールでつけた電子署名を、Acrobat（Reader）に内蔵している標準ハンドラが検証してしまうことがあります。

Acrobatのデフォルト署名ハンドラが、「検証できない」と言ってくれれば良いのですが、検証してしまって、エラーのレポートを出してしまうことが往々にしてあります。

これは、Acrobatだけではありません。

A社のツールでつけた署名を、A社のツールとB社のツールで検証した結果、異なるレポートが出てしまうという問題です。

A社のツールでつけた署名をA社のツールで検証すると、「署名後変更されていません」とレポートが出るのに、B社のツールで検証すると、「署名が壊れています」、あるいは、「署名後に変更されています」、などと報告されてしまう事態が起きてしまうという問題です。

こうなりますと、どちらを信用したら良いか分からない、ということになります。

PDFの電子署名仕様は、かなり複雑なので、PDFの署名フィールドの設定が少し違うだけでこういう事態が起こる可能性があります。

結局、最初にご紹介しました、「アドビの仕様以外の各社の独自仕様は各社のツールが検証できるようにするだけで良い。」という考え方は、閉鎖されたグループの中では適用できるものの、開いた・オープンなグループには適用できないということだろうと思います。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年11月21日

オープンソースって優れているから脅威なの？

「ウェブ時代をゆく」（梅田　望夫著　ちくま新書）を読んでいます。この本は、著者の梅田氏の仕事感・職業観についての本です。

対象の読者は、恐らく、30才代以前の年齢の人達だろうと思いますが、この本にはアイデアが溢れています。特に、「ロールモデル思考法」なんて、今まで考えてみたこともありませんでした。私にとっては、それだけで、読む価値があります。

ところで、ひとつだけ、文句を言いたいことが。

梅田氏は、オープンソースを盛んに持ち上げています。特に、例えば「リナックスのように成功するオープンソース組織は強固なものとなり、成果物たるソフトウェアの性能や品質が、営利組織によって作られたものを大きく凌ぐという摩訶不思議な現象を引き起しているのである。」（p.182）というような記述が何回も出てくるのは、ソフトウェア・メーカの経営に携わるものにとって、率直に言って、まったく我慢できません。

私は、リナックスが、Windowsより優れていると思ったことは、過去に一度もありません。また、例えば、弊社のXSL Formatterと競合するオープンソースにFOPというのがありますが、恐らく、XSL-FOの専門家100人に聞いて、FOPがXSL Formatterより優れているという人は、居るかもしれませんが、極僅かなことは確かでしょう。

プログラムには、無論、出来の良し悪しがあります。オープンソースで良いものもあるでしょうし、営利組織の作った製品で良くないものもあると思います。しかし、恐らく、全体としていえば、オープンソースの方が玉石混交で、使えないものが多いでしょう。私の経験ではオープンソースで、本当に良いと思ったソフトウェアはないとは言いませんが、極少ないです。営利組織の方が平均すれば品質は良いのではないでしょうか。

まあ、こういうことは、検証可能な数字で議論しないと水掛け論ではありますが。

「オープンソースが産業界にとって脅威」という言葉もでてきました。確かにオープンソースは脅威ではありますが、その理由は、私の立場からは「オープンソースは無償なので、マーケットがデフレ構造になってしまう。」という理由です。「オープンソースが優れているから脅威だ。」と思ったこともあまりありませんね。

という訳で、「面白い！」「腹が立つ！」の繰り返しで読んでいる本。そういうにはめったに出会えませんね。梅田さんありがとうございました。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年11月19日

バグほど高いものはない。バグ一匹20万円也

先月までの数ヶ月で、XSL FormatterのサポートにJAVAインターフェイスに問題が出ているという報告が数件溜まりました。片手間の調査を進めても、なかなか原因が判明しません。しかし、社内の担当者を調査専任にアサインする余裕がありませんでしたので、取引先で一番優秀なエンジニアに常駐してもらい、2週間ほど徹底的に調査･デバッグをしてもらいました。

その結果、JAVAのインターフェイス自体には問題が見つかりませんでしたが、JAVAのサンプル・プログラムに問題があることと、マルチスレッドがらみのバグが2つ見つかり修正しました。JAVAインターフェイスを使いますと、Formatter本体はマルチスレッドで動かすことになりますので、このあたりが問題の原因だったのかもしれません。

マルチスレッドがらみのデバッグは大変難しいと言われています。従って、2週間で2個の障害発見は、大きな成果ともいえます。それは、良かったのですが。

今は、デスクトップでソフトウェアを動かす時代から、サーバサイドでソフトウェアを動かす時代になっています。弊社の売上も、既に、デスクトップ製品よりも、サーバ製品（システム製品）の方が多いかもしれません。

サーバ製品の場合、24時間稼動が当たり前になっており、デスクトップ製品と比べて格段の信頼性と安定性が求められることになります。

しかも、システムが複雑になりますし、使い方が良くない可能性もあります。クレームが来ても、どこに問題があるか特定し、その問題を発見するのが大変難しくなります。

北海道のお菓子屋さん「柳月」の田村社長は、ケーキ1個160円で売るために、従業員に「ケーキ1個壊すと、16個分の利益が吹っ飛ぶ」と教えているそうです。そういう意識をもってもらってコストダウンを図っているということです。

今回、バグ1個の修正コスト20万円也についたわけですが、バグほど高いものはありません。コストを下げるためには、最初から、バグを埋め込まないように作るのが一番です。

先週末、「PDF Tool V2.6MR1」をリリースしました。これも、バグ修正版です。ふーー。蛾の悪夢を見てしまいそう。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年11月17日

検索キーワードとしての”PDF”

いつも思うことなのですが、Googleで”PDF”で検索しますと、ファイル形式[PDF]の検索結果が混ざっています。しかもそれが上位に多数出てきます。ちなみに20番目までの中で、テーマ(トピック)としての”PDF”という事柄に関連するWebページは、9件しかありません。

検索のキーワード："PDF" GoogleでWeb全体から検索。1,850万件の上位１～20番
--------------------------------------------------
1 Adobe - Adobe Readerのダウンロード - すべてのバージョン
2 Portable Document Format - Wikipedia
3 PDFとは 【Portable Document Format】 - 意味・解説 ： IT用語辞典
4 クセロPDF／瞬簡シリーズ
5 [PDF] IT 政策パッケージ-2005
6 PDFとは - はてなダイアリー
7 [PDF] PLAYSTATION 3 2006年11月11日 日本国内発売
8 PDFの作り方 - TeX Wiki
9 [PDF] 東京近郊路線図
10 [PDF] 再 入 国 許 可 申 請 書
11 [PDF] e-Japan 重点計画ー2004
12 ソースネクスト：「いきなりPDF」シリーズ
13 [PDF] - 1 - ノロウイルスに関するQ＆A （作成：平成16年2月4日）
14 [PDF] Authoring Tool Accessibility Guidelines 1.0
15 [PDF] 「貸します詐欺」
16 クセロPDF2(WindowsNT/2000/XP/Vista / 文書作成)
17 XLsoft エクセルソフト : activePDF 無料 PDF 作成/変換ソフトウェア ...
18 [PDF] カーネル法による複数のゲノムデータからの タンパク質間機能 ...
20 [PDF] pdf
--------------------------------------------------

[PDF]が付いているのは、ファイル形式がPDFであって、主題はPDFとは無関係と思われます。どうしてこういう検索語とはあまり関係ないと思われる項目を除外できないのかな。

一方、Yahooで”PDF”で検索しますと、次のような結果になります。Googleとは違って、ファイル形式が[PDF]のページは検索結果にはでません。

検索のキーワード："PDF" Yahoo(ジャパン）でWeb全体から検索。上位１～20番
--------------------------------------------------
1 Adobe - のダウンロード - すべてのバージョン
2 PDFの作り方 - TeX Wiki
3 Adobe - Reader
4 Portable Document Format - Wikipedia
5 クセロPDF/瞬簡シリーズ
6 PDF Conference On the web
7 PDF総研
8 PDF|PDFに簡単変換してダウンロードできる「BS-PDF」
9 PDFとは - はてなダイアリー
10 印刷通販のＰＤＦ印刷
11 PDF Adviser: ホーム
12 ライブPDF
13 無料PDF変換作成ソフトXeloPDF
14 PDF無料活用クラブ
15 PDFと帳票システムのYSS
16 PDFとは 【Portable Document Format ...
17 ソースネクスト・ドットコム/PDF作成ソフト/いきなりPDF ...
18 新・フリーソフトで作るPDF!
19 PDF、文書変換と表示、XSL-FO組版のアンテナハウス株式会社
20 ソースネクスト・ドットコム/PDF作成ソフト/いきなりPDF
--------------------------------------------------

この結果だけで見ますと、GoogleよりYahooの検索結果の方が適切な（妥当な）ように思います。「ひょっとすると、Yahooの検索エンジンの方が妥当な検索結果を返すようになってきているのかもしれないなあ。そろそろ普段使う検索エンジンをGoogle一辺倒から見直しする方が良いかな。」と思うこの頃です。しかし、習慣とは恐ろしいもので、なかなか、Google頼みから抜け出せません。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年11月16日

Google Docs は進歩しているか？ — ワープロ文書の場合

先日、Google Docsを1年振りに触ってみましたところ、1年前はワープロ文書と表計算だけでしたが、今は、プレゼンテーションも作成できるようになっていたこととお話しました。この点では、進歩しているといえるのですが、その後、たまたまワープロ文書を少し触ってみました。どうも、ワープロ文書は全然進歩していないような印象を受けます。それどころか、以前よりも悪くなっているのではないかという印象すら受けます。

例えば、ワープロ文書をひとつPDFにしてみました。
まず、文書をパブリッシュしてみました。
http://docs.google.com/Doc?id=dxspw42_184d7zj8c

この文書をPDFに保存したものがこれです。
○アドビ・リーダの画面

○PDFファイル
ファイルをダウンロード

このPDFをご覧いただきますと分かりますが、日本語の文字の配置がかなり異常になっています。

PDFのプロパティを見ますと、PDFの生成はOpenOffice.orgを使っていますし、日本語フォントは依然として東風明朝です。

※ご参考
2006年10月17日　Google Docs/Spreadsheetsを初体験(4) — Kochi-Minchoで、東風明朝の問題を指摘しました。

ざっとみまして、ワープロ文書については、この1年間でほとんど進歩していないような印象を受けます。

ワープロ文書の編集メニューは、昨年とまったく変わっていないようです。次の画面は、昨年のブログで紹介した文書を、もう一度、ローカルPCからアップロードしたものです。

この画面を昨年のブログの画面と比較しますと、全く変わっていません。
2006年10月16日　Google Docs/Spreadsheetsを初体験(3)

この文書を、PDF保存してみました。このPDFの文字が画面上とずれている度合いも、昨年と全く同じです。
ファイルをダウンロード

従って、ワープロ文書編集、PDF出力に関する部分については、昨年からほとんど変わっていない、と言えそうです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年11月09日

ソフトウェアのビジネスモデル（３）

先日、といっても、もう半月ほど前ですが、猪瀬直樹の「眼からウロコ」 というシリーズで、

「タダは国を滅ぼす〜高速道路も年金もタダにできるわけない (2007/10/23)」

という記事が出ていました。

何でもタダが良いという風潮が蔓延している例を挙げた上で、
・高速道路も年金もタダでできるはずがない。
・受益者負担を明確にすべき
・タダは人を腐敗させる

というかなり過激な論説でした。まさしくそのとおりと喝采を送りたかったのですが、ついでに、「ソフトウェア」をタダにするのも一緒に批判して欲しい、と痛切に感じました。

品質の高いソフトウェアを開発する、というのは決して小さなコストで済むものではありません。ソフトウェアを開発する技術者の人件費だけではなく、テスト担当者、ドキュメント制作担当者、サポート担当者などのコストを含めますと、小さなソフトウェアであってもかなり大きなコストがかかるのは絶対的な事実です。まさしく、「タダでできるはずがない」のです。

それをビジネスとして成立させるには、使用者からライセンス・フィーを頂くのが一番直接的ですが、そうでなくて、それを利用して広告収入を得たり、あるいはコンテンツとセットで販売するなどの様々な工夫を凝らす、新しい方法を模索する努力は必要だろうと思います。

しかし、タダが当然という考え方、あるいは、国の税金を使ってそのコストを埋め合わせることには、どうしても賛成できません。

汗を流して一生懸命働き、そうして得た対価によって、自分の欲しいものを自分できちんと代金を払って購入する、という意識を国民全体がもつことが必要なのではないでしょうか。

猪瀬さん、もう少し頑張って！と言いたいところでした。

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年11月07日

ソフトウェアのビジネス・モデル （続き）

前回、2007年11月02日　ソフトウェアのビジネス・モデルでは、

・ASP/SaaSが、新しいビジネスモデルとして、今後増えていくのは間違いのないところ、ということまでをお話しました。

もう一つの新しいビジネスモデルとして広告収入モデルがあります。広告収入モデルの最大の成功例は、Yahooであり、あるいはGoogleです。Yahooの場合は、インターネットを広告媒体としたことにありますが、Googleは検索結果と表示される広告をマッチさせるという新しい方式を実現して、ロングテール型の広告主を開拓したことで、検索エンジンに大きな広告媒体価値をつけたという点が画期的だと思います。

検索エンジンというソフトウェアと、無料で収集したインターネットのコンテンツを使って広告事業を行っているのがGoogleの現在のビジネスモデルだといえます。

ここまでは良いとして。では、同じ広告収入モデルが、検索エンジン以外のソフトウェアでも実現できるかどうか？ここが分からないところです。

そんなことを思いながら、丁度1年前に使って、そのままになっていた、Google Docsをまた試してみました。1年前（2006年10月14日～10月17日）に、アカウントを作成して、少しいじってそのままですが、1年ぶりのURLは、そのまま有効で、アカウントもそのまま有効です。

http://docs.google.com/
左上のロゴの脇に、小さく、「BETA」と書いてあります。まだ、正式サービスになっていないということなのでしょう。1年前と比べて、大きな違いは、「プレゼンテーション」が追加になったことです。

早速、サンプルとして、9月7日のX-over Dev Conで使用したパワーポイント・ファイルをアップしてみました。プレゼンテーション・ファイルは10MBまでアップロードできます。この位使えると実用的だと思います。

レイアウトが少し崩れますが、34ページのスライドを無事アップすることができます。

ファイルを「パブリッシュ」する機能を使って、下記に公開してみました。
http://docs.google.com/Doc?id=dxspw42_45fpbp2q
この公開ファイルをご覧になるには、Google Docsのアカウントが必要と思いますが、アカウントをもっていれば、プレゼンテーションファイルをご覧頂くことができるはずです。
アカウントがあり、ログインするようにセットされているとEditorの画面になってしまいますが、アカウントがなくても表示されます。

実際に使ってみますと、操作性はまだデスクトップのパワーポイントには及びません。しかし、操作性や機能が向上するのは時間の問題のように思います。

となりますと、やはり課題はビジネス・モデルということ・・

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年11月06日

Page Rank について

Page Rank という言葉をご存知でしょうか？

Webの検索エンジンについて詳しい人は、研究済みかと思いますが、これはGoogleが使っている（商標です）ものですが、０から10までの数値で、そのWebページの重要さを表します。Googleツールバーをインストールすることで、Webページを見るごとにそのページのランクをチェックすることができます。

ちなみに、アンテナハウス(日本語)のWebページのPage Rank は6となっています。

ページランクの概念については、例えば、ここに簡単に説明されています。
ページランク - Wikipedia

GoogleのPage Rankについて、いままで、Webページをあるキーワードで検索すると、その結果は、ページランクの高い方が順位が上に表示されると思っていましたが、どうもそう簡単ではないようです。

ちなみに、ここに「PDF」で検索したときの検索結果の中で、PDFファイルがヒットしたものを除いて、上位から15のWebページの表示順位とPageRankを示しました。

PDF千夜一夜のPageRankは、「5」となっています。

上位から7つのページのPage Rankの平均値は5.33、9番目から16番目のページのPage Rankの平均値は4.63ですので、一応、上位のページのページランクの方が高くなっていますが、完全にリニアな関係でもないようです。

PageRankが高くなると、検索結果で上位に表示されるのは確かだと思いますが、そうしてみますと、PageRankというのは検索結果の表示順位にどのように加味されているのでしょうか？

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年11月02日

ソフトウェアのビジネス・モデル

1980年代のパソコン・ソフトのビジネスモデルは、デスクトップ・ライセンス販売、フリーソフト、シェアウエアというモデルで、非常に簡単だったかと思います。

その後、サーバライセンス/サーバライセンス＋クライアント・アクセスライセンスが普及しました。また、オープンソース・ライセンスが増えてだんだんと複雑になってきました。

2000年代の新しいライセンスとしては、ASP（最近はSaaSという事が多いようです）モデルが脚光を浴びています。

ASP/SaaSは、特に新しいビジネスモデルではなく、1970年代にはデータ通信サービスとしてサービスが提供されていたと思います。もう、遥か昔のことのように思いますが、私も、DEMOSという電電公社のデータ通信サービスを使って、紙テープで統計計算を行ったことを思い出します。

近年、ASP/SaaSが有力なサービス形態となっているのは、ネットワーク・インフラが強力になってきたことが大きな理由と思います。

有力なソフトウェアの機能が、ASP/SaaSとして提供されるようになれば、ユーザの方はソフトウェアの使用料やシステム構築費用を低減できますので、大きなメリットがあります。従って、経済合理性から単純に判断して、ASP/SaaS型のビジネスが徐々に増えていくのは間違いがなさそうに思います。

さて、そうなりますと、ソフトウェアのエンドユーザ・ライセンス契約（EULA）の契約数を増やそうというビジネスはその影響を受けて減少することになるだろうと予想されます。

そんな訳で、アンテナハウスは、システム製品について2007年の新規のEULAから「ASP/SaaSに使用する場合は別契約で」、とお願いをしています。

■システム製品のご利用につきまして

日本のパッケージソフトのライセンス販売している会社の間には、ASP/SaaSを別料金にする会社はまだまだ少数のように思いますが、しかし、長期的には別料金化は避けられないのではないかと思っています。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年10月28日

ソフトウェアに国境はない（？）

最近、あるソフトウェアハウスのWebページを読んでいましたら「使いにくくて高い外国のソフトウェア製品を無理して使うよりも、使いやすい日本産のソフトウェア製品を使いましょう！」という表現がでてきました。

この手の「日本製ソフトを使いましょう」というプロパガンダを時々見かけますが、あまり感心しません。

ソフトウエア開発、関連サービスの提供という意味合いであれば、当然、身近でサービスを提供している会社の方が、外国を拠点でサービスを提供する会社よりは、きめ細かくて、お客さんの期待に沿うサービスを提供できることが期待できます。しかし、ソフトウェア開発とても、オフショアに依頼する傾向になっている時代です。

ソフトウェアそのものもどんどん進化しています。

例えば、私は、Office2007のベータ版を使ってみたとき、Office2003でいつも使っている、使いたいメニューを、Office2007で、どうしても探しだせず、とてもOffice2007は使えないと思ったのですが、ある人と話をしていましたら、Office2007を使い慣れると、今度は、Office2003がとても使いにくく感じるとのことです。

このように、使いやすいかどうかは、慣れの問題ということも大きいでしょうし、外国製ソフトが使いにくく、日本製ソフトは使いやすいというステレオタイプな区分が当てはまるものではないと思います。

むしろ、私などは、ソフトウェアには国境はない、と言いたいのです。その方が、少なくともこのインターネット時代の現実世界をよく現しているように思います。

とはいうものの、今日は、OpenOffice.orgで作った日本語文書を見て、ぎょっとしました。

１．これは、OpenOffice.orgで作成した、和文と欧文の混在した文字列です。

２．こちらは、同じ文字列をXSL Formatterで組版したものです。

いづれも、和文は、MSゴシック、欧文はArialフォントを使用しています。OpenOffice.orgでは、欧文フォントのベースラインと和文フォントのベースラインの位置の調整がうまくできていないようで、欧文が上にずれ過ぎています。

これを見ますと、OpenOffice.orgの日本語組版は極めて品質が低いことがわかります。うーん、組版に関わる限り、「ソフトウェアに国境はない」と言いきれるかどうか、疑問を感じてしまいます。少なくとも、OpenOffice.orgの開発者が日本語組版をあまり研究していない、ということはわかります。

投稿者 koba : 08:00 | コメント (3) | トラックバック

2007年09月21日

中国流　ドメイン登録販売促進術

こんなメールが届きました。当社ではUSのWebサイトのドメイン名　antennahouse.com を使っているのですが、そのインターネット･キーワード（antennahouse）と、antennahouse.cnなどについて、 "Hroom(USA)Venture Capital Co.,Ltd" から登録申請が来ているが、どうするのか？という話のようです。

-------------
From: ***** **** [mailto:*****.****@govidc.org.cn]
Sent: Monday, September 17, 2007 4:42 AM
To: info
Subject: antennahouse domain names dispute in china
---------

Dear manager :
We are Shanghai cn domain Network Information&Technology Co.,Ltd,which is the domain name register center in China.I have something need to confirm with you.
We have received an application formally,one company named "Hroom(USA)Venture Capital Co.,Ltd" applies for the domain names(www.antennahouse.cc, www.antennahouse.cn, www.antennahouse.com.cn,www.antennahouse.hk, www.antennahouse.info,and etc.), and the Internet keyword(antennahouse) on the internet Sep 17 2007. We need to know the opinion of your company because the domain names and keyword may relate to the usufruct of brand name on internet. We would like to get the affirmation of your company,please contactus by
telephone or email as soon as possible.

Best regards,
***** ****
Register Department
Shanghai IDC Network IT Co.,Ltd
Tel: 0086-21-51750338-0326
FAX: 0086-21-51750301
Website: www.govidc.org.cn,
E-mail: *****.****@govidc.org.cn
------------------------------------------------------------------------------

***** ****が実在の人物かどうかしりませんが、メールで聞いてみましたところ、antennahouse.XXX については当社が優先権をもっているので、15日以内に当社から登録申請があれば、当社の登録を優先するが、そうでなければ、申請された登録を受け付けて有効にするということでした。

さあ、これについて皆さんなら、どうしますか？

以下に、当社の担当者に調べてもらったことをご紹介します。

１．インターネットキーワードについて
(1)世界的な話
http://e-words.jp/w/E382A4E383B3E382BFE383BCE3838DE38383E38388E382ADE383BCE383AFE383BCE38389.html

しかし、USでは、インターネットキーワードは、ビジネスとしては、2002年に破綻したようです。
http://www.watch.impress.co.jp/internet/www/article/2002/0514/realn.htm

(2)中国
中国では、インターネットキーワードはまだビジネスになっているようです。
http://domainname.jp/report/keyword.html

■インターネットキーワードに関するレジストラからの連絡について
http://domainname.jp/report/keyword.html

ということがあります。

こういうのを見ますと、やはり、上の通知は、詐欺まがいと考えられます。

antennnahouse.XXXを、中国で登録したい人が本当にいるとはちょっと考えられません。登録をすれば、その維持費用だけでも結構お金が掛かります。ですので、本当に必要なければ、登録するだけ無駄でしょう。

仮に、インターネットキーワードantennahouseをHroom(USA)Venture Capital Co.,Ltdが登録して、なにかそれに見合った収入が得られるか、と言いますと、恐らく得られないでしょう。ですので、長い眼で見れば、仮に登録しても、Hroom(USA)Venture Capital Co.,Ltdは、なんの見返りも得られず、そのうちギブアップするのではないでしょうか。

と言うわけで、皆さんのところに同じメールが届いたときのために、頭の片隅での参考にしていただければ幸いです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年09月18日

USBトークン

昨日は、USBトークンを買おうと思って、ヨドバシカメラにいきました。ざっとみて回っても見当たらないので、お店の人に尋ねてみましたが、要領を得ません。どうも、USBトークンとは何か知らないようです。

USBトークンというのは、USBキーと似ていますが、メモリに公開鍵暗号の秘密鍵を保持しているものです。ICカードを内蔵しているものと、していないものがあるようです。

そんなことを、店員さんに説明して、お店で取り扱っているかどうか聞いてみました。Webで製品型番をしらべて、検索してもらいましたが、どうもヨドバシでは取り扱っていないようです。

で、その後、ビッグカメラにも行きまして、聞いてみました。やはり、店員さんも知らないようで、検索して調べて頂きましたが、取り扱っていないとのこと。

USBメモリは、お店の店頭には腐るほど商品が並んでいるのですが、USBトークンはお店に聞いても取り扱っていない、という一事を見ても、電子証明書の個人レベルでの普及度は、まだまだ、ということが分かります。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年09月01日

クセロReader ZEROの広告掲載モデルについて

クセロ Reader ZEROのダウンロードが始まって、もうそろそろ1ヶ月経ちます。

Vectorのダウンロードページにユーザの声が6人ほど掲載されています。
http://www.vector.co.jp/soft/cmt/winnt/writing/se435636.html

このコメントを見ていますと、広告への批判が多いですね。コメントした6人中4人が広告への批判です。これだけ、広告に対する批判が多いと、広告媒体としての価値を見出すのは難しいのではないでしょうか。

そうなるとどこに収入源を見出すのでしょうか？
長期的に見てビジネスとして成立するのでしょうか？

このあたりは大きな課題でしょう。

ところで、この製品の表示機能、とりわけ速度に対する評価は素晴らしく高いですが、皆さん、このソフトの実体がFoxitであることに気がついていないようです。クセロ Reader ZEROというのはFoxitの上に一枚の皮をかぶせたものです。

Aboutダイヤログをみれば、「Powered by Foxit PDF SDK」とありますし、インストールされているプログラムのプロパティをみれば次のようにFoxit社のものであることは簡単に分かります。

その点では、JAVAも、様々なOSの機能に皮をかぶせたようなものなので、JAVAと同じくらい価値があるとも言えなくはありませんが。そういえば、Googleもインターネットの皮のようなもんだ。ポータルだって皮だものね。

皮が一番おいしい？

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年08月18日

広告配信モデルの無償ソフトの将来は？

最近、広告収入を当て込んで、無償でソフトを配布する動きが幾つか見られるようになっています。

第1は、キングソフトの「Kingsoft Internet Security free」　7月19日から無償でのダウンロードを開始しています。セキュリティ業界初の触れ込みですが、キングソフトが現在販売している有料のプログラムと全く同じ品質でありながら、ユーザーにかかるコストは0という業界初の広告モデルとされています。セキュリティソフトの場合、ウイルスのパターンデータを更新するのですが、その更新のタイミングで広告を配信する、とのことで、オーバチュアやアフィリエイト広告パートナーと提携して、広告収入を当て込んでいます。

広告収入を増やすには、ダウンロード数が増えて、広告媒体価値が高くなることが、前提条件になります。無償ダウンロードを初めて約1ヶ月ですが、どの位のダウンロードがあったのでしょうか？

その第2は、クセロが最近配布を始めた「クセロReaderZERO」。これは、PDFのビューア・ソフトですが、1週間ほど前から無償ダウンロードで配布を始めました。触れ込みでは、年間200万ダウンロードを目指すとか。

クセロ社のニュース・リリース自体には、広告を収入源とするとは一言も書いてありません。ネット上のニュースを見ても、無償配布のことしか書いてありません。しかし、日経産業新聞の8月16日の記事によりますと、「ファイルの起動時に別画面で広告を表示。広告収入を得ることで利用者への無償提供を可能にした。年間3億円の売上を目指す。」とあります。

日経産業新聞の記事には次のような図までついています。ということはクセロの森社長が、日経の記者だけに計画を話したのでしょうか？

しかし、クセロのWebページを見ても、掲載を期待する広告主や製品は何かなど何も出ていません。（本当に広告ビジネス・モデルを考えているのでしょうかねえ。）

いづれにせよ、パッケージソフト・ビジネスを広告配信収入で維持できるものなのかどうか？この二つのビジネスの今後の展開がどうなるか。まずは、興味深々といったところです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年07月08日

PDF 戦線異常あり？

ソースネクストは、2007年6月に「いきなりPDF Professional3」を発売しました。

Webページはこちら。
http://www.sourcenext.com/titles/use/80130/

これは、次のような機能をもつPDF作成ソフトです。
・一括PDF作成（出力）
・ドラッグ＆ドロップPDFページ編集
・PDF編集（PDF注釈作成、リンク作成）
・PDF結合・分割

価格は2,970円です。
この製品の開発元は弊社です。

現在、ソースネクストの「いきなりPDFシリーズ」のWebページを見ますと、ラインアップがかなり整理されて、「いきなりPDF2」(1,980円）が消えています。また、「いきなりPDFtoData2」（1,980円)も消えています。

http://www.sourcenext.com/titles/pdf/

一時は10製品以上あったと記憶していますが、2007年7月7日現在では、6製品に整理され、「いきなりPDF」シリーズで、1,980円のものは、「いきなりPDF from スキャナ2」のみですね。

「いきなりPDF2」は、アマゾンでもVectorでも取り扱い終了したようです。1,980円の「いきなりPDF」シリーズは、市場から姿を消しつつあるということなんでしょうか。1,980円は安すぎて儲からないと判断したのかどうか？関心がもたれるところです。

でも、すくなくともビジネスの世界では、1,980円という価格は必ずしもユーザの求める価格ではないと思いますし、長い眼で見れば、ある程度高い価格で利益を確保していかないと新しい製品を生み出す力を維持できないですので、私的には歓迎です。

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年06月03日

XPS vs PDF　10年後はどうなる？

昨日、10年後に電子文書の世界がどうなるか、について雑談をしたのですが、以下は、その時話したことのメモです。

現在の時点で、電子文書といえばPDFということになります。

PDFが米国で生まれたのは1993年です。まだ、10数年しか経過していません。日本語版は1997年のAcrobatバージョン3からですので、日本語版は今年で10周年ということになります。

今年は、PDFの強力なライバルとして、マイクロソフトのXPSが登場しました。既に、XPS出力をサポートし始めているサードパーティ製品も登場していますし、遅かれ早かれ、我々もXPS出力をサポートすることになるでしょう。従って、電子文書の今後10年を予測するのは、XSPの将来を占う、ということとほとんど同義になるように思います。

それについて思い出しますのは、ネットスケープの盛衰です。

もう、なくなってしまいましたが、1980年代から1990年代にかけて、アメリカのコンピュータ関係の最大の展示会といえば、ラスベガスで開催された秋のCOMDEXでした。COMDEXに初めてInternetExplorerが登場したのは、多分、1995年ではないかと思います。その時、COMDEXには、インターネット関連の製品が雨後の竹の子のように現れて、沢山のブースで展示されていました。

そのブースの展示を見て回って驚いたことに、マイクロソフト以外のほとんどすべてのブースでは、インターネット製品のデモにネットスケープ・ナビゲータを使っていました。インターネット・エクスプローラを使っていたのはマイクロソフトのみ。ですので、マイクロソフトは「99対１」で負けていたという印象が強く残っています。

それから10年経過した、現在の状態は、皆さんがよくご承知の通りです。最近は、FireFoxが少し頑張ってシェアを取っていますが、インターネット・バンキングなんてIEしか対応していないものもあります。

そこで、PDFとXPSを対抗技術とみますと、現在、当時と同じようにマイクロソフトは「99対１」で負ている、と言って良いでしょう。では、10年後にPDF対XPSは、「10対90」になるのでしょうか。

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年04月26日

1億台のコンピュータ計画、進捗状況(2)

2007年04月23日　1億台のコンピュータ計画、進捗状況(1)の続きです。

・100ドル・ラップトップで、最も革新的な点は、ディスプレイだろう。このディスプレイは、グレースケールとカラーの２つの機能をもっており、切り替え可能。グレースケールの場合、1200×900ピクセルの解像度で、安価な時計や電卓などと同じ液晶方式。カラーの場合は、バックライトに白色のLEDパネルを使ってており、800×600ピクセルの解像度をもつ。この時、1200×900ピクセルの白黒液晶も同時にイメージを表示するので、解像度は1200×900ピクセルに近い印象を受ける。

このような、２つのモードをもつディスプレイは商用のラップトップでは初めてだそうな。

・また、ネットワークも革新的。IEEE 802.11sという、今年に最終版になる見込みのメッシュ・ネットワークの標準を、ドラフト仕様の段階で採用した。ディスプレイの上にウサギの耳のように突き出したＷｉ-Ｆｉアンテナを使って電波の受発信をする。ノードからノードの距離が600メートル離れていても接続が可能。

・OSは、ＲedHatのＦedra ＣoreをベースにしたＬinuxを採用。GUIの操作環境は、現在の主流であるデスクトップメタファではなく、新しいＳugarという操作環境を開発した。

Ｓugarの絵

ラップトップの全体説明図

問題は、このようなラップトップ・コンピュータは、数千万台のオーダーで未開発な国に提供されたときにどういう社会・経済的な現象が起きるかどいうことでしょう。

レポートの最後の方では、様々な人のコメントが紹介されていますが、明るい展望を述べている人が少ないように思います。

いづれにせよ、近いうちに実際の配布が始まるということで、これは注目しておく必要があるように思います。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年04月23日

1億台のコンピュータ計画、進捗状況(1)

日曜日ということで、Webでいろいろブログを読んでましたら、2005年にスイス・ダボスでの世界経済会議で、ネグロポンテ先生が提唱した、「子供１人に１台のラップトップを」（One Laptop Per Child：OLPC）計画の詳しいレポートに行き当たりました。

The Laptop Crusade （IEEE Spoectrum Online 4月号)

1年以内に、アルゼンチン、ブラジル、リビア、ナイジェリア、パキスタン、ルワンダ、ウルグアイの、電気のない地方の村の子供達に1,000万台のPCが配布されるだろうとのことです。以前、ニュースでこのプロジェクトの提案を読んだときは、途方もない計画！と思いましたが、だいぶ進んでいるようです。

IEEE Spectrumと言えば、信頼度の高い技術雑誌ですので、いい加減な情報ではないと思います。かなりの長文のレポートですが、どんなことが書かれているか、さわりだけをピックアップして紹介してみたいと思います。

・この計画は、100ドル・ラップトップ計画とも言われるが、世界中に20はある低コストのラップトップ開発計画の中でもっとも大規模で、もっとも資金的な裏付けのあるものだ。

・ネグロポンテ先生は、2005年に計画を提唱してから積極的に動いて、世界中の著名人やメディアにPRした。2006年にMITから独立してOne Laptop Per Childという非営利団体になり、同年6月に実際に動くプロトタイプを示した。

・政治的・教育的な課題 — OLPCは、世界の7カ国から、2008年初頭までに出荷する500万台以上の注文を得ている。しかし、これは、教育予算を使って、学校のために本を買う代わりにラップトップを買うことになるので、困惑している人も多い。買ったとしても政府の崩壊で、学校にコンピュータが届かない可能性もある。学校に届いたとしても、教師が使い方を知らない間に、子供が使い方を覚えて、授業の間にチャットをするのに使ってしまうかもしれない。

・技術的には驚異的 — ラップトップは、ゲーム・コンソール、家庭内の劇場、電子ブックとして使われるため、ディスプレイは自在に回転させる必要がある。そこで、CPUはディスプレイの背面に配置されて、キーボードとの配線が単純になっている。壊れないようにするため2ミリ厚のプラスティックの殻をもち、埃や液体から守るためキーボードはゴムで覆われている。

・ハードディスク、冷却ファン、モニタの背面蛍光がない。アプリケーションとドキュメントは130MBで、512MBのフラッシュ・メモリに保存されている。

・電源は、車の電池から取ることもできるし、リチウム・イオン電池に手回しのクランクで充電する。しかし、子供達の手では、充分な充電は難しそうだ。そこで、1月には、Squid Labが、糸で引く発電器のプロトタイプを作った。これはYO-YO A GO-GOと呼ばれる。

イメージはこちら

・通常のPCは、30Wの電力を使うこともあるが、100ドル・ラップトップのプロトタイプは3Wで動く。CPUは、AMDのGoeoge GX 500@1.0Wという32ビットCPUである。1万個以上のロットで20ドル/個以上する。

・もっとも驚きなのは、砂漠の太陽の下から、室内で文字を読めるようにするための超低消費電力ディスプレイである。台湾のChi Mei Optelectronicsと協力して作った。（続く）

One Laptop Per ChildのWebページ

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年04月17日

失敗した技術についての投票

コンピュータワールド（英文）が、「宣伝文句を信じるな、最大の技術的しくじり」という記事を書いて、読者投票をやっています。

原文：Don't Believe the Hype: The 21 Biggest Technology Flops

候補として上がっているは次の21項目ですが、知らないものも多いです。

Apple Lisa
Apple Newton
Digital audia tape
DIVX
Dot-bombs
Dreamcast
E-books
IBM PCjr.
Internet currency
Iridium
Microsoft Bob
The Net PC
NeXT
OS/2
The paperless office
Push technology
QUBE
Smart appliances
Speech recognition
Virtual reality
Web TV

この記事は、4月4日に掲載されたもので、既に、29886件の投票があり、NO1.はMicrosoft Bobが16%です。

Microsoft Bobってご存知の方いますか？私はMicrosoft Bob って技術があったこと自体、まったく知りませんでしたが、Windows 3.1の上の漫画チックなGUIのようです。

まだ、現在進行形の項目もいろいろあるようですが、paperless officeは、PDFが日本よりも遥かに普及しているアメリカでさえ、しくじりの典型（候補）なんでしょうか？

「書けまっせPDF」でpaperless officeを目指す私としては、ちょっと困ります。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年02月28日

低価格ソフトへの疑問

昨年10月20日に1,980円の「リッチテキストPDF2 D&D」をダウンロードで発売し、4ヶ月を経過しました。その後、11月下旬にパッケージ版を発売して3ヶ月が経過しました。

そこで、そろそろ、こうした低価格ソフトの販売について、一回、総括しなければならないと思い見直しています。

低価格ソフトは確かに本数的には、そこそこ出てはいますが、やはり本当に、お客さんと私達ソフトウェア・メーカの両方にとってハッピーなものなのかどうか、ということを考えますと、やはり違うのではないかと考えざるを得ない状況です。

ソフトウェアは、ハードウェアと違って、コピーが無償でできます。従って、製造コストは非常に安いですから、安くしようと思えば幾らでも安くできることになります。

ハードウエアの場合は、無償というのは普通の方法では実現できませんので、ダンピングを別にすれば、おのずと、最低価格があると思いますが、ソフトウェアの場合は、最低価格は無償ということがありうるわけです。で、実際に製品を無償で提供している会社もあります。

そういう中で、適正価格をうまく決めるのは非常に難しいものがあります。

適正価格とは、一言で言いますと、お客様も我々も両方がハッピーだと感じる価格ということになると思います。製品を購入していただいて、大部分の方が「ああ、こういうことがこの位の値段でできるのならば、買って良かった！」ということで満足していただき、我々もある程度の利益を得て、社員も幸せになり、次のより良いものを作る活動を継続できる、という価格が適正価格ということです。

そういう面から考えますと、どうも、税込み1,980円というのは現在のソフトウエア製品の価格としては、安すぎるということを感じます。まあ、それは、発売する前にシミュレーションしてみれば分かるじゃないか、と。確かにその通りなんですが、その辺りがいまひとつ、自分の力を正しく認識できてない、浅ましいというか、いろいろと欲目があって、事前にはうまく予測できないものなのですね。

でやってみると、実際、現実を認識してやはり、そうか、となる次第で。修行が足りなんでしょうね。きっと。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年02月11日

北京でのソフト開発１０年を振り返って　(2)中国での販売のこと

アンテナハウスの北京の子会社北京紅櫻楓軟件有限公司（HYF）では、アンテナハウスの製品の中国での販売、また中国独自製品の中国市場での販売も行っています。

中国国内販売は、最初、あまり成果が上がらなかったのですが、昨年は、ようやく中国国内売上がHYFの総売上の35%になりました。

特にPDF関係がやはり中国でも売上が伸びています。

また、XMLについても、一部の大手企業での導入は進んでいます。XSL Formatterは中国の大きな保険会社の外交員向けのシステムに組み込まれており、数万台の端末で使われています。中国の大企業には、米国帰りのIT責任者が在籍している場合があり、そういう場合は、日本よりもむしろ進んでいるケースもあるのです。

中国では汎用のパッケージソフトはほとんど売れません。10年前から比べると表向きはともかく、実態はまだ不正コピーが氾濫しているようです。ユーザ側では、無料で使える方法があるのにお金を払う必要がないという意識があるようで、そういう世界ではパッケージソフトはまったく売れないでしょう。中国市場で、パッケージソフトを売ろうとしたら絶対に違法コピーできないような仕組みが必要だろうと思います。

結局のところ、各企業ユーザ向けに個別カスタマイズ版を提供していくという方法を取ることになります。大きな案件がとれれば良いのですが、ひとつひとつの案件が小さいと、これはあまり生産性の高い方法ではないように思います。

あとは、日本と同じようにソリューションを開発するという方法でしょうか？但し、HYFでは、現状、ソリューションの開発はわずかですので、この方法でうまくいくかどうかは分かりません。

また中国製の携帯電話上で使える文書ビューアを開発して、中国の携帯電話メーカにライセンスを提供しています。携帯電話用のソフトであれば不正コピーはないだろうと考えていたのですが、甘かったようです。今度は、携帯電話メーカからなかなかライセンス料金を支払ってもらえません。販売本数分のライセンスを払うという契約を結んで、売れたという報告をもらっても、なかなかお金を払ってもらえません。ある大きな携帯電話メーカ向けの契約では、1年近い交渉で漸く、お金を払ってもらいました。他に1年経ってもまだ代金を払っていない会社もあります。これは、契約を元に粘り強く、取れるまで諦めずに交渉するしかないと思いますが、それにしても骨が折れます。

このように、お金が回り難い状態だと、なかなか企業が成長できないのではないかと思いますが、他の中国企業や日系企業はどうしているのでしょうか？他の会社のホンネを知りたいものです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年02月10日

北京でのソフト開発１０年を振り返って　(1)通貨のこと

２月７日に北京空港について、まず、通貨交換の窓口で、円から元に少し転換しました。このレートは１万円が621元で、1元が16円となります。

10年前は、確か、670元程度だったように記憶しています。つまり、10年間でせいぜい元が1割高くなったの程度ではないかと思います。

このように通貨の交換レートが10年も同じようなレベルで固定しているのは、中国の経済力の変化とはかなりかけ離れているように思います。つまり、中国の経済が大きく成長して、国際的な収支も大幅な黒字になっているにも関わらず、元が高くなっていないのです。これは中国が、元とドルのレートをまだ自由化していないためで、現状では、中国元はかなり不自然に安く設定されていると感じます。

中国のソフトウエア産業の2005年の輸出額は約36億ドルで、60%が日本向けだそうです。2004年と比べて45%の増加だそうです。

また、北京の市内を走ってみるだけでも、10年前と比べて、沢山のビルやマンションと思われる新しい建物が建設されています。北京は来年のオリンピックに向けて、様々な施設が、非常に活発に建設されています。

こうした活発な経済活動には、安く設定され、自由に交換できない元に支えられている部分があるのではないでしょうか？

中国に進出した日本の子会社では、いま、現地の日本人社員の給与を本社で負担していることが問題になっているとのことです。つまり、現地に出向している日本人社員の給与を、日本の親会社が負担しているところが多いのです。しかし、中国の子会社が力をつけて、利益を出し始めるにつれ、現地法人が日本人社員の給与を負担すべきではないか、と考えられ始めているのだそうです。

しかし、日本人社員に元で給与を支払っても、その給与を日本円にして持ち帰ることができません。一方、利益を出している子会社の社員の給与を、親会社が負担するのは、やはりおかしいということで、これをどうするかという問題に直面しているというわけです。子供がかなり大きくなったにも関わらず、依然として親が面倒を見ているようなもので、いずれはやり方を変更しなければならないでしょう。

こうした不自然さも、元を外貨と自由に交換できるようにすれば解消します。しかし、そのとき、交換レートが意図的に安く設定されていることのつけが回ってくる危険がありそうです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年02月09日

北京でのソフト開発10年を迎えて

2月7日と8日の2日間北京に行ってきました。アンテナハウスの北京の子会社である北京紅櫻楓軟件有限公司（HYF）の董事会と2007年経営計画発表会と懇親会のためです。

アンテナハウスは、1996年に100%出資の子会社としてHYFを設立、1997年2月から実際の業務を開始しました。月日が経つのは早いもので、この2月で満10年となります。営業開始時は、総経理以下5名でスタートしたのですが、半年後にはその中の3名が退社してしまい、一体どうなることかと前途に不安を感じたものです。当時から、そして今でも入社してから短時間で止めてしまう技術者が多いのですが、これはHYFだけでなく、北京のソフトウェア会社はどこも技術者の流動性の高さに悩んでいるようです。

単に給与の高い会社に移ってしまうだけでなく、優秀な技術者にはカナダやオーストラリアなどに行ってしまう人も多いようです。これは、カナダはIT技術者に対して広く門戸を開放していて、比較的簡単に市民権を取ることができるためで、HYFで働いていた技術者で、カナダへ移住してしまった人も数名は知っています。

この10年を振り返っての最大の困難は、技術者の流動対策にあります。最初の頃は、技術者の流動性の高さに、まるで砂の上に楼閣を作っているのではないかという印象さえも持っていました。こうした中で、総経理を中心に、技術者に愛社精神をもってもらい、長く働いてもらえる会社にしようと、様々な試みを行ってきました。経営計画発表会を始めたのも、会社の実状、経営理念、今後目指す方向を社員に伝え、理解してもらい、一緒にがんばってもらおうということが、その目的の一つです。

こうした努力の甲斐があり、現在は30名を少し超える人数となりました。また、今回の経営計画発表会では、入社10年表彰対象者が数名でましたし、6年以上継続勤務者もだいぶ増えてきました。

10年前のスタート時を振り返りますと、感慨ひとしおです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年01月29日

最近知ったブログなど

■言語工学研究所　国分社長の社長ブログ

http://blog.ruigo.jp/kokublog/

内容：日本語処理のシステムに取り組んでいて思いついたこと
2006年11月開始

国分さんは、もう知る人も少ないかも知れませんが、管理工学研究所で初代の「松」を開発された方です。6x歳でなお現役プログラマ。2x年前、プログラマ35歳定年説というのがあったようですが、そんな説はまったく正しくなかったことを証明する人。もう20年以上、日本語処理システムに取り組んでおられるようですが、最近は特に構文解析の開発が中心のようです。試行錯誤するときや、細かなことは人に頼むのよりは、やはり自分でプログラムを書く方が早いのだそうです。

■長村　玄氏のブログ　「明朝体・考」

http://nagamura.jp/moji/minchou/

内容：日本語の基軸書体である「明朝体」について考える
2006年08月開始

字体・字形について事象に現れる表面的なことでなく、根源から考えようとしているとことが伺えます。いま、社会現象としての文字の連載を連載中です。早く、続きを読みたいものです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年10月17日

Google Docs/Spreadsheetsを初体験(4) — Kochi-Mincho

2006年10月14日 Google Docs/Spreadsheetsを初体験(1)で、Google Docsで作成したPDFで使われているフォントが「Kochi-Mincho」になっていることに気がつきました。Googleのサーバで作成したPDFの日本語フォントには、Kochi-Minchoが埋め込まれています。

私の記憶では、Kochi-Minchoは日本語フォント名「東風フォント」と言い、確か権利侵害の問題で公開停止になっていたものではなかったかな？

その後、この問題はどうなったのでしょうか。少し気になりましたので、Webでざっと調べて、状況を整理しておきます。

■この経緯についての情報リストはここにあります。
StolenBitmap
緊急作成 --- 32 ドットビットマップフォントの無断複製について

これに基づいて、私なりに整理しますと。。
■渡邊フォント(ビットマップ）
まず、32 ドットビットマップフォントの無断複製についてによると、「渡邊フォント」と呼ばれる様々なサイズのビットマップフォントがあった。これは、1990年代初頭に、広く流通していたフリーのビットマップ・フォントを元にJaWaTeX の開発者である(当時)東北大学の渡邊雅俊さんが作成したフォント集。

ところが、2003 年 6 月 15 日に、当該ビットマップ・フォントは、日立とタイプバンクが制作してROMとして販売したフォントが無断で複製配布されていたものであることが判明。

■東風明朝フォント（TrueType版）　Kochi-Mincho
慶応大学の古川泰之さんが、渡邊フォント(ビットマップ）を元にアウトライン化したもの。

東風明朝フォントの製作過程

元になった、ビットマップフォントの問題が発覚したため、2003年10月21日に古川泰之さんは制作活動終了宣言をしています。

東風フォント制作活動終了のおしらせ (2003年10月21日)

■その後
東風フォントその後
東風フォントその後 ７～９
東風フォントその後 １０～１１
東風フォント問題が解決の方向へ無償利用も可能に

などを読みますと、話合いの結果、日立やタイプバンクとライセンス契約を結べば「東風フォント」などの派生フォントを（一定の条件で）開発、配布、利用できることになったようです。しかし、この過程で古川さんは「東風フォント」の開発・配布をやめ、内田明さんという方は、契約を結んで「XANO明朝フォント」を開発することにしたのだそうです。

XANO明朝フォントについて

つまり、開発者である古川さんは「東風フォント」の開発契約を結ばず、終結宣言をしたことから考えて、他の人が東風フォントを配布したり、利用するのは、正当な契約に基づかない行為になるのではないかと思います。契約に基づかない行為、すなわち無断使用が、直ちに不正であるとか、あるいは、損害賠償等の問題に発展するかは私にはわかりません。そういうことを判断する立場でもないですが。

しかし、Googleほどの企業であれば、有償フォントを購入して使えば良いのにね、と思うのは私だけでしょうか？

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年10月16日

Google Docs/Spreadsheetsを初体験(3)

Google Docs、まだ、生まれたての子供といったところですが、従来のワープロと違っているのは、やはりWeb上で使うという点。具体的には、Publish機能、Collaborate機能の二つでしょう。

Publish機能というのは、名前どおり作成した文書をそのままWebで公開する機能です。従来のワープロでも作成した文書をHTMLに変換して、Webに公開することはできましたが、Google Docsは、ボタンひとつで文書の公開ができるということで、従来とは、比べものにならない手軽さで文書の公開ができそうです。

試しにGoogle Docsで作成して、Publishした文書をおきます。
http://docs.google.com/View?docid=dxspw42_39r7cw8s

この文書はMicrosoft Wordで作成したものです。

■元の文書の印刷イメージ

■この文書をGoogle Docsにアップロードしたところ

■Publish

Publishと言いますと、大層な機能と思うかもしれませんが、要するにHTMLに変換してWebサーバの上に置くということです。ただ、こういう機能は、インターネット上で一般に公開するのよりも、社内用のグループウエアの掲示板などの方が用途が多いのではないでしょうか。インターネットにHTMLをパブリッシュできたとしても、それだけではたいして役に立たないように思います。

ちなみに同じ文書をPDFで保存変換しますと次のようになります。

■PDFに変換した結果

HTML変換に比べて、PDF変換では、レイアウトがかなり崩れてしまいます。PDFで保存はもう少し気合を入れて改良しないと使い物になりませんね。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年10月15日

Google Docs/Spreadsheetsを初体験(2)

さて、次にGoogle Docs/Spreadsheetsのもうひとつの核、表計算を体験してみましょう。

新しい表計算のメニューを選択しますと、ブラウザが新たに起動して、空白のシートができます。

メニューはワープロと似ていますが、やはり表計算独自の機能として行や列を挿入したり、削除するメニューがあります。

簡単な表を作ってみました。
■Google Spreadsheetsで作成した表

データの入力は、やはり、通常のデスクトップの表計算よりはレスポンスが悪いようです。また、入力したデータ（記号類)によって、インターネットの接続が切れたようになりデータが消えたりします。まだ、不安定な状態のようです。

ファイルメニューを見てみます。Google Docsとは違って、Exportの先にPDF形式があります。昨日のDocsでは、SaveAsの形式のひとつとしてPDFがありました。DocsとSpreadsheetsでメニューの整合性が取れていません。
■ファイルメニュー

■PDFへのエクスポート・ダイヤログ

PDFで保存してみました。このPDF作成のプロパティを見ますと、今度は、iTextになってますね。

■PDFの作成者プロパティ

OpenOffice.orgには、表計算もありますが、使っていないのはなぜなんでしょうか？
ワープロ文書はOpenOffice.orgでPDFを作成、表計算はiTextで独自にPDF作成機能を作った、というところは、やや荒削りな感じを受けます。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年10月14日

Google Docs/Spreadsheetsを初体験(1)

Googleが、11日にWebで使えるワープロと表計算GoogleDocs&Spreadsheetsを発表しました。そこで、早速、体験してみました。

GoogleDocs&Spreadsheetsのホームページ
■画面

この画面からワープロ文書の作成(New Document)、表計算の作成(New Spreadsheet)ができます。また、自分のローカルのハードディスクから文書を読み込む（Upload)することもできます。

■ローカルの文書を読み込む画面

これを見ますと、HTML、Word文書(Doc）など基本的な文書を読み込めるようです。ただし、500KBが読み込みできる大きさの限界になっていますので、あまり大きな文書は無理なようです。そこで、簡単な文書を読み込んで見ました。そうしますと、日本語の文書も比較的すなおに表示します。しかし、通常のワープロと違って、紙のようなページの概念はないように見えます。次のふたつの画面を比較しますと、そのことが分かります。

■編集用のウインドウ幅を広げた状態

■編集用のウインドウ幅を狭めた状態

ウインドウの幅の広さが変わると文章の改行位置が変わりますね。これはブラウザと同じように可変幅のディスプレイで使いやすくするためではないかと思います。ページレイアウトをWYSIWYGで表現することは意図していないということになります。

日本語の文字も編集ウインドウで直接入力できますが、フォントはどうやって指定するのでしょうか？試しに、日本語の文字列を選んで、フォントのメニューを開いても、次のようにTimesNewRomanという欧文フォントにチェックマークがついています。どうやら日本語フォントを指定するのは無理なのかな？

■日本語文字列を選んでフォントメニューを開く

普通のワープロと同じように、ファイルメニューもあります。
■ファイルメニュー

おお！PDF形式で保存なんてメニューがありますよ！そこで早速、PDFで保存してみました。

■出来上がったPDFのページ

改行位置が画面の表示と少し違います。将来、こういうワープロが普及してくると、改行位置なんてあまり気にしなくなるのでしょうか？そうなると「日本語行組版規則」なんてJISは化石な存在になるのかな？

このPDFのプロパティを見ますと、PDFの作成者は、OpenOffice.orgになってます。PDF出力はサーバサイドでOpenOffice.orgを使っているんでしょうね。

■PDFのプロパティ

■PDFのプロパティ（フォント）

普段使ったことのないフォントをいろいろ使ってますね。
ちなみに、このKochiMinchoという名前のフォントは、私のローカルのPC上のWindowsのFontsフォルダにはありません。従って、このフォントはGoogleのサーバ上にあるフォントということになります。

ワープロ編集画面上では、恐らくローカルのフォントで表示していると思います。そうしますと、必然的にWYSIWYGにはできないことになります。

ともあれ、Google Docsは、言ってみれば生まれたばかりの幼児ですが、将来どうなるか？夢が膨らみますね。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年10月06日

商標登録における顕著性について　続き

昨日、最後に「特許庁の審査基準が首尾一貫してないんじゃないでしょうか？疑問を感じます。」とお話しましたが、ひとつだけ具体例で説明してみたいと思います。

以前、アンテナハウスでは「XMLツールボックス」という製品を出していました。現在は、バージョンが新しくなり、バージョンアップの機会に、名前も「XML Editor」と変えてしまいました。

そんなわけで、過去の話になってしまいましたが、この「XMLツールボックス」の商標登録申請は、顕著性がないとして、拒絶されたひとつの例です。

「XML Tool Box(エックスエムエル・ツールボックス)」と「セキュアPDF」の構成要素を比較すると、
・XMLとPDFでは、どうみてもPDFの方が一般に知られていると思います。
・ツールボックスとセキュアでは、どうかといいますと、やはりセキュアの方が多くの人に使われているのじゃないかと思います。

そうしますと、「セキュアPDF」が商標登録できて、「XMLツールボックス」が商標登録できないというのはやはり納得できません。

「XMLツールボックス」を商標として認めない理由は、次の通りです。
---ここから---
この出願に係わる商標は、コンピュータプログラム言語の1種であるXML言語をタグで生成する補助機能が、頻繁に利用する機能をボタン化して画面に並べたものであるツールボックスに格納されていることの意を認識させる「XML Tool Box」「エックスエムエル・ツールボックス」を2段に並べたものに過ぎず。。中略。。単に商品の品質、機能を表示するにすぎないものと認めます。
---ここまで---

これ、そっくりそのまま、いや、もっと適切に「セキュアPDF」にあてはまると思うのですが。

しかも、「頻繁に利用する機能をボタン化して画面に並べたもの」って、Windowsアプリケーションの標準用語では、「ツールボックス」ではなく、「ツールバー」って言うんですよ。この審査官、「ツールバー」を知らないらしい。

そんなことを主張して反論したところ、「ジャストシステムのソフト（一太郎）では、『ツールボックス』の名称が用いられていますので、認定を覆すことはできません」という返事が来ました。審査官は、どうやら「一太郎」ファンだったようです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年10月05日

PDF製品の商標　｢セキュアPDF」

PDF製品の商標登録を調べていましたところ、次のような商標にぶつかりました。

【登録番号】 第４９２７４７８号
【登録日】 平成１８年（２００６）２月１０日
【商標（検索用）】 セキュアＰＤＦ
【標準文字商標】 セキュアＰＤＦ
【称呼】 セキュアピイデイエフ，ピイデイエフ，セキュア
【権利者】 株式会社リコー
【商品及び役務の区分並びに指定商品又は指定役務】
９ 。。。電子出版物

電子出版物に、「セキュアPDF」という名前をつけるとリコーの商標違反になるのでしょうか？

そもそも、「セキュア」、「PDF」というようなポピュラーな（顕著性のない）名称を組み合わせて、商標に登録できるというのはちょっとおかしいのではないでしょうか。
かなり昔ならいざしらず、登録日が平成18年なのに！

特許庁のホームページには
「どのような商標が登録にならないのか」
というページがあり、そこには、
「商標登録を受けることのできる商標は、次のような商標でなければなりません。」として、「自他商品の識別力又は自他役務の識別力を有する商標であること。」が条件になっています。

そして、次のような説明があります。
---引用ここから---
したがって、次のような商標は、自他商品の識別力又は自他役務の識別力を有しないものとして登録を受けることができません(商標法第３条第１項)。
・商品又は役務の普通名称を普通に用いられる方法で表示する標章のみからなる商標（第１号）
・商品又は役務の普通名称とは、取引業界において、その商品又は役務の一般的名称であると認識されるに至っているものをいいます。例えば、「時計」について「時計」、「靴の修理」について「靴修理」などがこれに該当します。
---引用ここまで---

私の経験でも、申請した商標が、顕著性のない言葉を組み合わせたものとして特許庁に拒絶されたことが、いままで何回かあります。私見では、「セキュア」と「PDF」よりもはるかに特殊な言葉を組み合わせたものでも拒絶されたこともあります。（まあ、これはあくまで私見ですが）。

「セキュア」と「PDF」は、これに該当しないのでしょうか。

特許庁の審査基準が首尾一貫してないんじゃないでしょうか？疑問を感じます。皆さんはどう思いますか？

投稿者 koba : 08:00 | コメント (2) | トラックバック

2006年09月02日

ソフトウェアの国際化について　続き

昨日は、現在では、ソフトウェア製品はワンソース、ワンバイナリで全世界の市場をカバーできるようになっているという話をしました。

これとインターネットが組み合わせれば、技術的には、全世界で同一のソフトウェアを販売することも可能になります。

そうするとソフトウェアの市場は飛躍的に大きくなりますので、今の10倍は売れるようになるのだろうと思います。

で、実際にやってみると、なかなかそうはうまくいかないものなんですね。

当社の場合、XSL　Formatterだけは、海外でかなり売れています。今年は、有名どころの会社だけでも、米国のB航空機製造会社、ドイツのD自動車会社、米国のIコンピュータ・メーカなど、錚々たる会社が大口ユーザになっていることもあり、最近は、海外売上げ比率70%以上になっています。

ところが、他の製品はなかなか売れないんですよ。市場がグローバル化されて広がったからと言って、売上げが増えるわけではないということを身をもって実感してます。

PDF関連ツールに限っていえば、残念ながら、念願の欧米市場参入すらできていません。欧米市場のPDF関連ソフトウェア・メーカ、PDF関係製品の種類も日本の市場とは比較にならないほど多く、競争も厳しいですから、この競争相手と同じ土俵で戦って頭角を現すだけのモノがなければ、製品を出しても、それこそ一顧だにされない、という状態になってしまうのは明らか。

自動車メーカ、OA機器メーカでもできたことなので、ソフトウェア・メーカだってできると思うのですが。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年09月01日

ソフトウエアの国際化について

昨日、英語版のWindowsXPの地域と言語のオプションを日本語としたOSで、英文のMicrosoft Word2003で作成した日本語フォントを含む文書をPDFにするとフォントのハンドリングがうまくできていないソフトウエアがあるということを報告しました。

私は、日本で開発したソフトウェア製品を欧米で売りたいと思っていますので、いつもWindowsは英語版を使うようにしています。日常PCを使って仕事する上では、それでほとんど支障を感じることはありません。

ところが、時々、昨日報告しましたように、日本語のWindowsで日本語のアプリケーションを動かしているのであれば問題ないのに、英語版を日本語用に使ったとき問題が出ることがあります。

それで思い出しますのは、20年前、MS-DOSの時代。昔は英語用に開発したOSやアプリケーションで日本語処理をするということは考えられませんでした。そして、Windows3.1、Windows95の時代では、英語版と日本語版は別のアプリケーションとするのが普通で、欧米のソフトウエア製品を日本語化して、初めて日本語で使うことができました。日本のソフトハウスの仕事のジャンルの一つに欧米のソフトのローカライズという仕事がありました。

ところが、WindowsNT、Windows2000、WindowsXPでは、最初から、全世界で使えるように作ることで、ソフトのローカライズの必要性はなくなっているはずです。

アプリケーションに表示するメニューでさえも、Windowsが英語版として動いているときには英語のメニューを表示し、Windowsが日本語で動いているときには日本語のメニューを表示するように作っておくことで、英語環境では英語版として、日本語環境では日本語版として使えるように作ることができます。

ワンソース、ワンバイナリでソフトウエアの多言語化ができるのです。

例えば、アンテナハウスのXSL Formatterはそのように作って、日本語版と英語版を常に同時リリースしています。（同じものなので当たり前ですが）。

XSL　Formatter日本語版のWebページ

XSL Formatter英語版のWebページ

上の図を比べていただくと日本語版と英語版が同時進行になっていることをご確認いただけると思います。現在は、最初から国際化を考えて設計することで、プログラムに関する限り、ローカライズ作業は必要なくすことができます。

従って、きちんと国際化を考えて作れば、昨日起きたような問題は本来起きないはずなのです。しかし、現実には起きるのですね、それが。で、この問題が起きるのはやはりフォント周りの話が多く、時々、まれにですが、弊社の社内でも私のPCでしか起きないという問題もなくはありません。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年08月30日

ベトナムでのソフト開発

ベトナムでのソフト開発は、中国よりも良いのではないかという噂は時々耳に挟んでいました。

今日、はじめて、実際にベトナムで開発したというパッケージ・ソフトのβ版を眼にし、その開発期間を聞いて、びっくりしました。

そのソフト、デモを少しみただけなのですが、良くできているという第一印象を受けました。

それだけならまあ驚くほどのことはないのですが、驚くべきはその開発期間、おそらく、ゼロから開発すれば、普通の日本の会社なら半年くらいはかかるであろうと思えるものが、なんとβ版まで3ヶ月とのこと。

このソフトを企画した人によると、日本のソフトハウス4社に話を持ちかけたが、すべての会社に3ヶ月でβ版のスケジュールは絶対無理と断られて、最後の頼みの綱としてベトナムの会社に発注したとのことです。

製品化するまでには、日本国内で仕上げが必要とのことですが、しかし、ベトナムの人たちが日本の会社ができないと断るような短納期の仕事を積極的に引き受けて、かつ、単価も日本の1/3から1/4でこなすとなると、日本のソフトハウスでのプログラマの仕事を維持すること、雇用確保するのは相当に大変なことだと、改めて気を引き締めた次第です。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年08月27日

XML技術のハイプ曲線

昨日は、XSL-FOがハイプ曲線のピークにある、ということはないのでは？という話をしました。そこで、もう少し調べてみました。

ガートナー・グループでは、XML技術のハイプ曲線2006年版というのを販売しています。
Hype Cycle for XML Technologies, 2006　11 July 2006には、レポートの目次が出てます。

それをみますと、XSL-FOはSliding Into the Troughの章で紹介されていて、XSL-FOはどうも幻滅の時期（反動期）に分類されているようです。

どうやら、ガートナー・グループではXSL-FOについて2005年が期待のピークで、2006年にはその反動で溝に落ち込んでいるという認識をしているようです。

ジャストシステムの資料に紹介されているのは2005年の図ですので、その中で、いくつかの項目をピックアアップし、2006年の位置づけと比較して、1年でどう変化したかを簡単にプロットしてみました。ガートナー・グループのレポートを買ったわけではありませんので、あくまで推測を交えた図なのですが、次のようになります。

・2006年08月24日に取り上げましたDITAは、2005年のレポートでは登場していませんが、2006年に早くもピークという認識がなされてます。（そうなんでしょうか？）

・XMLデータベース（XML　DB）は、2006年に安定期に入ったということです。

・そうかと思えば、XBRLのように2005年も2006年も同じ反動期に分類されているものもあります。

・今年、出現したOpen Office XMLファイル･フォーマットは黎明期で、これからということ。

こうしてみますと、大雑把にはあたっているといえなくもありません。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年08月20日

FireFox とPDF

FireFoxで、WebページにリンクされたPDFを表示しようとすると、FireFoxが死んでしまうことがあります。どうもどこかで無限ループになるようですが、この現象、なかなか改善されません。

私のWindows2000では起きないのですが、Window XP SP2では、かなりの確率で起きます。

うまく表示して、Adobe Readerを抜けて、元のWebページに戻ることができることもありますが、どういう条件が揃ったとき、Adobe Readerから終了できるかわかりません。

FireFox、AdobeReaderもいくつかアップデートしてもあまり改善されず、Windowsについても、一回、完全に入れ替えたのですが、それでも変わらない。

FireFoxのナレッジベースには次の記述があります。

PDF ファイルを開くとコンピュータがハングアップする

Acrobatの古いバージョンがあるとだめ？
最新版でも起きることがあり、鋭意調査を進めていますとありますが、1年経っても解決しませんね。

ちなみに、環境は次の通りです。
FireFoxのバージョン：　1.5.0.4
Windowsのバージョン：　Windows XP Professional Version 2002 Service Pack 2
Adobe Reader：　Version 7.0.8
Adobe Acrobat： Standard　6.0.0

このAcrobat Standard 6.0.0 が怪しいような気もします。

Acrobatのplug_insフォルダの中の一部のファイルだけを使ってみたらどうかどいうような対処策もブログにあります。しかし、やってみても解決しません。
Firefox PDF Acrobat Reader problem

というわけで、いまだに困っています。PDFにぶつかるたびに、注意してローカルに保存して開くしかないのかな？

投稿者 koba : 08:00 | コメント (2) | トラックバック

2006年08月12日

PDF千夜一夜　300日達成！

1000日連続更新を公約して始めた、このブログですが、今日で、300日連続更新を達成しました！

過去の記事一覧はこちらでご覧いただけます。

PDF千夜一夜　全記事一覧

このブログは、企業ブログとしてマーケティング上の目的をもって始めたものですが、最近は、かなり大勢の方から「読んでいるよ」という声をかけていただき、多少は、アンテナハウスPDFのPRに繋がっているかな、と手ごたえを感じています。

昔から、「石の上にも三年」と言われています。

この言葉を、私は、どんなことでも3年間一生懸命やればなんとかなるという教えと解釈しています。

20数年企業を経営してきた経験からは、また、3年というのはビジネスの成否を判断するときのひとつの区切りにもなると思います。

3年は、ほぼ1000日に相当します。このブログを書いている3年の間で、アンテナハウスPDFをちゃんとしたビジネスにするということです。

既にその3割が経過してしまった訳で、月日が経過する速さは、まさに光陰矢の如しですが、残り700日頑張りぬいて、目標達成を目指したいと思います。

投稿者 koba : 08:00 | コメント (1) | トラックバック

2006年07月23日

Googleのクリック詐欺訴訟　その後

7月22日に　2006年06月03日　企業の経営で一番大事なものはなにか？の記事に、福田　平治氏から「The National Law　Journal」に記事が出ているというコメントを頂きました。

このコメントにリプライしようとしたのですが、コメントを書き込むことができません。コメントスパムの書き込みを無くすために、先日、ブログサーバにいろいろ設定してもらったのですが、どうも、その際に、自分の記事にコメントを登録できなくなってしまったようです。

システム管理者が夏休みのため、戻るまで返事ができません。福田さん　ごめんなさい。　

そこで、本文で少しコメントすることにしました。

福田さんの紹介された記事は、The National Law　Journalの次の記事だろうと思います。

Google 'Click Fraud' Settlement Criticized
http://www.law.com/jsp/article.jsp?id=1153213525657

内容は、大略、次のようなものです。以下、概要：

１．Googleのクリック詐欺訴訟について、40社以上のオンライン広告主が反対の申告をした。

これについての”fairness hearing”が、7月24日に開催される。ちなみにこれは当初の予定通りです。

２．反対派の広告主2社の代理人であるDarren Kaplan氏は、反対派は、この和解をふっとばすために、銃火を交える以外のあらゆることをしている、と述べた。

Kaplan氏によると、広告主に補償されるのは、6000万ドルの基金の10%に相当する600万ドルに過ぎず、これは、前例の無いほどの過小評価である、とのこと。

３．反対派のIrwin B. Levin 氏は、もっと良い和解のための計算方法があるのではないか、と述べている。また、補償方法が現金でなく、広告費のクレジットになっている、ということにも注意している。

４．Kaplan氏と、やはり反対派のBrian Kabateck氏は、YahooとCheckmate Strategic Group社の間で争われている、クリック詐欺に関して、カリフォルニアで行われている別の集団訴訟の和解案を作成したが、そちらの和解案に近くなって欲しいと考えている。

５．一方、今回の原告側の弁護団は、彼らがYahooと今回の訴訟に関して調停している間に、 Kabateck氏らが、Yahooと秘密裏に交渉していると批判している。

（今回の集団訴訟では、Yahooも対象になっていて、Yahooとは和解案ができていない。）

６．Kabateck氏は、今回の原告側の弁護団は、彼が今まであったどんな弁護士よりも暴力的で、今回の集団訴訟の和解案は米国の歴史上最も悪いものの一つだ、と反論している。

概要ここまで。

この記事を読みますと、Googleのクリック詐欺訴訟を巡って、弁護士間で激しいやり取りが行われている様子が良く分かりますね。

投稿者 koba : 09:50 | コメント (2) | トラックバック

2006年06月11日

グーグル・クリック詐欺集団訴訟について　その４

グーグル・クリック詐欺集団訴訟のオプト・アウト(原告団に参加しない)、または、反対意見の提出期限は、6月19日消印まで有効です。

ということで、今日は、オプト・アウトの手紙を作成して書留航空便で投函してきました。自らをオプト・アウトしておかないと、自動的に原告団の一員となってしまい、この訴訟の和解に制約されることになります。そうすると、このブログの意見も消さねばならないかもしれません。そこで、まずはオプト・アウトすることにしました。

手紙の内容は、簡単で、自分の住所氏名を書いて、本文に

Please exclude myself from this class.

と書けば良いと思います。

こうしておけば、少なくとも、将来グーグルに意見を言う権利は確保されるでしょう。

ところで、訴訟に関する説明文書の日本語訳が下記に出ています。

集団訴訟の係争と和解、和解審問および賠償請求手続きに関する通知

これを読んで、私の英語の理解が間違っていたかもしれないと気が付きました。

このところ
原文は
Class counsel intend to seek a maximum of 33 ⅓ percent of the settlement fund, or $30 million, in attorneys’ fees and expenses in this case.

公開されている日本語訳は
原告団弁護士は、和解の決済基金の最大33 1/3%、すなわち3 千万ドルまでの支払いを求めています。

原文のorを、ここではすなわちと訳すのが正しいようです。そうすると、弁護団への報酬は、最大で約33億円ということになります。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年06月03日

企業の経営で一番大事なものはなにか？

先日、2006年05月31日グーグル・クリック詐欺集団訴訟和解案は、モラルを喪失した米国経済界の象徴で、弁護団もグーグルの経営陣もモラルにもとる行為をしている、と書いて、匿名氏から「ちょっと、企業のドメイン下に置くblogとしては感情的すぎるかと。」と批判を浴びてしまいました。

まあ、確かに少し過激発言ではありますが、感情的になっている訳ではありません。

個人的なことになりますが、私は1979年1月に中途採用で日経マグロウヒルという会社に入社しました。

日経マグロウヒル社（現在は、日経BP社になっています）は、当時、日本経済新聞社と米国のマグロウヒルの合弁会社として米国系の外資系企業でした。

入社が決まりまして、最初の上司に言われましたのが、「わが社はオネスト・カンパニーである。お客さんにウソを付かない経営を行っているんだ。」ということでした。その言葉は大変新鮮でいまでも印象に残っています。

それは、どういうことかと言いますと、日経マグロウヒル社は雑誌社ですから雑誌の広告掲載収入が、売上げの過半を占めている訳です。

広告というのは、経済効果を測定するのが、いまでも事情は変わっていませんが、昔から難しいものです。そうして、雑誌の発行部数というのは、いわゆる公称部数と言って、水増しした発行部数を広告主に提示するということが日常茶飯に行われています。

そういう風潮の中で、日経マグロウヒル社は、雑誌の部数についても正直に報告する、ということを会社の方針にしているのだ、と言われたのです。

また、1980年にニューヨークの米国マグロウヒルに行き、そこでマーケティングの研修を受けました。その時も、米国では雑誌の発行部数を公査するABC（Audit Bereau of Circulation)という機関があり、広告主は部数公査を受けている雑誌でなければ、広告を出さないんだ、ということをいろいろ教えてもらった記憶があります。

要するに、雑誌社には、自分達の雑誌の発行部数を水増しして、広告主に対して過大な部数を公称する会社が多い中で、日経マグロウヒルの経営陣は、そうではなく、自分達は正直にやるんだ、また、部数についても第三者機関の公査を受けて信頼できる部数を出すのだ、それで広告主の信頼を得るのだ、そういう企業姿勢が大事なのだということを言っていたわけです。

投稿者 koba : 08:00 | コメント (2) | トラックバック

2006年05月15日

オープンソース・ビジネスについて考える

XML資料室に、「オープンソース・ビジネスについて考える」という文書を公開しました。

これは、「PDF千夜一夜」の2006年03月25日から2006年04月13日のでのお話を元に、オープンソースのビジネスモデルについて整理してみたものです。

ブログをもとに、読みやすく、分かりやすいように再構成したものです。参考にしていただければ幸いです。コメントもお待ちしています。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月13日

オープンソースのビジネスモデル (17)

さて、そろそろ、この話題も一段落としたいと思います。

それにしても、今回初めて、ビジネスモデルという観点からMySQLのWebページをチェックしてみましたが、MySQL ABには随分多くのベンチャ・キャピタルが投資しています。

MySQL AB投資者
Benchmark Capital：　http://www.benchmark.com/
Institutional Venture Partners：　http://www.ivp.com/
Index Ventures：　http://www.indexventures.com/
Holtron Ventures：　http://www.holtron.fi/　(フィンランド)
Intel Capital：　http://www.intel.com/capital/
等々

う～～ん。MySQLの経営者は、ベンチャ・キャピタルから投資を引き出すのが上手なようですね。こうして投資資金が集まれば、ソフトウェアの開発を加速することができますから、開発競争という面では非常に有利です。

ベンチャ・キャピタルは通常の企業と違い、経営目標の第一優先順位は、投資先の企業の株式市場への公開と、それによるキャピタルゲインの取得にあります。この点、MySQLは、まだ公開していないと思いますが、果たして公開できるかどうか、また、その後、オープンソース・ビジネスモデルでRedHatに次ぐ（企業としての）成功例になるか興味深深ですね。

このように、欧米では、オープンソース・ビジネスに投資をするベンチャ・キャピタルが増えているようです。GPLは、元はといえばStallmanのプログラマ共産主義を実現するためのライセンスとして考案されたものですが、それが、回りまわって資本主義の権化ともいえるベンチャ・キャピタルの金儲けの手段として使われるとは世の中は面白いものです。

ところで、そういえば思い出しました。オープンソースのビジネスモデルとして適切かどうか、わかりませんが、UnysisのLZW特許のようなモデルもあります。つまり、

(5) プログラムをオープンソースで頒布し、普及した頃を見計らって、特許使用料を得る。

LZW特許は、既に米国でも日本でも失効して過去の話になりました。しかし、最近では、JPEGの特許が猛威を振るって問題になっています。

JPEG特許問題

JPEGのプログラムは、BSD/MIT類似のオープンソース・ライセンスで頒布されていますので、著作権上は誰でも自由に使えます。そこで、多くの製品・ソフトウェアで採用しています。しかし、特許は著作権とは別の問題になりますので、オープンソースだからといって採用すると危険という見本です。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月12日

オープンソースのビジネスモデル (16)

完全にボランティア・ベースのプロジェクトを起こすならともかく、優れたプログラムを開発して、世の中で大勢ユーザに喜んで使ってもらうことを目標に据えるならば、そのプロジェクトを継続するための資金をどうするかが大きな課題になります。

いままで調べてきました例で、オープンソース・プロジェクトの資金を獲得する方法として次のようなものが見られます。

(1) Apacheのように寄付金を募り、あるいは、企業からのボランティアに頼る。
(2) オープンソース・ライセンスと占有ライセンスのデュアルライセンス方式を採用する。
(3) RedHatのように、プログラムを商標権によって頒布制限する。
(4) W3Cのように会費制を取って開発する。できあがったものは、後で、オープンソースにする。

オープンソース・プロジェクトのビジネス・モデルを考える場合、どのようなライセンスを選ぶかは重要なポイントの一つです。一般的には、(2)のデュアルライセンス方式を選ぶケースが多いようです。PDF関係では、QhostScriptやXpdfがそうですが、この他に、欧米のオープンソースで成功している企業にはこのようなケースがよく見られます。

例えば、今、脚光を浴びているオープンソースDB　MySQLはGPLと商用ライセンスのデュアルライセンス方式です。MySQLのライセンスの説明には、(1)MySQLを自己のアプリケーションと組み合わせて顧客に販売したり、(2)お客さんがMySQLをインストールして使うことを要求するアプリケーションを販売したり、(3)MySQLを組み込んだハードウェアを販売するのは、再頒布と看做し、MySQLの商用ライセンスを買わねばならないと書いてあります。
　
実は、いま、初めて、MySQLのライセンスの説明について読んでみたのですが、MySQLのライセンス説明のページには少し問題がありそうに思います。

本来、GPLと占有ライセンスは、矛盾するライセンスです。GPLは占有ライセンスと同時に頒布することを認めていません。ですので、GPLで頒布されるMySQLと、占有ライセンスのプログラムを一緒に頒布するとGPL違反になります。従って、MySQLの商用ライセンスが必要となります。これは分かります。

しかし、本来GPLは、頒布に関する条件ですので、ユーザが自社内で使う分にはどんな使い方をしようがGPL違反ではないはずです。そうなりますと、ユーザが、自己の判断で、例えば、アンテナハウスのXSL FormatterをMySQLと組み合わせてシステムを作っても問題はないと思います。

XSL Formatterは占有ライセンスですので、両社を組み合わせて販売したらGPL違反で、ユーザが自己の判断で組み合わせてシステムを作成したらGPL違反にならないということになるはずです。しかし、MySQLのライセンスの説明では、このあたりが曖昧に書かれているような印象を受けます。

いずれにしても、占有ライセンスのソフトウェア供給者は、GPLのMySQLをサポートすると表明すると、まずいことになりそうです。MySQL ABと商用ライセンス契約を交わせばもちろん問題ありません。

このように、デュアルライセンス方式には一種の胡散臭さが残ります。ひとつのソースプログラムを2種類、あるいはそれ以上のライセンスで頒布するというのは、潔くないと思うのですが（日本語では二枚舌と言いますね）。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月11日

オープンソースのビジネスモデル (15)

６．７　W3C License

原文

World Wide Web Consortium (W3C) は、Web関係の標準化を進めている産学共同のコンソーシアムです。米国のMITのCSAIL（Computer Science and Artificial Intelligence Laboratory）、日本の慶応大学、フランスのERCIM（European Research Consortium for Informatics and Mathematics）の3組織がホストになって、世界の企業・団体を組織化しています。

W3Cは、プログラムの実装よりは、むしろ、標準の仕様を策定する方に重点を置いているようです。策定した仕様は公開されていますし、誰でも自由にその仕様を利用してプログラムを実装することができます。そういう意味ではオープンソース・プロジェクトに似ています。

多くのオープンソース・プロジェクトと異なるのは、参加企業・団体にかなり高額の年会費を賦課していることで、それにより、フルタイム専属スタッフを多数擁していることでしょうか。

オープンソース・プロジェクトも、W3Cのように参加会員を募って、プログラムの共同開発を行い、できあがったプログラムは最終的にオープンソースで公開するという仕組みを取ることを考えても良いのではないかと思います。

W3Cの仕様は開発の過程では、会員企業と特定の専門家の内部だけで議論をして進めていきます。W3Cの会員になるメリットは、(1)仕様策定に参加できること、(2)仕様に関する情報を早期に入手できること、(3)各種のPR支援を得られることがあります。

ちなみに、アンテナハウスも会員になっています。当社ではW3Cの仕様の中では、XSL-FO、SVG、MathMLという3種類の仕様を実装しています。W3Cは、そういった仕様に関する情報源として、また同時に、W3CのWebサイトで当社製品をPRしてもらえることは大きなメリットになっています。

話が横道にそれましたが、W3C License はW3Cが開発したソフトウェアを、改造の有無に関わらず、再頒布する際のライセンスです。著作権の表示を明記し、このW3C License 文書を添付すれば、自由に使用を許可するという、プログラム使用者に対して寛容なライセンスになっています。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月10日

オープンソースのビジネスモデル (14)

６．６　Apache：　Apache Software License,　Apache License, 2.0

(1)Apacheとは？
Apache Software Foundation （ASF）は、現在、もっとも広い範囲にわたるオープンソース・プロジェクトを運営している非営利団体です。

プロジェクト領域だけでも、HTTP Server, Ant, APR, Beehive, Cocoon, DB, Directory, Excalibur, Forrest, Geronimo, Gump, iBATIS, Incubator, Jackrabbit, Jakarta, James, Lenya, Logging, Lucene, Maven, MyFaces, Perl, Portals, SpamAssassin, Struts, TCL, Tomcat, Web Services, XML, XMLBeans, XML Graphicsの31があります。

例えば、XML Graphicsには、FOP（XMLからPDFなど）、Batik（SVG関係）のふたつの活動中のプロジェクトがあります。さらに新しいプロジェクトとして、Graphics Commonを計画しており、FOPのPDFライブラリーをGraphics Commonに移すことも検討しているようです。

このように各領域には一つ以上のプロジェクトがありますので、プロジェクト総数は100を超えると思います。ASFは、単にオープンソースのプロジェクトを集めているだけではなく、プロジェクトの活動についてASFの理事会で討議して一定の水準を保つ努力をしているようです。

毎年米国と欧州でApache Conという会議を継続して行っています。

米国歳入庁（IRS)への報告が公開されていますが、これを見ますと、収入は、1999年約45,000ドル、2000年約86,000ドル、2001年約1万ドルとなっています。2003年から2005年は2万5千ドル以下です。ASFには、コンピュータ・メーカからハードウェアやソフトウェアの寄贈があるようですが、これだけの大きな非営利団体の活動を、たった数百万円のキャッシュ・フローで支えることができるのでしょうか？これはなぞです。

(2)　Apache License, Version 2.0
・原文
・日本語訳

このライセンスは、ASFの成果物を頒布するために用いられているものです。Apache Licenseで頒布されているプログラム及びその派生物を、そのソースプログラムであれ実行形式であれ、Apache Licenseを添付し、必要な通知文をつければ自由に頒布することができます。

BSD/MITライセンスに似ています。ASFに寄贈されたプログラムも対象とすること、寄贈者が保有する特許の許諾も含めること、など追加されています。

Apache Licenseはこのように寛容なライセンスであることから、ASFの成果物を改良し、自己の製品として販売しているソフトウェア会社も世界には沢山あるようです。

投稿者 koba : 08:00 | コメント (2) | トラックバック

2006年04月09日

オープンソースのビジネスモデル (13)

６．５　MPL：Mozilla Public License

原文(MPL1.1)
日本語訳

MPLはネットスケープ（Netscape Communications Corp.）が作成したものでネットスケープが改訂権を持っています。Mozillaプロジェクトで使われており、最近、脚光を浴びている新しいブラウザFireFoxはMPL1.1で公開されています。

歴史を簡単にまとめますと；

(1) Netscape Publicライセンス　NPL 1.0
マイクロソフトのインターネット・エクスプローラとのブラウザ戦争で、劣勢になったネットスケープが、1998年にNetscape CommunicatorのソースプログラムをオープンソースしてMozｉｌｌａプロジェクトを起こしました。

その時、作られて適用されたのがNetscape Publicライセンス（NPL1.0）です。NPL 1.0はGPLに似ていて、Mozillaのソースコードを入手したプログラマが、それを改良したアプリケーションを作成して頒布するときは、改良したソースコードを公開・寄贈することを要求していました。

NPL1.0はNetscape Communicator用の修正条項（Amendments）があります。ここで、ネットスケープは、公開・寄贈されたソースコードをネットスケープ自身の他の占有ライセンス製品にも自由に使うことができるとした上、それらの占有ライセンス製品はNPL１．0で公開しなくても良い、というネットスケープに都合の良い条件をつけたことです。これはオープンソース関係者からの批判を招いたようです。

ちなみに、Netscape Communicatorのソースプログラムは複雑すぎて改良できないことが判明し、Mozillaブラウザはゼロから書き直す、ということになりました。Mozillaプロジェクトは失敗したオープンソース・プロジェクトと言えるでしょう。

(2)　Mozilla Public License （MPL) 1.0
Mozilla Public License1.0は、ＮＰＬ1.0にあるネットスケープ専用の修正条項を削除したものです。Mozillaのソースコードを修正した寄贈者が使うためのライセンスです。

(3)　Mozilla Public License （MPL) 1.１
MPL1.0の表現を改訂したもので、実質的な変更はないように思います。

(4)　MPLの特長
MPLの特長は、次の通りです。

・オリジナルのソースプログラムを修正してアプリケーションに使用した場合、その修正したプログラムをMPLで公開する必要があります。
・GPLと違って伝染性はありません。自分でゼロから書き起こしたプログラムは、修正プログラムには該当しません。仮にそれをMPLのプログラムと結合したアプリケーションを作成して頒布しても、自分のソースプログラムを公開することは要求されていません。

MPLは、Copyleftという点では、GPLとBSD/MITライセンスの中間のライセンスということができます。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月08日

オープンソースのビジネスモデル (12)

６．３　BSD：The BSD License

原文
日本語訳

このライセンスでは、修正の有無に関わらず、ソースプログラムまたはバイナリを頒布するときは次の条件を満たすこととされています。

BSDは非常に制限条件の緩いライセンスで、BSDで頒布されるオープンソースのプログラムは、修正したり、あるいは、修正なしで、占有ライセンス、あるいは、GPL/LGPLライセンスのものと一緒に組み合わせて頒布できます。

(1) ソースプログラムを頒布するときは、ソースプログラムに、著作権、BSDの条件、免責事項を含める。
(2) バイナリを頒布するときは添付のドキュメントに著作権、BSDの条件、免責事項を含める。
(3) 許可なく、オリジナルの開発者の名前を自分のプログラムの宣伝に使わないこと。

６．４　MIT：The MIT License

原文
日本語訳

MITライセンスで頒布されるプログラムを入手した人は、著作権表示とライセンス契約を添付するという条件を守れば、どのような使用でもできます。実質的に、BSDライセンスと同じです。

BSDライセンス、MITライセンスともおおらかなライセンスで、ビジネスモデルという表題の下で、取り上げるのが恥ずかしくなるくらいです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月07日

オープンソースのビジネスモデル (11)

LGPLで提供されているオープンソース・ライブラリーを自分で作ったアプリケーションから利用したとき、そのアプリケーションを占有ライセンスで、つまり、ソースプログラムを公開することなく頒布できるでしょうか？

LGPLの契約書はとても難しいのですが。第5節を見ますと次のようなことが書いてあります。

LGPLライブラリーをまったく含まないが、それと一緒にコンパイル、リンクして動作するプログラムはLGPLライブラリーを利用するプログラムといいます。コンパイルというのはプログラムをオブジェクト（バイナリ）にすること。リンクはプログラム同士を結合すること。

契約書第5節
(1)LGPLライブラリーのいかなる部分も含まないで、LGPLライブラリーと結合して一緒に動作するだけのプログラム単体は、LGPLライセンス契約の対象外です。

(2)LGPLライブラリーを利用するプログラムに、LGPLライブラリーをリンクして実行形式を作ると、その実行形式はLGPLライセンスの対象となります。

(3)LGPLライブラリーを利用するプログラムをコンパイルするとき、LGPLライブラリーのヘッダから取られたプログラムが組み込まれると、オブジェクトコードはLGPLライブラリーの適用対象となる可能性があります。但し、組み込まれたプログラムが極少ない分量であれば、LGPLライセンスの対象としなくても良いとされています。

要するに、自分で作成したプログラムにLGPLライブラリーのプログラムをある程度含んでいるか、LGPLライブラリーを静的にリンクすると、自分で作成したプログラムにもLGPLライセンスが適用されます。

そうしますと、頒布するとき、次の条件（第6節）に従わねばなりません。この第6節がまた、難解で、何度読んでも良くわかりません。

契約書第6節
どうやら、この第6節では、次のようなことを言っていると思います。
(1)　LGPLライセンスに感染したアプリケーションを占有ライセンスで頒布するときは、アプリケーションのリバースエンジニアリングを許可しなければならない。

(2)　さらに、LGPLライブラリーをユーザが改変してから自分のアプリケーションと再リンクして実行形式を作成できるか、あるいはコンピュータのシステム上でLGPLライブラリーを、他のアプリケーションど共有して使えるようにするなどの配慮をする必要があります。

(3)　第6節の条件が、自分の占有ライセンスの条件と矛盾する場合は、元のLGPLライセンスのライブラリーを自分で作成したアプリケーションの実行形式で使うことができません。

LGPLライセンスの第6節で要求しているリバースエンジニアリングは、通常の占有ライセンスでは許していないことが多いと思います。従って、多くの場合、第6節の条件で自分のアプリケーションを頒布することはできないのではないでしょうか。

結局、第5節の(3)の「但し」以降に該当する場合のみ、自分のアプリケーションを占有ライセンスとして、LGPLライセンスのライブラリーと一緒に頒布できる、と解釈します。安全な側に解釈しておかないと危険ですしね。

実を言いますと、この解釈はあまり自信がありません。どなたか、良くご存知の方にコメントしていただきたいものです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月06日

オープンソースのビジネスモデル (10)

６．２　LGPL：GNU Lesser General Public License

次にLGPLライセンスについて検討してみたいと思います。
LGPLはGNU Lesser General Public Licenseの略語です。
・原文
・日本語訳

これは、主にソフトウェア・ライブラリー（ソフトウェア関数やデータを集めた部品）用に使われるライセンスの種類です。

ライブラリーはソフトウェアの部品ですから、機械を組み立てるのと同じように、様々な部品を集め、さらにそれを有機的に統合して、アプリケーションを作るのに使います。

そうしますと、ひとつのアプリケーションには、様々なライセンス条件で提供されているライブラリーが混ざることになります。例えば、LGPLで頒布されているライブラリーを、他のプログラムと結合してアプリケーションを作成するとします。

そうするとできあがったアプリケーションを頒布するときのライセンスはどうなるのでしょうか？

(1)他のプログラムの中に、GPLライセンスで頒布されているものが一つでもあれば、当然、それらを結合したアプリケーションはすべてGPLライセンスを適用してオープンソースとして頒布しなければなりません。

(2)では、LGPLで頒布されているライブラリーを、占有ライセンスのプログラムと結合してひとつのアプリケーションを作成したとします。できあがったアプリケーションを占有ライセンスで頒布することができるのでしょうか？

もしこれができるのであれば、LGPLライセンスで頒布されているオープンソース・プログラムを、占有ライセンスで提供する製品のための部品として採用できます。

できないとすると、LGPLライセンスのライブラリーは、占有ライセンスのソフトウェアを開発するために採用できないことになります。

占有ライセンスで販売する市販パッケージ・ソフトウェアの開発者にとっては、上の質問(2)の答えによってLGPLライセンスのオープンソース・ライブラリーを採用できるかどうか、が決まります。大変に重要な問題です。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月05日

オープンソースのビジネスモデル (9)

RedHat のLinuxビジネスは、サービスを売っていると言われます。確かに表面上はそう見えます。

占有ライセンスでは、顧客がプログラムをインストールした台数に応じて、使用料が多く課金されるというビジネスモデルになります。しかし、RedHat Enterprise Linux （RHEL）はGPLライセンスで提供されますから、顧客は、RHELを自由に複製してインストールできます。

顧客が自分でRHELを複製してインストールすれば、インストールしたRHELの台数が増えてもサービス収入の増加には繋がらないでしょう。要するに工夫無しにサービスを売っても儲からないだろうと思います。

収入を増やすには、RHELのインストール台数が増えれば、自然にサービス契約が増えて、サービス料金を多く課金できる仕組が必要です。

このあたり、RedHatは、一体どうやって実現しているのでしょうか？

そこで、同社のサービス購読契約（Subscription Agreement）を見てみました。

ざっとみた結果ですが、うーーん。さすがに、なかなかのものです。多分、優秀な弁護士をそろえて知恵をひねったんでしょう。GPLライセンスのプログラムを頒布して収益を上げるための契約の枠組みを見事に作りあげています。

大雑把に紹介しますと、
１．付録1-1　
RHELは、GPLライセンスで提供していますので、契約書では顧客がプログラムの部品を改変したり、コピーしたり、再配布する権利を制約していません。（制約したらGPL違反になりますから。）

２．付録1-2　
知的所有権という項目で、顧客がRedHatという商標を使ったソフトウエアを頒布することを禁止します。RHELを第三者に頒布するには、RedHatの各種の商標やマークを削除しなければなりません。但し、単に削除するとソフトウェアが壊れるかもしれないと脅す。（商標権で規制してRHELの頒布をさせません。）

３．本文I-A　定義
最初のインストール・システムとは、最初に顧客がお金を払って購入したRHELの枚数。（RHELは公開の場で無償入手できないように規制していますので、1枚目は購入しない限り入手できません。購入した段階で契約が成立して、顧客に契約を守る義務が発生。）

４．本文I-１　契約期間
サービス契約は１年契約で、自動更新。（これは曲者）。

５．本文I-２　価格、請求
RedHatは、契約時、契約更新時に定価の請求書を発行します。顧客は30日以内に支払わねばなりません。（自動更新なので知らないうちに請求が来ます。）

５．本文I-４　報告と監査
インストール・システムを増やすには、RedHatに1台毎に報告して、サービス契約を増やさねばなりません。
RedHatは、契約期間中、顧客企業のインストール・システム数がサービス契約の数と一致しているかどうか1年1回未満で監査する権利があります。
監査結果で不正が見つかったら、顧客企業は20%分のペナルティを払わねばなりません。

大まかなところは以上ですが、これを見ますと、サービス契約を一旦締結すると、インストールした台数が増えたらそれを申告しなければならず、しかも自動更新なので定期的にRedHatに定価で支払いをしなければなりません。これはもしかするとRHELの方がWindowsよりも運用コストが高くつくかもしれません。

この仕組みだと確かにRHELは儲かるでしょう。こんな殆ど悪知恵のような仕組みを良くも考えたものです。

この契約書は、Webページに公開されているものです。オープンソース・プロジェクトを考えている人は、ぜひご自分で研究することをお勧めします。私の理解が間違っているかもしれませんしね。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月04日

オープンソースのビジネスモデル (8)

GPLライセンスが対象とするのは、GPLライセンスで配布されているプログラムを入手して、それを組み込んだり・改変して、それを第三者に頒布する行為です。

自分だけで使う分には無論、いくら改変しようが公開する必要はありません。

では、GPLライセンスのプログラムを、開発会社が入手して、受託開発で作成するシステムに組み込んで、客先に納品した時はどうなるのでしょうか？

GNUのQ&Aに次のような質問項目があります。
GPLは、私が機密保持契約の下で改変されたバージョンを開発することを許可していますか?

この質問への回答を読むと、客先のために機密保持契約を結んで、GPLライセンスのプログラムを組み込んだシステムを開発して納品しても、それを公開する必要はないように感じます。

但し、このあたりは、私の解釈にすぎませんので、もし、GPLを受託開発のシステムに使うならご自分で判断するか、専門の弁護士と相談してもらいたいと思います。

GPLは、Stallmanの、いわばプログラマ共産主義とでもいうべき思想を反映したもの。これを嫌う人も多いようです。しかし、著作権法に基づく私的契約としては、大変良く考えられた方式です。

GPLがこのように有名になったひとつの理由は、LinuxがGPLライセンスで頒布されていることにあります。では、Linuxの成功はGPLライセンスを採用したことが理由でしょうか？

Linuxの開発過程を研究して、「伽藍とバザール」（The Cathedral and the Bazaar）というオープンソース開発モデルについての有名な論文を発表したEric Raimondは、2005年6月の6th International Free Software Forum で、「もうGPLは必要としない」という基調講演を行ったとのことです。彼はインタビュー（ESR: "We Don't Need the GPL Anymore"）に応えて次のように述べています。

GPLがLinux成功の主要な理由とは思わない。むしろ、それは1991年Linusがソフトウェアの分散開発の正しい仕組みを最初に見つけた人だったからだろう。それ以前は安価なインターネットがなかったのでできなかった。それ以後は、新しいOSのプロジェクトを起こそうという人の多くは、Linuxを改善するのが最小コストの方法だということを発見したのだ。

ところで、このインタビューにRedHatについても話題になっています。2006年03月29日 オープンソースのビジネスモデル (2)で、話題になりましたようにRedHat Linux の主要部分は、GPLで公開されています。

でも、RedHat LinuxをCDまたはDVDで入手し、それをそのままインタネットに公開すると訴訟されるそうです。また、コンピュータ雑誌がおまけにRedHatのCDをつけるにはRedHatの許可が必要です。しかし、雑誌社がRedHatに申し込んでも絶対に許可しないそうです。

要するにRedHat Enterprise Linux (RHEL)を入手するには、RedHatに代金を支払って、Subscribe（購読)するしかないということになります。

どうやら、RedHatはRHELを複製再頒布をさせないように商標権で守っているようです。しかし、RHELはGPLで公開されているのでGPL違反ではない、ということになります。

「商標権で保護するとは賢い！」とEric Raimondは感心しています。Ericってすなおな人だねえ。

GPLプログラムを複製されないように商標権で守るというのは確かにオープンソースの新しいビジネスモデルです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月03日

オープンソースのビジネスモデル (7)

さて、ようやく準備ができましたので、オープンソースのライセンスについて検討してみます。

６．オープンソースライセンスの検討
2006年04月01日 オープンソースのビジネスモデル (5)で代表的なライセンスを幾つかあげました。順に簡単にレビューしてみます。

オープンソースでは、ソースプログラムを入手した人に、著作権者が持つのと同じような権利を付与するのですが、その時の条件が、ライセンス毎にそれぞれ違います。

６．１　GPL：GNU General Public License
GNU ProjectのGPLはオープンソースライセンスとして最も有名なものです。GNU Project以外に、さまざまな、オープンソース・プロジェクトが、そのプロジェクトで作成したプログラムを公開する時に、GPLライセンスを採用しています。現在使われているのはGPL Version 2（1991年6月版）です。

・原文
・日本語訳

なお、GPLのV3のドラフトが2006年1月に公開されて大きな論議を呼んでいるようです。
Welcome to GPLv3

GPLの特長はCopyleftというメカニズムです。これは、「誰でもソースコードを修正することができるようにするため、GPLを利用・改変したプログラムを頒布する場合はGPLライセンスで公開しなければならない」ということです。

このため、自分で開発したプログラムにGPLライセンスのオープンソースを結合すると、自分で開発したプログラムを頒布する場合、自分で作成した部分を含めて全てのソースプログラムをGPLライセンスで公開しなければなりません。

GNU ProjectをはじめたのはFree Software Foundation (FSF) のRichard Stallmanです。彼はエッセイCopyleft: Pragmatic Idealismで次の例を挙げています。

GNUのC++コンパイラはMCCが、GNUのCコンパイラを元にして開発したもの。MCCは普通は製品を占有ライセンスで提供している。MCCのC++コンパイラのフロントエンドには新しいファイルが沢山あったが、GNUのCコンパイラとリンクするために、新しいファイルにもGPLが適用された。こうしてMCCはC++コンパイラのフロントエンドを無償で出すことになった。

このようにGPLは感染するライセンスと言われます。GPLで公開されているオープンソースを使って、頒布用のプログラムを開発する時は、GPLは占有ライセンスとは一緒に使えないライセンスであることに注意しなければなりません。

GNU C/C++ コンパイラには例外があります。これらはGPLで公開されています。そして、自分で開発したソースプログラムをGNU C/C++でコンパイルすると、バイナリ・プログラムにコンパイラの標準ライブラリー（すなわちGPLの一部）が結合されてしまいます。そうなると、自分で開発したプログラムをGNU C/C++でコンパイルして頒布すると、自分のソースまで全部公開しなければならないということになりそうです。しかし、これはしなくても問題ありません。標準ライブラリーのソースプログラムのファイルに、標準ライブラリーをリンクしても、実行形式のバイナリはGPL感染から除外されるという例外規定が書かれています（runtime exceptionと言います）。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月02日

オープンソースのビジネスモデル (6)

昨日、オープンソースのライセンスについて代表的なものをあげました。それを読んで考えているうちに、特に複製権（第二十一条）と利用許諾権（第六十三条）の違いに考えて、もう少し、見ないといけないということに気が付きました。

３．複製権と利用許諾権
３．１　複製権と利用許諾権を同一の主体が行使

プログラム利用の一番典型的な例は、エンドユーザ（企業・個人）が、ソフトウェアの著作権者から複製物を入手して、自己のコンピュータの上でそのプログラムを動作して利用するものです（図１）。

この場合、プログラムの複製権・使用許諾権を行使しているのは著作権者（またはその許可を得た者）のみとなります。

図1　自己のコンピュータでプログラムを動かして利用

３．２　複製権と利用許諾権を異なる主体が行使

ところが、次の図２のように、プログラムは公衆または公共のコンピュータ上で動作させ、エンドユーザはその機能のみを利用する場合があります。例えば、いわゆるASP（Application Service Provider）の利用形態がこれに該当します。この場合、複製する行為と、利用許諾する行為の主体が別になっています。

図２　公衆用コンピュータでプログラムを動かして利用

すなわち、ASP形態の場合は、エンドユーザとプログラムの使用契約を交わすのは、ASP(事業者)となります。しかし、ASP事業者は（著作権者でない限り）、使用許諾を交わす権利はもっていません。いま、こうして改めて見ますと、ASP事業者は、著作権者と契約を交わして、第三者に使用を許諾することができる権利を得る必要があるように思います。

４．商用ライセンスと占有ライセンス
４．１　商用ライセンス
次に商用ライセンスという言葉を少し考えて見ます。このブログで商用ライセンスという言葉を既に何回か使いましたが、これは英語のWebサイトに頻繁に出てくるCommercial Licenseの訳として使いました。

商用ライセンスは、プログラム著作者のもつ権利を使って何らかのビジネス行為を行うことを意味していると思います。しかし、商用ライセンスはオープンソースと対比するべき言葉ではありません。

４．２　占有ライセンス
オープンソースライセンスをざっくり言いますと、ソースプログラムを公開し、かつ、そのソースプログラムを入手した人に、著作権者と同等の権利を、一定の条件付きで、権利使用料を取らずに許諾するというものです。

そうしますとオープンソースでないライセンスとは、次のようになると思います。
ソースプログラムを公開しないか、あるいは、著作権者のもつ権利の一部を権利使用料をとって許諾する。

以下、このブログでは、後者を占有（Proprietary）ライセンスと言いうことにします。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年04月01日

オープンソースのビジネスモデル (5)

昨日、著作権法の概略を簡単に説明しましたように、国が定める著作権法が著作権者にいろいろな権利を認めています。

２．２　オープンソースの著作権者
特にオープンソースで少し気になりますのは、著作権者が誰になるかということです。個人でやっている場合は別として、団体、特にネット経由でお互いに協力しながら開発を行う場合、できあがったプログラムの著作権者が誰になるかは自明とは言えないように思います。

もし、特定の組織に著作権を帰属させるのであれば、参加者と組織の間で著作権の帰属についての契約を結んでおかないといけないでしょう。例えば、ApacheのFOPのプロジェクトを見ていますと、SI会社に帰属するプログラマや個人と思われるプログラマが参加しています。しかし、開発者が会社の許可を得て、オープンソースの開発に従事した場合、職務著作物にはあたらないでしょう。ですので著作権の帰属についてきちんと契約を結んでおかないと問題が発生しそうです。

２．３　ライセンス契約の根拠
オープンソースに限らず、ソフトウエアの使用許諾契約（ライセンス契約）は、著作権者が利用者に対して、一定の条件でソフトウエア著作物の使用を許諾するものです。

ライセンス契約では、著作権者は、特に使用許諾を与える権利を行使しているということになります。

プログラムの使用許諾を受ける側は、著作権者から提示された条件を承認して契約を結ぶわけです。従って、約束としてそれを守らねばならないということになります。

２．４　ライセンス契約の種類
Open Source Initiative (OSI)のWebページには、オープンソース・ライセンスとしてOSIが承認したもののリストがあります。

・The Approved Licenses

ABC順にAcademic Free License からzlib/libpng license まで58種類がリストされています。

・OSI承認ライセンス 日本語訳一覧

この中で普及している、有力なものは、
・GPL　GNU General Public License
・LGPL　GNU Library or "Lesser" General Public License
・BSD　New BSD license　（MITライセンスと同等）
・MIT　MIT license　
・MPL　Mozilla Public License
・Apache　Apache Software License,　Apache License, 2.0
・W3C License
あたりでしょう。

独断、偏見、多少の経験に基づく判断で選びましたが、次にこれらのライセンスについて、少し検討してみましょう。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月31日

オープンソースのビジネスモデル (4)

先に進む前に、ここでオープンソースという言葉とライセンスについて簡単に検討してみます。

まず、オープンソースという言葉ですが、プログラムのソースコードを公開、共有利用するというのは30年以上前からありました。

私がコンピュータをはじめて使いましたのは1973年ですが、当時、Fortranという言語で多変量解析などのプログラムを書いて、大型コンピュータ（メモリは128KB位から256KB位だったと記憶していますが）で計算しました。

そのプログラムは数式を元にゼロからプログラムを書いたわけではなく、専門書に掲載されていたプログラムや専門の研究所から入手したプログラムリスト（プログラムのプリントアウト）で、他の人の書いたプログラムを読んで、それを元に自分なりに多少修正してプログラムを作ったことの方が多かったと記憶しています。

実際、大きなプログラムをゼロから書くことはあまりなく、90%位は既存のものを使い、仕事に合わせて10%位書き直してということをやっていたと思います。ですからプログラムは（社外だけでなく社外とも）共有するものなんだな、とずっと思っていた位です。

そもそも自分の開発したプログラムのソースコードを占有し、使いたい人に使用権をライセンスするというビジネスの方が比較的新しいビジネスモデルである、といえるかもしれません。

さて、以上の話は個人的な余談として、本題に入ります。

１．オープンソースとは
現在、オープンソースの話についてはいろいろな人が語っていますので、ここではもう語るのはやめて、オープンソース・イニシアティブの言葉の定義を示しておきます。

１．１　原文(英語)
・Open Source Initiative (OSI)

・The Open Source Definition

１．２　日本語訳
・オープンソースの定義（The Open Source Definitionの翻訳）
・オープンソースグループ・ジャパン(日本独自の団体）

２．ライセンスとは
ソフトウエア(特に新しいソフトウェアを開発する）プロジェクトという点から考えますと、オープンソースという言葉の検討より、どのようなライセンスを選択するかという検討が重要です。ライセンスは著作権者とそれを利用する者の間の私的契約事項です。そこで順序として、最初に著作権者と利用者の基本的権利を確認しておきます。

２．１　法律上の根拠
ライセンスの基本になるのは国家の法律です。
ソフトウエアを保護することができる法律は、主に次のふたつだろうと思います。
(1) 著作権法
(2) 特許権

著作権法については、日本国内では日本の著作権法が適用されます。
海外では、当該の国の著作権法で保護されることになると思います。

国際的には、万国著作権条約加盟国では、各国内の著作権法を万国著作権条約の規定に合わせて変更しています。
日本の場合：万国著作権条約の実施に伴う著作権法の特例に関する法律

プログラムは著作権法の対象になると具体的に例示されています。
・第十条　（著作物の例示）　九項　プログラムの著作物

職務著作物としてのプログラムの著作者は、原則としてその人が属する法人になります。
・第十五条の2　職務上作成する著作物の著作者

著作者は幾つかの権利を持ちます。プログラムに関してその主なものは、
・第十八条　公表権
・第十九条　氏名表示権
・第二十条　同一性保持権　　但し、動作しないプログラムを動作するように改変することは、同一性保持権の適用対象外
・第二十一条　複製権　これは著作者の専有です。
・第二十六条の二　譲渡権　著作者は複製による譲渡権を専有します。
・第二十八条　二次的著作物の利用に関する原著作者の権利　原著作者は二次的著作物にも権利を持ちます。

一方、著作権には制限があります。
・第四十七条の二　プログラムの著作物の複製物の所有者は、利用する必要と認められる限度で複製・翻案を行うことができます。

著作者の権利の行使
・第六十三条　著作権者は著作物の利用を許諾できます。

権利侵害
・第百十二条　著作者は差止請求権をもつ
・第百十四条　損害の額の推定

罰則
・著作権違反については、段階に応じて、罰則（懲役または罰金）規定があります。

このように、国家の法律では著作権者の権利を一部の制限を除いて守っていることをまず理解しなければなりません。これは著作権者の権利を守ることで、創作活動が活発になり、文化の発展につながるということが大義名分です。

特許権についても、著作権と同じように特許権者の占有権を保護しています。ここでは、省略しますが、ビジネスを行ううえでは、これらの法律の大筋を理解しておく必要があります。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月30日

オープンソースのビジネスモデル (3)

PDFのオープンソースのビジネスモデルのもう一つのタイプはGhostScriptやXpdfのように、同じものを商用ライセンスとオープンソースライセンスのデュアルライセンスで提供するタイプです。

例えば、GhostScriptのライセンスはここに説明されています。
http://www.artifex.com/licensing/index.htm

これによりますと、GhostScriptは３種類のライセンスで提供されています。

なお、以下でいうライセンスの違いは、主にGhostScriptを使ったアプリケーションを再配布する時の条件の違いになります。従って、製品提供者側向けの話です。エンドユーザの使用権について言っているわけではありません。

(1) Artifex Ghostscript　商用ライセンス
Artifex 社と契約を結びGhostScriptのソースコードを入手、GhostScriptを自分で開発したアプリケーションと一緒に配布する権利を得ることができます。このとき、自分で開発したアプリケーションのソースコードをオープンソースにしなくても構いません。

(2) AFPL Ghostscript：Aladdinフリー公開ライセンス（Free Public License）
(3) GPL Ghostscript： GPLライセンス

GPLまたはAFPLのGhostScriptを使うなら、自分が開発するアプリケーションが、次のいずれかにあてはまる場合、自分が開発するアプリケーションすべてをGPLまたはAFPLで公開しなければなりません。

・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptのコピーを含む。
・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptから派生している。
・自分で開発するアプリケーションが、GPLまたはAFPLのGhostScriptのひとつ以上の機能を使っている。

自分が開発するアプリケーションをGPLまたはAFPLで公開しないなら、(1)の商用ライセンスを選択しなければならないのです。つまり、お金を払って再頒布の許可を得なければなりません。

AFPL GhostScriptはこちらから入手できます。
AFPL Ghostscript

GPL GhostScriptはこちらから入手できます。
GPL Ghostscript

ややこしいですね。それにしても、なぜ、商用ライセンスの他に、GPLとAFPLの2種類のライセンスがあるのでしょうか？

Aladdin Free Public Licenseの文章をざっとみますと、まず、これは、(いわゆる）オープンソースではないと書いてあります。GPLとの違いとして、AFPLでは「商用団体が、直接的にせよ、間接的にせよ、対価をとってAFPL GhostScriptを配布することを禁止している」ということで、「AFPLはGPLより厳しいライセンス」であると書かれています。
GPLは対価を取ることを禁止していません。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月29日

オープンソースのビジネスモデル (2)

PDFのオープンソース・プロジェクトの中で、現在の時点で一番うまくいったのは、PDFLibでしょう。PDFLibはオープンソースから初めましたが、既にオープンソースを卒業してしまったようです。成功した例が既にオープンソース・プロジェクトでない、というのは皮肉です。

改めてPDFLibのWebページを見ましたが、現在では、PDFLib Liteのみが、オープンソース開発者、私的利用者、研究者向けに限りオープンソース・ライセンスで提供されています。他の製品はすべて商用ライセンスを有償で購入する必要があります。

PDFLib Liteのライセンスページ
http://www.pdflib.com/purchase/license-lite.html

ちなみに、いま盛んに宣伝されているLinuxで、もっとも成功したのはRedHatだろうと思います。RedHat Linuxはオープンソースからスタートしたかもしれませんが、現在はRedHat Linuxをオープンソース・プロジェクトに分類するのは不適切なように思います。PDFLibと同じように、RedHat Linuxは極一部だけ、オープンソースで提供しているように思います。

このふたつの例をもって、オープンソース・プロジェクトは成功するとオープンソースでなくなる、といったら言い過ぎかもしれません。しかし、多少なりとも大きなプロジェクトにして、品質の高い製品を継続的に出していこうとすれば、どうしても対価を得る必要があります。そのためには対価と交換に製品を提供するという仕組みをとるのが一番単純明快のように思います。

元に戻りますが、PDFLibのWebページを見ますと、現在では、ＰＤＦLibは同名の会社名となり、PDFLibはバージョン6、製品の種類も増えて世界の60カ国以上に製品を販売していると言っています。いくらインターネットを通じてオンライン・ダウンロード販売できると言っても、世界60カ国はなかなかすごいと思います。

PDFLibの成功の要因は次のようなことでしょう。
(1) サーバサイドPDFへの取り組みが早かった。
(2) 書籍などでPRして有名になった。
(3) 開発者のPDFに関する知識のレベルが優れていた。
(4) プログラムの品質が高い。

しかし、この成功の条件はオープンソースとあまり関係ありませんね。PDFLibの成功にはオープンソースで始めたことはあまり関係ないのではないでしょうか。

他には、ReportLabも結構長期間に渡って頑張っています。ReportLabは、商用ライセンスとオープンソース・ライセンス（OSL）の両方を用意して、ユーザがどちらかを選択するデュアルライセンス方式を取っています。

このデュアルライセンス方式は、オープンソースのビジネスモデルの一つです。
ReportLabは、商用ライセンスの製品では、OSLの製品と比べて、製品の種類を増やしています。また、利益源になる製品は商用ライセンスしか提供していません。このあたり、PDFLibやRedHat Linuxと似ています。

結局、オープンソースから商用ライセンスに向かうというところに成功への道が一つあるように思います。

2006/3/30追記　sodaさんのご指摘の通り、RedHat Linuxの中核部分のソースは公開されているようです。公開部分が全体のどの位の割合になるか分かりませんが、RedHatのビジネスモデルがPDFLibと同じと分類するのは不適切でした。RedHatの課金方法は、一見、商用ライセンスと似ていますが、商用ライセンスに向かっていると分類はできないようです。

なお、3月28日に2006年2月度のRedHatの決算が発表されています。
Red Hat Reports Fiscal Fourth Quarter and Fiscal Year 2006 Results
売上高　　　2億78百万ドル　前年比53%増
営業利益　　　 58百万ドル 前年比165%増

というすばらしい業績です。但し、まだ多額の累積損失が残っていて、自己資本比率は30%台なので優良企業というにはあと数年掛かるように思います。

投稿者 koba : 08:00 | コメント (6) | トラックバック

2006年03月28日

オープンソースのビジネスモデル (1)

さて、過去3回にわたりPDFのオープンソース・プロジェクトについてチェックしてみました。

次に、これらの事例を参考にしながら、オープンソースのビジネスモデルについて検討してみたいと思います。

新しいプロジェクトを始めるにあたり、それが成功するための条件が分かれば良いのですけれども。しかし、PDF分野では期待したほど成功したオープンソースはありません。ですのでビジネスモデルを検討するには不十分かもしれません。随時、他の事例を参照しながら考えて見たいと思います。

予めお断りしますが、以下の議論では、オープンソースの成果を消費する立場ではなく、オープンソースで何かを作りだそうという立場でのものです。

どんなプロジェクトでも成功するには大義名分が必要です。

商用ソフトウエアのメーカは、私利私欲を追及していると見られがちです。ここで強調しておきたいと思いますが、当社の場合は、私利私欲を追及している訳ではありません。念のため。

この点、オープンソースのプロジェクトは、利己的な利益と離れて、公益を追求すると言う大義名分を付けやすいように思います。しかし、実際は、大義名分だけでは持ちこたえることができないのは、社会人であれば誰にでも分かると思います。

オープンソースのプロジェクトで、恐らく一番大きな問題は、開発者に資金が還流しないことです。

商用ソフトウェアの場合は、ソースコードの権利と、その生成物であるオブジェクトの権利を占有し、顧客に使用権を提供すると同時に見返りに対価を得るというビジネスモデルが成り立ちます。

しかし、オープンソースでは、ソースコードを誰でも入手できます。結果的にオブジェクトを誰でも入手できることになります。誰でも入手して使えることになれば、当然使用権を提供して対価を得ることは難しくなります。ありていに言えば、誰も使用料を払わなくなるということです。従ってプログラムの使用料を得るのは難しいことになります。

一方、どのようなものであれ、開発には必ずお金が掛かります。そのための資金を集めなければなりません。しかし、開発に使った資金がより大きな価値となって回収できる見込みがなければ、新しいプロジェクトに投資する人はいないでしょう。大きなプロジェクトを起こすには、ベンチャキャピタルという仕組みもありますが、ベンチャキャピタルは投資が回収できる見込みがなければ決して投資しないでしょう。

この点、米英でオープンソース方式で開発するソフトウエア会社にベンチャキャピタルが出資するケースが増えているのは注目されます。

政府のような公的機関の場合は、資金の回収ということはあまり考えないかもしれませんが、国民の汗と涙の結晶である税金を使う以上は、ベンチャキャピタルなどよりは遥かに厳しい投資判断基準が必要なはずです。

最近のオープンソース・プロジェクトは、コンピュータ・メーカやシステム・インテグレータに在籍する開発者がフルタイムで働くものが多いですが、その場合、プログラマが在籍する企業にとってオープンソース・プロジェクトが価値があるものでなければなりません。

草の根オープンソース・プロジェクトでは開発者が手弁当で働くことになります。この場合、苦労した開発者が報われないような仕組みでは、プロジェクトを長期にわたって活発に継続することはできないでしょう。

このようなことを考えると、オープンソース・プロジェクトを起こすにあたって、ビジネスモデルを十分に検討することが最も大事といえるでしょう。このためのひとつの手段は、成功したプロジェクトを研究することです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月06日

アドビのマルチ・プラットフォーム作戦の行方　Linuxを買収？

アドビのCEO Bruce Chizen のWhartonインタビュー読めば読むほど面白い。アドビは、幾つかの事業をもっているのですが、Bruce は、その一つとしてengagement platform構想について熱く語っています。

このアドビのengagement platform構想を追求していくと、恐らくLinuxをどれか買収しなければ済まないのではないか？という気がします。

以下は、私の妄想ですので、そう思って気楽に読んでください。間違っても、どこかのLinuxベンダの株を買いに走ったりしないように。Linux株で損しても、私は一切責任をもちませんから。

まず、アドビがMacromediaを買収した最大の目的はFlashだ、と述べています。そうして、FlashとPDFを組み合わせて、マルチプラット・フォームで表示系を抑えるということを狙っているようです。

engagement platformで、Windows、Macintosh、SunなどのPCまたはワークステーションなどのコンピュータ系だけではなく、携帯電話のようなモバイル機器、自動車、あるいは、eBookなどの読書端末までをカバーしようとしています。インタビューでは、後者をmini engagement platformとしています。

まず、コンピュータ系の世界で考えますと、Bruceの発言でもありますが、アドビのengagement platformは、Microsoftが支配するWindowsの世界では、それ程大きな価値はありません。Windows以外のコンピュータが増えないと価値が大きくならないのです。

さらに、engagement platformは表示用途ですので、サーバ・コンピュータ用ではなく、デスクトップ・コンピュータ用となります。ところで、いま、注目を集めているLinuxはサーバ用途では普及が進んでいますが、デスクトップ用途ではなかなか普及が進みません。なぜかと言いますと、デスクトップではマンマシン･インターフェイスであるグラフィック・ユーザ・インターフェイス（GUI)が重要なのですが、LinuxOSにはWindowsのような優れたGUIシステムがないからです。そうするとengagement platformの価値を増大するには、LinuxOSにWindowsシステムを構築するという大掛かりな投資が必要となります。従って、これをどうするかがアドビの次の課題ということになります。

mini engagement platformについていえば、例えば日本の携帯電話のOSは、一時はTronが主流でした。しかし、Tronは減っていると思います。世界的に見ますと米国Qualcom社のBrew、英国シンビアン社のSymbianOSを見逃すことができません。最近はLinuxを組み込んだ携帯電話も増えています。
・「2005年度は1000万台近いLinux搭載3G携帯を出荷する」---NTTドコモ 照沼和明氏

アドビのPDFは一部の携帯電話に載っていますが、あまりメジャーな存在にはなっていません。Flashを欲しかった最大の理由は、恐らく携帯電話への取り組みの遅れを取り戻したかったことが大きな動機になっていると思います。そうすると、mini engagement platformの分野でMicrosoftを出し抜くための、アドビの次の一手は組み込みLinuxを手に入れる、ということになりそうです。

どっちにしてもLinuxだ！

投稿者 koba : 08:00 | コメント (0) | トラックバック