A.トフラー氏の『富の未来』によれば、様々な社会経済システムの中で、法律の進化がダントツで遅いという。制度の変化が一番速いのが企業。以降、社会団体、家族、官僚機構、教育、国際機関、政治、と続く中で、際立って遅いスピード最下位は「法律」ということである。
しかし、それでは困る事情が頻発している。IT、特に使いやすくなったWebを象徴するWeb
2.0の世界では、データ、著作物、ソフトウェア機能の利用や共有が進み、様々な新しい利用形態が次々と毎月のように出現している。この現状で、法的な仕組みの活用環境が旧態依然としたままでは困る。Webについていえば、例えば次のような素朴な疑問についても諸国の法制度が必ずしも明解な回答を与えているわけではない：
・リンクを付けるのに事前許諾はいるのか
・URLを１行書いただけのものも著作権法上の「引用」なのか
・自頁の内部に一体化してはめ込まれてはいるが所有権をもたない動的コンテンツ（リンク後に内容が更新）に問題があった場合に何らかの法に抵触するのか
これらの事態は、非常に頻繁に起きているにも関わらず、法的解釈は定まらず、揺れているのが現状のようである。
さらに、異なる関連法をもつ国々の国境を超えたリンクや連携をどうしたら良いかという問題がある。100以上の異なる国に対して瞬時にコンテンツやサービスを公開できるインターネットの進化はこれまで以上に加速しつつある。このため、その技術やビジネスモデルの現状と法的仕組みを多国籍環境で調停する効率的な方法を編み出していくことも急務である。法律の活用も低コストでスピーディにできるようになって欲しいわけである。
ビジネスになる部分では、著作権活用の仕組みが急速に進化している面もある。例えば、JASRAC
によれば、「着うた」等、インタラクティブ配信市場の急拡大に伴い、配信スタイルに応じた新しい課金システムの登場しているという。2005年度の商用配信の市場は約92億円で、サービスの総数は約5,700本。うち、着うた着メロ系のサービスは約4,700本である。今後はApple社のiTunes
Music Storeに代表される本格的な音楽配信、映像配信が急増するとみられている。
音楽配信については、従来の 「曲数×情報料単価」という価格モデルに対し、次のような新たな課金モデルが現れ、急速に一般化してきている。
・有期限ダウンロード、ポッドキャスティング:収入源と有効期間による課金
例： 再生期限のあるダウンロードで音楽が主たる目的、複製不可の場合
収入なし 1曲 7日3.5円
30日4.5円
広告収入のみ 1曲
7日3.85円
30日5円
情報料あり 1曲 7日4.5円or情報料の4.5% 30日5.6円or5.6%の多い方
・インターネットCM：リクエスト数別もしくは媒体費総額×料率
例：CMコンテンツをストリーム/ダウンロード配信し広告主（or代理店）が支払う場合
媒体費単価あり：月ごとの 「媒体費単価×５％×リクエスト数」 or 5,000円 の多い方
媒体費単価なし：月ごとの 「媒体費総額×７％」 or 5,000円 の多い方
この仕組みを成り立たさせるため、従来の警察機構に成り代わって、JASRACがJ-MUSEという名のWebロボットを使って、違法なファイルを監視、パトロールしている。これは、インターネット上を自動巡回して著作権を侵害している音楽データを探索するWebロボットである。例えば、著作権のある歌詞を掲載したサイトを発見した場合、次の手順で迅速に問題解決を行う。
step-1. 当該サイトにおける個々の侵害ファイルを特定し確認
step-2. サイト運営者に警告
step-3. ISPへ連絡
step-4. （通常の場合）ISPは<a
href="http://www.isplaw.jp/">「プロバイダ責任制限法」</a>に基づいて違法音楽ファイルを削除
この新しい仕組みにより2002/10〜2006/7 の間で約20万ファイルが処理されている。もし仮に、旧来の警察機構、司法機構に頼るだけだったとすれば、処理のスピードや、網羅性が、違反の発生に全く追いつかなかった可能性が高い。そうなれば、新しい課金モデルが市場に定着せず、配信ビジネスの健全な市場が形成されなかったであろう。
さて、本節のテーマであるマッシュアップについては、どうしたら良いだろうか。まず、マッシュアップアプリを作って公開したいアプリ作成者の立場で考えてみよう。現状は、自身、自社のオリジナル素材以外の素材（さにその素材（WebAPI等）が呼び出すその元となった素材）の利用許諾契約書を全部読んでマッシュアップの可否やその利用条件等について理解しないといけない。利用許諾契約書は法律文章であり、母国語であっても解読困難である。また、意味を理解できた、と思っても、法律家に特有の法的解釈を施さないと大きく誤解してしまうことがあり、危険である。逆に、そこで言及されている新しい技術的概念は法律の専門家には理解困難なことが多く、タイムリーにその全貌を把握するのは難しい。
さらに、個々の素材の利用許諾条件ばかりでなく、他の素材と組み合わさった場合や、その素材が別の素材からできている際に引き継がれる条件、引き継がれない条件についても熟考、吟味しなければならない可能性が十分ある。現実的にはもっとまずい事態もある。例えば、散々苦労して解釈した利用許諾書が眼前のサービスにどう見ても合わないようなとき、実はその条文は古いパッケージソフトウェアのためのものを延々と何１０年も引き写しし続けていて、提供者側が実質的に読んでもいなかったということもあり得るのだ。そのような不適切な利用許諾を長時間かけて解読する不毛な時間を費やしている間に、技術的理由、コンテンツや美的デザインの優劣などの理由で、あっさりと別の素材の採用に隣席の同僚が踏み切っていたりしたら悲惨である。
既にGoogleのパーソナライズドHome Pageなどに具現化した次世代のオフィスワーカーの端末には、自分の今週のStartPage上に数１０のWebAPI部品がのっている。その多くはニュース配信などの複合コンテンツで、部品のそのまた部品の原著作者が存在する。その全体を誰か別の人に利用してもらおうと思ったら、上述のように、原理的には、末広がりにつながったこれらの全著作権者との間で、１つ１つ異なる利用許諾契約書を締結する、ということになる。
これを、数年間かけて、地道にこつこつとやる方法もないではないだろう。しかし、2007年になって、現実に見え始めたニーズとは、例えば、次のようなものである：
・隣の席に座っている派遣社員さんに自分の端末上の「本日のマッシュアップ状態」の作業環境の利用許諾を与える
・１分後に利用開始してもらって１０分後に分析結果を意見、コメント付きで出してもらう
・そのシステムの利用が円満に終了
・翌日にはもうそのシステム（「前日のマッシュアップ状態」の作業環境）は寿命を終え、廃棄されている
この９分間の利用に本来必要だったからといって、１０数頁の利用許諾契約書を数百本作成して双方の会社の顧問弁護士の間で交渉、調整を行って調印にこぎ着ける、というのが法律の定めだ、と言われても、その実施、運用は事実上不可能であろう。２者間契約で済めばまだ良い方である。
「え？あのG****APIと並べて使われるの？それは困る」とか、
「え？あのY****APIから自動生成されたデータをうちのAPIの隠し機能の入力に流し込むわけ？
Y****Pipesを使って？そんな前例の無い利用形態なら北米本社に持ち帰って検討しなければならないので３ヶ月お待ちください」などの状況を想定すれば、果たして「本日のマッシュアップ状態」の作業環境が法的にオーソライズされる日なんて永遠に来ないかもしれない、とさえ思える。このように、従来の法制度を厳格に運用した場合、前述の「数年かけて」は決して大げさな表現とはいえないのではなかろうか。
本稿では、Web2.0に特徴的なマッシュアップをエンタープライズ向けに実現する際にネックの１つとなる、利用許諾条件のチェック、相性の確認を[半]自動化して高速化し、多数の素材の中から、適切なものを現実的な時間コストで選ぶためにCreative
Commonsの法的メタデータの活用を提案する。なお、法的条件は、必要条件としてはたらいてしまうため、コンテンツの質や量、機能の出来やセンスの面で妥協しながらマッシュアップする、という状況も今後は予想される。個人向けサービスは鮮度の高さが勝負かもしれない。しかし、エンタープライズマッシュアップでは、理想には遠い第二候補のサービスを採用したり、あるいは、本命のサービスが落ちているときの代打サービスをも用意する、といったことが日常的になるかもしれない。
前述の問題を解決するためには、各素材の利用許諾表示が、
・シンプルで把握しやすく、迅速に理解できる
・記述方法や組み合わせ規則が統一されているため比較や整合性チェックが容易、
・古い記述が混入したりしにくく、正確に最新の利用条件が表示されているようにしやすい、そして何より、
・ソフトウェアによる自動処理が可能
という条件が満たされることが望ましい。
我々は、既に一定の実績のあるクリエイティブ・コモンズ(CC)の道具立てを活用することで、これらの条件をすべてクリアできる可能性に気づいた。クリエイティブ・コモンズ(CC)は、2002.12.15に誕生して以来４年が経過し、全世界で推計１億５千万程度のオンラインリソースに付与されている著作権表示の仕組みである。元々は、クリエータの著作物が、そのクリエータの意思を反映して流通していくように、と願って作られたものである。高城剛氏の「作者本人がコピー・フリーを望むならそれが可能なように著作権法を改めるべし」という考え方と整合している。
http://itpro.nikkeibp.co.jp/article/Watcher/20060810/245622/
「コモンズ」という概念は全くの公共の場と、１者に私有された場の中間の領域を指す。「共有地」という訳語ではかえってわかりにくいが、権利関係として全くのパブリックドメインのものと、１者が１００％権利を占有した状態の中間と捉えると理解しやすい。
１．全ての権利を留保する“All Rights Reserved”
２．いわゆるパブリックドメイン、“No Rights Reserved”
３．両者の中間としての、“Some Rights Reserved”
パソコン通信黎明期の80年代後期に「パブリックドメインソフトウェア」（PDS)という言葉が初期の頃、一時的に使われたことを記憶している方は、その用語が忌避された理由もご記憶かもしれない。パブリックドメインとなると、著作物や発明などの知的創作物について、著作者や発明者などが排他的な権利（特に著作権）を一切主張できず、一般公衆に属する状態となる。これでは、たとえフリーウェアであっても責任をもってバージョン・アップすることすらできなくなる、という懸念から、シェアウェアも含めたオンラインソフトウェア（OLS：昨今のオンライン・サービスと違ってダウンロードして実行されるソフトウェアのこと）という名称に変更されたのである。
現状では、プレゼンテーション資料のフッター部分には“All Rights Reserved”と表示されているものが大多数であろう。しかし、全ての内容、表現を全くのゼロからオリジナルに作るなどということがあるだろうか。仮に少しでも似た絵柄や文章表現を回避し、図面の構成（例：ピラミッド階層の分類図）さえも全く独創的な表現として新規に「開発」したとしよう。それを見る者にとって、既知のものと見比べるアナロジーが働かず理解不能になってしまうのではなかろうか。学術論文やそのプレゼンテーション資料も９０％以上は既存の知識、先人の成果物から構成され、それに少々のオリジナル部分を継ぎ足したものだと言われる。実際その通りであるから理解可能となるのであろう（オリジナリティが無いのに理解困難な論文などは存在しなくてよろしい。本稿がそうならないことを祈る；笑）。
ソフトウェアやサービスを含めて、人間の知的所為による創造物の殆どは、膨大な先人のアイディアや表現や実体（ソースそのもの他）に少し独自のものを「マッシュアップしたもの」と考えれば、それについて、“Some Rights Reserved”と表示するのが適切だったのではないか。万国著作権条約の本来の精神も、著作物の利用（とくに創造者が先人の遺産を利用）して自身のオリジナリティを刺激し、新たな著作物を積み上げて拡大再生産するプロセスを加速させたい、というものであった。人類全体の幸福の総量を増加させる一手段として。マッシュアップと“Some Rights Reserved”は、この著作権法の目的、理念を忠実に、シンプルに言い表したものと言ってよいのではなかろうか。
クリエイティブ・コモンズ(CC)が共通化し、統一を提案する著作権表示は、４つの要素の組合せである（図１）。帰属 Attributionはいわゆる著作者名の表示であり、略称は"BY"。人が立っているようなシンプルなアイコンで視認性を高めている。非営利 Non-commercial (略称"NC") のフラグが立っていれば、「非商用目的に限り複製・頒布・表示・上演、派生物の作成を認める」ことを意味する。アイコンは国別に若干ローカライズされており、日本国著作権法に適合されたバージョンのクリエイティブ・コモンズ(CC)では、「￥」マークに禁止の意味で斜線を入れた、道路標識のようなアイコンが使われる。
派生禁止 No Derivative Works (略称は"ND")の場合、改変せずに配布せよ、利用せよ、という意味で、「＝」マークのアイコンを用いる。日本国著作権法の同一性保持権に対応するが、寧ろ注目すべきは、このフラグを立てないことで、自由な改変を奨励することができる点かもしれない。同一条件許諾 Share Alike(略称は"SA")のフラグが立っていれば、再配布する場合、この現在表示中のライセンスと同一のライセンスを維持した場合に限り派生物の頒布を認められる。
帰属 Attributionは省略不能とされており、また、"ND"と"SA"は組み合わせられないため、（たった）６種類で、主要な利用許諾条件をクリエイティブ・コモンズ(CC)は表現することができる。
このクリエイティブ・コモンズ(CC)に準拠した利用許諾条件には、大別して次の３種類がある。
（１）機械が読んで "理解"するための、<a
href="http://e-words.jp/w/RDF.html">
RDF形式</a>のコンピュータプログラム、ネットワークエージェントなどが
（２）一般人が一目で認識できる４種のアイコンと平易な日常語による自然文、そして、
（３）従来と同様の、法律家向けの利用ライセンス契約書の法律文章
自分のニーズに即してこれらの実例を見るには、クリエイティブ・コモンズ(CC)のサイトで実際に作成してみるのが早道である。
http://creativecommons.org/license/?lang=ja
図２に示すように、アンケート形式になっていて、質問に答えていくと、有り難いことにこれら３種類が生成され、出力される。
図３は、自動生成されたRDFの例である。XML言語の語彙としては、RDF, RDFS (RDF Schema) の他に、汎用メタデータのDC (Dublin
Core)、そして、名前空間xmlns="http://web.resource.org/cc/"
で示される、クリエイティブ・コモンズ(CC)独自の語彙を含む。具体的な条件は、License
要素の内部に記述されている。また、日本国著作権法に準拠した日本版のクリエイティブ・コモンズ(CC)であることは、
"http://creativecommons.org/licenses/by-nc-sa/2.1/jp/"
というURL指定で表示されている。
このRDFを用いて自動的に選別可能なオンライン・リソースは、2006年央の時点で、１億４千万あるという（『情報処理』2006.11月号）。身近なコンテンツの例としては、
WIRED CDの曲(コーネリアスも参加)
http://hotwired.goo.ne.jp/original/cornelius/
stop-rokkasho.orgの作品(坂本龍一も参加)
http://stop-rokkasho.org/
Google、Yahoo、Microsoft提携のウェブインデックスプロトコル「sitemaps」
http://www.sitemaps.org/
などがある。日本産のものはまだ少ない。しかし、携帯向けをはじめとするコンテンツ配信の先進的取り組みに、Web
2.0のユーザ参加が加わって、急速に浸透する可能性がある。従来の著作権管理団体が関与しないCGM(Consumer Generated Media)上のコンテンツを再利用したり、複合コンテンツをはじめとする２次著作物を安心して作成するには、エイティブ・コモンズ(CC)のような「軽い」仕組みが適しているとみられるからである。
上記クリエイティブ・コモンズ(CC)のサイトにいちいちアクセスして、１つ１つのリソースについて対話的にCCを付与する以外に、効率よくCCを付与するためのツールが公開されている。例えば、eMicrosoft
Office Excel 2003, PowerPoint 2003, Word 2003, Excel 2002, PowerPoint 2002,
Word 2002
のAdd-inとして動作し、これらの文書にCCを埋め込むことができるようである（筆者は未だにOffice2000を使い続けているため試すに至っていない）。
http://www.microsoft.com/downloads/details.aspx?FamilyId=113B53DD-1CC0-4FBE-9E1D-B91D07C76504&displaylang=en
大量のオンラインリソースにクリエイティブ・コモンズ(CC)の表示が付いたなら、すぐに検索、絞り込みの機能が必要となる。実は、既に、英語版のGoogle検索、Yahoo検索でクリエイティブ・コモンズ(CC)の条件を指定した検索が実現している。
--------
Googleでの検索方法
--------
「表示設定」から表示する言語を「英語」にして「保存」
→「Advanced Search」から「Usage Rights」をプルダウンで選択
プルダウンの選択肢がライセンス種別に対応、選択肢は以下
+ not filtered by license
ライセンスは関係ない検索を実施
+ free to use or share by
パブリックドメイン、by、sa、nc、ndのいずれかを含むものを検索
+ free to use or share, even commercially
パブリックドメイン、by、sa、ndのいずれかを含むものから
ncを除いたものを検索
+ free to use share or modify
パブリックドメイン、by、sa、ncのいずれかを含むものから
ndを除いたものを検索
+ free to use, share or modify, even commercially
パブリックドメイン、by、saのいずれかを含むものから
nc もしくは nd を除いたものを検索
プルダウンメニューからはsaに関する検索はできないが、URLにはsaに関する検索条件に相当する「sharealike」が存在するため、それを利用することはできる。
例:pd,by から
ncもしくはndもしくはsaを除いたものを検索するときのURLでのライセンス検索条件：
&as_rights=%28cc_publicdomain%7Ccc_attribute%29.-%28cc_noncommercial%7Ccc_nonderived%7Ccc_sharealike%29
--------
Yahooでの検索方法
--------
http://search.yahoo.com/cc
のフォーム直下にある、"Find content I can use for commercial purposes. ",
"Find content I can modify, adapt, or build upon. "
に適宜チェックを入れるかはずすかして検索する。ここで、Enter(Return)キーを押すと、CC付きのリソースを検索する、[Search
CC]ボタンを押したことになる。例えば、"メタデータ"とフォームに入力して、[Search
CC]ボタンを押すと、2007年４月12日現在、368件のヒットとなり、[Search the Web]ボタンを押すと、通常のYST (Yahoo
Search Technology)エンジンで検索したのと同じ、120万件のヒットとなった。
以上２つのCC付きのリソースを検索方法は、CC自身のサイトにマッシュアップされ、英語版のメニュー操作が面倒な人でも簡単に検索オプションやボタン、フォームに辿り着けるようになっている：
http://www.creativecommons.jp/find/
いずれの検索エンジンにおいても、そのサイト自身がCCであるものと、その中の特定のコンテンツがCCであるもの、そして、CCについて言及している箇所の区別がついていないようである。そこを補うには、filetypeを指定して、たとえばfiletype:pdfとすることで、CCに言及した文書（の一部）に限定して検索する、などのノウハウが現時点では必要である。
----------
プロトコルやプロファイルXML記述のデファクト標準がCCで公開されている例
----------
2007年４月12日現在、Yahoo CC検索で、"メタデータ"を検索して368件中の第２位にランクされた<a href="http://www.google.com/support/webmasters/bin/answer.py?answer=34654&hl=ja">Googleのウェブマスター向けヘルプ センターの頁</a>では、<a href="https://www.google.com/webmasters/tools/docs/en/protocol.html">サイトマッププロトコル</a>を使用したサイトマップ作成が推奨されている。このサイトマッププロトコルはクリエイティブ コモンズのシェア・アライクの利用条件のもとで提供されており、Google以外の検索エンジンでも使用可能となっている。
<a href="https://www.google.com/webmasters/tools/docs/en/protocol.html">サイトマッププロトコル</a>とは、Google製のXML言語によるのオープンソースのプロトコルである。これに準拠したサイトマップファイルには、通常、サイトの URL のリストと、これらの URL に関する情報を記述する。Google他からサイトマップ生成ツールが提供されており、また、上記CCの利用条件の下、プロトコルを拡張可能しつつツールを自作することもできる。標準プロトコルだけでも、頁の詳細情報 (最後更新日や優先度等) を検索エンジンに伝えることができる。
上図「CCコンテンツのマッシュアップ」のように、互いに異なるCCが付いたAというサービスとBというサービスをマッシュアップしたサイトのライセンスは、OR演算で自動判定可能と考えられる。
帰属「BY」の必要性は、A,Bを含むマッシュアップ素材の全てに及ぶ。このため、マッシュアップ・アプリ上には素材の著作者を並記することになり、（Boolean演算ではないが） 集合和として、ANDでなくORをとったということができる。
非営利「NC」については、素材の１つでも非営利であれば、マッシュアップ・アプリも非営利でなければ利用できないことになる。したがって、BooleanのOR演算で計算する
ことになる。
派生禁止「ND」についても、素材の一部がいくら派生を認めていても、他の素材の１つでも派生禁止であれば、全体として派生禁止でなければならない。したがって、これも、BooleanのOR演算で計算することになる。
同一条件許諾「SA」（NDのフラグが立っていない場合にのみ）は、素材の一部がいくら異なるライセンスでの頒布を認めていても、他の素材が１つでも同一条件でのみ許諾されるのであれば、全体として同一条件許諾「SA」が適用されねばならない。したがって、これも、BooleanのOR演算で計算することになる。
CCの条件によっては、互いに組み合わせることのできないAPI、マッシュアップ素材もある。上図で、サービスBには既に派生禁止「ND」がたっているため、一般的には他のサービス（それに「ND」がたっているか否かによらず）とは組み合わせ不可、と解釈される。しかし、詳細を記述した法的文章によるライセンスの中に、例外規定として、特定の条件を満たした別サービスとはマッシュアップ可能とされているかもしれない。
いや、むしろ、マッシュアップの発展のためには、この「ND」を細分化した例外規定のサブ・フラグを新設し、「このようなCCのものとだけはマッシュアップして派生著作物を作れる」という拡張CCを提案したいところである。
上図では、サービスBは既に商用利用禁止「NC」がたっているため、他のサービスAなどが商用利用を認めていても、それをマッシュアップした全体は、商用利用禁止「NC」がたつことになる。しかし、これは、サービスAからみると、その派生物であるマッシュアップサイトは同一条件に限り許諾という「SA」（サービスAの「SA」）に違反してしまう。したがって、上図のサービスAとサービスBは、互いにマッシュアップ不能と考えなければならない。
以上を実装した、マッシュアップを支援するディレクトリ・サイトや、IDE（Integrated Development Environment; 統合開発環境）ができれば、大いに福音ではなかろうか。
十分多数のＡＰＩ、素材の候補があれば、機械的に足切りして残った候補のみを表示する。
僅かの候補しか残らない、あるいはゼロの場合は、ライセンスのネックとなっている部分をハイライト表示し、新たな契約交渉の余地があるとの記載があれば連絡先アドレスの入ったEmailの執筆画面まで開いてしまう。
また、事前に、マッシュアップ結果に求められるライセンス条件を指定しておいて、適合する候補しか表示しないモードと、面白いマッシュアップができそうならば当初考えていたライセンス条件を変更することも辞さないモードがあっても良いだろう。
CCを使っていないサイトについては、次の対策が考えられる。
このＣＣへの置き換えを第三者が実施するサービスが成り立つかは疑問である。無保証で、「恐らくこうだろう」と、自然言語処理を併用したパターン・マッチングで実行した場合も、その結果が一人歩きすることのないよう、根拠情報を添える（検索エンジン出力中のサマリのように）とともに、一瞬で元となったライセンス契約文章の全文にとびやすいようにしなければならないだろう。
WebAPIのディレクトリ・サイトであれば、原著作者にコンタクトして、自発的にＣＣを付けてもらうように交渉すべきであろう。それが特異なもので、せっかくの優れた技術やコンテンツが使われなさそうであれば、変更してはどうか？との提案を行っても良いかもしれない。
それがかなわなければ、「法的にはこちらが使いやすいですよ」と、利用者にお奨めできるような代打サービスを探索して登録し、マッシュアップを促進する、という事業戦略が考えられる。
代打サービスは、ライセンス条件が合わない時のみならず、継続性、可用性がネックとなったとき、あるいは、現在利用中のサービスの利用条件（無料から有料へ、課金条件、料金値上げ、等）が変更されて利用困難になった時にも有効と考えられる。もう１つ重要な点は、本命サービスのダウン時に代打サービスに切り替えることで、サービス数を増やしたにもかかわらず可用性（稼働率）を向上させられる可能性である。無料・無保証のマッシュアップと違って、エンタープライズ・マッシュアップとなると、利用サービスが増えるにつれて全体の可用性が低下する一方では許されない、と考えられるからである。
この他、ディレクトリ・サイトとしては、それらのサービスが何に使われているか、その度合いを個々のＡＰＩごとに表示したり、利用先を自動的に開いたり、さらにはサービスの機能をサムネイル・ビューの動画で実際に見せてしまう、などの可能性が考えられる。これらにより、単なる検索エンジンにはない付加価値を生み出すことができるだろう。
CCを推進する団体は、書籍内容のようないわゆる伝統的な著作物（主にオンライン版）を対象とし、ソフトウェアはGPLなどに任せている、という。上記のサイトマッププロトコルは例外のようにみえるが、このようなハイレベルのプロトコルやプロファイルはXML文書の形で実装されているので、無理なくCCの対象とできた、ということかもしれない。
我々がWebAPIを対象にすべき、と考えた理由は、
・機能部品といいながらコンテンツと表裏一体にみえることが多いから
・マッシュアップ、すなわち「引用」が容易。寧ろ引用されるためにこそ存在している
・Drag&Dropやデスクトップに「追加」というインタフェースで簡易にマッシュアップする操作は、コンテンツ部品をコピペする利用感覚に限りなく近い
などである。
WebAPIについては、文書と違ってRDFメタデータを埋め込むのではなく、APIにCCオプションを付けてRDF文書が返るようにする実装が妥当であろう。通常のコンテンツ表示にオーバーラップしてCCのアイコンを表示するモードへの切り替えができる設定用APIなども有用かもしれない。
マッシュアップの作法についても我々は「引用の正当な慣習」に極力従うべき、とも考えた。その理由は、これらの部品が表示された状態では、動く部品ではあるものの（ハリーポッターの通ったホグワーツ魔法学校の壁にかかっていた動く絵のよう！）、枠にはめられたコンテンツとして、全体の文脈の中で意味付けられるからである。これはまさに引用と同様の概念である。
アジャイルな開発プロセスの中で、on demand で「引用」、「借用」するのがマッシュアップ。そこで、ソフトウェア開発の一種ではありながら、次のように言いたくなるのである。
「レッシグ教授、マッシュアップはＧＰＬなどではうまくカバーできません。貴方が産み出したCreative Commonsが向いているのですよ！」
最後に感想であるが、従来は法律、契約の類を煙たがってきた技術者が法的メタデータに目を輝かせて取り組めたのは新鮮な驚きであった。マッシュアップするエンタープライズ系の開発者にとって、法的条件の考察、処理をアジャイルに行う必要が生じつつある現在、その環境整備の道具としてCreative Commonsの法的メタデータ標準は有望である。超短納期、あるいはアジャイルな開発環境の下では、部品が細粒度化するため、自分の手元で技術のみならずコンテンツの質や量、ＵＩデザインから美的デザイン、そして利用許諾条件までアジャイルに評価できる必要が生じる。このため、本テーマを『エンタープライズシステムのためのWeb 2.0』の一節としてとりあげた次第である。
ビジネスを考える立場からは、利用許諾条件、マッシュアップの構成や内容によって課金の方式や額が大きく変わってきそうな点に注目すべきである。すると、必要最低限の条件を記述した利用許諾条件のCC化だけでなくSLA（Service Level Agreement)の記述にまでRDFを拡張し、課金の条件や計算方式、上限・下限までも記述可能にしてしまう、という発想さえも出てくる。かように、エンタープライズマッシュアップの発展の正否を、部分的にCC活用の整備が左右するように感じられる。
本頁の著作権： Copyright (c) XML コンソーシアム 2007 All rights reserved. Copyright (c) メタデータ株式会社 2007 All rights reserved.
「エンタープライズ・システムのためのWeb 2.0」目次に戻る