Re: Licenses for non-software entities
Hi,
>>"Charles" == Charles Briscoe-Smith <cpbs@debian.org> writes:
Charles> "Non-software"? Data is software, isn't it?
Not as the term is commonly used.
>From The Free On-line Dictionary of Computing (15Feb98) (foldoc)
software
<programming> Computer {programs}, as opposed to the computers on
which they run (the "{hardware}").
Programs stored on {non-volatile storage} built from {integrated
circuits} (e.g. {ROM} or {PROM}) are usually called {firmware}.
Software can be split into two main types - {system software} and
application software or {application programs}. System software is any
software required to support the production or execution of
application programs but which is not specific to any particular
application. Examples of system software would include the {operating
system}, {compilers}, editors and sorting programs. Examples of
application programs would include an accounts package or a {CAD}
program.
Software includes both {source code} written by humans and executable
{machine code} produced by {assemblers} or {compilers}. It does not
usually include the data processed by programs unless this is in a
format such as {multimedia} which depends on the use of computers for
its presentation.
Charles> Aren't ideas software?
Not unless you stretcxh the definition enough that you and I
are both also software, and I definitely do not give people with
scalpels the right to modify me.
Charles> I don't yet have a firm opinion on this issue. I think
Charles> mutability is good, for any document, even a document
Charles> expressing a standard. After all, what happens if the
Charles> original author of a standard goes away?
You ask the author, if available, and the people who were
involved in the creation, or the standards body under whose aegis it
all happened.
There is also the reality that all standards (ISO/ANSI, IEEE,
[eg< POSIX, C, C++], FHS, FSSTND, etc, are all immutable.
We are not here to figure out what the best license is, but
what licenses are acceptable.
Charles> On the other hand, a standard could be considered the
Charles> technical opinion of the entity who published it. If that
Charles> entity is well-enough respected and/or the opinion widely
Charles> regarded as a Good Thing, then technical opinion becomes, de
Charles> facto, standard.
This is only part of the story. Standards bodies like ISO and
ANSI meet to produce standards; people commit before the fact to
accept the standards. These are not merely technical opinions that
become standards.
Charles> Looked at this way, modified versions of the standard would
Charles> be detrimental if widely distributed, or insufficiently
Charles> clearly marked as a modified version of the standard.
>> A Standards document
>> Technical Opinion
Charles> I don't think there is really any objective difference
Charles> between these two groups. A standard is simply a technical
Charles> opinion which the community at large considers to be a
Charles> standard.
Yes, there is. An opinion is not a standard. Some opinion
documents may be complete enough to be standards. And standards,
because of the larger impact, may need to be considered separately.
My technical opinion is that Schilds annotated C reference
books is too full of inaccuracies and bugs to be useful, it is
even harmful. This is an opinion (albeit less complete than if
it were standalone); it can't be a standard.
Charles> To elaborate: how would you define the word 'binding' as you
Charles> used it above? I think you'd have to define it in terms of
Charles> the expectations of the community at large. There is no law
Charles> to stop me from implementing an SMTP which does not meet the
Charles> RFC's definition, and I can do so, so it is not 'binding' in
Charles> either a legal or an absolute sense. However, the community
Charles> will not accept my implementation, so the RFC is 'binding'
Charles> in that sense.
You implementation would fail to work, if it diverged
enough. If other SMTP serversfail to understand you, and do not
accept or send mail to you, you have failed. To an extent the RFC is
binding, since failuer to follow that results in an implementation
that does not work as expected, or at all.
Charles> Thus, I think the line between a technical opinion and a standard is,
Charles> at best, very fuzzy.
I think it is defined stronger than you represent. Like
pornography, I know one when I see one.
>> Works of fiction
Charles> What about works of fiction which are not static, but which
Charles> are interactive? (We already have a few of these packaged.)
Games? Software programs? Or are you saying we need another
category?
Charles> Some interactive fictions are expressed as a program written
Charles> for a 'safe' virtual machine (the actual VMs are not quite
Charles> 'safe', so this is hypothetical). It could be argued that,
Charles> if these are not capable of interacting with the real
Charles> machine (except for interaction with the user), they are
Charles> effectively data, and not 'real' programs at all, and as
Charles> such should be treated just like works of static fiction.
I think that is stretching it.
Charles> Hmm. How do we distinguish between program and data?
Charles> Perhaps we use the definition that, IIRC, some judge used
Charles> (according to slashdot); that of whether it is a 'functional
Charles> device'. If the software can (instruct a computer to)
Charles> perform a real-world function, it is a program, otherwise it
Charles> is data.
Do we really need define it at such levels? If I create a C
interpreter, does your C code become data? So there are really
no java programs, they are all data?
Charles> No, I know, this isn't really very well thought-out yet. Just my
Charles> (half-baked) opinion...
It would all be very interesting if I were not trying to get
some kind of a consensus on how we handle these documents, without it
all dying in clever arguments ;-)
And these are indeed clever arguments. But, I hope, you are
not serious enough about them that they need all be resolved before
we can agree (as Marcus said, we have to resort to common sense at
some level of detail).
However, if you feel strongly about this, say so, and let us
see if we can reach a compromise (hopeully before the document
reaches a hundred pages)
manoj
--
Prejudice: A vagrant opinion without visible means of support. Ambrose Bierce
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: