Re: A possible GFDL comporomise: a proposal
Fedor Zuev wrote:
>First, try to answer to several simply questions.
FYI, these are *my* answers, not necessarily everyone's answers.
>0) Is printed Emacs Manual in bookstore a software or hardware?
The lump of paper and ink is hardware. Including the various splotches
of ink resulting from printing press problems. But the 'text of the manual',
that abstract entity embodied in the manual, is software.
>1) Is Emacs Manual recorded on CD-Audio a software or hardware?
The bits are software, the lump of plastic is hardware.
>2) Is Debian/main printed as book a software or hardware?
The hunk of paper is hardware, the 'text' in it is software.
>3) Why? What differs from 0,1?
Nothing.
>4) Is Debian/main printed into punch-cards a software or hardware?
The physical punch cards are hardware, the data on them is software.
>5) Why? What differs from 0,1,2?
Nothing.
>6) Is Debian/main written on CD-ROM a software or hardware?
The lump of plastic is hardware. The data on it is software.
>7) Why? What differs from 0, 1,2,4?
Nothing.
>8)Is Debian logo written on [cover of] the same CD-ROM software or
>hardware?
Neither, really, but... The printed cover with its actual copy of the logo,
possibly with some dirt, etc., is hardware. The logo as a copyrightable
entity embodied on the cover is software.
>9) Why? What differs from 0, 1, 2, 4, 6?
Nothing.
>10) Is Debian installation, hardcoded into embedded system software
>or hardware?
This is usually called "firmware". Again, the lump of silicon and metal
circuits is hardware, and the data hardcoded into it is software.
>11) Why? What differs from 0, 1, 2, 4, 6, 8?
Nothing.
To answer a question you didn't ask, the *design spec* for a piece of hardware
is software. The hardware itself isn't.
Get the picture? This is the extremely useful definition of software I use.
(Software is a more useful term for discrete/digital data than for
continuous/analog data, because continuous/analog data can't be reproduced
without data loss, making the software inseperable from the hardware to some
degree.)
--
Nathanael Nerode <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html
Reply to: