Re: Licenses for non-software entities
Manoj Srivastava <srivasta@datasync.com> wrote:
>Hi,
Hello.
>>>"Charles" == Charles Briscoe-Smith <cpbs@debian.org> 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.
Reply to: