您好，想請問軟體開發的問題。
在開發過程中，如果使用自由軟體之功能，例如使用 MySQL 當成資料庫來源，但卻沒有修改 MySQL 的任何原始程式碼，開發之後的程式是否需要遵循 GPL ，將原始程式碼公布？
開發軟體後(例如 Servlet, JavaBean)，並且在自由軟體平台上執行(Tomcat, Apache ..)，那麼，這樣有需要將原始程式碼公布嗎？
可以將開發軟體商業化，然後採用這些平台？

謝謝您的回覆

Hi Ken,

針對以下兩個問題，這裡先簡單的答覆，如果就具體案例更有補充說明，那麼我們再接續討論細節可能產生的差異。

一、「在開發過程中，如果使用自由軟體之功能，例如使用 MySQL 當成資料庫來源，但卻沒有修改 MySQL 的任何原始程式碼，開發之後的程式是否需要遵循 GPL ，將原始程式碼公布？」

簡答，如已身開發程式實際取用了MySQL軟體的程式碼，則其再散布時即要遵守GPL2開放己身原始碼；但如果此一開發程式並不欲散布，則毋庸開放原始碼。

關於這個問題，就MySQL而言、MySQL AB這家公司採行的是「雙重授權模式(Dual Licensing Mode)」，意即其以自由軟體授權條款的方式，併同商業授權方式同時進行，欲付費使用者向其購買商業授權的權利，而不欲付費使用者，則可依自由軟體授權條款取得程式，但是其後就須依足此一自由軟體授權條款的諸般義務性要求，是以如果此例中使用者選用的是商業授權模式，自然不會有任何開放已身程式原始碼的問題，所以必然討論的問題聚焦在於以「自由軟體授權條款」的方式取得MySQL的狀況。

而在此例中，MySQL取用的自由軟體授權條款、乃是最著名的「革奴公眾授權條款(GNU General Public License 2.0，其後簡稱GPL2.0)」，那其最為人稱誦或是為人垢病的(立場不同之故)特點，就在於「感染性」這個面像，任何程式取用了GPL2程式任一部份的程式碼，原則上、其衍生作品其後若欲進行再散布，就只能取用GPL2為其唯一的散布條款。所以這個問題推衍至今，可以將解決方式簡化為下列二個簡單的詢答。

1、已身所開發的程式是否「取用」了MySQL資料庫程式的程式碼？

所謂的「取用」包括取用MySQL資料庫程式碼的一部或是全部，所謂全部取用即指將自身程式與MySQL程式進行結合而成為單一可安裝、執行程式；而所謂的一部取用則是將MySQL資料庫的程式碼一部份寫入自身開發的程式，在這兩種狀況下、這個所謂已身開發的衍生作品即為GPL2所「感染」，而其後僅能以GPL2為其再散布時唯一可取用的授權條款，亦即、依GPL2散布之後若收受程式碼欲向您索取程式原始碼，則須依GPL2的規定提供其程式原始碼。

2、雖然已身程式確實取用了MySQL資料庫程式的程式碼，但其利用方式並不涉及「散布」。

即是一般俗稱的ASP(Application service provider)的利用模式，亦即對於此一程式的利用並無涉及「實質程式碼的傳遞(Convey)」，則此時程式並不會被繩以GPL2散布者所須擔負的開放原始碼義務，此種認定方式在GPL2時代一直有所爭議，但到了GPL3、第三版的革奴公眾授權條款，已幾近共識而寫入了授權條款本文之中，是以若您己身開發的程式確實取用了GPL程式的程式碼，意即將GPL軟體程式的程式碼編寫進本身程式中，則若事涉程式散布、就須為GPL授權條款所拘束，但若能不將程式進行散布即可進行利用，則便不須開放已身程式原始碼。

二、在自由軟體平台上執行(tomcat、apache)，有需要將原始碼公布嗎？可以將軟體商業化、然後採用這些平台？

簡答，若程式完全由己力編寫(未涉及其他自由軟體程式碼的取用)，則著作權人可自擇其商業授權方式，亦可將其應用於自由軟體的平台；但若程式並非完全由己力編寫，乃取用一部份其他自由軟體既成的程式碼，則可能日後的授權方式便已受限，而不能完全由此程式的著作人決定。

關於這個問題也是大哉問，不過原則上已有解決的共識，關於開發私有軟體(Propreitary Software)然後將其應用於自由軟體的程式平台之上運作，可以從三個面像來分析這個問題：

1、依GPL2的理想狀態並不允許(應然面)

如果說是直接參照GPL2授權條款本文的話，那麼其並不容許此類活動，任何程式與GPL2程式產生連結運用，並且這種運用關係也摻雜了實際程式碼的混用，那麼原則上此類程式就會被GPL程式所「感染」，而僅能以GPL2為其散布時的授權條款，但這是GPL授權條款所欲達到的「理想面」，實際上其「感染性」也並沒有辦法在現實世界裡得到如此擴張的「落實」。

2、現實狀況所在多有(實然面)

就現實面來說、目前坊間不乏軟體其並未開放原始碼，但卻是運作於Linux Kernel(Linux核心，以GPL2為其授權條款)這個平台之上。這樣的情況歷年亦引發了很多的討論和爭議，甚至Linux Kernel研發的核心人物Linus Torvalds亦有對此事公開發表過看法，其以兼容的心態聲明，並不對於此等運作方式表達排拒的反感，因為就長遠面來看，如果更多的程式可以運作在自由軟體的作業平台上，某種程度也是擴大了自由軟體的應用及影響面。

3、應然與實然之間的容忍範圍(法律面)

是以就此問題來看、其「應然面(GPL2的理想狀態)」與「實然面(實際的發展狀況)」實在存有一定程度的落差。那麼判準到底在哪，實際上就著作權法上的觀點而言，其實要看此自行開發軟體的著作權歸屬性質為何，簡單來說、若是此自行開發的軟體，其乃自始由作者自行編寫並不涉及GPL2相關軟體的程式碼取用(Pure Clean Code)，那麼此時作者獨占所有的著作權人地位，其欲以何種授權條款、授權方式來處置其軟體的應用皆為法之所允，並不會因為其運作於GPL軟體程式的平台上，就必然受到GPL授權條款的「感染」，畢竟就法律邏輯來思考，「僅有權利人有地位聲明其權利行使、並且防止他人侵害其權利」，那麼如果此一應用程式自始自終皆為作者獨立撰寫，那亦僅有著作人自身可以主張這個軟體的著作權利，亦即是、自由軟體基金會(FSF)僅是GPL授權條款的撰稿人，其並非此一程式著作權人，那麼著作權人欲如何利用自己的軟體，要以何種方式釋出，其可悉依自己所欲，而當然的不被自由軟體基金會所拘束，但此例為程式完全由著作人自行編寫的狀況，若是此一程式的生成、乃奠基於其他GPL軟體的程式碼取用，則此時衍生作品的作者就無權悉依已意決定衍生作品嗣後的授權方式了，仍要回歸到前一問題，就GPL授權條款的感染性問題做思考。

20071122 1340 自由軟體鑄造場 林誠夏