Tuesday, June 9, 2015

Apple may regret its choice of a permissive open source license for the Swift programming language

As the founder of an app development company with one Swift-based project underway, I was excited to hear about Apple's decision, announced yesterday at its WWDC, to open-source the next generation of its latest and greatest programming language. I'll say a few more things about my own perspective at the end of this post (just in case anyone cares to know) but before we get there I'd like to focus on the broader strategic implications.

According to yesterday's announcement, "Swift source code will be released under an OSI-approved [OSI = Open Source Initiative] permissive license." This means Apple will relinquish its rights in that code to the greatest extent it can under all the kinds of software licenses I know. "Permissive" means Microsoft, Google, Samsung (Tizen) and anyone else can just take that code and incorporate it, for free, into their own products, including closed-source, commercial offerings.

The alternative for open-sourcing Swift would have been to release the Swift source code under a copyleft license such as the GPL. That license would give users the same rights but also impose an important obligation: any derivative product would have to be made available on copyleft terms as well. I know the Free Software movement doesn't like the terms "viral" or "infectuous." But I mean them non-judgmentally and they describe the effect. If the smallest piece of a larger work is GPL'd, the whole thing must be GPL'd, too.

The copyleft "share-alike" obligation would have been a poison pill at least for Microsoft and Google. The whole Oracle v. Google Android-Java copyright infringement litigation would never have happened if Google had adopted Java under the GPL (the license under which Sun Microsystems already made Java code available before being acquired by Oracle), but it feared that copyleft would prevent its device makers from differentiating through proprietary add-ons.

The original right holder, Apple in this case, still remains free to make the same code available on two ("dual-licensing") or more licenses in parallel. So Apple could have protected its own ecosystem from copyleft, and could have negotiated case-by-case licenses with others in the industry for the same purpose, while forcing the rest to make an all-or-nothing decision. I have my own (positive) experience with dual licensing as an early shareholder (more than 10 years ago) in MySQL AB, maker of the namesake open source database (which was later acquired by Sun, thus got bought by Oracle alongside Java).

The first beneficiary of Apple's choice of license type that comes to my mind is Microsoft (and, by extension, companies like mine who would like to build Windows versions of their apps provided it doesn't cost us much time). In April, Microsoft announced that it would make the porting of Android and iOS apps to Windows easier. They weren't talking about emulation, just about letting us compile Objective-C and Java code under Windows and giving us direct replacements for key iOS and Android API functions. It was more about familiarity than compatibility, but still very useful. Support for Swift was not announced at the time. With Swift becoming available under a permissive open source license, however, it should only be a matter of time, and probably not a whole lot of time, until Microsoft supports Swift as well. It would be crazy if it didn't.

Sure, Apple could theoretically do the same with .NET and its Common Language Runtime, which Microsoft released under the permissive MIT license. But it wouldn't make sense because Apple doesn't need this to attract developers to its platform. In the post-PC world, Apple is the #1 in economic terms, Google has the largest user base, and Microsoft is a distant third by either measure. If the primary winner and the primary loser in a given market adopt the very same licensing strategy for their platforms, there are only two possibilities: either their license choice is the only one that makes sense regardless of how successful or unsuccessful you've been (for example, it might be great for the ones at the top and the ones at the bottom but squeeze the one(s) in the middle) or one of them has made the wrong choice.

It will take years to find out which of the two is the case. This here is not a prediction post; I just want to discuss the potential implications.

Apple has undoubtedly thought about what Microsoft and Google (and others) might do now. Microsoft will benefit, and I could see Tizen benefit in a similar way. Google has a huge developer base that is happy with Java, and if it ever wanted to replace Java, there's a couple of alternative languages that it's been developing for some time.

Apple may feel that neither Windows nor Tizen are ever going to be a threat, no matter how small the effort to port Swift apps to those platforms might be in the future. Apple could even hope that more market share for Windows and Tizen will just hurt Google (divide and conquer, sort of).

But what is Apple trying to achieve here? A permissive open source license for Swift is the answer... but what is the question?

If Swift had adoption problems, open-sourcing it would be a Hail Mary. But in only a year it has experienced an incredible uptake. App developers have understood quickly that Objective-C is just a legacy and in a few years it may be deprecated.

I already thought five years ago that Android was going to do to the iPhone what Windows had done to the Macintosh. It could still happen, but not too soon. The one thing that would really threaten Apple's business model would be if app developers decided to put major new releases out on Android first, or invested more in their Android versions than in their iOS versions. There comes a point when the collective innovative capacity of an entire ecosystem dwarfs even that of the world's most valuable corporation. It was the Windows ecosystem, not Microsoft alone, who marginalized the Mac. However, as of now, those network effects are still favorable to Apple, simply because its customers spend more on and especially inside apps, so app developers (like my little company) have a greater opportunity, depending on their geographic target markets of course, on iOS. It's also a prestige thing to succeed on iOS. "If you can make it there, you can make it anywhere."

Even in Germany, where I see far more Android than iOS devices on trains and in public places, Google Play revenues have just recently, according to at least one market research firm, exceeded App Store revenues. On a worldwide basis, the Play Store appears to be catching up slowly, and an increasing reliance of app developers on advertising revenues (for example, giving you in-game coins in exchange for watching video ads) could also benefit Android over time. But iOS is still in a strong and safe position, probably due in part to the fact that many Android phones are technically smartphones but practically used like dumbphones. And even if Apple feared Android's ability to close the gap, what good would it do to open-source Swift?

It's really a mystery to me. The iPhone and iPad don't need this; for the Mac it would actually have been an opportunity to be the desktop platform that iPhone/iPad developers can support with the smallest effort, but if Microsoft adopts Swift in some way, this will be just as much of an opportunity for the Windows desktop and, by extension, for devices like the Surface. And on the desktop, the collective purchasing power of all Windows users is clearly greater than that of the Mac user base.

Even in the absolute best-case scenario for Swift, a permissive license would then enable Google (or any company in its ecosystem) to make it easy to port Swift apps to Android. The effect would be commoditization, which is not in the interest of the one with the highest profit margins.

If this strategy didn't work out for Apple, for example because of others having a greater benefit from it than Apple itself, it could always release a future version of Swift -- 3.0, 4.0, or later -- exclusively under a proprietary software license. It can't re-close the source code published by then, but it has no obligation to publish more code on open source terms. And that's why the rest of the industry, in the absence of a multi-company consortium that would control future development of the language, won't rely on Apple's newfound openness anyway. They will just evaluate ways in which they can opportunistically benefit from it. "Embrace, extend, extinguish" will be hard as long as Apple invests significantly in Swift, but it's not impossible.

I'm sure the Free Software movement is very disappointed right now that Apple, like Microsoft, has chosen a permissive software license rather than the GPL. However, permissive licensing might turn out not to be in Apple's commercial interests, and maybe a future version of Swift will be published under the GPL.

[Update] I've received messages via social media stressing that Apple won't open-source the Cocoa APIs. Right: just the compiler and the standard libraries. But this isn't about wholesale emulation. It's about Microsoft (and possibly others in the future) letting you stay in the programming language in which you've developed your original app and giving you replacement API functions. [/Update]

Own perspective

At the beginning of this post I said I was going to focus on the broader, industry-wide strategic implications of Apple's licensing decision and would talk about my own company's perspective only at the end. I've mentioned my game development plans on various occasions since the second half of 2013. I haven't announced any title or even a genre, so arguably this isn't "vaporware," but it's true that it's taken a lot longer already than I would have thought. Part of the reason is that I firstly had to restructure my work so as to be able to focus almost 100% on app development. An even bigger part is that the original project became ever more ambitious, and late last year I decided to start a second project in parallel, with external developers. The internal project will result in a game that I want to revolutionize an old genre. My goal is that people who look at it think it's 90 or 95% new and only 5% or 10% of it is what they have already seen in other games in that category. The second project will have a completely novel task at its center, as the Rubik's Cube or Tetris had. It's not a blend of existing categories either. It will create a whole new category. You'll see.

Right now both games are well on track to be released in the second half of the year, in the fourth quarter more likely than in the third. And both will be published on iOS first, though the internal project originally started on Android. Internally we use Swift, and I'm glad we made that choice last year despite its "childhood diseases," but what really made me determine that "iOS first" was the right choice at the moment is that especially for the internal title a large part of the commercial opportunity will be in the U.S. market, where iOS has been able to even regain market share thanks to the iPhone 6. Apple is doing way better at this stage than I would have thought a year or two ago that it would now.

I still like Android a lot and our Android versions will have the same quality as our iOS products, and at some point I hope to port at least the Swift-based game to Windows as well, so Apple's decision to make Swift available under a license that will enable Microsoft to make iOS-to-Windows ports pretty efficient for Swift apps is good news for me. I still don't understand how this will benefit Apple. Maybe I'll find out over the next few years just like I found out that Apple's (largely) failed patent enforcement efforts were unnecessary anyway because of other success factors it benefits from.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Share with other professionals via LinkedIn: