[[136884]]

蘋果公司表示其將把Swift語言打造為開源項目，但在軟件自由度的問題方面仍然有所保留。

那么對于一款編程語言來說，開源機制的介入到底意味著什么？這個話題說起來就有些復雜了，而且也關系到開源命題的核心所在。具體來說，其編譯器可能是開源的、整套工具鏈可能是開源的、而語言本身也可能由開源IDE負責支持。這里提到的每一項都可以算作是一種語言走向開源的必要元素。

接下來要提出的問題則是：單憑獨立開發者之力，能否實現語言的開源轉化？這個問題同樣復雜。就以甲骨文公司為例，雖然其切實將Java推向了開源，但卻無法容忍Java替代性方案的出現——正如谷歌所發現。因此，我們必須等待蘋果公司最終拿出的實際許可，并借此了解其到底是真正為我們帶來代表著開放的大門、抑或僅僅是像甲骨文那樣通過玩弄專利與版權來刺激與項目相關的創新活動。

不過值得關注的內容還不止于此。當前最值得大家認真考慮的問題在于，這款編程工具是否會帶來軟件自由。要回答這個問題，單純關注語法、工具鏈甚至是獨立實現的可能性都還遠遠不夠。

一種編程語言絕不僅僅是將多套SDK——即API加上代碼庫——拼合起來所形成的產物。從自身角度出發，編程語言能做的并不多。但真正重要的是對應平臺擁有可資利用的開源SDK外加用戶能夠切實獲得的API，特別是對于那些以軟件自由性為核心訴求的編程語言而言。

Swift語言的設計主旨是為了給蘋果公司旗下受到嚴格保護的移動系統平臺開發安全性更高且開發過程較Objective-C更簡潔的編程成果。蘋果公司指出，其“計劃面向OS X、iOS以及Linux”，但三者事實上存在著巨大差異。其中iOS與OS X功能集的最大特征在于“匯聚”，相比之下Linux則擁有面向一系列系統方案的“松散”特征——具體來講，單單是通用型窗口管理器就分為GNOME與KDE兩大陣營，其下還各自包含多種分支版本。

盡管Swift將為iOS系統開發工作帶來更出色的類型與內存安全效果，但在我們看來，利用Swift為iOS及OS X編寫的應用程序恐怕很難被移植到其它系統之上——除了應用中的通用“引擎”代碼之外。也許那些采取嚴格MVC方法的應用能夠更輕松地與Swift的控制器機制相對接，但我們仍然很難相信這足以帶來可順暢移植的視圖代碼。

那么蘋果公司的Swift編程語言到底是否會走向“開源”？除非親眼看到該工具鏈當中的具體許可及治理條款，否則我們沒辦法給出確切答案，不過蘋果方面給出的答復是肯定的（包括OSI核準許可、接受代碼貢獻等等）。而且即使開源成為現實，如果我們無法利用Swift語言開發出開源應用，那么這一切仍然毫無意義——這絕不是什么學術問題。

編程語言本身并不是問題的關鍵所在；它們所使用的SDK才是真正核心。當蘋果公司公布能夠與Swift并行協作的SDK方案時，這些方案幾乎不可能會以無縫化方式作用于Android或者其它任何基于Linux的開源平臺之上（更不用提Windows了）。

Swift也許能夠為現代開發人員提供口頭上的開源承諾與對自身有利的輿論籌碼，但我個人對此并不抱太大希望——特別是考慮到蘋果公司對于自身專利技術儲備所抱持的一貫保護態度。