When is an API a Silo? fluidinfo Knows

Fluidinfo: Openly writable shared metadata for everything

The announcement of “O’Reilly’s new API” and a contest for its creative use just caught my eye on Twitter.

I’m intrigued by the broad sweep of the tagline: Openly writable shared metadata for everything.  Everything!

I must know more.  Mustn’t you?

The use of ligatures fi and fl (U+FB01 and U+FB02) is amusing and slick, as is the home page for the fluidinfo site.  Everything is an invitation to try it and like it.  It is all very cleanly done.

Dancing Around the Unsaid

Very clean, except for one little thing.  What exactly is it?  I see that it aggregates metadata and relies on domain names for decentralized establishment of authorities.  But exactly what is it I am using, participating in, contributing to, and jointed-at-the-hip with when I sign up to play?

The About page is a clue: “Fluidinfo is an online information storage and search platform”

Hmm, it is a thing: a storage and search platform.   There’s all this puffing about openly-writable metadata, sharing, and modern writable APIs.  But at the heart there’s this platform thing.  Is it just one platform thing or is this some federative arrangement that the API supports?

How Open is Open for fluidinfo?

Fluidinfo sign-up form is very simple with terms-of-use clickthrough

The first step towards finding out what (and whose) game you’ll be playing in is to go to the sign-up form.  Here’s the first clue that something is not straight about this, a kind of non-disclosing disclosure:

    • “Sign up for API access to Fluidinfo.”
      Very well, we are registering for access to Fluidinfo through a furnished API.  It is not so much about the API as it is access to the Fluidinfo platform thingy
    • “You’ll need your username and password to access the API.”
      Well, all right. I think of Fluidinfo as what is being accessed, and an (here: “the”) API is the means of access or maybe the entry-point.  I have come to think of an API as an interface behind which there may be any variety of services that accept that interface, but it appears we don’t mean one quite that high-flown.  Here, we seem to need to think of the specific API by which the Fluidinfo platform is accessed.  They are conceptually joined-at-the-hip.

So, we are accessing a platform thingy, and it belongs to someone.  There are terms of use that we are required to agree to (by at least clicking the box on the sign-up form).

It is clear to me, on arriving at this point, that I am invited to play in someone’s silo.  At this point, I can’t tell if it is an “open-data” silo with an exciting API or is some other kind of fish with an exciting API.

Perhaps the Terms Are Important?

The terms and conditions linked from the sign-up form remove any doubt about what it is we are signing up for.  The definitions at the beginning establish the essentials:

    • Company: FluidInfo, Inc., the entity offering a data service.
    • API: is how the data service is designated, confirming that we mean access to fluidinfo and “API” is never described or used in any other manner in the terms.
    • Licensee: you or I.

Hmm, and I Am Giving Up What?

There are some promises that Licensee (you or I) must make as part of enjoying the use of the service.  These are clearly spelled out.  It is important to know what they are, along with other limitations:

  1. The limited license granted to Licensee is “to use the API for the purpose of making procedure calls to Company servers for storage, retrieval and/or manipulation of Licensee’s information (the ‘Content’).”  Note that this is not anyone else’s Content, only our own.
        (I think this is an unintended consequence of “retrieval” being lumped here, unless broader retrieval is by other than “the API.”)
  2. Licensee (that’s you and I) “will not patent anything that relates to, or builds up, extends, supplements, is based on or surrounds any aspect of any portion of the API.” Umm, well, API is the service offered by Company, so that might make some sense, although something broader may be reached for here.
  3. But not to worry.  If we do happen to breach (2), we are also granting Company all rights to the patent.  Well, at least it is not an exclusive grant, although it appears that Company can do whatever they want with it, including giving away licenses.
  4. It gets better.  The API (here it is quite murky what the scope is here) and all intellectual property rights in it are the sole and exclusive property of Company and if, by some strange circumstance Licensee may have any interest in such intellectual property, it is hereby transferred and assigned to Company. 
  5. I don’t think I need to look any deeper, but scrolling down to the item on Government Use I noticed this interesting statement: “The API is a ‘commercial item,’ ‘commercial computer software’ and ‘commercial computer software documentation.’ ”

I can’t recall any license for use of a free service, however silo-enclosed, that embroiled me in an intellectual property transfer.   This has me worry that I haven’t been reading the fine print in other click-through licenses closely enough. 

One advantage of the fluidinfo terms and conditions is that they are brief and to the point (though I still have trouble parsing “API”), so I could get the gist of them without lapsing into a coma first.  How’s that for you?

One Last Word

Looking at the Fluid Info API Documentation, especially the HTTP API, it is clear that others could offer the same interface at their own access point (e.g., by specifying a different API host with whatever ports it will allow).  This makes terms and conditions with respect to the “API” rather curious, and it also raises questions, for me, about what the reach of intellectual property claims with respect to the “API” is intended to be.

Enhanced by Zemanta
This entry was posted in Computers and Internet, ecostructure, nfoWorks, Social Networking, trust and tagged . Bookmark the permalink.

4 Responses to When is an API a Silo? fluidinfo Knows

  1. Pingback: fluidinfo: A SemWeb Like a Wiki[pedia] or Like a Google? | Orcmid's Live HideOut

  2. Hey, I’m the developer responsible for the website at Fluidinfo (among other things). I’m glad you seem like its cleanliness ;-)

    With regard to the legalese… I’m not a lawyer but here’s my personal reading of the issues you raise about Fluidinfo’s terms.

    You’re right! Fluidinfo *is* a company whose product is a data-service (as the terms say, “hereafter called the API”) :-P

    If you replace “API” with “data service”, “Fluidinfo” or “our product” then I think it starts to sound a lot less sinister than you make out and perhaps helps you “parse” the term (as you put it). We’re definitely *not* a nefarious bunch of nerds intent on trapping you into using Fluidinfo for the purpose of exploiting your intellectual property.

    However, if our legalese is causing a problem than we obviously need to address whatever the problem might be.

    Specifically for each point here’s my personal take:

    1) Yup, good point about the scope. That probably needs changing and I’ll raise this with the appropriate people.

    2) Nothing broader is being reached for here. If it were, we’d make sure it was explicit. As you say, it seems to make sense.

    3) Hmmm… ok, so what else are we supposed to say..? “Sure, go ahead, use our product and then patent the way it works..!” :-)

    4) OK, to return to the parsing problem; remember API = Fluidinfo’s data service = our product…? So, *our product* is obviously the property of Fluidinfo. I’m trying to work out how there might be a problem with a company owning its own product..? Perhaps I’m being naive and missing something..? (I am definitely not a lawyer so there is a distinct possibility that I *am* missing something.)

    5) You’d be surprised how obvious you need to make some things to some people.

    “I haven’t been reading the fine print in other click-through licenses closely enough” – couldn’t agree more and I’m glad you read ours. It’s always good to get feedback.

    Interestingly, you didn’t mention what I’d consider the most important clause:

    “Unless in violation of 2(c) above, any data stored in the Company’s servers by the Licensee’s use of the API shall at all times remain the sole and exclusive property of the Licensee.”

    Anyway, I hope this addresses some of your concerns. If not, we’d love to hear what exactly *is* the issue. Like I said, we’re not a bunch of nefarious nerds – we’d rather reading our terms of service made sense and didn’t scare people off.

    • orcmid says:

      Let’s look at two parts of this.

      1. It is really messy to have taken “API” (a term of art that is not that unambiguous already) and have it mean “the service.” I think of an API as an interface for which the requester does not see into the implemented service but into a model that is part of the interface specification. Likewise, the service has no idea what the requests to the service are on behalf of in regard to the implementation of the requests and the choice of material submitted via the interface. For me, the interface (how I think of APIs) is a protocol and formats that allow the service requester and the service provider to be at arms-length in a very useful way.

      Go to the Terms and Conditions and replace every occurrence of “[the] API” with “[the Service]” and see how it goes. Then try that in other documentation where “[the] API” appears. Notice how Clause 1(a) becomes very strange when you do that. To me, this conflation makes it very unclear what is being licensed and what IP is claimed over.

      I know that APIs are often thought of in conjunction with a specific service implementation (e.g., the Twitter API) but I think that is just a casual and natural way of speaking. But the Terms and Conditions do not make such casual use, even though having “API” as a special term of reference invites such confusion.

      2. Concerning IP, I think the same situation arises. It makes not sense that I be prohibited from using Fluidinfo (the service) underneath my implementation of a process for which there are essential patent claims, whether patents of mine or patents which I have appropriate licenses for. To say I can’t, or that I must (sub-)license them to you makes no sense. Think of it in terms of a business process implemented atop of Microsoft SQL Server that implements a form of one-click ordering by an amazon.com licensee. That has nothing to do with SQL Server nor the supported API for making requests via SQL. It also makes no sense to consider that SQL Server is now an infringing device.

      If I come up with a novel way to track shipments involving multiple carriers and I patent that, my implementation and offering of the tracking service as an application of Fluidinfo should be of no concern whatsoever. The Terms and Conditions read to me as if it is not only a great concern but that Fluidinfo Ltd is making it their business.

      I didn’t mention clause 3(b) because it doesn’t involve the user of the Fluidinfo service giving anything up.

      • orcmid says:

        The replacement activity I mention in the preceding comment is actually of “[the] API” with “[the] Service” in case there’s any doubt.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s