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+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Richard Stallman's Mono and DotGNU patent concerns

Glyn Moody, a true FOSS expert among journalists and author of the OpenDotDotDot blog, has interviewed Richard Stallman, the founder of the software freedom movement, by email to discuss RMS's concerns over software patents in connection with free implementations of the .NET programming interface (Mono and DotGNU).

Glyn's article was published by Computerworld UK.

To sum up the key points, RMS stated the following in the interview:

1. Due to patents held by Microsoft on its .NET technology, the availability of two .NET implementations (Mono and DotGNU) under free software licenses doesn't mean that free software developers should, according to RMS, write code for the platform. His call on the free software community: "You shouldn't write software to use .NET. No exceptions." RMS says that Microsoft could one day use patents against free .NET implementations.


2. RMS thinks that the C# ("C Sharp") programming language should also be avoided. He makes a distinction between that one and .NET because C# was "standardized by a standards committee" and Microsoft made "a stronger commitment" concerning patents than for alternative implementations of other elements of .NET.


3. As a requirement for RMS to encourage the development of free software on free implementations of .NET, Micosoft would have to "make an ironclad commitment that its present and future patents will never be used against implementations of DotNET."

The exchange between Glyn and Richard has raised important questions and resulted in interesting answers. I agree with RMS on the incompatibility of software patents with the notion of free software and on many other patent issues, but I don't think the advice he gives to the developer community makes any sense at all in this particular case.

RMS's utopian advice runs counter to commercial logic and fails to advance the cause of software freedom

Adopting his advice would be an utterly stupid decision for any developer from a business point of view, which is actually normal because RMS's agenda is all about software freedom and not at all about commercial success. But even from a non-commercial free software point of view I think this kind of advice doesn't make sense in the world in which we actually live.

The only alternatives in terms of programming languages and platforms that could perhaps be supported under RMS's premises would have had to be open-sourced in exactly the same form more than 20 years ago (without even the smallest modification made ever since) and then the new software one writes on top of it today wouldn't be guaranteed to be truly free software for another 20 years. 20 years is the potential life expectancy of a software patent, and I'll explain the logic of this further below.

So unless someone wants to waste 20 years or even an entire professional life of 40 years just for the sake of an ideology, it's better to reject such utopian advice and take a realistic perspective on patent-related risks.

There's no particular reason not to develop software for .NET (as compared to any other platform on this planet), and free implementations of .NET such as Mono and DotGNU aren't really less free than a free Java application server or a PHP interpreter for Apache.

RMS focuses on the lesser risk and ignores the greater one

The fundamental mistake made by RMS in the aforementioned interview is that he narrows the whole patent-related risk down to only one company (Microsoft), which actually has a stronger commercial interest than any other in the world to make the .NET platform popular and to ensure developers succeed with the applications they build on top of it. And we all know how much competition there is between platform companies for the hearts and minds of developers. More importantly, Richard completely ignores the fact that hostilities against Mono and DotGNU could also come from other patent holders.

Even if one sides with RMS concerning what the greater risk is and rejects my business logic for the platform company itself being most likely to want the best for its application developers, no one can reasonably deny that there's a huge number of patent holders other than Microsoft whom RMS fails to take into consideration. That mistake is sufficient all by itself -- regardless of how to assess the different risks -- to prove RMS's advice concerning C#, .NET, Mono and DotGNU wrong in the sense that there are also patent risks concerning any other programming language or platform out there.

Yes, free software is incompatible with patents, but software patents exist on pretty much every kind of software technology and therefore I don't think one can make the case that free .NET implementations or software written to run on them is inherently less free than other software available under the same licenses.

Time heals the wounded and invalidates patents

In the patent minefield that exists, there's no such thing as a reliably patent-unencumbered programming language or API (application programming interface) except for a hypothetical scenario of no practical relevance. That scenario is one in which all patents that may read on the platform have either expired or can be easily invalidated.

Since software patents (at least in the jurisdictions I know) have a maximum term of validity of 20 years and patented ideas must be new by the time of the application (or they can be invalidated later on the basis of "prior art"), one can argue that if software was published (as open source) more than 20 years ago, all patents will either have expired or the published source code (which should be time-stamped to prove its vintage year) could be used as prior art to take down younger patents on the same technology.

Therefore, free software developers would have to use free platforms that are more than 20 years old (and were published as free software back then, not just later). The applications they write couldn't be guaranteed to be patent-unencumbered for another 20 years after the publication of their source code.

In other words, the price to be paid for a guarantee of being patent-unencumbered is to be decades behind the evolution of technology, and to be extremely patient relative to the duration of a human professional life.

The pragmatic alternative is to regard free software as a great idea and a wonderful vision, but to understand that patents make all software potentially non-free, regardless of whether the patents in question are held by Microsoft or anyone else.

The solution proposed by RMS (an "ironclad commitment") would be desirable but insufficient

At the end of the interview, RMS made the proposal I mentioned in item 3 of my summary of his position at the beginning of this posting. He said that Microsoft should make an "ironclad commitment" not to use current or future patents against free implementations of the .NET API.

I, for my part, would very much welcome such a commitment. But I disagree that it would make all the difference that RMS suggests it would make. It wouldn't solve the problem of third-party patents. Every other current or future software patent holder in the world would also have to make that promise in order for RMS's vision to materialize.

The second part also applies to platforms for which the original developer makes an "ironclad" patent promise. Even a free programming language like PHP can infringe and almost certainly will infringe on some third-party patents out there, unless you take a programming platform that was open-sourced more than 20 years back (as I explained further above).

So I strongly recommend to focus on how patent holders actually use their rights. In that respect, I will comment on Microsoft in greater detail in some other posting, but I can already say at this stage that there simply isn't any evidence of Microsoft using patents in a way that would drive companies out of business or jeopardize the existence of FOSS projects.

Don't cut off your nose to spite your face

RMS also refers to Eben Moglen's assessment that Microsoft's Open Specification Promise "is not something we can rely on." I can see why Richard and Eben say so. But I can also see reasons for which one could say the same about (to name but a few examples) Red Hat's patent policy, the promises Oracle made concerning the acquisition of MySQL (without wanting to comment on what Oracle is doing now), Google's vague assurances concerning WebM, the Open Invention Network's arbitrary scope of protection, or IBM's broken patent pledge.

Concerning IBM's pledge, I remember that RMS also commented on it unfavorably back in 2005 when it was made (not as aggressively as I did, but it was clear that Richard also rejected that approach). So he's aware of the fact that vendors don't make those public commitments in an "ironclad" form. That's a general problem and it's not particular to .NET, C#, Mono and DotGNU. Nor are the other concerns voiced by RMS specific to those technologies.

That's why I think a decision to write software for .NET, or to implement .NET interfaces in free software, isn't a statement against freedom any more than using any other current platform: Java, PHP, you name it. But acting in accordance with RMS's advice would be a self-imposed restriction of freedom, for no good reason.

With the greatest respect (which he deserves), he sometimes proposes to cut off one's nose to spite one's face.

If you'd like to be updated on patent issues affecting free software and open source, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.