Manoj Srivastava <[EMAIL PROTECTED]> wrote: >Hi, Hello.
>>>"Charles" == Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > Charles> "Non-software"? Data is software, isn't it? > > Not as the term is commonly used. Granted; but you might want to use "non-program" or "non-executable" in the title of your document to avoid possible confusion. That's the only reason I mentioned it. > 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. I definitely do not give people with hex editors the right to modify my hard drive. On the other hand, I often listen to other peoples' ideas, and modify my own based on them, and I do both accept email from most people and download software from the net, and modify the contents of my hard drive to incorporate them. Perhaps I should have said "the expression of ideas". In any case, what I meant was that prose, poems, programs and their documentation, techincal opinions and designs are all "software" as I understand the term. Certainly these things are not hardware. It seems FOLDOC isn't in agreement with me. Neither is my dictionary. Oops. > Charles> After all, what happens if the > Charles> original author of a standard goes away? Take the FHS as an example. > You ask the author, if available, Suppose that Dan Quinlan became uncontactable for some reason. > and the people who were involved in the creation, They don't own the copyright on the standard. > or the standards body under whose aegis it all happened. There isn't one. If the FHS were immutable, we'd have to rewrite the thing from scratch in the unlikely event that, say, Dan Q. renounced computers and went to live in a mud hut in the middle of a rain forest. (People -do- do strange things occasionally.) This, in my opinion, is one of the more important reasons why programs should be free: good free programs which are unmaintained are free to get themselves maintained by someone else, even without the previous maintainer explicitly "passing the baton". I think this applies to technical documents, including standards, as well. However, this isn't a problem wrt the FHS... > There is also the reality that all standards (ISO/ANSI, IEEE, > [eg< POSIX, C, C++], FHS, FSSTND, etc, are all immutable. Point of information: the FHS is, in fact, free. I'll put a copy of its licence at the end of this message. > We are not here to figure out what the best license is, but > what licenses are acceptable. Shouldn't we demand the best? ;-) > 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. You have a point. However, those kind of standards (from ISO, IEEE, Unicode, etc.) are AFAIK not often freely distributable at all, let alone mutable. Do we need to consider them when forming our policy? We are, after all, deciding which classes of freely redistributable documents we are willing to make "official" parts of Debian. > Charles> I don't think there is really any objective difference > Charles> between [standards docs and statements of technical opinion]. > > Yes, there is. An opinion is not a standard. (I didn't write what I meant. Sorry.) But is not a standard a kind of opinion? I don't mean to say that standards documents cannot be distinguished from statements of opinion (I, too, know them when I see them), only that they deserve to be treated the same way: the ideas in them can be borrowed and reused, but modified versions of the content should not be passed off as the original. Whether we should require the right to modify-and-distinguish before we put documents in Debian proper, I'm not sure about. However, I think that we should treat both standards and expressions of opinion similarly. (I probably worded this badly in my previous posting; this point was one of a pair of conflicting alternatives, and in this one I was actually supporting your position (as I understand it to be), but apparently didn't say so clearly enough for you to recognise it.) > Some opinion documents may be complete enough to be standards. True. > And standards, because of the larger impact, may need to be > considered separately. >From statements of opinion? Are you sure? > 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. Maybe not, but I think it should be -treated- in a similar way to a standards document; I should not be misrepresenting your opinion, just as I should not misrepresent the compliance conditions of 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. [...] > > 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. Suppose I were building a private network, and used only my own SMTP implementation? This is what I mean by "not binding" in an absolute sense. Certainly the rest of the world wouldn't buy it, and it wouldn't interoperate, but there's nothing to stop me doing it (other than common sense, of course). > 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. You're right. I should have been talking about the way we treat them, not the definition of the two categories. But then, is the Debian policy manual a standard, or a technical opinion? It is "binding" wrt Debian packages; I think this makes it a standard. Outside of that scope, though, it is not binding; it is the technical opinion of the Debian project. > 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> [hypothetical safe VMs make programs act like data] > > I think that is stretching it. You may be right. I won't push it. I was just in the mood for challenging your division of works into categories; particularly the boundary between program and non-program entities. > Charles> Hmm. How do we distinguish between program and 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? If your C interpreter prevents the programs it runs from doing anything other than hold a dialogue with the user, then yes, IMO. A properly-sandboxing JVM embedded in a web browser would allow programs to be treated as if they were "interactive data". (Even then, it's not complete; the JVM sandbox model allows applets to talk to their server of origin. While that's quite useful in practice, it means Java applets cannot really be treated as data.) Of course, it's quite possible to write "real" (non-applet, non-sandboxed) programs in Java, too, something many people forget. > 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) As I said, I don't really have that firm an firm opinion myself. I'm open to persuasion. (I'm doing a good job of persuading myself that you're wrong, though...) I think it's OK for statements of opinion to be immutable. I think standards should be treated similarly to statements of opinion. On the other hand, I don't want us to get lumbered with an unmaintainable standard if the copyright holder disappears. If the standard's copyright holder (and some standards relevant to us are written by private individuals, not standards bodies) disappeared without first giving anyone else permission to alter his document, the community might get saddled with what would be, given the large amount of content in a typical standard, the unenviable task of writing an equivalent document from scratch -- and, what's more, checking that the new document expresses the same standard as the original -- as a prerequisite to making an updated version of the standard. Distributing amendments alongside the original standard might work, but would not be an ideal solution, especially for large or pervasive changes. The ability to modify-and-distinguish would be very useful in that kind of situation. Imagine what would have happened had the Debian policy manual been licenced only for verbatim copying, as you contend should be acceptible. We might have had to rewrite it when our (former) policy editor left. Well, I think I've written enough for now. Hundred-page documents never get read as much as three-page ones... -- 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 The FHS's copyright and licence: Copyright © 1994, 1995, 1996, 1997 Daniel Quinlan Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder.
