essays_and_articles:openfoundry_legal_column_selected_collections_2011:淺析自由開源軟體專案與其個別元件授權條款之差異
差異處
這裏顯示兩個版本的差異處。
| 兩邊的前次修訂版前次修改 下次修改 | 前次修改 | ||
| essays_and_articles:openfoundry_legal_column_selected_collections_2011:淺析自由開源軟體專案與其個別元件授權條款之差異 [2013/10/28 12:17] – lucien | essays_and_articles:openfoundry_legal_column_selected_collections_2011:淺析自由開源軟體專案與其個別元件授權條款之差異 [2026/03/06 16:38] (目前版本) – 外部編輯 127.0.0.1 | ||
|---|---|---|---|
| 行 11: | 行 11: | ||
| 這幾年很受到歡迎的多媒體播放器與其框架專案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 授權的程式碼，也一併經引用而成為後續衍生專案不可分割的一部份了。 | 這幾年很受到歡迎的多媒體播放器與其框架專案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 授權的程式碼，也一併經引用而成為後續衍生專案不可分割的一部份了。 | ||
| - | http:// | + | {{: |
| ▲ 圖1：VLC 在 2011 年 12 月 7 日發佈的新聞稿中說明，核心引擎已經改為 LGPL-2.1 授權（註三）。 | ▲ 圖1：VLC 在 2011 年 12 月 7 日發佈的新聞稿中說明，核心引擎已經改為 LGPL-2.1 授權（註三）。 | ||
| 行 18: | 行 18: | ||
| FFmpeg 是個結合多媒體框架與播放解碼器 (codec) 的軟體專案，專案整體採用 LGPL-2.1 及其後版本授權 (LGPL-2.1+)，但是 FFmpeg 在原本標準的預設功能與程式碼之外，還額外提供了可以最佳化部份播放功能的程式碼，但與專案的主要框架不同，這些具有最佳化功能的程式碼是採用 GPL-2.0 及其後版本來授權的 (GPL-2.0+)。因此當開發者利用 FFmpeg 專案的程式碼來開發新軟體時，若是利用到 FFmpeg 的部份僅有其標準預設功能程式碼，新開發出來軟體的授權條款便可以只要考慮 LGPL-2.1 授權方式的拘束性，與利用到同採 LGPL-2.1 的 VLC 核心引擎函式庫一樣，透過既定介面來與其互動者，不需要受到 LGPL-2.1 授權的拘束，不過若是後續開發者，選擇啟動這些以 GPL-2.0 授權的額外程式碼來最佳化 FFmpeg 的衍生專案，就有可能讓整個衍生專案轉為 GPL-2.0+ 授權，影響所及，可能會讓整個新軟體成為 FFmpeg 的衍生程式，新軟體也因此可能必須要採用 GPL-2.0 來授權散布（註四）。 | FFmpeg 是個結合多媒體框架與播放解碼器 (codec) 的軟體專案，專案整體採用 LGPL-2.1 及其後版本授權 (LGPL-2.1+)，但是 FFmpeg 在原本標準的預設功能與程式碼之外，還額外提供了可以最佳化部份播放功能的程式碼，但與專案的主要框架不同，這些具有最佳化功能的程式碼是採用 GPL-2.0 及其後版本來授權的 (GPL-2.0+)。因此當開發者利用 FFmpeg 專案的程式碼來開發新軟體時，若是利用到 FFmpeg 的部份僅有其標準預設功能程式碼，新開發出來軟體的授權條款便可以只要考慮 LGPL-2.1 授權方式的拘束性，與利用到同採 LGPL-2.1 的 VLC 核心引擎函式庫一樣，透過既定介面來與其互動者，不需要受到 LGPL-2.1 授權的拘束，不過若是後續開發者，選擇啟動這些以 GPL-2.0 授權的額外程式碼來最佳化 FFmpeg 的衍生專案，就有可能讓整個衍生專案轉為 GPL-2.0+ 授權，影響所及，可能會讓整個新軟體成為 FFmpeg 的衍生程式，新軟體也因此可能必須要採用 GPL-2.0 來授權散布（註四）。 | ||
| - | http:// | + | {{: |
| ▲ 圖2：FFmpeg v. 2.0.2 中的 LICENSE 純文字檔，羅列了所有採用 GPL-2.0+ 授權的源碼檔案。 | ▲ 圖2：FFmpeg v. 2.0.2 中的 LICENSE 純文字檔，羅列了所有採用 GPL-2.0+ 授權的源碼檔案。 | ||
| 行 27: | 行 27: | ||
| 之所以有這樣現象存在，是因為 MPL-2.0 的授權特性介於 GPL 跟 BSD 之間：原則上，後續開發者修改 MPL-2.0 軟體所產生的衍生檔案，仍然必須採用 MPL-2.0 來授權，但若是一個獨立檔案裡，並未包含任何 MPL-2.0 授權的程式碼，那麼這個檔案就可以採用非 MPL-2.0 的條款來授權，只要其授權條款的具體內容，不會與 MPL-2.0 產生衝突即可。而由於 BSD 類的授權條款並不會與 MPL-2.0 產生衝突，所以我們才會在 Firefox 專案中看到許多 BSD 類條款授權的個別元件與檔案存在其中（註六）。也因此，當開發者擷取 Firefox 程式碼來開發新軟體時，若擷取的剛好僅是這些 BSD 類條款授權的源碼檔案時，那麼在應用上只需要遵守這些 BSD 類條款的授權規定即可，而毋須一體受到 MPL-2.0 所拘束。 | 之所以有這樣現象存在，是因為 MPL-2.0 的授權特性介於 GPL 跟 BSD 之間：原則上，後續開發者修改 MPL-2.0 軟體所產生的衍生檔案，仍然必須採用 MPL-2.0 來授權，但若是一個獨立檔案裡，並未包含任何 MPL-2.0 授權的程式碼，那麼這個檔案就可以採用非 MPL-2.0 的條款來授權，只要其授權條款的具體內容，不會與 MPL-2.0 產生衝突即可。而由於 BSD 類的授權條款並不會與 MPL-2.0 產生衝突，所以我們才會在 Firefox 專案中看到許多 BSD 類條款授權的個別元件與檔案存在其中（註六）。也因此，當開發者擷取 Firefox 程式碼來開發新軟體時，若擷取的剛好僅是這些 BSD 類條款授權的源碼檔案時，那麼在應用上只需要遵守這些 BSD 類條款的授權規定即可，而毋須一體受到 MPL-2.0 所拘束。 | ||
| - | http:// | + | {{: |
| ▲ 圖3：Firefox v. 18.0 中的授權資訊頁面，說明 Firefox 包含非 MPL-2.0 授權的元件，這些元件所適用的授權條款數量多達將近 60 款。 | ▲ 圖3：Firefox v. 18.0 中的授權資訊頁面，說明 Firefox 包含非 MPL-2.0 授權的元件，這些元件所適用的授權條款數量多達將近 60 款。 | ||
essays_and_articles/openfoundry_legal_column_selected_collections_2011/淺析自由開源軟體專案與其個別元件授權條款之差異.1382962664.txt.gz · 上一次變更: (外部編輯)