In our day-to-day work looking after open source licensing, we lamented the proliferation of licenses and decided that we would split the difference and only offer a very limited subset of the approved OSI licenses choices to our users as a stand against the proliferation of the same. You see, we felt then and still feel now that the excessive number of open source licenses presents a problem for open source developers and those that adopt that software. Thus when we launched project hosting on code.google.com, we only launched with a small subset of licenses.
This was hardly a barrier to adoption. While there were some complaints from some corners, in the intervening 5+ years since then, we've grown to become one of the largest hosts while allowing that ethic behind license choice to persist.
What's changing and why change now?
We've added an option to the license selector to allow any project to use an OSI approved license. Simply select “other open source” and indicate in your LICENSING, COPYING or similar file which license you are using.
Public domain projects are still only allowed on a case by case basis, as true public domain projects are quite rare and, in some countries, impossible. We encourage those that want to truly ship public domain to look at how Dr. Richard Hipp does things around SQLLite and emulate his style. Email email@example.com if you’d like to request that license be applied to your project.
(Please note: we will continue to hunt down and kill non-open source projects or other projects using Google Code as a generic file-hosting service.)
Why change now? The TL;DR version is that we think we've made our point and that this new way of doing things is a better fit to our goal of supporting open source software developers.
The longer form of the reason why is that we never really liked turning away projects that were under real, compatible licenses like the zlib or other permissive licenses, nor did we really like turning away projects under licenses that serve a truly new function, like the AGPL. We also think that there were inconsistencies in how we handled multi-licensed projects (for instance: a project that is under an Apache license, but has a zlib component.)
To rectify this, we decided to add an additional option to the license selector that would accommodate some flexibility around open source licenses. We hope you find it useful and look forward to seeing how you use the site!