對常見開源協議的理解

在使用開源**的時候，也需要注意其對應的開源協議，特別是在商業級應用中。下面就我個人針對各個常見的開源協議做個簡單的彙總和理解。

假設我們使用的開源**為 a，我們自己開發的為 b，其中使用到了a

bsd協議

1。若b開源，b中帶有a的**，則b在發布時必須帶有a的bsd協議宣告。

3。不允許用a的作者或者任何其他資訊作為b的市場推廣。

總結：自由度很大，很適合商業用途。

apache協議：

1。b發布時需要給使用者乙份apache許可。

2。若修改了a的**，則需要在該**檔案裡註明。

3。在b中需要帶有a的協議、商標、專利宣告以及a中一切要求衍生軟體/類庫宣告的內容。

4。b中包含乙個notice檔案，裡面包含apache許可證及你自己要求宣告的內容。（該內容不可與apache協議本身衝突）

總結：自由度也很大，適合商業用途。

gpl協議：

1。b必須符合gpl協議（傳染性），b必須開源、免費。

2。b發布時必須宣告自己是gpl協議。

3。允許在b中修改a的內容。

總結：不適合商用，必須是開源、免費。

lgpl協議：

1。b若修改了a的內容，修改部分及額外衍生**必須符合lgpl協議。

2。允許b中部分閉源，鏈結（link）到a或a的衍生部分。

總結：適合一定範圍內商用。

對常見開源協議的理解

在使用開源 的時候，也需要注意其對應的開源協議，特別是在商業級應用中。下面就我個人針對各個常見的開源協議做個簡單的彙總和理解。假設我們使用的開源 為 a，我們自己開發的為 b，其中使用到了a bsd協議 1。若b開源，b中帶有a的 則b在發布時必須帶有a的bsd協議宣告。3。不允許用a的作者或者任何...

常見的開源協議

關鍵字linux，傳染性 只要你用了任何該協議的庫 甚至是一段 那麼你的整個程式，不管以何種方式鏈結，都必須全部使用gpl協議 並遵循該協議開源。商業軟體公司一般禁用gpl 但可以使用gpl的可執行檔案和應用程式。gpl的出發點是 的開源 免費使用和引用 修改 衍生 的開源 免費使用，但不允許修改後...

常見開源協議

宣告變更 state changes 在 中宣告對原來 的重大修改及變更 公開原始碼 disclose source 必需公開。如果是基於lgpl協議 下，則只需使用的開源 公開，不必將整個軟體原始碼公開 庫引用 library usage 該庫可以用於商業軟體中 責任承擔 hold liable ...