Hi change，
您所提及的問題主要可以分為三項，一是Javascript此種明碼的運作方式，是否毋須再另行提供程式源碼？還有Jquery相關的授權拘束性問題；二是wijmo套件是否可以依GPL-3.0的規則，合法在公司內部使用；三是highcharts的非商業授權版本，能不能拿來在一般商業公司的內部使用。
以下，我便就這些問題的要項，提出一些經驗上的分享。
一、採用Javascript此種明碼的運作方式，是否毋須再另行提供程式源碼？而若組合多種自由開源軟體授權的元件來使用，其彼此間的授權拘束關係為？
雖然我很想給一個簡要YES或是NO的明確答覆，不過這個問題的答案，目前仍然是見仁見智、要看個案的狀況，重點的判斷標準：要進一步去看該Javascript前手開發者的散布方式！
因為依照GPL-2.0、GPL-3.0的相關規定，對於程式源碼(Source Code)的範圍都有進一步細部的界定，就嵌入式元件或是一般應用程式來講，源碼的範圍包含該程式的安裝資訊與編譯腳本(install information & compling script)在內，而就定義來說，其實只要是進行專案程式碼修改時，所會用來便利這個修改過程的相關元件與資訊，都可以是廣義源碼的一部份。援引GNU計畫下的FAQ的說法就是：原來的程式設計師要修改這些程式，所會用到那一個參照版本，就是最佳的源碼版本。這樣的文字其實也被載明在GPL各版條款裡：The source code for a work means the preferred form of the work for
making modifications to it.所以說，Javascript透過明碼來互動，想要看到這些程式碼的人是可以看到的，但是節錄、片斷的程式碼，不會是拿來修改的最佳格式，也就是說，如果這些程式碼是以GPL相關條款釋出的，那依條款規定是要提供另外打包下載的途徑為宜，因為這樣才符合條款所描述的理想狀態。
而就MIT、BSD、Apache-2.0這樣較寬鬆的授權條款(permissive license)來說，雖然就源碼的內容與範圍並沒有細節的規範，然而就「顯名主義」上也是有明確的要求，也就是說，使用這些授權方式的程式碼，並不會讓它的授權方式拘束到之後的衍生專案，但是！必須要透過合理的方式來表彰前手創作者的權利聲明與免責聲明(Copyright Notice & Disclaimer Notice)。所以說，「單純明碼的披露」其實是並沒有辦法滿足這些顯名的要求，故在MIT、BSD、Apache-2.0授權專案下，即使是Javascript這樣明碼的互動模式，還是盡可能提供打包下載形式的源碼為宜。
承上，所以實務上重點的判斷標準就在於：該Javascript專案是否有前手開發者，而前手開發者提供源碼的態度與方式又為何？白話來說，如果前手開發者(通常即為該專案的權利人)本身提供源碼的方式比較隨興，並沒有打包檔、也並沒有敘述完整的授權聲明資訊，那麼此時承襲他的態度來使用這些程式碼，則涉及侵權爭議的風險是小的，因為如果前手自己沒有嚴格執行的事，在社群論理道德下，也比較沒有立場去向後手要求一定要完整的做到；然而，若是前手開發者本身提供源碼的方式十分嚴謹，除了打包檔的提供外，更延申提供說明與優化調校文件，並且也詳述其授權聲明資訊，那麼此時將這些程式碼，修改之後置於網路上互動，卻不額外提供打包下載的途徑的話，則涉及侵權爭議的風險就是大的，因為此時前手自己已然嚴格執行，並且提供了盡量完整的程式源碼，但是在後手修改過後相關資訊卻變成斷簡殘編，這種狀況之下，引發爭議的可能性自然就會大為增加。
最後，自由開源軟體元件之間，在如何的互動關係下會產生授權拘束的影響，是一個這個領域的大哉問。基本上的回答是，舉GPL-3.0為例，如果B元件會被視為GPL-3.0授權A元件的衍生作品，則B元件必須要依照GPL-3.0的規則來向後授權。而若GPL授權的A元件，與BSD、MIT、Apache-2.0授權的A元件在一個專案裡一起互動，如果這些元件的互動關係緊密且不可分，則依GPL-3.0的授權拘束特性，該原以BSD、MIT、Apache-2.0授權的A元件，須與B元件合併改以GPL-3.0的授權方式來向後散布；然而、實務上常見的狀況多是，此專案裡原以BSD、MIT、Apache-2.0授權的元件，仍保留其原來permissive的授權方式，併合與標示GPL-3.0的B元件一同散布，為什麼會是這樣？其一是這些MIT、BSD、Apache-2.0授權的元件，其授權標示資訊可能散見各元件的根目錄，或是個別檔案的檔頭資訊裡(header file)，要一個個去更易修改實是不易，其二是，以BSD、MIT、Apache-2.0授權的元件，因為容許再授權(sublicense)，故隨時能被後手散布者改用GPL-3.0的方式進行散布，所以讓其保留原BSD、MIT、Apache-2.0的標示方式，也不一定會直接產生未來不可修復的授權衝突。
所以說，如果您的作法是讓GPL授權的B元件併同MIT授權的A元件一起運作，並且兩部份都提供程式源碼給後手的話，那應用上的實際爭議是小的；但若是您的作法是讓GPL授權的B元件，併同原以MIT授權但後續您打算Close Source的A元件一同運作，則實務上的實際爭議就會變大，其實，這也就是為何Google Android平台上完全是以自由開源軟體授權函式庫來組成中隔層的緣故，因為這些函式庫雖然並非依GPL來授權，但一樣是採他種permissive的開源授權方式散布，亦能讓人取得完整的程式源碼，故應用上不會產生直接的授權衝突。
這部份進一步的相關資訊，可以參照拙撰，GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（上）：
www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01；GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（下）：
www.openfoundry.org/legal-column/8447。
二、wijmo套件是否可以依GPL-3.0的規則，合法在公司內部使用？
沒有問題！GPL授權的元件本就可以拿來進行不限目的之使用，這包括了商業使用。更多的資訊可以參照GNU計畫的專文，Selling Free Software(得否販售自由軟體？)：
www.gnu.org/philosophy/selling.html
不過，您這邊的提問可能牽涉到進一步的問題，那就是GPL-3.0的元件置於內部使用，需不需要提供程式源碼出來？若真是這個問題，那可以參照GPL-3.0條款內容右列的部份： You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
依上列的說明，如果公司的管理者與其承包商或是員工訂立契約，明文約定該GPL-3.0的程式僅是因包工或管理關係，不涉及程式碼的傳遞與授權的話，那麼單單持有此程式並依公司指示進行修改之人，並不能將該程式自行向外散布，也是說，具文清楚律定的內部關係，可以被GPL-3.0視為內部使用，此時，便不會開啟GPL-3.0要求散布者必須肩負的「提供程式源碼予後手」之義務。
三、highcharts的非商業授權版本，能不能拿來在一般商業公司的內部使用。
highcharts的非商業授權版本，是採用Creative Commons的NC標章來聲明的，而事實上在Creative Commons的定義裡，何謂「非商業性 Non-commercial」的範圍也時常引發爭議和討論，Creative Commons曾經透過問卷調查的方式來「尋求共識」，其在2008年9月發起了一個「非商業性使用」研究計畫的研究計畫(
creativecommons.tw/blog/20081020)，透過問卷調查的方式(
creativecommons.org/press-releases/entry/9554)，探求Creative Commons授權標章的使用者其「心中所認定的非商業性範圍究竟到哪裡」，其後並在一年之後公布研究報告：
creativecommons.tw/blog/20090916，透過參閱這份報告書的全文，大概就可以知道一般人認知的「商業性vs.非商業性」的區隔在哪裡。
然而，此份研究報告的內容並未直接登載在後續的授權條款裡，故從實而論，它具有參考的價值，但並沒有實質的拘束力。在司法實務上，何謂「商業行為」可說是一個「不確定的法律概念」，就像我國民法72條所說的「公序良俗-公共秩序與善良風俗」一樣，必須有賴契約內容的補充（例如Google Maps/Google Earth API 服務條款：
code.google.com/intl/zh-TW/apis/maps/terms.html，其對於商業利用／非商業利用就額外多了很多的描述和定義。），並且放在個案的脈絡下去解釋才會比較清楚。也就是說，如果權利人在以公眾授權的方式釋出其作品的同時，對於何謂商業利用、何謂非商業利用已經做了公示，則司法實務上原則是會尊重其公示的範圍。
一般Freeware(免費軟體)常常將商業公司的內部使用，也視為整體商業行為的一環，故常見所謂「免費家用版本(free home edition)」，或是「免費教育版本(free education edition)」，那麼這樣的律定方式，其實已經喻含商業公司的使用，是被排除在「非商業性」的範疇之外的。所以實際去查看highcharts專案網頁的說明，其認為非商使用限定在「For non-profit organizations, students, universities, public schools and non-commercial personal websites.」這樣的表達方式，原則上就是將商業公司的內部使用排除在外的，雖然並無販售，但已然被專案的權利人觀為商業使用的一環了。
希望上述的資訊對您的疑惑有所幫助，若有後續問題，歡迎隨時接續討論。
20121127 1610 LUCIEN C.H. LIN
Favoured: 1
