Nearly 6 years ago when we first started thinking about
doing project hosting on code.google.com we noticed something particular about the other open
source project hosting sites. They either accepted all Open Source
Initiative (OSI) approved licenses, like Sourceforge, or they only accepted one, like the
Free Software Foundation's Savannah project, which only accepted GPL'd projects.
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 D. Richard Hipp does things around SQLite and emulate his
style. Email google-code-hosting@googlegroups.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!
