legist-says 強言所知

本文最初發表於 自由軟體鑄造場電子報第 143 期 法律源地專欄。
本文授權採 創用CC「姓名標示－禁止改作－非商業性」授權條款 台灣 2.5 版。
本文引用之圖片係合理使用自本文（註一）中 Stephen Shankland 於 cnet.com 之新聞報導附圖，本人並非該圖著作權人，故該圖不在本文授權範圍內，在此合先敘明。

去年 (2009) 年底，企業精神標榜「莫作惡 (Don't be evil)」的 Google，對於在其開放源碼開發平台 Google Code 的 JSMin-PHP 專案，表示不再繼續提供專案託管的相關服務，因為 JSMin-PHP 的授權條款中包含了「本軟體必須用於善行，不得為惡 (The Software shall be used for Good, not Evil.)」的這段文字（以下簡稱為「善行條款」），不符合 Google Code 的專案授權政策。

這件事的起因是，JSMin 專案的開發者 Douglas Crockford，用 MIT 來授權其程式碼，並且基於個人反戰的信念，認為其程式碼僅得用於良善、反對邪惡的用途，因此在該 MIT 授權條款中加入這個「善行條款」。其後 Ryan Grove 將 JSMin 以 PHP 語言重新撰寫，成立 JSMin-PHP 專案，就這樣繼續維持了內含「善行條款」的授權條款。又因為，JSMin-PHP 是在 Google Code 上開發，在 Google 了解到有這樣的授權條款後，其開放原始碼部門的經理 Chris DiBona 就去信要求 JSMin-PHP 必須將它改成單純的 MIT 授權，否則就拒絕繼續提供託管的相關服務。但 Grove 認為 JSMin-PHP 是源自於 JSMin，他不能自作主張拿掉原來 Crockford 想要的授權條款，於是拒絕這個要求，並將該專案轉到 GitHub。（註一）

Google 會有這樣的要求，與 Google Code 的託管專案授權政策有關。如果要在 Google Code上開專案，我們只能「不自由地」從它預設的 9 種條款中選取其中一種（註二），在授權的選項上會比較沒有彈性。根據 Google的說法，這樣的限制其實是為了避免各程式碼之間的授權不相容的問題；雖然犧牲了部分選擇的自由，但可以換取程式碼之間更大的相互抄寫利用的可能性。無論如何，JSMin-PHP 既然採用了「MIT ＋ 善行條款」的授權，就不是 Google Code 願意託管的專案了，因此必須另覓他處。話說回來，站在自由軟體的角度來看，我們應該如何理解「善行條款」的意義呢？

從自由軟體的定義來看，分別著眼在「自由」或「開源」，大概可以區分為兩種概念：一、根據自由軟體基金會 (Free Software Foundation, FSF) 的說法，一個軟體必須要符合四大自由（註三）；二、開放源碼促進會 (Open Source Initiative, OSI) 提出了開放原始碼定義 (Open Source Definition, OSD)（註四），其中包括十項較為細緻的判斷標準。若對於上述這兩種概念還不那麼了解，可以參見上述註解中的相關文章介紹。

筆者從這兩組判斷標準的內涵綜合歸納出幾個自由軟體（註五）授權條款的通則要件：1. 必須開放原始碼；2. 不得收取授權金；3. 不得限制授權的時間、地域；4. 必須平等，不得歧視任何人或團體，也不得歧視任何用途；5. 必須讓後手也取得四大自由。

其中「不得歧視任何用途」這部分，一方面是基於科技中立性的考量，意思是說，我們不能在授權條款中規定必須使用或禁止使用某個技術或某些用途，因為技術無罪，它可能會有各種好的、壞的應用，不能逕為禁止；另一方面則是為了要減少對於開放原始碼的阻礙，例如，若有授權條款要求禁止商業利用，這樣的開放必然不夠徹底，對於被授權人也不夠自由。

因此，我們可以理解到，自由軟體授權條款除了「自由」及「開放原始碼」之外，也要求「平等」──對待任何用途都必須要全然的平等，不能限制被授權人該怎麼利用這個軟體；必須要有「平等」這個手段，才能確保開放原始碼最大的自由。基於這樣的想法，要限制這個軟體「僅得為善、不得為惡」，就可能有與自由齟齬之虞了。總之，如果一個授權條款包括對於用途的限制，那麼它與上述自由軟體的判斷標準就會有所出入，因此要稱之為自由軟體就可能會有一些疑慮。

雖然包含「善行條款」的授權條款或許不能遽視之為典型的自由軟體授權條款，但從法律的層面來看，它仍然應該被認定是有效的。儘管善行的定義非常的模糊不清，但權利人依著作權法，本來就享有完整的電腦程式著作權，我們要利用其程式碼時，本應向權利人請求授權；當授權範圍不明時，則仍應該直接寫信聯絡權利人，說明我們的用途是什麼，並請求他的合法授權，而不能直接依自己的善惡觀來決定自己是否為善、有否被授權。也就是說，我們利用這樣的軟體，已經無法純粹地以面對自由軟體的相同態度來利用了；謹慎一點的做法則應該是，最好先問過著作權人，他有授權，我們再來利用他的程式碼。雖然它仍然開放原始碼的，但從自由利用抄寫的角度來看，這個軟體較之典型的自由軟體授權條款而言，可能相對上比較接近專屬軟體「要求先詢問」的特性。（註六）

綜上所述，不只是「善行條款」，像是「非商業利用」、「禁止從事基因研究」、「反軍事利用」（註七）等等，任何對於用途限制的條款，某程度上都可能會影響自由軟體所要保障的自由。如果我們終極的首位目標是讓抄寫利用變得完全自由，那麼就必須使其他的目的退讓，才能真正維護這個目標。反之，如果站在不同的價值判斷上，我們當然也可以基於現有的著作權法制，讓每個人可以基於他個人心中的正義及價值來自由地決定要如何授權。

正如我們依照憲法享有言論自由，並不會因此就可以隨意公然侮辱或是造謠誹謗一樣，任何的自由都有其極限，否則無法達到真正的自由。自由軟體在定義及性質上會有這樣的限制，當然是為了維護最大公約所認定的自由。不過每個人心中總有他自己的正義感及道德觀，正如在自由軟體中，有 copyleft 性質強烈、冀求於確保軟體自由的 GPL 類條款，同時也存在接近公共領域，只講求名譽，其他一律不問的 BSD 類條款等等。若要對於軟體的用途設限，好處是在於權利人可以自由地體現其價值，但其副作用則是某種程度上將影響自由軟體所保障的自由，也會限縮開放原始碼的利用範圍、降低了授權相容性。因此，大家在選擇自由軟體授權條款時，若有打算在現有的條款中附加限制，甚至自己發明新條款來進行授權，可能還是要先考量一下前述的效果，再來決定囉！

（註一）相關連結：Stephen Shankland, 'Don't-be-evil' Google spurns no-evil software; Ryan Grove, JSMin isn't welcome on Google Code。

（註二）這 9 種類條款分別是：Apache License 2.0、Artistic License/GPL、EPL 1.0、GPL v2、GPL v3、LGPL、MIT、MPL 1.1以及New BSD等 9 種。OSI目前已認證通過的條款共計 65 種，參見，Open Source Initiative, Open Source Licenses by Name。

（註三）參見，葛冬梅，充滿烏托邦理想的四大自由，自由軟體鑄造場電子報第35期。

（註四）參見，葛冬梅，開放原始碼的十項定義 ，自由軟體鑄造場電子報第42期。

（註五）關於「自由軟體」的用語，基於不同的理念，有被稱為「Free Software」、「Open Source Software」、「Free/Open Source Software, FOSS)」以及「Free/Libre/Open Source Software, FLOSS」等，中譯則有「自由軟體」、「開放原始碼軟體」、「開放源（代）碼軟體」等等。筆者在理念上並無特別的偏好，惟在法律分析上亦宜將上述這些名詞視為同一個物件（客體）來看待，因筆者任職單位中文名稱為「自由軟體鑄造場 (Open Source Software Foundry)」，為求一貫，故以「自由軟體」一詞為中文的統一用詞。

（註六）不過，從實際的運作狀況來說，Douglas Crockford 以及後續的開發者，迄今並沒有真正利用這條「善行條款」去實際要求任一個使用軟體者「什麼事能做、什麼事不能做」。因此，亦有見解認為，這樣的善行附款其實只是一種道德宣言，就像我國民法第 1084 條第1項的「孝順條款」─「子女應孝敬父母」一樣，雖有「構成要件」，但沒有說明「法律效果」；因此從這樣的事實脈絡下認為，應該先探求當事人之真意表現，否則只就精準的文義解釋，仍可能造成與事實情狀不符之弊。
惟本文見解認為，其一旦將「善行條款」寫進授權條款的文字裡，從法律的角度來看，這就是一個具有法律效力的權利義務關係；若有人違反，授權人認為被授權人是用於惡行時，的確享有法律上的權能禁止其行為，只是事實上目前他們沒有去行使其法律上的權能而已。並且，如果認為它可能是道德宣言，我們打算利用這樣的程式碼時，還是最好先探求當事人的真意，這形同還要上討論區或寫信去問問對方到底怎麼想，不論權利人最終表示這只是道德宣言，還是權利人回應他是玩真的，都必須要經過詢問這一步；這與「不必問，只要符合條款規定就可自由利用」的典型自由軟體授權條款的情況，還是有些不同的。

（註七）反軍事利用是自由軟體界一直以來皆有討論的議題。相關連結：Tina Gasperson, Open source project adds "no military use" clause to the GPL。