Apple’s decision to open-source Swift at WWDC surprised some people (though others described it as “table stakes”).
What does it mean for a programming language to be open source? It’s complicated, and it links to the heart of the proposition of open source. The compiler may be open source; the full tool chain may be open source; the language may be supported by an open source IDE. Each of these is a necessary element of a claim for a language to be open source.
The next question that needs asking: Can an independent developer implement the language as open source? That in itself is complicated; Oracle for example tolerates an open source implementation of Java but won’t tolerate an alternative approach to Java, as Google has found. When we see the precise license choice we'll know whether Apple has left the door open to reimplementation or whether it will use patents and copyrights to chill innovation as Oracle has.
But there’s more. The real question that needs answering is whether the programming tool delivers software freedom. That question involves more than the syntax, the tool chain, or even the possibility of independent implementation.
A programming language is merely glue for joining together SDKs: APIs and libraries. On its own, a programming language doesn’t do much. What matters is the availability of an open source SDK for the platforms and APIs you actually use, especially the ones where software freedom is the rule.
Swift was designed to make programming for Apple’s walled garden safer and less onerous than it was with Objective-C. Apple says it “intend[s] to contribute ports for OS X, iOS, and Linux,” but that is not all the same. iOS and OS X imply a well-known feature set that’s aiming to converge. But Linux is used as a loose term for a wide range of systems, where even those with a common window manager like GNOME or KDE come in a variety of flavors.
While Swift will bring better type and memory safety to writing for iOS, it does not seem likely that apps written in Swift for iOS and OS X will port easily to other systems beyond generic “engine” code. Maybe those with a strict MVC approach will breathe easier with Swift for the Controller, but it seems unlikely to help with portable View code.
Will Apple’s Swift programming language be “open source”? Until we see the licenses and governance for the tool chain, we won't really know, though the company says the right things (OSI-approved permissive license, accepts contributions, and more). Even when we do, if we can’t use it to program open source apps, the question is rather academic.
Programming languages alone don’t make programs; the SDKs they leverage are the key. When Apple speaks of the SDKs that work well with Swift, it is highly unlikely it is talking about anything that works seamlessly on Android or indeed within any other Linux-based open source platform (not to mention Windows).
Swift may be offering lip service to open source to pay table stakes with modern developers, but I’m not holding my breath when it comes to extending software freedom to anyone beyond Apple's walled garden.