一個普遍的看法認為,Google 很明顯地站在開放源碼這邊,只是因為開放源碼能帶給該公司好處,但 Google 的回饋卻相對地不足。這一派人士認定 Google Code 禁止服務的專案採用 Affero GPL 授權的政策,背離 Google 宣稱尊重且認同的開放源碼主張。
Chris DiBona 在文章中寫道,code.google.com 事實上不支援 AGPL,在 code.google.com 上成立 AGPL 專案,卻宣稱採用的是 GPL,同樣是不受允許。解決方法就是移除你的專案,將專案轉到其他地方。
DiBona 舉出的理由,包括 AGPL 並非 OSI 認可的授權以及 AGPL 使用不夠廣泛。僅管部份理由遭到社群人士反駁。
AGPL 或稱之為 Affero GPL 擴大了 GPL 對於散佈的定義。GPL 的條款只有散佈 GPL 授權的程式碼時,才會發揮效用。除非程式碼被散佈到組織外,否則 GPL 軟體的使用者或企業沒有義務揭露自己對 GPL 程式碼的修改。
AGPL 修正了這個漏洞,對於部份人士而言,足以讓他們眼中的搭開放源碼便車的各家公司,如 Google、Digg 等,再也無法使用開放源碼軟體而不須回饋。在此背景下,Google Code 拒絕讓 Google Code 上出現採用 AGPL 授權的專案,也就格外引人注意,並且難以使外界不多做聯想。Google 不願意 Google Code 容納 AGPL 授權專案,是因為一旦所有人在開放源碼上獲得同等立足點,Google 將會喪失優勢。
從協助創新的觀點看來,Google、Yahoo! 等公司積極回饋開放源碼社群,將為自身與整個產業帶來好處。由於 Google、Yahoo! 對 Linux、MySQL 所作的不公開修改,彼此間的差別或許不如廠商單方面想像的多。同樣的開放源碼專案,同時有相似的創新活動在進行。當這些公司能分享自身開發的部份,所有人都將脫離核心、基本的類似程式碼,進行更進一步的創新活動。
支持 Google 的一方以 Google 等公司透過提供支薪人力支援或財務支援等方式,對開放源碼專案做出回饋為例,宣稱許多重要的開放源碼專案事實上靠了企業支援,才得以擁有如今的規模。例如 IBM、惠普 (HP)、甲骨文 (Oracle)、紅帽 (Red Hat) 與 Novell 之於 Linux,Yahoo! 之於 PHP,Firefox 之於 Google 等。
此外,假如 Linux、PHP、Apache、HTTPD 與 MySQL 等一開始採用的是 AGPL,Google 等企業很有可能選擇付費取得無須回饋程式碼修改的權力。畢竟願意將重要差異化技術資產公諸在競爭者面前的企業並不多。更糟的情況下,Google 等公司也許不會成長到像今天這樣的規模。
基於 Google 等企業為 IT 使用者帶來的服務價值,社群部份人士認為,足以彌補廠商對開放源碼社群回饋不足之處。
單就授權本身看來,防止授權暴增帶來的混亂情況是 Google 所提出的理由之一。Google 在 Google Code 上最初允許 7 種專案授權,加入 GPLv3 後增加到 8 種。Google 擔心開放源碼授權數量暴增後,開發者整合來自不同授權專案的元件時,法律權力將複雜不明。
關鍵在於,Google 拒絕 AGPL,是因為 AGPL 有害 Google 核心競爭力?抑或只是防止授權暴增問題的方法?當 Clipperz 等專案選擇離開 Google Code 之際,是否會有更進一步的專案出走潮,Google 會如何因應,會是後續外界觀察重點。由於 Google 同樣不允許專案採用 Eclipse Public License 等其他授權,防止授權暴增之說似有可信之處,但是當採用 AGPL 的專案漸增後,Google 的態度是否會有變化,將成為驗證此說的機會。
相關網址:
1.Google 與 AGPL 的問題持續惡化
2.為什麼我認為 Google Code 不支援 AGPL 並非大問題
3.AGPL 對 Google
4.Google 要弱化 AGPL?