Yesterday we discussed the Game of Thrones level drama that has erupted between the various REBNY and RLS vendors. We obtained and read through some of the claims laid out in the Stratus Data Systems demand letter to REBNY. Here are some key arguments.
REBNY and Stratus Always Agreed On Data Ownership
Usually these API and data disputes are at the heart of who owns the data. REBNY seems to have that covered in their original contract with Stratus. No one seems to dispute that the data belongs to the brokerages, and Stratus the vendor never owned the data.
Data Schema, Software Methodology, and API Design In Dispute
However, Stratus claims the way they crafted the data schema is proprietary. Moreover, vendors using the system were prohibited from reverse-engineering or copying the software and related methods for distributing the RLS Data of New York apartment listings, and how they syndicate to NYC real estate marketplace portal websites.
Perchwell Replacement Is a URL Change To Identical System
As evidence that Perchwell is in violation of the agreement, Stratus points out REBNY alledgedly told other vendors that transitioning to Perchwell would be seamless. No methods of querying, inserting, or reading data from the RLS will require changes. The only changes would be a URL change to point to a new server, and a new set of credentials.
Of course, Perchwell and REBNY had planned further modifications, but Stratus claims the initial transition is a reverse-engineering of their proprietary systems and a violation of their agreement.
Both Systems Use Industry-Standard RETS specification and API
To make things more complicated, the Stratus system is compliant with a widely used industry standard called RETS. It is neither an API or a schema, but a data transport standard. It mandates many of the API calls that a RETS server should implement, a general way of laying out the data schema, AND a query language for inserting and selecting data.
There are many RETS implementations already out in the world, many open source. However, details of how to make a local marketplace fit into a RETS implementation is left unspecified.
That’s a good idea, because it allows the local brokers and websites to accommodate local peculiarities. For example, in some cities the property types will be “House” vs “Mobile Home” vs “Farm”. In NYC, you instead see “Condo”, “Co-op”, and “Townhouse“.
No Stolen Code, No Stolen Data, Industry-Standard API, Proprietary Implementation Of Schema
So where does that leave us? No one has stolen any code or any data! However, did they steal by reverse engineering the proprietary technology architecture? Is it proprietary when we are talking about a widely used industry standard, but with customizations tailored to the New York market?
For the geeks out there, it’s not quite like REST, which is purely a transport standard on top of HTTP. RETS clearly mandates some real estate specific endpoints, methods of querying, and an architecture built around iterating through a multiple listings service.
But it’s also not the same as a ready-to-use SQL schema where all tables, columns, and indexes are in place, and all that is left to do is drop in the data. RETS requires the implementation to think carefully about what data fields are necessary and how they might be linked. For example, is every listing part of a unit? Is every unit a part of a building? Can a unit be part of two buildings?
I am not a lawyer. I am not an expert in IP law. However, I am a data nerd, software engineer, and real estate enthusiast. We will continue the 3rd part of our analysis next time!
