Apple表示会让Swift语言成为一个开源项目，但在软件自由的问题上还是有所保留。那么对于一门编程语言来说，开源机制的介入意味着什么呢？这个话题说起来有点复杂，同时也关系到开源命题的核心。具体来说，它的编译器可能是开源的，整个工具链可能是开源的，语言本身可能由开源IDE支持。这里提到的每一项都可以算作一种语言走向开源的必备要素。下一个要提出的问题是：单靠独立开发者的力量能否实现语言的开源改造？这个问题同样复杂。以甲骨文为例。虽然它确实推动了Java的开源，但它不能容忍Java替代品的出现——正如谷歌所发现的那样。因此，我们将不得不等待Apple的最终实际许可，看看它是否真的代表了对我们敞开的大门，或者它是否只是像Oracle一样玩弄专利和版权来刺激与项目Activity相关的创新。但值得关注的远不止于此。现在最严重的问题是这个编程工具是否会导致软件自由。要回答这个问题，仅关注语法、工具链甚至独立实现的可能性是不够的。一种编程语言不仅仅是将多套SDK——即API+代码库放在一起的产物。就其本身而言，编程语言不会做太多事情。但真正重要的是，对应的平台有可用的开源SDK加上用户实际可以获得的API，尤其是那些以软件自由为核心诉求的编程语言。Swift语言旨在为Apple严格保护的移动系统平台开发出比Objective-C安全性更高、开发过程更简单的编程结果。Apple指出它“计划针对OSX、iOS和Linux”，但实际情况是这三者截然不同。其中，iOS和OSX功能集最大的特点就是“融合”。相比之下，Linux对于一系列的系统解决方案都有一个“松散”的特点——具体而言，单独将通用窗口管理器分为GNOME和Windows。KDE的两大阵营各自包含了多种分支版本。虽然Swift会给iOS系统开发工作带来更好的类型和内存安全效果，但在我们看来，使用Swift为iOS和OSX编写的应用程序可能很难移植到其他系统——除了通用“引擎”代码之外的应用程序在里面。也许采用严格的MVC方法的应用程序可以更轻松地与Swift的控制器机制交互，但仍然很难相信这足以导致流畅的可移植视图代码。那么苹果的Swift编程语言会“开源”吗？除非我们亲自看到工具链的具体许可和治理条款，否则我们无法给出确定的答案，但苹果的答案是肯定的（包括OSI批准许可、接受代码贡献等）。而即使开源成为现实，如果我们不能使用Swift语言开发开源应用，那么这一切仍然毫无意义——这绝不是一个学术问题。编程语言本身并不是问题的关键；他们使用的SDK才是真正的核心。当Apple宣布可以与Swift并行工作的SDK解决方案时，这些解决方案几乎不可能在Android或任何其他基于Linux的开源平台（更不用说Windows）上无缝工作。Swift或许能够为现代开发人员口头承诺开源承诺并为他们自己谋利，但我个人对此并不抱太大希望——尤其是考虑到Apple对其专利技术储备的不懈承诺。保护态度。
