Conference noted::hackers_v1

Working in the PRO group, and having to deal with piracy protected software,
has lead me to the horrid realization that I agree with Jerry Pournelle on
something.

JP states that we shouldn't be doing ANYTHING to piracy protect the
software.

The following reasons apply to PC's at DEC, possibly other PC's, and
possibly to larger systems.

1.  We don't make money on software.  We make money on the hardware that
    you can't sell without the software.  For example, PRO/DECnet software
    sells for ~$98.  The DECNA is ~$900.  I doubt we'll ever recover the
    project costs from software revenue alone.

2.  Printing documentation costs mucho bucks.  Out of the $98, I'll bet
    that 15 to 20% goes to the printers.

3.  Since we don't make money on the software, who cares if someone pirates
    it?

4.  Most piracy protection schemes don't protect the software from anything
    but the most casual of pirates.  Mainly, the protection causes problems
    in backing up the software.

Pournelle DOES have a possible solution for the piracy problem.

    Make your documentation the best possible, so that if the pirate doesn't
    have it, it isn't worth having the software.  Now charge to the sky for
    the documentation.

There are problems with that scheme.

1.  It implies no on-line help.  Hard for me to agree with.

2.  You have to make the documentation reasonably difficult to duplicate.
    We've gone a long ways toward this goal, just by producing the manuals
    in that strange 6"x9" inch format.  There is also a coating (sizing?)
    that can be put on paper that fluoresces when you attempt to photocopy
    the page.  Unfortunately the coating was fairly expensive, last time
    I heard.

/s/ Chuck (trying to pour napalm on the fire)

I have an old Osborne-1 micro at home and a BBC microcomputer. 
I know enough people to scrounge software for copying from but 
the following things stop me:

1)	The low cost of products like JRT and Borland PASCAL.

2)	The volume of documentation.

The latter point is quite relevant because it would be a two 
minute job to copy something like DBASE-2. However, copying the 
manual (about an inch and a half thick) is out of the question.

Even games can have associated documentation. The volume of 
this is usually related to the sophistication of the game. 
Simple games are easy to follow from the on-screen help. 
Sophisticated games such as Acornsoft's Elite (probably not 
seen outside the UK yet) are just about playable without 
documentation - otherwise you have to copy about fifty pages.

The principle of trying out software is quite a valid one. That 
is scrounging a copy of something to see if it is any good then 
buying only if interested. Try choosing a data base for the 
IBM PC - there must be at least fifty packages around!

The other point is to publish documentation in colour. The use 
of colour in various DEC manuals has been a considerable aid to 
understanding diagrams and examples. It also devalues the 
photocopied version - although the colour will copy, the point 
illustrated will not be as clear.

Hugh.

This discussion may lead some to believe they should not produce
high-quality on-line documentation or help for their product(s).

While this does have some minor advantage in the area of software
piracy, it presents a generally less useful, and lowered quality
product to the majority of customers who've paid for the product.

Although this may offer some protection against piracy on small
computers, where documentation is almost never on-line, note that
its inadvisable on large systems.

Finally, note that the best or most useable software needs little
or no documentation.

What's an example of something that is soo good, or so usable that it
needs little or no documentation?     ^so^

I remember when a PDP-10 Assembly Language Handbook cost $5.00.  Now the
manuals it is composed of would cost well over $100 to buy.  This has a
way of getting evened out, though.  You see it is now in vogue to ship
draft manuals on magtape during field test, instead of sending a single
copy run off on a line printer.  I have not discussed manuals with any
field tes site which has not placed the manual up on SYS: for people at
the site to print off at leisure.  And the file never goes away when the
field test is over.  One guy even turned the manual into an ITS EMACS
INFO tree!  It will eventually get distributed to other sites, I bet.
				/AHM

University of Illinois PLATO has ONLY on-line documentation.  The system
continually evolves (although unlike some operating systems we know,
it remains compatible) and keeping paper documentation up-to-date would
be impossible.  But more importantly, the on-line documentation system
is so powerful it is much MORE effective than any paper documentation
could possibly be.

	Paul

It's almost an accident that we've got the problem.  The problem is that the
"reading" and "recording" media are the same and the mechanism is cheap. 

Consider phonograph records and video-game ROMs:  The "reading" mechanism is
cheap.  The recording mechanism is expensive. 

If the industry had started out by selling software on plug-in ROMs (adding a
trivial cost) to the computer, we'd now be facing a wholly different problem. 

If people don't show a little more discipline in pirating software, it's a sure
thing that the quality of software isn't going to much better. Except for
Richard Stallman, programmers are not known for their altruism. 

Pat Sweeney 

It is not an "accident" that software comes on magnetic media... it is
a matter of economics.  A computer, in order to be useful, should have 
a mass storage device and a device for reading and writing media that 
can be shared.  Since you can get both of these features with a tape or
disk drive you don't need another device for reading programs... it just 
raises the cost of the machine.  I don't know of any USER/PURCHASER who 
would prefer software in ROM packs to software on magnetic media if the
machine price has to be raised to read the ROM packs.  It may be a good
idea for companies who want to limit software availability for their
machine... remember the TI 99/4?

		John A. Wasser
		(Give me floppies or give me death!)

John, 

We agree.  The "accident" that I refer to is that the physics of stamping vinyl
and "reading" vinyl create a cost difference.  The physics of reading and
writing magnetic domains on round plastic things, are so similar that there's
no cost difference. 

If a software author's investment isn't protected, good software won't be
written. 

The only way you'll get anyone to write and sell software will be to hold a gun
to their heads.  When software is priced too high, don't buy it. 

Nobody is holding a gun to your head to use 1-2-3, when you can buy the cheaper
SUPERCALC 3. 

If the industry could have forseen the problem in the future from 1975, we
could have started from the beginning by distributing ROMs rather than floppies
and then software would have been cheaper for all of us who buy rather than
steal software. 

Pat Sweeney 

Hmm... let's see; one VAX here has VMS, DTR, COBOL, TDMS, Fortran, 
All-in-1, DBMS, VAXsim, Basic, PL/I, Pascal, DSM, DECspell, DECgraph, 
DECslide, Pro/toolkit, Pro/Cobol-81, Pro/Basic, Pro/Pascal, Pro/comms, 
DECnet, DY32, .... you get the idea.

Now how many ROMs will I need to run this system? Of course, they'd 
all need to be plugged in at the same time.

Perhaps something a bit slicker than ROMs is in order. How about laser 
disks? I could order all the software I wanted, DEC would put it all 
on one laser disk which I'd then shove into my machine. How much can a 
laser disk reader be compared with the cost of the average VAX?

$ Set note/noramble

						- Bluejay Adametz, CFI

Turbo Pascal probably costs much less (on disk) than it would on ROM.

by the way, if you're interested in rom software, look at the IBM
PC Jr.

The only software pirate I know personally (an MD in California)
would stop pirating immediately when he stops being ripped off
by software producers.  There are all too many clowns out there
who spend a couple of months hacking together a piece of barely-working
junk and assume they will be rich for the rest of their lives
by selling updates.  To put things in perspective, my friend the
MD buys the primary pediatrics reference manual every year for $80.00
and doesn't believe that -- say -- Visicalc should be charging
him $200 TO FIX THE ERRORS in the copy of Visicalc that he
paid full price for.  So he pirates a copy.

Martin.

On the small machines - it is a lot easier to pirate the ROMS 
than some protected disks. Good quality EPROM wiping and 
blowing equipment costs about 130 pounds in the UK. Some micros
such as the BBC rely a lot for software distribution on 27128s. 
If you don't own such blowing equipment yourself, you can 
usually find a friend who does.

Even worse, some companies are distributing hardware mods for 
the above machine to allow you to replace one of the EPROMS 
with RAM. This saves you the cost of the EPROMS (15 pounds) as 
you can then carry around thirty or so EPROMS on a disk!

Hugh.
P.S.	The BBC Micro is a particularly easy machine to pirate 
software from because of the open nature of the architecture. 
That is, it is very well documented from both hardware and 
software viewpoints.

Re .8 and following:

    I think you miss the point.  It was not an accident of physics that
    led to the widespread use of magnetic tape and diskettes in small
    computers.

    A read/write medium is essential for information storage and retrieval.
    Without information storage and retrieval capabilities a computer is
    truly just a toy.  You can't use such a computer for word processing,
    because you can't store your document.  You can't use it for accounting,
    because you can't keep your journal and ledger anywhere.  And so on.

    The fact that magnetic diskettes are non-volatile (while RAM is volatile)
    is no accident either.  A volatile madium simply would not have been
    been chosen.

    The fact that diskettes are removable is no accident either.  Cheap 
    removable storage, together with a little manual volume management,
    *vastly* increases the total information handling capability of the
    computer.

    Once you have a read/write medium, you have most of the components needed
    for piracy, regardless of whether the software is distributed on read-only
    or read-write form.

    This is not a quirk of recent technological development.  Back in the late
    1700s, when the Constitution of the US was being written and adopted, it
    was cheaper to reproduce somebody else's creative expression than to create
    a high quality original creative expression of your own.  That is why the
    constitution established the authority to create patent and copyright law.

    It has remained true at every point in history between then and now that
    original creative expression has required more effort than imitation.  It
    is safe to predict that it will remain true no matter what technology for
    storing, retrieving, communicating, and processing information we invent.

    [end of lecture]

    Dave

> If a software author's investment isn't protected, good software won't be
> written.

	There *are* some Richard Stallmans out there.  Not all people have the
same motivations.
		<_Jym_>

There have been a few other ideas mentioned here to avoid copying:
make the documentation real attractive, or price the software really cheap
(the Turbo method).

What I was recommending was to use a read-only device (maybe a laser CD)
which allows for changing programs, but is 'execute-only', and has certain
characteristics so that the micro can be certain it is a 'certified device'.
I did not intend this for VAXes with its wide plethora of layered software.
It is more intended for the PC user who can get to his system more directly.

By only being able to execute programs stored on the 'device', the user
would not even THINK of copying software.  This strategy is not really aimed
at the 'hacker' who is committed to trying to steal the software (there are
other methods for that). This strategy is for the casual businessperson
or home-user who copies because it is so easy. ('if they didn't want me to
steal it they wouldn't leave it unlocked' mindset). This method is designed
to make it seem ridiculous to try to copy CD to CD, ROM to ROM, etc.

As for cost, the portable Sony CD player is selling for $399.00  It is smaller
than the Hard-Disk we put in our own micros.  I am not saying that a CD
is the best solution (it might still be too big compared to a device that you
just plug in you 'rom' or whatever into), but I am trying to show that the
size and cost constraints of the device have been solved. Now only the 
architecture of the machine needs to only execute code from the device.

The new PLAY-ONLY VCR's that are hitting the market offer NO increase in
performance, only a drop in cost.  BUT, the Device I am recommending could
offer an increase in application start-time, and for devices such as CD's
(at $399 RETAIL) or some other, the incremental Hardware Cost could be
minimal.

TO HELP SOFTWARE VENDORS WANT TO DEVELOP FOR OUR MACHINES: This feature
of DEC's machines would attract software vendors to DEC's PC's (an admitted
problem so far) since DEC would be the only vendor to have such a security
enhancement. Software Vendors are saying that they have to charge so much
due to the many stolen copies out there.  This is a way to help DEC get
some software for our PC's,and possibly be able to sell them at a reasonable
price.

	The main problem with the concept of an "EXECUTE ONLY" device is
	that (on current vonNeuman type machines) there is no such thing.
	In order for a program to be executed (on every machine I've ever
	used or heard of) the program must be read into main memory.  If
	a program can be read into main memory, it can be written to
	another device.  This reading and writing is all done under
	software control.  It only takes one person to write a program
	to read the "EXECUTE ONLY" device and write the data (program)
	on a floppy (or whatever mass storage media is available).  This
	program could be sold for a low price (everyone will want a copy
	so they can back up their programs).  Once the program is on a
	read/write medium, you can make backup copies and load the program
	from any of them.  If you want such a device to appear on future
	DEC personal workstations, please outline the design of an "EXECUTE 
	ONLY" device that CANNOT be copied from in this way.

		-John A. Wasser
		 Rainbow Software Engineering

The "execute only" device should only be usable when a certain flag
bit is set. This flag bit is set by power being turned on and cleared
by software. There would be no way to set the bit under software.

ROM in the PC would be responsible for immediatly booting off of
the execute only device if one is present in the system and there
is something in the drive. If not, the software in ROM would clear
the bit "turning off" the "execute only" device.

The problem with this scheme is that someone could always replace the
ROM, but how far can you go?

Kevin

re: .16

	What you have designed is a "BOOT ONLY" device, not an "EXECUTE ONLY"
	device.  Since the device cannot be used for any program that is not
	"stand alone" it wouldn't be very useful for most applications.  You
	would not be able to load more than one such program per session.
	We're getting closer but please make the device as general a program
	storage device as a disk (can load multiple programs from multiple
	disks) and still maintain the "EXECUTE ONLY" restriction.

			-John A. Wasser
			Rainbow Software Engineering

	P.S.  If somebody can come up with a Product Requirements Document
	for this device, I would be interested in seeing it here.

    I think you are overlooking something.  The functionality you are
    designing doesn't do anything FOR the owner (at least not directly).

    Why should I pay extra for you to put a governor under my hood?
    What does that do for me, as an honest user?  as a dishonest user?
    as a hacker?  as a software developer?  Yeah, the software development
    people want *other* people's PCs to be incapable of piracy, but
    I'm talking about their own PCs.

    The only way you're going to get me to pay more money for something
    that does less is to illegalize the other kind.  I don't think the
    industry is stable or mature enough yet to let the government enact
    standards and licenses for us.

    Yeah, I know a piracy proof PC will be favored by lots of software,
    but it remains to be seen whether   that will fetch a price differential
    equal to the cost differential dur to the piracy protection gear.

    Dave

re .15: Even if someone does copy programs from the execute-only device to
a floppy, that won't help the users out there, since their PC's cannot 
execute from floppy; they can still only execute from the execute-device.
This strategy also expects that this is a new PC or in some way 'different'
so that the 'end-user PC's' will still only be able to execute only from
the execute-device.  (This could be done by having an 'end-user operating
system' that will only execute from the execute-device (yes, it does internally
load the program into memory, but it only does it on its own free will, and
you would use your own security to prevent tampering with the operating system,
much the way much operating system security is devised today).

re .18:  The current cost of a Sony CD is $299 RETAIL (not $399 as I said
   in an earlier note) so AS AN EXAMPLE, a CD is a cost-effective medium
   for an execute-device. Of course, a ROM holder on top of the PC, or any
   number of other ideas could also serve as the EXECUTE-Device.

Some of the advantages for the customer are:

   - at only $299 RETAIL, it is possible DEC could absorb the extra WHOLESALE
     cost.

   - Because this method help prevent the CASUAL user from copying, the 
     customer has reduced risk of lawsuit from software vendors.

   - This method is cheaper than the one Mitch Kapor (Lotus) has been touting,
     and is less deadly than the worm software out there.

   - Many Companies would feel safer if their end-user could only USE 
     applications, rather than write their own. (The hostility about not
     being able to develop on early releases of the PRO were not so much
     due to what the users couldn't do, but that the programmers had to buy
     a whole VAX to do their work (and Vaxes weren't as small then).

   - There are probably some other efficiencies we could introduce by having
     end-user machines only being execute-only. (they would of course still
     have a disk for storing their data, lotus-routines, etc., but other
     things might no longer be needed. any ideas?).

   - CD's LOOK NEAT. Go to a record store and check out a CD.
     Compare it with a Floppy. CD's look like the computer-age. Floppies
     Look like the Plastic-age. And in the Computer-age, LOOKING high-tech
     is almost more important than being high-tech. People don't want 
     machines just because they solve their business problem (that's only
     a REQUIREMENT). They want machines because they LIKE the way it does it.

I haven't gotten a chance to look at the CD Notes file (it probably has
other input for this idea, but also remember that CD's are just an example:
The EXECUTE-only device can be anything that the casual user normally 
cannot write onto.

I might try to write up a Product Requirement Spec if someone sent me an 
example (and a description).  But I really don't want to get hung up filling
out all sorts of forms. (See marketing notes for complaints about such forms).
I would, however, be anxious to provide more detail, and have been thinking
about this for a while. (I drafted a letter to the editor to Infoworld
in light of what they've been saying about Kapor's method. I of course didn't
mention DEC since I still can't find out what you have to do to get approval
to write an article or anything as a DEC employee, and I didn't get the idea
at DEC (DEC doesn't have showers in the office)). If someone within DEC tells 
me not to send it because they want DEC to have a lead by being first, though, 
then I certainly wouldn't submit it.

re: 18

If you don't believe in intellectual property rights you should since by this
note.  If you don't believe that the software market is "free" that is to
say that vendors of software are free to choose what they sell and at what
price, and buyers of software are free to choose what they buy and at what
price, then since by this note.

Turbo Pascal is free to sell at their price (low).  Stallman is free to sell
at his price (zero).  Kapor is free to sell at his price (high).

Nobody is forced to buy.  Everybody is free to discuss among themseleves the
information regarding VisiCalc (ie, it has bugs) and 1-2-3 (ie that it's good).

I'm free to insist that the only way you can buy my software is on a laser
disk or ROM.  You can insist that the only way you'll buy software is if
it's on non-copy-protected floppies.

Maybe I'll COPYRIGHT my software.  You know the law.  If I catch you making
a copy, I'll take you into court.

Maybe I'll get tired of doing that and I'll go into another business.

I think we all agree that something has got to give in the software industry
at least in the personal conputer area.

You'll say that one day all software will be cheap.  I'll say that one day
all software will be effectively copy-protected.  Don't ask me how.  If I
knew I could leave DEC, make millions, and retire.

Pat Sweeney

Execute-only protection is definitely possible on Van Neumann machines.
Read the Burroughs 6700 reference manual.

(basically the idea is that memory has n databits/word and also k tag bits.
The tag bits encode the intended use of the word in question.  Only that
use is allowed by the CPU -- and in fact data references change in semantics
depending on the tag.  For example, if I do a "fetch" and the tag is zero,
that's a dataword.  If the tag is ?4? then it's an address (pointer word)
and the CPU will automatically follow the pointer to get to the data it points
to (you couldn't fetch the pointer if you tried!).  If the tag is 7,
then this is code, and the CPU will automatically CALL the code -- an
implicit function reference...)

	Paul

CD's also have an advantage in durability. From what I've heard, 
they're virtually indestructible. That should keep down some of the 
outcry about having to make backup copies.

						- Bluejay Adametz, CFI

Re .19 Non-executable floppies...

	If you can't load programs from floppies, how are you going to use
	the programs that your local programmers write?  Require them to 
	get a VAX so they can write CD's?

	DEC does not make a profit by "absorbing" manufacturing costs.  That
	is how you sell for a loss.

	Customers who don't want to risk lawsuits don't have to make copies.
	There is no advantage to the user who doesn't intend to make copies
	and no advantage to the user who DOES want to take the risk and
	make copies.

	Your best bet is to abandon the single system users and sell only
	to big corporations... they might indeed wish to pay more to
	protect themselves against their end-users copying.  If you limit
	the market in this way, you also limit the type of software that
	will be written for the system... only "corporate" software need
	be written because that is the only market.

Re .21 Burroughs 6700 Execute Only

	You are correct... with the proper hardware and a secure operating
	system with restricted privileges (direct I/O, Memory and File 
	access control) and a non-removable media (so you can't move it
	to a system that is not protected), you can arrange to have files
	on the media protected against copying.  I wonder how long before
	all of these features make it to the PC market?

Re .22 CD Durability...

	I believe the disks are durable in the music mode because errors
	can be easily faked over.  If you loose a sample, just interpolate.
	The error correction will work for bursts up to 4000 bits 
	(0.1 inches) and interpolation works up to 12,300 bits (0.31 inches).
	Scratches longer than .1 inches will cause you to lose data... unless
	you put on another layer of error correction.

			-John A. Wasser
			Rainbow Software Engineering

    You need no extra hardware to protect against truly casual theft:

    Just but a bit in the file directory entry for each file that says
    "copyrighted material", and have the file copy program look at the bit.

    Just put a bit in the volume label that says "contains copyrighted
    material", and have the disk copy program look at the bit.

    Of course, sombody will write their own file copy and disk copy program,
    and start selling it.  Is that still casual theft?

    Again, of course, software protected this way would be a little less 
    valuable to me, because if something went wrong with the original
    medium, I'd have to buy another copy.  I suppose software vendors
    could give me a credit for returning the broken medium.

    With regard to having DEC absorb the extra cost of the CD ROM: Bull.
    A manufacturuer always spreads all tyhe costs of making all the products
    across all the sales.  If the people who buy the PCs don't pay for the
    CD ROM, someone else will. Who do you suggest?

The cost difference between RAM and ROM may be useful here.  If the O/S and
layered products were put in a helluva big ROM, that ROM should be cheaper
than any RAM to which the software could be copied.

Re .26:

    Wait.  RAM can act as a cache for secondary storage like diskettes.
    ROM cannot.  A cost comparison that ignores this fact would be 
    meaningless.

re: Cost Comparison

	While a generally better system can be built at (usually) lower cost
	by avoiding ROM, this doesn't address the problem of unauthorized
	duplication of software.  Basically, any solution will cost extra.

Re .-1:

    I agree that any solution will cost extra.  My question is, "cost whom?"
    The would be pirate or casual thief?  I don't think they want to pay.
    The honest person?  I don't think so.  When I pay extra for locks on
    my doors, it is to keep other people from stealing from me, not to keep
    me from stealing from other people.

    It seems as though the purchaser will have to bear the cost, though.
    Now the problem is how to turn this "feature" the user didn't need into
    a benefit for THAT user, so as to make it worth the extra cost.  The
    only possible way I can see that happening is is more/better/cheaper
    software is developed for such systems, because the software developers
    expect to make a better return on their investment.

    It's not clear to me that that will happen.  Even if it will, it's not
    clear how it gets started.

The way it gets started is that the vendor (DEC) makes the first move.
When DEC announces to the world that we are trying to limit our marketplace
and not aim at the retail market, that sends a signal to the software
writers that their maximum number of sales from making a DEC version
will be limitted.  Add to that the fact that the vendor has to then 
choose 'which DEC-box' to write it for, and you can see that the problem
with limitted software for DEC boxes is DEC caused.  I have seen lots
of small software packages written for the IBM PC (specialized markets),
and here too, I cannot blame the writer for not bothering to write versions
for the different DEC PC's.

But if writing for the DEC PC's had something 'extra', such as a more 
secure feeling that they will get revenue for actual usage, than the vendor
might like DEC that extra bit more that we so desparately need.

With regard to 'RAM can't be used as cache for floppy', my question is:
Does any of our software currently use RAM as cache for floppy?
As I've said before, the SONY CD is only 299$ RETAIL. That is such a small
price that it does not have to be passed onto the customer directly.
And even if it is passed on, CD's look more computereze, and ROM's might
be easier to handle, store, or other reason's marketing or engineers could
certainly come up with, especially when compared to plastic, bendable,
non-coffee-resistant floppies. ROM's could come in neat cases, etc., and
DEC would do more than meet the requirements: we would give them
something that had that something 'extra' that the users thought was fun.

Please also bear in mind that the security strategy simply requires a
device which is normally read-only (execute-only), and not the same media
that the user is accustomed to being able to write onto. (change their
mindset).  It doesn't have to be ROM or CD, but those look like good ideas.

My hope is that a new PC that DEC offers (new instruction set to DEc, whether
it be IBM compatable or not) have the 'execute only' unit with it.
And THEN, watch all the software be written for it! Of course, still
use other security methods such as serial number checking or whatever,
but make it so that the user wouldn't even THINK of copying the software,
because after all, they've never seen a device that WRITES that media.

Whether DEC offers a new idea or not, companies like LOTUS and the
worm-people are coming out with copy-protection tools. I think our
strategy is the cleanest because it says 'the users won't have the 
equipment to make a copy in the first place', and it doesn't get in
the way of other protection devices that might be used as well.
(ie. our method would work with the LOTUS method).

The rest of the world is going to start adding protection
anyway, and DEC could be first with a new idea, or we could watch everyone
else start doing something, and then play catch-up. But if we're first
with a new idea,  (while the industry is still talking about it and looking
for solutions!) maybe it will add value to our machines, and our
company. The public eye considers DEC micros to be non-leader
and non-follower machines (we're in our own world).  So let's make
our world a place where customers and software developers will want to be.

COPY PROTECTION is something that is hot in the industry today.
Let's make DEC a leader. (or at least be responsible for contributing a new
idea).

Regarding "using RAM as cache for floppy":

    I'm sorry.  I was indulging in something I do all the time when talking,
    which is to use concepts in a slightly "off center" manner.  Conceptplay
    is as much fun for me as wordplay, but I should be more careful how I
    communicate over the net.

    What I meant by "using RAM as cache for Floppy" was something that goes
    about like this:

    Software does not execute off of Floppies.  It executes off of RAM
    (or ROM).  When it is executing from RAM something that originally
    came from a floppy, it's doing for the contents of the floppy something
    like what cache does for main memory:  keeping the "currently most
    relevant piece" more available in a smaller memory.  That's what I
    use the word "cacheing" for, whether I'm talking about cache, or VM,
    or diskettes & main memory, or tape archiving, etc, etc.

    The same RAM, at different points in time, supports the execution of
    different applications.  I have oodles more bytes of purchased software
    than of RAM.  If the stuff came in ROM, I couldn't do that.  I'd either
    have to find a way to stuff all the ROM in there at once, or swap manually,
    or copy the stuff to be executed into a read write memory. If we take the
    last approach, I fear we defeat the entire goal you were aiming at by
    putting the software on ROM to begin with, because we have now given the
    user the tools needed to make executable copies.

so I guess that a ROM could still serve as a POSSIBLE execute-only media,
but that it doesn't necessarily mean that the RAM could be removed.

But other savings might be found, since each user would not need all the
development tools (they are only 'users'), and in fact, might not need as
much memory altogether (at least in Apple machines, a big problem was that
you needed a Fat Mac to develop software for the regular Mac, but the Mac
features mostly appealed to the programmer types).

Maybe there are other cost-saving features. But at 299$ retail for a CD,
(and other methods such as a 'rom-like'(not necessarily a ROM) might also
work), cost-saving isn't the most important feature of this idea anyway.

But a device with a transfer rate faster than floppy might be nice bonus
for the user, even though user-bonus won't be as critical as software-developer
bonus.  The main goal is making the software available but protected, and
making it so that we'll have a way to provide software from a variety of
vendors on what might be a popular PC.  And help DEC;s image as a
mainstream company at the same time.