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