登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
討論區
关于商业软件中多个license的问题 (1 位瀏覽者) (1) Guest
Go to bottom Favoured: 0
TOPIC: 关于商业软件中多个license的问题
#610
关于商业软件中多个license的问题 2010/10/06 18:29  (9 Years, 1 Month ago) Karma: 0  
Hi:everyone
项目背景是这样的:我们要开发一款软件系统,在该系统中会使用到一部分第三方的开源软件,包括以下协议授权的软件
1、Apache 1.1
2、Apache 2.0
3、BSD
4、MIT
5、PostgreSQL License (www.postgresql.org/about/licence
6、Eclipse Distribution License v1.0 (www.eclipse.org/org/documents/edl-v10.php
7、Eclipse Public License - v 1.0 (www.eclipse.org/legal/epl-v10.html
8、MPL

项目的要求:
1、由于是商业软件,我们不能提供或者说是不能公布我们自己编写的源代码
2、我们对这款软件可以保留版权(及我们能决定授权给哪些人使用)

我们以前就了解到apache2.0 bsd mit PostgreSQL License都是bsd类似的license(PostgreSQL 官方也这么说),给人的使用权限都比较宽泛,这4个授权方式应该可以满足我们的项目要求。我们最大的疑问就是以上授权的开源软体在一起使用的时候能否满足我们的项目要求,如果不满足我们将不会使用相应的授权软件

期待您的解答,谢谢:
ABD (User)
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
Last Edit: 2010/10/06 18:31 By ABD.
 
The administrator has disabled public write access.  
#612
Re:关于商业软件中多个license的问题 2010/10/07 22:32  (9 Years, 1 Month ago) Karma: 10  
Hi ABD,

您所提到的「1、Apache 1.1;2、Apache 2.0;3、BSD;4、MIT;5、PostgreSQL License」,都符合您的需求。

但特別要提醒的是、BSD類別的授權條款僅授權「著作權(Copyright)」予使用者使用,

如果您所選用的BSD類別軟體元件其中內含已經註冊的商標(Trademark)的話,

記得再散布衍生程式時要把這些商標手動去除,

或是和原來的商標權利人洽談商標權的授權費用。

但另外您亦同時列舉的「6、Eclipse Distribution License v1.0;7、Eclipse Public License - v 1.0;8、MPL」是屬於第三分類的自由軟體授權條款。

這類的授權條款帶有「部份的COPYLEFT特性」,

視情況可能會被稱為「file-based COPYLEFT」或是「module-based COPYLEFT」 ,

COPYLEFT簡單來說就是您修改了它程式的本體,

再散布時這個程式的衍生作品就必須要依原來的授權方式來散布,

所以修改了MPL授權的元件、再散布時一樣要用MPL來授權,

修改了EPL授權的元件、再散布時一樣得用EPL來授權,

但第三類自由軟體授權元件與GPL授權元件最大的不同在於,

其在授權上並不具完全的「擴張性」,

例如MPL規定自行編寫的獨立檔案、並不會受到MPL授權程式的拘束,

EPL規定自行編寫的獨立的模組,亦不會受到EPL授權程式的拘束。

所以依您所描述,

完全符合您的需求和期待的會是BSD類別的自由軟體授權元件,

至於EPL、MPL授權的元件,

則要個案看這些第三類授權狀態的程式,

在整個產品中所佔的角色、地位,以及和其他元件的互動關係(Interation)來個案判定。

希望上述的資訊對您有所幫助。

有問題歡迎後續接著討論。

20101007 Lucien C.H. Lin
lucien (Admin)
Moderator
Posts: 157
graph
User Offline Click here to see the profile of this user
Logged Logged  
 
Last Edit: 2010/10/07 22:34 By lucien.
 
The administrator has disabled public write access.  
#613
Re:关于商业软件中多个license的问题 2010/10/08 01:16  (9 Years, 1 Month ago) Karma: 0  
Hi,Lucien
我的疑问是:
1、如果一家企业在项目中使用了第三方的EPL,MPL授权的软件,并且在项目中修改了EPL,或者是MPL授权的软件(即使是一个字符),那么就不再满足上述要求?

2、找了一个使用EPL软件的例子,比如zend guard是一款基于eclipse rcp开发的一款商业软件,软件的界面显示没有eclipse rcp就不能运行,www.zend.com/en/products/guard/downloads。zend guard 并没有使用epl发布和开源,那么就是意味着两种情况:1、zend guard向eclipse基金会缴纳了额外的一笔授权费用,获得商业开发的权限;2、zend guard的做法是错误的应该使用EPL的协议发布zend guard?

3、
(a 代表EPL自由软件程式) (b 代表企业开发程式)
互动关系
(1)、b中配置文件(XML,properties,ini等)中配置a中的类
比如: org.hibernate.ejb.HibernatePersistence
(2)、b中的类中引用a中的类
比如:
import com.eclipse.look.DTFF;
public class LookSystem {
//....
}
(3)、a是一个完整的应用软件:比如一个b中有一个startup.bat去启动a,并不修改a中的任何程序
是不是只要一但在企业开发的b程式中使用到了(2)的情况就不再满足要求,必须使用EPL授权;或者是还得看角色和地位?

4、
比如有如下模型分析
角色: 低 中 高
地位: 低 中 高
EPL的开源程式a在企业开发的产品b中的只要是地位和角色二者中有一个所处的环境为“高“,那么不管互动关系是什么情况那么就必须用EPL对产品b授权,也就是不满足我们的要求。
反过来说,如果a与b之间互动关系要求使用EPL,是不是即使a的角色和地位再低那么都得使用EPL授权


5、如果没有修改EPL,MPL授权的软件,是否满足要求就要看上文中所提到的“在整個產品中所佔的角色、地位,以及和其他元件的互動關係(Interation)來個案判定。”

在下面尽可能的总结列出了EPL,或者MPL授权的元件在整个产品中所处的7种不同程度的,角色和地位


A、该元件是图标(虽然图标不是某种意义上的软件,但是网上确实有很多epl,gpl授权的图标)

B、该元件是look and feel(通俗说就是主题外观),没有该元件,整个产品仍然可以正常运行。
互动关系以java程序为例,需要在企业开发的软件中引入一行EPL程式代码比如
import com.eclipse.look.DTFF;
public class LookSystem {
//....
}

C1、该元件是一个EPL授权的在线编辑器,一家企业在自主开发的CMS产品中使用到了EPL的在线编辑器元件
C2、一家企业在自主开发的CMS产品中使用到了fckedtior(gpl lgpl mpl)的在线编辑器元件
C3、该元件是一个CSS网页样式的类库

D、该元件是一个框架,没有该元件整个软件就不能正常运行

E、该元件是一款数据库(用于辅助功能)。比如说firefox就是用到了Sqlite(public domain),Sqlite元件只是用于firefox的辅助功能比如说存储浏览器的浏览记录,firefox的主要功能浏览网页并不需要用到sqlite。没有sqlite,firefox的部分功能不能使用。
如果一家企业开发了一款浏览器,并且使用到了一个EPL授权的数据库元件,那么是否还满足不公开源代码,按照自己的方式来授权的要求呢?

F、该元件是一款数据库(用于主要功能)。比如说一家企业开发的物料系统中用到的数据库元件。没有该元件,物料系统的功能几乎不能使用。

G、该元件是对某一个规范或者标准的实现。比如说 eclipselink(EPL EDL)是oracle 制定的jpa规范的一个实现元件。一家企业在开发的流量系统中用到了eclipselink元件。
值得注意的是:eclipselink(EPL EDL)openjpa(Apache 2)Hibernate(LGPL)都是jpa规范的实现元件,使用以上三种元件之一开发的产品可以通过修改配置文件实现轻松的切换。B与G不同的是,B可以不要该元件程序也可以正常运行,G中没有eclipselink,openjpa,Hibernate三者之一程序就不可运行。
其中的互动关系是:
还是以(a 代表自由软件程式) (b 代表企业开发程式)
在b中并不会调用任何a的程序代码,因为a中实现的都是jpa(java api)的规范,调用的都是java api,但是需要一部分配置文件。


Thank you
ABD (User)
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
Last Edit: 2010/10/08 05:13 By ABD.
 
The administrator has disabled public write access.  
#622
Re:关于商业软件中多个license的问题 2010/10/19 00:29  (9 Years, 1 Month ago) Karma: 10  
Hi ABD,

抱歉我上一封回文並沒有說得非常清楚,

因為我稍有誤解您原來項目的要求條件:
1、由于是商业软件,我们不能提供或者说是不能公布我们自己编写的源代码
2、我们对这款软件可以保留版权(及我们能决定授权给哪些人使用)

如果嚴格要達到上述條件,確實只能利用BSD/MIT類別的自由軟體來開發您的產品。

但是、如果您將要求條件改為:
1、由於是商業軟體,我們不能提供或是不能公布我們自行編寫「那一部份」的源代碼
2、我們對這個產品的要求是,原來以自由軟體授權方式授權的元件可以依其本來的授權模式散布,而我們自行編寫的部份可以保留版權,並且自行決定這些授權要給哪些人使用。

如果是上述的條件,那麼可以用來加入產品開發的自由軟體元件,就可以包括MPL/CDDL/EPL/CPL這種第三類別的授權元件。

因為MPL/CDDL/EPL/CPL這類的自由軟體,其在LINK、MERGE上的解讀方式並不完全類同GPL授權程式那般的擴張,也就是說、這類的開源軟體雖然倒具有COPYLEFT的性質,但一般會被稱為是FILE-based COPYLEFT,而非完全類同GPL式的Link-based COPYLEFT。也就是說、改寫了原來以MPL/CDDL/EPL/CPL授權元件的核心部份,如果是修改同一個檔案上的源代碼或是BINARY CODE,那麼再散布這部份程式一樣得依MPL/CDDL/EPL/CPL的授權模式來走,但另外編寫、而是獨立檔案(FILE)、模組(MODULE)的那一部份,就可以用自己想要的授權方式來與MPL/CDDL/EPL/CPL授權的元件一起散布,重點是這二部份的授權狀態不會互相干擾。

簡單來說就是,如果您的產品內含了MPL/CDDL/EPL/CPL授權的元件,並且整個元件都統合為一個整合過的衍生作品(Derivative Work),那麼您將失去決定這個統一作品著作權宣告模式的自由;但是、若是您可以將自行編寫的部份,依MPL/CDDL/EPL/CPL個別的規定與其核心元件做區隔處理,那麼您就可以依MPL/CDDL/EPL/CPL元件原來的授權方式來散布這些元件,同時用自己選定也與MPL/CDDL/EPL/CPL不衝突的其他授權方式來散布自己編寫部份的程式碼。

所以、我以上面的立論基礎來回答您下面的問題:

1、如果一家企业在项目中使用了第三方的EPL,MPL授权的软件,并且在项目中修改了EPL,或者是MPL授权的软件(即使是一个字符),那么就不再满足上述要求?

您無法主張這個產品中所有的程式碼都完全依您自行律定的授權方式來散布,該EPL/MPL授權的軟件,即使只是修改一個字符,都須依其本來的授權方式來散布;然而、您自行編寫並可區隔的程式碼,便可依您自行指定且與MPL/EPL不相衝突的其他授權方式來散布。

2、找了一个使用EPL软件的例子,比如zend guard是一款基于eclipse rcp开发的一款商业软件,软件的界面显示没有eclipse rcp就不能运行,www.zend.com/en/products/guard/downloads。zend guard 并没有使用epl发布和开源,那么就是意味着两种情况:1、zend guard向eclipse基金会缴纳了额外的一笔授权费用,获得商业开发的权限;2、zend guard的做法是错误的应该使用EPL的协议发布zend guard?

我的判斷是,Zend Guard符合EPL關於獨立模組的定義,從而其可以用自己的授權方式來散布,而不會必然受到EPL的限制。

Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program.

3、以下都是EPL程式與自行編寫程式之間互動關係的類型化判斷。

我想這部份的問題比較複雜,我先就原則回答。

原則就是某些程式碼若必然得「基於原程式元件」方可「再創作出來」的,那就會被視為原程式的「衍生作品(Derivative Work)」,那麼這部份衍生作品的授權方式,將會受限於「原程式元件的授權模式」,這是因為版權法(COPYRIGHT LAW)預設改作原作品、或是依原作品重新創作出衍生作品的權利是專屬於原作者,所以若要對某個程式著作重新創作的話,需要先取得該程式元件作者的預先授權,或是符合其預設的自由軟體授權條款的相關規定。

但是關於怎麼樣的改作或是依賴行為算是原作品的衍生著作,則不同的自由軟體授權原件對於這個改作範圍的解讀有寬嚴不同的態度。GPL對於衍生作品的定義範圍算是比版權法的預設還要嚴,而、MPL/EPL/CPL/CDDL這類的授權方式,我個人認為認定改作的範圍要比版權法的預設還要鬆一些。以Mozilla Firefox為例,FIREFOX上許多的插件(PLUGIN)皆依賴於FIREFOX這個BROWSER的主架構,但MOZILLA FOUNDATION並沒有嚴格要求這些PLUGIN皆須依MPL或是GPL/LGPL來授權(FIREFOX其實是三重併行授權:MPL/GPL/LGPL)。所以MPL常被稱為是FILE-based COPYLEFT,也就是說、除非寫入同一個以MPL授權的檔案(FILE),否則其他自行編寫程式碼的授權方式,原則上只要與MPL授權的主元件互不干擾即可。然而、這是MPL FOUNDATION的運作態度,並不必然能完全推論到EPL授權的元件上。

而回歸EPL的授權文字,其特別指出:

Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program.

所以、依這段文字的解釋,確實、細部就會進入您所提出的,哪一種互動關係算是原作者的Derivative work(依賴於原著作而產生的衍生著作),哪一種互動關係不算入原程式衍生著作的討論。

然而、EPL就衍生著作的判斷其實並沒有特章說明,沒有特別說明的話,就應該是回歸版權法(COPYRIGHT LAW)的預設。

下篇待我較有回答餘裕的時候,就會依你提出的這幾點範例,就版權法目前討論的通說來說明,哪些互動模式可能會被視為原程式的衍生作品,哪些互動原則上不會被視為原著作的衍生作品。

REGARDS,

20101018 1629 LUCIEN C.H. LIN
lucien (Admin)
Moderator
Posts: 157
graph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
Go to top