獨樹一格的藝術條款-Artistic License 2.0
Created at Friday, 21 January 2011 03:58 Last Updated on Monday, 14 May 2012 14:48
Written by 葛冬梅
Artistic License 2.0(以下簡稱 Artistic-2.0)這份條款並不像 GPL、LGPL、BSD 或 MIT 等條款如此地廣為人知,不過對於有在接觸 Perl 這個高階直譯式程式語言與相關專案的開發者來說,對於 Artistic 系列條款就應該一點也不陌生,因為第一版的 Artistic-1.0(註一)便是由 The Perl Foundation(TPF,註二)所起草,並且適用於 Perl 程式語言及其相關的軟體專案,不過由於第一版本的 Artistic 規定有些許模糊不清的地方,並且授權狀態不相容於使用比例較為普遍的 GPL 授權條款,所以 TPF 經過多年的討論與意見蒐集之後,於 2006 年正式發布細心修訂之後的 Artistic-2.0。
如同其他的自由開源軟體授權條款一樣,以 Artistic-2.0 授權的軟體專案,可以讓使用者自由地執行、修改、重製與散布,然而 Artistic-2.0 的授權方式,並不像 BSD 類別條款那樣幾近毫無拘束,但也不像 GPL 類別條款那般嚴格地拘束使用者後續的散布方式,具體分析下、Artistic-2.0 有著它獨樹一格的授權規則,這些獨樹一格的設計來自於編撰 Artistic 條款的基礎理想,那就是:讓軟體專案的原始開發者可以用自由開源授權的方式來釋出專案,但同時讓後續的開發流程,也能夠達到「藝術控制(artistic control,註三)」的理想目標。
【Artistic License 的授權特色在於達致專案藝術控制的理想目標】Artistic-2.0 所秉持的「藝術控制」目標是指,對於某些程式開發者來說,開發軟體就好像是在從事藝術品創作一般,原始開發者對於該專案有其特別的理想,並且期待讓這個軟體專案,後續仍是朝著自己心中的理想方向來發展。例如程式語言必須具有統一的標準內容、撰寫出來的程式碼必須簡潔清爽,以及符合特定的撰寫規則 (coding style) 等等。但由於自由開源軟體在授權狀態上,亦高度重視後手對於前手程式的修改地位,所以對於多數自由開源軟體專案的原始開發者來說,恐怕沒有辦法用嚴格規定的方式,直接控管所有修改版本與分支版本的發展方向,但為了實現原始專案開發者心中對於專案撰寫規則方面的堅持,所以 TPF 才會在兼顧自由改寫的開源精神下,撰寫出 Artistic 這一系列風格獨特的授權條款,一方面將「藝術控制」的元素融入到授權文字中,另一方面也讓專案的原始開發者,可以持續了解或參與各個「修改版本」的修改過程與討論內容,後續並得以將符合心中理想的衍生程式碼,帶入到原軟體專案的「標準版本」中。
【透過標準版本與修改版本的分立來確保專案寫作風格的一致性】為了達到上述的目標,Artistic-2.0 首先劃清了「標準版本 (Standard Version)」的定義與範圍,原則上、只有兩類軟體可以被稱為標準版本,一類是專案原始開發者自行發布的軟體專案,另一類是依照專案原始開發者明確指示而修改出來的版本,至於其他因為修改標準版本而產生的衍生程式,都只會被稱為該專案的「修改版本 (Modified Version)」。透過標準版本與修改版本分立的機制,Artistic 授權專案的原始開發者,可以確保標準版本都會依照自己堅持的寫作規則來發展,同時也讓他人透過「標準版本」這個名詞,來辨識出哪一個版本是專案原始開發者心中認可的理想後繼版本。此外,Artistic 專案的修改者,若僅僅在修改的檔案處標示修改者與修改日期等基本資訊是不夠的,Artistic-2.0 進一步規定,修改者必須詳實記錄修改版本與標準版本的所有不同之處,包括兩者有哪些不同的功能、可執行檔案或者是任何經過變動的模組資訊等等,以便利專案的原始開發團隊能了解修改內容,並在認同修改內容的情況下,將這些修改特點順暢地納入標準版本的後續開發,以達到專案原始開發者能持續參與軟體修改與更新除錯的目的。
【Artistic-2.0 擴張修改版本授權相容性的彈性規定】Artistic-2.0 對於修改版本的授權方式也有著獨特的彈性規定,關於這部份可以分為以下三種狀況來說明(註四):
- 修改者可以選擇 Artistic-2.0 作為修改版本的授權條款,並且主動地讓專案原始開發者可以取得修改版本的程式碼,以便利專案原始開發者將修改的內容納入後續的標準版本。所以,若是修改者想要將自己修改的內容回饋給原本的開發社群,就可以利用這條規定;
- 修改者亦可以採用其他具有授權拘束性的自由開源軟體授權條款來散布修改版本,這類條款包括 GPL、LGPL 與 MPL 等(註五)。這項規定間接擴展了原 Artistic-2.0 授權軟體的應用與發展層面,因為更改授權方式後的修改版本,可與前述 GPL、LGPL 或 MPL 等其他的自由開源軟體元件,相容在同一個軟體專案裡進行授權結合。此外,由於這些具有授權拘束性的條款皆規定,散布後的程式源碼必須提供出來給該修改版本的後續使用者,這樣讓原來 Artistic-2.0 專案的原始開發者,可以有機會獲得這些修改版本的改作內容,並進而在學習後重新撰寫,將之納入到後繼的標準版本中;
- 若是修改版本的安裝不會影響到標準版本的安裝或執行,修改版本可以採用任何一份符合修改者需求的條款來授權,例如 BSD、MIT 等較為寬鬆的自由開源軟體授權條款 (permissive license),甚至採用不提供程式源碼的專屬軟體授權模式也是可以的。因此若是修改者預計不採用 Artistic-2.0 、或其他具有授權拘束性的條款來散布修改版本的話,就可以利用這項彈性規定。不過必須注意的是,此時修改版本的名稱必須要讓人能夠清楚辨識,不會與標準版本的名稱混淆才可以。Artistic-2.0 這樣的規定雖然可能會讓專案的原始開發者無法取得後續修改版本的修改內容,不過這也清楚劃分了一條簡明的使用界線給軟體的修改者,也就是說在同一個操作環境下,若使用者無法使用原始標準版本置換回修改版本進行運作的話,這就算是影響到了標準版本的安裝或執行,一旦跨越過這條使用界線,修改版本就必須回頭採用 Artistic-2.0 、或其他具有授權拘束性的條款來進行散布才可以(註六)。
除了上述的這些特色規定之外,如同近年來新修訂的其他自由開源軟體授權條款,Artistic-2.0 也新增了專利授權與專利反制的相關規定,以降低軟體使用者可能遭受到的專利侵權風險。所以、只要是專案原始開發者有權利可以再授權出去的專利技術,一旦自主性地寫入到 Artistic-2.0 授權軟體中的話,就代表後續使用者在利用這個 Artistic-2.0 軟體的同時,可以連帶免費、自由地依 Artistic-2.0 的相關規定來運用這些專利技術,但若是任一使用者對該軟體的其他使用者提出專利控訴,主張 Artistic-2.0 授權軟體侵害他人專利權的話,則 Artistic-2.0 對這位使用者的各項授權關係將會被自動終止,這位專利控訴者將無權繼續合法使用這個 Artistic-2.0 授權軟體。
Artistic-2.0 在 2007 年時經過開放源碼促進會 (Open Source Initiative, OSI) 審核通過,是一份經過 OSI 核可認證的開放源碼授權條款,此外、自由軟體基金會 (Free Software Foundation, FSF) 也認定這是一份符合四大自由的自由軟體授權條款,因此 Artistic-2.0 是一份同時符合開放源碼十項標準與自由軟體四項定義的自由開源軟體授權條款。不過由於這份條款在使用上並不如 GPL、LGPL、BSD 或 MPL 等明星條款一般的名氣響亮,因此對於一般開發者來說,其中的細部規定也不是那麼讓人耳熟能詳,因此若是在開發專案的時候,有開發者利用到 Artistic-2.0 授權的元件時,還請務必注意這份條款所特有的規定,詳實記錄修改內容與原始標準版本的不同之處,以便利專案的原始開發者能後續將您修改的內容納入到標準版本之中,這樣、才能同時達到 Artistic-2.0 所追求完善「藝術控制」的目的,但亦不妨礙軟體專案能被自由散布、自由修改的開源理念。
註一:Artistic-1.0 的中文介紹請參考:
https://www.openfoundry.org/tw/licenses/30/;Artistic-2.0 英文原文請見:
https://opensource.org/licenses/artistic-license-2.0/。
註二:The Perl Foundation 官方網站:
https://www.perlfoundation.org/。
註三:「藝術控制」是一個來自多媒體製作過程的用語,在電影、電視或音樂後製的過程中,擁有藝術控制權的人可以最終決定這件電影、電視或音樂成品最後將會如何呈現。進一步的相關資料,可參照英文版維基百科條目:
https://en.wikipedia.org/wiki/Artistic_control。
註四:相關的規定內容請參照 Artistic-2.0 第 4 條。
註五:這部份的規定是在 Artistic-2.0 第 4 條第 c (ii) 款中,原文僅規定這類授權條款的抽象要件,包括:(1) 允許修改版本的被授權人自由重製、修改與再散布修改版本,(2) 修改版本必須一直採用相同的授權內容,(3) 他人可以自由取得修改版本與再衍生程式的程式源碼,(4) 修改版本與衍生程式在散布時禁止收取授權金,不過可以收取其他的散布費用 (Distributor Fees)。這些抽象要件就是指 GPL、LGPL 與 MPL 這類具有授權拘束性的條款,因此本文為了方便讀者了解,直接採用「具有授權拘束性的自由開源軟體授權條款」等語加以說明。
註六:可以參照 The Perl Foundation 對於 Artistic-2.0 的相關解說:
https://www.perlfoundation.org/artistic_2_0_notes。