Oracle this morning announced that it has acquired GoAhead Software, which sells packaged service availability software to network equipment providers (NEPs) and other players in the commmunications industry. Financial terms of the acquisition were not disclosed.

GoAhead, a privately-held company based in Bellevue, Washington, provides software that speeds the time to market of carrier-grade services that need to be always available at all times.

The company claims its software has seen over 100,000 deployments by NEPs to date.

Customers include Motorola, LG-Nortel, Alcatel and Oki.

The transaction is subject to customary closing conditions and is expected to close before the end of 2011. Until the deal closes, each company will continue to operate independently.

Oracle this morning announced that it has acquired RightNow – both companies are listed on NASDAQ – for $43 per share or roughly $1.5 billion net of RightNow’s cash and debt. With the acquisition, Oracle is adding a robust cloud-based customer service offering (see graph below) to its own Public Cloud solution – more info on that here. RightNow’s share price closed at $35.96 last week, so the deal represents a premium of roughly 20 percent on its closing price on Friday the 21st of October.

RightNow’s solutions help companies handle customer interactions across a multitude of channels, including call and contact centers, the Web and social networks.

Its products are used by nearly 2,000 organizations across the globe, the company says.

Founded in 1997, RightNow went public in 2004. The company boasted a market cap of $1.2 billion at market close last week.

The acquisition by Oracle is expected to close later this year or in early 2012. As usual, the transaction is subject to a number of things, including RightNow stockholder approval, regulatory approvals and other customary closing conditions.

Oracle has closed 6 acquisitions this year. While its takeovers of RightNow and Endeca are pending, the company has completed the purchases of Datanomic, FatWire, Inquira, select intellectual property assets of Ndevr, Ksplice and Pillar Data Systems in 2011 alone.

Google v. Oracle. It’s a sensational case. A battle of tech heavyweights — and a software copyright case that went all the way to the U.S. Supreme Court. Millions of dollars are at stake. And the ramifications for software entrepreneurs are significant.

The facts are not in dispute. Google copied a portion of Oracle’s Java application programming interface (API) to create the Android operating system — the most installed mobile operating system in the world.

Oracle then sued Google for copyright infringement, but lost in federal district court. Then, surprising many, it won a major victory — a reversal at the U.S. Court of Appeals for the Federal Circuit — an appeals court directly below the U.S. Supreme Court.

The Federal Circuit, overturning the district court’s decision, decided that Oracle’s Java API is copyrightable. And in June of this year, the U.S. Supreme Court refused to consider the case.

Software developers routinely treat APIs as exempt from copyright protection. That was Google’s assumption when it copied the Java API. That assumption must now change. Under the court’s logic, nearly any API larger than a few words or phrases could be protected by copyright.

Now, Google and other developers who copy an API without having a license to do so may have only one defense: a doctrine in copyright law called “fair use.”

The jury in the district court case already considered whether Google’s copying was fair use, but was unable to decide. So this high-stakes case now falls back into the hands of a hesitant jury charged with deciding whether Google’s having used Oracle’s Java API for its Android operating system was in fact fair use. There is no way to predict the outcome.

Because using APIs is so common, startups, as well as established software companies, need to operate with a clear understanding of this legal battle. They need to understand the implications of this decision in order to avoid running afoul of others’ copyrights — and to leverage their own. 

Copyright Versus Patents

The difference between copyright and patent protection is often misunderstood. In the context of software development, copyrights and patents protect two entirely different, non-overlapping aspects.

Patents protect functional aspects of software, such as processes and methods of operation. We generally think of these as features of the software. Reproducing patented processes and methods, even in independently written code, is patent infringement.

In contrast, copyright only protects artistic aspects of software code, not its functional aspects. Consequently, if software is protected only by copyright, then others may appropriate any of the features implemented by the software by simply writing their own code independently.

America’s courts have historically struggled with how to separate artistic aspects of software code from functional aspects. Because software is mostly functional, you might think that copyright protection of software is weak. Generally, you’d be right.

But copyright protection is very useful if someone copies either the source code or the compiled code. If someone literally copies all or a portion of such code, then a court would probably decide that at least some artistic aspects were copied, thereby infringing the original developer’s copyright.

But, you think, if that is the case, why would Google think it could literally copy a portion of the Java API? The answer is based on a well-established principle of copyright law that tries to prevent granting patent-like rights through copyright. Specifically, according to the Copyright Act, copyright protection in a work must not extend to any functional system or method of operation, regardless of the form in which the system or method is described in the work. 

One reason for this copyright principle is the differing ease at which protection may be obtained. Copyright protection arises out of the creative effort of writing software. No application for copyright protection is required. In contrast, to obtain patent protection, an application must be filed at the U.S. Patent and Trademark Office. A highly trained patent examiner reviews the application against the state of known technologies. An examiner may only grant a patent when convinced that the claimed invention is new and not obvious over such technologies.

Google had argued that if the Java API were copyrightable, then copyright protection would effectively extend to the functional system described in the Java API. Thus, Google claimed, for anyone to create a functional system exactly as described in the Java API, they would have to copy the Java API.

Then, said Google, because copying the Java API would infringe Oracle’s copyright, its copyright effectively extends to the functional system described in the Java API — improperly granting patent-like rights through copyright.

The Federal Circuit disagreed. It reasoned that “the declaring code [in the Java API] could have been written and organized in any number of ways and still have achieved the same functions.”

For example, the Court argued that the Windows Phone API from Microsoft provides “similar functionality” with an entirely different structure, naming scheme and selection than the Java API. Whether Google could copy the exact functional system described in the API is apparently a question of compatibility, which the Court said should be addressed with a “fair use defense.”

Avoiding Copyright Infringement

One tip to avoid copyright infringement is developers should not copy a third-party’s API unless the developers have a license to do so. That sounds straightforward, but it is often difficult or impossible. Say a company plans to develop a new software product that will compete with a competitor’s existing software product. Customers will access the new software product through an API.

Competitor customers also access the competitor’s existing software product through an API. To encourage the competitor customers to switch to the company’s new software product, the company may be tempted to copy the competitor’s API. If the new API is the same as the competitor’s API, then the competitor customers would not need to make any changes to their code to use the company’s new software product.

In such a scenario, the company should not copy the competitor’s API without a license and rely on the fair use defense without first consulting a copyright attorney. Fair use is highly fact-sensitive — and highly subjective. A jury weighs multiple factors, and it is difficult to know in advance whether any fair use defense will succeed.

Surprisingly, if the innovating company develops a new API instead of making an identical copy of the competitor’s, it still risks copyright infringement. A copyright owner may prove that an original work has been copied by first proving that the accused infringer had access to the original work and second showing that the accused work is “substantially similar” to the original. In this “copy test,” direct evidence of copying is not a requirement.

So, developing a new API may risk infringement even if the new API is not identical to the competitor’s and was not actually consciously copied from the competitor. If the two APIs are found to be “substantially similar” and the developers of the new API had access to the competitor’s, then that competitor could successfully argue that the new API infringes their copyright.

You can surely imagine the scene in court where an attorney shows a jury the two APIs side-by-side, and points out all the similarities!

One way to mitigate this risk is to develop any new API using “clean room” development. In this approach, the desired functionality is given to a developer, who writes the new API from scratch without ever accessing the competitor’s API. This technique addresses the issue of whether one’s developers had access to the competitor’s API in the “copy test.”

If a company is a startup, though, all its developers may already have had access to the competitor’s API. That may make a “clean room” option economically unviable because the startup would have to hire one or more other developers who demonstrably had no access to the competitor’s API.

Instead, the company may deliberately try to make the new API different from the competitor’s. It may first instruct its developers to develop a unique new API based on the desired functionality without referring back to the competitor’s API; then it could compare the resulting new API to the competitor’s and modify any elements that are too similar. However, this “deliberately different” option is much riskier than the “clean room” option.

Protecting Software

How can a company protect its own software? One way is to publish its APIs just to make it easier to show that a competitor had access to them. Ideally, there also is another legitimate reason to publish its APIs, such as to provide online documentation for users. Then, if the competitor creates a substantially similar API, a company might succeed in a copyright infringement claim.

That brings us back to patent protection, which should be sought for new and innovative features. Although recent Supreme Court rulings such as the notable 2014 decision in Alice Corporation v. CLS Bank Intl. have made patenting certain categories of software inventions more difficult, patents on software features for many different technologies are alive and well.

Parting Thought: Issues For Some Entrepreneurs Are An Opportunity For Others

As just explained, the decision in Google v. Oracle is inconsistent with many software developers’ past view of APIs. As a result, many APIs now probably infringe another’s copyright. For better or worse, this creates opportunities for entrepreneurs to make money based on litigation or a threat of litigation. Some such scenarios might be viewed as the copyright analog of what have commonly become known as “patent trolls.”

Specifically, entities may emerge that purchase copyrights in original APIs, search for instances of others’ copying those APIs without a license and sue for damages. That surely would be an unintended outcome of the Federal Circuit’s decision — and one worth keeping an eye on.

This article is intended to provide information of general interest to the public and is not intended to offer legal advice about specific situations or problems. You should consult a lawyer if you have a legal matter requiring attention.

It’s no secret that open-source technology — once the province of radicals, hippies and granola eaters — has gone mainstream. According to industry estimates, more than 180 young companies that give away their software raised roughly $3.2 billion in financing from 2011 to 2014.

Even major enterprise-IT vendors are relying on open-source for critical business functions today. It’s a big turnaround from the days when former Microsoft CEO Steve Ballmer famously called the open-source Linux operating system “a cancer” (and obviously a threat to Windows).

Despite the growing popularity of open-source software, though, many open-source companies are not financially healthy. Just like eyeballs didn’t translate into actual online purchases during the first dot-com era in the late 1990s, millions of free-software downloads do not always lead to sustainable revenue streams.

Make no mistake, open-source software is a brilliant delivery model to drive user adoption, and it’s poised to drive increasing market value in the coming years. But it’s not a business model on its own.

Source: Publicly available data

Just how challenging is it to build a big, profitable open-source business? Consider this: Besides the ongoing success of Red Hat — the company now boasts a $14 billion valuation, built over 20 years — and MySQL’s acquisition by Sun for $1 billion in 2008, there are few other landmark exits in the history of open source.

But success, for entrepreneurs and investors alike, is possible. Based on our experience working with open-source names, including Mirantis*, Cloudera*, MongoDB* and others, we have isolated some key lessons for entrepreneurs to consider as they build open-source communities and sustainable businesses in parallel; the two don’t have to be mutually exclusive.

Think about a business model from day one

This seems obvious, but you’d be surprised how often open-source entrepreneurs think of their business model only after their free-software downloads are off the charts. In contrast, our experience suggests that some of the best open-source companies had a clear idea of how they were going to make money from their early days.

Companies often do this by selling enterprise versions of open-source projects with extra security and management features. These are designed to appeal to the large enterprises that are big IT spenders. Another option is to offer a premium SaaS service, essentially a pay-as-you-go model. While delivering a reliable service can be difficult — namely, packaging many open-source components together into one compelling, cloud-based offering — SaaS can be another route to revenue.

Red Hat is a good example of a company that thought about monetization from the get-go. Early on, when the company was shifting from shipping Linux CDs in textbooks toward selling to big enterprises, executives drew a clear delineation between the company’s free Fedora user community and the more sophisticated Red Hat Enterprise Linux (RHEL) product. They recognized that their target buyers — CIOs and operations executives — valued stability over features, and these execs wanted an enterprise-grade, paid product supporting their core Linux applications.

So while Red Hat maintained a vibrant open-source community around Fedora, updating it with new features and releases every six months, the company marketed enterprise-grade security and optimization on standard Intel hardware to people using the paid enterprise product. This allowed Red Hat to build a recurring revenue stream of more than $1 billion from enterprise customers; it also, more broadly, helped Linux become the most widely adopted server operating system.

Another forward-thinking open-source company, Cloudera, comes from the big-data world, where several companies are trying to commercialize the open-source project called Hadoop. Like Red Hat, Cloudera has reserved some important enterprise features — security, performance and business analytics — for its higher-end product, called Enterprise Data Hub. Meanwhile, big-data competitor Hortonworks is trying to make money from paid product support, which may be a more difficult model.

The Apache software foundation, whose open-source server software burst onto the tech scene in the 1990s, led to many vendors trying a similar strategy — essentially, selling customers support as a sort of insurance policy on their deployments, which some users considered risky because they were based on open-source technology. Over time, though, many customers got comfortable with the products and didn’t need the support — demonstrating that this was not a long-term strategy for monetization.

Source: Publicly available data

Pick a licensing model aligned with your monetization strategy

Open-source licenses determine exactly who owns modified versions of your open-source product, and can have big implications for your business. Some licenses allow anyone to create closed-source derivative works that build on the original product, while others reserve that right only for the owners of the original product. This is a big deal when you’re trying to figure out how to add features to your product that people will purchase.

Keep in mind that even open-source software is always owned by someone, usually either a for-profit company or a non-profit foundation (kumbaya only goes so far). Licenses range from permissive (Apache) to restrictive (General Public License, or GPL, variants, with Affero GPL the most restrictive), and everything in between.

There are 71 different flavors, to be exact, all listed on opensource.org. More permissive licenses make it easier to build large ecosystems. If any open-source project can incorporate yours, you can get a tailwind by being included in, or connected to, other successful projects. Looser licenses also may make it easier to solicit contributions to the product, and they make users more comfortable that the project is less dependent on a small startup.

At the same time, allowing anyone to add enterprise features to your product makes it harder to create sustained differentiation, build revenue and avoid fragmentation. A case in point is the popular OpenStack project for cloud infrastructure, governed by the OpenStack Foundation. Early buy-in from tech giants like Intel, Red Hat, H-P, Dell, Juniper and others was critical to early support from large users like PayPal, Walmart and Symantec, who knew their core infrastructure foundation was supported by the broader community and large hardware companies.

However, OpenStack recently has been criticized for moving in multiple directions, driven by the various hardware players who all have competing business and strategic agendas and, now, products that may not work well with each other. This has led to the emergence of two vendors, Red Hat and Mirantis*, who promise to be the “Switzerland” of the ecosystem and work with everyone. It seems a compelling business case, given the problems this permissive license has created.

MongoDB, by contrast, has consistently followed the stricter AGPL license model. Despite using a strict license, MongoDB’s software has become very popular. This happened mostly because the company offered a compelling product: a simple, flexible-document database that many developers found much easier to use than older relational databases. That product trumped the restrictive license.

Within two years, MongoDB had amassed millions of downloads; it has 10 million today. For open-source entrepreneurs who believe their product can gain wide adoption without having to piggyback on the success of other open-source projects, a more restrictive license may be better in the longer run. But if you go that route, be prepared to invest heavily in building community in the early days.

Ancillary services and “hand holding” may be necessary, but don’t get hooked on them for revenue

Open-source software has disrupted some of the most important technologies in enterprise infrastructure: think MongoDB and Cassandra taking on legacy Oracle databases, OpenStack and Docker threatening virtualization giant VMware and Linux displacing Solaris and Windows Server software. What helped these open-source underdogs grow was real-world successes — not, as some entrepreneurs think, pricey consulting services to augment deployments.

In the early days of open-source adoption, of course, some professional services and “hand holding” may be necessary to get open-source systems off the ground, especially when customers are dealing with integrating legacy software. Indeed, some of the earliest Hadoop, OpenStack and Cloud Foundry deployments needed consulting services to make key customers successful.

But don’t try to build your business on services revenue. It carries a lower gross profit margin than other revenue streams — perhaps 20-30 percent, as opposed to 90 percent for product-related revenue — and it’s not generally repeatable. Ultimately, if you’re successful, you’ll have millions of users, but you’ll only be able to tap perhaps a few hundred of them for services revenue.

Plus, if you chase services revenue too aggressively you could wind up competing with services partners (e.g., Accenture, IBM) that could help bring you new users. Our advice: Focus on building your recurring revenue from subscriptions, which should be your high-margin core product. Build your services organization to support customer success and partner success, not to drive revenue. What’s more, we would even support aggressively cannibalizing your services business by making your product easier to use and your partners more capable, so that they can take over running it themselves in the longer term.

Ongoing customer satisfaction trumps upfront sales

Sales cycles in open source are very different from those in traditional, enterprise software. With regular, enterprise software, it’s often hard to convince customers to use the technology; on top of that, they have to pay for it. In open source, that decision process is often bifurcated, happening in two separate steps. Convincing people to use your software is often much easier, because the product may be initially free. But then you face a separate task, later, to convince them to pay.

This shift can be disorienting for those who are used to traditional enterprise-software sales and marketing. Reps can spend lots of time trying to convince someone to use your software — and succeeding — but then not wind up with any revenue for their effort. In the early days of your company, that might be okay, because you’re also trying to build your user base, which could turn into revenue later.

But even after you grow, and start racking up sales, you need to become very disciplined about getting your sales team to focus on ongoing customer satisfaction, because happy customers buy more, and buy products with higher ASPs (average selling prices). This, in turn, helps subsidize your ongoing R&D. Overall, this is quite different than most enterprise-sales models, which focus on making the sale and moving on to the next prospect.

Salespeople need to be measured on the subscription revenue they are bringing in, while a separate team focused on community should nurture adoption growth. This may mean hiring a different type of salesperson — someone who may not be from the high-pressure Oracle mold, for instance, though those folks can still succeed with the right type of training.

At MongoDB, we had a very successful salesperson who had previously started a sports-uniform business and another business to clean roof gutters. He may not have had a lot of software experience, but he was fanatical about customer satisfaction.

Getting past the open-source revenue conundrum

Clearly, making money from free software is possible, and there are different paths to doing it successfully. But focusing on monetization and licensing from the beginning, and building the right type of services model and sales team, are key tactics for doing it right. We now have plenty of corporate case studies from the last 20 years that demonstrate that you can indeed build a profitable, open-source company that is also very popular with users.

In other words, you can have your granola and eat it, too.

*Denotes an investment by Mr. Thakker when he was at Intel Capital.

Oracle and Google are in the courtroom again — the same court they started in back in 2010, when Oracle first sued Google over the company’s use of 37 Java APIs in its Android operating system. The case, first decided in favor of Google, bounced up to an appeals court and was reversed, then appealed to the Supreme Court, which declined to hear the case. Now Oracle’s lawsuit, which could net the company $9 billion, is back where it started in U.S. District Court.

But this time, instead of debating whether Google infringed on Oracle’s copyright when it used the Java APIs in Android, the two companies are arguing over whether Google’s coding falls under fair use. And while Oracle is hitting hard on the four legal measures for fair use, its lawyers and witnesses are also working to portray Oracle as a defender of free and open source software.

It’s an image that will be tough to square with the reputation Oracle has developed during this case as a corporate fist clamping down on open source. A long list of computer scientists have opposed Oracle, saying that the company’s position will cause far-reaching harm to the open source community.

But Oracle co-CEO Safra Catz testified Monday and Tuesday this week that it was Google, not Oracle, that locked its software away within a walled garden.

Google says the open source nature of Java is what led the Android team to embrace its APIs. But Catz claimed that the only way to preserve Java’s longstanding “write once, run anywhere” philosophy was to protect the language from interlopers like Google, which, in Oracle’s view, warped it into non-compatible form with Android.

Oracle began telling its side of the story yesterday when Catz took the stand. Catz, who shares Oracle’s chief executive role with Mark Hurd, said that Oracle’s decision to purchase Sun Microsystems in 2009 was largely motivated by a desire to protect Java and preserve the programming language for fair and open use.

Catz testified that, when Sun’s stock slid in the mid-2000s, she began to fret about the fate of Java. Oracle was already using Java to build software and Catz was concerned that, if Sun tanked, Oracle’s go-to programming language would falter.

“We were concerned [Sun] wouldn’t invest enough, and Java was critical for our product,” Catz said.

So, in order to avoid losing Java to decay or to a competitor, Oracle started trying to buy it. Catz explained that Oracle started small, offering to purchase only Java and some other pieces of Sun’s software business, only to be rebuffed. When it became clear that IBM might buy Sun, hardware and all, Oracle came back to the table with $7.4 billion and beat IBM’s offer of $7 billion to buy the entire company.

At the time of the purchase, Oracle’s then-CEO Larry Ellison called Java the “single most important software asset we have ever acquired.” (Ellison is now Oracle’s chairman.) Catz echoed his remark in court on Monday, adding that she recommended the acquisition to Ellison and planned to grow Java once it was brought in-house. “We intended to invest in Java and bring the Java community together and come out with new versions of Java going forward,” Catz said.

Catz testified that Google’s use of Java in Android became a topic of conversation at Oracle soon after the acquisition. She said Sun’s former CEO, Jonathan Schwartz, told Oracle that he had been in negotiations with Google to get the company to purchase a license for its use of Java. (Schwartz testified on behalf of Google in the case.)

But, by the time Oracle’s deal with Sun closed in early 2010, Catz said Android’s effect on the openness of Java was too large to reverse. She claimed today that the entire community of Java programmers had been split in two, with some of the programmers switching to the Android platform and thereby limiting the universality of Java. With Java, Catz said, “They could write it once and run it anywhere. Once you write it in Android, you can’t run it on anything but Android.”

It’s a bit of a rhetorical leap to characterize Android, a free and open platform, as one that’s restrictive of development. Google’s attorneys pushed back on this assertion during their questioning of Catz, suggesting that Oracle didn’t fully understand the open nature of Java and that executives were either unprepared to manage an open source platform, or had every intention of restricting use of Java.

Google’s lawyers also questioned Catz about Oracle’s own efforts to develop a smartphone, a plan that Oracle considered soon after the acquisition of Sun but ultimately abandoned. At one point, attorneys displayed a slide from an internal Oracle presentation on phone development that read in part, “Oracle has very limited internal expertise to make smart decisions.”

Google made some headway in suggesting that Oracle only chose to sue after its efforts to make a smartphone failed, showing emails between Ellison and Alphabet executive chairman Eric Schmidt that indicated the pair were meeting just months before Oracle filed its suit. Google also referenced Ellison’s now-infamous remarks at a JavaOne developers’ conference, when he indicated he was happy with Google’s implementation of Java. “I think we can see lots and lots of Java devices, some coming from our friends at Google,” Ellison said.

Whatever friendship existed between Oracle and Google executives has long since withered. Catz testified that Google’s general counsel Kent Walker approached her at a bat mitzvah in March 2012 to discuss the lawsuit. According to Catz, Walker said, “Google is a very special company and the old rules don’t apply to us.”

Catz fired back with one old rule: “Thou shalt not steal.”

She testified that Google’s alleged infringement has cost Oracle hundreds of millions of dollars, including in a bargain basement deal with Amazon for use of Java in the development of Paperwhite.

Testimony in the case is scheduled to continue this week, with closing arguments expected to begin next week.

Alphabet CEO and Google co-founder Larry Page defended his company’s development of the Android platform today during an ongoing legal battle with Oracle. Oracle sued Google in 2010, claiming that Android developers copied sections of proprietary code from Java. Google has maintained that the code in question was open source and free for its engineers to use, and that the implementation of the Java code in Android was transformative enough to be considered fair use.

Page testified that he had little knowledge of the engineering details of Android that are at issue in this case, despite the fact that the lawsuit has now dragged on over the course of five years. However, he disputed Oracle’s assertion that Google stole its intellectual property when it used Java declaring code in Android. “When Sun established Java, they established it as an open source thing,” Page said. “We didn’t pay for the free and open things.”

He defended Google’s decision to use the APIs without obtaining a license from Sun Microsystems, which was later acquired by Oracle, saying that copying and reimplementing the APIs in question was a standard industry practice. Page claimed that Google’s implementation of the APIs was original and transformative, suggesting that his company’s coding would fall under fair use.

“I think we acted very responsibly and carefully around intellectual property issues,” Page explained.

Oracle attorneys presented Page with a Google slide deck that said the Android ecosystem was generating $43 billion in revenue each year. But Page argued that the massive revenue described in the slide wasn’t going into Google’s pockets, but rather to phone manufacturers and carriers. “I don’t know how much that has to do with Google,” Page testified, adding that carriers like Verizon “made a lot of money, but that doesn’t do Google any good.”

Page also discussed founding Google and acquiring Android. He said he took an interest in building a smartphone when he became frustrated with other phones on the market.

“I was super frustrated with the state of phones at the time, many of which were running Java. They didn’t really work very well. You couldn’t even take a picture and share it with someone. We had a closet full of a hundred phones so we could test them. They all worked differently and we couldn’t get our software to work on them. It was incredibly frustrating,” Page explained.

He added that he wanted Google to develop a phone so that he could expand access to his search engine to as many people as possible. “We make most of our money from Google Search and we want people to be able to access that, even if you don’t have very much money,” Page said.

Oracle and Google are presenting their final witnesses in the case today. Closing arguments are expected to begin on Monday and a jury will consider next week whether Google’s use of the Java APIs qualifies as fair use.