Re: Inconsistencies in our approach
On Tue, 12 Aug 2003, Manoj Srivastava wrote:
MS>> My suggestion:
MS>> Software "is a set of statements" primarily intended to perform
MS>> some operations on the some set of input information "in order to
MS>> bring about a certain result" with this information. Regardless
MS>> of the way it does so.
MS>> Data "is a set of statements" primarily intended to describe
MS>> itself (as such) to a reader, be latter the human or the program.
MS>> Regardless of the way it does so.
MS>> Data primarily intended to describe itself to human reader is a
MS>> documentation.
MS>> What do you do if the same collection of bits performs each of
MS>> these functions?
MS>> Same bits? Example, please. I do not believe in existence of
MS>> such thing. It would contradict a human psychology.
MS> Then prepare to have your understanding of human psychology
MS> expanded.
OK. May be it would be better to say "contradict a
definition of 'intent'".
MS> In the example I posted before, the, the documentation of the
MS> probe lists the access methods and protocols that one can talk
MS> to the probe; this is the documentation part. The sensor parses
MS> the same bits to determine the capabilities of the probe, and
MS> publishes that as data to a central trading service.
And where the problem? This list is clearly not a
software, it is a data. I agree that there are data formats equally
suitable for reading by human and by program reader. After all, it
is basically same thing.
MS> The very same bits are read by the generic probe handler, and
MS> with an xsl transform, is handed a series of instructions to
MS> deploy the probe. In all these use cases, exactly the same set
MS> of bits is used.
I do not understand. These "series of instructions" all
listed in documentation mentioned above? And these "series of
instructions" all "published as data to a central trading service"?
Or they just bundled to a tail of the file (or individual records in
the file) for further burden? Or they appears only in generic
"probe handler" software?
MS>> Maybe, you mean that documentation and software can be
MS>> bundled in the same package, even in the same file? Yes, it can.
MS> Aren't you being a trifle pedantic? How is a file different
MS> from what I originally said, a "collection of bits"?
package.tar.gz is a file,
and debian4.0-1.iso is a file,
and /dev/hda is a file.
It is completely meaningless to talk about copyright,
licences and similar things in the terms of the filesystem
hierarchy. Subject of copyright is a "work of authorship", not a
file.
Bundling, combination, derivative works is a essential part
of copyright as a whole and of free software movement specifically.
Why do you accept this fact in general, but deny it in the one
special case?
MS>> There is not a news and not a problem. Different categories of
MS>> "works of autorship" often bundled, and moreover - included each
MS>> other. Book can contain a photos and drawings - but there still a
MS>> difference between graphic and literary works. Movie can include a
MS>> song - but this is not mean that musical and audiovisual works is
MS>> the same thing. Each category has its own legal regime.
MS> I am not talking about bundles -- I am talking about a the
MS> same bits. Even if I were talking about different parts of a file,
MS> are you now arguing that distinguishing between different part of a
MS> file is useful distinction when talking about licenses?
You do not have a choice. You already have to distinguish
between different parts of a file regarding its authorship, patent
and cryptography problems and other issues, sometimes very specific
and complicated.
Reply to: