本文原刊登於自由軟體鑄造場的法律專欄。
這是一篇有趣的文章，文章靈感來自於近日跟一位業界工程師所聊到的一段話，當時他表示有些自由開源軟體專案的授權還蠻複雜的，因為專案整體標示的是一種授權，但是裡面卻可能包含許多其他不同授權的程式碼，一不注意的話，可能就會誤解授權義務規定，而有侵權利用的狀況產生。這讓我想到，前一陣子處理的諮詢問題中，剛好也有開發者誤認元件授權條款跟專案整體授權條款一樣，最後必須置換元件的實例，因此而有了撰寫這篇文章的想法。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
有經驗的開發者在利用自由開源軟體時，會主動了解軟體專案所適用的授權條款，以遵守授權義務規定的方式來應用自由開源軟體。但是，不少開發者可能容易忽略的是，有些自由開源軟體專案裡，還可能包含或附帶與主專案框架不同授權條款的元件，若是應用專案的方式涉及到這些元件的話，便可能會在實際應用上產生完全不同的效果。
【個案實例】
1、關鍵引擎採用 LGPL-2.1 授權的 GPL-2.0 專案：VLC
這幾年很受到歡迎的多媒體播放器與其框架專案VLC，就是一個很顯著的例子。VLC專案整體採用 GPL-2.0 授權，但是為了讓 VLC 可以持續地被應用在 Linux、Windows、Mac OS X、Android 等不同平台上，該專案的開發者在 2011 年決定，要將 VLC 的關鍵引擎改用 LGPL-2.1 來重新授權（註一），這是因為 LGPL-2.1 對於函式庫的利用方式有著較為彈性的規定，使用者只要在合於授權規定的方式內，透過函式庫既定的介面來與其互動存取資料，則新開發出來的軟體，就可以適用非 LGPL-2.1 條款的方式來授權散布，甚至必要時也有機會採取封閉源碼的方式來授權新軟體。因此當開發者僅利用到 LGPL-2.1 函式庫或程式碼的話，就有著根據 LGPL-2.1 授權規定來開發私有軟體 (proprietary software) 的彈性空間（註二），但若是開發者確實是利用到整個 VLC 專案的程式碼，包括 LGPL-2.1 授權的函式庫，以及 GPL-2.0 的播放框架時，便可能必須一體遵守 GPL-2.0 的規定，因此時 GPL-2.0 授權的程式碼，也一併經引用而成為後續衍生專案不可分割的一部份了。