open source授權條款比較表 2.3
http://www.openfoundry.org/tw/comparison-of-licenses
授權條款比較表 2.3
| 原 始 程 式 | ||||
| 您要求他人再散布程式時必須提供原始碼嗎？ | 您允許他人對程式進行再授權嗎？ | 您願意將程式所包含的專利授權出來嗎？ | 若是散布程式時，不包含原始碼在內，而是另外提供原始碼，此時您允許收取散佈原始碼的費用可以高於散布成本？ | |
| MIT | 否 | 是 | 否 | 是 |
| BSD | 否 | 否 | 否 | 是 |
| zlib / libpng | 否 | 否 | 否 | 是 |
| Apache 1.1 | 否 | 否 | 否 | 是 |
| Apache 2.0 | 否 | 是 | 是 | 是 |
| Artistic | 是 | 否 | 否 | 是 |
| CPL 1.0 | 是 | 是 | 是 | 是 |
| MPL 1.1 | 是 | 是 | 是 | 是 |
| LGPL 2.1 | 是 | 否 | 否 | 否 |
| GPL 2.0 | 是 | 否 | 否 | 否 |
| 修 改 程 式 | ||||
| 您允許程式被修改後使用不同的授權條款嗎？ | 承左題，您願意在什麼狀況下允許使用者選擇符合自己需求的授權條款呢？ 0. 使用者只能採用原本的授權條款。 2. 我希望使用者選擇我所指定的授權條款。 3. 只要不和原本採用的授權條款相違背，使用者可以自行決定授權內容。 | 您要求程式被修改後必須公開原始碼嗎？ | 您要求後續修改者修改程式時必須附加修改說明文件嗎？ | |
| MIT | 是 | 3 | 否 | 否 |
| BSD | 是 | 3 | 否 | 否 |
| zlib / libpng | 是 | 3 | 否 | 是 |
| Apache 1.1 | 是 | 3 | 否 | 是 |
| Apache 2.0 | 是 | 3 | 否 | 是 |
| Artistic | 是 | 3 | 是 | 是 |
| CPL 1.0 | 否 | 3 | 是 | 否 |
| MPL 1.1 | 是 | 2 | 是 | 是 |
| LGPL 2.1 | 否 | 0 | 是 | 是 |
| GPL 2.0 | 否 | 0 | 是 | 是 |
http://www.openfoundry.org/tw/compatibility-of-licenses
相容性
http://www.openfoundry.org/tw/foss-license-category
授權條款分類表
| 分類 | 授 權 條 款 | 全 名 |
| BSD類 | ||
| Apache-1.1 | Apache Software License 1.1 | |
| Apache-2.0 | Apache License 2.0 | |
| BSD-3-Clause | New BSD License | |
| MIT | MIT License | |
| Zlib | Zlib/libpng License | |
| GPL類 | GPL-2.0 / 3.0 | GNU General Public License 2.0 / 3.0 |
| LGPL-2.1 / 3.0 | GNU Lesser General Public License 2.1 / 3.0 | |
| AGPL-3.0 | GNU Affero General Public License 3.0 | |
| 其他類 | CPL-1.0 / EPL-1.0 | Common Public License 1.0 Eclipse Public License 1.0 |
| MPL-1.1 / 2.0 | Mozilla Public License 1.1 / 2.0 | |
| CDDL-1.0 | Common Development and Distribution License 1.0 | |
| Artisic-2.0 | Artistic License 2.0 | |
修改或取用的注意事項
您當然可以修改自由軟體的原始碼，或者是取用原始碼到自己正在撰寫的新程式當中，但是有些規定必須要注意與遵守。由於各授權條款間的內容差異頗大，有時甚至南轅北轍，因此以下所列僅為鑄造場認為較重要的幾點注意事項，並無法涵蓋所有授權條款的完整內容，以及個別的特殊規定。不過，下列前兩項是很基本的的要求，鑄造場建議您一定要遵守，後兩項要求在各條款間的規定就頗有差異，您若仍有疑問或有必要進一步了解相關細節的話，請參考法政中心的各授權條款的中文介紹，或來信鑄造場詢問。
（一）請保留軟體中的標示 (notice)
這是最基本的一項：除非真有必要，否則軟體中的任何標示請不要拿掉，例如著作權標示、軟體不附擔保的說明標示等。雖然並非所有的條款均強制要求保留所有的標示，但是因為不同條款規定略有不同，最保險與簡單的原則就是原封不動地保留所有標示。若您真的需要變動或修改這些標示的話，就有必要詳閱授權條款中關於刪留這些標示的規定。
（二）標明軟體已經過修改
許多的授權條款會要求，您必須要在修改的檔案中標明這個檔案是被修改過的，並且加上修改日期，有些條款則並未有相關規定。也有像 Artistic 這一系列 的條款，則是要求必須另外附上說明檔案，描述檔案的修改歷程，以及修改後的檔案與原檔案有什麼不同之處等等。 由於這類的規定相當分歧，若您不知道所修改的自由軟體的授權條款規定如何，鑄造場建議您在修改的檔案中至少標明該檔案已被修改過以及修改日期，這樣的標明方式可以讓之後拿到修改軟體的人知道你修改過哪些檔案，算是滿足最低的標示要求。當然最佳的情況下，您若是可以將如何修改檔案說明清楚，對於未來要研究與修改這個軟體的其他人將可以產生很大的幫助。
（三）要提供取得原始碼的管道
若修改或取用的自由軟體採用 GPL2、GPL3、LGPL2、LGPL3、MPL、CPL、EPL 或 CDDL 等條款授權，原則上，您必須要將修改過的程式或者新結合程式的原始碼提供給他人。但是各條款中對於修改與取用的細部規定不盡相同，所以在合於各授權條款規定的情況下，修改過的自由軟體或取用自由軟體程式碼而新寫出來的程式，也有可能不需要將原始碼再提供給他人。關於這方面的規定，各條款間的差異頗大，若您沒有什麼特殊考慮因素的話，鑄造場建議您可以將所有新增或修改過的原始碼都提供出來，讓有興趣的人可以來研究你的原始碼，一同分享、討論撰寫原始碼的各種心得。若您因為一些因素，不願意或者無法將新增或修改的原始碼提供給他人時，就必須要詳閱各授權條款的細部規定，看不提供原始碼的散布行為是否合於條款規定。若是不符合的話，這時候最好的方式就是將程式保留在自己手上使用，而不要散布您修改過的程式或新程式給其他人。
（四）請注意授權條款之間是否相容
自由軟體的原始碼因為可以自由取得與利用，所以您很可能從網路上抓了不同的程式碼，放在同一個程式中使用。這些程式碼的授權條款若都一樣，就可以不必擔心條款的內容有所衝突，若程式碼授權條款不同的話，就必須要注意這些條款的內容是否彼此相容。關於自由軟體授權條款的相容性，您可以參考下列中文資訊：「決定未來程式被利用與發展的方式」； 「授權條款相容性」。 若您有個別的條款相容性問題，歡迎直接與鑄造場聯絡。
商業產品釋出源碼的實用提醒
1. BusyBox 設定檔
您需要提供 BusyBox 相關的設定資訊，讓他人可以根據這些資訊將 BusyBox 建置成為原始碼的一部分。而隨著 BusyBox 版本的不同，設定資訊相關檔案的名稱也會有所不同：在 BusyBox 0.60.5 及之前的版本，檔案名稱是 Config.h，在 BusyBox 1.00-pre1 及之後的版本，檔案名稱則是 .config。
2. Linux kernel 設定檔
假如您的產品利用到 Linux kernel，您必須要將相關的設定資訊提供出來，讓他人可以根據這些資訊將 Linux kernel 建置成為原始碼的一部分。
3. 額外的 Linux kernel 模組
假如您的產品有利用到額外的 kernel 驅動程式，您可能必須要提供這些驅動程式的原始碼。您應仔細了解這些驅動程式的授權條款內容，以確認是否需要提供原始碼。
4. C 函式庫
假如您的產品利用到 glibc 或 uClibc 函式庫，您必須要提供這些函式庫的原始碼。假如相關的軟體開發套件 (SDK) 只有二進位碼，並且是由您的上游供應商所提供的，此時您需要向上游供應商索取原始碼，以便這些函式庫的原始碼能提供出來。
5. 目的檔
假如您的程式將非自由軟體程式碼連結到 LGPL 2.1 授權的程式碼，那麼您就需要提供目的檔與建置所需要的設定資訊，這代表者編譯描述檔 (Makefile) 等資訊也在提供之列。
例如：
liborz-0.11 採用 LGPL 2.1 授權，您的程式 bar 中的 foo.o 檔案連結利用 liborz-0.11。此時，為了滿足 LGPL 的要求，您必須提供 liborz-0.11 的原始碼、foo.o 的目的檔以及結合這兩者的編譯描述案 (Makefile)。
6. 開機管理程式
許多裝置是包含著 GPL 授權的開機管理程式 (Bootloader) 出貨的，例如： ARMboot、PPCboot、RedBoot 或 u-boot 等。假如開機管理程式 GPL 授權的話，您必須要提供這些程式的原始碼給您的客戶。若這些開機管理程式是您的上游供應商提供的話，上游供應商必須依照 GPL 規定給您原始碼。
7. 工具程式
若您隨著產品裝置或是在網路上散布二進位的工具程式（編譯器、binutils、C 函式庫），您就需要讓他人也可以取得這些工具程式的原始碼。工具程式通常是包含在軟體開發套件 (SDK) 裡面，並且由您的上游供應商提供，因此您可以向他們索取原始碼。
8. 韌體
因為許多不同的產品都是從同一個原始碼樹狀結構 (source tree) 中產生出來，因此韌體中常會包含一些其他裝置才需要的多餘程式，假如這些多餘程式是採用 GPL 或 LGPL 授權的話，當散布韌體時，您也必須提供這些多餘程式的原始碼。此時您有兩種不同的解決方法：您可以如前面所描述的那樣，提供他人原始碼，或者您也可以將這些不會被用到的程式從原始碼樹狀結構中刪除。
GNU Lesser General Public License
From Wikipedia, the free encyclopedia
Differences from the GPL[edit]
The main difference between the GPL and the LGPL is that the latter allows the work to be linked with (in the case of a library, 'used by') a non-(L)GPLed program, regardless of whether it is free software or proprietary software.[1] The non-(L)GPLed program can then be distributed under any terms if it is not a derivative work. If it is a derivative work, then the program's terms must allow for "modification for the customer's own use and reverse engineering for debugging such modifications." Whether a work that uses an LGPL program is a derivative work or not is a legal issue. A standalone executable that dynamically links to a library through a .so, .dll, or similar medium is generally accepted as not being a derivative work as defined by the LGPL. It would fall under the definition of a "work that uses the Library". Paragraph 5 of the LGPL version 2.1 states:
- A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked library is allowed if either source code or linkable object files are provided.[2]
留言