◎ 活動時間：2006/12/15 (五) 9:00~17:40
◎ 活動地點：中央研究院資訊科學研究所
◎ 報名網址：http://swan.iis.sinica.edu.tw/signup/

Open Source 的發展為軟體界帶來嶄新的思維，並加速了市場的擴大與演化，促成了包括 SAP、Oracle、Microsoft 等傳統商用軟體廠商，陸續跨入 Open Source 軟體服務的市場。從早期企業內部的商業流程 e化需求、近期興起的 Web 2.0 風潮，到企業對外的數位化服務等，再再顯示 e化商機是無所不在。新的商業模式有哪些？背後的運作原理為何？面對數位世界新的機會與挑戰，又該如何應用 Open Source 來強化成本效益？這些都是值得資訊從業人員思考的策略議題。

「2006 企業運算研討會：開放源碼的機會」將邀請國內外技術社群、學術、產業以及政府單位中的企業軟體開發者及使用者先進與會。目的在於促進彼此間的交流、互動與合作，進一步瞭解國內大型及中小企業在軟體開發與應用上的需求。期許透過此次會議的交流溝通，開發出契合國內企業需求的企業軟體解決方案。

本研討會將邀請國內外技術社群、學術、產業以及政府單位中的企業軟體開發者及使用者先進與會。目的在於促進彼此間的交流、互動與合作，進一步瞭解國內大型及中小企業在軟體開發與應用上的需求，期許透過此次會議的交流溝通，進而開發出國內企業有效且能接受的企業軟體需求解決方案。

會議時間為期一天，主辦單位特別安排兩場座談會，主題分別是「企業軟體在台灣的發展與挑戰」及 "What are the opportunities for Taiwan e-service ? "。此外，也邀請多位專家針對企業軟體的經驗與技術發表演說及現場討論，會場外亦規劃有多家企業軟體廠商進行 商品及服務展示。

我們深信，您的參與及對台灣資訊科技政策與產業推動的經驗，將會對本研討會有關鍵性的助益，我們殷盼您的蒞臨指導。

記得從我剛接觸自由/開放源碼授權這個領域沒多久，就人問我這樣 的問題：用自由/開放源碼軟體來架設網站，然後向利用網站的客戶 收費，卻不提供原始碼這樣算不算違反授權規定？用自由/開放源碼 應用程式透過網路向客戶端提供服務，收取費用，卻不提供原始碼， 這樣算不算違反授權呢？一直到現在，類似的問題仍然不斷地被提出。 在我答覆之後，所獲得的回應常是兩種截然不同的情緒：不是義憤 填膺，就是暢然釋懷。

用軟體來架設網站或透過網路向客戶端提供應用程式服務，都是常見 的資訊服務形式，也就是業者以 ASP（Application Service Provider， 應用程式服務供應商）的身份來營利。ASP 之所產生爭議是因為許多 人認為，ASP 用自由/開放源碼軟體來營利，卻不提供修改的原始碼 回饋社群，是一種只獲取不付出的行為，因此透過網路提供服務，究 竟算不算是自由/開放源碼授權條款中所定義的散布，就成為討論的 焦點。若是的話，提供這樣服務的公司就必須向客戶提供程式原始碼， 若不是的話，就不需要提供。而現行一般對於散布的定義都並未將「 透過網路提供服務」此種運用程式的態樣包括在內，因此，在沒有例 外的情況下，對於上述問題，我的回答都是：NO，沒有違反！

這樣的回答讓一些社群朋友義憤填膺，覺得商業公司利用社群開發結 晶謀取利潤，卻沒有回饋；同樣回答則讓業界朋友覺得暢然釋懷，因 為這樣沒有違反授權規定，也不需要提供原始碼給他人。

這樣的狀況，就我所知，尚沒有解決之道，因為大部分授權條款均採 用「散布 (distribute) 」這一個詞，而白話來說，目前在法律領域 中對這個詞的解釋還停留在，程式是不是真的有移動過，因此在回答 這類問題之前我常會問：程式是在哪個電腦上執行的？若是在自己的 電腦上執行，那麼就是沒有散布出去；若是在另外一端的使用者電腦 上執行的話，那就是有散布出去。

這樣的判斷方式適用於大部分的自由/開放源碼授權條款，當然，GPL 也不例外。不過也有授權條款針對此點有特別規定，AGPL (Affero General Public License v.1)（註一）與HPL (Honest Public License v.1)（註二）即為二例。

AGPL 與 GPL2 基本上是完全相同的內容，只是 AGPL 在第 2 條第 1 項後面多了第 (d) 款，其中規定，若程式執行的方式可以讓使用者 透過網路與程式互動，而使用者所接受到的程式版本本身也給與使用 者可以要求傳輸完整程式原始碼的機制，此時被授權人在修改程式時， 不可將這樣的機制除去，並且也必須提供適當機會，讓使用者一樣可 以透過網路與程式互動而要求修改程式的原始碼。

AGPL 這樣規定的立意雖好，但是窺究其內容是以程式本身有讓使用 者要求程式碼的機制，若一個程式本身並無這樣的機制，即使適用 AGPL，一樣無法強制要求 ASP 提供其客戶程式原始碼。

HPL 與 AGPL 一樣，以 GPL2 為基礎在第 2 條第 1 項後面增加了第 (d) 款，不過這個增加的內容較 AGPL 來的有力，因為 HPL 直接規 定，從解釋使用者取得程式原始碼的角度來看，使用者透過網路與程 式互動 (communication) 的型態，也算是包括在散布的認定範圍內。 依據 HPL 這樣的規定，ASP 透過網路提供應用程式服務的行為，無 論程式是否具有讓使用者要求原始碼的自動機制，也屬於 HPL 所規 定的散布，因而必須提供程式的原始碼給客戶。

此外，像 APL (Academic Public License) 與 OSL (Open Software License)（註三）中，特別將「互動 (communication)」與「散布 (distribution)」兩個詞並列，在解釋上也有相當的空間，可以用 互動這個概念來涵蓋ASP的服務行為，不過筆者至今尚未見到實際運 用案例出現。

目前草擬的 GPL3 草案第二版 (GNU General Public License v.3 draft 2)，在第 0 條第 2 項定義的“propagation”包含了「使公 眾可以取得 (making available to the public)」（註四），這樣 模糊的文字描述也有著解釋的空間，可以將 ASP 業者行為納入 pro- pagation 中，而產生必須提供原始碼的後續效果。

即使有上述條款的特殊規定，不過筆者至今所看到大部份的 ASP 業 者仍不必提供原始碼給客戶，因為這些業者大多採用 GPL2 程式！ 因此關於這個問題的爭論應該還會持續很常一段時間。未來 GPL3 的內容有可能明確地處理這個爭議，不過這並不代表問題的解決， 因為就算有GPL3的解決內容，著作權人不採納GPL3做為自己程式的 授權條款，問題仍然存在。筆者在此只能期待 ASP 業者在可行的範 圍內，可以對於開發社群有所回饋，畢竟自由/開放源碼的基本理念 是取之於社群、回饋於社群，有取有給如此才能建立一個良好的雙 贏環境。

註一：AGPL 並非 OSI 所認可通過的授權條款。其原文內容請見這裡。
註二：HPL 一樣並非是 OSI 所認可通過的授權條款。其原文內容請 見這裡。
註三：APL 與 OSL 的介紹請參見：葛冬梅，邱冠勛，OSL 與 AFL：特質完全相反的雙生條款（上），開放鑄造場電子報第62期； 葛冬梅，邱冠勛，OSL 與 AFL：特質完全相反的雙生條款（下），開放鑄造場電子報第63期。
註四：可參見該文字的討論。