Pitfalls of Open Government Data Licensing

This week, a new columnist joins the OSBR: Jordan Hatcher is a lawyer, academic, and entrepreneur working on Intellectual Property and Internet law issues in the UK and worldwide. He writes:

Drafting new open licenses is not something to be taken lightly. The recent announcement of the Italian "Open" Data License (IODL) drives this point home quite effectively. I use quotation marks around "open," because this new license is not open and should be avoided for open data licensing. While the group behind the IODL are to be applauded for taking the initiative for making more government data accessible, the story of the IODL's development offers a topical lesson for the open licensing community.

A Tale of Two Open Government Initiatives

The UK recently announced a new Open Government Licence (OGL) for a broad range of public information. The UK government crafted this license only after examining existing open licensing solutions such as Creative Commons and Open Data Commons and concluded that they required, based on their needs, to draft their own legal tool. Why? Their reasons are their own, but my understanding is that this is because they wanted a single license for both data and content and CC licenses didn't fit due to issues with database rights and Open Data Commons only applies to databases. This is a sensible reason from my perspective. The UK government went about drafting their new license in the right way -- by consulting many people in the open licensing community and gathering input from experts -- and the resulting document makes for an excellent example of how to go about this process. The OGL complies with the Open Definition, which is an important standard for defining the rights behind openness, and is effectively an "attribution-only" style of license. The OGL applies to a broad range of information produced by the government, but specifically takes into account some of the unique situations that come up with open (government) data.

The recently announced Italian Open Data License is neither actually open as the Open Definition defines it -- it contains a non-commercial restriction clause -- nor does it appear to have been drafted with a great deal of attention to the specific problems of open data. Data and databases are a bit like software and a bit like content in terms of what users do with them, and data/databases have some unique legal rights, particularly in Europe where we have the Database Directive. This means that open licenses in this area should take into account the particular legal and technical challenges of open data when addressing this area.

This problem doesn't arise just in newer, greenfield, areas of open licensing such as open data. It's a problem that has a history in software as well.

License Pollution

Drafting workable open licenses is hard work, but the good licenses make it look easy, which is perhaps why so many people take on the task of writing their own terms. These range from the practically public domain WTFPL, and all the *ware licenses: sisterware, catware, beerware, tacoware, all the way to much more restrictive and complicated homegrown licenses.

By tweaking a term, adding an addendum, or contributing a clause, you create a new license. A perfect example is the so-called BSD/MIT group of licenses, where there are limitless variants. Many of these are relatively innocuous; these licenses weren't drafted for mass consumption and so each time you change the "licensor" it produces a variant. These generally get lumped as "BSD-style" licenses. However the temptation is great to add just an extra clause or restriction on to these licenses (since you're tinkering with them anyway...).

Each change increases the chance that you are defeating legal interoperability as opposed to technical interoperability. This means that you may have the perfect technical solution -- the best dataset or functioning code for the job -- but the license doesn't allow its use. We inadvertently build "license silos", even within the open licensing community that prevents use and reuse between licensed content, code, and data. This situation frustrates both lawyers and techies alike.

The Pollution Solution

Thankfully there's an easy way to avoid license pollution and thus license silos: use an existing open, public license. Public licenses -- licenses drafted for mass use and often maintained by a host organisation -- offer many advantages:

• an upgrade path for bugs and for changes in the law or prevailing practice, such as GPLv2 to GPLv3
• public comment periods, allowing for open source style "all bugs are shallow" development for the open licenses themselves to come into play
• communities of users that help each other define common practice and approaches. Eben Moglen often describes the GPL as the "constitution of the free software community," and constitutions only become living, working documents through active participation. Using an existing open public license taps into that and helps your business.
• increased user uptake: using existing solutions simply makes it easier for your users as they no longer have to stop and invest significant resources into figuring out a new license.
• less cost: rolling your own and doing it right costs money and time. Take advantage of someone who has already done the hard work for you.

All of these reasons aren't all that different from open source software development itself. Somehow I think we end up with a blindspot for these very same advantages when looking at open licensing. Self-drafting an open license should be a court of last resort, but sometimes it is a valid and justifiable option, such as with the UK's Open Government Licence. However, instead of having all of the UK's hard work and good drafting only be used within the UK, should we instead be looking to roll this document as a template across Europe? It certainly would help initiatives such as those in Italy avoid the pitfalls of lone open license development.

GLOSS

Today's columnist is Christopher Sean Morrison from BRL-CAD. He writes:

"If the Trojan horse had been made of glass, Troy never would’ve fallen."

Scott McNealy, Sun Microsystems Co-founder

High atop an office building on the outskirts of Washington D.C., a bunch of U.S. government software developers from around the country got together this week with a common vision: more open source. I was among this collection of geeky, coffee-drinking, sandal-wearing patriots, most of whom work directly or indirectly for the U.S. Department of Defense (DoD) where we're part of a grassroots movement to promote the use and development of open source by government organizations. This was the second working group meeting of the Mil-OSS community, where a collection of civilians, military, and contractors gathered to discuss topics of policy, philosophy, legalities, life, liberty, and the pursuit of open source. The wealth of insights, planning, case studies, recommendations, and even a bit of coding on the spot are helping to establish a growing trend towards the establishment of GLOSS: Government Libre Open Source Software.

From the traditionally secretive military industrial complex has blossomed a belief that the old way of doing business is fundamentally changing. It's changing fast. By necessity, to remain competitive and productive, development is becoming more open, dynamic, collaborative, and social. The open source proponents working within the DoD have been laying a foundation to facilitate change not only within the military, but throughout all branches of the U.S. government. This change is reaching a tipping point as more and more agencies adopt strategies for managing open source software, realize how much open source they already use, and observe the benefits being garnered by others that adopt and promote Free Libre Open Source Software (FLOSS).

So what makes GLOSS different from FLOSS? Why the GLOSS vs. FLOSS distinction at all? While it is very true that most of the same principles of open source apply, governments around the world are faced with unique challenges as participants in an open source arena. A primary distinction is one of intellectual property and rights management. Most governments must abide by a completely different set of rules and regulations than those that apply to individuals or businesses. Most governments are not in the business of competing with commercial industry. To the contrary, many are explicitly prohibited by federal statutes to do so. The legalities can be considerably complex to navigate.

Consider a "simple" matter of copyright. In most countries, someone who writes some software automatically has a set of intrinsic rights as the author or creator of an original work. One of the most basic intellectual property rights is the ability to authorize others to use your original work on agreed terms. Unlike the fair use and fair dealing doctrines that attempt to ensure that individuals have some basic protections of their own as users, copyright holders have considerably broader rights on their work in part due to protections ensured by the Berne Convention. The Berne Convention is an international agreement signed into law by most countries to help ensure that copyright protections are completely automatic in most countries, without the need to register or notify anyone. When a government produces a work, however, different laws come into play and can vary wildly from country to country.

For example, the United States considers works by U.S. government employees as being not entitled to domestic copyright protection. The U.S. government can claim copyright on their works in other countries, just not with their own citizens that paid for that work. To make matters more complicated, the U.S. government can be assigned copyright, but the circumstances of those rules are governed by a body of federal acquisition laws with numerous complexities. In Canada and other commonwealth realms, the government does make a claim of copyright -- a "Crown copyright" -- on works produced by government employees. The rules can be particularly complicated and vary substantially from country to country, but you get the idea.

So with all of that complexity, why does GLOSS even matter? The reason is simple. Governments around the world employ a massive number of people and affect the behavior of an even larger proportion of industry. Well over a million people work for the National Health Service (NHS) in the United Kingdom. More than 1.6 million people work for Indian Railways, the state-owned railway company of India. At nearly two million civilian employees and 2% percent of the entire national workforce, the U.S. federal government is the nation's largest employer with a majority working for the DoD (and that doesn't even include the Postal Service, intelligence agencies, or government contractors). Around the world, governments are spending time and money developing massive amounts of software, but in only exceptionally rare contributions are those released as open source.

The past couple years have been particularly exciting for the Mil-OSS community as a new trend has been emerging within the U.S. government to shift more towards open operations. On his first day of office, January 21st, 2009, U.S. president Barack Obama gave guidance to the federal workforce that a presumption in favor of disclosure should be adopted for Freedom of Information Act (FOIA) requests. That was immediately followed by another memo calling for "an unprecedented level of openness in Government." That transparency memo reads like a HOWTO for directly supporting open source with visionary claims that:

• Government should be transparent
  

• Government should be participatory
  

• Government should be collaborative
  

This guidance, while long overdue, ultimately reinforced and helped accelerate a trend towards open source that was already under way. Open source is in pervasive use throughout most governments. Like many corporations, governments rely on popular open source software products such as Linux, Apache, Bind, GCC, Firefox, MySQL, Kerberos, and dozens more as part of critical IT infrastructure. The accelerant has been notable direct contributions to open source by government agencies releasing their own source code as open source software.

Examples of open source contributions include NASA's extensive suite of open source projects, the U.S. Army converting BRL-CAD into an open source project, the NSA developing SELinux, and the White House releasing numerous Drupal modules after deploying a new website built on Drupal. Many departments and agencies within the U.S government now have one or more notable open source projects.

There still remain many challenges down the road ahead. Most governments are terrible at interactive participatory communication, collaboration, and transparency even after directed to be that way. Individuals can help, however, by engaging agencies with specific requests and attainable goals. Canadians can file a request for access to unclassified records under the Access to Information Act. If you're in the U.S., you can file a FOIA request for specific data. With source code in hand, citizens are empowered to help their governments adopt a GLOSS perspective on their works by releasing it for them. GLOSS will become a major player across the diverse FLOSS ecosystem.

May Issue of OSBR Available

The May issue of the OSBR is now available in PDF and HTML formats. The theme this month is "open source in government" and the authors include:

Gijs Hillenius, news editor of the Open Source Observatory and Repository, provides an overview of recent advancements and setbacks in the implementation of open source and open standards by public administrations in the 27 member states of the European Union.

Edgy Paiva, Director of IVIA, gives some examples of successful projects within the Brazilian Government that use open source and explains some difficulties for implementing open source.

Mike Gifford, president of OpenConcept Consulting, discusses the global momentum in federal government departments to support open source and problems with the current federal government's procurement process in Canada.

Darlene Meskell, Director of Intergovernmental Solutions at GSA, provides an overview of current open government initiatives in both the United States and other parts of the world.

Tom Schmit, an instructor at Riga Business School, and Zigmunds Zitmanis, Vice-Rector for Information Technology at Riga Technical University, discuss the reasons for the University's choice of an open source product as the application to provide the single point of entry into electronic services.

The editorial theme for the upcoming June issue is "women in open source" and the guest editor will be Rikki Kite from Linux Pro Magazine. Contact the editor if you're interested in a submission for this issue.

Upcoming Issue on Open Source in Government

Here's a preview of some of the articles in the upcoming May issue on Open Source in Government:

Gijs Hillenius, from the EU's Open Source Observatory and Repository, provides an overview of the advancements and some of the setbacks of the implementation of open source and open standards by public administrations in the 27 member states of the European Union in 2008.

Edgy Paiva, Director of IVIA, shows how the Brazilian Government is using OSS, gives some examples of successful Brazilian projects that use OSS, explains some difficulties for implementing OSS, and makes a comparison of the advantages and disadvantages of using OSS.

Darlene Meskell, Director of Intergovernmental Solutions at GSA, provides an overview of current open government initiatives in both the United States and other parts of the world.

Zigmunds Zitmanis, Vice-Rector for Information Technology at Riga Technical University, discuss the reasons for the decision of Riga Technical University in Latvia to choose an open source product as the application to provide the single point of entry into electronic services for the University.

February Issue of OSBR Available

The February issue has just been published. In this issue:

Tony Bailetti from Carleton University contributes a tool to measure the strength of a business model and shows how open source can be used to strengthen market offers' business models.

Peter Carbone, a veteran executive who specializes in ICT strategy and commercialization, highlights the relevance of new business models and ecosystems in the knowledge-era economy.

Edy Ferreira and Stoyan Tanev from Carleton University describe the ways companies make money from market offers that rely on open source hardware projects.

David A. Wheeler, a software developer and technical author, argues that there are two types of commercial software: proprietary software and F/LOSS.

Jennifer Bell introduces VisibleGovernment.ca and describes why open government data is a valuable investment in Canada's infrastructure.

Mike Kavis answers the question "How can an individual or small business give back to an open source community?".

As always, we encourage readers to share articles of interest with their colleagues, and to provide their comments either online or directly to the authors. We hope you enjoy this issue of the OSBR.

The editorial theme for the upcoming March issue of the OSBR is Geospatial and the guest editor will be Dave McIlhagga, CEO of DM Solutions.

Government Open Source Software Resource Center

The Government Open Source Software Resource Center "is a resource aimed at providing information on Free/Open Source Software for stakeholders in (and interested in) all levels of Government. The content of the site is not aimed at any specific geographical area, and aim to provide an extensive, global resource."

They have started a list of researchers who are currently studying the use of open source within government. If you are a researcher, contact info for adding yourself to the list is provided at the website. They also have a LinkedIn group for researchers in this field.

One of the listed researchers, Karsten Gerloff, will be featured in the December 2008 issue of the OSBR and will discuss his research results thus far.