Much has been said about copy protection and related issues. Since a number of comments have referred, directly or indirectly, to DB Master, I'd like to address some of the technical and economic realities rather than hash over the same moral issues. While my remarks will refer specifically to my own software, I assume that authors of other business packages have similar concerns. DB Master's nonstandard DOS and file structure have nothing to do with copy protection. They were developed, at no small expense, for increased performance in program chaining, data retrieval, and storage capacity. There is copy protection, but that was added much later. I should also point out that ours was one of the first major programs to offer a free backup diskette.
For example, we can chain a 16K Basic program module in about four seconds. Standard Apple DOS 3.3 takes about five seconds from a hard disk, and with a standard floppy, it takes over sixteen seconds. Likewise, our data compaction, binary number storage, and lack of track sector lists let us get more data on one data disk than, we believe, any of our competitors. You can also have more than one disk of data per file, a feature that few, if any, of the other Apple database programs are designed with. Of course, DB Master-generated data disks are copiable with any standard copy program. You can catalog them from normal DOS 3.3 to find out which file they belong to and how much data they contain. But even if the files were stored under regular DOS, as they were early in the program's development, most of the data would be unrecognizable without our "unpacking" routines. So it's a trade-off. In trying to squeeze as much performance as possible from what is really a fairly small computer, some compromises had to be made. Since our intended market was the business oriented nonprogrammer, we decided to sacrifice file compatibility in return for program performance.
Why not just make all of our source code available to our customers, and let them make whatever modifications they want? There are many very good reasons for not allowing that. The folks at Stoneware, our publisher, do a great job of customer support, but there's no way they could begin to support users trying to modify code that Stoneware didn't write. We've turned down a number of offers in the $10,000-$20,000 range for licenses to use our ISAM system because we aren't set up to support a single, sophisticated user trying to work with a system that was never designed for use by others. If only 1 percent of the users ofDB Master (which was designed for use by oth^s) decided to modify the program or the operating system, we would be faced with hundreds of generally less-sophisticated users trying to deal with, among other things, an operating system that will let you save a program anywhere on a disk, including on top of other programs Let's says you allow your users to modify your code. Now someone calls your hotline to report a problem in using the program. Is the problem in your code or in their modification? At what point does their customizing void your warranties? What is your responsibility and how much time can you afford to spend trying to trace whose code is doing what? It took about five man-years of programming time to bring DB Master to market. Since then, another five or more man-years have been put into improving, refining (all right, debugging), and adding new features and utility programs. Standard DB Master includes about 16K of machine code and over 120K of Basic in eighteen individual modules. It barely fits on one diskette (the hard disk version doesn't), and the Basic code is about as crunched as can be. The operating system is just as bad.
A similar problem applies to users who want to run our software on nonstandard disk systems. As for "simple" things like using hi-res graphics for a company logo (as was suggested by one writer) , you gotta be kidding! You see, there's this little problem: no RAM at the IN#0. (Sorry about that.) We weren't being nasty or lazy when we decided not to support RAM-based printer drivers. It's just that we've already broken several crowbars trying to wedge a few more features, or a little more file capacity, into the Apple, and folks, there just isn't any more room. On the other hand, we believe our built-in printer support is second to none. What about using extra RAM? In converting DB Master to run on hard disk systems, we modified it to make use of a 16K RAM card. This gave us additional room, but now we're back to trade-offs again. What should we give up (reducing the system for all users) to make room for those few who require RAM drivers to use some nonstandard piece of hardware?
In regard to trade secrets, we've got a heck of a lot of time invested in this system, and we're simply not about to publish commented source code for the world to plagiarize. There are those who feel that spending a couple of hundred dollars on a piece of software gives them (rather than the authors or publishers) the right to dictate how that software should be marketed and what rights they should have to it. Those who feel that way should reevaluate these feelings in light of their professed political and economic beliefs. Articles have appeared decrying the use of nonstandard operating systems, file structures, etc. I submit that too great an emphasis on standardization can only stifle the creativity, exploration, and willingness to take risks which has brought our industry so far in such a short period of time. Nonstandard systems can cause problems, but they can also solve them. How can a software developer know if they've made the right trade-offs? In a free enterprise economy, the market will tell.
Barney Stone (DB Master coauthor), San Rafael, CA - V2N12