Re: Licenses for non-software entities
(I'm afraid the discussion will have moved on since I wrote this; I am
subject to a lag of about a day. If the discussion has progressed to
the point that this is irrelevant, feel free to ignore it.)
In article <[🔎] 87g1f1lx4f.fsf@tiamat.datasync.com>:
> Licenses for non-software entities
> ----------------------------------
> Manoj Srivastava<srivasta@debian.org>
> $Revision: 1.2 $
"Non-software"? Data is software, isn't it? Aren't ideas software?
I think "Licences for non-program entities" might be a better title.
I don't yet have a firm opinion on this issue. I think mutability
is good, for any document, even a document expressing a standard.
After all, what happens if the original author of a standard goes away?
If, say, the author of the FHS falls off the face of the net tomorrow,
or gets run over by a bus? If the standard is immutable, it then is
impossible for someone else to step up and take over the maintanence
of the standard without first rewriting it from scratch. This is one
issue where standards are like programs.
On the other hand, a standard could be considered the technical opinion
of the entity who published it. If that entity is well-enough respected
and/or the opinion widely regarded as a Good Thing, then technical
opinion becomes, de facto, standard. Looked at this way, modified
versions of the standard would be detrimental if widely distributed,
or insufficiently clearly marked as a modified version of the standard.
However, allowing changes does not mandate changes. For example,
if Debian decided to distribute a standard whose licence allowed
modification, the package maintainer would (I hope) not make any such
modifications, even though they were allowed to.
> A Standards document
> A standard describes is a common set of standard interfaces,
> formats, rules, application programming interfaces, common
[...]
> Technical Opinion
> Documents which state the opinion of a particular person or group
> in relation to a technical matter. Unlike standards, this
> material is not binding in an of itself, but serves rather to
[...]
I don't think there is really any objective difference between these
two groups. A standard is simply a technical opinion which the community
at large considers to be a standard.
To elaborate: how would you define the word 'binding' as you used it
above? I think you'd have to define it in terms of the expectations of
the community at large. There is no law to stop me from implementing
an SMTP which does not meet the RFC's definition, and I can do so, so
it is not 'binding' in either a legal or an absolute sense. However,
the community will not accept my implementation, so the RFC is 'binding'
in that sense.
Thus, I think the line between a technical opinion and a standard is,
at best, very fuzzy.
> Works of fiction
What about works of fiction which are not static, but which are
interactive? (We already have a few of these packaged.) Some interactive
fictions are expressed as a program written for a 'safe' virtual machine
(the actual VMs are not quite 'safe', so this is hypothetical). It could
be argued that, if these are not capable of interacting with the real
machine (except for interaction with the user), they are effectively data,
and not 'real' programs at all, and as such should be treated just like
works of static fiction.
Hmm. How do we distinguish between program and data? Perhaps we use the
definition that, IIRC, some judge used (according to slashdot); that of
whether it is a 'functional device'. If the software can (instruct a
computer to) perform a real-world function, it is a program, otherwise
it is data.
No, I know, this isn't really very well thought-out yet. Just my
(half-baked) opinion...
Cheers,
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Reply to: