There Is No Creative Commons License

Today's columnist is Jordan Hatcher from the Open Knowledge Foundation. He writes:

People often talk about using “the Creative Commons license” or suggest that a business or government body “uses Creative Commons” for their licensing. The problem: there isn't one Creative Commons license. Creative Commons (CC) isn't a single license but rather is a collection of them.

There are a set of six main CC licenses, plus other legal tools such as CC0 and the Public Domain Mark. CC also has its own version of the BSD license, and several deprecated licenses, such as the Developing Nations license. Creative Commons therefore doesn't make "a license." Some of these licenses are open, some aren't. In my opinion, they are generally inappropriate for software and are also inappropriate for databases, for most users. For the most part, CC offers content licenses.

Here, I want to focus on the six main CC licenses because they're the most popular. The six main CC licenses consist of combinations of four license elements:

1. BY – Attribution (giving credit)

2. NC – Non-commercial (banning commercial use)

3. SA – Share Alike (copyleft/reciprocal licensing)

4. ND – No-derivatives (restricting remix of the work)
   

CC doesn't offer these main licenses without attribution, so the set of six looks like:

1. Attribution (BY) (OPEN)
   

2. Attribution | No Derivatives (BY-ND)
   

3. Attribution | Non-Commercial | No Derivatives (BY-NC-ND)
   

4. Attribution | Non-Commercial (BY-NC)
   

5. Attribution | Non-Commercial | Share Alike (BY-NC-SA)
   

6. Attribution | Share Alike (BY-SA) (OPEN)
   

Two of the above license elements don't meet the Open Knowledge Foundation's open definition because they restrict the field of use – the non-commercial (NC) element – and the ability to reuse and create derivative works – the no derivatives (ND) element. As a result, only two of the six main CC licenses can be classified as open licenses: CC-BY and CC-BY-SA.

So let's say you've decided which of the six licenses best fits your needs as a creator. The license variation doesn't end with that initial choice. Even within the six main licenses, there are many variations of each, though each still accomplishes the core goal of that license type. Public licenses, such as those published by Creative Commons, get upgraded as the law changes or as bugs in the license text are fixed, and each of the six licenses has been through multiple versions. All past versions remain active for people who licensed their work under those versions, though of course new licensors should choose the most current version. So the six licenses change through time, with past versions still potentially active. Licensors should always consider how they will upgrade their CC content when new license versions come out as part of their adoption plan.

In addition to versioning, these six licenses also get "ported" to the national law of many different jurisdictions. Intellectual property law is generally national in nature, but the Internet is global. Canada, France, Germany, Scotland, England & Wales, USA, Mexico, and so on all have their own adapted version of these six licenses. Currently CC has projects around their licenses in more than 70 separate jurisdictions. Also, CC offers an “unported” license for uses that aren't specific to any one jurisdiction. So, when discussing CC licenses, be aware that CC has multiple jurisdictional variations across both the six main license types and version types – a CC-BY Scotland and a CC-BY Canada for example.

Broadly, each license type does what it says: a CC-BY license should only require attribution, regardless of whether it's a Scottish 2.5 version of the CC-BY license or the latest unported 3.0 version. However, the process of adapting a CC license for a particular nation goes beyond language localization; the licenses get mapped onto national IP laws, and so there can exist important legal differences. For instance, the European Union CC licenses may be silent on areas such as the EU's sui generis Database Right or may explicitly waive the Database Right (depending on the jurisdiction and version), or there may even be a choice of law and jurisdiction clause, such as the Scottish CC licenses.

So when licensing and discussing CC licenses, make sure you're specific as to what you want and what you mean: It can have an important impact on the end result.

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.

Communications Enabled Applications

The May issue of the OSBR is now available in PDF and HTML formats. The editorial theme this month is "Communications Enabled Applications" and the authors include:

Craik Pyke, Senior Technical Architect at Nortel, examines the shift in traditional telecommunications business models.

Daniel Cardenas, Software Architect at Rezact Inc, demonstrates how a small company improved customer service and increased operational efficiency by implementing communication enabled applications.

Andrew Ceponkus, a project manager within IBM’s Tivoli Provisioning Manager Quality Assurance team, provides an overview of lessons learned from an investigation of collaborative telehealth systems delivery in Canada.

Patrick O'Halloran, a Staff Design Engineer with Xilinx Inc., presents the key licensing considerations when using CEA building blocks.

Jean-Pierre Poulin, an entrepreneur, discusses the lessons learned by his startup's approach to communications enablement.

Elias Majic describes his startup's experiences in integrating communications services.

The editorial theme for the upcoming June issue of the OSBR is Growing Business and the guest editor will be Mekki MacAulay. Submissions are due by May 20--contact the Editor if you are interested in a submission.

Upcoming April Issue

The theme for the upcoming April issue is "Open APIs". Here's a sneak peek at the authors and their articles:

Michael Weiss from Carleton University describes a research framework to examine the structure of the mashup ecosystem and its growth over time using network analysis to obtain key characteristics of the ecosystem and identify significant ecosystem members and their relationships.

G.R. Gangadharan, a research scientist at the Novay in the Netherlands, provides an overview of open API licensing, provide examples from current open APIs, and briefly discusses open licensing of open APIs.

Owen Byrne, Senior Manager of Travelpod Labs, compares the features of the most commonly used JavaScript Toolkits used to create rich Internet applications and how freely available toolkits are able to compete against proprietary alternatives.

Roberto Milev and Steven Muegge of Carleton University describe a method for examining the evolving modularity of large-scale software systems and introduce a new modularity metric for comparing code bases of different size.

Byron Thom, a student at at the University of Ottawa's Faculty of Law, summarizes a recent Torys Technology Law Speaker Series where Professor Madison, Associate Dean for Research and Professor of Law at the University of Pittsburgh School of Law, introduced a novel interpretation of copyright in the age of OSS using a spatial framework to deal with open source licenses.

Paul Ramsey's article in French

Directions Magazine has translated and republished Paul Ramsey's in French.

This is a good time to remind both readers and authors that authors retain copyright to their articles and that they are published under the Creative Commons attribution license. This means articles can be republished and remixed (e.g. translated, turned into a whitepaper, etc.), as long as the original author and the OSBR as the original publication source are attributed. We want to see authors' ideas reach the largest audience possible.

Jacobsen v. Katzer

Bruce Perens, author of the open source definition, recently discussed the outcome of a court case between a model train hobbyist who had developed the GPL licensed Java Model Railroad Interface and a company who patented several features provided by the interface.

According to the article: "An appeals court has erased most of the doubt around Open Source licensing...For a decade there'd been questions: Are Open Source licenses enforceable at all? Are their terms, calling for a patent detente or disclosure of source code, legal? Are they contracts, which require agreement by all parties to be valid, or licenses, which are binding even if you don't agree to then? What legal penalties can a Free Software developer employ: only token damages, or much more?" Bruce provides a very readable summary of a complex court case.

This court case was briefly discussed by Kamal Hassin in the Licensing issue of the OSBR back in October 2007. You can also learn more about the creation of the open source definition in Russ Nelson's article.

Open Educational Resources

Yesterday's post was about the reasons why corporations embrace open source. Today's is about the reasons why educational institutions choose to give away their "product" (courses, knowledge, and research) for free.

Jan Hylen provides some answers in the appropriately named article
Why Give Knowledge Away for Free? The Case for Open Educational Resources. His article highlights the findings from a study carried out by the OECD Centre for Educational Research and Innovation and discusses the reasons for producing open content as well as the associated problems of licensing and sustainability. For further research into these problems, see the conference report on Open Education 2007 and Jordan Hatcher's article on the Open Data Commons Project.