創用CC授權條款3.0台灣版已經在2009.10.31正式上線

創用CC計畫編輯群/文

在經過多次審慎檢查以及專家諮詢後，我們於2009年5月26日正式在網路上公開「創用CC授權條款 3.0 台 灣版」預演版。這幾個月的時間，我們廣納與蒐集了大家的意見後，又再度作了細微的修改，並且與 Creative Commons 位於舊金山的總部經過好幾次的聯繫、確認後，創用CC授權條款3.0台灣版終於完成本 地化的工作了。此次3.0版本與之前的版本有些許的更動，其中的細節可以參閱《創用CC電子報》第三十 八期由林懿萱小姐撰寫的專文〈創用CC授權條款3.0台灣華語版面世前之先行導讀〉一文。我們已於2009 年10月31日完成正式上線的工作，歡迎大家上網了解、使用、並繼續支持創用CC授權。

再次提醒大家的是，創用CC授權條款3.0臺灣版的誕生，僅是因應全球創用CC授權使用社群的意見回應所 做的變動，提供給大家多一種選項；亦即是以使用者意願為基礎的進階版授權條款。也因此，已使用創用 CC授權2.5版或以前版本釋出著作的權利人，不需要擔心會在權利義務上因為3.0版的問世而產生變化。比 較值得注意的是，若您採用創用CC授權2.0版以及2.5版含有「相同方式分享」的授權要素釋出著作，未來 使用人改作你的著作再次繼續分享給他人時，是可以選擇具有相同授權要素的後續版本，因此採用3.0版是沒有問題的。

 

「建立數位公共領域-理論構建與在地實踐」國際學術研討會 報名開跑

MozCC 在 Jetpack 裡重生：JetCC

 在弄 ccZotero 時，網頁裡後設資料皆經由 ccMetaView (MozCC 的一部份) 擷取而來。ccMetaView 的目標是要能夠抓到各式相關的後設資料格式 (而不論是否與 CC 相關)，這是好事，不過如果就真的只想抓 CC 的後設資料、是否有跟 MozCC 1.0 一樣的簡單套件呢？又，Firefox 的 API 隨著版本演進而變，而就 CC 總部投注在 MozCC 上的資源，顯然不足以隨著版本變動而更新，是否有更能快速修改的東西呢？

 之前提過，我最近花比較多時間玩 Jetpack，所以在想到這些後，就把腦筋動到 Jetpack 上。這種單純的架構果然是實作簡單套件的最佳方式，只花了一點點時間、就把這個 Jetpack feature: JetCC 做出來了。

 安裝 JetCC 之後，在狀態列上會顯示目前網頁的授權方式，點選之後則會帶你前往授權條款的說明頁面。其實一切就與 MozCC 1.0 差不多，這也是我覺得比較「輕量」的方式。

 拜 HTML 5 Selector API 所賜 (在此以 jQuery 處理)，要找到網頁中有沒有「授權條款」相關資訊，只需要簡單一行：

 $(doc).find("a[rel~='license']");

 接著再取得該元素中的 href 屬性 (也就是授權條款網址)，即可得知該文件採用什麼授權條款，然後顯示相應圖片即可、輕鬆愉快。

 在這個小套件裡有幾件事情值得與大家分享：

 1. CC Metadata 格式

從古到今，就我所知有三種在網頁裡嵌入 CC 授權資訊的方法，分別是放在註解裡的 RDF、microformat、以及目前的 ccREL 規格。後兩者都可以用剛剛那樣擷取 rel="license" 的方法來察知，不過對 JavaScript 來說、放在註解裡的東西還真是苦手。實作上還是可以分析網頁後自己寫簡要 RDF parser、不過我懶了…

除了註解中的 RDF 之外，XML 中的 RDF 也是個問題。按理說我不需要管到 XML 的部份、但因為 Firefox 的構成介面：XUL 也是種 XML，所以利用 XUL 做的「網頁」 (例如高橋流 XUL) 也可以由 Firefox 開啟，這麼一來支援一下就是理所當然的事情了。不過同上，目前懶得做，願意幫忙的大德快來吧 XD

2. 產生 referer

點選狀態列的 CC 圖示會帶你到該授權條款的說明網頁。其實 CC 的授權條款說明頁面會自動偵測來源網頁是否有其他 ccREL 的資訊 (例如 morePermission、姓名標示資訊等)，並且顯示出來。因此，如果在這邊單純用 jetpack.tabs.open() 來開啟授權條款說明頁的話，在 HTTP request 內並不會送出 referer，那說明網頁也就無法找到來源網頁上的其他資訊。

只要能送出 referer 就能解決此問題，不過 Jetpack 的 API 目前還沒有提供修改 HTTP Request 內容的方法，所以只能靠其他旁門左道來處理了。在你點選狀態列的 JetCC 圖示時，我們偷偷在目前頁面上插入一個按鈕，設定按下後前往授權條款網頁，再用程式模擬按下動作。這樣就暫時繞過了 referer 的問題。

嚴格說來，這個套件的作用相當有限，但有鑑於 Jetpack 這種方式是未來瀏覽器擴充套件架構必走的道路，當成試作品亦有他的價值。程式碼本身相當簡單，我直接宣告進入 Public Domain 了，歡迎大家隨意使用，如果有興趣改成 Google Chrome 可以安裝的擴充套件也不錯 (應該也相當簡單)。

Film Annex 發表了六個專播 Creative Commons 授權影片的網路電視頻道

專文：雜談 ccPlus 運作模式

趙柏強/文

自 iSummit 2008 回來後，筆者撰寫的 Open Business 心得裡提過 ccPlus 這項技術。時過境遷，ccPlus 已經成為 ccREL (為作品以數位方式標示 CC 授權條款的標準規格) 的一部份，當您前往 CC 網站選擇授權條款時若填入「其他授權方式網址」，則產生的程式碼裡就會包含 ccPlus 的資訊。

簡言之，程式碼中的 rel="cc:morePermissions" 相應標籤中，正標示了進一步連絡的網址。如果使用者需要更進一步洽談授權、點選這個網址就對了！事實上，經由按下網頁上的 CC 授權標章前往授權標章的說明網頁時，說明網頁上也會告知訪客該去哪裡洽談更多授權。

授權代理實作方式

ccPlus 的原理十分簡單，商業組織要實作相應的功能也不太難。當創作者為自己的作品標上 ccREL 資訊、並且在其中包含 morePermission 資訊後，支援 ccREL 的瀏覽工具應能直接辨識出授權代理商的連結並提示使用者；在使用者點選授權代理商的連結後，主機端再加以辨識 HTTP 標頭中的 refferer 資訊，得知來源網址、再依據來源網址的原始授權方式決定要提供哪些額外的權利供使用者購買即可。

舉個例子：創作人「小強」以創用 CC 姓名標示—非商業性—相同方式分享條款授權他人使用自己的歌曲，而聽眾「包柏」很喜歡這首歌、並且想用在自己的作品上，但基於種種因素無法遵守這個授權條 款，於是他點選小強網頁上的「其他授權方式請點選此處」，連到了授權代理商 morepermission.com 的網頁。morepermission.com 此時因為 HTTP refferer 的資訊得知包柏因小強的歌曲而來，並且從小強的原網頁查明小強採用 CC:BY-NC-SA 條款，因此自動列出下列購物選項供包柏選擇：

1. 除原條款授予之權利外、額外增加「商業使用」的權利：1000 元/單件作品
2. 除原條款授予之權利外、額外允許免去「相同方式分享」的權利：3000 元/單件作品
3. 直接購買一般性商業使用權利 (不需標示姓名、不需相同方式分享)： 20000 元/單件作品

包柏勾選第 1 及第 2 項，並且填寫相關資訊後結帳，便擁有在單件商業作品上利用小強的歌曲、且不需以相同方式分享的權利。每個月都有數十位像包柏這樣的人前來 morepermission.com 購買小強作品的額外權利，而 morepermission.com 則在月底與小強一次回報本月的銷售狀況及結算金額。包柏跟小強都免去了信件往來的等待時間與麻煩，而 morepermission.com 則收取一定比例的服務費。

衍生問題

剛剛的流程看起來還不錯，但就技術面來說、其中會有幾個問題：

1. 包柏要的，是小強網頁上的哪個作品？

當同一個網頁上又有圖、又有文、又有音樂，程式如何判斷 ccREL 所指的東西是什麼？ccREL 可能出現在網頁上的任一處，即便授權代理商能循線回到來源網頁查驗、也無法用電腦程式準確判斷出網頁上的那個部份是授權的標的。

2. morepermission.com 怎麼自動提出購物選項？

最簡單的想法是，原始的授權條款有哪些元素，就提出相對應的「取消」選項。例如本例中原始授權標的物採「姓名標示—非商業性—相同方式分享」授權大眾使用，那麼直接提出「不需姓名標示」、「允許商業利用」、「不需以相同方式分享」作為採購選項似乎便是可行的方式。

不過考慮到原始著作人的意願，那麼事情又有些不同：或許對小強來說，取消「相同方式分享」跟「非商業性」都還好說話，但很堅持必須保留「姓名標示」的權利，此時 morepermission.com 還是必須提出相應的機制來回應著作人意願。

當然，也要考慮到我們並不需要在「more permission」的層面上被 CC 的各項元素綁死，而更可以直接將「一般性的商業使用權利」當成選項之一。選擇此項時，買賣雙方的關係就不是「我已經獲得著作人以 CC 某條款授權、且著作人對我額外免除某些條件」，而是「我已經獲得著作人以一般商業使用權利授權」，則此時就完全不需要看 CC 的條約內容，對於利用人來說或許更為簡便。

3. 如何定價？

取消各種權利時，該怎麼定價？且雖然範例裡「不需相同方式分享」的價碼較「可商業利用」來得高，但不同的著作人可能又有不同的看法。又，依據使用目的不同、定價方式也該有所差異：耗資千萬的電影與巷口的咖啡館要用你的音樂，應該就有不同的計價方法。

這 3 個問題都可以經由著作人與代理商先行約定來解決，也就是說小強在 morepermission.com 上先註冊一個帳號，指定「由這個網址來時、代表著作物是這首歌」、選擇願意有條件除去的授權元素、再分別就各種情形自行給予定價。也或許小強可以指定「某 個網址來的著作、一律堅持保留姓名標示元素」、「某些特定網址的著作，一律僅給予『直接購買一般性商業使用權利』的選項」等等。

不過既然要「登記」，那麼又衍生出「如何知道帳號的所有人就是作品所有人」的問題，這個層面其實已經離 CC 所關心的事情有點遠、但又容易被牽扯為 CC 應該解決的問題。筆者認為，無論有沒有 CC、在世界上盜用別人作品自稱作者的事情也本來就存在，那麼原本怎麼解決就怎麼解決、原本難以解決的也不用在這個地方苛求 CC 有所作為。目前來說，服務商及購買者只能相信網頁提供者確實提供了自己擁有著作權的作品。

其他玩法

上面舉的例子是獨立的授權代理商機制，也是筆者認為比較開放的玩法。依據這個作法，使用者可以自由選擇作品的發佈平台及授權代理商，避免被一家公司綁死。

不過，事實上在目前可見的 ccPlus 服務供應商裡，大多都是把著作發表平台 (content hosting) 直接結合金流，還沒有看到開放、接受外部作品一起販售的情形。以 Jamendo 為例，在平台上發表的音樂內含 ccPlus 資訊，但使用者沒辦法選擇授權代理商、而是會直接又連回 Jamendo 的授權網頁。

此外，能夠選擇的授權方式也不若 ccPlus 原先「可以隨選要減少的授權要素」的規劃，而大多是直接就作品要利用的層面來販售商業性使用授權。也以 Jamendo 為例，在選擇好要買的歌曲之後，網站會出現表單要求你描述作品的應用方式，並藉以決定要收多少費用。

這種方式把剛剛提到的作品、購物選項、定價等問題，都直接由該平台幫你決定了。雖然一次解決了很多問題，但相對來講就不那麼自由，且使用者若想藉由多個平 台來增加曝光度、也無法選擇統一的授權代理商來簡化收費流程。但不可否認，這樣的實作方式對於服務提供者來講是比較方便、利益也比較高的，因此無怪乎大家 都以此種方式實作 ccPlus。

但就算作品發佈平台想兼營金流機制來收一點服務費，無可避免也必須付出相對的營運成本與代價。所以可以想見另一種模式很可能會在不久的將來出現：作品發佈 平台提供有限的選擇，讓著作人自三到四家的授權代理商中選擇其一，而發佈平台再與授權代理商分享手續費。這個模式可以讓發佈平台免去增加金流業務的麻煩、 且又能讓想合作的授權代理商自行「投標」加入合作伙伴，獲得一定利益，著作人也能因此獲得 (有限的) 選擇自由。若授權代理商增加到一定的數目，這個方式很可能在未來成為主流。

那麼，目前有多少獨立授權代理商？

在筆者有限的資訊裡，答案是零、一家都沒有。

ccPlus 概念推出已經超過兩年，目前實際支援這項技術的獨立授權代理商就是找不到。以全球作為市場範圍來講，這多少應該還是個有利可圖的行業，會造成毫無獨立廠商支援的理由，筆者隨便猜一下：

1. CC 不紅，ccPlus 更不紅：也就是「這是個解決問題提升利益的好技術，但知道的人不多、實作的人當然更少」。其實這是最好的狀況，問題僅僅在推廣而已，而不是機制本身有問題。
2. 著作發表平台不支援：獨立授權代理商想賺錢，那麼自然希望有足量的著作人使用 ccPlus 技術、且願意指定自己為授權代理。但目前提供著作人發表著作的服務平台、似乎都沒看見能讓你選擇外部授權廠商的設定可填。
3. 雞生蛋蛋生雞：以著作發表平台的角度而言，現在這類授權代理機制還不風行，好像也沒有必要提供支援。上述兩點明顯為雞生蛋、蛋生雞的情境，讓支援 ccPlus 的獨立授權代理商在短期之內只能從自己架主機發表作品的著作人身上賺到服務費，吸引力太小。
4. 也或許，這個市場本來就小得可憐？筆者不這麼認為，但沒有統計數據支持的情形下這必須列為一個可能。

其實應該再加一個「以上皆非」 —— 也或許其實 ccPlus 機制設計上有什麼問題，是我們這些太熟悉 CC 的人沒有注意到的？

無論如何，有更多的後設資料我們就有機會利用機器做更多的事，ccPlus 是後設資料的一種、與其相關的授權機制也有推動的價值。筆者在接下來的半年內將尋訪創作者及既有平台服務商 (包括著作發表平台及線上授權服務平台等)，希望能整理出 ccPlus 機制運作架構建議及目前的狀況分析，期待明年中有機會再與各位分享心得與成果。

如果您想了解更多關於 ccPlus 的資訊，請見 CCTW Wiki: http://wiki.creativecommons.org.tw/CC_Plus

如果您想參與這項研究或討論，請前往筆者網誌留言指教：http://blog.bobchao.net/2009/11/ccplus.html