While Brian may have been disappointed by the document, he has approached both the legal and business issues in good faith and with equanimity, and gave us a lot to chew on. Perhaps more importantly, however, he elicited a decent amount of public reaction, and offered to create a forum for those who wished to speak anonymously. While I’ll admit to having been naive about the reasons why smart people with opinions would be nervous about expressing them in public, Brian did us all a favor by offering them a place to speak behind the screen.

In addition to everything happening online, we have now handed the agreement out to more than 150 MLSs which requested it and have begun to receive their feedback as well – both individually and from certain collectives.  A few themes emerged – ranging from technical to broader business and policy issues.  And there was enough consensus on many of them to merit a revision of our template, which we have done and which is linked from this post for you to see in comparison form to the earlier document so that you can easily make note of all of the changes.

What’s new:

• Made explicit that the RPR Website will be made available for free to all of the Participants and Subscribers of a Licensor’s MLS.
• Added further definition of the user access policies governing what content non-Subscribers to a Licensor’s MLS will see, and what Participants/Subscribers who are not NAR members will see.
• Provided options for Licensors to open up or restrict their content differently than called for under the user access policies.
• Made explicit that there is no consumer access to RPR, except through reports that can be created by an authorized user.
• Incorporated the RPR Website Terms of Use, under which all users must access the system.
• Added language on security measures RPR will take to protect the licensed content.
• Clarified the designation of confidential MLS information and stated that it will not be used on the RPR Website (unless requested by a Provider).
• Made explicit that broker consent, if required, must be obtained by Provider.
• Added specific and clear definitions of the analytics products that will be produced by RPR, specifically: the “RVM” and address file matching services.
• Added express restrictions of any analytics product that: i) could result in the sale of the Licensed Content back to a Realtor, ii) could result in the marketing of services to a Realtor, or iii) could result in the marketing of services to a consumer.
• Provided an option to restrict RVM sales to county assessors.
• Made explicit that all analytics work will be performed exclusively on RPR infrastructure, and that Licensed Content will not be exported.
• Added clarifying language regarding the destruction of all Licensed Content upon termination.
• Extended the offer not to compete with MLS providers to three years if RPR terminates the agreement.
• Made explicit that Licensed Content will not be used to compete with Providers should they terminate the agreement.
• Added provisions for first-level end-user support, and tier-2 support of Providers.
• Clarified that roster fields are only required insofar as they are already supported by a Provider’s MLS.
• Clarified that provider may determine the method of data access.
• Provided a reasonable standard for suspension or termination if the Provider believes the data is being misused by RPR.
• Expanded language on confidentiality.

No less importantly, what has not changed: there is no formula for revenue sharing with an MLS provider.  While the reasons for this have been described and discussed in dozens of forums since RPR was first announced, our thinking behind this remains that as a NAR member benefit, in which NAR members have already invested, it is critical that RPR be able to sustain the services that we will provide to the members without charging them for access, enhancements, advertising, or services.  Recently, we have begun to engage large brokers – both individually, and in several brainstorming groups – who have generally supported the rationale behind this approach.  Also, there is now a competitive offering which compensates the MLS providers without offering anything to the members, and we are pleased for the line between the two to have been drawn as brightly as it has been.

Finally, our own discussions with MLS providers large and small about the original agreement confirmed that the key issue for many, if not most, was not actually licensing revenue, but the use of the data once it has been licensed to RPR.  That has now been addressed through specific and narrow definitions of the RPR offerings in the revised template that we have included in this post.

While ordinarily it might seem a bit strange to post revisions to a contract out in the open, it made sense to us given the level and tone of the debate over the past few weeks.  We hope it is helpful both as a show of responsiveness and in terms of opening up the discussion even further, and we look forward to knowing your thoughts about these changes.

View Full Screen | Printable Version

The RPR Public Records Application Programming Interface, or API, is for MLS organizations only, and provides a way for MLS Web applications to “talk” to RPR— requesting data that can then be analyzed and formatted for presentation on your MLS system.  This is all done automatically, behind the scenes and transparent to your subscribers. Here are two excellent examples:  pulling tax records to auto-populate a listing, or pulling comparable properties for display along side a listing.  There are many possibilities!  Best of all, you don’t need any problematic data feeds.  You simply need development personnel skilled in the implementation of XML web services.

We want your feedback!

One of the challenges with producing a robust and stable API is that it is difficult to know how the entire user base will implement the functionality or the data it returns.   Since we are releasing this API as a public beta even before the RPR Web site launches, we focused on a few of the essentials that resulted from talks with several initial MLS organizations:

• Provide data for the auto-population of listing input screens.
• Provide comparable properties for use on MLS property detail pages.
• Provide enough data to generate a property details page.
• Provide links back to MLS-branded pages on RPR for full property details, neighborhood demographics, charting, maps and all the other interactive functionality on RPR.

This API should be out the door sometime in February.  We have additional functionality in the pipeline, which we will be deploying over time to support features of the RPR Web site as they are tested and released to NAR’s members.

With that said, we are interested in hearing your wants and needs for our upcoming releases.   If you represent an MLS organization, please send your suggestions to us at and we’ll consider them for our API product pipeline.