Many think of ‘open source’ the same way they do free software: totally free and open for everyone to use. And Swift is indeed open and free. Released under the Apache license, Swift is also gaining LSP support, which will give it the ability to compile in just about any IDE you’d want to use (and even some you don’t).
Apple still drives Swift’s progress. Swift.org, the site dedicated to Swift’s open-source roadmap and release history, is owned and managed by Apple. Those who contribute most to the language’s success are typically Apple staffers, or were (Swift creator Chris Lattner, who is now at Google, is still heavily involved with the language).
But in the forums on Swift.org, users are noticing Apple’s patent filings reach beyond hardware and into the language itself. Specifically, Apple patented the method for
optionals chaining, a feature released in Swift version 4.2 that allows developers to query or call properties, methods, and subscripts that may be nil. It’s an alternative to force-unwrapping. From Swift.org:
If the optional contains a value, the property, method, or subscript call succeeds; if the optional is nil, the property, method, or subscript call returns nil. Multiple queries can be chained together, and the entire chain fails gracefully if any link in the chain is nil.
The user who originally posted Apple’s language feature patent to the Swift.org blogs calls it “disturbing,” adding: “It’s like Apple has gone insane. Computer languages are not supposed to be owned by any company. We learned this mistake with Java and APIs. Computer languages are supposed to be a part of the Commons, owned by everyone for the benefit of humanity, not the benefit of a greedy corporation.”
This is an issue of the spirit of a law versus the letter of it. To most, ‘open source’ means you must give everything away for free when dealing with the project (as we see above, the poster conflates features with the language). But the Apache license grants the use of patents. The most recent version of the Apache license, version 2.0, was released in 2004. It specifically calls out patents as a viable concession for the license:
The 2.0 version of the Apache License was approved by the ASF in 2004. The goals of this license revision have been to reduce the number of frequently asked questions, to allow the license to be reusable without modification by any project (including non-ASF projects), to allow the license to be included by reference instead of listed in every file, to clarify the license on submission of contributions, to require a patent license on contributions that necessarily infringe the contributor’s own patents, and to move comments regarding Apache and other inherited attribution notices to a location outside the license terms.
Commenting on the thread about Swift language patents, Lattner suggests Apple uses the Apache license specifically so it can patent features, writing “…one of the major reasons that Swift uses the Apache 2 license is to provide more certainty for the community [with regard to] licensing and patents.”
Swift’s new leader, Ted Kremenek, argues patents actually secure the language. “Any company making a contribution to Swift is intentionally licensing implied patents to the project,” he writes. “This is a business decision. Speaking on Apple’s behalf, that business decision is clear and deliberate: we want Swift to be successful and to be used widely. The Apache 2 license provides a form of IP licensing as well as IP protection for the project, and thus its users.”
Some fear Apple may use a feature patent it owns to sue anyone using said feature for their own forked Swift project, but that’s unfounded. From the Apache license terms and conditions, article three:
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
Simply put, if Apple were to sue another entity or person for using optionals chaining within the scope of Swift, it would lose claim to said patents under the license. That’s not to say Apple loses ownership of the patents themselves; but in making the features available to Swift for use under the Apache license, Apple can’t sue someone just for using those patented features within the scope of the broader Swift ecosystem. That would be like managing a library but refusing to let people check books out.
For now (and maybe for all time) developers will have to agree to disagree with Apple about patenting features for Swift. We’d say it’s better Apple be first-to-file as than some patent troll scraping GitHub, protecting the project itself as Kremenek suggests. If anything, it seems Apple is just trying to keep Swift on the tracks it designed for the language as much as possible. Soon, we’ll have LSP support and ABI stability, which will make Swift usable in any IDE and compilable to essentially any platform… or cross-platform apps and services like ‘Marzipan.’ That’ll really blow the proverbial doors open.
Apple hasn’t commented on its Swift feature patents officially, and likely won’t. Some developers want Apple to explain itself, and they won’t get satisfaction on that front. If we’re speculating, this is Apple guarding its flanks; it created
optionals chaining for Swift, and released it to Swift, and patented the feature while still allowing it to be used for Swift. This allows the Swift community to use the feature unabated, while allowing Apple “ownership” of it so another language can’t snipe it. As Kremenek suggests, this is “protection for the project.”