這是本文件的舊版！
自由軟體授權資訊的標示與SPDX
非自由軟體技術的議程→自由軟體法律授權的議程→技術固然重要→大型專案、自由軟體授權知識→辨識FOSS專案授權資訊的方法與重要性
MySQL積木圖→拼圖：快速組裝、急速上市→TIME to MARKET→FOSS的調理包→快速上菜→FOSS的雙益處→然而？並非所有的自由軟體授權方式都是相容的→水火不容、蛇吞象、牛鷺居→專案不同元件授權相容示意圖→拼圖會垮、菜會吃壞肚子→沒賺錢沒問題、有賺錢有問題
所以、OSDC，LICENSE CHECKER→捉別人的自由軟體元件時，可以用一些自動化、半自動化的掃描機制→給檔案下載連結→然而、除了知道別人的專案是怎麼授權的，接下來更重要的是→自己新創、改作他人的自由軟體專案，再釋出時應該如何標示？
常見的自由軟體授權資訊標示問題→1、網站上根本沒有擺、或是放在不顯眼的角落處→2、網站上有提示，但專案的目錄結構裡沒有說明資訊的檔案／自由軟體容許再散布，檔案裡沒有授權資訊，再散布後就誰也不知道這個檔案本來是用什麼授權的了→3、專案的目錄結構裡有說明資訊的檔案，但是個別檔案的header file裡沒有任何授權資訊／如果別人是擷取個別元件的檔案，沒有改寫或是改寫後再散布出去，那麼還是誰也不知道這個檔案原本是用什麼方式授權
妥善登錄軟體的授權資訊能降低未來的侵權風險→做的不夠好VS做的更好→1、在專案首頁加上簡要的授權標示資訊、然後再讓這個標示連結到一個專責的說明頁面→2、編寫檔案時，將授權簡要資訊加到該檔案的header file裡→建議要有「專案名稱」、「著作權利人姓名」、「創作年份」、「專案網址」、「所使用授權條款的名稱」→例如：LF Converter-1.0、2011 © 林誠夏、http://lf_converter.fakelink.com、Release under GPL-3.0+」→3、釋出時的第一層目錄，README、LEGAL，授權相關資訊→4、釋出時的第一層目錄，COPYING、LICENSE，LINUX KERNEL→5、釋出時的第一層目錄，THIRDPARTYLICENSE→6、單純過手、授權相關檔案全部保留→7、改作他人元件時，記得同步更新THIRDPARTYLICENSE。
SPDX、Software Package Data Exchange→Blackduck, Canonical, Motorola, HP, Intel, OpenLogic, nexB, Source Auditor, Cisco + Linux Foundation→Project of Linux Foundation→業界共通的FOSS授權資訊標示標準→八月中旬的LinuxCon North America→目的：A、提升流通速率，B、降低侵權風險→1、軟體套件資訊(package info)與個別檔案資訊(per file info)：專案套件與個別檔案中的著作權聲明、授權條款列表與相關評論、軟體套件名稱、檔案名稱、下載位置、版本對照檢驗方式(checksum)、技術描述資訊…→2、授權資訊：按步就班的表格將該被記錄的授權資訊填註到軟體專案裡，並隨著程式碼一併散布出去→重整授權條款縮寫表：簡名為首、以半形符號「-」連接授權條款版本別及其他重要資訊，例如「GNU General Public License v2.0 及其後版本」“GPL-2.0+“，「GNU General Public License v3.0加上GCC編譯器例外條款」”GPL-3.0-with-GCC-exception”→3、分析資訊：兩套後設資料(metadata)的標準，一為tag、二為RDF。→未來可能產生的影響？→SPDX第一版規格書的下載節點：http://spdx.org/spec/current
給專文網址和頁面(自由軟體授權資訊的標示說明與SPDX)
