薪光幫,柏強

網誌原名為「柏強的城市探險記」,您沒有走錯。

BobChao柏強高雄人。學的是資訊管理,對於網際應用、組織資訊流程、社群營造與行銷皆有一定興趣。目前居住於台北,是 MozTW 社群及 Creative Commons Taiwan 的成員,工作跟自由文化高度相關。

其他資訊 (電子名片)

雜談 ccPlus 運作模式

這篇是下期 CC 電子報的專文 (一刀未剪版),為了鼓勵集中回應,先貼一下自己的 Blog 以便取得連結 :P


自 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

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 可以安裝的擴充套件也不錯 (應該也相當簡單)。

JetWave 0.2 with waves list in your sidebar.

I just add a feature to JetWave which can show your inbox in Jetpack sidebar. Check the screenshot below:

Also, you can install JetWave from the new Jetpack Gallery, which is still in the alpha stage but usable. Remember to check the "Let me install this unreviewed Jetpack" near the install button.


我為 JetWave 新增了在側邊欄內讀取 Wave 清單的功能 (見上圖),另外也把 JetWave 丟到 Mozilla 實驗中的 Jetpack Gallery 裡了。如果您要從那邊安裝的話,記得先勾選「Install Jetpack」上方的「Let me install this unreviewed Jetpack」。

JetWave, JetPack feature for Google Wave

JetWave is a JetPack "feature" for Firefox. Just like Gmail-notifier extensions, JetWave can help you to check your inbox in Google Wave.

For install and usage information, please check the JetWave page.

我最近花蠻多時間玩 JetPack 的。雖然上官覺得 JavaScript 其實不簡單,不過我自己來講、「簡單」代表的是肉腳如我也可以隨便寫出點東西來,我們這種人是不會要求自己太多、或者要把什麼東西寫得太好太複雜的 ;) JetPack (及 Google Chrome 的擴充套件架構) 就蠻適合我們這些平常只碰網頁設計、會點 JavaScript 的人。

JetWave 是簡單的 Google Wave 檢查套件,安裝後會在狀態列上顯示收件匣內的新訊息數目,點擊後則可前往 Google Wave 查看新訊息。除此之外,我也蠻建議會點 JavaScript 的人看一下程式碼 —— 我並不專精於程式設計,但相信看了後可以大概了解用 JetPack 快速寫個符合需求套件 (或說「feature」) 的方法。

安裝或其他資訊,請往此處去

我接下來想做中職戰況快速檢視的東西,不過今天晚上我要去ㄆㄘㄉ了 :P 所以就跟預定的 JetCPBL 套件說聲明年三月見囉~

Bring CC data to Zotero

Zotero is a Firefox extension which plays the role of EndNote, help you to manage the resource you collected on the web, like research papers or articles. Though there's a Rights field for copyright / license metadata, it seems that Zotero can't recognize CC license data.

Zotero supports COinS, but don't save rft.rights values from OpenURL (I don't know why.) That means you have to enter every rights information by yourself, or you might have copyright issues when you wanna reuse the data.

Luckily we have MozCC, an extension to recognize hidden metadatas in the web page. In this way, we can make another extension to bring the power of MozCC to Zotero. It actually pretty simple, but I did spent way more time then coding for these issues:

  1. After 2.4, CC HQ break MozCC into two extension: one for recognize metadatas in web page, one for UI display. Since the separation is at the early stage, I feel lost often when I read the code. :( Well I'm not a good programmer, I knew it from the very beginning.
  2. COinS is totally new for me, and there's only a few example for rft.rights on the Internet. Pretty strange but it's true, do a search and you'll see. I have to decide if it is the good place to save license data and if true, in which format. Since I wanna solve the multi-licenses issue (see below) in the next step, I save the license URL only at this point. 
  3. When there are two (or more) license statements on one page, how do you know which is license you should follow? Sometimes it means the page is dual-licensed (like Wikipedia, license under both GFDL and CC:by-sa, ) and sometimes it shows different licenses for different part on the same page. This could be a problem, and even MozCC didn't solve this.
  4. Bob is too lazy.

Anyway, I made a simple extension (or "plugin for Zotero",) to try out the possibility. If you wanna give it a try or even help me to improve it, you can get it from my website.

You have to install MozCC and Zotero first. You can use Zotero 1.x or 2.x beta, and for MozCC, please install the newest version IN THE SANDBOX (2.4.9+) from Firefox Addons.

Patches and feedback welcome, just leave your message :)


練習寫英文的分隔線 (喔對了歡迎幫我改作文 orz 請寄信給我)


Zotero 是個 Firefox 的擴充套件,可以用來管理網路文件與你擷取的其他資料,跟 EndNote 的作用非常相近、都是比較偏向學術文件管理的用途。我家老闆希望有個可以管理網路 CC 資源的軟體,這當然是非常棒的東西,但可惜他雖有「授權」欄位、卻認不得 CC 的資料。

我查了一下他支援的 COinS 格式,此格式將 OpenURL 嵌入網頁,規格裡也有 rft.rights 這個欄位,不過 Zotero 不吃… 所以我把腦筋動到 MozCC、一個可以辨識網頁上 CC 資訊的套件上。理論上,可以寫個小程式,讓 Zotero 在儲存資料時「順手」將 MozCC 辨識出來的資訊帶到 相對應的欄位裡,完成任務。

程式其實很簡單… 不過我花的時間好像比較多在查資料,包括:

  1. MozCC 2.4.9 開始真的把這套件拆成兩個部份了,一個用來辨識、一個用來顯示。這很棒,也是正確方向,不過目前分割得不是很乾淨,我看程式碼時常迷路 orz 我真的很遜。
  2. COinS 跟 OpenURL 對我來說是新東西,其實我不太敢確認  rft.rights「可以」拿來存授權資料;目前反正是心一橫就上了,而且我有看到有人的使用方式跟我相近。另外,要儲存什麼資訊呢?我一開始有想過像 MP3 的授權欄位一樣,儲存「本文章採用創用CC姓名標示條款授權,請見 {網址}」這類的東西,不過考量到我想解決多重授權(看下一條)等問題,所以目前先單純儲存授權條款網址再說。
  3. 網頁上如果出現兩個(以上)的授權聲明,怎麼辨識儲存下來的部份該遵從哪一個條款?是平行授權、還是針對網頁的不同部份授予不同權利呢?這真的有難,MozCC 也沒解決這問題,不過我想試試看有沒有什麼好方法可以處理,以後再說。
  4. 我好懶。現在每天看棒球轉播是我唯一的嗜好。

總之總之,我還是做了一個小套件。先裝 Zotero 跟 MozCC 2.4.9+ 再裝這個套件,那麼儲存網頁時如果 MozCC 有偵測到 CC 授權資訊、Zotero 就會把授權條款資訊儲存在「權利」那個欄位內。有興趣的可以試試看,也超歡迎幫忙修改、一起討論的。

我覺得寫得簡單又爛,其實很掙扎要不要丟出來 orz 不過考量到其實我好像沒在怕別人知道我多遜,就丟吧 XD 有興趣幫改或提意見的,請直接留言囉。