每一個自由/開放源碼專案在釋出時，都會遭遇到一個問題：應該為自己的程式選擇那一個授權條款？因為著作權人對於未來運用程式構想不盡相同，所以這是一個可大可小的問題。

若著作權人相當認同自由/開放源碼理念，希望可以提供他人最大的機會取得原始碼，那麼 GPL 類（註一）的授權條款就很適合，因為 GPL 類條款承襲 copyleft 精神（註二）， 讓取得程式之人也有取得原始碼的權利，即使程式被修改後也一樣。若是不拘原始碼是否一定可以被取得，而僅希望程式可以被他人廣泛地再利用，則可以選擇 BSD 類的條款，這類條款的授權範圍都很大，拿到程式之人幾乎可以不受限制地任意利用程式，就算是採用不同的授權內容再次運用也是允許的。
不過以上這種 GPL 類或 BSD 類的判斷方式是很初步的，適用於單純沒有特殊條件的專案，而大多數的專案或多或少都會有一些既有的條件或要求限制，例如：使用既有程式碼開發專案，因此必 須遵守這些既有程式碼的授權條款；希望程式未來商業化運用等。前者的情況，就必須要看所使用程式碼的授權條款內容為何，各條款內容差異大，不過若所使用的 是 BSD 類的程式，就有很大的空間來為新開發出來的專案程式選擇授權條款，若屬於 GPL 類，新開發出來的專案在沒有例外的情況下，通常仍然必須採用一樣的授權條款。後者的情況，還要看商業化的模式而定，若希望開發出來的程式為他人自由修改與 運用，那一樣可以採用 BSD 類來授權；若準備採取雙重授權，根據目前的經驗，不少公司採用 GPL2 與封閉原始碼商業授權並行的模式，此外，也有像 MPL 的彈性多重授權模式：被授權人可以為特定部份程式碼選擇非 MPL 授權條款，不過可以選擇的授權條款必須在著作權人特定的範圍內。

不過無論是哪一種情況，最重要的是在於儘早規劃，最好是可以在專案一開始的時候就規劃好程式未來的運用方式，然後依照所規劃的運用方式來 開發並選擇授權條款，這樣可以避免被其他程式授權條款綁住的困擾。有些人在程式要釋出之際，才開始真正思考要採用哪一份授權條款，他們對於程式的運用有一 些既定的想法，可是在開發過程中已經使用其他既有的程式碼，新開發程式必須受到既有程式碼授權條款的限制，變得無法完全依照自己的想法來授權程式。若是可 以在專案開始之際就規劃討論要適用的授權條款，開發過程也避免使用到與規劃條款內容不相容的程式，就可以將此種問題發生的機率降到最低。由此可知，授權條 款的選擇雖然只是一個中間程序，卻會影響之前的開發過程與後續的運用模式。


此外，盡量選擇現行通用的授權條款，如此可以避免專案程式無法與其他程式結合運用的困擾。一般情況下，著作權人大多希望專案程式可以廣為 散布與利用，選擇與大部分自由/ 開放源碼軟體相容的授權條款可以讓專案程式容易為他人再運用，目前一般常用的 GPL2、BSD、MIT、Apache 2.0 等都是很好的選擇考量。不過若是對於專案程式的運用有特定構想，現有的常用授權條款很有可能無法滿足構想內容，那就必須要個案處理，另行尋找適合的授權條 款。不過，筆者在此仍然強烈建議，盡可能地採用現行常用授權條款，因為目前自由/開放源碼授權條款眾多，各條款內容不盡相同，甚至相互衝突不相容，這使得 程式開發遭遇問題，為了不讓這些問題繼續擴大，維持現行常用授權條款數量是一項重要的手段。

決定授權條款的過程可簡單可複雜，端視著作權人對於程式運用規劃內容而定，而無論是一般的社群專案，還是業界公司所開發預計商業化的產品，及早規劃都是必要的，將可以避免許多後續不必要的麻煩。

註一：關於授權條款的分類，請見：葛冬梅，自由/開放源碼授權條款的三分法 ，開放鑄造場電子報，第72期。

註二：關於copyleft，請見：葛冬梅，讓人既愛又頭痛的 GNU/GPL ，開放鑄造場電子報，第33期。 註三：本文所提到的各授權條款內容介紹，請參見：授權條款介紹 ，OSSF：自由軟體鑄造場。