本頁面內容依編撰者己意，採 CC0 1.0 貢獻至公眾領域，不主張任何著作權利之保留。 / Content of this page is dedicated to the public domain under the CC0 1.0 Public Domain Dedication.
您好，
首先確定討論範圍，如果對象是API文件的授權方式與狀態，那麼以下幾個要點，分享一下經驗與意見。
1、API (application programming interface) 的提供方式或授權方式，是著作權方面的議題，即使用較寬鬆的著作權授權方式提供，並不表示API token一定要不限制任何人使用，也就是說，即使API文件在著作權方面，採很寬鬆的方式提供，貴司一樣可以在上游伺服器或系統方面，因為資安或流量管理方面的需求，而要求實際透過API介面寫入或投遞陳情資訊的使用者，必須先獲得token方面的驗證。
2、純粹資訊導向的API究竟受不受著作權利保護，這在各國的法律探討是有相當爭議性，因為著作權保護的客體是文學、藝術，或科學方面的創作，創作必須有創意性，然API有時只是呼叫方式、資料層級的定義與引導，或是系統或方式的操作指示(system or method of operation)，究竟單一API文件有沒有獨立受到著作權保護的必要或定位，向來有論者採正反相對的立場。例如已歷時數年，目前在美國聯邦法院仍在纏訟的 Oracle America, Inc. v. Google, Inc. 關於Java 37 項 APIs的訴訟案，一審法官William Alsup認為APIs並不具創意性，故不受到著作權法的保護，公布出來僅為事實狀態的操作資訊，依其來編寫互動程式從而不需要獲得授權；然而這樣的見解在上訴審已被推翻，該案上訴審的見解是任何人類的創意只要足以辨識出來，善難稱這樣的創意必然不受到著作權的保護，所以依此見解廢棄原判決，並發回第一審法院重新審理。
不過目前美國此一世紀大案的審理狀態是，經過陪審團的裁定，即使APIs可以受到著作權法保護，在相當條件下，使用者亦有機會主張合理使用，從而在未獲授權的狀態上直接使用之。如果想知道更多該案的資訊，可以參閱之前受數位時代邀稿，拙撰，Oracle 與 Google 的官司裡的「合理使用」是什麼？：http://www.bnext.com.tw/column/view/id/39754
總合目前我所認識各國多數見解的看法，API可以受著作權法保護，但其發揮效力在個案上必須自我抑制，所以說，如果貴司願意開放API，並希望這份API文件可以獲得最大程度的被利用，有下列幾個提供模式可供考量！
(1) 直接採「cc0 公眾領域貢獻宣告」的模式來提供，宣告所釋出的API其實不具著作權利的保護。
CC0公眾領域貢獻宣告，是文件的產製人以作者的身份，自我認定該文件不會受到著作權利的保護，或雖受保護但依己意主動拋棄，讓它進入眾人皆不受限得以自由使用的公眾領域(Public Domain)，進一步的說明，可參閱中研院台灣創用CC計畫的介紹專頁：http://www.creativecommons.org.tw/cc0，而可供引據的實例，就是美國白宮在2014制定的Open Data行動方案(U.S. OPEN DATA ACTION PLAN: https://www.whitehouse.gov/sites/default/files/microsites/ostp/us_open_data_action_plan.pdf)，明確採用CC0來釋出相關的資料集。所以，若是貴司打算釋出的API文件，較偏向前述「呼叫方式、資料層級的定義與引導，或是系統或方式的操作指示(system or method of operation)」，必要時可以採CC0的方式直接讓其進入公眾領域。
(2) 若是不介意衍生程式的授權或商用狀態可採Apache-2.0授權來提供這些API相關文件
然而，究竟API受不受著作權保護是有不同見解與觀點，司法界目前也仍未獲共識，若是貴司希望仍主張具有著作權利，但也希望相關的衍生應用可以最大幅度的成長，那建議採用Apache-2.0授權來提供這些API相關文件，相關範例可見白宮Project Open Data裡API Sandbox這個子專案，目前這個子專案提供兩個編寫選項，一為I/O Docs，採比Apache-2.0更寬鬆的MIT License釋出(https://github.com/project-open-data/iodocs)；另一為Swagger，採Apache-2.0釋出(https://github.com/project-open-data/swagger-core)，個人建議Apache-2.0的主因是，MIT License固然非常輕簡，但就是過於輕簡有些細節沒有被描述到，而Apache-2.0的條款裡有明示商標權予以保留，並且禁止背書或有不當代表行為，也許更適合公部門取之釋出專案。
(3) 若是希望依此API衍生應用都必須後續提供程式源碼出來，則採「GPL-2.0及其後版本」的模式來提供這些API文件。
並非十分建議採用這個模式，原因如前所述，「各國多數見解的看法，API可以受著作權法保護，但其發揮效力在個案上必須自我抑制。」而GPL授權的要點在於，依據GPL授權程式編寫的衍生程式，後續也必須同採GPL來授權並進行後續提供。採用這個授權方式，可以讓使用者有主動提供程式源碼給後手的壓力，從而了解這些API被衍生與應用的狀況，仍然，也可能因為此一Copyleft的義務性規定，造成部份商業應用者迴避使用這些API，而不會取用它來做程式的開發，故這樣的模式有利有弊。美國白宮的Project Open Data裡，有部份API相關的子元件，主要是轉檔程式，確實是採GPL的方式釋出，例如：https://github.com/project-open-data/db-to-api / https://github.com/project-open-data/csv-to-api ，所以也不能說全無例子可循。故敝人的評鑑與建議是，若貴司非常希望後續相關的應用程式，都必須提供衍生程式源碼出來，才來採用這個模式，進一步，讓它採「GPL-2.0及其後版本(GPL-2.0 and later version)」的模式來釋出，可以在授權相容性獲得最高的靈活度。
整理一下，大意就是，若公部門機關構希望各相關衍生應用都必須提供衍生的程式源碼，選項3-GPL-2.0及其後版本，不過此法也許部份廠商或APP開發者，會迴避使用；若希望最大幅度提供給開發者，無意做後續管理，選項1-CC0公眾領域貢獻宣告；若持平較為中庸，希望給予使用的靈活度，但不限制衍生作品的授權狀態，僅要求其標示出處來自貴司且禁止不當背書行為，可採選項2-Apache-2.0。
以上，若後續有衍生的想法或問題，我們再隨時接續討論。
日安、健康，事事如意。
:)
20161007 20:39 開放文化基金會 林誠夏
----
您好，
本部部份資料會在去識別化後，採對公眾釋出的方式提供，想請教與研討：開放評論的API，其相關定義及資料層級欲採公眾授權或能吸納最多群眾協力共工的方式釋出，未知在授權策略上是否有供公部門機關構參考的資訊或分析？