Google joins the OpenChain Project for license compliance

Google is thrilled to announce that we are joining the OpenChain Project as Platinum Members. OpenChain is an effort to make open source license compliance simpler and more consistent. We will also join the OpenChain board and are excited that Facebook and Uber will be fellow board members.

Over the last 14 years, the Open Source Programs Office (OSPO) at Google has developed rigorous policies and processes so that we can do open source license compliance correctly, and at scale. This helps us use free and open source software extensively across the company and makes it easier to upstream our work. For us, it’s a matter of legal compliance as well as showing respect for the amazing communities that create and maintain the software.

Until now, there’s been no commonly accepted standard for open source compliance within an organization. Most organizations, like Google, have had to invent and cobble together policies and processes, occasionally comparing notes and hoping we haven’t forgotten anything.

The OpenChain Project is changing that by defining the core requirements of a quality compliance program and developing curriculum to help with training and management. It’s hard to overstate the importance of this work now that open source is a critical input at every step in the supply chain, both in hardware and software.

Google believes in this mission and is excited for the opportunity to use what we’ve learned to pave the way for the rest of the industry. We can help guide the development of standards that are rigorous, clear, and easy to follow for companies both large and small.

By Max Sills and Josh Simmons, Google Open Source

Adopting a Community-Oriented Approach to Open Source License Compliance

Today Google joins Red Hat, Facebook, and IBM alongside the Linux Kernel Community in increasing the predictability of open source license compliance and enforcement.

We are taking an approach to compliance enforcement that is consistent with the Principles of Community-Oriented GPL Enforcement. We hope that this will encourage greater collaboration on open source projects, and foster discussion on how we can all continue to work closely together.

You can learn more about today’s announcement in Red Hat’s press release and in our GPL Enforcement Statement.

By Chris DiBona, Director of Open Source

Geek Time with Eben Moglen

Earlier this year at LibrePlanet 2012, Jeremy Allison caught up with Eben Moglen, head of the Software Freedom Law Center, to discuss the GPLv3 and the software project Freedom Box. Some highlights from the chat are listed below:

What is the role of the Software Freedom Law Center?  (0:27)

Eben discusses the creation of the GPLv3.  (1:30)

By the time the GPLv2 license reached its 15th year he and Richard Stallman realized they needed to update it because of concerns around trusted computing (DRM lockdown) and international patent issues.  (2:24)

Jeremy points out that GPLv3 is not the license that the Linux kernel developers use and they haven’t agreed to adopt it, and asks is this is a big failure?  (3:50)

Jeremy comments that free software is doing well and on an upward trajectory with many people working very hard behind the scenes to work with companies interested in using free software.  (6:25)

Eben talks about the software project called “Freedom Box.”  (8:19)

Jeremy recommends viewing Eben’s keynote speech at LibrePlanet 2012.  (11:45)

Jeremy asks how Eben got started on this career path.  (12:18)

Thank you to Daniel Piccirillo for his great camera work for this interview.

By Stephanie Taylor, Open Source Programs

License Evolution and Hosting Projects on Code.Google.Com

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 [email protected] 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

Interviews @ GUADEC, part 1

Jeremy Allison, co-founder of Samba and member of the Google Open Source Programs Office, recently returned from GUADEC, the GNOME conference held in The Hague, Netherlands. Jeremy was kind enough to bring his video camera along with him so he could interview some open source community notables and share the recordings here on this blog.

Jeremy’s first interview is with Bradley Kuhn, who is a board member of the Free Software Foundation, the president of Software Freedom Conservancy, and the Policy Analyst and Technology Director at the Software Freedom Law Center. Jeremy and Bradley discuss the GPLv3 and Bradley’s work as an advocate of free and open source software.



By Ellen Ko, Open Source Team

Updates from the Free Software Foundation Europe

By Shane Coughlan, FTF Coordinator, Free Software Foundation Europe

My name is Shane Coughlan and and I work for Free Software Foundation Europe (FSFE), a non-profit, non-governmental organisation with offices in Germany, Switzerland, Belgium and Sweden. You may remember me from my last FSFE update on this blog on the Freedom Task Force, which is the FSFE's legal training project which I coordinate. Google's Open Source Team invited me to send an update about some of the cool stuff we are doing, so I'd like to start by giving you a little background about who we are and what we do.

The FSFE is one of four sister organisations, the other three being the Free Software Foundation (FSF) in the United States, the Free Software Foundation India and the Free Software Foundation Latin America. The FSFE works on European Union and United Nations software policy and we engage with issues like the European software patents debate. We also engage the community on these issues at many European software conferences. The Freedom Task Force focuses on providing education, training, consultancy and legal assistance in answering questions about Free Software licenses. On a day-to-day level this involves attending conferences and local meetings as well as dealing with incoming requests via email from both commercial and non-commercial community members.

One of our main activities during the last two years has been facilitation for the
European Legal Network. This is a group of Free Software legal and technical experts who share knowledge with the community. In the last year and a half we have scaled to cover nineteen European countries (a total of twenty-seven) and to have over one hundred and twenty members. During the month of September alone, we will have two physical meetings to discuss Free Software business processes and software patents. It's quite high level stuff, but we hope to provide participants insights into the resolution of long-term deployment questions and builds on the excellent work of organisations like gpl-violations.org.

Other wonderful news comes from the recent the Akademy 2008 conference, where one of our long-term infrastructure projects came to fruition. KDE e.V. — the organisation representing the KDE project in legal and financial matters — voted to adopt the Fiduciary Licence Agreement (FLA) as an option for its project contributors. The FLA is a legal document that addresses the issue of copyright fragmentation by providing consolidation in common and civil legal systems, and acts as a tool to assist with re-licensing and license enforcement. It's a baby of the FSFE legal project, drafted some years ago for FSFE's own fiduciary programme, and is available for other organisations to adapt for their own use.

That brings me to our biggest news for this week. The FSFE has just announced that we are translating the Fiduciary License Agreement (FLA) into ten languages to provide copyright consolidation options to local projects across Europe. We're looking forward to providing tools to help people manage their code and we believe it's important to at least have reference documents in as many native languages as possible. Such tools are likely to become more important as Free Software grows, and FSFE is proud to make a contribution in this area. Kudos are also due to the kind folks at Google, who made a donation to support both our outreach and translation work earlier in the year.

If you would like to learn more about FSFE's work you can visit our website at www.fsfeurope.org. You might also want to learn more about the legal project specifiically or information about contributing to our efforts. If you want to become part of the FSFE family you might also want to join the Fellowship.

Thanks for reading, Happy Hacking, and I'll see you at the next conference....

Mozilla and Eclipse Licenses Now Available for Hosting Users

By Chris DiBona, Open Source Team

You might remember that we recently removed the MPL from the list of licenses available to projects hosted on Google Code. We did this because we have been trying as a company to make a statement against open source license proliferation. You see, we feel it is damaging to the larger world of open source development if there are too many duplicative licenses. So...Why are we changing our mind about the MPL and EPL now?

Since we started hosting projects, we've been petitioned by the Eclipse Foundation (of which Google is a member) and its community of developers to include the EPL as an option for new projects. We've resisted until now as we felt that the features of the EPL were not unique enough to justify its inclusion. This hasn't changed, but how we think about licenses is getting a bit more nuanced.

Eclipse is an important, lively and healthy project with an enormous plug in and developer community that uses an otherwise duplicative license. They aren't interested in using the BSD or other open source licenses that are readily combinable with EPL code. We have decided that after nearly 2 years of operation, that it was time to add the EPL and serve these open source developers.

We also want to show our solidarity with our friends at the Eclipse project through this action.

Considering the user base, and not just the popularity of an otherwise non-majority license isn't unprecedented for us. For instance: We considered this when we first opened the site in our acceptance of the Artistic/GPLv2 combination which sees little substantive use outside of Perl.

In that light, our removal of the MPL from the site seemed a little absurd. So, our bad. We're putting that option back up for new projects. The groups that want to use the MPL to enable their additions, extensions and more for Firefox and other Mozilla projects are legion and considering their recent summit, represent a very healthy global collection of developers.

Let us know what you think in the comments and we look forward to seeing the new projects that we'll be able to serve here on Google Code.

Standing Against License Proliferation

By Greg Stein, Open Source Team

The proliferation of Open Source licenses has been a known problem in the community for a few years. As the number of licenses grows, the possible combinations and interactions skyrocket. This makes it very difficult to mix code from multiple sources because the licenses may be incompatible or create burdensome notification or publishing requirements. Many people in the community have been talking about how to stem the tide of new Open Source licenses, and how to reduce the existing set, in order to simplify the legal framework surrounding the Open Source universe.

When we set out to create the project hosting service on Google Code, I turned to my colleague Chris DiBona and said, "Dude. I think we have an opportunity here. What do you think if we offer only a limited set of licenses?" He replied, "Hunh... Cool idea!" Fifteen minutes later, we had a list of six licenses: Apache License v2.0, (New) BSD, MIT, GPLv2, LGPL, and MPL 1.1. About four weeks before launch, Robert Spier pointed out our oversight in not remembering the Artistic/GPLv2 dual-license used by the Perl community. Whoops! We launched with those seven licenses (and added GPLv3 a year later). Further, we do not allow any dual-licensing (other than the Artistic/GPLv2 combination), nor the dreaded tri-license. I'm not going to get started on what I think about that.

Two years later, we are nearing 100,000 projects hosted on Google Code. The trend around licensing is obvious: GPLv2/GPLv3 represent 42.6% of the projects, and Apache is 25.8%. MIT, BSD, and LGPL are at about 8% each, Artistic at 3.5%, and MPL 1.1 at a mere 2.7%. This follows my own observation about how people license their projects. If they are advocates of Free Software, they will choose GPL; advocates of Open Source will choose Apache (a more modern and thorough permissive license, compared to BSD or MIT). And this is exactly what I recommend to people: choose GPLv3 or Apache v2 based on your personal philosophy.

People very rarely choose licenses like MPL, EPL, or CDDL unless they are part of those communities (Mozilla, Eclipse, and Sun, respectively). Unfortunately, licenses that are typically community-specific also tend to create islands of code. And while there is no good reason that I cannot lift code from an EPL'd Eclipse plugin and incorporate it into some Apache-licensed server application that I'm writing, that kind of blending just does not happen. Based on the low popularity, and in an attempt to limit this artificial segregation of code, we plan to remove the MPL from the set of licenses on our project hosting service (for new projects; existing projects will not have to relicense).

At Google, we believe that the software community would be much better served by a reduction in the number of licenses used by software projects. We hope to steer people in that direction with our license choices on Google Code. We also highly recommend choosing the Apache License or GPLv3 for your projects.

Updates from the Free Software Foundation

By Chris DiBona, Open Source Team

Google's Open Source Team is a proud supporter of many Free and Open Source technical and advocacy organizations. From time to time, we ask that these colleagues give an update to the community about their latest and greatest achievements. Peter Brown, Executive Director of the Free Software Foundation, was kind enough to write in to us:

The Free Software Foundation (FSF) recently held its annual members meeting at MIT in Cambridge, Massachusetts, U.S.A. The meeting is a chance to reflect upon the achievements of the year past and plan for the year ahead. Google has supported our work in the past through our corporate patron program, and this year they have just confirmed that they are renewing their support once again. This seems like a good occasion then to brief Google followers on what work we have been doing and what you can expect from the FSF in the year ahead.

The FSF launched the GNU GPLv3 on June 29, 2007. This was the culmination of an 18-month period to redraft the world's most popular free software license. I am pleased to report that not only have we published a license that protects free software from the latest attempts to make it proprietary, but we have also seen widespread adoption, including developer and corporate support. We have also updated and launched the GNU LGPLv3 and created a new license: the GNU Affero GPLv3. You may have also heard that the FSF, Wikimedia and Creative Commons are cooperating over the new GNU GFDL — the license currently used for all articles on Wikipedia. You can find out more about FSF copyleft licensing at the FSF Licensing and Compliance Lab.

With the release of the GNU AGPLv3, we have also started to make progress on how to tackle the issue of computer user freedom and web services. To that end, we recently hosted a summit, "Freedom for Web Services," as a launching point for a year-long community discussion on this topic. Reports from that summit will be published soon.

The Free Software Foundation sponsors the ongoing development of the GNU project — and many new GNU projects are added every year. GNU now stretches far beyond the core system components found in the typical GNU/Linux distribution. Apart from our own projects we also work to highlight those projects that have a strategic importance to free software. The FSF high priority projects list is currently under review following a recent rash of success, and we hope to relaunch in April with a new set of targets for software development.

In 2008, the FSF will be marking the 25th anniversary of the launch of the GNU project — the starting point for the free operating system GNU/Linux, and the free software movement. We are planning to mark the anniversary with a public awareness campaign. Expect to see lots of people talking about free software during the year ahead. In preparation for that campaign we have updated our website, www.fsf.org, with a new friendly look as we welcome a new audience of users to free software.

Speaking of celebrations, Happy Document Freedom Day! Our campaign for Open Document has been underway since October 2005, and we are helping spread awareness of the need for our public institutions to hold records in formats that we can all utilize. You can join us in this process by sending an email or letter to your national or local government officials or government agencies and politicians. Getting your voice heard on this issue will go a long way in preparing the political ground for the acceptance of free and open formats. There are many other ways you can get involved beyond our Open Document efforts. Head over to our campaign center now or look through our volunteer section to find something that you can get active with.

Part of our public awareness campaign is a major free software event to be held in Massachusetts in the summer of 2009. We are working in collaboration with local educational institutions and other stakeholders to develop an event that will bring developers and users together in a fun and interesting way. We also aim to use the event to highlight the need to draw more young women into computer science. Google's own Leslie Hawthorn has generously joined our planning committee, and you will probably hear updates from her later this year.

Google's support is great to have, but we receive the bulk of our funding from individual contributors and much of the work is done by volunteers. You can join the Free Software Foundation as an Associate Member — it's a great way to get involved and stay connected with our work.

Many thanks to Peter for this report.