Since its launch just over three years ago Google Code has become a widely used repository for the code of free and open source projects (OSS Watch have a briefing note on how to start a Google Code project here). Unlike its venerable competitor Sourceforge, Google Code permits only a small subset of the Open Source Initiative‘s approved licence list. At the time of writing you must distribute under one of the following licences if you want your project to be hosted on Google Code:
Why do Google only allow this subset? The answer is given in this FAQ answer:
Why do you only offer a small set of licenses?
The open source community has been flooded with lots of nearly identical licenses. We’d like to see projects standardize on the most popular, time-tested ones. The selected licenses offer diversity to meet most developer needs.
The phenomenon described there, licence proliferation, has been recognised as a thorny problem for many years. Back in 2004 the Open Source Initiative kicked off a project aimed at making the dozens of free and open source licences more readily comprehensible and easier to assess. The final report of the project recommended the strategy of grouping the licences by function and drawing up a menu of ‘licenses that are popular and widely used or with strong communities’ to help people choose.
Despite the imperative to keep the number of licences manageable, the Open Source Initiative keeps approving new ones where they accord with the Open Source Definition and clearly provide new features over the current stable. Recently they approved the GNU Affero General Public License v3 (AGPL), a close cousin of the GNU General Public License v3. In fact the AGPL’s provisions are identical to those of the GPLv3 except for one additional clause:
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
This clause is intended to close what has become the ‘ASP Loophole’ present in most current open source licences. As networked computers have become more and more common, it was noted by the free and open source community that many ‘Application Service Provider’ (ASP) companies were setting up selling services over the internet that were based upon tweaked and improved versions of free and open source software. If these companies had been distributing the software itself, many of them would have been obliged by the licence under which they received the software to make the source code to their improved versions available to all. However as they were merely making the service based on the software available they had no such responsibilities. Under the AGPL, however, an ASP who used APGL’d software as the basis of a service would have to share their source code as a consequence of allowing people to interact with it over a network.
Now in fact during the drafting of the GPL version 3 itself, many had argued that such a provision be included. In the event the authors of the GPLv3 decided that they did not wish to make such a provision mandatory, and instead chose to help draw up the AGPLv3 and add a clause to the GPLv3 that ensures compatibility between codebases released under the two licences. In this way developers could choose whether they wanted to enforce source distribution as a result of network interaction with their code and its derivatives.
Now some developers who use Google Code have started wanting to choose the AGPL for their code, and indeed some have already done so, simply by selecting ‘GNU General Public License v3′ on the form when they create the project then adding a note to the project itself which states that it is in fact under the AGPL. Google, in the shape of their Open Source Programs Manager, Chris Di Bona, responded initially by saying that they would not include the AGPL as it was not OSI-approved and would exacerbate proflieration. Once it was OSI-approved, the issue arose again and Di Bona argued on his personal blog that the terms of the AGPL were unclear and that time was needed to see how the licence was used and construed. Thus AGPL-licensed projects are moving away from Google Code.
Of course, some chose to see Google’s rejection of the AGPL for Google Code as a self-interested act. After all, Google’s own business is built on services implemented using adapted free and open source software. If free and open source software licences had always contained AGPL-like provisions, the source to many of Google’s popular services and adaptations (including potentially the code used to implement many aspects of Google’s core search business) would be available for the world to see and use. While it’s tempting to speculate on conspiracies, particularly those that involve enormous corporations, I can’t see that Google’s opposition to the AGPL is based on a perceived threat to their business model. Having achieved their ascendancy already, they can simply refuse to adapt any AGPL’d code; it’s not as though there is anything likely to be under the AGPL that Google could not afford to re-engineer themselves.
What these events do point to, though, is the ability of large organisations like Google to potentially change the open source landscape. By limiting the licence choices on Google Code, Google openly acknowledge that they are trying to change the profile of selected licences within the community. At the moment their aim is to suppress proliferation, a common goal with the OSI. When asked in the thread linked above what would persuade Google to allow AGPL on Google Code, Chris Di Bona replies that once it is as widely used as the BSD license, it would naturally find a place there. While this seems reasonable, I have to wonder how such a benchmark would work if Google Code becomes even more widely used. Eventually exclusion from Google Code could become a major obstacle to uptake of a licence, and thus a Google-excluded licence could have real difficulties meeting the popularity conditions necessary for subsequent inclusion. Even with the best of intentions, an organisation the size of Google needs to tread carefully.