Clickthrough v. browsewrap agreements

I had hoped to publish this blog post over two weeks ago, but you know how that goes – work travel, projects for clients, jury duty, and a head cold took priority. However late, I still want to clarify an answer I gave as part of the COVE conference legal panel on February 21. A conference attendee asked about the enforceability of clickthrough agreements. I am concerned that I may have provided a confusing explanation of browsewrap and clickthrough agreements and that I may have given the wrong impression that clickthrough agreements might not be enforceable. To be clear, clickthrough agreements are enforceable when properly implemented (which is not difficult). 

What follows is a little more information about browsewrap and clickthrough agreements. I’ll discuss one component of the legal formation of a contract (mutual assent), compare browsewrap and clickthrough agreements, explain why clickthrough agreements are generally enforceable, and then describe the problems with browsewrap agreements and ways in which browsewrap agreements may be enforceable.

Lame attorney disclaimer – for advice specific to your circumstances on how to implement an enforceable agreement on your website, please contact an attorney. 

Showing assent

A basic understanding of part of contract formation is required to understand the legal differences between browsewrap and clickthrough agreements. To form a contract each party must show that it intended to be bound by the agreement—each party must show there was an offer to contract and an acceptance of that offer, which shows mutual assent. Mutual assent may be achieved through different methods. Parties may physically sign an agreement, use an electronic signature service, make an affirmative act that shows assent, etc. (The method of assent is separate from the type of agreement, such as terms of use, privacy policy, user agreement, end user license agreement, terms of service, etc.)

Clickthrough v. browsewrap 

Clickthrough and browsewrap agreements differ in how the offeree (the one accepting an offer) shows assent. A visitor agrees to a clickthrough agreement by taking an affirmative act, such as clicking “yes” on a check box. A visitor (theoretically) agrees to a browsewrap agreement by being on notice of an agreement (e.g., through terms of use) and accepting the agreement through continued use of the website.

(Sidenote: Why “browsewrap? It’s derived from the use of “shrinkwrap” to describe agreements that were literally wrapped around packaged software. A purchaser manifested assent to the agreement by opening the shrinkwrapped box.)

Clickthrough assent

Showing assent with a clickthrough agreement is pretty straightforward. The website owner will only allow a user to perform a given function if he clicks that he understands and agrees to the agreement. For example, think about the last time you installed software. A dialog box likely popped up and required you to click that you accept the terms of use. By structuring website use so that a user must agree to the clickthrough agreement before performing a certain function (typically a search or purchase), the website owner knows that the user has shown assent to the agreement.

More on browsewraps

The problem with browsewrap agreements is that it’s tough to adequately show that a website user is on notice and agrees to an agreement. One legal scholar calls browsewrap agreements “not a contract.” He states:

Although there are some aberrational cases to the contrary, for the most part courts do not treat browsewraps as a contract, and anyone relying on a so-called browsewrap does so at their extreme peril. 

(See his blog post for a more in depth look at this topic and the Zappos case.)

What I tried to describe (too quickly and unclearly) at the COVE conference, is that it is pretty easy to show that a website user assents to a clickthrough agreement: as described above, the user must accept an offer to use the website. In contrast, proving that a website visitor has assented to a browsewrap agreement is more difficult.

However, showing assent through a browsewrap agreement can be done. Enforceability of browsewrap agreements depends on a website user’s actual or constructive knowledge of the agreement. Here are some factors courts have considered for determining whether actual or constructive knowledge of a browsewrap agreement exists.

• Was the agreement prominently referenced many times throughout the website? 
• Was the agreement present during an order/purchase/signup process?
• Would a reasonable prudent user be on notice of the agreement?
• Did the link to the agreement stand out from the rest of the webpage? Does a website user have to scroll to find it? 

Depending on the answer to those questions, a browsewrap agreement might be enforceable. Any company relying on a browsewrap agreement to implement a terms of use for its website should consult an attorney. (Want to read a couple cases that deal with this issue? Check out Specht v. Netscape Communications Corp. (court found no contract existed), Van Tassell v. United Marketing Group, LLC (court found contract existed).)

What’s the bottom line? 

Clickthrough agreements are by far the preferred method for implementing binding agreements through website use, and it might be possible to create binding browsewrap agreements. I was concerned that I may have given the impression that clickthrough agreements are not be enforceable at the COVE conference. That is not the case. Again, clickthrough agreements are enforceable when properly implemented.

-Mitch

NAR lockbox policies in focus

During the Council of MLS members-only webinar on Thursday, November 1, I briefly discussed one issue that will be before NAR’s Multiple Listing Issues and Policies Committee (MLIPC) in Orlando next week. I’ll recap that issue here. But during the conversation, a related issue came up, and I’m afraid that I may have caused more confusion than clarity on that, so I’ll attempt to clear it up here.

Current policy issue: Can brokers be forced to pay for lockboxes?

First, the issue before the MLIPC next week: Back in April, a Michigan MLS asked NAR to reclassify lockbox services under NAR’s statement of multiple listing policy 7.57. That policy divides all services provided by MLSs into three categories:

• Core: These are the services you must provide just to be counted an MLS under NAR policies, namely, providing access to active listings and being a facility for broker to make and accept offers of compensation. (Note that some MLSs not affiliated with NAR do not require offers of compensation—but if you are not an NAR-affiliated MLS, why are you bothering to read this post?)
• Basic: These are services that are central, but not essential, for provision of MLS. MLSs that offer them can make their cost part of the basic fees for MLS; in other words, MLSs can make all participating brokers pay for these services whether they want to or not. Examples include off-market listing information, tax records, mapping services, and statistical information, among others.
• Optional: These are services that MLSs cannot require brokers to use or pay for. The only listed optional services are “lock box equipment,” including keycards and lockboxes, and advertising (like an MLS magazine or listing syndication).

The MLS making the request wants to do what many others have wanted to do over the years: make the lockbox service/system a non-optional service. The requesting MLS, and a couple others who chimed in over the summer, cite the following reasons for wanting to make lockboxes part of the basic MLS package:

• It standardizes access to properties listed in MLS, facilitating showings and sales.
• Use of the electronic lockbox systems results in a higher level of security for homesellers.
• It permits easier tracking of unauthorized granting of access; for example, some brokers have given combo box combinations directly to their clients and let them go and show themselves the properties of sellers.
• It helps to address problems where listing brokers are not making properties accessible.

The MLS Technology and Emerging Issues Subcommittee (TEIS) of the MLIPC (this is the same group that came up with the social media policy proposal I discussed a week or two ago [link]) considered this issue and has recommended that the policy NOT be changed. Their rationales:

• Not many MLSs have asked for this.
• Most brokers use lockboxes if their MLSs make them available optionally, so why is it necessary to require them?
• The proposal makes “no provision to limited possible abuse of the requested authority.” (Candidly, I have no idea what the subcommittee meant by this… if an MLS wants to abuse its authority, there are myriad ways to do so. The current policy is hardly a meaningful restraint.)
• The proposal does not account for the fact that lockboxes are sometimes provided as a service of the REALTOR® Association rather than the MLS.
• There are potential antitrust concerns of trying to tie the purchase of lockbox services to the purchase of other MLS services.

I’m not interested in evaluating the claims or rationales of either side here, as I have not thought them through yet. The key for MLSs to understand: If you want this change from “optional” to “basic” for the classification of lockbox services, you had better either immediately send a letter to NAR emphasizing that or show up at the MLIPC meeting (9:00 a.m. Eastern, Saturday, November 10 in Orlando) to let NAR know that this matters to your organization and you want further consideration of it.

Policy issue from May: Can brokers be required to use lockboxes?

OK, so far so good. Here’s where I got on thin ice on Thursday. Back at Midyear meetings in May in Washington, the MLIPC considered a different proposal to modify the lockbox policy. There was a proposal from the California Association of REALTORS® to allow MLSs to require the use of MLS-approved lockboxes in certain circumstances. NAR eventually adopted the following policy language in statement of policy:

MLSs may, as a matter of local option, require placement of an MLS approved lock box on listed properties if any device giving access to real estate professionals and/or service providers is authorized by the seller and occupant and is placed on the property. The purpose of this requirement, if adopted by an MLS, is to ensure cooperating participants and subscribers have timely access to listed properties. Requiring that a lock box or other access device be “MLS-approved” does not limit the devices that satisfy the requirement to lock boxes leased or sold by an association or MLS. The MLS may require that the devices be submitted in advance for approval, and the access device may be any lock box or other access device that provides reasonable, timely access to listed property. The MLS also may revoke the approval and/or subject the participant to discipline if the device is used in a manner that fails to continue to satisfy this requirement.

The gist of this:

• MLS cannot force broker or seller to put a lockbox on the property at all. Broker and seller can say, “no lockboxes, period.”
• MLS cannot force broker or seller to use a lockbox from the MLS’s or association’s system.
• MLS can (but need not) have a rule that says, if there’s a lockbox or any other kind of access device (like a digital doorknob) on the listing, the listing broker must do one of two things. Either (1) use the MLS or association lockbox system, or (2) use a device or system, in combination with listing broker operational procedures, that meets the reasonable and timely access standard adopted by the MLS.

I spoke about this issue at length with Elizabeth Miller-Bougdanos, who is senior legal counsel at the California Association of REALTORS® and has given this issue more thought than probably any other lawyer on the planet. CAR has adopted a model rule, which NAR has approved, that defines the “reasonable and timely access standard” this way:

(1) it allows all participants and subscribers timely access to listed property by reliance solely on data submitted to and residing on the MLS; (2) complete, accurate and stand-alone instructions are provided for accessing the listed property in the appropriate agent section on the Service; and (3) it ensures that the lockbox or device will provide reasonable access to listed property with any information, code or key needed to access the contents of the lockbox or device to be made available or access to the property otherwise scheduled within four [4] hours of initial contact in the event the lockbox or device requires the participating member to obtain additional information to enable access (ex: “call listing agent for entry code”) with said 4 hour response obligation in effect every day from 8am to 6pm.

(If you want more of the materials that CAR has prepared, contact Elizabeth if you have her address, or contact me and I’ll provide it.) At first blush, this seems quite reasonable to me, though I have not given it the detailed analysis it deserves. I also have lots of questions about hypothetical situations that I discussed briefly with Elizabeth, but this post is already too long to discuss those.

Conclusion/summary

In sum, then, here are three rules that every NAR-affiliated MLS is bound to under the current policy (and this is not likely to change next week, given the TEIS’s recommendation):

• MLS cannot make brokers pay for lockbox systems as part of MLS’s basic fee structure. (There is some nuance to this part of the policy. Call me if you want to discuss.)
• MLS cannot require a lockbox of any kind to be used on a listing just because the listing is in MLS.
• If the listing broker and seller decide to use a lockbox, MLS cannot require it to be one from the MLS’s (or REALTOR® association’s) system. But MLS can adopt a “reasonable and timely access standard” with regard to means of access other than those provided by the MLS or association.

Comments?
-Brian

Keep it simple, stupid

No, I’m not talking to you. I’m thinking out loud. Please do not be offended.

It is easy for me lose sight of the “big picture” when dealing with data distribution legal issues on a day-in and day-out basis. Wading through the weeds on a contract-by-contract basis is important. However, the big picture of MLS data acceptance and distribution, and the basic contracts that govern those relationships, may be more essential.

Contracts are like insurance policies. Hopefully you will never need to use them. Hopefully they get negotiated, signed, and collect dust in a drawer. But like insurance policies, they provide a nice safety net.

A written contract formalizes a relationship so there are no surprises when questions about the relationship arise. At its absolute simplest*, there are four core relationships regarding data and the MLS. These relationships need the safety net of a contract.

• MLS relationship with Participant 
• MLS relationship with Subscriber
• MLS providing data to Third Parties
• MLS providing data to Participants/Subscribers

It occurred to me that we have not explicitly spelled out these core safety nets on this blog before. We work on them frequently, so it was easy to gloss over the overall structure and focus on the issues with which they address (MLS copyright infringement, copyright protection, and license scope).

There are several methods for dealing with the above relationships. Every organization may have its own method for formalizing relationships regarding receipt/distribution of data; but it should have something. The simplest way to address the relationships, in my humble opinion, is with four agreements that govern the four core relationships.

That’s it. A 330 word post. See ya’ll in Orlando.

-Mitch

*It should be readily apparent that this is an extreme over simplification. There may be other parties that provide data and it’s likely there are other destinations for data distribution. The goal of the documents that govern these relationships is to cast the largest safety net as simply as possible.

License scope (and Trulia Direct Reference)

The following is not intended to be legal advice and describes legal concepts in generalized terms. If you have specific questions regarding your organization or a specific agreement, please contact an attorney.

MLSs are the hubs and warehouses of valuable data. They receive data for which they want to limit their liability and which they want to try to protect from pirates; and they distribute data that is valuable to the MLS, its members, and companies that seek to use it for profit-making businesses. MLSs that want to make sure they are striking fair bargains for the data they license will want to pay close attention to the scope of license clauses in contracts.

In this post, I will discuss why the scope of a license matters, explain why the use of precise language in a license is important, and examine an industry example of incongruence of license scope and the expectations some MLSs might have.

Why does scope matter?  

The license scope creates the boundaries for what the licensee can do with the licensed materials. Describing the scope of a license precisely is important because it allows the licensee to use the licensed material as the parties intend and sets the boundaries for prohibited uses of the licensed material. Creating a license scope that is consistent with the parties’ verbal agreement ensures that both parties are getting and giving what they expect. If an MLS is contemplating sending its data to a third party, presumably the MLS has concluded that the payments or services the third party offers in return are worth some value back to the MLS. If the scope of the license does not accurately reflect the bargain, the value might not be adequate for the MLS. MLS should therefore make sure the scope of the license is broad enough so the third party can do only what it needs to with the data, but no more.

License language matters.

MLSs and brokerages should closely examine license language in agreements. Terms that may appear to a non-lawyer as layperson descriptions could have legal significance. Simple examples include “distribution,” “reproduction,” and “derivative works.” These terms describe the exclusive rights of a copyright holder. They are the sticks in the bundle of rights granted under federal copyright law (17 U.S.C. 106). By including these terms in the scope of a license, an MLS is granting a licensee specific legal rights. In a lay sense the terms may seem innocuous, but an MLS may be granting rights it never intended to license. A major part of contract negotiation is making sure the contract properly embodies the agreement between the parties. Without a careful analysis of the whole written agreement (especially the license scope), what may seem like a fair bargain at the time of handshake might not be fair once it’s embodied in writing. (A discussion of making sure an MLS is getting what it expects will be reserved for another blog post.)

What precipitated this post. 

I recently reviewed a few Trulia Direct Reference (TDR) agreements for clients. Trulia provided us this description of the TDR service:

Trulia Direct Reference is a cooperative effort between Trulia and MLSs to identify, correct and eliminate inaccurate listing data distributed by third party syndication companies. MLSs provide Trulia a data feed, which Trulia uses solely as a benchmark for accuracy against listings they receive from third party syndicators.

When Trulia identifies information in data received from third party syndicators that is different than data in the MLS version of a listing, they correct the errant data before it appears on Trulia.com, and then send an email to the listing broker and agent indicating the source of the errant data and the information that is different. Trulia also sends a weekly summary report as well as a daily detail report to the participating MLS. This program is free to MLS organizations and their members.

Several of our clients have identified this as a valuable service and are entering or have entered agreements with Trulia for it. I noted, however, that the TDR agreement appears to have changed within the last year. The new document is much shorter, has less legalese (not the scary looking two columns of narrow font), and frankly appears friendlier. But I also noticed changes that appeared to expand the scope of the license to Trulia. Trulia may not have intended to expand the scope of its agreement, but the scope of the new license did not match the expectations of some of our clients’ about the TDR service. It appeared to me to authorize a much broader set of uses.

Even if my reading was correct, if MLSs know Trulia can do more with their data than operate the TDR service, and if the MLSs believe that it is part of the bargain they agreed to – great! If they want Trulia to be able to do different things with the data, it might end up in some really cool products (I think the commute map is a great idea – kudos, T). But if the MLS did not intend to allow uses beyond accuracy checking of listings, the written agreement does not capture the bargain the MLS thought it struck.

I assumed there was no nefarious intent. Trulia was probably trying to simplify its contracting process. It’s entirely likely that Trulia developed a base + exhibit agreement system that would work for various products as its services evolve. Sometimes companies will have a generic “master” base agreement and then attach exhibits to better define the subject matter of the agreement. I’ve seen this contract management method before with other MLS and non-MLS clients. Trulia might have introduced this to avoid complexity and attorneys’ fees and just hadn’t properly dialed in the agreement yet.

That turned out to be correct. Brian and I arranged a telephone call with Trulia representatives and in-house legal counsel. First, they confirmed that Trulia will use the TDR data only to correct listings received from third parties (brokers, agents, syndication channels) for posting on Trulia products. Second, they disagreed with our interpretation of their license’s scope; in other words, they believe that the language we reviewed permitted only the uses we described above. Well, we agreed to disagree on the interpretation of their contract language, but they also agreed to revise it to clear up the disagreement. Trulia’s counsel revised the scope of the license to be consistent with our and their understanding of what they actually do with the data received for the TDR service. That seems like a win-win for Trulia and the industry.

The bottom line?  

Closely review data license language granting rights to other parties, even if they are trustworthy partners. If necessary, engage an attorney so you don’t accidentally read over any terms of art. And more broadly, make sure your verbal bargain is properly embodied in your written agreement – it can save a lot of headaches (and legal fees) down the road.

-Mitch

BTW: We don’t do any legal work for Trulia. In fact, Brian was a little disappointed that he couldn’t figure out who to bill for the talk we had with them.

Social-media-lite policy proposed for NAR in Orlando

The MLS Technology and Emerging Issues Subcommittee (TEIS) of NAR’s Multiple Listing Issues and Policies Committee is at it again. This group (and its previous iterations) has labored to sort out the issue of Broker A displaying Broker B’s listing in social media for years it seems (yup, I just checked my old files; I think it’s appropriate to pronounce the subcommittee’s acronym as “tease”). The efforts came to something of a head in May, when the NAR board adopted a policy change that effectively permitted IDX through mobile applications. I think that was great news: though I expect we’ll see problems of one kind or another with it over the coming months and years, I expect we can work them out.

<ShamelessAct type=”promotion” target=”self”> Drop me a line if your MLS wants help sorting out how to implement the mobile app in IDX stuff. Generally, it requires slight changes to your data license agreement (you do require anyone who gets access to your data to sign one, right?) and rules.</ShamelessAct>

But the MLIPC also directed the TEIS to try on social media again. Last week, the TEIS came out with its further recommendation. It’s based on feedback NAR received from the whole MLIPC and a conference call by the TEIS earlier this month. According to an NAR staffer’s summary, the feedback from the MLIPC over the summer reflected several tendencies of thought: First, there was not a consensus whether NAR policy should even address the display of listings outside of IDX and VOW. Some folks are hostile to the idea, and think that “display of other participants’ listings outside of VOW and IDX may result in overexposure, misappropriation of listing data, failure to attribute listing participants, and license law violations.” This is no doubt true, but it’s also true within IDX. Most MLSs make some effort to police for these problems in IDX; and it may be difficult to police social media sites in the same ways. So, for example, stale data and its consequences would likely be a more widespread problem in social media displays (or at least the ones I’ve seen described). Of course, there are other folks who strongly believe that “display of other participants’ listings outside of VOW or IDX will give greater exposure of listings to consumers, enhancing the possibility of quicker sales.”

Second, there is a consensus that there’s not a consensus on how to define what actually constitutes a “social media” site. I posted at length on this last year—no need to rehash here.

Third, there is a consensus that if there is a policy, it should be optional for the MLS and the listing participants; that is, each MLS can decide whether to adopt it, and each listing broker can decide whether her listings will be included in it.

The TEIS cleaved to these principles when it proposed the following new policy, which will be on the agenda in Orlando:

MLSs may but are not required to give participants the ability to authorize electronic display of their listings by other participants outside the context of the Internet Data Exchange (“IDX”) policy and rules and the Virtual Office Website (“VOW”) policy and rules. 

Participants may not be required to consent to display or distribution of their listings through non-IDX and non-VOW channels as a condition of participation in MLS or as a condition of participation in IDX.  Electronic display and distribution pursuant to this policy contemplates, but is not limited to, Short Message Services (“SMS”)/texting technologies, and interactive “social media”.  All electronic displays and/or distribution of other participants’ listings conducted pursuant to this policy must comply with state law and regulations and applicable rules. 

Displays addressed by this policy may be subject to technological limitations on disabling/discontinuing third-party comments/reviews, disabling/discontinuing automated displays of market value, “refreshing” displays on a periodic basis, and possibly other issues which should be taken into consideration when developing rules and policies governing such displays.

There’s nothing controversial here, unless you were hoping the TEIS would give your MLS a blueprint for how to do this. OK, so this is really just punting to the local organizations, but I don’t mind that, as the locals make good laboratories.

So, now we’re looking for an MLS or two burning to adopt this optional policy; we’d like to help sort out the complex of legal, operational, and technical issues. If the project works well, maybe NAR will adopt your approach as a model for the rest of its MLSs. We can have some fun with it in the meantime.

I'm really interested in comments from folks (a) who think that MLSs SHOULD adopt an approach like this and (b) who are willing to share specific concerns/reservations about the idea.

-Brian

Spark Platform 3: Understanding the Technology Framework

Previously, I outlined my general understanding of FBS’s Spark Platform and the legal framework it creates. Now, as promised, I’m considering the technology framework. I should warn all readers, however, that I’m a lawyer, not a technologist, so I’m counting very heavily on tech-savvy folks to correct me in the comments where I go astray. It seems to me the big questions are (a) how data gets into Spark; (b) how it gets out for appropriate uses.

As I understand it, MLSs taking part in the Spark Platform will provide RETS feeds of listings data to FBS. (An exception may be the many participating MLSs who are already FBS customers; I expect there might be more efficient back-end approaches for FBS to copy and synchronize their listing data onto the Spark Platform.) The Spark Platform will, to the extent possible, map listings data from the MLSs’ native formats onto RESO’s data dictionary, making it as standard as it can be on a national level. The RESO data dictionary is a fairly new piece of standardization. (My colleague Mitch Skinner—@MitchellSkinner—has been working with RESO on the intellectual property framework and license agreements for the newly launched data dictionary this year.) The RESO dictionary is not meant, though, to cover every data field that might be important in a given MLS. I asked FBS CEO Michael Wurzer who will you handle local “oddities”—e.g., “dune grass” in western Washington State? He responded:

These will be available through the API as custom fields.  As described here, data standardization through the platform is a process, which will improve over time as more applications are developed and need more standardized data and the dictionary broadens and improves.

But Spark seeks to go further than that; it would also extract and maintain contact information provided by agents. Thus, if FBS is your MLS vendor (FlexMLS system) and you put buyer prospects into the MLS system, I anticipate contact info for those prospects would be usable to you in apps you obtain through the Spark Platform. I also understand that FBS’s goal is that the searches you save in MLS would be available in these other apps, too. I wondered whether contact information and saved searches collected by an agent and put into one Spark-enabled app will be available to the agent in other Spark-enabled apps and even through the agent’s MLS. I asked FBS to confirm/elaborate on these matters, and here’s Michael’s response:

[T]his is the goal, but, importantly, standardization of searches is a process that's going to take time similar to the standardization of fields. Some searches may be converted to the new standard fields and search format but others may not be able to be converted. Most importantly, however, new searches created by applications using the API, such as Flexmls Mobile, will be in a standard format and available to all applications through the API. Ending the days of user data being locked in properitary formats that cannot be accessed by other applications is a main goal of the Platform.  

There is no standard comparable to RETS or the RESO data dictionary yet for these other types of data; though our friend Matt Cohen has long been urging the development of such standards for a variety of reasons.

Another kind of data comes from the MLS. The MLS indicates on the Spark Platform what data fields and statuses are confidential (i.e., cannot be displayed on the Internet), what data fields are required on IDX displays, what data fields are permitted in VOWs but not permitted in IDX, etc. This “metadata” is not data about listings and individuals, but data about how that data can be used. Incorporating these business rules into the Spark Platform is a critical step to create efficiency in development of products based on data from many different MLSs.

As for getting data out of Spark, that requires use of an API, or application programming interface. An API is basically a framework for two computer programs (or a database and a program, or two databases… you get the idea) to talk to each other. The API provides all the data and metadata I described above in one consistent fashion for all the MLSs involved in Spark to each product or service provider (PoSP)/developer in the Spark network. The data a PoSP gets will depend on what kind of application it is offering. (Less data for IDX than for VOW services, etc.) Documentation for the API is available now online; I confess that I don’t understand most of it, and I’m counting on more technical readers of this blog to comment on its sufficiency and practical utility.

Note that this technology framework also implements the legal framework I discussed in the last post. Spark is not the first to do this. RETS IQ has implemented an automated contracting framework for use with its custom RETS server projects in at least one of our client MLSs. (Mitch helped develop the contracts for that, too.)

I mentioned there may be some difference between Spark’s integration with FBS systems and its integration with non-FBS systems. Brian Boero also asked whether MLS vendors other than FBS would take part. As I understand it, FBS is working with several MLSs and their vendors to determine the best way to integrate into the MLS system the Spark Store and the applications purchased. The idea is that adoption will be improved by deeper integration into the MLS system, and so developing standards for this integration is critical as well. It seems to me that FBS is very open to working with the other system vendors on this; I don't know how much they will want to cooperate.

Well, that’s a rudimentary understanding of the technology framework. Again, I hope that folks who understand the technology better will speak up with comments and clarifications. I know Mike Wurzer from FBS sometimes reads this blog, so if you direct technical questions his way in the comments, you can probably expect a pretty prompt answer.

Next time, we’ll consider what I think are the significant obstacles to the adoption of the Spark Platform (or similar concepts). See you then!

-Brian

Pausing for a reflection and an apology (two, actually)

Yesterday, I was part of a panel at Inman Connect about the Future of MLS. As it happens, I did not get to talk about the Spark Platform (about which I’ve made posts here yesterday and the day before). For folks who may have attended yesterday expecting a conversation about that, I apologize. I’ll continue with the blog posts on the topic starting again on Monday.

A second issue arose late in the session, when I made a comment regarding NAR’s role in MLS matters, specifically in the context of RPR. The gist of my comment was to urge MLSs not to worry about the (conspiracy) theory that RPR is expected or intended to be a national MLS. I stand by that advice: If you are spending time in your board meetings worrying about that, you are wasting precious leadership time. If you have a business case for signing up with RPR, do it (and by all means, hire us to negotiate the agreement for you as we have for many MLSs); if you don’t have the business case, don’t do it.

However, in the process of making my comments about RPR, I made another regarding NAR’s role in MLS matters that unfairly minimized those places where NAR has played a positive role. An NAR staffer, someone whom I have liked and respected for years, came up afterwards and expressed distress about the comment. That prompted me to reflect on it, and now I’m inclined to apologize for it.

I have criticized NAR’s role in MLS matters before: I think NAR’s leadership and staff are often out of touch when it comes to the day-to-day and strategic issues that matter to most MLSs. However, NAR has played a positive role in a number of regards, of which I’ll mention just two examples. One I raised in my talk yesterday: Last year’s settlement between the industry and CIVIX over its patent claims, engineered by Laurie Janik at NAR (with help from Ann Bailey and Chris Osborn), was a swift and intelligent response to an issue that could have cost the industry countless hours and millions of dollars of resources. (I’ve written before about my approval of NAR’s role in that effort.) There was also much talk yesterday of the progress RESO is making; I’m sure everyone remembers that NAR effectively founded and funded the initial development of RETS and has been an important supporter of standards in our industry since the beginning. (I remember those NAR-funded meetings in the late 90s where the RETS concept was hatched.) There are other examples of NAR playing a constructive role.

I think it’s fair, and in fact necessary, to look on NAR’s involvement in MLS matters with a critical eye, and I will continue to do so. But it’s unfair for me to make flip remarks that minimize those places where NAR has played a valuable role. For doing that yesterday, I apologize.

-Brian