20 April 2005

Always a Beta, Never a Bride

A key factor in Google's remarkable success during its short corporate history has been its unwillingness to be bound by conventional wisdom -- not just in its technology and business decisions, but in its licensing choices as well. For its legions of faithful users, Google's "go your own way" approach has produced services that are often useful to the point of indispensability, but Google's licensing practices, while right for Google, may not be right for all. Widespread adoption of such practices by other software companies for other types of software products could quickly prove problematic both for software users and for those lawyers charged with their care and feeding.

A new software product, like most new products, rarely is suitable for the masses in its first complete iteration from the development environment. Many times, planned features are not yet completed, some functions do not operate as expected or at all, or the design of the product doesn't meet the developer's or its users' needs. An interim version of the software is necessary to work through these concerns; such a version needs to be complete enough to work with but need not be so polished that it's considered "ready for prime time". Such a version is generally termed a "beta" release; as defined by WhatIs:
[A] beta test is the second phase of software testing in which a sampling of the intended audience tries the product out. (Beta is the second letter of the Greek alphabet.) Originally, the term alpha test meant the first phase of testing in a software development process. The first phase includes unit testing, component testing, and system testing. Beta testing can be considered "pre-release testing." Beta test versions of software are now distributed to a wide audience on the Web partly to give the program a "real-world" test and partly to provide a preview of the next release.
The issue then is not whether a new product will require beta testing, but when such testing will occur; alternately, and perhaps more precisely, the issue is how a software developer will define its "sampling of the intended audience".

Unlike a marketing focus group, beta testers have not generally been a representative cross-section of the intended audience; rather, these testers were usually much more technically-savvy than the general audience for the tested products. These "power users" were often selected for their technical skills -- skills which would enable them to recognize problems ordinary users wouldn't and to better-understand the root causes of those problems. For some beta tests, a more representative cross-section of the intended audience would be useful to a developer, but regardless the breadth of this sampling, it was just that -- a sample of the overall user base.

Thus, in the traditional sense, a beta product differed from the final (or "general release") product in two ways: 1) the product's intended audience (a sampling of the user base versus the entire user base); and 2) the "completeness" of the product. Implicit in the concept of the beta product is that it is an interim version of the product; the beta test is a prelude to the general release, rather than a general release in and of itself. This naturally begs the question, if a "beta" product is released to an entire user base and there is no definitive expectation by the developer to transition to a more complete and polished version, is this really a beta at all?

In the Disney version of Alice in Wonderland, the Mad Hatter and the March Hare explain the concept of the "unbirthday":
Let's all congratulate us with another cup of tea
A very merry unbirthday to you
Now statistics prove
Prove that you've one birthday
Imagine just one birthday every year
Ah, but there are 364 unbirthdays
Precisely why we're gathered here to cheer
Poor Alice. When we try to define something by what it isn't rather than by what it is, we're bound for trouble, aren't we? So when a "beta" product is defined more as an "un-general release", by only noting that it isn't a general release version, where does that leave us as users and as users' attorneys?

The concern for us revolves around the differences between a general release product's license terms and those terms applicable to a beta product. Like any contract, a software license describes mutual obligations. For software users, such obligations generally include restrictions on use and copying of the software and documentation, prohibitions against decompiling software object code or modifying scripted programming statements, and (most important to those of us who work on the developer side) an obligation to pay licensing fees. For software developers, licenses generally describe warranty and support obligations.

A beta transaction is different. In such a relationship, the consideration on each side is less mercantile in nature. For a user of beta software, the value may be in working with and understanding an advanced product before the general public does, or in influencing the development of a product; for some, the ego boost associated with simply being granted access to something when others are not may be value enough. For a developer, the value of the beta is the feedback received from the test audience. As such, it is not generally expected that a beta tester pay for the privilege of receiving the beta product or that a developer warrant the product or indemnify the tester's use of it.

Where Google has departed from these licensing norms is in its blurring of the line between beta products and general release products -- many of Google's products, including the immensely-popular Gmail and Google News services, are still designated as "beta" while functioning in practice no differently than Google's other products. By providing what are de facto general release services under the legal guise of beta offerings, Google derives the full benefit of its products without the usually-associated customer expectations or obligations.

Whether this is intentional on Google's part or just legal happenstance is debatable. When Gmail debuted in April, 2004, contemporaneous reports clearly indicated that its beta status was not intended to be perpetual:
[Analyst Hellen Omwando] also pointed out that, although Gmail remains in a beta format, the service does lack some functionality offered by rivals such as Yahoo, such as the ability for users to access multiple e-mail accounts from one central account.

Google is wary of announcing a launch date for the service until beta testing is complete, but according to Kate Burns, managing director of Google UK's ad sales, it will be widely available to consumers fairly soon.

"My feeling is that we have already done an awful lot of testing, so it will be a limited test period--a matter of weeks," Burns said.

Since that time, more than a dozen major improvements have been made to the Gmail service, but it remains (officially at least) in beta. Although many users have recently noticed a loosening of the invitation supply (by which new users are enabled to join the service), Google has not indicated when, if ever, Gmail will lose its "beta" tag.

It is also not certain whether Google News remains in beta four years after its launch by design or by circumstance. According to Wired last year:
As it turns out, however, Google has a problem that is nearly as complex as its algorithms. It can't make money from Google News.

So while other online publishers like Yahoo News and MSNBC earn tens of millions of dollars in revenue each year and continue to grow, Google News remains in beta mode -- three years after it launched -- long after most of the bugs have been excised.

The reason: The minute Google News runs paid advertising of any sort it could face a torrent of cease-and-desist letters from the legal departments of newspapers, which would argue that "fair use" doesn't cover lifting headlines and lead paragraphs verbatim from their articles. Other publishers might simply block users originating from Google News, effectively snuffing it out.

These potential copyright issues, while a legitimate (no pun intended) concern, do not result from any technical or design weaknesses in the service itself. The Google News service is, at least in my experience as a long-time user, a stable and complete one; while the list of news sources and the algorithms applied thereto are continuously modified by Google behind-the-scenes, the only major feature change in the service in recent months has been the addition of a personalization function. Moreover, the limitation identified in the Wired article -- Google's reluctance to add commercial advertising to a "beta" service -- is belied by the fact that the Gmail service (as discussed above, also in beta) does display such advertising; commercialization is clearly not the demarcation line for Google between beta and general release.

Still, all of this pseudo-beta nonsense works for Google. In part, this is because its free, publicly-available services are 1) free; 2) publicly-available; and 3) services. Because all of Google's services are supported by advertising (or by the company itself) and provided at no charge to users, Google enjoys a degree of freedom as it does not have the usual developer's incentive to move its beta products into general release in order to be paid for their use. Because services like Gmail and Google News are made publicly-available, the usual licensing concerns of software developers that their products will be copied and distributed without authorization do not apply. Because Google's applications are hosted by Google and provided as services, users have no practical means to copy those applications; whereas a developer of shrink-wrapped software products needs to maintain a high degree of legal control over its creation because it is leaving its possession and will be "entrusted" to another party, Google has no such concern. Moreover, as free, publicly-available services, users have no expectation that Google will provide them with traditional software warranties; beyond privacy concerns, which Google addresses, users take what they can get, gladly and without further questions.

What this all boils down to is that neither Google nor its customers has any need for the formalities of a traditional software license; consequently, if a Google service remains officially in beta even years after its launch and in the absence of any apparent material defects or feature gaps, who cares? In Google's case, no one really. However, when developers whose products are not similar to Google's seek to extract traditional license obligations and fees from users, but disclaim their own traditional license obligations because the software is "in beta", we should be concerned; when the developer in question is the world's largest, we should be very concerned.

In its escalating competition with Google, Microsoft has often played catch-up, as with its revamped web search service (codenamed "Underdog" during its development) and enhanced HotMail web-based e-mail service. Microsoft has also focused on preventing or mitigating Google's encroachment upon its traditional software strengths in business applications, operating systems, and development tools. For some observers, this is a David-versus-Goliath struggle between the world's largest software company and a nimble and talented newcomer; for others, Microsoft and Google are merely proxies in a larger battle between PC-based and web-based applications. Regardless which, if either, characterization is true, Microsoft's perception of a Google threat has affected the development and positioning of its products, particularly its web-based products, but has not clearly affected its licensing methodology until now:
Microsoft released on Monday test versions of its forthcoming development tools and database, early versions the company said are already suitable for running production business applications.

Microsoft customers who subscribe to the Microsoft Development Network can access the second beta of the Visual Studio 2005 and the April "community technology preview" of SQL Server 2005. Both products are due for completion in the second half of the year and will be released in tandem.

The preview version of the database will include all planned features for SQL Server 2005. Rather than have a third beta program as originally planned, Microsoft will release updates every six to eight weeks until the product is finished, said Tom Rizzo, director of product management for SQL Server.

For both the SQL server and Visual Studio betas, Microsoft will offer customers the option to sign a "GoLive" license, which will allow them to deploy production systems on the beta software. Typically, beta software agreements do not allow customers to run applications because Microsoft does not officially offer support.

Because of the change in the license and the quality of the code, Microsoft expects 50,000 customers to move production applications onto the beta versions of Visual Studio 2005 and the .Net Framework, the software needed to run applications.

The referenced "Go-Live" License provides in part:

Recipient wishes to have the option, at Recipient's sole discretion, of using the Pre-Release Software to a) deploy applications built with such Pre-Release Software in a live internal production environment, and/or b) deploy or distribute for use by third parties certain applications created with the Pre-Release Software . . . .

8. No Support. Microsoft is not obligated to provide maintenance, technical support, Updates or other support to Recipient or Recipient’s users of the Applications. Recipient is solely responsible for updating its users, if needed, with versions of Applications that operate satisfactorily with subsequent releases (including the final commercial release) of the Pre-Release Software.

. . . .

10. PRERELEASE/TIME SENSITIVE CODE. THE PRE-RELEASE SOFTWARE CONTAINS TIME SENSITIVE AND PRERELEASE CODE THAT IS NOT AT THE LEVEL OF PERFORMANCE AND COMPATIBILITY OF A FINAL, GENERALLY AVAILABLE, PRODUCT OFFERING AND MAY NOT OPERATE CORRECTLY. RECIPIENT'S EXERCISE OF ANY RIGHTS UNDER THIS SUPPLEMENTAL LICENSE IS AT RECIPIENT'S SOLE DISCRETION AND RECIPIENT ASSUMES ALL RESPONSIBILITY FOR AND RISK OF ANY AND ALL DAMAGES THAT MAY RESULT FROM OR IN CONNECTION WITH THE EXERCISE OF SUCH RIGHTS, INCLUDING WITHOUT LIMITATION THE LOSS OF ANY DATA OR OTHER CONTENT.

To parse all that a bit, what's described is a situation wherein paying customers (albeit not paying specifically for this software license) are encouraged to deploy software "that is not at the level of a final, generally available, product offering" in a production, rather than test, operating environment. These customers are to do this without the usual developer support available for final, generally available products, without legal recourse for any effects caused by the software, and without any assurance that future changes in the still-developing software will not wipe out the customer's deployment efforts. Moreover, the customer is encouraged to provide to other parties applications it develops which are based and reliant upon the beta software.

This is the software licensing analog to a piece of real estate bought "as is" by quitclaim. It's legally permitted to buy land like that, but is it wise to do so? Would you advise someone to buy land in that fashion and, further, to build on that land in reliance on their quality of title to it? It's risky business in both real estate and technology.

Generally, software applications do not operate in isolation. One application receives inputs from another application and outputs to a third application; all of them operate within an environment created and managed by still more software. Usually, each developer-vendor will warrant and maintain its own piece of the puzzle and none other; to be fully-protected, an end user of this system must be able to string together these piecemeal warranties to achieve complete coverage. To the extent that one or another of these applications is a beta application without such warranties, there is a gap in the coverage; whether that gap becomes dangerous is a matter of degree.

Let me be clear on this -- what Microsoft is doing is legal and does not jeopardize their interests. If I were Microsoft's attorney, I'd love this. I'm not Microsoft's attorney, though. I'm an attorney for a company that relies on Microsoft's products and the legal warranties and remedies described in the software licenses for which we've paid; I'm a direct user of Microsoft's products and indirectly, I use Microsoft's products through my use of other applications and services which rely upon them. As a consumer of software generally, I know that the license practices of other developers often take their cues from the bigger players -- the Googles and Microsofts of the world -- and what starts with those bigger players (good and bad) tends to trickle down to everyone until it becomes accepted as the status quo.

Microsoft's "Go-Live" License may be a one-off scheme or it may be the proverbial camel's nose under the tent. Given the increasing acceptance of the Google-style perpetual beta, I'm less confident than I might be that it's the former. For both users and their attorneys, times were simpler when the universe of beta software was kept separate from the universe of general release software, but the times they are a changin'.

UPDATE

1 comment:

Anonymous said...

Greetings,
I found this to be very enlightening and interesting.


"However, when developers whose products are not similar to Google's seek to extract traditional license obligations and fees from users, but disclaim their own traditional license obligations because the software is "in beta", we should be concerned;.."

I think this is happening more and more frequently the latest example of this that I have come across is imvu.com