Hi,
All Right!. This is a good message; something I can sink my
teeth into.
Something to consider: you have gone a ong way towards
convincing me that the rename-and-distinguish-if-modified clause is a
good thing if one is creating a standard; but what if the author has
gone the route of no modifications at all? Is this so egregious that
we throw it out of Debian? Why should exeptions be made for licenses
(which are in just as great a need to be improved and modified look
at NPL, AbiPL, and other GPL knockoffs [which in some way do dilute
the GPL, is only psychologically]) but not for standards? What about
non-technical documents, like Graphic novels or any of the other
categories?
Actually, I am going to make a stand about our Hypocrisy;
anything that you have said also applies to Licenses. You want to
throw things like the FHS and others out of main, you have to throw
out the DFSG, the social contract, and GPL etc out as well
All the arguments about stadards apply to licenses as well.
>>"Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes:
Marcus> On Thu, Aug 13, 1998 at 11:53:40PM -0500, Manoj Srivastava wrote:
Marcus> please accept that I see it differently from you. You think
Marcus> that modifying a standard is detrimental to the community, I
Marcus> don't see it this way.
Firstly: having differing views is a good thing. Secondly, my
fears are indeed more about dissemination of almost similar standards.
Marcus> BTW: I don't think reuse is a major goal, I think the
Marcus> possibility to reuse is an important thing. For example the
Marcus> Docbook Standard: It is a DTD which defines a standard format
Marcus> to write documents in. It is extensible, but you can also
Marcus> modify the core DTD, you just have to rename it, and give it
Marcus> a different pubic identifier. Most people will use the DTD as
Marcus> is, but if there is the need, you don't have to start from
Marcus> the beginning.
All right. This may be acceptable.. I will even grant you that
derived works, as long as the original is not tainted with knock-off
copies pretending to be the original, are beneficial to the
community.
Marcus> You beat on me not providing technical arguments, but on the
Marcus> level you are carrying out the discussion, technical
Marcus> arguments have no effect anymore.
Try me. This is the first message where you have actually
gotten some substnace; and I did concede a fwe points.
Marcus> You have made it a matter of opinion. Regardless of what I
Marcus> say, you will always say something to the effect that
Marcus> standards should not be modificable because it is bad for the
Marcus> community, you've done this constantly from the beginning of
Marcus> the discussion. I'll attach a list of quotes I collected from
Marcus> the discussion, were technical arguments were given.
Marcus> (Manoj)
Marcus> Standards are modified by the standards body, not by any
Marcus> tom dick, or harry that comes along. How would things be
Marcus> if Debian modifies the FHS, and so does Red Hat, and
Marcus> caldera an so. We all have our own FHS, and now none of
Marcus> the distributions are using compatible file layouts.
Marcus> But we are not talking about Debian making modifications to
Marcus> standards. There is a difference: If you allow modifications
Marcus> or if you use your right to the full extend. The following
Marcus> has to be kept in mind: ----- With the name-changing-clause,
Marcus> there will EVER be only ONE version of a standard, the
Marcus> official one. All derivations from it are renamed and
Marcus> therefore there is no additional confusion created.
Conceded. Applies to licenses as well.
Marcus> Raul Miller:
>> It's important to recognize that DFSG already provides a mechanism which
>> preserves the integrity of a standard: that's the "you must relabel
>> the document if you change it" type of license.
Not merely relable, but remove all vestiges of the original
name. But I concede this point. Applies to licenses as well.
>>
>> It's also important to recognize that the DFSG does not even address the
>> problem of preventing buggy software. I feel that stupid modifications
>> of standards documents are in some way analogous to this.
The modifications need not be stupid. (NPL, AbiPL). Applies to
licenses as well.
Marcus> Jules:
>> Maybe you don't want to change them. But, before agreeing that they are
>> OK in main, ask yourself, 'Might I, or might one of our users, want to
>> create a derived work?'
Point. Applies to licenses as well.
>> One of the advantages of main, IMHO, is that I know I can create a dervied
>> work from anything therein, without carefully reading the license. I
>> would not like to give up that right too easily...
True. Applies to licenses as well.
Marcus> Richard Braakman:
>> I would be very sad if this happened. You see, the one area where
>> proprietary software still beats free software hands-down is that of
>> artwork to go with the program. This is most visible with games of
>> course.
>> Right now there seems to be a general lack of Free Art to go with
>> the Free Software. I would like that to change! And it _is_
>> changing. This is not the time to move the line.
Does Free have to mean mutable? If yes, also applies to licenses.
Marcus> [...]
>> If Debian takes a stand on this, and stands for Free Content in general
>> (which is really Free Software and all that goes with it), we could
>> lead this movement. But if we accept the assumption that novels and
>> other artwork need not be free, we may set it back considerably.
Applies to licenses as well.
Marcus> Guy Maor:
>> If standards can't be modified, how can they be improved? I think
>> there is gain in allowing standards to be modified. Modified
>> standards must be distributed with a prominent notice that this is not
>> the original standard and that the original standard may be obtained
>> from wherever.
Applies to licenses as well.
Marcus> Guy in response to Manoj:
>> But isn't innovation important? If I come up with a new modified
>> standard, and prominently plaster big warnings all over it that this
>> isn't the original standard, why shouldn't I be allowed to distribute
>> it? Why shouldn't I be allowed to distribute patches so that programs
>> follow this new standard? What if my idea is a good one and the
>> standards body see it and incorporates it into the next standard?
>>
>> Is innovation of standards only allowed to come from the specified
>> standards committee itself?
Applies to licenses as well.
Marcus> Adam Harris:
>> Well, suppose we want to add an appendix to the FHS. For instance,
>> the FHS doesn't not talk about icons and pixmaps and where shared
>> pixmaps should be placed. We should feel we have the power to add
>> components to the standard; in this case, probably it would mean a
>> separate *appendix* document. However, I could see cases where we
>> might feel that for the benefit of the developers, it's easier for
>> them to look at the FHS, and our extensions (still compliant with
>> baseline FHS) in the same document. So couldn't we, shouldn't we, be
>> empowered to retitle the document ("Filesystem Heirarchy Standard,
>> including Debian extensions"), and add a few additional directories,
>> in each case where we are adding, mark the addition as Debian-specific
>> very clearly?
Bad. Really Bad. This is not renaming. This effect is better
achieved by creating a new documents, and saying that we follow the
FHS, and we also follow Policy, and that document is part of
Policy. We should never modify the original and call it Debians
version of ``Original''; there should be no chance of confusion.
Marcus> Adam in response to Manoj:
>> > A plethora of almost same bug subtly different "standards"
>> > dilutes the presence of the standard, and in my opinion, hurts the
>> > software community wirse than proprietary, non free software does. It
>> > divides us, and lowers the efficacy of the stnadardizing effort.
>>
>> I agree, but I don't see why it is *necessarily* a problem if
>> annotated clearly, and if the derivation does not pose as the original
>> in any way.
Applies to licenses as well.
Marcus> [...]
>> Marcus's discussions about standards were adequate, I think, while
>> still protecting the integrity of the standards.
Applies to licenses as well.
Marcus> Enrique about translations (in response to Manoj, in response to
Marcus):
>> > Marcus> It is okay for authors to think and act this way, but I don't
>> > Marcus> think we can distribute technical documents with this
>> > Marcus> restrict copyright in main.
>> >
>> > Reasons, please.
>>
>> Because that does hurt the non-english-speaking free-software community.
>> Good software needs good documentation, but to a non-english speaker a
>> manual written in english is like no manual at all. If its author doesn't
>> allow translations, someone else has to write a new manual from scratch.
>> If everybody choose the "no-translation" terms that means the community
>> needs different manuals for english, french, german, spanish, italian,
>> japanese, chinese, ...
Marcus> [same applies to standard documents, IMHO --- Marcus]
Applies to licenses as well.
Marcus> Marcus, in response to Manoj (about subverting standards):
>> > Not so. Our fears of trojan horses have never been
>> > instantiated. Our fears about people destroyin our CVS data have
>> > never been instantiated. Does that mean we do not plan and take
>> > precautions? This is a groundless argument.
>> This is a groundless argument? Not quite so. The softwrae examples show that
>> there are other ways to take precautions. The whole free software movement
>> shows this. The precautions don't have to be set in the license.
>>
>> Trust is one thing, honesty another. Silly changes to standards will be
>> followed by nobody, especially not by Debian.
>>
>> Taking precautions is one thing, making improvements impossible in the first
>> place another.
Applies to licenses as well.
Marcus> [...]
>> > Marcus> Some people are frightened about their software, too, and
>> > Marcus> forbid disassembling etc. We don't allow this software in
>> > Marcus> main.
>> >
>> > We have a reason. It has to do with sharing. It has to do with
>> > being able to see what is going on, and not being locked in to a
>> > vendor. Part of that does not apply to documents, and the sharing
>> > aspect is actually enhanced if we can trust we all follow the same
>> > standard, not w locally modified version of what used to be a common
>> > but is not more standard.
>>
>> This is your opinion. My opinion is that the same reasons apply so that we
>> are not being locked in by silly standards.
>>
>> IMHO, locally modified versions of a standard are better than nobody
>> following an insufficient standard at all and everyone making up his own
>> "standard". Eventually someone will step up and merge all differences into a
>> single standard again (as it happened with apache, for example. Sorry for
>> the software analogy).
Following a locally modified standard is worse than no
standards at all. Yuo modify what the standard says, and you follow
the modified stnadard, you are harming yourself, and not following
what evceryone else is, and you are harming the community.
Marcus> Philip Hands:
>> Including anything that is non-DFSG in main, means that people have to start
>> checking licences, before playing with the source --- a Bad Thing IMHO.
Applies to licenses as well.
Manoj
--
Everyone is entitled to my opinion.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
