opensource.google.com

Menu

License Evolution and Hosting Projects on Code.Google.Com

Friday, September 10, 2010

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?

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!

By Chris DiBona, for the Project Hosting Team
.