iOS

2014年09月25日

Metalでボーンアニメーション!!

はてなブックマークに登録

3Dアプリの開発にはまずモデルの読み込みが必要となります。
Metalにはレンダリング機能はあるものの、ローダは備わっていません。
そこで今回はボーンアニメーションに対応したモデルローダ作成のノウハウ(特にMetalの特性にどう対応したか)を紹介したいと思います。

ソースコードはこちらです: http://log.blog.klab.org/support/20140925/Blacksmith-bone_animation_sample.zip
メインとなるファイルはBSModelとBSRendererです。
BSModelはモデルデータの管理やボーン計算を担当し、BSRendererはBSModelから頂点データやテクスチャ、ボーンマトリックス等を受け取ってレンダリングを行います。

04


まずはじめにモデルファイルのパースが必要となります。
3Dモデルのファイルフォーマットは世の中にいくつも存在するので、それら全ての仕様を把握して対応するのは大変です。
ですが、代表的な複数のフォーマットに対応したAssimpというオープンソースのライブラリがあります。
http://assimp.sourceforge.net/
Assimpは様々なフォーマットのファイルを読み込んで統一の形式に変換してくれるので、BSModelの中でパーサとしてこのライブラリを使わせていただきました。
Assimpの開発に関わっている方々に感謝いたします。

さて、ボーンアニメーションを再生するための頂点の位置計算にはいくつか方法があります。
 1)ボーンマトリックスをパラメータとして渡して頂点シェーダで計算する
 2)レンダリングパスを分けながら頂点シェーダで計算する
 3)頂点テクスチャにボーンマトリックスを格納して頂点シェーダで計算する
 4)CPUで計算する
まずはOpenGL(ES)を使う場合を考えてみましょう。
GPUを利用してハードウェアアクセラレーションを効かせられるのが1〜3の方法です。
もし1の方法で問題なく実行できる環境にあればそれがベストです。
しかし、OpenGL(ES)にはシェーダに渡せるパラメータの大きさに制限があり、ボーンマトリックスの数がそれを超えてしまうと正しく計算できません。
そこでそのような場合には2の方法を取りますが、レンダリングパスが増えてしまうのでパフォーマンスは落ちます。
3の方法はボーンマトリックスの情報をテクスチャに格納してシェーダに渡すというテクニカルな方法です。
テクスチャは先程のパラメータの大きさ制限を受けることはないので、大量のデータを格納してシェーダに渡すことが出来ます。
ただし、頂点シェーダでテクスチャをフェッチできるようになったのはOpenGLESでは3.0からなので、古い環境をサポートしなければならない場合は3の方法を取ることは出来ません。
4は環境に依存することのない方法で、ボーンが何本あろうとも有効な方法ですが、ハードウェアアクセラレーションが効かないので、頂点数に比例して処理時間がかかります。
VBOを使わない方法なので毎フレームメインメモリからの転送が必要で、その分のコストもかかってしまいます。

一方、Metalではシェーダに渡せるデータ容量の制限が大幅に緩和されています。
ですのでボーンアニメーションを実装する場合には特に気にすることなく1の方法を採用出来、実装が非常に簡単になります。
これはOpenGL(ES)と比べ、大きな強みと言えるでしょう。
シェーダはGPUProgram.metalに書かれており、vertexShaderWithBoneAnimation(…)がボーンマトリックスを元に頂点の位置計算を行う頂点シェーダです。

頂点の位置を計算する仕組みは整ったので、後はボーンマトリックスを準備しなくてはいけません。
ボーンマトリックスの計算自体はOpenGL使用時と特に変わりありませんが、Metal使用時のポイントが一つあります。
それはボーンマトリックスのバッファ(CPU/GPU shared memory buffer)を複数用意するということです。
CPUとGPUは非同期で動いています。
CPUでレンダリングコマンドを作成してコマンドキューにプッシュした後は、GPUが処理を終えて終了通知のコールバックが返ってくるまではGPUがボーンマトリックスのバッファにアクセスしています。
その間にCPUからボーンマトリックスのバッファに対して書き込みを行うと不整合が起きます。
しかしながらレンダリングコマンドを投げた後にGPUが非同期で働いている間、CPUに何もさせずに待っているのももったいない話です。
ですのでボーンマトリックスのバッファを複数用意しておき、GPUがある一つのバッファにアクセスしている間、その他のバッファに対してCPUで計算した結果を書き込むようにします。
こうすることでCPUとGPUが非同期で動いていることを活かしたパフォーマンスの引き出し方が可能になります。

以上で紹介したように、MetalではOpenGLよりも簡単にボーンアニメーションに対応することが可能で、よりパフォーマンスを上げる仕組みを採用することが出来ます。
OpenGL(ES)に対応した従来のミドルウェアは上記1〜4の方法をハードウェアスペックとボーンの数により切り替えることによってボーンアニメーションを実現していると私は予想しています。
全体的なパフォーマンスアップに埋もれて気づき難いかもしれませんが、ミドルウェアがMetalへの対応を行えばボーンアニメーションのパフォーマンスが向上することが予想されます。
ミドルウェアを使用する側もボーンの数を気にせずにモデリングできる様になるかと思います。
これからはiOSのゲームにヤマタノオロチの様な沢山のボーンを持ったキャラクターがガンガン登場するようになるかもしれません。
2014年09月19日

Metalのコードを読む前に知っておくと楽なこと

はてなブックマークに登録

iOSのDeveloperサイトでは基本的なものから応用的なものまでいくつかのMetalのサンプルがダウンロードできるようになっています。
早速Metalを学習しようと一番基本的なサンプルを紐解いてみるも、以下のように沢山のクラスが登場します。
 ・MTLDevice
 ・MTLBuffer
 ・MTLTexture
 ・MTLCommandQueue
 ・MTLCommandBuffer
 ・MTLRenderCommandEncoder
 ・MTLLibrary
 ・MTLFunction
 ・MTLRenderPipelineState
主なものを列挙してみましたが、数が多いだけに前提知識無しでいきなりサンプルを読み進めるのは困難です。
そこで今回はこれらのクラスがレンダリング全体の流れの中でどのような役割を担っているか図で整理しながら紹介したいと思います。
ここで紹介する流れは複雑なサンプルであっても同じであるし、コードを書く際にも役立つものと考えております。

まず、具体的にAPIの説明に入る前に、ハードウェアとレンダリングの流れを説明します。
46

モデルデータやテクスチャなどのオブジェクトは「shared CPU/GPU memory buffer」上に格納されます。
CPUはアプリケーションの実行において様々な仕事を担当しますが、GPUへの命令を作成して渡してあげるのも役割の1つです。
GPUがレンダリング処理をするために必要なデータやプログラムをコマンドと言う形にまとめて、コマンドキューにプッシュします。
コマンドキューからポップされたコマンドをGPUが受け取り、レンダリング処理を行って画面に出力します。
以上が簡単なレンダリング処理のイメージです。

それでは各APIの役割について説明していきます。

MTLDevice
ハードウェア全体を司る、言わばボス的な存在です。
モデルデータを保持するバッファや、テクスチャ領域をメモリ上に確保したいときはこのMTLDeviceに依頼する形になります。
また、コマンドキュー(後述のMTLCommandQueue)の管理も担当しています。

MTLBuffer
モデルデータ(頂点データ)やその他レンダリングに必要なパラメータを記憶しておく領域。
CPUからもGPUからもアクセス可能。

MTLTexture
レンダリングに必要なテクスチャを管理するためのクラスです。

MTLCommandQueue
レンダリング(またはコンピューティング)コマンドをGPUに流すためのキュー。
GPUのタスクが空き次第プッシュされた順にコマンドが実行されます。

MTLCommandBuffer
上記MTLCommandQueueにプッシュするコマンド本体。
コマンドは主にGPUで実行されるシェーダプログラムやテクスチャ・頂点データのポインタ、その他のパラメータのポインタなどの情報で構成されます。
レンダリング用のMTLCommandBufferのオブジェクトを作成するには次のMTLRenderCommandEncoderを使用します。
また、このコマンドはGPUで処理が完了した際に、CPU側にコールバックが返るようになっています。
コマンドをプッシュしてからコールバックが返ってくるまではMTLBufferの内容をCPU側で書き換えないようにするのが競合を防ぐポイントです。

MTLRenderCommandEncoder
レンダリングコマンドを作成するための役割を持つクラスです。
MTLBufferやMTLTextureのオブジェクトのポインタや、以下で紹介するMTLRenderPipelineStateのオブジェクトを元にコマンドを生成します。

MTLLibrary ・ MTLFunction ・ MTLRenderPipelineState
これら3つはシェーダやカーネル関数のようなGPUで実行されるプログラムに関するものです。
OpenGLでは実行時にシェーダをコンパイルしていましたが、Metalではアプリのビルド時に一緒にコンパイルされ、ライブラリというファイルにひとまとめでバンドルされます。
そのライブラリにアプリからアクセスするためのクラスがMTLLibraryです。
ライブラリからバーテックスシェーダ・フラグメントシェーダ・カーネル関数を一つ一つ取り出したものがMTLFunctionのオブジェクトです。
これらの関数をレンダリングコマンドとして使うためにMTLRenderPipelineStateに持たせてMTLRenderCommandEncoderに渡します。


以上、主なクラスについて整理してみました。
Metalのサンプルを読み解く際やプログラムを書くときに、紹介した図を思い浮かべて各クラスの役割を思い出してみるとスムーズに進むかと思います。
2014年09月18日

Metalの「shared CPU/GPU memory buffer」について

はてなブックマークに登録

iOS8のリリースにより、A7を搭載したiOS端末からはOpenGLESに代わる新グラフィックスAPIであるMetalが動くようになりました。
iOS8発表時のAppleのKeynoteで紹介されたとおり、MetalはOpenGLとくらべてAPIの層が薄くて最適化されているので高速に動作するようで、他の多くの記事でもこの事が書かれています。

しかし実際にMetalに触れてみると、単にAppleのハードウェアに最適化されていてオーバーヘッドが低く速いということに留まらず、ある一つの特長に気付きます。
それは「shared CPU/GPU memory buffer」つまりCPU/GPU間でメモリが共有されているというものです。
ここでは今までiOSの3Dアプリケーション開発に利用されていたOpenGLESでのメモリの扱い方と比較しつつ、CPU/GPU間でメモリが共有されることのメリットについて触れたいと思います。

まずiOS端末ではなく、PCにおけるOpenGLについて振り返ってみます。
OpenGLにおいてはGPUメモリにCPUから直接アクセスすることが出来ないようになっています。(GPUからメインメモリへも同様)
その理由として以下の2つが考えられます。
 1)物理的に離れており、アクセスするのに大きなオーバーヘッドがある。
 2)CPUとGPUは非同期で動いており、お互いのメモリ領域に自由にアクセスできてしまうと不整合が起きる。
1つ目はPCを自作されたことのある方ならよくご存知かと思いますが、メインメモリはマザーボード上のスロットに差し込み、GPUメモリはGPUと同じくグラフィックカード上に搭載されていて物理的には離れた位置に配置されます。
CPUで読み込んだモデルデータを実際にレンダリングするにはメインメモリからGPUメモリにデータを転送する必要がありましたが、上記の2つの理由により、一度GPUメモリに転送したモデルデータはCPUから書き換えが出来ないようになっています。
レンダリングの度に転送するのでは負荷が高いので、転送したデータを使いまわすVBO(VertexBufferObject)という仕組みが用意されています。
VBOはCPUから加工できないので、頂点の位置を変えたい・色を変えたい等の操作はShaderを作成してGPUに任せるしかありませんでした。
より柔軟にモデルをレンダリングするため、VBOを使わずにレンダリングの度にCPUで都度加工したデータをGPUメモリに転送するという手段もありますが、転送には大きなコストが掛かります。
ハイポリの大きなデータであればVBOを使わずに処理するのは現実的ではないでしょう。

iOS端末におけるOpenGLESについても見てみたいと思います。
iOS端末のGPUメモリはハードウェアのスペースが限られているという事情も影響してか、PCのように物理的に切り離されておらず、メインメモリ上の一部を共有する形で実装されています。
せっかく共有されているのでCPUから直接アクセス出来ても良いように思えますが、上記の2)の事情はiOS端末においても同様であり、またOpenGLESはiOS端末以外のモバイルデバイスのサポートも考慮しなくてはならず、やはりOpenGLの仕様が踏襲された形で制限がかかったままとなっています。

一方、MetalはOpenGLESのようにApple以外のモバイルデバイスの事情を考慮する必要がなく、GPUメモリにCPUから直接アクセスできる仕様になっています。
上記2)についても心配はありません。
CPUがレンダリング命令をパイプラインに流すまではGPUが処理を開始することはなく、またGPUが非同期で処理を終えた際にコールバックがCPU側に返るようになっています。
よって、GPUがメモリにアクセスするタイミングは明白(命令発行〜コールバックの間)であり、その間はCPUからのメモリアクセスを控えれば2)の心配は無いのです。

このようにMetalはプログラマの責任において、CPUからもGPUからも同じメモリ領域にアクセスできます。
そのためVBOという概念もありません。
CPU側で共有メモリのポインタを取得することが出来てデータの書き換えが可能であるし、GPUへ命令を流す際に頂点バッファのアドレスとして同じポインタを指定します。

以上で述べたように、MetalはOpenGLES利用時のCPUとGPUの壁を壊したと言っても過言ではなく、大きなアドバンテージと考える事ができます。
CPU/GPU間でメモリが共有されれば3Dレンダリングの可能性が広がります。
Metalが登場するまでは難しかった以下の様なことが考えられるのではないでしょうか?
 A)GPUが忙しく働いていてCPUリソースに空きがあるような場合には仕事を分散することが出来る
 B)モデルの動的な編集・パーツの追加&削除
A)はXcodeでCPU/GPUそれぞれのパフォーマンスをチェックしつつ、GPUのタスクを減らしてCPUに任せるチューニング方法です。
シェーダを書き換えてメインプログラムを追記する必要があるのでなかなか大変ではありますが、チューニングの方法の一つとしては有効だと思います。
B)の方はアイディア次第で色々なことが実現できます。
成長してゆく植物や姿・形を変えるモンスターも表現できるでしょうし、破壊シミュレーションや流体の表現にも役立つかもしれません。
リアルタイムなプロシージャル技術で成形したモデルも本格的に使えそうです。

ゲーム開発のためのミドルウェアもMetalへの対応を進めているようですが、そういった対応を待つだけでなく直接触れてみると低レイヤー部分の事情を知ることができるのでなかなか楽しめます(^^)
2014年04月21日

スマホアプリと米国輸出規制に関するメモの続き

はてなブックマークに登録

前回の記事の続きです。今回は、前回の記事において米国商務省によるフローチャートで輸出規制への該非判定を行った iOS アプリ「stone for iOS」を App Store へ登録申請し、それが一度のリジェクトを経て公開されるまでの経緯を紹介します。

記事へ引用の原文および参考訳は 2014年4月7日時点のものです
※引用文中の赤字・強調表示は筆者によるものです。「:」は引用の中略を示します

許可例外「TSU」とは?

さて、暗号を使用するオープンソースの iOS アプリ「stone for iOS」は、ソースコードが「一般に入手可能(publicly available)」であることから 米国輸出管理規則上の許可例外のひとつである「TSU」の適用が可能で、その措置により商務省の輸出許可を得ることなく米国内の App Store からの輸出が可能であることがわかりました。

一連の許可例外は EAR Part 740 "License Exception"(参考訳:EAR Part 740 "許可例外")に定められています。「TSU」は「Technology and Software Unrestricted(規制されない技術及びソフトウェア)」の略です。前出のフローチャートの指示に添って §740.13(e) の内容を確認してみましょう。

原文:§740.13 Technology and Software Unrestricted (TSU)(以下抜粋)

§ 740.13 TECHNOLOGY AND SOFTWARE UNRESTRICTED (TSU) 
 
This license exception authorizes exports and reexports
of operation technology and software; sales technology
and software; software updates (bug fixes);“mass market”
software subject to the General Software Note; and
encryption source code (and corresponding object code) 
that would be considered publicly available under
§734.3(b)(3) of the EAR. 

                         :

(e) Publicly available encryption source code. 
 
 (1) Scope and eligibility.  Subject to the notification
     requirements of paragraph (e)(3) of this section, 
     this paragraph (e) authorizes exports and reexports
     of publicly available encryption source code
     classified under   ECCN 5D002 that is subject to
     the EAR (see §734.3(b)(3) of the EAR).   
     Such source code is eligible for License Exception
     TSU under this paragraph (e) even if it is subject
     to an express agreement for the payment of a licensing
     fee or royalty for commercial production or sale of
     any product developed using the source code.   
  
 (2) Restrictions.  This paragraph (e) does not authorize: 
 
  (i) Export or reexport of any encryption software
      classified under ECCN 5D002 that does not meet the
      requirements of paragraph (e)(1), even if the
      software incorporates or is specially designed to
      use other encryption software that meets the
      requirements of paragraph (e)(1) of this section; or

  (ii) Any knowing export or reexport to a country listed
       in Country Group E:1 in Supplement No. 1 to part 740
       of the EAR.   
 
 (3) Notification requirement. You must notify BIS and
     the ENC Encryption Request Coordinator via e-mail of
     the Internet location (e.g., URL or Internet address)
     of the publicly available encryption source code or
     provide each of them a copy of the publicly available 
     encryption source code. If you update or modify the
     source code, you must also provide additional copies
     to each of them each time the cryptographic 
     functionality of the source code is updated or modified.
     In addition, if you posted the source code on the
     Internet, you must notify BIS and the ENC Encryption
     Request Coordinator each time the Internet location is 
     changed, but you are not required to notify them of
     updates or modifications made to the encryption source
     code at the previously notified location. In all
     instances, submit the notification or copy to
     crypt@bis.doc.gov and to enc@nsa.gov. 

原文:EAR§734.3(b)(3) より
EAR Part 734 "Scope of the Export Administration Regulations"

                         :
  Publicly available encryption object code software
  classified under ECCN 5D002 is not subject to the EAR
  when the corresponding source code meets the criteria
  specified in §740.13(e) of the EAR.  

参考訳:§740.13 規制されない技術及びソフトウェア(TSU)(以下抜粋)

§740.13 規制されない技術及びソフトウェア(TSU) 

この許可例外は、使用に係る技術及びソフトウェア、販売に
係る技術及びソフトウェア、ソフトウェアのアップデート
(バグの修復) 、General Software Noteの対象となる
"マスマーケット"ソフトウェア、並びに暗号ソースコード
(及び対応するオブジェクトコード)であって、
EAR §734.3(b)(3)のもとに一般に入手可能とみなされるものの
輸出及び再輸出を是認するものである。 

                         :

(e) 一般に入手可能な暗号ソースコード 

 (1) 適用範囲及び適格性 
     本節の(e)(3)項の届出要求事項を条件として、
     この(e)項は、ECCN 5D002のもとに番号分類される一般に
     入手可能な暗号ソースコードであって、EARの対象となる
     ものの輸出及び再輸出を是認する (EAR§734.3(b)(3)を
     参照のこと)。このようなソースコードは、たとえ、
     そのソースコードを用いて開発される製品の商売を目的
     とする製造又は販売のためにライセンス料金又は
     ロイヤリティの支払いに関する明確な契約に従う場合で
     あっても、この(e)項のもとに許可例外 TSUが適用できる。 

 (2) 制限事項 
     この(e)項は、次の(i)又は(ii)については是認しない: 

   (i) (e)(1)項の要求事項を満たさない ECCN 5D002 の
       もとに番号分類される暗号ソフトウェアの輸出
       若しくは再輸出(たとえ、そのソフトウェアが
       本節の(e)(1)項の要求事項を満たす他の暗号ソフト
       ウェアを組み込んでいたり、他の暗号ソフトウェア
       を使用するために特別に設計したものであっても
       同様である);又は 

   (ii) EAR§740 Supplement No.1 のカントリーグループ
        E:1に掲載されている国に輸出若しくは再輸出する
        ことを知っている場合。 

  (3) 届出要求事項 
     あなたは、一般に入手可能な暗号ソースコードの
     インターネットロケーション(例えば、URL若しくは
     インターネットアドレス)を電子メールで BIS及び
     ENC暗号請求コーディネータに届け出るか、或いは一般に
     入手可能な暗号ソースコードのコピーを両者のそれぞれに
     提供しなければならない。あなたがソースコードを
     アップデートするか変更する場合、あなたは、当該ソース
     コードの暗号機能がアップデート又は変更されるたびに、
     両者のそれぞれに追加のコピーを同様に提供しなければ
     ならない。それに加えて、あなたがインターネットに
     ソースコードを掲示する場合、インターネットロケーション
     が変わるたびに、BIS及び ENC 暗号請求コーディネータに
     届け出なければならない、しかし、以前に届け出た
     ロケーションにある暗号ソースコードに対して行うアップ
     デート又は変更については、両者に届け出る必要はない。
     すべての場合において、届出又はコピーを crypt@bis.doc.gov
     及び enc@nsa.govに提出しなさい。 

参考訳:EAR§734.3(b)(3) より
EAR Part 734 "EARの管轄範囲"

                         :
 ECCN 5D002 のもとに番号分類される一般に入手可能な暗号
 オブジェクトコードソフトウェアは、対応するソースコードが
 EAR§740.13(e)で指定される基準を満たしている場合、EARの
 対象とならない。

「ソースコードを一般に入手可能な暗号ソフトウェアとその実行形式は、当該ソースコードのインターネットロケーションを電子メールで当局へ届け出れば輸出規制対象にならない」ということですね。なお、§740.13(e)(2)(ii) に言及のある「カントリーグループ E:1」は米国政府指定の「テロ支援国家」であり、これらの国から App Store を利用することはできません。

暗号処理を内蔵・使用していても米国当局に対しメールでの届け出を行うだけで許可例外 TSU を適用できることはオープンソースソフトウェアの強みのひとつと言えるかもしれません。では、具体的にはどのようなメールを送ればいいのでしょう?

TSU NOTIFICATION メールの書き方と送り方

以前は米国商務省(BIS)のサイトに「Notification Requirements for "Publicly Available" Encryption Source Code("一般に入手可能な" 暗号ソースコードの届出要求事項)」という記事があり、そこにオープンソース暗号ソフトウェアのソースの場所を当局へ届け出るための要領が判りやすく説明されていたのですが、今回何年かぶりに上のリンクの URL へアクセスしてみるとご覧の通り「404 File Not Found」でした。また、サイト内をざっと検索したところでは新しい記事は見当たりませんでした。

上の記事が削除された理由は判然としませんが(事情をご存知の方はお知らせ下さい)、内容は規則の一部ではなく届け出の要領の説明であり、別の記事を手早く見つけることができない以上、仮に多少旧くなっていたとしても届出義務そのものを果たすためにそこでの説明に準じることは当事者としての善意に基づく自然な判断と言えるでしょう。web.archive.org に残っている 2012-01-31 付の最後のキャッシュへのリンクを以下に掲載します。

http://web.archive.org/web/20120131171318/http://www.bis.doc.gov/encryption/pubavailencsourcecodenofify.html

(上の記事の全文)

参考訳(筆者)

"一般に入手可能な" 暗号ソースコードの届出要求事項

このページ上のEARの引用箇所は、Government Printing Office の
Webサイトの「December 9, 2004 Encryption Rule」で見つけること
ができます

ステップ1:輸出管理規則(EAR)の関連部分を読む

このガイダンスは、許可例外TSUのもとで、一般に入手可能
(EARセクション734.3(b)(3) 参照)とみなされる暗号ソース
コードを輸出を進行する前の注意事項を提供するために設計
されており、輸出管理規則 (EAR) の関連箇所と組み合わせて
使用されるべきです。

EARのセクション740.13 (e)は、許可例外TSUを使用して
"一般に入手可能な"暗号ソースコードを輸出する際の主要な
規制基準です。このセクションでは、ECCN 5D002 で規制
されており、また、EAR セクション 734.3(b)(3) で一般に
入手可能とみなされる暗号化ソースコードの輸出(例えば 
インターネットへのポスト)と再輸出のための届出について
説明します。こういった暗号化ソースコード(および対応
するオブジェクトコード、供給されたオブジェクトコードも
また一般に入手可能とみなされます)は、BIS(および
ENC Encryption Request Coordinator)へインターネット
ロケーション(例:URL または インターネットアドレス)
または輸出時点のソースコードのコピーを届け出ることで、
審査なしに輸出・再輸出されることがあります。

一般に入手可能とみなされる暗号化ソースコードは、たとえ
それが商業生産やそのソースコードを使って開発された製品の
販売へのライセンス料やロイヤリティの明示的な同意を受ける
場合においても、許可例外TSUのこの規定の対象となります。
そうしたソースコードをコンパイルした結果の対応する
オブジェクトコードも、それがまた一般に入手可能とされて
いれば許可例外TSUの対象となります。
たとえ一般に入手可能とみなされる暗号ソフトウェアに
組み込まれていたりそれを使うことに特化されていても、
一般に入手可能とはみなされない ECCN 5D002規制下の
暗号ソフトウェアは、許可例外TSUのこの条項
(セクション740.13(e))のもとに輸出や再輸出の対象とは
なりません。

ステップ2:URLロケーション(またはソースコードのコピー)の
           届け出を BIS および ENC Encryption Request
           Coordinator へ提出

あなたは、輸出の時点でソースコードのインターネット
ロケーション(例:URL またはインターネットアドレス)
(またはソースコードのコピー)の記された届出を BIS へ
提供しなければなりません。届け出を E-Mail で BIS へ提出し 
ENC Encryption Request Coordinator へ写しを送ってください。

[注:この段落内のリンクは、自動的に両方の電子メールを
 生成します]
また、このガイダンスのページの末尾に記載されている
アドレスにメールで届け出を提出することができます。

BIS と ENC Encryption Request Coodinator の両方へ
E-Mail で届け出のための書式指定:

あなたの電子メールの件名に、次のように入力します。
"TSU NOTIFICATION"
[注:上記の電子メールのいずれかのリンクをクリックする場合、
これは既に実行されています。]

メールの本文に、次の情報を入力します。

SUBMISSION TYPE: "TSU"と入力
SUBMITTED BY:
SUBMITTED FOR: (暗号品目を輸出する会社または個人の名前)
POINT OF CONTACT:
PHONE and/or FAX:
MANUFACTURER: (該当する場合)
PRODUCT NAME/MODEL #:
ECCN: 5D002

NOTIFICATION:ソースコードのURLまたはインターネットアドレス、
              または他のソースコードのコピーを提供する

FAXまたは手紙による通知による代替の書式の指定:
(以下略)

「stone for iOS」のソースコードを GitHub のリポジトリへコミットした後で以下の内容でメールを送りました。これでこのソフトウェアに許可例外 TSU を適用するために必要な届出要件は満たされました。ちなみにこれは「申請」ではなく「届出」なので送付先からのレスポンスはありません。

From: Tanabe, Makoto
Sent: Thursday, March 13, 2014 3:09 PM
To: crypt@bis.doc.gov; enc@nsa.gov; web_site@bis.doc.gov
Cc: 'Tanabe, Makoto (KLab Inc.)'
Subject: TSU NOTIFICATION - Encryption


SUBMISSION TYPE: TSU
SUBMITTED BY: Tanabe, Makoto
SUBMITTED FOR: KLab Inc.
POINT OF CONTACT: K-Laboratory, KLab Inc.
FAX: +81-3-▒░░▒-▒░░▒
MANUFACTURER(S): The OpenSSL Project
PRODUCT NAME/MODEL #: stone for iOS
ECCN: 5D002

NOTIFICATION:https://www.openssl.org/source/ (OpenSSL)
NOTIFICATION:https://github.com/mkttanabe/stone-for-iOS (stone for iOS)
NOTIFICATION:http://sourceforge.jp/cvs/view/stone/stone/ (stone)

'stone for iOS' is an iOS application.
'stone for iOS' is an open source software.
'stone for iOS' is a GUI version of the open source packet repeater 'stone'.
'stone for iOS' is static linked with the OpenSSL Library. 
'stone for iOS' uses the OpenSSL functions.

App Store への登録申請

以上の手続きで「輸出」を行う準備が整いました。いよいよ「stone for iOS」を App Store へ登録申請します。アプリケーションの説明欄には以下のように簡単にアプリの内容と OpenSSL に関する表記、ソースコードの URL を書きました。

一連のメタデータの記入を終えたあとで「Ready to Upload Binary」ボタンを押下し Export Compliance の確認画面へ移行します。

上の設問の参考訳(筆者)

Export Compliance

あなたのアプリは暗号技術を使用するように設計されているか、あるいは暗号技術を含んだり組み込んでいますか?(たとえあなたのアプリが iOS や OS X で利用可能な暗号化のみを利用していても Yes を選んで下さい)

あなたのアプリは米国輸出管理規則のカテゴリ 5, パート 2 で規定されたいずれかの適用除外の資格がありますか?

あなたのアプリがここにリストされている適用除外の基準に適合していることを確認してください。 あなたはあなたのプロダクトの適切な分類に責任があります。あなたのアプリの不正確な分類は 米国輸出法違反につながる可能性があり、あなたのアプリが App Store から削除されることを含め あなたを処罰の対象と成し得ます。質問に答える前に十分に FAQ を読んで下さい。

もしあなたのアプリの暗号化が次のいずれかであれば、あなたは 質問 #2 に Yes を選択できます:
(a) 医療のエンドユースのために特別に設計されている
(b) 知的所有権と著作権 の保護に限定されている
(c) 認証、デジタル署名、またはファイルのデータの復号 に限定されている
(d) 銀行業務または"金銭取引" のために限定され特別に設計されている;または
(e) "固定式" のデータ圧縮または符号化技術 に限定されている

あなたのアプリが米国輸出管理規則のカテゴリ 5, パート 2 の注 4 に規定された記述に適合している場合にもあなたは Yes を選択できます。

適用除外に関するその他のガイダンスについては FAQ を参照してください。

※サインインの必要なページなので引用をさし控えますが、iTunes Connect の FAQ > Export Compliance はわかりやすく書かれた良い記事です

最初の質問の「Yes」をチェックすると表示されるふたつめの質問 は、前回の記事で何度も見てきた米国商務省規制リストの「カテゴリ 5 パート 2」参考訳)の規定により当該アプリが規制の対象外となるか否かを問うものですね。
カテゴリ 5 パート 2 の ECCN 5D002 のエントリより、オープンソースの暗号ソフトウェアを規制対象外と規定している箇所の原文と参考訳の抜粋を以下に示します。

5D002 “Software” as follows
       (see List of Items Controlled)

              :

Note: Encryption source code classified under this entry
remains subject to the EAR even when made publicly
available in accordance with part 734 of the EAR. 
However, publicly available encryption object code
software classified under ECCN 5D002 is not subject to
the EAR when the corresponding source code meets the
criteria specified in §740.13(e), see also
§734.3(b)(3) of the EAR.

5D002  "ソフトウェア"であって、次のいずれかに
       該当するもの (規制品目リスト参照)

              :

注:このエントリーのもとに番号分類される暗号ソース
コードは、たとえ EAR§734により一般に入手可能にされたと
しても、依然として EAR の対象である。しかし、ECCN 5D002
のもとに番号分類される一般に入手可能な暗号オブジェクト
コードソフトウェアは、対応するソースコードが
EAR§740.13(e)で指定される基準を満たしている場合、EARの
対象とならない(EAR§734.3(b)(3)についても参照のこと) 。

このように、カテゴリ 5 パート 2 には、前出の §740.13(e) での基準を満たすオープンソースの暗号ソフトウェアを規制の対象外とすることが明確に規定されています。したがって、Export Compliance 確認での「あなたのアプリは米国輸出管理規則のカテゴリ 5, パート 2 で規定されたいずれかの適用除外の資格がありますか?」というふたつめの質問に対する「stone for iOS」のステータスは「Yes」です。

こうして質問への回答を終えアプリ本体のアップロードを完了しました。後は審査待ちです。

「stone for Android」での経験とふたつのアプリケーションストア

実のところ、ここまでのプロセスは先年 Android 用アプリとして Google Play ストアで公開した「stone for Android」でのケースとほとんど同じでした。同アプリもまたオープンソースソフトウェアです。iOS 版が OpenSSL ライブラリをスタティックリンクしているのに対し Android 版はシステムに含まれている OpenSSL の共有ライブラリをダイナミックリンクしているといった構成上の違いはあるものの、これまで見てきたように EAR は暗号処理の実体がどこにあっても暗号を使うソフトウェアを等しく「暗号ソフトウェア」として扱うため、米国から輸出を行う上でこの Android 版と今回の iOS 版に法律上の区別はありません。

また、前述のように App Store の Export Compliance 確認画面に「あなたはあなたのプロダクトの適切な分類に責任がある」と明記されているのと同様に、Google 陣営の [ support.google.com - Android デベロッパー > ヘルプ > 販売者のためのガイドライン > 輸出法の遵守 ] のページにも「コンプライアンス要件を判断するのはあくまでもデベロッパーの責任です」と記述されており、その部分についてはこのふたつのストアの基本的なスタンスは共通していると考えてよさそうです。

逆に、アプリケーション登録まわりでの両ストアの対応の大きな違いとしては、まず、App Store では登録時の Export Compliance の確認が複数の質問で念入りに行われその過程で対応指針の指示までもが行われるのに対し、Google Play では「当該アプリは米国の輸出法を遵守している」旨の宣言文に添えられたチェックボックスのクリックひとつで完了する(※)点と、広く知られているように App Store ではアプリの事前審査を専任のスタッフが実施しているのに対し、Google Play では自動化されたシステムが処理している(※)点のふたつが挙げられるでしょう。 (※2014年4月時点)

いずれにせよどちらも同じ米国内に拠点を置くメジャーなアプリケーションストアであることは共通しているわけで、数年前に Android 版を何事もなくリリースした背景もあり、同様の対応を行った今回の iOS 版についてもコンプライアンス面での不安はあまり感じていませんでした。ところが・・・

リジェクトされました (^^;

申請から一週間ほど経ったところで App Store からメールが届きました。思惑とは裏腹にリジェクトされたようです。あれれと思いながら詳細を iTunes Connect の Resolution Center で確認しました。次の内容です。

Reasons

Program License Agreement

----- PLA 2.3 -----


We found that your Application Description states:

"This product includes cryptographic software..."

However, your app does not have Export Compliance, which does not comply with the iOS Developer Program License Agreement, as required by the App Store Review Guidelines.

Section 2.3 of the iOS Developer Program License Agreement specifies,

"You certify that (i) none of the Licensed Applications contains, uses or supports any data encryption or cryptographic functions; or (ii) in the event that any Licensed Application contains, uses or supports any such data encryption or cryptographic functionality, You will, upon request, provide Apple with a PDF copy of Your Encryption Registration Number (ERN), or export classification ruling (CCATS) issued by the United States Commerce Department, Bureau of Industry and Security and PDF copies of appropriate authorizations from other countries that mandate import authorizations for that Licensed Application, as required."

Please review your app's encryption ability, and when resubmitting your binary, check the appropriate answers to the questions in the Export Compliance section of iTunes Connect. You may be asked some follow-on questions to determine the level of encryption in your app; you may also be asked to provide a copy of your CCATS.

If you have questions related to export compliance and your app's use of encryption, please contact the App Store Export Compliance team at ▒░░▒░▒░@apple.com.
ざっくり要約すると、「アプリの説明に "This product includes cryptographic software..." とあるが、あなたのアプリには米国商務省から発行された暗号登録番号(ERN)や製品分類自動追跡システム番号(CCATS)の PDF コピーが添えられておらず iOS Developer Program License Agreement に準拠していない。コンプライアンスの不備である。Export Compliance の質問へ適切に回答し対処して下さい」という内容です。しばらく考えました。

そもそも App Store の拠点は米国内にあり、それ故にそこから製品を配布したければ米国法に従う必要があるわけですが、その一方で当の App Store 自体もまた米国法に準じての運営が前提であるはずです。これまでの話題の通り、EAR は決して「暗号ソフトウェア」のすべてを規制しているわけではありません。したがって、「cryptographic software」の文言が説明文に含まれているからと言ってそのアプリが常に「カテゴリ 5 パート 2」での規制対象に該当するとみなすことは法に照らして適切とは言えませんし、ただちに ERN や CCATS の提示ばかりを求めるのもいささか短絡的でしょう。この指摘にはそういう違和感がありました。

なお、"This product includes cryptographic software..." のくだりは OpenSSL ライセンス中のテキストです。あらためて同ライセンスを確認してみると、こういった場所への記載を求められているのは "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)" の一文のみのようです。そのためこのテキストを外すことは簡単ですが、仮にその即物的な編集を行った結果審査を通ったとしてもそれは本質的な解決ではありません。暗号処理を使いながらも当該ソフトウェアが法規制の対象外となる条件を満たしていることを確認ずみである以上、本来であれば暗号を使っていることを真正面から記述しても何の問題もないはずです。

先方からの連絡には「the App Store Export Compliance team」の紹介もありますが、ここはまず自分の頭で考えることにしました。今回の件の輪郭をなぞると、ストア側がアプリの審査において Export Compliance 確認への回答内容よりも「アプリの説明」の内容に注目した構図が浮き上がります。ということは、その状況に対して効果のあるアプローチは、「アプリの説明」においてこのアプリが米国法に適切に対応していることを積極的に主張することではないかと考えました。

説明文の変更〜再申請

そんなわけで、アプリケーションの説明文に「このソフトウェアは暗号を使っているが米国輸出法上の "規制されない技術及びソフトウェア" に該当するものであり法に従って配布している」という旨を明記することにしました。

当初その文章をゼロから作りかけていたのですが、ふと、法や規則への言及を含むこういった文章にはたいてい定型的なパターンがあることを思い出しました。身近なところではソフトウェアの使用許諾契約書の文章などがそうですね。この手の定型的な文章には多くの場合先人の知恵と経験知が凝縮されていることに加え表現そのものに対する社会的な認知度が概して高い側面があるため適切に使えばあえて自分ではじめから作文をするよりも効果的でしょう。

ネットを探索し、所定のソフトウェアが TSU であることを表明する目的のために The Apache Software Foundation をはじめ複数のソフトウェアベンダが使用している定型的な表現の存在を知りました。その内容を確認して手を加え、最終的に説明文を次の内容に変更して再び App Store への登録申請を行いました。なお、Export Compliance の確認には迷いなく初回と同様に「Yes - Yes」と回答しました。

(「* Cryptographic Software Notice *」以降の参考訳)

* 暗号ソフトウェアに関する注意 *

このソフトウェアは暗号ソフトウェアを含んでいます。あなたが現在住んでいる国は暗号ソフトウェアの輸入、所持、使用、および/または他国への再輸出 に制限があるかもしれません。いかなる暗号ソフトウェアも使用する前に、許可されているかどうかを確かめるために、暗号ソフトウェアの 輸入、所持、または使用、そして再輸出に関するあなたの国の法律、規則および政策をご確認下さい。詳細は http://www.wassenaar.org/ を参照して下さい。

アメリカ合衆国商務省産業安全保障局 (BIS) はこのソフトウェアを、非対称アルゴリズムで暗号機能を使用または実行する情報セキュリティソフトウェア を含む 輸出規制分類番号 (ECCN) 5D002.C.1 として分類しました。この配布の形式と作法は オブジェクトコードとソースコードの両方に許可例外 Technology Software Unrestricted (TSU) のもとでの輸出のための資格を与えています。(BIS 輸出管理規則のセクション 740.13 を参照して下さい)

このソフトウェアは無料で配布され 全体のソースコードは以下のように一般に入手可能です:
- stone for iOS (オリジナルの 'stone' を含む)
https://github.com/mkttanabe/stone-for-iOS
- OpenSSL
https://www.openssl.org/source/

※「ECCN 5D002.C.1」の詳細は前回の記事の「『ECCN 5D002』とは」の項を参照して下さい

結果と所感

後日再びストア側のレビューが実施され、今回は何事もなく審査を通過し App Store へ「stone for iOS」が掲載されました。リジェクト時にストア側から連絡された内容には従わなかったものの結局こちらの判断は間違っていなかったようです。App Store へ暗号を使うアプリを登録したのはこれが初めてでしたが、今回のような経緯でリジェクトされたことは良い経験でした。前述のとおり同じアプリであるにも関わらず Google Play ストアの場合にはコンプライアンスまわりが自己申告のみで通ったことを考え合わせると両ストアの個性の違いが興味深く感じられます。

このふたつのアプリケーションストアに閉じた話題に留まらず、今回の経験からあらためて教訓にしたいと思ったのは、何かを公にする場合にはその行為やその内容が所定のルールを適切に遵守しているという正当性を積極的にアピールすべきだということです。そういった表示や宣言を行うことがルールで義務づけられている場合にはもちろんのこと、そうでない場合や事情が判然としない場合にも、殊に文化・習慣の土壌の異なる環境においては何らかの形で主体的に表明を行う判断が安全でしょう。App Store にしても今回のように暗号を使用しながらも規制対象外であるアプリの申請方法を明示しているわけではありませんが、そのことが「説明を必要としない」という意味ではなかったことはここに書いた通りです。ひとことで言えば、ルールを適切に守ることと同様に、それを適切に伝えることもまた自分にとっても他者にとっても重要だということに他ならないと思います。つまるところルールを間に挟んだ両側にいるのはどちらも「人間」なのですよね。


二度に渡り記事の前半では主に米国輸出管理規則の概要と読み方や扱い方、後半では実在のスマホアプリへ許可例外を適用し App Store で公開するまでの具体的な話題を中心に紹介しました。TSU 以外の様々な許可例外を適用するケースや米国商務省への申請が必要となるケースなど実務上のバリエーションは多岐に渡りますが、まずはこの記事が EAR と米国のアプリケーションストアに向き合いながら対応を行う上での参考情報のひとつとなれば何より幸いです。

前回の記事へ

(tanabe)
klab_gijutsu2 at 08:30|この記事のURLComments(0)TrackBack(0)
2014年04月09日

スマホアプリと米国輸出規制に関するメモ

はてなブックマークに登録

※2014-04-21 追記:続きの記事を公開しました
「スマホアプリと米国輸出規制に関するメモの続き 」へ

記事の概要

スマートフォンの普及に伴いそれをターゲットとするソフトウェアベンダや開発者が増えています。スマートフォン向けのアプリケーションを公開する際には通常 Google Play や App Store 等のアプリケーションストアを使用しますが、これらのストアの拠点は米国にあるためそこでアプリを配布することは米国からの輸出に該当し 同国の輸出法の適用対象となることに注意が必要です。

米国の輸出規制の内容は EAR (Export Administration Regulations 輸出管理規則) に定められており、規制に該当するか否かは「何」を「どこへ」輸出しそれを「誰」が「何のため」に使用するかによって決まります。規制対象にあたる輸出を行う際には米国商務省へ申請を行い有効期限を伴う 輸出許可(Export License)を得なければならないケースもありますが、EAR にはある品目の輸出が規制の対象外となるケースや 所定の条件のもとに許可不要となる 許可例外(License Exception)について個別の規定があり、実際には案件の多くにそのいずれかを適用できるようになっています。ただし、その判断と対応を適切に行うためには関連する規則を適切に読み解くことが必要となります。

ソフトウェアに関しては、EAR は「一般に入手可能な技術及びソフトウェア」を輸出規制の対象外とする一方で 暗号処理を包含または使用するソフトウェア(「暗号ソフトウェア」)については規制対象として詳細な規則を設けています。暗号品目に関する規制内容は EAR の「商務省規制品リスト」の中の「カテゴリ 5 パート 2」同参考訳)に定められています。

先日、手元で開発した iOS 用のアプリ「stone for iOS」を App Store で公開しました。このアプリは OpenSSL ライブラリをスタティックリンクしそこに含まれる暗号関数を使用しています。そのため EAR の規制対象にあたりますが、許可例外のひとつである「規制されない技術及びソフトウェア」(=「TSU」)に該当する要件をあらかじめ備えていたため米国からの輸出に際し要した手続きはわずかなものでした。そういった具体的な事例の情報はあまり見かけないため、この記事では関連する規則の説明とともに今回のケースにおいて手元で行った対応内容を紹介します。筆者は取り立てて法律に詳しいわけではなく単に自分の手がけたソフトウェアを公開するために必要な実務上の手続きの一環として所定の規則を読みかじっているに過ぎませんが、情報のひとつとして、特にオープンソースソフトウェア開発者の方のご参考となれば幸いです。

なお、EAR は暗号処理を本体に含むか否かにかかわらず暗号を使用する品目全般を対象としています。ソフトウェアの場合だと OS 組み込みの暗号機能のみを使っているソフトウェアも原則的に規制の対象となります。記事ではその話題にも触れてみることにします。

資料

米国輸出規制に関する資料へのリンクです。 続きを読む

klab_gijutsu2 at 10:09|この記事のURLComments(0)TrackBack(0)
2014年03月25日

「stone for iOS」について

はてなブックマークに登録

オープンソースの多機能パケットリピータ「stone」は数多くの OS プラットフォームで利用されています。スマートフォンまわりでは先年手元で Android 環境向けのポーティングを行いましたが、このところ iPhone を使う機会が増えていることもあり iOS 環境でも動かしたいと考えました。iOS 用 GUI アプリとしてひと通り動作するようになったため次の場所で公開しています。興味のある方はお試し下さい。

iTunes App Store - stone for iOS
ソースコード: GitHub - stone for iOS

使い方

アプリの使い方を簡単に説明します。

メイン画面


画面最上部のコマンドフィールドに stone パラメータを記述します。パラメータの記述方法は「stone の README」を参照して下さい。

各ボタンの機能

  • [Run] - stone の処理を開始します
  • [Stop] - 本アプリケーションを終了します
  • [Clear] - 表示中のログを消去します
  • [History] - コマンド履歴を表示します
  • ツールボタン - ツールメニューを表示します

"-dd www.gcd.org:80 1234"
初期状態でコマンドフィールドに表示されている上記のパラメータは stone の効果を確認するためのサンプルです。[Run] で stone の処理を開始し、ブラウザから
http://[この端末の IP アドレス]:1234/
へアクセスすると http://www.gcd.org/ (stone 公式サイト)へ繋がります。

コマンド履歴画面


stone で実行したコマンドパラメータの履歴です。タップするとメイン画面のコマンドフィールドへペーストされます。「編集」ボタンからエントリの削除・並べ替えができます。

ツールメニュー


各種設定やヘルプを表示します。詳細は各画面をご覧下さい。

ローカルファイルの保存

".stone" の拡張子が付与された任意のファイルをメーラ等のアプリケーション上でタップすると、そのファイルを本アプリケーションのローカルファイルとしてコピーすることができます。保存ずみのローカルファイルは stone パラメータへの指定が可能です。
(例)"-C stone.cnf"

※現バージョンの stone for iOS は、iOS キーチェーンへの電子証明書のインポートおよび参照には未対応です。証明書はローカルファイルとして保存した上で使用して下さい。

謝辞

本ソフトウェアは以下のオープンソースソフトウェア資産を使用しています。素晴らしいソフトウェアを公開されている各氏に深謝いたします。

stone

Copyright (c) 1995-2014 by Hiroaki Sengoku

「この stone に関する全ての著作権は、原著作者である仙石浩明が所有します。この stone は、GNU General Public License (GPL) に準ずるフリーソフトウェアです。個人的に使用する場合は、改変・複製に制限はありません。配布する場合は GPL に従って下さい。また、openssl とリンクして使用することを許可します。」
「この stone は無保証です。この stone を使って生じたいかなる損害に対しても、原著作者は責任を負いません。詳しくは GPL を参照して下さい。」

stone 公式サイト

OpenSSL

Copyright (c) 1998-2011 The OpenSSL Project. All rights reserved.

"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
"THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."
"This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com)."

OpenSSL 公式サイト

(tanabe)
* Cryptographic Software Notice *

This software includes cryptographic software. The country in which you currently reside may have restrictions on the import, possession, use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check your country's laws, regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted. See http://www.wassenaar.org/ for more information.

The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), has classified this software as Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic functions with asymmetric algorithms. The form and manner of this distribution makes it eligible for export under the License Exception Technology Software Unrestricted (TSU) for both object code and source code. (see the BIS Export Administration Regulations, Section 740.13)

klab_gijutsu2 at 15:02|この記事のURLComments(0)TrackBack(0)
Blog内検索
Archives
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント