Hi Kurapika,
日安、也好一陣子沒看到你的問題的了。
以下一樣將你的問題分述成三個子題，然後分述回覆。
一、採用SQLite於商業產品中，需要額外取得它的商業授權嗎？
簡答：不用、因為SQLite程式碼的權利已經都被原作者拋棄到「公眾領域(Public Domain)」的層次，原則上任何人都可以不限制目的去使用這些程式碼。
所謂的Public Domain，指的是一個權利客體，進入了法律所不再保護的狀態，因為著作權的存續與保護其實是有期間限制的，目前多數的國家都是保護作者終身再加上其過世後五十年的期間，例如我國著作權法第30條就是這樣規定的：「著作財產權，除本法另有規定外，存續於著作人之生存期間及其死亡後五十年。」所以像紅樓夢、老殘遊記這樣的古文，今天都已經進入了Public Domain的領域，而可以自由地被人透過網路來傳輸和散布，而不會有著作權侵權方面的問題；然而、法律的預設是一個著作權客體，是在期間經過後自動進入Public Domain，但有些著作權利人，願意在這個期間之前就主動放棄權利，就會透過一個公示拋棄的程序，來加快其著作權利進入Public Domain的速度，SQLite就是一個這樣的專案，其權利人已經拋棄了這些程式碼的著作權利，並公告大家都可以不限制目的去使用這些程式碼，自然、這個使用方式也包含商業應用在內。
但是如果是這樣，為什麼「
https://www.sqlite.org/copyright.html」這個頁面還會提到取得額外授權的事呢？
那是因為在某國司法管轄領域裡面，並不完全贊同「拋棄著作權利=進入Public Domain」的，或者說、法律條文中並沒有直接將Public Domain這樣的概念描繪出來，以我國著作權法為例：第42條規定「著作財產權因存續期間屆滿而消滅」，第43條規定「著作財產權消滅之著作，除本法另有規定外，任何人均得自由利用」。所以我國的法規是採取著作權保護期間屆滿便自動進入Public Domain的方式，然而、對於權利人主動拋棄其著作權，只有在第40條第2項的地方有註明「共同著作之著作人拋棄其應有部分者，其應有部分由其他共同著作人依其應有部分之比例分享之。」所以在共同著作的部份，我國法律是有點出「著作權利人有權拋棄其應有部份的著作權」，從而解釋上來說、既然共同著作的作者可以拋棄其應有部份的權利，那麼單一著作的狀況照這個解釋，亦應允許著作權利人提前拋棄其所有的著作權利。
所以解釋上我國的法制，是認同權利人可以在權利存續期前，就主動拋棄著作權利的。（並非所有法定權利都可以讓人主動拋棄，例如父母照料關心子女的「親權」，就屬於一種不能主動拋棄的權利。）那麼依照SQLite授權頁面的說明，在國內使用這套軟體，可以直接述明其已進入Public Domain，而不會受到任何使用上的限制，然而、並不是在全球所有的司法管轄區域都可以做這樣的解釋和處理，於是SQLite才會額外在授權頁面說明，若是使用者使用SQLite，但是因為下列理由無論如何都需要得到一份明示的法律授權的話：
1、You are using SQLite in a jurisdiction that does not recognize the public domain.（使用者所處的司法管轄區域不認可Public Domain這種法律概念。）
2、You are using SQLite in a jurisdiction that does not recognize the right of an author to dedicate their work to the public domain.（使用者所處的司法管轄區域，不核可著作權利人可以在保護期間屆滿前，直接拋棄該著作權利到Public Domain。）
3、You want to hold a tangible legal document as evidence that you have the legal right to use and distribute SQLite.（您個人或是公司無論如何，都想要持有一份成文的正式法律文書，以確保您對於SQLite所擁有的軟體合法使用權利。）
4、Your legal department tells you that you have to purchase a license.（您公司的法務部門，要求您一定要取得成文的正式法律授權文書。）
那麼在上述的狀況之下，使用者才需要額外的向Hipp, Wyrick & Company, Inc.這家公司，付費取得一份由其認可並出具證明的SQLite正式授權文件。
二、取用或修改zlib/libpng授權的程式碼之後，是否允許使用者不散布它的程式原始碼？
簡答：zlib/libpng授權類同BSD類授權，使用者修改其程式碼之後，採用不提供程式原始碼的方式來後續散布是可以的。
基本上zlib/libpng授權條款，只要求使用者以下三件事：
1、The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.（散布者不可以讓其他人誤以為其為程式的原始著作權利人，如果將此程式加到商業產品裡，而將程式原著作人的顯名聲明加到產品的說明檔裡是很好，但這也並不是一個一定要去遵守的義務，產品販售者可以自行依狀況來評估。）
2、Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.（如果散布者修改了原始版本的檔案，這些被修改的狀況一定要被標示出來，並且不能讓其他人誤以為被修改的版本，亦為原著作權利人所撰寫的版本。）
3、This notice may not be removed or altered from any source distribution.（如果本程式後續還是用Source Code的狀態向外散布，則程式原作者依據zlib/libpng授權條款所標示的授權聲明，並不能被移除或是修改掉。）
所以統合上面的三項規定，我們可以說：
1、使用、改寫zlib/libpng授權的程式碼到自己的產品，但產品後續是用Binary Code的方式散布，此時依zlib/libpng授權條款的規定，產品散布者願意在說明文件特別彰明zlib/libpng程式原作者的Credit是很好，但這並不是一個必定要做的義務性要件，也就是說、改寫zlib/libpng授權程式成為Binary Form，後續這些程式碼可以不用再照zlib/libpng的方式來授權。
2、但若是使用、修改zlib/libpng授權程式碼之後，仍然是以提供程式源碼(Source Code)的方式來散布程式，則zlib/libpng授權條款要求，原作者依據zlib/libpng授權條款所標示的授權聲明，便都不能被移除或是修改掉；所以此時的建議是，若是願意的話、可以保留zlib/libpng授權條款全文及原作者的聲明，後續仍然採用zlib/libpng授權方式來散布這些程式源碼，或者是、改寫zlib/libpng授權條款的內容，並將其授權條款的名稱一併做變更，例如「zlib/libpng-modifiled license」，以讓其他人知道此一元件雖然還是提供程式源碼，但已不再採用「原始的zlib/libpng授權方式」來散布。
三、Apache-2.0的授權方式為何不相容於GPL-3.0的授權方式？（
更正！原文為筆誤typo，Apache-2.0的授權方式是不相容於GPL-2.0，但只要能適用GPL-3.0第7條的額外添附條款-Additional Terms，則Apache2.0與GPL-3.0是相容的！）
這部份的資訊在GNU計畫的官方網頁有簡要的說明：
https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
----------
Apache License, Version 2.0
This is a free software license, compatible with version 3 of the GPL.
Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in the older version. These include certain patent termination and indemnification provisions.
----------
上面這段文字的涵義是表示，Apache-2.0裡面有一些GPL-2.0所沒有描述的規定，例如專利授權、廣告禁止、商標權保留條款，因此兩條款內容實際上是有衝突的，沒有辦法完全相容，因為GPL-2.0是屬於強質性Copyleft的授權條款(strictly Copyleft)，它與其他的自由軟體授權元件直接merge所生的衍生元件，都被要求得全部依GPL-2.0的授權方式來散布，所以這點造成了Apache-2.0與GPL-2.0的不相容；然而、Apache-2.0與GPL-3.0照自由軟體基金會的解釋是相容的，因為GPL-3.0有第7條「額外添附條款(additional terms)」的機制，這些可以添加的內容包括了調升擔保條款、顯名聲明條款、版本另名條款、廣告禁止條款、商標保留條款、責任禁添條款。這樣的額外添附條款最主要的用意，便是在於增加GPL-3.0與其他自由開源授權條款的相容性，因為透過添附條款的機制，原本是Apache-2.0授權條款才有的專利授權、廣告禁止，以及商標權保留條款，都可以透過額外添附條款的形式，加寫到GPL-3.0的授權本文裡，而讓Apache-2.0與GPL-3.0授權的元件，在merge之後、可以統一用「GPL-3.0+額外添附條款」的方式向外散布。
而事實上Apache Software Foundation對自由軟體基金會上述的解釋開始是持不同見解：
ftp://ftp.heanet.ie/disk1/apache/licenses/GPL-compatibility.html，ASF認為Apache-2.0與GPL-2.0彼此間透過解釋是可以相容的，但這個看法並沒有被自由軟體基金會所認可，所以最後ASF也有了正式的回應：
https://www.apache.org/licenses/GPL-compatibility.html
Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license. The Apache Software Foundation believes that you should always try to obey the constraints expressed by the copyright holder when redistributing their work.
這段大意是指，Apache Software Foundation已善盡努力讓Apache-2.0能夠與GPL-2.0相容，但因為自由開源軟體實務的運作上，還是要尊重著作權利人對條款本身的解釋，那麼自由軟體基金會手上掌有許多重要以GPL-2.0釋出元件的著作權，且亦為GPL-2.0條款的撰文者，既然FSF認定GPL-2.0與Apache-2.0的授權狀態是不相容的，那麼ASF也尊重這樣的看法，也呼籲Apache-2.0授權元件的使用者要注意並尊重這樣的見解。
所以最後兩大組織的共識便是：Apache-2.0元件與GPL-3.0元件，在merge的狀態下是相容的，但Apache-2.0元件與GPL-2.0元件，則原則上不具這樣的直接相容性。
希望上述的資訊對您有所幫助，有任何的疑問一樣歡迎接續討論！
敬祝 順心健康、事事如意
20111102 1710 LUCIEN C.H. LIN
Favoured: 1
