首先要感謝這個網站的工作人員，我真是學習了很多有用的知識。

我開發了一個資料存取軟件，使用Java作開發語言。這Java軟件在執行時會使用以下的程式:
1. Appserver, (GNU/GPL) www.appservnetwork.com/
2. 7 Zip, (GNU LGPL) www.7-zip.org/ (7 zip的作用是把MYSQL的資料打的包作backup用)
3. MYSQL JDBC driver, (GNU General Public License, version 2) dev.mysql.com/downloads/connector/j/
4. Jasper Report, (GNU Lesser General Public License version 3) jasperforge.org/index.php?q=project/jasperreports
5. Spring, (Apache License, Version 2.0.) www.springsource.org/about
6. JDatePicker, (Simplified BSD Licence ) www.pepperbytes.net/opensource/jdatepicker.html
7. Excelsior JET, (Commercial) www.excelsior-usa.com/jet.html

這個軟件不會發行光碟或可在網上下載，因為要到客戶公司安裝及設定。

程式 1, 2, 3, 4 及 5，會預先從網上下載到USB隨身碟，再到客戶公司安裝。 (程式 1 ,2 是exe檔。程式 3, 4 及 5 是jar檔，jar檔會複製到目錄下。)

主程式(Java) 及 程式6 會預先使用程式7打包成為一個exe檔，再到客戶公司安裝。

問題
A. 我的資料存取軟件是否要按照 GUN / GPL / LGPL / Apache / BSD License 通知客戶？
B. 我的資料存取軟件會否成為開放？(比較擔心程式 1, 2, 3)
C. 如果在安裝程式 1 ,2時我要求客戶按"Accept terms and agreement"的按鈕。那麼問題A及B的答案會否不同？

謝謝

Hi newhand,

我想關鍵的判斷依據重點是：「你所採用的自由軟體運用手段，是不是涉及程式碼的向外散布。」

關於程式碼的散布行為，GPL2與GPL3其實相去不遠，但是GPL3做了更詳細的描述，所以這邊直接引GPL3為例(註一)：

To 『convey』 a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

而關於「傳遞」這個字詞、以下用以表達「增殖」過程中明確地將拷貝作品程式碼(原重製作品或是衍生作品)遞交予後手的行為過程。如果僅是透過網際網路進行資訊的互動，而並不涉及程式碼的移轉遞交，則不會被GPL3視為「傳遞」行為之一種。

所以、原則上如果你利用這些自由軟體的方式，可以被解釋為涉及程式碼的向外散布，那麼這些自由軟體授權條款的義務性規定都會生效。

以上述這個判斷重點來解釋你的問題：

A. 我的資料存取軟件是否要按照 GNU GPL2 / GNU GPL3 / GNU LGPL2.1 / Apache2.0 / 3-clause BSD License 的方式通知客戶？

是的、建議你可以羅列一張軟體授權清單(Open Source Software List)以提供給你的客戶，並且明示哪一部份的元件是利用哪些授權的軟體。

B. 我的資料存取軟件會否成為開放？(比較擔心程式 1, 2, 3)

如果這邊指的是這些GPL授權元件是否會開啟它的授權拘束性(註二)，那麼需就個案而定、就你的軟體列表來看，這應該是一個協置網站建置的服務工作，一般來說、如果你打包成一整個PACKAGE，讓整個網站可以自動化安裝的話，那麼多數的見解是這樣的運用方式會開啟GPL授權元件的授權拘束性。

C. 如果在安裝程式 1 ,2時我要求客戶按"Accept terms and agreement"的按鈕。那麼問題A及B的答案會否不同？

如果你在安裝程式的流程裡，讓客戶自行閱讀軟體的授權聲明，並自行進行這些自由軟體授權元件的安裝，那麼法律流程中可以視為客戶自行取得這些自由軟體授權元件，是有機會解釋為「自由軟體分開下載」的區隔方式。不過、相當程度會加高客戶購買這個網站架設服務的難度與降低操作接受度。適當與否、就要看你這邊的裁量了。

希望這些簡短的資訊對你有所幫助，

後續如還有延伸性的疑問，

歡迎接續留言來討論。

20110320 2215 Lucien C.H. Lin

註一：其他細節部份可參照我個人網誌上GPL3的草稿翻譯：lucien.cc/?p=11，不過、此僅為草稿翻譯，如有轉譯上的謬誤還請包涵，並且、不代表自由軟體鑄造場(Open Source Software Foundry, OSSF)的官方立場。

註二：關於GPL授權元件授權拘束性的開啟，可以參照之前論壇的相關回文：www.openfoundry.org/tw/forum?func=view&catid=8&id=475#480，或是葛冬梅小姐右列專文：www.openfoundry.org/tw/legal-column-list/1788-android-gpl-

非常感謝你這麼快有回覆。

這個應用只是一個記帳軟件，伺服器也不會對外開放。但因為它的邏輯很複雜，只好這樣做。Appserver事實上也只要MYSQL部份，其他的(Aparche, PHP, phpMyAdmin) 只是方便我有需要時更改資料用。

如果我將程式 1, 2, 3, 4 及 5，改成從客戶公司的網路下載到他的電腦，再作安裝。又會怎樣？即是程式1, 2, 3, 4 及 5手動安裝。

因為程式 3 是一個 jar 檔，不可找客戶自已按 Accept 按鈕，是否有方法防止我整個記帳軟件變成開源？（這就是我的底線）

另一個問題是有關jdbc的使用量,因為我的java會不停通過jdbc的訪問mysql.

會否因這樣使我的java變成開源？

Hi newhand,

抱歉近來事務比較多，沒有辦法第一時間follow後續的討論。

如果我的認知沒錯，

這個帳務系統build在大部份的Open Source元件之上運作，但希望移轉給客戶使用後，自己加寫的腳本與介面不需要完全提供程式原始碼，對嗎？

如果是的話，那麼、這應該就是屬於GPL拘束性避除術的範疇。

但是要先說在前面的是，關於GPL的避除術，討論的立場有很多，因為大家解讀GPL的定位和角度都有所不同，所以寬嚴之間也會有所落差，我這邊僅能協助引述一些看法，並不能說是權威或是司法裁判上的最終見解。

(1)分開下載的方式能將被GPL拘束的風險降到最低，但此種作法也並不是沒有爭議。

如你所說的：「將程式 1, 2, 3, 4 及 5，改成從客戶公司的網路下載到他的電腦，再作安裝。」

則這樣的方式是將程式與程式間結合的責任轉嫁給客戶，所以受到GPL授權條款拘束的主體就變成該名自行安裝GPL程式的客戶，實務上來說、只要該客戶不再散布這個組合過的系統，則就不會產生GPL程式散布後要再提供程式原始碼給後手的問題，但前提是、客戶需要充份認知到這個事實並且也同意，先期溝通清楚，這樣可以降低日後很多的爭議或是糾紛。

(2)程式3是一個jar檔，不方便讓客戶自行安裝後使用，仍有辦法使用「分開下載、自行安裝」的方式來隔離GPL程式的拘束性嗎？

實務上的作法不是沒有，例如有些人是自行寫一個安裝的script，讓客戶去執行script，而這個script採用LGPL授權來中隔GPL元件的拘束性，但此法比起單純的分開下載，爭議性會變得更大，操作也更為複雜。因為有許多社群朋友認為，此種作法是惡意的避除術，而會更積極的去質疑這隻中隔程式的獨立性，而如果找得到原來GPL程式著作權人的支持的話，就會由權利人發警告信表達其反對意見，狀況嚴重時、便會透過gpl-violations.org或是Software Freedom Law Center這樣的組織來代為提出訴訟。

(3)透過jdbc來訪問MySQL會不會讓自身的程式也必須受到GPL授權條款的拘束而被要求提供原始碼？

這個問題也是見仁見智，如果是一般存取提供數據，並且MySQL部份也是讓客戶自行下載安裝的話，那風險性自然就降低；但是、如果MySQL這個資料庫是由你散布提供予客戶的話，從MySQL官方經營策略端來做解釋的話，其公司政策是不認同這樣的存取方式的，也就是說、從MySQL公司的立場(Oracle)，其認為這是該當於GPL授權擴張拘束性的範圍，需要一體釋出整個專案的程式原始碼。

因為MySQL是併以商業模式來釋出其專案，此為「雙重授權模式：GPL授權模式 + 商業授權模式」，也就是說、MySQL併以GPL與商業的方式釋出其專案，讓使用者選擇要用哪一種授權方式來取得程式授權，若是以GPL方式取得授權，則不需要繳付授權金予MySQL，但後續修改或是結合後的軟體專案，就得依GPL的遊戲規則釋出改作後的程式原始碼，而若以商業授權模式取得的MySQL，則需要繳付授權金費用予MySQL，但後續修改或是結合後的軟體專案，則照著個別約定的商業條款來走，不用釋出自己改作後的程式原始碼。所以MySQL在MySQL AB、SUN,與現在Oracle的時期，對於GPL拘束範圍的解釋都是非常嚴謹的，也就是說、其對GPL授權的拘束範圍解釋的愈嚴，則愈多使用者會願意向其洽詢商業授權的方式來取得程式，MySQL甚至為此成立基本的查緝部門，一發現有哪些公司是以GPL的授權方式取得MySQL，但後續商業散布時並沒有提供自身改作後的程式原始碼時，他們也會透過發信警告、後續協商的方式來促使商業使用者撥付一定程度的商業授權金回到MySQL。

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

敬祝 順心健康

20110331 1315 LUCIEN C.H. LIN

非常感謝你的熱心回覆。

為了逃避Oracle的魔掌，我會改用其他的資料庫。jdbc 這一部份我會用回 java sdk 自帶的。這樣相信在實務上可以避過GUN的拘束性。

祝 平安喜樂