Reciprocity and Data Licensing

The phrase “reciprocal licensing” got into my head a few months ago. If you go poke around you find that the term is mostly used to describe ways that one organization agrees to honor the licenses granted to professionals by some other organization. Licenses are, of course, set of rights and responsibilities. For example is the state of Massachusetts grants me the right to drive a car on it’s highways most of the rest of the planet will also grant me that right. Lots of professions have associated systems of reciprocal licensing: plumbers, teachers, and lawyers. When you grant respect to a person’s title, for example Vice President of Engineering, outside the context where that title was granted you would seem to be engaged in a form of reciprocity.

Reciprocity isn’t just for roles. The GNU software licenses are a form of reciprocal licensing. In exchange for the right to modify the software you relinquish your option of hoarding those modifications. The peer to peer file sharing, systems are another example, in exchange for drawing down a file from the system you are expected to reciprocate by providing bandwidth for further file sharing. The peer to peer messaging and VOIP systems are two more example. Once you start noticing you’ll see lots of these.

Reciprocity is one way of framing the coordination aspects of collaboration. It’s a way of talking more explicitly about the responsibilities that come with club membership around a club goods. The peer to peer system, the GNU code community, the professional society around plumbers or doctors, even the universe of international drivers all have rules that govern how the goods are maintained in collaboration. You can find other examples around patent pools. Some platform vendors have begun to use these ideas to assure that members of their developer networks add to the platform. For example Microsoft’s consumer electronics platform has rules that clarify the timing of various developer IP rights so innovations can flow back into the common pool around their platform – or so I’ve been told.

Peering agreements are another interesting application of reciprocal licensing used is for. IP packet routing, or phone call routing, or check clearing are all examples. The problem is you want to join a distributed network but your concerned that other members of the network will freeload or cheat in various ways that disadvantage you. You need trust at a distance. By setting up a standard contract that every participant is required to sign you can temper some of the risks.

Data pooling agreements have the same challenges. Consider an example. Imagine you are an insurance company. You have worked hard at great expense to collect data about insurance claims. This data is valuable because in aggregate it drives how you set rates. If you had more data you could set rates even more accurately. That could be very profitable. The insurance industry shares data like this by establishing master database. And, I assume, they use a contract much like a patent pool or a peering agreement to reduce the risk that some companies freeload or engage in any number of other ways of gaining an advantage.

Of course all industries have a power-law distribution of players. One way you can disadvantage the small players is to create barriers to entry that only large players can overcome. One place you can establish these barriers is with the rules around the reciprocity agreements. But, on the other hand, you can use the reciprocity agreement to frustrate that. The GNU license is a fine example of that. There is another example found in the open source VOIP community. They need to exchange call routing data. They have a peering agreement for that which tries to keep large players from locking out tiny guys – like me with my basement phone switch.

For the last year or so I’ve been puzzling about the problem of how to equitably distribute blog pings from blogs to interested parties. The tough nut in the design is that there are some very large gorillas in the blog world and they are all, presumably, tempted to horde their ping data to gain various competitive advantages. And, as usual in these two sided markets where there are lots of providers and lots of consumers there is a two sided network effect that could lead to a single winner who acts as the hub for the exchange. A middleman taking a small cut as he coordinates the interactions. The usual way to temper that risk is to introduce some standards that fragment the market while solving the coordination problem enough. With luck you can even get the standard to do a better job than a single hub would.

All that has brought me around to the question of what the reciprocity rules would be in such a market. What the world needs is creative commons like license for pings. I want to know that when I ping weblogs.com, or ping-o-matic, or technorati, or pubsub.com that they aren’t going to horde the resulting data. I want to know that they have signed onto a peering agreement that assures that my ping joins rest of the ping flux as public data. Some rights and responsibilities are granted when you ping these guys. Their responsibilities need to be made more explicit.

I don’t mind if they want to horde information that they accumulated by spidering, polling, and scraping; though I suspect we will see similar creative commons like licenses appearing on sites. Licenses that make explicit the reciprocal nature of the relationships.

0 thoughts on “Reciprocity and Data Licensing

  1. John Furier

    Nothing wrong with wanting to horde.. but forward on first. hey store and forward works here…everyone should be on a level playing field with the ping data… and let innovation and good programming define the competitive edge… at the end of the day users benefit from this approach…

    i want my own ping server…who doesn’t..very valuable

  2. Bob Wyman

    If FeedMesh works, then we’ll have a community of folk who avoid hording. That will be a good thing. However, there is the interesting question about what to do with spam pings — or, what one of the FeedMesh members “thinks” is a spam ping. Clearly, hording of pings is undesirable if hording is defined as receiving and using a ping without forwarding it to others. This kind of hording allows one service to gain an information advantage over another service. However, should a ping receiver be expected to pass on to others those pings that it receives but declines to use since the receiver is convinced they are junk, false, or spam?

    bob wyman

Leave a Reply

Your email address will not be published. Required fields are marked *