Introduction
Today we will be taking a look at the major history of one of the original relational databases for personal computers, dBase. After creating the the personal database market of the late 1970s and 1980s, it dominated the market for years and was one of the three major applications of the 1980s.
The trifecta of Lotus 1-2-3 (spreadsheets), WordPerfect (word processing), and dBase (database) was so overwhelmingly dominant that most PC owners had at least one of them, and many had all three. However today, dBase is almost entirely forgotten, and of the people that do remember it, few know that it actually still exists today as a modern, (somewhat) updated product.
In the late 1970s, Wayne Ratliff was a programmer for the Martin Marietta Corporation, then working under contract for the Jet Propulsion Laboratory. Ratliff liked to bet in football pools, and decided that he needed an edge in determining how to place his bets with the greatest chance of success.
In another interview Ratliff stated “dBASE started, oddly enough, from football games. I was in a football pool where you picked the winner and then a point spread. I’ve never known that much about football. It was the motivation to win, rather than the game itself, that interested me. I thought that if I devoutly applied myself to the mathematical process, I could win.
The way to do that was to look at all the statistics. Every Monday morning the newspaper publishes all the statistics for the weekend games--it takes up at least a double page. About four or five weeks into the season, I had an entire room completely layered with newspaper! I was trying to figure out how to pick a winner by going from paper to paper, a horrible process, and I decided it was too much to handle without a computer.”
Attempting to track and calculate a wide variety of football statistics for all games of interest that were played on any given weekend was simply an overwhelming amount of data to handle purely via pen and paper.
In Ratliff’s words, “Four weeks into the season, my entire room had become covered with Monday morning newspapers containing the information I needed to make my final picks. I realized there must be a better way to assemble and analyze this information, so I started writing a computer program. But I wanted the program to do more than just analyze football pools. Within a week, the whole idea had grown into something very intelligent.”
And he just so happened to have one of the new personal computers, an IMSAI 80801 computer that he had assembled himself from a kit. At the time, the standard operating system for personal computers was CP/M, however Ratliff preferred an operating system called PTDOS (Processor Technology Disk Operating System).
Information on PTDOS is rather scanty, although the brief Wikipedia stub does link to two interesting resources on it. The first is the initial issue of a publication called “SOLUS News”, which came out in January of 1978, and the second is a link to a scanned five page advertisement from Processor Technology for their PTDOS equipped “Helios II Disk Memory System”.
It appears that PTDOS was a powerful operating system for the day, with a number of advantages over CP/M, especially for a power user such as Ratliff. In exchange for steeper system requirements (PTDOS needed a system equipped with a minimum of 20k of RAM, preferably more) versus CP/M, the user had access to a considerably larger command set.
Furthermore, PTDOS’s implementation of commands that were also found in CP/M tended to be more powerful. An example given is the memory saving command, which was far more powerful on PTDOS, allowing the user to save an arbitrary number of non-contiguous memory areas to a file.
PTDOS also had powerful file handling tools, enabling a user to set one of seven attributes to a given file, which could for example keep it from being read or written to. CP/M had no file protection at all, and relied far more heavily on the user to manage things.
Finally, PTDOS’s file handling (basically everything in PTDOS was handled as a file) enabled a somewhat basic version of Unix’s “pipelines”. CP/M did have a version of this as well, but it was far more rudimentary.
All in all, PTDOS was an elegant operating system for the era, that put a lot of power in the hands of an experienced user like Ratliff, and provided a sturdy basis for developing powerful applications.
Its also worth noting that Ratliff’s IMSAI 8080 was the same model of computer that Matthew Broderick's character in the movie WarGames used to talk to WOPR.
Although the IMSAI 8080 was somewhat dated by the time the movie came out in 1983, it was still a decently powerful system in the late 1970s, basically the pinnacle of what the buggy Altair 8800 (which it was a clone of) could have been.
This is all largely irrelevant to the story of dBASE of course, I just find it interesting.
According to a fascinating interview that Ratliff did with PC Mag in February of 1984, he started developing dBase (albeit not under that name) in January of 1978. He had decided to utilize his programming skills and IMSAI 8080 to program a database that he could feed various statistics into, track them, and have the program spit out the best possible bet.
And what statistics was Ratliff interested in initially tracking? Football.
One other story about dBase’s inception goes that it came about because Ratliff was interested in artificial intelligence (as an outgrowth of work going on at JPL on space probes) and wanted to build a database that could be used to drive a robot’s actions. This is what Popular Computing stated in an article on the history of dBase that ran in their February 1983 issue.2
A few moments of thought makes it clear that it is pretty unlikely, even if we didn’t have Ratliff’s own words confirming that he started out wanting a better way of tracking football statistics. An well-regarded clone of the pioneering Altair, the IMSAI was a sturdy and rugged machine but one that was totally inadequate for something like running a relational database in real time to control a robot.
Ratliff’s goal was to create an actual relational database, something that was quite ambitious for a personal computer of that era, especially one with the IMSAI’s limited specs.
I do not know what Ratliff’s IMSAI was set up with, but in theory it may have had as little as 20k (PTDOS’s minimum requirement) of RAM and certainly no more than 64k. Ratliff once mentioned that his original IMSAI build had only 1k of RAM (which was still four times what the initial Altair had shipped with).
Unsurprisingly, he had significantly upgraded it (and probably everything else), spending a total of six thousand dollars (roughly thirty-two thousand dollars today) when all was said and done.3
Given that the minimum specs for the database when it was released required 36k of RAM, it’s probably safe to assume that Ratliff had either 48k or 64k of RAM in his IMSAI. He also was solely working in 8080 assembler language, a necessity given the tight hardware constraints he was working under.
Ratliff wasn’t working completely from scratch however, as he decided to use the features and language of the public domain database JPLDIS as the basis for his new database.
JPLDIS ran on mainframes, and was used at the JPL(hence the JPL in the name), and thus Ratliff was quite familiar with it. Make a mental note of the whole “public domain database” thing because it will become relevant down the road.
Vulcan
Ratliff worked on the program throughout 1978 and 1979, and eventually realized that his database might have commercial potential. He duly christened it Vulcan after Spock’s home planet and took out an ad in the October 1979 issue of Byte magazine. By this point Vulcan could run under both PTDOS or the far more common CP/M from Gary Kildall’s Digital Research.
In its initial form and features, Vulcan implemented a lot of what JPLDIS possessed, but I’m not sure I agree with Robert Cringely’s4 take on it: “Some have claimed that Ratliff wrote JPLDIS, but the truth is that he only wrote Vulcan, which had a subset of JPLDIS features combined with a full-screen interface, allowing users to seek and sort data by filling out an on-screen form rather than typing a list of cryptic commands.”
While it’s true that Vulcan took a lot of features from JPLDIS, and Ratliff freely admitted this, it took an enormous amount of time, effort, creativity, and just plain hard work for Ratliff to program Vulcan.
He had to come up with an entirely new interface, figure out which features he wanted to keep from JPLDIS, and which ones he needed to create, and then write all of the code to implement those features and build the program. Oh and do it all in 8080 assembler to boot.
When Ratliff was asked which features of Vulcan came from JPLDIS, he responded that5 “Some of the most basic commands, like STORE, DISPLAY, and LIST are directly from DIS. However all of the commands that deal with the full-screen display are beyond DIS, as are B-TREE and other indexing commands.”
Additionally, the finished product needed to run not on a mainframe but in the cramped confines of the first generation of personal computers. The fact that Vulcan was based on a public domain database would normally be purely an academic question, except for the fact that a few years down the road, this fact became critically important to the story of dBase.
More on that later.
A quick aside on price: Merrill Chapman’s entertaining book In Search of Stupidity states that Ratliff originally sold Vulcan for the rather shockingly low price of 50 dollars.
However the ad in Byte states that Vulcan was 490 dollars, which matches what at least one other source I consulted, From Airline Reservations to Sonic the Hedgehog6, states the price was. It's entirely possible, and even likely, that Ratliff had been previously selling it for fifty dollars, however I have not been able to find definitive proof of that.
Fifty dollars was an incredibly low price for something as powerful as Vulcan was, and it seems more likely that it started out at 490 dollars from the start. It’s also possible that fifty dollars was the initial cost of it, before Ratliff quickly realized that the market for such a powerful database would happily pay ten times as much as the original listing price.
Alternatively, he may have found out that he needed to sell the product for a much higher price in order for it to be taken seriously and thus sell more copies.
Among other features, the ad touted Vulcan’s “38 powerful, easy to learn, English-like commands to manipulate field, records, fields, and scratch-pad variables”, as well as the fact that it was programmed entirely in assembly to make it as optimized as possible.
This last bit was a key feature of Vulcan, as running a database on the slow consumer hardware of 1979 meant that every little bit of optimization was badly needed. And yes, all applications from this era would be affected to some degree or other by the slow processors and limited memory of the day, but a database would arguably be one of the most demanding productivity applications available for personal computers.
Vulcan also required a CP/M or PTDOS computer with at least one disk drive and 36k of RAM.
In the July 1980 issue of Byte, Jerry Pournelle favorably called out the program for its power, while also slamming it for its poor documentation, saying: “Vulcan is a program that falls into a category I call "infuriatingly excellent"; that means it does everything you'd like it to, and perhaps a lot more, but the documentation is plain lousy. We find Vulcan worth the effort, because it is fast, and comprehensive, and allows you to change the field structure of the database at will, or create new data bases<sic> selectively out of the master; but we do a lot of pounding on the table and screaming in rage at the documentation.”
None of this is surprising in light of the fact that Ratliff was running everything by himself while still working full time for Martin Marietta. Writing good documentation for something as complex as a relational database is no easy task, let alone doing it while trying to juggle all the other aspects of running a growing business on top of working a full time job.
The initial response to Vulcan was large enough that Ratliff was running himself ragged trying to keep up with it all by himself, and he was apparently seriously considering just exiting the software business entirely.
In his words7, “I was still working at JPL, coming home at night and trying to run my business, making software changes, responding to inquiries from Byte’s readers, handling correspondence and telephone calls, and also shipping the product. It was all a one-man show.”
Since Ratliff did not have a disk duplicator, every sale required him to manually copy Vulcan from one disk drive to a second disk drive, one at a time.
The load was simply getting too much for Ratliff, who was burning himself out trying to hold it all together by himself. Things came to head in mid-1980s, with Ratliff saying8 “I really ran out of steam…In the summer of 1980, I decided to quit advertising Vulcan and let it drop off to nothing. I would continue to support all the people who had purchased it, but I wasn’t going to aggressively go out to find any new buyers.”
To be clear, Ratliff wasn’t planning on stopping work on Vulcan, he simply wanted to be able to just focus on developing it further and stop trying to also juggle marketing and sales. To this end, he started trying to find someone to take over all marketing for him.
Although in the burgeoning world of 1980 software sales, this wasn’t exactly a simple task. According to Ratliff, he started out by talking to a Seattle professor about marketing, before meeting a pair of Hals. Specifically, Hal Lashlee and Hal Pawluk.
Lashlee was the cofounder of Software Plus, along with George Tate. Hal Pawluk did not work for Software Plus directly, but rather was in charge of Software Plus’s marketing through the advertising agency he worked for.
A quick word on this latter fact.
According to Ratliff, Pawluk worked for an ad agency called Abert, Newhoff & Burr, however Pawluk’s own LinkedIn account says that after working for Chiat/Day from 1968 to 1970, he founded Pawluk Advertising Inc in 1974 and was its creative director, overseeing Software Plus’s account.
I also found a 1990 Los Angeles Times article that said that Abert, Newhoff & Burr had gone out of business in February of 1990, after seven years, meaning the company was founded well after Software Plus/Ashton-Tate was already well established.
Since Abert, Newhoff & Burr did handle some of Software Plus/Ashton Tate’s business in the early 1980s, in combination with other ad agencies, it's easy to see how some confusion could arise.
Anyhow, after seeing what Software Plus had to offer, Ratliff was impressed and very willing to license Vulcan to them, saying9 “They were selling discount software and already had several small software businesses. They were incorporated, had telephones, and computers.”
In the free-and-easy software world of the day, the fact that Software Plus was a formal business with a legal structure, business telephones, and computerized record keeping (of some sort) put it a significant step above a lot of the competition.
However, although Software Plus looked good to Ratliff, it was apparently struggling quite a bit to keep its head above the water and both Lashlee and Tate were looking around for a hit product.
Prior to founding Software Plus with Lashlee, George Tate had been a stereo repairman who had excitedly purchased an Altair in the mid-1970s. In common with many early purchasers of the pioneering Altair, he had been forced to put it together himself, after which he realized that the only thing he knew how to do with it was…turn it on10.
However, given how difficult a task merely assembling an Altair was, Tate’s success pointed to the possession of heretofore untapped abilities, and he soon became an expert on computers, working as a freelance computer repairman. He then worked as a sales manager for a company that sold terminals, before teaming up with his friend Hal Lashlee to found Software Plus.
Both Tate and Ashlee saw enormous potential in Vulcan, and believed that it could turn Software Plus from a flailing company into a successful one. They had no idea just how right they were and how successful their turnaround as a company was going to be.
Ashton-Tate and dBase II
Since Ratliff still wanted to keep developing Vulcan, he had no interest in selling the rights to it at this point. Hence Software Plus initially did not buy Vulcan, rather they secured the exclusive distribution rights to it and paid Ratliff royalties on each copy sold. That was step one of the turnaround plan.
Step two was to rename the company to something less generic than “Software Plus”. Since George Tate and Hal Lashlee were the two partners, they naturally decided to go with a new business name that combined their last names, and thus Lashlee-Tate was born.
Actually I‘m just kidding, they went with the name Ashton-Tate. It's easy to see where “Tate'' came from, but where exactly did “Ashton” come from?
Nobody knows for sure, inside of the company it was apparently generally believed that it was picked because it sounded British, however In Search of Stupidity points out that Tate did have a parrot named Ashton around this time. I’m rather curious what Lashlee thought of all this, but have not been able to find any source that mentions it.
The admittedly excellent new name was the brainchild of Pawluk, who on his LinkedIn has a bullet point saying that he “Named the company and convincingly positioned it as being much more than the garage-shop operation it literally was.”
Having secured the rights to Vulcan, and renamed the company into something suitably high-brow sounding, the final step in Ashton-Tate’s turnaround and rebranding was to pick a new name for Vulcan, as it didn’t take much of a knowledge of copyright and trademark to realize that Paramount may have a few words to say about using a Star Trek name without permission.
Possibly Ashton-Tate had access to better lawyers than IBM possessed fifteen years later, when IBM decided to use the name “Warp” for OS/2 and got into serious trouble with Paramount for doing so…but that’s a different story.
One other mildly entertaining note: a book on software that Time-Life published in 1985 doesn’t mention Paramount and Star Trek, it just says11 “Another company already had a claim on the Vulcan name, so the partners decided to call the product something else.”
Or maybe Paramount and Star Trek didn’t enter into it at all, and Software Plus just got lucky. In an interview Ratliff gave to PC Mag, he stated that the name Vulcan was already taken by an operating system created by Harris Computers, and that was why they needed to change the name.
So it's also very possible that nobody was even thinking about the possibility of trouble with Paramount at this point…but it still seems like somebody must have realized the potential for trouble down the road if they kept the name. Or maybe they just got lucky in a way that IBM didn’t with OS/2.
Vulcan was duly rechristened as dBase II, as a way of making it seem like it was a mature product as opposed to still being basically the original release from Ratliff.
This name was proposed by Hal Pawluk in his role as head of Ashton-Tate’s advertising, with one source 12saying that Pawluk “thought it had a nice high-tech ring, and he also liked its none-too-subtle implication that the software was a newer–and presumably improved–version of a predecessor dBASE.”
And Ratliff is very generous with his praise to Pawluk with coming up with the name, saying13 “I really think a large part of dBASE II’s success is due to Hal Pawluk’s advertising genius. I had thought of the name a long time earlier, but I thought it sounded too close to “debasing.” So I dismissed it. Hal’s stroke of genius was the small “d,” which has really caught on. There’s something about the ‘d’ that makes the program memorable and usable.”
With a spiffy new company name and a spiffier new product name, Ashton-Tate then took out their first ad for dBase II in the January 1981 edition of Byte.
This full page ad (written by Hal Pawluk himself) compared dBase against bilge pumps, and solemnly promised that while bilge pumps sucked, dBase didn’t.
And you could own dBase II for the low, low price of 700 dollars. In spite of the change, Ratliff continued to work full time for Martin-Marrietta until 1982, working on improving dBase II in his spare time, as required14 by his contract with Ashton-Tate.
Although at this point dBase still apparently only ran on CP/M machines (and the increasingly irrelevant PTDOS), it was quickly ported to DOS and was one of the few major initial programs available for the IBM PC when it launched in 1981, and that was what drove its sale into the stratosphere.
Ashton-Tate would eventually rocket to annual sales in excess of 100 million dollars by 1985, helped along by lavish spending on marketing that reached around one-third15 of its total income.
This growth was primarily driven by dBase II, with it driving over 80 percent16 of Ashton-Tate’s total revenues by the mid-1980s. Its eventual successors, dBase III and III Plus, did sell well upon release but took time to build sales momentum when compared to the overwhelming success of dBase II.
Its also worth noting that Ashton-Tate was very much a marketing driven company first and foremost, not a software development company. According to Personal Computing, as of 1989 Ashton-Tate had never put more than a relatively meager ten percent of its revenue into research and development.
They mostly focused on fancy packaging and slick advertising, with Personal Computing sniffing in 1989 that “Ashton-Tate has always concentrated more on acquiring products than designing its own”.17
Ashton-Tate did see some success with a program called Framework, an integrated everything-but-the-kitchen-sink application that is beyond the scope of this article, but was never really able to diversify away from being primarily a dBase company.
Although the extent of just how relational dBase actually was apparently caused some arguments amongst database purists18, it had become essentially synonymous with the term “relational database” in the 1980s.
In May of 1983, the dBase II Runtime was released. This application enabled dBase developers to create a standalone dBase database that could be packaged and sold as a single application.
Ashton-Tate charged a hefty fee for their run-time product, but it enabled a developer to use dBase to create and sell applications without Ashton-Tate seeing any additional money. Creating run-time applications wasn’t a feature that was unique to dBase of course, as most other relational databases of the era generally had the same ability.
Microsoft would even offer a run-time version of Windows 1, 2, and 2.1 for software applications, enabling programs such as PageMaker to run under Windows even if the user didn’t have it installed. Granted, this was pretty much entirely an effort to increase Windows’ meager market share, and the run-time was dropped when it became clear that Windows 3.0 was going to be very successful.
Today with the rise of Software-as-a-service such a feature is increasingly rare of course, as companies chase the dream of permanent recurring revenue.
For example, Claris removed the ability to create runtimes from their FileMaker relational database in 2020, as part of their continued efforts to keep FileMaker a boutique product that comparatively few people use. Not that that has anything to do with this article’s topic, but I’m mildly salty about it.
In 1983, Ashton-Tate went ahead and purchased the full rights to dBase, bringing Ratliff on board as a vice-president and head of dBase III development, and putting 24 programmers under him. Its worth noting that there may have been some shenanigans involved with this, with Ratliff claiming in 1989 that Ashton-Tate had quietly hired someone to clone dBase in order to put pressure on him to sell out.19
By 1984 dBase had reached sales of over 200,000 units, which is even more impressive when one considers how comparatively small the personal computer market was back then. These sales figures propelled Ashton-Tate to sales of 40 million dollars that year, with the company growing to 350 employees as well.
dBase III
dBase III was released in June of 1984 , with a major upgrade, dBase III Plus, hitting the market in December of 1985. dBase Plus offered a number of new features, most significantly a new interface called Assist, that allowed users to tap into quite a bit of dBase III’s power purely through pulldown menus.
Accordingly, one ad for dBase III Plus boasted that users “can build complex queries just by selecting from the dBASE III PLUS pull down menus.” This was probably quite helpful for dBase users, especially ones who were not developers.
There was also a new feature called Application Generator that apparently sought to make it easier and faster for novice developers to more easily create databases, although serious development still of course required working in dBase’s programming language.
With its improved user friendliness and faster speeds, dBase III Plus seems to have been by far the most successful version of dBase. It not only gained a dominant market share of both dBase users and the database market as a whole, but it also had a surprisingly lengthy life as successive versions of dBase that were meant to replace it, struggled for a variety of reasons.
On August 14th 1984, at age 40 Tate unexpectedly died from a heart attack, and his second-in-command Ed Esber took over as CEO. Or in Robert Cringely’s more colorful phrasing20, “George Tate snorted one line of cocaine too many and died of a heart attack at his desk.”
Ed Esber was a marketing guy, hired from VisiCorp in 1984 as the Executive Vice President for worldwide marketing of dBase and presumably anything else Ashton-Tate was selling worldwide (Framework?).
Cringely’s book Accidental Empires says that Esber had only been in his role for a few weeks when Tate passed away, and dismisses him as21 “…a marketer, not a technologist, and except for the vacuum created by Tate’s sudden death probably would not have been considered for the jobs of president, chairman, and CEO that fell to him.”
You might ask where Lashlee was in all of this, and honestly, I am not sure. According to a January 1986 article in the Los Angeles Time, Lashlee “hasn’t been involved in day-to-day operations of the computer software producer since 1982”, which doesn’t really explain why Esber took over and not him.
Perhaps he just wasn’t interested, or didn’t have enough control to take over. Lashlee would leave Ashton-Tate entirely in January of 1986, selling off the bulk of his Ashton-Tate stock and leaving the board of directors as well. A 1987 article in the Los Angeles Times stated that Lashlee had been given the name “the phantom” by friends and was difficult to reach for any sort of comment.
That same article did state that “Former associates say the founder left because he thought Esber was overpaying for acquisitions. Sources say Lashlee also opposed Esber’s decision to move into what some wags have dubbed “Ed’s Edifice”--Ashton-Tate’s starkly modern and lavishly furnished office tower near the intersection of the Harbor and San Diego freeways.”
Freed from the restraint of either of the company’s founders Esber decided to restructure the way Ashton-Tate had been operating previously, moving it from Tate’s more loose free flowing management style, to a more MBA driven and professional style.
And he then, whether on his own or in combination with Ashton-Tate’s board of directors, apparently decided to pick a war with dBase’s large and rapidly growing development community. This fateful decision would play a key role in the eventual destruction of Ashton-Tate and everything that had been built up over the past few years.
Let’s set the groundwork a bit for what was going on. With an almost seventy percent share of the market by the mid-1980s, dBase basically owned the relational database market for personal computers. Thanks to domination, a thriving ecosystem had sprung up around dBase, as developers and small companies worked to extend dBase’s capabilities in a plethora of ways.
There were everything from plugins that extended dBase’s capabilities or fixed bugs, together with books, training seminars, and an army of thousands of developers who built, maintained, and sold dBase applications (frequently run-time ones).
Sometimes they were maintaining and extending an existing dBase product, sometimes they were small or even single programmer firms that were selling an application made in dBase to a particular market or vertical segment.
According to one source22: “By 1984, about 1,800 companies had signed up for Ashton-Tate’s support program for developing dBase II templates for vertical markets, and the Application Junction catalog for 1985 listed more than 1,700 complementary products.”
This ecosystem, the source of much of dBase’s strength and market share, began to be looked at as a problem by Esber. According to the book In Search of Stupidity, Esber was infuriated at the number of people selling dBase applications that, thanks to the run-time product, did not directly make Ashton-Tate any money.
Since developers were able to use dBase as a full development environment, and then create a full standalone application that just happened to be a dBase database application internally, the end user didn’t even necessarily realize that they were using dBase at all.
Sure developers wishing to create standalone dBase applications had to purchase the dBase run-time compiler from Ashton-Tate, but that was the only money that Ashton-Tate would see.
One consequence of Ashton-Tate’s frustration with this was the fact that the dBase run-time product was priced very expensively, with the company seeking to make up for (at least some) of what it viewed as lost revenue, by charging through the nose for the compiler.
And then to add insult to injury…competing applications sprang up that could create run-time versions of dBase databases on their own, no Ashton-Tate compiler needed.
A number of enterprising developers saw a major opportunity and came out with their own compilers that could take a dBase database and package it up into an executable that didn’t require the dBase run-time product at all.
Some of these dBase compilers were dBXL, QuickSilver, Arago, Clipper and Force, with Clipper probably being the most successful and best remembered.
Because these compilers were sold well below what Ashton-Tate’s dBase compiler retailed for, sales of the run-time version of dBase apparently fell off a cliff, something that made Esber even madder. And let’s be fair here, watching one of your core products suddenly collapse in sales due to a bunch of copycats…it's perfectly understandable why that would be upsetting.
However, since these clones were legally made, and had arisen due to the high price Ashton-Tate was charging for its own runtime product, a better way of dealing with things would probably have been to either drastically drop the price of the dBase runtime product, or even just incorporate it into the main version of dBase itself.
Sure that would have made Ashton-Tate lose out on sales of the standalone runtime, but it would have crippled, possibly even killed, the competing runtime clones and given overall sales a boost.
Instead of doing this or something like it however, Esber instead started threatening various members of the dBase community that he felt were threatening Ashton-Tate’s control of the dBase market…with lawsuits.
Esber was very vague as to what exactly constituted infringement, and his legal threats continued to make the wider dBase community extremely upset with him. Then Esber ratcheted things up a notch, with 1987 bringing a full scale assault on the dBase community.
His first target was a group of third party developers that were working to create what was called a “standard dBase”23 specification. They were threatened with a lawsuit for infringement if they didn’t cease work immediately. They complied with the letter of the law, and instead began working on a standard specification for what they then termed “xBase”, basically the same thing with just a fractionally different name.
Esber then moved on to attacking a new front, stating that the dBase programming language, the language that dBase developers used to create dBase database, was proprietary, and required Ashton-Tate’s permission to use. He was then quoted as referring to the third party companies in the dBase ecosystem as “parasites”24.
This would be comparable to Microsoft deciding that Visual Basic was proprietary, and nobody could use it or develop applications with it without Microsoft’s explicit permission, especially including Microsoft Access development.
Even Microsoft has never gone this far, and it is highly doubtful that Microsoft Access would have gained the massive market share that it did, had Microsoft chosen to go down this route. This was a lesson that Ashton-Tate was going to have to painfully learn.
Esber then took this behavior even further, by starting to mail out cease-and-desist letters to basically anybody who used the word “dBase” in their training materials. Some of the top dBase consultants received these letters, ones with significant followings.
Again, imagine Microsoft saying that nobody could put on a Microsoft Access training seminar that used the word “Access” in any form of printed or on-screen material.
Ridiculous right?
Then Esber and Ashton-Tate took the unprecedented step of attempting to claim sole ownership of the dBase language.
Whatever Esber’s actual intentions, the dBase community took this as Esber attempting to make it illegal for anybody to actually sell any dBase applications, presumably in an attempt to make it so that only internal developers at companies that used dBase would be allowed.
External developers, especially including ones who sold standalone dBase applications; would presumably be frozen out.
Not to hammer this point home with, you know, the same hammer I’ve already whacked away, but let’s imagine Microsoft telling the entire Access community that only internal Access applications were legally allowed and no run-time Access applications would be allowed.
Sure at this point Access is probably mostly known for clunky legacy internal applications that are still somehow being used decades after being written…but I digress.
Esber also got up in front of a Software Publishing Association conference and shouted “make my day” at the assembled developers, before apparently going on to threaten them and anyone else who was thinking about making a dBase compatible product.
Behavior such as this was not exactly endearing Esber and Ashton-Tate to anybody.
Now then, let’s take a look at Ed Esber’s side of the story, since if I am going to levy this much criticism at him, it's only fair to let his side be told as well.
Esber’s website, edesber.com, has a seven page article called “dBase Language Lawsuit Chronology”, that gives his perspective on his actions. According to it, Esber was not directing his ire at the dBase developers themselves, rather he was upset with the companies and developers that were taking dBase itself and producing clones of it such as FoxPro.
The article states that “Esber was upset with the companies that cloned dBASE products, but was always supportive of the third-party developers who he viewed as an important part of the dBASE ecosystem. He did not believe nor support companies that cloned dBASE and leveraged the millions of dollars his shareholders had paid to market dBASE.”
Taking Esber’s statement at face value, while I can understand much of his frustration with people cloning the dBase platform and language, the main reason such competitors could exist and thrive was probably largely due to dBase’s high cost and the increasing perception that Ashton-Tate was trying to find ways to undercut and sabotage third party dBase developers.
And again, even if Esber wasn’t actually aiming his ire at third party dBase developers, that is not how it was taken.
When Microsoft Access came along in the early 1990s, it only took a few years to become almost ubiquitous thanks to Microsoft’s affordable pricing, its eventual inclusion with Office (Office being Microsoft's cleverest product as it attacked multiple competing applications simultaneously) and the fact that it was a genuinely good program.
Plus Microsoft didn't give off vibes of hostility towards Access developers. I’m not an Access person, but I can respect Microsoft's very clever positioning, pricing, and peddling of it, ensuring that it muscled aside pretty much all of its competitors and never had problems with Access clones.
By the late 1980s Ed Esber had become a deeply radioactive man to the software industry, or at least the database corner of it.
Merrill Chapman, who actually worked for Ashton-Tate during this time, quotes25 one infuriated dBase developer as telling him that “Ed Esber is a diseased amoeboid life form with the intelligence of a sick protozoa”, a rather umm…memorable way of putting into words just exactly how a large percentage of the dBase development community was apparently feeling towards Esber.
Again, it doesn’t really matter what Esber’s intentions actually were, what matters is how his actions were interpreted by the dBase community. However I encourage you to go over to his website, edesber.com and read his take on what happened.
You may not agree with it, and I certainly don’t agree with how he handled things, but it's always important to get both sides of a story whenever possible. And I would definitely say that his frustrations with dBase getting cannibalized by applications that cloned the dBase platform, are very understandable.
IBM experienced much of the same frustrations with the explosion in PC compatibles, from companies such as Compaq that cloned the IBM PC, bought a license for MS-DOS, and proceeded to happily demolish IBM’s market share.
However valid the frustrations are, the response needs to take into account the realities of the situation, see things as they are, not as they are wished to be.
In Ashton-Tate’s case, I bet a lot of the problem would have been mitigated by simply dropping the price of dBase, including the run-time compiler with every install, and working to grow the platform as much as possible by growing the market.
The goal being to make it extremely easy and affordable to develop applications using dBase, for as many people and companies as possible, as opposed to fighting with the existing base of dBase developers and spurring the development of dBase clones.
But so long as Ashton-Tate was in charge of dBase, this probably wasn’t going to happen for one reason or another. It also would have helped if dBase had put more effort into developing less buggy future versions of dBase…as we are about to see.
Because if a product is already struggling with enraging its user base…and then its user base is expected to fork over money for a new version of the product…and that product has serious issues…anyhow let’s talk about dBase IV.
Actually before discussing the giant pile of bugs that was the initial release of dBase IV, let’s briefly discuss dBase Mac.
dBase Mac
dBase’s initial absence from the Macintosh was fairly understandable. The 1984 Macintosh was crippled by lack of RAM (only 128k), limiting its ability to effectively run RAM-intensive applications such as a relational database. Its powerful Motorola 68k CPU on the other hand, was quite capable of handling the demands of a relational database, it just needed to be fed with enough RAM.
However, not only was the Macintosh was not really viewed as a business machine, but it also required developers to get to grips with an entirely new paradigm, the so-called WIMP (Windows, Icons, Menus, Pointer) as well as master the Macintosh Toolbox.
Unlike with a PC running DOS, you could not program to the bare metal, you had to work within the Macintosh’s operating system and APIs, adding a significant layer of complexity to developing for it.
So far as the Macintosh went however, the RAM limitation was quickly done away with, as an upgraded Macintosh with 512k of RAM (the so-called “Fat Mac”) was released in September of 1986. It was clear that Apple was working to make the Macintosh more business friendly, and Ashton-Tate really should have a version of dBase for it.
Rather than diverting developer focus away from its bread-and-butter DOS based platform, Ashton-Tate instead looked for a product that it could just buy, eventually focusing on a still-in-development Macintosh database from a small Salt Lake City based company called Digicorp.
Digicorp had been working on a relational database for the Macintosh, but had not given it a name yet (although it undoubtedly had some sort of codename or development name). The database was being developed by a mere three programmers, one of whom had previously been the company president, Mike Rossetti.
In summer of 1985, Ashton-Tate purchased the marketing rights to this database, paying Digicorp 150,000 dollars advance against future royalties, committing to paying 35,000 dollars a year for the next four years, and agreeing to a 7.5 percent royalty on sales.26
Ashton-Tate also had the right to buy the product outright for 1.75 million dollars after a year.27 According to InfoWorld, “Esber says the acquisition of the Mac database product “fits nicely” with Ashton-Tate’s overall corporate strategy.”28
As usual for Ashton-Tate, development dragged on far longer than anticipated. Although dBase for the Macintosh was originally said to be coming in late 1985, it doesn’t seem to have had a commercial release out in all of 1986.
However, developers were definitely using it at some point in 1986, with a September 1986 InfoWorld article saying that “many database developers are turning to Ashton-Tate’s dBase Mac for writing applications, saying the program's ease of use will speed development.”29
In 1987, Ashton-Tate finally released the database, rather appropriately calling it dBase Mac. To be clear though, this was still not actually a port of the main dBase application, but rather an entirely different application altogether that simply carried the dBase branding and name.
Its worth mentioning that there is some confusion over when dBase Mac was actually released, since a September 1986 InfoWorld article states that developers were already developing new dBase applications using dBase Mac.30
However a November 1987 article in MacUser (a review of relational database Fourth Dimension) explicitly: “[a]t the time this review was being written, Ashton-Tate’s dBase Mac was still not a released product.”31
My assumption is that in 1986 Ashton-Tate (or Digicorp) probably seeded beta versions of the database to various developers, hoping to jumpstart the dBase Macintosh ecosystem as well as get valuable feedback.
dBase Mac had its own programming language and could not read standard dBase databases, although it could read dBase DOS data files.32 The language itself was proprietary, but fairly full featured.
In MacUser’s review of dBase Mac, they were fairly favorable toward the language, saying it was “a fully structured language, including repeat and while commands for iteration and if/then/else and case for selection. The language also includes commands for drawing dialog boxes and alerts and for managing events in those objects.”33
They did fault it for being “less Pascal-like” than 4th Dimension’s built in language however.34
dBase Mac had an entirely mouse-based interface that conformed to the Macintosh’s UX requirements, and packed a lot of power, although it was judged inferior to some of the competition, such as 4th Dimension.
Relationships were handled by a very intuitive graphical view called the Database Structure window, with the user dragging lines from fields in one table to another table’s field in order to relate the two tables.
The initial release of dBase Mac could not create runtime files, meaning every user needed their own licensed copy of dBase Mac. Each version cost 495 dollars, and came on a single 800k floppy. Users needed a minimum of a Macintosh Plus and a hard drive in order to run it.
The excellent Macintosh Plus had come along in January of 1986, and came standard with 1 MB of RAM, expandable to a whopping 4 MB. It was an excellent office computer, and made a solid platform for dBase Mac.
It‘s fair to point out though that matter the Macintosh configuration, dBase Mac was apparently somewhat slow, although it was a bit faster than rival 4th Dimension.
But the Macintosh version was never more than a sideshow, and would quickly be abandoned, sold off to another company in 1990 where it quickly vanished into obscurity.
Ashton-Tate’s major focus was on the next major version of dBase, dBase IV 1.0. Unfortunately development was not going well.
dBase IV
dBase IV’s development had turned into a major, major headache, with seventy-five developers working on it, producing 450,000 lines of code in the end. The chaos that this was creating inside of Ashton-Tate was significant, as more and more of the company’s resources were sucked into the dBase IV black hole, with the project dragging on well past its estimated delivery date.
Esber apparently told Ratliff, who was still overseeing development at Ashton-Tate and was very much respected by the community…that he was at the same level as the company janitors35 when it came to value.
It also bears mentioning that according to an article in the Los Angeles Times in 1987, what Esber said was that Ratliff was “no more important to the success of the company than the guy on the loading dock who throws the boxes onto the trucks,”.36 So basically Ratliff was told that he was no more valuable than janitor or a warehouse worker.
In fairness to Esber, what he may have been trying to communicate was that everyone was equally valuable at Ashton-Tate. However, that was definitely not how it was taken by…pretty much everybody.
It also seems that Ratliff was already discontented with how things were going in general and with dBase IV development in particular, and thus he shortly afterward left the company, taking with him most of whatever goodwill remained in the community towards Ashton-Tate.
And then Ratliff started working for a small software company called Migent Corp, which boasted several dozen former Ashton-Tate employees, including Ashton-Tate’s former vice-president of sales. Ratliff was working to develop a new database program that would presumably compete with dBase, to be called Emerald Bay and it was eventually released.
However prior to its release…since Ratliff had left Ashton-Tate and was working for a competitor that employed a number of other former Ashton-Tate employees…a lawsuit was of course filed against him, Migent, and other former Ashton-Tate employees by Esber and Ashton-Tate. You can read a bit more about that in this 1987 article from the Los Angeles Times.
So now the two founders of Ashton-Tate were no longer involved, and the developer of Ashton-Tate’s bread-and-butter application was not only gone, but Ashton-Tate was suing him. And in the midst of all of this turmoil, dBase IV was struggling to finish its turbulent development.
And speaking of dBase IV, it was scheduled to come out in 1988, and if it was an excellent release there was a good chance that the wider dBase community would swallow their anger at Esber and Ashton-Tate, and find a way to keep moving forward with the platform that so many people’s livelihoods depend on.
After all, with tens of thousands of developers and a massive install base, dBase still dominated the relational database industry and there would surely be a way to keep using it as the community wished, even if it was in spite of Esber and Ashton-Tate’s best efforts.
dBase IV also was going to natively include SQL support for the first time, a major feature that could prove a significant selling point. And by SQL support, I mean that dBase IV appears to have sort of…half added support for it.
In the words of one article in Byte, “As for this year's hot database topic, dBASE IV sort of does SQL. Well, actually, dBASE IV emulates SQL using dBASE data tables. It lets you use a set of SQL commands inside dBASE when you SET SQL ON. When you do this, you deactivate dBASE IV commands that are in conflict with SQL.”
If I am reading this correctly, it means that dBase IV took SQL commands mixed in with normal dBase scripting and then internally translated them to native dBase commands, while ignoring any native dBase commands that somehow conflicted with SQL.
Given how hot SQL was at this time, adding the bullet point of SQL compatibility to dBase IV would presumably be a big selling point. One that would not only please the existing users that wanted a more powerful program, but one that would also bring in new developers who already knew SQL and thus presumably would get a leg up on getting up to speed with dBase IV.
Of course it all depended on just how good dBase IV was going to be. Given that I already used the words “bug-ridden”, you can probably already guess how good dBase IV was when it hit store shelves.
Esber by this point had hired a new company president, Luther Nussbaum, who was in charge of Ashotn-Tate’s day-to-day operations while Esber remained as CEO and big brain thinker. Nussbaum was a bit of an odd choice for president of a major software company as his previous job was with a company that built diesel engines, and he was apparently far from technical.
According to Merrill Chapmen37, Nussbaum also “quickly developed a reputation within Ashton-Tate for preferring to rule by bullying and intimidation”. This is far from unknown in any industry, let alone a software one, but since Nussbaum apparently lacked the technical knowledge to know what exactly he was pushing his employees to do, and lacked Steve Jobs’ enormous charisma…it wasn’t exactly a recipe for success.
So with a technically illiterate company president and a disconnected CEO, how exactly did dBase IV fare when it was released in October of 1988?
It was a disaster. According to Chapman:38 “The product had serious memory management issues, contained plenty of bugs, and lacked promised capabilities such as an integrated compiler. In the words of dBase maven Adam Green, it “didn’t work.” The reviews were devastating and the development community howled loudly in disdain”.
Ratliff also gave an interview39 to Business Week after the bug-ridden dBase IV had staggered out the door, stating that Ashton-Tate “did not understand the software development process.”
dBase IV 1.0 also apparently had issues with some SQL queries returning the wrong results, something that seems like a rather glaring problem that should have been caught in testing, especially for such a well-anticipated feature.
Additionally, dBase IV 1.0 apparently had severe memory problems, with one later Byte article saying that “dBASE IV 1.0 ate up so much RAM that it often required extra hardware to run over a network. In some situations, each of the workstations running dBASE required an additional memory card.”
And of all the times to release a product that required significant investments in additional RAM…1988 was probably the worst time.
1988 was the year that the price of RAM, which had been steadily falling throughout the decade so far, suddenly reversed itself and soared to stratospheric levels, paired with severe shortages of certain chips, such as 256k DRAM chips.
One source I looked at stated that in July of 1988 the cost of a megabyte of RAM spiked from 199 dollars to 505 dollars…in a single month! It got so bad that “the cost of a 256k DRAM chip had surged from $2.95 at the beginning of 1988 to $12.45—a price level maintained for nearly a year.”
IBM would also learn a painful lesson in market realities when it launched the initial (and very memory hungry) release of OS/2 just in time to run headlong into the RAM shortage.
(Note from Jonathan: This article was originally published in late 2023. As I do edits on it now in mid-2026, we are smack in the middle of our own RAMpocolypse. Its hard to make an exact comparison, but I feel fairly safe in saying that RAM prices in 1988 were every bit as painful to computer users as they are today in 2026. And just like back then, at some point RAM prices will fall back to reasonable levels.)
The reasons for the RAM shortage and price increases are beyond the scope of this article, but it was a major problem in the industry for at least a year. And dBase IV landed right smack in the middle of the RAM shortage. It was certainly far from its only problem, and probably wasn’t even its worst problem, but it was one more problem added to the load it was reeling under.
After dBase IV staggered out the door, Ashton-Tate then apparently spent a few months publicly downplaying the problems. Specifically of the 105 major bugs dBase IV apparently possessed40, Ashton-Tate conceded to the existence of a mere 44.
They also started talking up a promised dBase IV version for OS/2 that would be amazing and have none of the problems that they were officially claiming weren’t actually even in dBase IV. Or words to that effect.
According to one source, Ashton-Tate didn’t even intend to fix the bugs in the DOS version of dBase IV, they simply focused all internal development on porting dBase to OS/2, which was supposed to be dBase IV 1.1.
1989 was a bloodbath for Ashton-Tate, as dBase IV was so badly damaged that sales of it collapsed and Ashton-Tate lost over 60 million dollars as tons of shipped (but not sold) retail boxes of dBase IV were returned by retailers.
And it wasn’t just dBase IV boxes being returned, large quantities of other Ashton-Tate products such as MultiMate and ChartMaster were also returned by resellers.
This happened because Ashton-Tate had apparently been engaging in channel stuffing, where retailers were heavily incentivized with generous return policies and pricing to take not just dBase, but also other applications from Ashton-Tate.
This allowed Ashton-Tate to book a lot of revenue, but this did not represent actual sales to customers (“Sell-through”).
All of this booked revenue was a time bomb waiting to go off if retailers decided that they weren’t going to be able to actually eventually sell their piles of Ashton-Tate applications and decided to return them en masse. A precipitating event such as a poorly received release of a major product…such as dBase IV, could trigger a lot of hurt.
And it did.
The fallout from the dBase IV fiasco, exacerbated by the consequences of the channel stuffing backfiring was severe, with Ashton-Tate’s board removing Esber from his position.
It did somewhat help that there were a lot of people still needing and buying dBase…they just were apparently primarily buying the older but reliable dBase III Plus41, and thus Ashton-Tate’s business as a whole didn’t collapse, but the red ink was still mounting.
Finally the Ashton-Tate’s board of directors took action, forcing out Esber and replacing him as CEO with Bill Lyons.
According to a Los Angeles Times article from May 1, 1990 ”Edward M. Esber Jr. resigned Monday as chairman and chief executive of Ashton-Tate Corp. after struggling for 18 months to rescue the Torrance software publisher from problems caused by the release of an error-riddled version of its most popular personal computer program.”
Bill Lyons was a relative newcomer to Ashton-Tate, having joined the board in October of 1988, after previously working for IBM.
The Los Angeles Times goes on to quote the new chairman of the Ashton-Tate board, Carmelo J. Santoro, who said “The board felt the company needs to be operated by a guy with a short-term, tactical mentality who can focus on the internal operations of the company. Bill is that kind of guy. . . . Ed’s strength is not operations.”
In July of 1990, a revised and overhauled version of dBase IV, version 1.1 for DOS was released that fixed the majority of problems and was easier to install than the original release as well as being a snappier program overall.
A review from Byte’s December 1990 edition was quite favorable, stating “It looks like Ashton-Tate has resolved some of dBASE 1. 0' s most glaring faults. The decreased RAM demand enhances network support and improves performance. More efficient overlay swapping translates into snappier operation, especially with larger applications. And Ashton-Tate has apparently fixed the bug that caused incorrect results from certain Structured Query Language queries. It looks like a strong product-but will it rebuild Ashton-Tate's reputation as the premier manufacturer of PC databases? Only time and an extensive user community can tell.”
The revised dBase IV also required less RAM than the initial release, 450k instead of 516k, and made use of caching commonly required data in RAM to speed up data retrieval, lessening the need to access the slow hard drives of the day.
All good things for sure, and welcome improvements.
The New York Times also covered the 1.1 launch on August 19, 1990, in an article called “The Executive Computer: Can the New dBase Solve Ashton-Tate’s Problems?”
They praised dBase IV 1.1 for fixing the worst problems from IV’s original release, saying “The good news is that the new version 1.1 appears to fix the problems that afflicted its predecessor, version 1.0. These included some obscure bugs that caused unexpected system crashes and, in the worst cases, corruption or destruction of data files.”
I also find it worthy of mention that the full boxed retail version of dBase IV 1.1 apparently weighed an astounding 13 pounds and shipped in an eye-catching bright red box.
dBase IV 1.1 turned the product into a reasonably solid database again, but the damage was quite frankly irreparable. In the words of the previously mentioned New York Times article, “The bad news for Ashton-Tate is that its delay in getting the update into users' hands eroded the broad base of support for dBASE, which at one point commanded an overwhelming share of the data base market. According to the International Data Corporation of Framingham, Mass., dBASE had 40 percent of the data base market in 1989, compared with 62.5 percent in 1985.”
Sure dBase IV sold well into the existing community, and still was the leading database overall, but rival databases were nipping at its heels. And that collapse from 62.5 down to 40 percent in only four years is pretty calamitous, as one would expect when a product loses over a third of its market.
Going forward dBase’s days of growth were well and truly over and it would never recover. dBase 1.1 was essentially the Blackberry 10 of its day, a good product that fixed the vast majority of the errors that had caused people to abandon the platform in large numbers, but wasn’t good enough to get them back from wherever they had moved on to.
And as someone who heavily used (and loved) a Blackberry Playbook in grad school, and was quite fond of the platform…I don’t use that analogy lightly. So far as DOS relational databases went, dBase IV 1.1 seems to have been a very solid release.
Adding to their woes, in December of 1990 Ashton-Tate also lost a court battle with Fox Software over Ashton-Tate’s claim to have the exclusive right to use the dBase language. Fox Software was selling a very successful dBase clone called FoxBase Plus, that was high profile enough to make them target #1 to Ashton-Tate.
Its worth noting that in a March 1989 Personal Computing article profiling Ashton-Tate, Wayne Ratliff (who was gone from Ashton-Tate by that point) told them that he was dubious about the lawsuit’s validity. Ratliff flat out stated that dBase’s programming language was originally based on JPLDIS, and thus he personally felt that the lawsuit against Fox Software was on very shaky ground.
The reason Ashton-Tate lost the court case went back to the fact that the dBase language had originally been based on the public domain JPLDIS language, and thus couldn’t be owned by Ashton-Tate.
Losing the lawsuit meant that the door was wide open for dBase clones to freely use their own implementation of dBase’s programming language, the one that millions of programmers were already familiar with.
Losing this court case further damaged Ashton-Tate, although in a rather odd postscript the judge that ruled against Ashton-Tate in December of 1990 apparently reversed his ruling the following year.
Ed Esber has a clipped article on his site that according to a handwritten date is from April 24th, 1991, that says “Judge Reconsiders Ruling on Ashton-Tate Copyright”.
This date matches a TechMonitor article I found that said “US District Judge Terry Hatter has thought better of his ruling that Ashton-Tate Corp is not entitled to claim copyright on its dBase database products. Hatter originally ruled the copyright invalid on grounds that Ashton had not disclosed prior art, but the US Register of Copyrights independently filed a declaration supporting Ashton-Tate’s position and saying the company had followed the proper copyright registration procedure. The new ruling does not affirm or deny the copyright and the Fox suit proceeds.”
A really good comment was left under the original version of this article by SEE, which I am quoting here in full.
So, to explain the judge’s ruling and self-reversal --
The judge initially ruled that because Ashton-Tate did not disclose JPLDIS, Ashton-Tate did not have a validly-registered copyright on the dBase software itself. Which would have eliminated Ashton-Tate’s legal ability to file infringement suits even against people literally copying and distributing (say) the dBase IV 1.1 disks. Throw in the 1990 state of criminal copyright infringement law (infringing software copyright was only a misdemeanor prior to 1992, and only then if it was done for financial gain), and basically the judge was throwing the dBase software (not just the dBase language) into the public domain.
And it was a clear mistake of law by the judge, who incorrectly applied patent law standards of disclosure to copyright. When you register a copyright, you do not have to disclose that your registered work is knowingly derivative of a public domain work; the Copyright Office doesn’t even ask if it is. Which is why the US Register of Copyrights got involved. So the judge reversed that ruling, and so Ashton-Tate’s registered copyrights on its specific dBase software products were not voided.
By this point however, the judge’s reversal seems to have been basically irrelevant as Borland was about to buy Ashton-Tate and the whole issue of whether Ashton-Tate could exclusively own the dBase language and platform would basically go away.
So far as I can tell, Borland had no interest in pursuing it and in fact dropped the lawsuit entirely. They may have dropped the suit somewhat unwillingly however, as according to a FoxPro history site, “after Borland acquired Ashton-Tate, the company dropped the suit under pressure from the Justice Department and promised not to file a similar suit for ten years”, clearing the way for Microsoft to acquire FoxPro in 1992.
Whether they dropped it willingly, or grudgingly, it was over and now Borland could focus its energies entirely on trying to unsnarl dBase IV, regain market share, and fight off Microsoft's upcoming Access database.
The problem was that although the updated dBase IV finally was a good product and still had a massive community, there was no real idea of where to take the product next. It was helpful that with Esber gone, a lot of the major irritations between Ashton-Tate and its community were at least minimized, but there needed to be a vision for the future of dBase, and one just didn’t exist.
Windows was taking the market by storm, and dBase still didn’t have a Windows version, being bound to the aging DOS platform. Plus, you know, Borland already had a successful and well regarded relational database, Paradox.
Microsoft, bolstered by its purchase of Fox Software and its FoxPro technology (especially Rushmore, a rapid and efficient way accessing and processing records), was prepping for the initial release of Microsoft Access in 1992.
Additionally Microsoft was also starting to really leverage its experience with creating graphical applications in Windows to make Microsoft Office a killer application bundle that provided best-of-breed Windows applications at an affordable price.
Each Office application was squarely targeted at the-then market leader.
The Rise, Fall, and Surprising Survival of WordPerfect
As the personal computer market exploded in popularity in the late 1970s, many people bought them first, and then tried to figure out what useful purpose they could possibly be used for. Early computers such as the Apple II, TRS-80, and Commodore PET were sharply limited machines, especially in comparison with their own later revisions. The differences primarily come down to the amount of available RAM, which was the major bottleneck for software.
Word was targeted at WordPerfect, Excel was aimed at Lotus 1-2-3, and soon Access would setting its sights squarely at dBase. Ashton-Tate badly needed a coordinated campaign to defend dBase’s position, plus get a new Windows version of dBase out-the-door that would maintain feature superiority over Access.
They also needed to do this while managing the threat of the Microsoft Office pricing and application juggernaut. Faced with all of these challenges, although some were of course only visible in hindsight, Ashton-Tate dithered.
As previously mentioned, in 1991 Bill Lyons somehow convinced Borland and its CEO, Philippe Kahn, to purchase Ashton-Tate for a frankly ridiculous 440 million dollars in stock.
Borland was actually a smaller company than Ashton-Tate, and as previously mentioned already had a well-regarded relational database, Paradox, so this acquisition was a bit of a head scratcher.
However it did make dBase and its future…somebody else’s problem.
dBase IV 1.5
In 1992 dBase IV version 1.5 was released to generally favorable reviews, with Compute saying42 “Still the market leader, dBASE is always a good choice. There’s a huge market of third-party books and training materials for dBASE, and it runs on every computer known to humankind. Its user interface was given a face-lift for version 1.5, but it doesn’t come close to FoxPro’s. It has great documentation, an excellent report writer, and a very good programming language. It uses memory efficiently, runs well on 286s, and will soon be doing Windows.”
Although it appears that dBase IV 1.5 still didn’t have a compiler, so run-time dBase applications still could not be created natively.
This last sentence points to the other major problem that was going to do dBase in…it was still a DOS program, not a Windows one.
By the time it released in 1992, Windows 3.0 had been on the market for two years, and Windows 3.1 had been released in April of 1992, cementing its success and making it clear that Windows, not DOS or OS/2 was going to be the operating system for most PCs.
With no Windows version, dBase was in serious trouble and Borland needed to figure out a strategy fast. They umm…didn’t really do a good job of this. And by that I mean that the next version of dBase still wasn’t targeted at Windows.
dBase IV 2.0
Borland did finally get seriously working on a new DOS release of dBase, to be creatively called version IV 2.0. This shiny new version was eventually released in March of 1993.
The 2.0 team, led by a man named Tom Burt, also finally managed to give dBase IV 2.0 the long promised compiler. InfoWorld rather bluntly phrased it as “After years of broken promises, dBase this month will finally have a compiler”, although it still was a separate 495 dollar purchase, separate from the 795 dollar cost of dBase IV 2.0 itself.
According to an ad for dBase IV 2.0 that ran in the September 6, 1993 issue of InfoWorld, the compiler could not only create executables for all versions of dBase IV databases, but was also backwards compatible with dBase III and III Plus.
dBase IV 2.0 was well received and was generally considered an all around solid product, unlike the absolute fiasco of the original dBase IV release. It was also a vastly speeded up product, with Borland proudly claiming speed increases of up to ten times over previous versions of dBase.
It did require a minimum install of at least a megabyte of protected memory, and according to an InfoWorld review, Borland recommended at least 3 megabytes of extended memory.
A new virtual memory manager also allowed dBase IV 2.0 to utilize up to 16 megabytes of memory. Fortunately RAM prices in 1993 were back to following a steady curve of price drops and increased capacity and thus the new memory requirements do not seem to have been considered an issue.
dBase 5.0
Borland then pushed ahead with a Windows version of dBase, and also switched the numbering scheme from Roman numbers to Arabic. Presumably because mixing Roman and Arabic numbers together was a very silly idea, but they still did it once with the aforementioned dBase IV 2.0.
And obviously the next step from version IV 2.0 would be dBase 5.0. I mean…I guess it does sort of make sense, since technically the previous version of dBase was version 4, just in Roman numbers. Sort of…there had after all been dBase “4” 1.0, 1.1, and 2.0.
dBase 5.0 would be the first Windows version available, but it wasn’t ready for release until August of 1994, four years after Windows 3.0 was released and two years after Windows 3.1 took the world by storm.
And Borland majorly screwed up the development of 5.0, not so much with bugs as with how development was done. Basically, Borland was well into development of dBase 5.0 for Windows while dBase IV 2.0 was being developed, however the developers were apparently struggling to get 5.0 to work correctly within the Windows GUI paradigm.
In the meantime, a small company called WordTech was working on a database for Windows called Arago. Arago made use of a virtual machine, similar to what Java would use a couple years later (not that virtual machines were anything new at the time of course).
For some reason Borland was so blown away by Arago and its ability to run on any platform that had the virtual machine, that they bought the whole company, threw away most of the existing dBase 5.0 development, and used Arago as the basis for a major reboot of dBase 5.0’s development.
The only thing salvaged from all the work already put into 5.0’s original development was…the debugger.
Now, I will say that it's a little unclear to me if there were two released versions of dBase for Windows, the original one and the one based on Arago. In Search of Stupidity says that43 “At this point, Borland had two incompatible versions of dBASE for Windows…to market and support.” which makes it sound like Borland actually released two versions of dBase for Windows.
However an article called “A personal History of dBase” that is hosted on dbase.com says “When some Borland officials heard about and first saw a prototype of Arago for Windows (demonstrated at Comdex), Borland headquarters began looking like Panic City: Borland had to buy Arago. But above all, Borland had to get those geniuses at WordTech. The easiest way to have them was to buy their employer. By doing so, Borland had two different versions of dBASE for Windows. Arago for Windows became the foundation of dBASE for Windows 5.0, released in August 1994. The only thing salvaged from the previous dBASE project was the debugger.” which makes it sound like Borland had two internal versions of dBase for Windows, but didn’t release both of them.
Looking for reviews in InfoWorld, I don’t see anything about two separate versions of dBase for Windows, I only see reviews for one Windows based dBase, and furthermore in an ad from Borland itself, only a single dBase for Windows and a single dBase for DOS are shown.
So from what I can tell, Borland only released a single version of dBase for Windows, they just had two parallel Windows dBase development projects internally for an unknown amount of time before the older one was canceled, with only its debugger surviving to be incorporated into the shipping product, which was based on the Arago acquisition.
All of this turmoil and wasted development effort meant that dBase 5.0 for Windows wasn’t released until August 1994. Presumably Borland felt that the ability to easily port dBase to multiple operating systems would be a major competitive advantage and would help them stave off the onset of Access and whatever Microsoft wound up doing with its then-recent purchase of FoxPro.
Looking at a list of other operating systems that dBase IV had wound up being ported to…yeah I am not really seeing this as a competitive advantage.
I’m sure the Sun, SPARC, Solaris, AIX, and VMS crowd were happy to have dBase available, but by the mid 1990s the action was all in Windows, with DOS rapidly going away (although it did hang on for games for a bit longer) and Apple Computer collapsing so precipitously that it came surprisingly close to being forced out of business.
And looking at a list of dBase releases, I don't see that dBase 5.0 was really ported anywhere else besides a 1996 release of dBase V for DOS, a version that apparently went back to using Roman letters.
For some of this I am grudgingly using a timeline from Wikipedia as detailed information about dBase from this point on is rather hard to come by. I am also going to only hit the highlights of major future versions going forward and not go into every single release.
No matter its excellence, dBase 5.0 was released almost two years after Microsoft released the first version of Access. That was two years of Microsoft building market share, while dBase stayed fairly stagnant, relegated to the slowly shrinking DOS market.
To further complicate matters, Borland also already had a relational database, Paradox, and was thus splitting its development efforts between two competing products. And Paradox was already available for Windows, with an install base of around 900 thousand according to Byte magazine, a number that Access was rapidly approaching with an estimated install base of 810 thousand.
Borland did make the smart decision to ensure that dBase 5.0 was backwards compatible with the previous two major versions of dBase, version III Plus and IV.
And dBase 5.0 was a very solid, capable release that could apparently go toe-to-toe with any competitor. That wasn’t enough to stop its precipitous slide downhill, but it was enough to keep it from going defunct.
There was always a core of dBase users that stuck with the program, whether it was because they had legacy dBase applications that would cost too much to port to a different database, or they genuinely felt that dBase was still the best database available, or they just had too much of an investment in acquired experience to switch.
And also never discount the “refuse to use Microsoft applications” group, a group that undoubtedly also helped fellow legacy application WordPerfect survive to the present day. Given the fact that dBase and WordPerfect solely run under Windows, the latter group probably grudgingly runs Windows for the same reason I do…for some things there simply isn’t another choice.
Note: Since I felt the need to put a gratuitous Windows bash in, I will elaborate that I have both a Windows gaming tower I built in 2020, as well as a 2023 15” MacBook Air. Both platforms have their strong suits. I have been burned by Linux (most recently Pop!OS, but I’ve also run Fedora and Mint as well as obscure ones such as gOS and Ubuntu Netbook Remix) repeatedly, but I would love to eventually switch fully over to it, assuming I could ever find a Linux distro that worked for me.
The Trouble With Linux: A Frustrated Tale
This is going to be a little different piece from my usual tech history stuff. For one thing, it’s going to be comparatively brief, at least by my usual long winded standards, and it's not going to have a bunch of citations, as this is very much an opinion piece.
Visual dBase 5.5
Visual dBase 5.5 was released in July of 1995. When InfoWorld reviewed it in the June 5, 1995 edition, they had high praise for it and felt that it represented not just a really good dBase release but one that was one of best database options out there.
Specifically the review states “Borland is back to doing what it does best–building top-quality development tools. This renewed focus and enthusiasm shows in Visual dBase 5.5 and its optional Visual dBase Compiler. With this version, Borland has successfully beefed up the dBase environment enough that it should no longer interest just legacy dBase users but draw in anyone looking for a visual database applications development environment.”
Sadly for Borland and dBase, Visual dBase 5.5 doesn’t really seem to have moved the needle much, and sales and market share continued to collapse. In November of 1996, InfoWorld reported that Borland was going to lay off at least 500 of its 1700 employees, as part of restructuring.
Visual dBase 7.0
The numbering once again oddly jumped, this time to Visual dBase 7, which was released in December of 1997 for Windows 95 and Windows NT.
Visual dBase 7 was 32 bit only and dropped all support for Windows 3.x.
It also apparently dropped all support for older dBase files and programming syntax as well, with InfoWorld’s review saying “Visual dBase 7 is a leap of faith for Borland International. It jumps away from the albatrosslike early language constructs such as this program code…By abandoning this much-used syntax, Visual dBase 7 says it is ready for the Windows/GUI world, no longer constrained by the promise of backwards compatibility…Both old dBase code and Windows 3.x are found on many corporate desktops, and Borland is now cutting them off.”
InfoWorld at least, felt that Visual dBase 7 was a winner, and that the sacrifice of backwards compatibility was worth it for the gains in functionality.
Borland was really struggling at this point though. Recently it had renamed itself to the remarkably silly name of Inprise, and had unloaded its other relational database, Paradox, to Corel in 1996. Visual dBase 7 must not have done much to reverse the calamitous decline in market share however, as in 1999 Inprise sold the rights to dBase for Windows to a group of dBase developers who had formed a company called KSoft.
According to a contemporary article from Techmonitor titled “Inprise Finally Sells Off dBase to KSoft”, which ran on March 14th, 1999 “Ksoft assumes all development, support and marketing for the Windows database and development tool.”
Whatever other dBase versions for non-Windows platforms were out there were still apparently owned by Borland/Inprise, where they would apparently be left to die on the vine as it were.
It also looks like KSoft immediately set up a subsidiary called dBase Inc as soon as it got the rights to dBase and also started using or took over the website dBase.com. The earliest capture the Wayback Machine has for dbase.com is from November of 1999, when it belonged to an automotive shop called Meineke.
Sometime between then and June 2000 was when the website was taken over by KSoft and relaunched. I’m curious how much money changed hands, as well as why Borland hadn't locked down the dbase domain years prior.
Visual dBase 5.7 and Visual dBase 7.5
1999 was a bit of an odd year, with the new dBase Inc releasing both Visual dBase 5.7 and Visual dBase 7.5. According to the archived version of the dBase website from February 2001, these two versions were “were primarily updates of earlier Borland releases.”
According to a PCWorld article I found, this was because dBase 5.5 was the final 16 bit version of dBase, whereas dBase 7.0 was the first 32 bit and thus the two versions had significant differences requiring separate updates.
The updates, carried over at least somewhat from whatever state they were in when Borland was working on them, were not earth shaking.
PCWorld stated that dBase 7.5 in particular “For the most part, dBASE 7.5 will fix problems that have been left as is for nearly two years. For instance, dBASE 7.5 will allow cutting and pasting in places where 7.0 left it out. But dBASE 7.5 will offer some new functionality. The release will boast new Web classes to ease tasks like creating electronic commerce applications.”
Granted, cut and paste may not seem like a feature worth boasting about adding (or extending existing limited functionality, details are unclear as to just what the cut-and-paste limitation of dBase 7.0 were) to dBase 7.5.
However, given that cut-and-paste didn’t come to the iPhone until iOS 3.0, two years after the iPhone launched…and its inclusion warranted a dedicated section in Ars Technica’s massive review of iOS 3.0. A section that contained 360 words, five paragraphs and three screenshots covering the feature in full.
In light of this, I’d say cut-and-paste’s inclusion/improvement in dBase 7.5 warranted a shoutout.
While working on getting the two updates out the door, dBase was also simultaneously working on a new version of dBase, which would be known as dB2K, although that name may have been changed at the last minute since PCWorld referred to it as “dBase 2000.”
Post-dBase Borland
After selling off dBase for Windows, Borland did manage to crawl back from the brink for at least a few years. Recognizing how silly a name “Inprise” was, Borland went back to its original name of, well, “Borland '' as of November 14th, 2000, and changed its stock trading name from “INPR” to “BORL”.
The newly re-christened Borland then managed to successfully turn its legacy product Turbo Pascal into a modern programming language and development environment called Delphi, and saw considerable success with it for a while, although it too faltered as the 2000s went on.
Delphi still remains with us today, although Borland sold it off to a company called Embarcadero in 2008 for a pittance of twenty-three million dollars. Borland itself was bought by Micro Focus in 2009 for a mere seventy-five million dollars.
Eventually Micro Focus merged with a company called Attachmate and then grouped all its owned brands (NetIQ, AttachMate, Novell, Borland) under the Micro Focus name, finally bringing an end to Borland as a discrete entity and name.
dB2K
The first dBase version that was most likely solely developed by KSoft was, as previously mentioned, renamed yet again to “dB2K” and was, as the name suggests, released in 2000. By this point dBase was so forgotten that I couldn’t even find a single review of this version on Google, or in archived copies of InfoWorld, or any news article on it.
I assume there was at least some coverage of it at the time, however all I could find was a couple archived copies of the same thread where a guy was trying to figure out how to use it and a bunch of dBase people were genuinely being very helpful and trying to get the guy up to speed.
Utilizing the Wayback Machine to check out what dBase.com was showing on December 4, 2000, there is a notice that dB2K had gone gold, and would ship out on December 26.
A raft of new features and improvements are cited here as well, all grouped under the quote “dB2K is a Great Information Tool. Even better, a Great Information Toolset. No other product delivers its unique combination of easy, economical and powerful data creation, manipulation, reporting, and application development tools:”
All of this power could be yours for 579 dollars, although early birds could order it for a hundred dollars off.
At some point the product was renamed yet again to dBASE Plus, and a new application package was also made available called dBASE SE which retailed for 249 dollars and included, among other things, the last 16 bit version of dBase.
The full description of the product said that “dBASE SE (Special Edition) is a limited capability version of dBASE specifically developed for legacy users of earlier dBASE products, who need to update their applications. In addition to most standard dBASE functionality, dBASE SE includes a collection of tools that assist in converting older (DOS) dBASE applications to the 32-bit Windows environment. The CD also includes Visual dBASE 5.7 (the 16-bit predecessor to the current 32-bit product), dBASE 5.0 for DOS, and the dBASE SE User's Guide (English) in a PDF format.”
dBase Today
Like WordPerfect, dBase is still available today, with the newest version, dBase 2019, available from their website for 499 dollars or as an upgrade for 399 dollars. However the path from the early 2000s to where dBase is today is a rather confusing one, with limited documentation available.
In 2004, dBase Inc apparently rebranded itself into a company called dataBased Intelligence Inc, and it seems to no longer have been a subsidiary of KSoft. The reason for this odd name change is unclear, but I did find an article from Information Week called “dBASE Assumes New Identity, Enters BI Market” that said “The company that owns the rights to the dBASE database program has repositioned itself as a business intelligence vendor…”.
From what I can tell, dataBased Intelligence, or dBI as it was also known, was based around a new business strategy. They had a new product called dQuery that they marketed alongside dBase. dQuery was supposed to make it easy for non programmers to query various databases that used or supported the .dbf filetype.
I have no idea how successful this was, but the product still exists and can be purchased so it must have built at least some sort of user base.
Then in 2012 a new company, dBASE LLC, took over the rights to dBase from dBI.
This new company was apparently founded by, among other people, former employees of dBI. I found a press release from April 2, 2012 that stated that “dBase LLC, a company built on a 25-year foundation of technology and software development excellence, was launched today with a vision to create a new generation of business intelligence products and data management tools that will transform the way small- and medium-sized businesses manage data. The company dBase was created by a group of investors, experienced technology and business leaders, and former employees of dataBased Intelligence, Inc. (dBI), a privately held company that had been the legal heir to dBASE, the world’s first widely used relational database management system and one of the best-selling software titles of its time.”
11 years later, dBase LLC is still in charge of dBase, the longest the product has stayed with the same company since the Ashton-Tate days.
The handful of reviews on the dBase website praise dBase’s easy no-code development and powerful queries, but also complain about the price and its lack of availability for any operating system apart from Windows.
One review also complained about its proprietary file format for some reason…I’m not exactly sure why. FileMaker has its own file format, and while I have my problems with how Claris is handling FileMaker as a platform, I have never once thought that its use of a proprietary database format was one of them.
Anyhow, so that pretty much wraps this up for today.
dBase has somehow survived over forty years of highs and lows, been passed through multiple companies, and has seen its userbase dwindle down to a fraction of what it was in the glory days.
Most people who know the name dBase probably assume it went defunct several decades ago. And yet, somehow, it still survives today, one of a select handful of applications from the early days of personal computers, still serving its users today in the 2020s.
One more note that I find interesting. There were three main applications from the mid-to-late 1980s that were staples of the majority of PCs, meaning that any given PC had a good chance of having at least one of them installed and many had all three.
These applications were WordPerfect for word processing, Lotus 1-2-3 for spreadsheet work, and dBase for either developing or using dBase created databases. Of these three heavy hitters, two are actually still around today, under at least somewhat active development and support.
These two are WordPerfect, and dBase. Two unlikely survivors with a legacy that stretches back over forty years of personal computers.
I think that’s pretty neat.
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 220). essay, The MIT Press.
“The Evolution of dBase II”, Popular Computing, February 1983
Ibid
Cringely, R. X. (n.d.). In Accidental empires: How the boys of Silicon Valley make their millions, battle foreign competition and still can’t get a date (p. 262). essay.
From Basement to Boardroom, February 7, 1984 https://books.google.com/books?id=knOwBOkBuYQC&pg=PA131#v=onepage&q&f=false
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 220). essay, The MIT Press.
From Basement to Boardroom, February 7, 1984 https://books.google.com/books?id=knOwBOkBuYQC&pg=PA131#v=onepage&q&f=false
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 220). essay, The MIT Press.
From Basement to Boardroom, February 7, 1984 https://books.google.com/books?id=knOwBOkBuYQC&pg=PA131#v=onepage&q&f=false
Time-Life Books. (1986). In Software (p. 71). essay.
Ibid
Ibid
From Basement to Boardroom, February 7, 1984 https://books.google.com/books?id=knOwBOkBuYQC&pg=PA131#v=onepage&q&f=false
Cringely, R. X. (n.d.). In Accidental empires: How the boys of Silicon Valley make their millions, battle foreign competition and still can’t get a date (p. 262). essay.
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 210). essay, The MIT Press.
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 212). essay, The MIT Press.
“Is Ashton-Tate Born Again?”, Personal Computing, March 1989
Chapman, M. R. (2006). In In search of stupidity: Over 20 years of high-tech marketing disasters (p. 73). essay, Apress.
“Is Ashton-Tate Born Again?”, Personal Computing, March 1989
Cringely, R. X. (n.d.). In Accidental empires: How the boys of Silicon Valley make their millions, battle foreign competition and still can’t get a date (p. 263). essay.
Ibid
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 256). essay, The MIT Press.
Chapman, M. R. (2006). In In search of stupidity: Over 20 years of high-tech marketing disasters (p. 78). essay, Apress.
Ibid
Chapman, M. R. (2006). In In search of stupidity: Over 20 years of high-tech marketing disasters (p. 80). essay, Apress.
“Ashton-Tate Precedes Buyout with Purchase of Digicorp Macintosh Product”, InfoWorld, August 12, 1985
Ibid
Ibid
“Database Publishers Like dBase Mac’s Ease of Use”, InfoWorld, September 1, 1986
“Database Publishers Like dBase Mac’s Ease of Use”, InfoWorld, September 1, 1986
“An Entirely New Dimension”, MacUser, November 1987
“Database is Slow, But Powerful and Accessible”, InfoWorld, November 2, 1987
“dBase Is·Loaded”, MacUser, February 1988
Ibid
Chapman, M. R. (2006). In In search of stupidity: Over 20 years of high-tech marketing disasters (p. 79). essay, Apress.
Quoted in “ASHTON-TATE : Confronting a Hard Life in the World of Software”, Los Angeles Times, May 10, 1987, https://www.latimes.com/archives/la-xpm-1987-05-10-fi-6728-story.html
Chapman, M. R. (2006). In In search of stupidity: Over 20 years of high-tech marketing disasters (p. 81). essay, Apress.
Ibid
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 257). essay, The MIT Press.
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 256). essay, The MIT Press.
Campbell-Kelly, M. (2004). In From airline reservations to sonic the hedgehog: A history of the software industry (p. 257). essay, The MIT Press.
Compute, November 1992, Page 12
Chapman, M. R. (2006). In In search of stupidity: Over 20 years of high-tech marketing disasters (p. 133). essay, Apress.
So, to explain the judge's ruling and self-reversal --
The judge initially ruled that because Ashton-Tate did not disclose JPLDIS, Ashton-Tate did not have a validly-registered copyright on the dBase software itself. Which would have eliminated Ashton-Tate's legal ability to file infringement suits even against people literally copying and distributing (say) the dBase IV 1.1 disks. Throw in the 1990 state of criminal copyright infringement law (infringing software copyright was only a misdemeanor prior to 1992, and only then if it was done for financial gain), and basically the judge was throwing the dBase software (not just the dBase language) into the public domain.
And it was a clear mistake of law by the judge, who incorrectly applied patent law standards of disclosure to copyright. When you register a copyright, you do not have to disclose that your registered work is knowingly derivative of a public domain work; the Copyright Office doesn't even ask if it is. Which is why the US Register of Copyrights got involved. So the judge reversed that ruling, and so Ashton-Tate's registered copyrights on its specific dBase software products were not voided.
Thanks so much for this. I was a programmer while all of these events unfolded. I was a Clipper developer for a good number of years. That is a rabbit hole in and of itself. As a side note, I used Desqview as part of my development environment, another rabbit hole.
Thanks Again for the trip down memory lane!