When I was on the ICANN board, we were dealing with the issue of Internationalized Domain Names (IDNs), an initiative to allow non-latin characters in domain names. Technically, it was difficult and even more difficult was the consensus process to decide exactly how to do it. Many communities like the Chinese and Arabic regions were anxious to get started and were getting very frustrated with the ICANN process around IDNs. At times, it seemed like the Arab Internet and the Chinese Internet were ready to either fork away and make their own Internet to solve the problem or were ready to introduce local technical “hacks” to deal with the issue which would have broken many applications that depended the standard behavior of the Domain Name System.

Luckily, in the end, we were able to come up with some basic understandings around IDNs after a lot of work. The Internet held together in one piece, almost impossibly so.

When I joined the Open Source Initiative board of directors, we were also struggling with a similar, but slightly different problem. We called it “License Proliferation”. License proliferation was the problem of companies and projects creating their own “vanity” Free and Open Source licenses rather than using existing, established licenses. Because these vanity licenses were tailored (at times even just very slightly from an existing licenses) to address the particular steward’s needs, they added to the complexity of the source, causing users to become confused and creating legally incompatible bodies of code.

Copy-left licenses such as the Free Software Foundation’s GNU Public License require derivative works be licensed under the same license. This feature—and to many coders this is a feature, not a bug—however, makes it challenging to combine code from projects with different licenses because of the requirement on how derivatives must be licensed. These islands of code looked a lot like a forked Internet, existing IM networks and email before the Internet connected them together.

Two great features of the Internet are the low cost of transaction and the standards and protocols that allow interoperability fueling the massive network effect that drives innovation.

At Creative Commons we have the benefit of hindsight as the “new layer” of the stack and are working hard to keep transaction costs low and interoperability high by trying to prevent license proliferation and “forking”.

For instance, Wikipedia was established before Creative Commons licenses were available. Wikipedia, until last year, was licensed under the Free Software Foundation’s GNU Free Document License (GFDL). The GFDL is copy-left license, very similar to the Creative Commons share-alike license which allows people to use the content as long as the derivatives are licensed under the same license. However, since the GFDL was primarily designed for documentation for free software, there were a number of attributes that made it sub-optimal for massive online collaborations like Wikipedia.

Also, as more and more content was being created under the Creative Commons Share-Alike license, it created two oceans of content that were not remixable or compatible because of the two different licenses. It was like having two Internets.

After years of discussion with the Free Software Foundation, the Wikipedia and Wikimedia board and community and the Creative Commons community, last year we were finally able to convert Wikipedia to a Creative Commons Share-Alike license. This brought together two communities and two bodies of content so that they could share and collaborate freely.

The moment felt a lot like the early days of email when finally you could send email to anyone instead of only those people on your network.

As the idea of sharing and free culture begins to become more and more accepted and governments, Internet services and even broadcasters begin to implement the idea of sharing, the specter of license proliferation has begun to present a real risk.

Companies and governments are beginning to create vanity licenses either for purely branding and egotistical reason or because there are certain features that they would like to “tweak”. What many of these communities don’t understand is that tweaking a free content license is a lot like tweaking character codes or the Internet protocol. While you may have some satisfaction of a minor feature or a feeling of ownership, you will introduce the friction of yet another license that we all have to understand and in many cases, fundamental incompatibility and lack of interoperability.

Creative Commons is not just a single license “option”. We are a global conversation among lawyers, judges, academics, users and companies in over a hundred countries with extremely rigorous compatible license ports in more than 50 jurisdictions. We are focused on taking into consideration the needs of all of the stake holders in this new ecosystem and updating and modifying our licenses to try to provide as many options as possible while trying to keep things as simple as possible to achieve maximum interoperability and ease of use.

Some would argue that our six core licenses provide too many choices. Some of our critics point—perhaps rightly—to the fact that our own licenses are not all compatible with one another. Others would argue that they do not provide enough choices. But we believe, 350,000,000 licensed works later, that we are successfully navigating the sweet spot between simplicity and choice.

As sharing and the adoption of new, free licenses begins to accelerate, I believe we are in danger of creating sloppy licenses or incompatible licenses backed by torrents of content funded by well-meaning governments, non-profits, users and even commercial entities. Poorly drafted licenses, licenses that are not adequately stewarded or supported by a dedicated team of legal experts, content encumbered by onerous neighboring rights and isolated and restrictive licenses can create mountains of unusable content which we might call “free” but which for all practical purposes become puddles of unusable content and what we would call “failed sharing”.

I would like to urge all of those people who have seen the benefit of sharing and free licensing to really consider the value of focusing on a single set of licenses and to resist the urge to create vanity or lets-just-add-this-one-feature-for-our-users licenses. We are trying to create a open global dialog and encourage people to join the conversation and present their cases for how our licenses might be improved and listen to the reason why each of the clauses in our license have been written the way they have.

For the future users of our content and participants in the architecture that we are creating, we really MUST try to hold this network together and try to proactively stamp out license proliferation and fragmentation. If the ICANN and OSI experiences provide any guidance and learnings—and if we are to avoid the challenges and risks those organizations and communities confronted—we all must be vigilant and uncompromising on this point.