GPLv3: is anti-Tivoisation flawed?

GPLv3 is the latest incarnation of the Free Software Foundation s (FSF) GNU General Public License (GPL), published in June 2007. Its predecessor, GPLv2, was published in 1991 and has since become the most widely used FSF software License ever with estimates of between 50% and 70% of all open source and free software being licensed under GPLv2.

A lot has happened in the software world since 1991, to the extent that the FSF announced in January 2006 that they were going to create a new GPL license. The purpose of this new license would be to address some of the areas identified for improvement and clarification in GPLv2 such as lack of clarity on patent indemnity, better understanding of what is understood to be derivative works (now classed as covered works), improved internationalisation and better remedies for inadvertent License infringement (rather than the previous immediate Termination effect). Indeed the new GPLv3 license is nearly double the length of the GPLv2; such has been the fortitude to write a license which is more precise, clearer in language and ideally more consistently interpreted.

But is the GPL v3 future proof ?

The GPLv3 was written by Richard Stallman of the FSF and Eben Moglen of the Software Freedom Law Centre. There was by all appearances a very broad, consensus-driven process to arrive at GPLv3. This process was informed by 4 separate Committees and broad public comment:
– Committee A comprised mostly Free Software supporters and Projects such as Debian, Google, Samba, SleepyCat, Red Hat and others.
– Committee B included the erstwhile giants of the IT and software world such as IBM, HP, Sun Microsystems, Apple, Nokia, Intel and so on.
– Committee C constituted various academics, lawyers and activists in the public domain with an interest in the GPL. Last but not least
-Committee D comprised interested onlookers, programmers and licensing enthusiasts such as myself.

I do not intend on providing a summary of GPLv3 there are already a number of good summaries available here and here, but I will deal with one specific part of GPLv3 and that is the Tivoisation aspect.

Tivoisation potentially a counter-intuitive move?
My background is in commercial software licensing and development (but I am not a lawyer!) – as such I am particularly interested in the extent to which for-profit entities and businesses will wish to use software that is licensed under GPLv3 for their products and so I have a particular interest in the impact of the anti-Tivoisation clauses in GPLv3.

Firstly let s understand what is meant by the term Tivoisation and more importantly how it has been construed and interpreted by the Free Software Foundation.

Briefly, Tivoisation is named after the Tivo product, a digital video recorder and consumer device which allows users to capture television programming to an internal hard disk storage for viewing later basically you can record many TV channels at once and watch them later (so called time-shifting). Tivo contains a small Linux OS and so under GPLv2 this requires the manufacturer to make the source code available to users which it does. Users can modify the source code and then compile it – but it won t run because Tivo contains a special mechanism which notices that there have been changes to the code and just shuts down. Therefore whilst Tivo is fulfilling its obligations as required under GPLv2 it is actually inhibiting the four freedoms as set-out by the FSF and that is to preserve the users freedom to run, copy, distribute, study, change and improve the software . As the software no longer works post-modification, due to the special mechanism that forces Tivo to shut down post source-code modification, the user is prevented from running the software.

So what does the new GPLv3 add in order to preserve these freedoms?

Firstly GPLv3 contains some new terms and requirements under Section 6 of the License, titled Conveying Non-Source Forms . The first new term is User Product and is defined as per the below. As far as I can ascertain, the purpose of including this definition is to ensure as broad as coverage as possible for any products that make use of software using GPLv3 licensed software.

“A ‘User Product’ is either (1) a consumer product , which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.”

So User Products can be digital recorders (such as Tivo), mobile phones, CD players, Televisions and the like but could also be fixtures and fittings, furniture and alarm systems etc. Personally I believe that this definition is extremely important as it could be interpreted to mean anything in a dwelling including potential new consumer or household devices as yet uninvented. The implications of applying such anti-Tivoisation clause to these as yet uninvented intentions we cannot either envisage or quantify. Therefore we do not know what the impact of this broadened scope could ultimately entail.

The second new term introduced in this section is the term Installation Information described as

Installation Information for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

This is a new requirement that was not in GPLv2 and is intended to ensure that entities using GPLv3 licensed software also provide any and all additional information necessary to ensure installation and running of said software. This is a very interesting concept in that there is more often than not valuable IP and software know-how contained in installation methods that may actually provide unique value to the entity using GPLv3 licensed software. Whilst it is clear that the quid-pro-quo for accessing GPLv2 licensed software is to provide that same freedom to others, we cannot quantify or easily assess at this early stage what special processes or unique knowledge may be contained in installation methods . Indeed I would guess that this new term installation methods will create as much confusion to the GPLv3 as the term derivative works generated in GPLv2.

The next most interesting aspect of this new anti-Tivoisation tenet is in the paragraph following the above definitions, quoted in full below (note that the bold markup is my own):-

“If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).”

It is clear from our discussion above that the entity using the GPLv3 software must provide the source code and the installation details of a User Product when conveying the code. This does not apply if the entity using the GPLv3 software or any other 3rd party cannot install modified object code on the User Product. So if you don t have that freedom i.e. the freedom to modify the object code in the ROM, then you cannot pass that freedom on to future Licensees or users of the software.

I suspect as I was not party to the GPLv3 license discussions that this final sentence was added in order to allow those entities that distribute User Products containing GPL code installed in the ROM (such as mobile handset manufacturers, amongst others) a get-out clause to avoid having to provide source code or to provide installation information. This also makes sense from a FSF perspective in that they are still adhering to their freedom aims as generally software contained in the ROM is not modifiable or generally modified by users.

On first reading this appears to be sufficient for the commercialisation of GPLv3 covered code in mobile devices and other User Devices. However on closer examination of this paragraph there appears to be a number of implications that may not have been foreseen and were probably not intended. Although with as many brains in all those Committees overseeing the new GPL I feel sure that this point must have either been brought up and ignored or alternatively deemed not sufficiently important by the FSF.

Anti-Tivoisation clause potential (unplanned?) impacts
Firstly the presumption under this clause is that you, the entity using the software licensed under GPLv3 terms, will only store software that may be modified in the RAM memory of a device. This get-out clause works only up-to-a-point and presumes that a mobile handset manufacturer using GPL v3 code will never want to or need to modify software in the ROM, as they would otherwise trigger the obligation to provide source code and installation files. However, this is already technological history and has been surpassed by the introduction of FOTA. FOTA i.e. Firmware-over-the-air upgrades are used by most of the major handset device manufacturers and this is remote modification of the ROM image on the device.

We could perhaps argue that this is a change to or of the whole ROM image and as such is not really modifying at all but replacement . Or perhaps the exception here is that the FOTA generated binaries that are stored in the ROM are not a change of source code but a change of binary code? And perhaps it doesn t actually matter that a mobile device manufacturer would have to provide the installation files as well as the source code as perhaps it is unlikely that there is valuable proprietary IP contained within installation files (although I doubt this).

I am not sure that such an argument would hold water and even if it did, the same argument would be less effective in relation on new technologies designed to provide advanced mobile device management capabilities, such as the soon-to-be-completed OMA SCOMO specification.
SCOMO (Software Component Management Object) is the successor to FOTA and is being introduced by the Open Mobile Alliance (OMA). It is intended to enable remote software component management to allow network operators and mobile device manufacturers to deploy, install and execute discrete software components in both the RAM and more importantly the ROM memory post-device sale (note that VisionMobile have recently published a research paper on Mobile Software Management where we discuss SCOMO in detail see our white paper for more info). Whilst FOTA has been very successful in allowing ROM upgrades remotely to the complete ROM image, SCOMO allows discrete component-based updates to the ROM. The killer application of SCOMO is being touted as the ability to update those particularly important and more intrinsic middleware applications resident on a mobile device that are stored in the ROM such as Java and Flash libraries, graphics codecs and libraries and so on.

So what does this mean?

I strongly believe that this is a classic instance of technology transcending business models and licensing frameworks. Whilst it may have been originally envisaged that mobile device manufacturers would only ever need to update source code resident on the RAM and not ROM this is and will not be the case in the future.

Of course there are some mitigations to this issue. For example those User Products that are licensed via the Dual Licensing mechanism will not be subject to these obligations, to the extent that they are licensed under GPLv3 and also under a more commercially friendly license and will of course be precluded from this obligation under the commercial license regime. But not all User Products are dual-licensed.

All in all the moral of this story may be that by legislating to exclude very specific use-cases, you could actually end up precluding technological advancements and improvements on specific sets of software licensed under GPLv3. However perhaps this is considered a small sacrifice in return for adhering to the freedoms that are demanded, and also passed on to others, under the GPLv3, but it remains to be seen if commercial entities deploying free and open source software will be prepared to move to GPLv3 and accept these obligations.

– Liz

Flash-Inside (R)

Adobe’s Flash Lite has a enviable history of market penetration. Starting from DoCoMo handsets in May 2003, Flash Lite is quickly spreading to Europe as a feature of Nokia’s S60 and recently Series 40 platforms. As an application environment, Flash Lite is second only to Java ME in terms of market penetration, yet is controlled by a single vendor. Adobe projects to have shipped 1 billion Flash Lite -enabled devices by 2010; So how will Adobe manage to penetrate the mobile device market so agressively ?

Flash Lite penetration
As an application environment, Flash Lite’s installed base is second only to Java ME, which has been around since 1999. Yet Flash is controlled by a single vendor (Adobe), while Java ME’s roadmap is controlled by Sun and the consortium of vendors participating in the Java Community Process (JCP). How does Flash Lite’s penetration compare to other application environments ?
– Java ME is embedded on approximately 50% of devices shipping in 2007 (over 500 million) according to Informa and approx. 80% of devices shipping in 2007 according to Ovum.
– Adobe estimates 220 million Flash Lite -enabled devices (mobile and consumer electronics) to have shipped by the end of 2006; given that the ratio of mobile to CE device models is 2 to 1, we can guestimate the number of devices with Flash Lite to 145 million.
– SVG-T implementations are embedded in more than 225 million handsets to date according to Ikivo. Given that SVG-T is only a graphics rendering engine (without any scripting element prior to version 1.2) it doesn’t really compare with Flash Lite which combines both declarative and scripting elements. Version 1.2 of SVG-T implementations started shipping only recently, so there market penetration is really lower than versions 1.1 and earlier.
– Symbian OS has been shipped in 126 million devices (as of March 07) according to Symbian. This puts S60 at 60-70% of that figure.
– Other application environments (.NET Compact Framework, App Forge, Python, etc) have much lower market penetration.

So how has Adobe/Macromedia accomplished such a market penetration and how will the company manage to reach the 1 billion phones mark by 2010 ?

Aggressive subsidising
A closer inspection of Al Ramadan’s presentation during Adobe s financial analyst meeting in March 2007 reveals the following per-unit royalties for Flash Lite installations; Average royalties dropped from $0.37 in Q4 2004 to $0.31 in Q4 2005 to $0.20 in Q4 2006 (note that prices are approximate as I had to extract them from visual bar charts.). This is aggressive underpricing, far beyond the trend of price erosion for embedded mobile software today. As a $2.5 billion-a-year company, Adobe can afford to subsidise the Flash Lite product in order to stimulate sales of its tools (tools account for the majority of Adobe’s revenues). This is a classic platform->tools strategy practiced by Qualcomm (BREW sales drive chipset sales + IP royalties), Microsoft (Windows sales -> drive Windows, Office and Visual Studio sales) and Intel (new hardware architectures driven new chip sales).

The right technology
Adobe’s acquisition of French company Actimagine in October 2006 gives Adobe very fast rendering technology (by some accounts 4 times faster and 4 times smaller memory footprint in rendering Flash animations). I believe that the introduction of Actimagine rendering technology in the Flash Lite codebase in Q4 2007 will allow Flash Lite to penetrate lower-end devices (and could also explain the inclusion of Flash Lite in the Series 40 platform). Adobe estimates the target addressable market for Flash Lite to jump from 51% in 2006 to 72% in 2007 (again numbers are extrapolated from Adobe’s financial analyst presentation).

The right tools
Adobe has without doubt the best-in-class tools for mobile content development. Particularly Device Central released recently is a role model for how to best help developers take their applications to a highly diverse and fragmented market (Sun should take note).

More importantly, the UI strategy teams inside handset OEMs are people who ‘ve grown up with Flash and Macromedia’s tools. Designing mobile applications with Flash (Lite) is familiar to handset OEMs. This is despite the fact that developing core applications based on Flash UI (see the LG Prada) takes more C++ glue than meets the eye.

A ghost platform strategy
I previously argued that handset manufacturers will not buy platforms. Platforms are expensive to integrate and more importantly engender single vendor lock-in. So how has Adobe managed to embed Flash Lite on more than 200 handset models from 16 manufacturers and how will it sustain this growth ?

Adobe is merging its Flash Home, Flash Cast, Flash Lite and Flash UI products into a single codebase, which will be released towards the end of this year. Adobe is pitching the Flash family as software that will cater to any manufacturer need; whether an OEM needs to implement a vector graphics library, a UI framework, an application environment, a content-driven application (on-device portal), or an active idle screen, Flash is the tool for the job. Flash is therefore solving a short-term problem for the OEM.

And while Flash is a tactical solution, it is establishing itself as strategic platform within a large and diverse range of handset models. This is what I would call a ghost platform. It reminds me of MS-DOS and IBM. Little did IBM know that the operating system would be crucial to value generation and sustainability. But today’s handset OEM know better, right ? I ‘m sure they do, but I believe that by adopting Flash as a tactical solution, Flash might emerge as tomorrow’s Windows.

Flash-inside, anyone ?

– Andreas

How iPhone is impacting the mobile industry

As an analyst working inside the mobile industry I ‘ve witnessed to hubbub of cheering, admiration and idolatry for the iPhone in the last week since its release. However, I do not think that the real impact of the iPhone is in the sleekness of its curves, the intuitiveness of its interaction design or its cool-looking widgets. I believe the iPhone is creating a much deeper impact in the mobile industry, along the following three lines:

1. The phone as a premium consumer good.

Status quo: Operator efforts to attract and retain subscribers have resulted into considerable phone subsidies in most markets, primarily Europe and the US. A handset is typically subsidised by several hundred dollars in order to attract a customer purchase. As a consequence, mobile handsets have become commodity items in the eyes, where the price is the primary differentiator. Consumers therefore have come to not respect the value of the mobile phone, which they see as reflected on its price.

iPhone impact: the iPhone has not been subsidised – at $500-$600 this is a premium-priced phone (with a 55% margin according to iSuppli). Yet consumers have been flogging to buy it, realising implicitely that there is a brand premium that the iPhone can command. If more phone manufacturers follow iPhone’s example of denying any operator or channel subsidy, that would foster a more healthy market, where the value of phones is more reflective of its price, allowing operators can reduce tariffs in response to lowering subsidies.

2. ODMs gain back market share

Status quo: The top-5 OEMs (Nokia, Motorola, Sony Ericsson, Samsung, LG) have over 82% of the market (Q1 2007 figures from Informa T&M). This figure has been growing in the last years and is showing signs of stability. As a result, smaller OEMs and ODMs have seen their market share dwindle.

iPhone impact: Apple expects to sell about 10 million iPhones next year, or 1 percent of the 1-billion-a-year mobile phone market. This goal seems easily achievable since the iPhone is reported to have sold more than half a million handsets in its opening weekend. the iPhone is made by Quanta and Foxconn, two Asian ODMs. ODMs have produced highly customised phones like the O2 ICE and O2 Cocoon before, but not in volumes of this scale. iPhone will undoubtedly shake the ground of top-5 OEM dominance by increasing the credibility of Asian ODMs and their ability to execute not only me-too, but daring industrial designs. this comes at a time when brands and operators are increasingly looking at cheap routes to market for uniquely customised handsets.

3. UI technology coming to the forefront

Status quo: software vendors have been challenged to sell products on the basis of improving the user experience; whereas this is a common ‘sales pitch’, software sourcing deals are signed on the basis of added features, functionality or post-sales revenue. An improved UI is an intangible premium, and therefore undervalued.

iPhone impact: the iPhone introduces an intuitive user interface (to be more specific, an innovative interaction design, including use of orientation, light and proximity sensors) which are not to be found on any other phone available today. The appeal and sexiness of the iPhone user interface is actually leading to the appreciation of the value of the UI as a tangible premium (tangible as in ‘see how much premium the iPhone can command!’). The effect this has had is that already at least a couple of mobile operators / handset manufacturers have started projects aiming at producing iPhone killer phones. At the forefront of these projects are UI technology companies who can now pitch their wares as not just nice-to-have but as software solving short-term problems for the manufacturers/operators, that is allowing them to favourably compete in the post-iPhone age. Naturally, image/video hardware acceleration vendors are also seeing the market change in their favour.

– Andreas