AndroidのAPIをめぐる問題

JavaのコードをAndroidが勝手に使っていたとして
OracleがGoogleを訴えていた事項で、次のような判決が下った。


「Oracle対Google裁判、陪審がAndroidにおける一部著作権侵害を認める」
http://itpro.nikkeibp.co.jp/article/NEWS/20120508/394981/

この解説をみただけではこれが良くあるコードの不正使用であり
ある意味ニュースとしてはありきたりの事件として思われるかもしれない。
しかし、今までの訴訟の流れを見るとオープンソースというもの流通を阻む
可能性を示唆した大変重大な問題であると分かるでだろう。


つまり・・・・
---------------
１）2010年8月、OracleはJavaに関する7件の特許を侵害しているとしてGoogleを訴える。


２）特許をめぐるこの裁判は、2012年3月に、Oracleの一部の特許請求が米特許
商標局（USPTO）により却下されたことを受けて、Oracleが申立ての一部を取り下げ、
2件の特許について争う。（ただし、そのうち一件の特許は今年12月に期限切れになる。）


３）裁判所は、両者に4/13までの和解を勧告。
Googleは、和解案を受け入れ、「特許侵害が認められれば、280万ドルを支払う」ことを表明。




４）ところが、Oracleは、金額が低すぎるとそれを拒否し、新たな訴えを起こす。


新しい裁判では、これまでの特許権侵害についての争点とは一転し、
Oracleは、Androidが、Javaの、37のAPIを利用していることが、
著作権の侵害にあたるとして、10億ドルの損害賠償を求めています。

---------------


補足：APIとは、アプリケーション・インタフェースの略称で
あるソフトウェア機能を外部のソフトウェア部分から利用する定義の事で、
それ自体には実態となる機能（中身となるソースコード）が存在するわけではない。

今回のOracleは、言語のAPI自身も著作権で保護されるべきだというものです。

もし、そうした主張が認められるなら、Scala、JRubyなども、Oracleの著作権を

侵害していることになります。

また、長年業界ではAPIはよほど特殊なものでなく妥当な定義であれば

誰が考えてもほぼ同じ結論に達する場合も多く、その中身を丸々コピーしないので

あれば、同じようなAPIを実装したプログラムが世の中にはいっぱいあります。

それは自動車業界やその他産業界においても同じ状況でありましょう。

著作権というものを単なるお金儲けの道具にしていいのでしょうか？

本来の著作権法の目的であるテクノロジーの共通化やオープン化という振興に逆行する、

私たちの将来の進歩に不利益をとなる火種を伴う、思ったより重大な問題かもしれません。

パノラマの実験

パノラマの実験をしてみました。

PCではFlash、iPhone,iPadだとHTML5に自動的に切り替わって表示します。

元にしたパノラマ写真は、iPhoneのDerManDarというフリーソフトで撮った写真ですが腕が悪いのでずれて二重にだぶって映っている所があります。

けれどだいたいの表示と操作の雰囲気は分かるかと思う。

下の画像をクリックしてみて下さい。

FlashをHTML5に自動変換

「Google Swiffy」を使うと、SWF形式のファイルをHTML5に自動変換してくれる。

クラウドツールで使う事もできるし、Adobe Flash Professional CS4のExtentionをダウンロードする事もできます。

下記は、実際にSWFファイルをアップしてHTML5に変換されたものと比較表示された画面。

SHELL32.dllにおけるWindowsバージョンの違いによる不都合。

先日、僕が公開しているファイル検索ツールFileDiverのユーザから不具合のご連絡頂いた。WindowsXPにおいて下記のようなメッセージが出て起動できないというものである。

「プロシージャーエントリーポイントSHGetKnownFolderPathがダイナミックリンクライブラリ

SHELL32.dllから見つかりませんでした。」

著者のテスト環境は現在、VistaとWindows7でXP以下についてはアプリケーションの互換モード設定を使って確認している。勿論互換モードではそのようなエラーは出ていなかったはずで、再度互換モードで確認しても再現できない。

そこで念の為、XPの入った古いパソコンを引っ張り出して、インストールしてみると・・・確かにエラーが出る。

LocalLow は、Vista以降で導入されたアプリケーションが一時的に蓄積する場所でSHGKownFolderPath()で取得する事が出来る。したがって、アプリケーションの動作しているバージョン番号をチェックして、Vista以上でSHGKownFolderPath()を呼べば良いはずである。XPではSHGKownFolderPath()はコールしていないにも関わらず・・・。

「どういうこと？」

ネットをあさってみると、やはり同じような対処方法しか書いていないが、一部海外のもので同じような現象で困って、XPで動くVista用のshell32.dllを作って取り換えるという荒技などを紹介したサイトがあった。

これはもしかしてと思い次のようなコードを書いて、Vista以降で呼ぶようにしたらXPあっさり動いた。アプリケーションが使用するWindowsの基本DLLにあるメソッドを全てリストアップして、あれば起動時にエントリーポイントをロードしているようである。

したがって、たとえ実際に動作時に１度もコールしていなくても動作環境のDLLになければエラーが発生する。これは全ての同様なアプリケーションで発生する可能性のあるワールドワイドな不都合だ。

Microsoftは、WindowsXPのSHELL32.dllにも、ダミーのSHGKownFolderPathメソッドを作成してWindowsUpdateで配るべきだと思う。

CString getLocalAppDataLow() {
typedef HRESULT ( WINAPI *FPSHGetKnownFolderPath )( const GUID&, DWORD, HANDLE, PWSTR * );
CString strPath;
HRESULT hr;
HMODULE hLib;

hLib = LoadLibrary( _T( “shell32.dll” ) );
if (hLib ) {
FPSHGetKnownFolderPath func = reinterpret_cast<FPSHGetKnownFolderPath>( GetProcAddress( hLib, “SHGetKnownFolderPath” ) );
if ( func ) {
LPWSTR pstr = NULL;
hr = ( *func )( FOLDERID_LocalAppDataLow, 0, NULL, &pstr );
if ( !FAILED( hr )) {
strPath = pstr;
}
}
FreeLibrary( hLib );
}
return strPath;
}