登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
討論區
web-based服務的商業授權問題 (1 位瀏覽者) (1) Guest
Go to bottom Favoured: 0
TOPIC: web-based服務的商業授權問題
#919
web-based服務的商業授權問題 2014/06/24 10:57  (5 Years, 5 Months ago) Karma: 0  
想詢問一個商業模式下的授權問題,先介紹一下產品的運作環境和商業模式:程式是用PHP寫的,web-based的服務,會在Apache, PHP, MySQL的環境下運行,更精確的說程式是用CodeIgniter的Framework開發的(沒有改core),source code有用到PHP, Javascript, jQuery, 還有用jQuery開發的2個plugin(一個是MIT, 一個是Dual licensed: MIT/GPL)。

CI和jQuery相關授權的討論有這個www.openfoundry.org/en/forum?func=view&catid=8&id=635

1)如果公司打算用販售服務的方式來賣這個產品的話,也就是除了這包source code之外,還提供環境架設(Apache, PHP, MySQL會另外下載安裝),後續諮詢或維護程式之類的服務,那麼根據上面那個討論串,我理解的是應該沒有商業授權上的問題(jQuery及plugin的版權聲明不動不改),只要在程式包內把CodeIgniter的原始版權聲明的license txt給付上即可,這樣對嗎?

2)如果公司只打算販售那包source code,環境安裝則由買方自行負責,那麼是否程式包內附上CI的license txt後就可以了呢?

3)如果公司只打算販售那包source code,而未來使用上不在網路上公開,可能是在公司內部架設服務使用,或是精簡版只在工程師的筆電內安裝這樣,那麼同樣的是否程式包內附上CI的license txt後就可以了呢?

4)另外是這包程式的授權問題,基於使用工具上的授權(如jQuery是MIT, CI是BSD等等),這包程式是否就會是BSD授權?如果我想要在程式內部也撰寫這包程式的授權,是否就是修改BSD的條款,只是把名稱改成程式的命名之類的?那麼CI的授權聲明是否也需附帶在程式包內,也就是程式包內同時有CI的授權聲明以及這份程式自己的授權聲明?

5)最後一個問題是個人的疑問,雖說BSD是可以不提供原始碼,但是像這類web-based的服務,當我們是為使用者(比如說某個公司)撰寫主程式的時候,不是無可避免一定會把整份原始碼給使用者(公司)嗎?


不好意思因為自己查詢了資料但還是模模糊糊,所以才上來發問。

先謝謝各位。
arielblue (User)
Fresh Boarder
Posts: 2
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
#921
Re:web-based服務的商業授權問題 2014/06/25 17:17  (5 Years, 5 Months ago) Karma: 10  
Hi arielblue,

歡迎來本論壇留言,你所提問的問題,大抵扣緊二個主軸,一是拿Open Source元件來修改之後,後續程式碼的傳遞怎麼標示的問題,第二個問題則是什麼時候要提供程式源碼,什麼時候不用提供程式源碼。

關於第一點,我先破個題,MIT、Apache-2.0這類的授權條款是允許轉授權/再授權(sublicense)的,也就是說,再散布程式時,你可以用自己的名義,把從前手得到的權利,轉給後手。比如說程式本來的授權聲明是這樣:2014 作者A released under MIT License,你可以更改為 2014 作者B(你自己) released under MIT License。然而,GPL、LGPL、AGPL,以及MPL、EPL這類copyleft性質的授權條款,是不允許轉授權/再授權(sublicense)的,也就是說,修改者只能將自己的名字與前手作者的名字堆疊在一起,以彼此的名義共同釋出後續的程式,比如說程式本來的授權聲明是這樣:2014 作者A released under GPL-2.0,你只能將其更改為 2014 作者A & 作者B(你自己) released under GPL-2.0。

而關於第二點,什麼時候要提供程式源碼,基本上只要是copyleft性質的程式碼,修改過的部份又是原始程式的衍生程式的話,這個部份依授權條款的規定,程式的散布方就是要提供程式源碼(Source Code)給程式的接受方的;而如果並不是copyleft性質的專案,例如MIT、BSD、Apache-2.0這樣比較寬鬆(permissive)的授權方式,程式的散布方是可以自行決定不要提供程式源碼,只要他在散布時聲明該元件過去是採MIT、BSD、Apache-2.0來提供,但經其調整之後改用Closed Source的其他授權方式,如Mirosoft Win7作業系統裡,就有不少這樣的宣告。

那麼,以下即截取你所提問的問題,大要式的回覆:

一、如果公司打算用販售服務的方式來賣這個產品的話,也就是除了這包source code之外,還提供環境架設(Apache, PHP, MySQL會另外下載安裝),後續諮詢或維護程式之類的服務,那麼根據上面那個討論串,我理解的是應該沒有商業授權上的問題(jQuery及plugin的版權聲明不動不改),只要在程式包內把CodeIgniter的原始版權聲明的license txt給付上即可,這樣對嗎?

是的、沒有「商業使用」上的問題。精準一點來說,你可以將上述的Source Code與LAMP(Linux + Apache + MySQL + PHP)這樣的運作框架作結合之後,進行商業販售。基本上,所有的自由開源軟體都是可以拿來做商業利用的,只是個別元件相關的授權義務性規則也要去遵守,並且如果部份程式碼是延續自由開源軟體授權的模式來散布的話,該部份的收費名目不能是軟體授權金(royalty),而應該是客製化費用,或是方案提供的服務費用(total solution service fee)。

所以說,如果你提供給客戶的產品包括上述CodeIgniter的Framework、jQuery開發的2個plugin,以及LAMP的各個部份,相關元件如果延續是用自由開源軟體的授權方式,則這些開源元件都必須要提供下列的資料:

1、其授權條款全文
2、一個名為legal或notice的文字檔,統一說明各元件的授權狀態。
3、一個名為readme的文字檔,說明這些開源元件安裝時的必要資訊,以及嗣後從貴公司這端,得到程式目的碼之人,應該透過什麼程序或方式向貴公司索取相關開源元件的程式源碼。

補充說明,一般來說GNU相關的開源專案,內載授權條款全文的文件,會稱為COPYING,而說明各元件授權狀態的文件,會以LEGAL為檔名;而Apache Software Foundation、Mozilla Foundation相關專案,內載授權條款全文的文件,會稱為LICENSE,而說明各元件授權狀態的文件,會以NOTICE為檔名。此一檔名的標示方式雖然沒有在條款裡嚴格規定,不過是眾多專案標示上約定成俗的習慣。

二、如果公司只打算販售那包source code,環境安裝則由買方自行負責,那麼是否程式包內附上CI的license txt後就可以了呢?

自由開源軟體領域裡的原則是,散布者只要對自己所散布的開源程式元件,作義務性規定的負責。所以如果貴公司僅有販售/散布CodeIgniter的Framework、jQuery開發的2個plugin,而不涉及LAMP的各個部份,自然就只要就CodeIgniter的Framework、jQuery開發的2個plugin這部份,進行前述資料的提供:

1、其授權條款全文
2、一個名為legal或notice的文字檔,統一說明各元件的授權狀態。
3、一個名為readme的文字檔,說明這些開源元件安裝時的必要資訊,以及嗣後從貴公司這端,得到程式目的碼之人,應該透過什麼程序或方式向貴公司索取相關開源元件的程式源碼。

三、如果公司只打算販售那包source code,而未來使用上不在網路上公開,可能是在公司內部架設服務使用,或是精簡版只在工程師的筆電內安裝這樣,那麼同樣的是否程式包內附上CI的license txt後就可以了呢?

如果我的理解沒錯,此處講的是將CodeIgniter的Framework、jQuery開發的2個plugin,以及LAMP的各個部份,組合起來變成遠端式的應用程式服務(Application Service Provider)。而付費的客戶原則上是接觸不到相關的程式源碼,僅是透過貴公司搭建的網路平台來使用遠端的服務。如果是這種類型的話,貴公司並不需要提供前述開源元件的相關程式源碼給客戶,因為就像之前提到的「自由開源軟體領域裡的原則是,散布者只要對自己所散布的開源程式元件,作義務性規定的負責。」所以如果貴公司從頭至尾都沒有程式碼的散布與提供行為,那原則上是不會開啟自由開源軟體授權條款相關的義務性規定。但,亦有下列幾個例外:

1、GPL-3.0、LGPL-3.0之後的版本,規定就算不需要提供程式源碼,也必須在產品的相關標示上告知使用者,該產品內含GPL-3.0或LGPL-3.0授權的元件,此為明示的告知義務。
2、AGPL-3.0授權條款在第13款的地方明訂,若修改了AGPL-3.0授權的程式元件,且將其置於電腦網絡上進行服務上的應用,此時即使程式碼以遠端的利用方式並未散布,但亦必須提供程式源碼給該程式的使用者;另外一款OSL-3.0授權條款(Open Software License v. 3.0)亦是如此。

所以如果貴公司使用到的開源元件包括GPL-3.0、LGPL-3.0、AGPL-3.0或OSL-3.0,就必須特別注意額外的標示義務或程式源碼的提供義務,其他的開源元件,則沒有這樣進一步的要求。

四、另外是這包程式的授權問題,基於使用工具上的授權(如jQuery是MIT, CI是BSD等等),這包程式是否就會是BSD授權?如果我想要在程式內部也撰寫這包程式的授權,是否就是修改BSD的條款,只是把名稱改成程式的命名之類的?那麼CI的授權聲明是否也需附帶在程式包內,也就是程式包內同時有CI的授權聲明以及這份程式自己的授權聲明?

首先,當這包Source Code裡面又有BSD又有MIT授權的元件時,各元件彼此間的授權狀態其實並不會互相干擾,因為BSD、MIT授權的元件,其在授權特性上都沒有外擴性,所以有一種作法就是個自保留其原本的授權方式,然後以前述資料提供的方式作統一的標示來處理即可:

1、其授權條款全文
2、一個名為legal或notice的文字檔,統一說明各元件的授權狀態。
3、一個名為readme的文字檔,說明這些開源元件安裝時的必要資訊,以及嗣後從貴公司這端,得到程式目的碼之人,應該透過什麼程序或方式向貴公司索取相關開源元件的程式源碼。

而如果貴公司要更改這些BSD、MIT授權元件的聲明,例如改為自己的商業授權模式,來停止提供後手程式源碼的話,也是可以的,因為BSD、MIT授權條款是容許這樣的調整方式(GPL、MPL、EPL則不可),實例可以參考附圖,Microsoft在Windows 7安裝過程中所作的標示範例。

五、最後一個問題是個人的疑問,雖說BSD是可以不提供原始碼,但是像這類web-based的服務,當我們是為使用者(比如說某個公司)撰寫主程式的時候,不是無可避免一定會把整份原始碼給使用者(公司)嗎?

嗯…是的,不過web-based的服務為使用者(某個公司)撰寫程式這樣的態樣,大致上是商業上的契約行為。可以說,依BSD、MIT授權條款,供給方可以改寫或調整BSD、MIT授權的元件,改以「不提供源碼的封閉授權條款」來提供,然而若需求方是商業上的夥伴,其在給付價金之後自然可能會將「提供源碼」作為契約要求的一環,此時提供義務就是寫在供給方與需求方個別擬定的契約條款裡了,而沒有和BSD、MIT授權條款本身有直接的關係。

其他與上述問題相關的文章有下列幾則,也表列在此供你作個參考:

修改自由軟體的著作權人標示:www.openfoundry.org/tw/legal-column-list/1747-2010-07-15-10-26-14
自由軟體授權資訊的標示說明與 SPDX:www.openfoundry.org/tw/legal-column-list/8420-license-info-of-floss-and-spdx
內含 GPL 授權元件產品的標示義務:www.openfoundry.org/tw/legal-column-list/2384--gpl-
如何提供 GPL 元件的程式源碼:www.openfoundry.org/tw/legal-column-list/8782-how-to-distribute-gpl-source-code
從開放源碼的理想到提供源碼的義務:www.openfoundry.org/en/news/9120?task=view
散布 GPL 衍生程式所須提供的源碼範圍:www.openfoundry.org/tw/legal-column-list/8119--gpl-

希望這些資訊對你有所幫助,後續有疑問的話,歡迎隨時接續討論。



20140625 17:10 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.  
#922
Re:web-based服務的商業授權問題 2014/06/26 16:17  (5 Years, 4 Months ago) Karma: 0  
謝謝LUCIEN詳盡的解釋和說明,
您提供的連結對我非常有用,
目前邊閱讀也邊撰寫產品的相關授權說明部分。

最後我還有一個關於MySQL授權的疑問想請問:

我開發的產品是用MySQL Community Server(GPL V2)的環境在運行,
dev.mysql.com/downloads/mysql/

除了MySQL外還有Apache(Apache License, V2.0)
www.apache.org/licenses/LICENSE-2.0

和PHP(PHP License v3.01) php.net/license/

之前看到了這個討論串 www.openfoundry.org/tw/forum?func=view&catid=8&id=807#813
產生了疑問,
我的認知如下,
因為我的Source Code裡會用到MySQL的指令來存取database的資料,
儘管有除外條款 www.mysql.com/about/legal/licensing/foss-exception/#1
但我的程式包還是有可能會有GPLv2感染的問題,
得看他們(MySQL)對derived work(我的程式包)的認定,
那麼根據討論串,
和MySQL在同一個專案一併運作的話,
也必須要用除外條款中的授權(就是必須提供程式源碼),
不過我的問題是所謂的感染應該只限於derived work需不需因此轉成GPLv2授權(提供程式碼),
PHP和Apache會不會也因此受到感染呢?

如果說Apache因此感染,
那麼Apache License, V2.0和GPL V2不相容會不會有衝突呢?
www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

謝謝。
arielblue (User)
Fresh Boarder
Posts: 2
graphgraph
User Offline Click here to see the profile of this user
Logged Logged  
 
The administrator has disabled public write access.  
Go to top