為了要解決工作上所需處理的授權分析問題，筆者常會需要了解一個專案究竟利用了哪些自由軟體元件，以及這些元件是採用哪一份自由軟體授權條款？這些工作通常得透過人工進行，也就是請實際開發專案的工程師提供他們的軟體架構圖，並且查詢這些軟體元件適用哪些授權條款，等到取得這些資料後，才有辦法進行後續的授權分析，以研擬授權衝突的解決方案。若涉及的自由軟體元件僅三、四個，那這樣的人工作業尚不困難，但若是牽涉到幾十個自由軟體授權元件，那就得花上好一番的功夫來進行人工作業。因此為了簡便這些授權分析的流程，近年不少團隊就此需求建置了自由軟體程式碼掃描的自動化系統，以掃描軟體專案程式碼的授權方式，並進一步列出報表以顯示該專案裡自由軟體元件的利用情形，以及所使用到自由軟體元件的授權細節。

近半年來，筆者接到的一些諮商問題，不約而同地詢問到哪裡可以找到這樣的掃瞄系統，因此透過本文來介紹幾套這類型的掃瞄系統，提供給想要了解這方面資訊的朋友一個初步的參考（註一）。但由於筆者本身並不具有程式開發的技術背景，因此介紹的內容，將僅就這類系統在授權分析方面的特點加以描述，而不針對技術細節來進行說明。

以自由軟體授權元件來加速產品開發已漸成時代趨勢，但許多著名的自由軟體授權條款皆帶有 Copyleft（註一）性質的授權拘束性，其拘束散布這些自由軟體授權元件目的碼（Binary code）及其衍生作品（Derivative Works）者，亦有義務一併提供該元件的原始碼（Source code）予收受程式的後手，所以連帶的要求散布者亦需盡相當程度的「標示義務」。

所謂的「標示義務」是說，散布者在散布該自由軟體授權元件的當下，須得開宗明義的將該元件的授權狀態提示予後手知悉，並應進一步說明該元件原始碼的取得途徑給後手知道。以使用率非常高的 GPL 授權條款為說明範例的話，其要求內含 GPL 授權元件的產品釋出時，皆需要有個顯著清楚的標示，說明該產品中哪些部份是內含 GPL 授權程式碼的元件，並進一步告知使用者有取得該元件原始碼的權利，以及後續取得這些原始碼的方式。這樣的理論說來簡單，但實際上國內外精準完成此項義務的廠商並不多見，所以以下即以 gpl-violations.org 所撰寫的「商用常見問答集（註二）」為說明基礎。

自由軟體支持者向來反對軟體專利 (software patent)，但現實上專利制度並無法輕易被改變，導致開發者在運用自由軟體的過程中面對了 FUD (fear, uncertainty, doubt) 的不安。所以近年許多新改版的自由軟體授權條款常會一併要求程式碼授權人同時授權其專利，例如 GPL 第 3 版的序言及第 11 條中就說明，任何寫入 GPL 程式的軟體專利必須以允許他人自由使用為前提，否則就不應寫入 GPL 專案裡；但是如果專利權人根本就未將其專利依相關條款授權，專利侵權的魅影將無所不在。

※ 編按：原「法律源地」專欄，自本期開始更名為「法律專欄」。名稱改變、堅持不變！透過法律專欄，自由軟體鑄造場將會持續提供給您一個與眾不同的角度，來認識自由軟體。

自由軟體授權條款種類眾多，不論在理解或選擇上，都帶給使用者不少的困擾，於是，如何能簡化理解或選擇的步驟，便成為值得研究的議題。
在台灣，自由軟體鑄造場 (Open Source Software Foundry, OSSF) 幾年前就陸續開發了授權指引 (license wizard) 及製作授權條款比較表，幫助專案發開者選擇合適的授權條款（註一）；在國外， Creative Commons （簡稱 CC ）也曾推出 GNU General Public License （簡稱 GPL ）、 GNU Lesser General Public License （簡稱 LGPL ）及 BSD 這三種自由軟體授權條款的授權標章 (Commons Deed) 及數位標籤 (metadata)，這些都是為了減少使用者理解與選擇授權條款的困擾。而去年（2009 年）底負責歐洲自由軟體基金會 (Free Software Foundation Europe) 法律事務的 Adriaan de Groot ，從創用 CC 授權條款 (Creative Commons licenses) 的授權標章得到靈感，也利用了不同的圖像 (icon) 來代表自由軟體授權條款的重要元素，並選擇較廣為使用的十來種授權條款，以表格方式呈現，讓人一目了然這些授權條款的異同（註二）。