The evil of the Office UI ribbon license

For the next major version of a certain application I'm working on (gee, what might that be ) I'm researching some UI frameworks and techniques. In the past few months I've spend most of my time working on application support library code, language designs, algorithm design etc. etc. (more on that in a later article) and I arrived at the point where I wanted to see how my vision for the major version would work in a draft application, just to see how the various elements would work together visually.

One of the first questions one would ask these days when a new desktop application is started is: WPF or Winforms? The current version is build with Winforms all the way though it's tempting to go for WPF, as it's new, has nice performance and great looks (if you're able to cook up the styles). After a day or 2 of fiddling with the various WPF docking frameworks out there, there's one firm conclusion to be drawn: WPF isn't up to par with Winforms when it comes to serious applications which use a normal windows look and feel: automatic menu, buttonbar handling based on selected docked window for example, one of the cool features of many winforms control libraries, is one of those things which is hard to do in WPF (at least, it's not directly available/build in). One other thing which made me draw the above conclusion was that it in general sucks bigtime when you have a normal windows application with normal menus: the text is in general blurry (or at least blurry in a short period of time after a move/open) and to make the menus to look like normal menus like in VS.NET is a pain (it doesn't get close).

Because we will need a custom rendering system in this major version for some areas, we do need WPF. However, one can host a WPF control just fine in a winforms application, so re-using our already written winforms skeleton was a choice I didn't expect at first but which makes sense.

To Ribbon or Not To Ribbon
The second question one will ask is: should we use a ribbon-like menu system? After all, it's well known that good-looking applications are often chosen over the uglier competition: Looks Sell. So, a nice fancy ribbon menu in an application is tempting, right? After all, at first, a ribbon-containing application looks better (although it doesn't have to be more productive/easier to use, that's another story) Almost every control package out there, WPF or winforms comes with a ribbon control. Now, there's a catch and you likely already know: Microsoft had the fancy idea that if you're going to use a ribbon UI, you have to sign a license with them.

Let's keep the usefullness of a ribbon UI (which IMHO is heavily overrated) aside for now, let's focus on this 'license'. There are two things in this license which made me decide to not sign it and write this blog entry instead to warn you not to sign it as well. Disclaimer: I'm in Europe, and we think a bit differently about imaginary property than for example in the USA (like software patents and the like).

• It's unclear what a ribbon UI is
  This might sound weird, but let's do a thought experiment. One of the paragraphs in the license says:

  Your Licensed UI must comply with the Design Guidelines. If Microsoft notifies you that the Design Guidelines have been updated or that you are not complying with the Design Guidelines, you will make the necessary changes to comply as soon as you reasonably can, but no later than your next product release that is 6 months or more from the date you receive notice.

  Let's say I create a UI, call it MyUI. MyUI uses a ribbon control. However, as it's MyUI of MyApp, I use it as I see fit, it's my application and my work after all. The control I use is from a 3rd party vendor, not MS. If MyUI doesn't comply with the Office UI license, is it then a UI which has to be licensed? After all, a normal button bar UI also doesn't comply with the ribbon license. That's perhaps obvious, but where is the line which makes a given UI not a ribbon UI? To define that, one has to define exactly what a ribbon UI is. Though if a given UI, MyUI isn't compliant with that definition, it can't be in violation of this Office UI license, as it's not, by definition, a ribbon UI, and therefore doesn't need a license. After all, a normal windows UI isn't a ribbon UI either, although several Office 2007 applications use exactly that UI (Outlook main window for example, no ribbon in sight)
  
  Let's take another point of view. Let's say 5 other companies are also super proud of their UI work and also try to tie a developers hands by forcing him to sign a license for these UIs. Perhaps you're not even aware of these companies' work and you've never heard of them. Still, your UI looks remarkably similar to their work, or at least main parts of it. Are you now liable? Should you be seen as liable? I don't think so. For the people who think I'm paranoid: ever created a UI for an application which uses a 'Card' UI to display customer data for example ? Likely as the 3rd party control package used had this fancy option and it looked great. But... who cooked up that UI concept? Unknown, yet, that company or person might want to force a license on you similar to the Office UI license, simply because that person or that company is also proud of that Card UI concept. "That's stupid" you might say, and I agree, but why is this Office UI then different? Because it's owned by Microsoft? (although I would like to see what exactly they 'own' in this case, a 'button bar' is definitely not something they invented, and for example many winforms control packages have a system where you can define one set of commands which can be placed in a menu and on a button bar, equally.).
  
  It's similar to the Office UI and the ribbon: for WPF, there aren't any button bar / toolbar controls available, just ribbon controls. You are of course aware of Office 2007, but say you're working in a company which has still Office 2003, and your application is a normal business application, not something which competes with Office 2007 at all. Why should you sign a license agreement with some company X while you purchased the ribbon control you're using from company Y and have never used or are hardly using this 'UI' from X? And why should you sign only a license agreement for that ribbon control with company X, and not for the docking framework, the statusbar, the grid etc. ?
  
  Doesn't make any sense.

• The license contains traps
  For an ISV, the 'I' in ISV is important: we're independent and want to stay that way: only an independent software vendor can create software which is really worth using, as it's not tied to the train of thought of another company. However, the Office UI license contains restrictions that you effectively sign your independency away to Microsoft: Microsoft decides if the UI of your application is 'compliant' with the license and you have to update your UI to make it compliant or you're in violation of the license, and you have at most 6 months for that, which means you can't decide when to make the changes: MS sets the deadlines for that. But that's not the biggest issue. The biggest traps are these:

  c. Microsoft is the sole owner of the Microsoft IP. All goodwill arising from your use of the Microsoft trademark and trade dress rights granted to you in Section 2 will be for Microsoft’s benefit. The quality of your Licensed Products will be consistent with your other products, meet or exceed relevant industry standards and comply with all laws, rules and regulations that apply.
  
  f. You will comply with all export laws that apply to the subject matter of this license.

  For a European like me, I can't comply to rule f. The point is: the USA has different export laws for software than the EU. For an ISV outside the USA, the ISV and not MS nor the USA, is going to decide to which clients to sell the software, to which countries to export the software. Example: one can't sell a software application to an Iranian firm at the moment, according to the USA. However, the firm apparently has computers which run windows and .NET. It's up to the laws of the country the ISV is in, not to the laws of the USA nor to MS.
  
  The rule c is a trap as well: since when is the hard work of a) the control vendor (not MS) and b) the ISV something MS can benefit from? Goodwill can come into play when the ISV is sold to another company: the total price to pay will contain 'goodwill'. MS also can't decide what the quality bar is that the ISV will bring into the application: who will judge if the ISV has met the 'relevant industry standard' ? Who even decides what that industry standard is? Microsoft?

I'm often accused of being negative instead of being one of the cheerio-pass-me-the-marketeese-pipe crowd, but keep in mind that the world of an ISV is somewhat different than that of a developer who can leave all legal crap to some suit on the top floor: if the people in charge of the ISV don't take care of these legal issues, if they don't look into the 'what if's, it might well be the ISV simply keels over due to a heavy lawsuit which drains them from all their money, even if they're totally correct and that on paper they should win. That's why ISVs should be careful.

It might sound far fetched, but these kind of issues will in the end affect the normal developer as well. Therefore every developer should say no to software patents and no to silly, evil, licenses like the Office UI license.