Why I don't share Manojs fears.
On Thu, Aug 13, 1998 at 11:53:40PM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
>
> Marcus> Great option. Imagine the free software would follow the same
> Marcus> criterion. "If you want to publish a variant C compiler, you
> Marcus> can always rewrite gcc".
>
> *Sigh*. Again you harp on software, and insist on applying
> licenses good for software to everything else, blindly. Makes me
> wonder of you actually know why feredom of software is
> essential. (If reuse was a major goal, than by and large it has
> failed; though there are plenty of exceptions to this statement).
Manoj,
please accept that I see it differently from you. You think that modifying a
standard is detrimental to the community, I don't see it this way.
You are seeing the dangers, I'm seeing the benefits.
BTW: I don't think reuse is a major goal, I think the possibility to reuse
is an important thing. For example the Docbook Standard: It is a DTD which
defines a standard format to write documents in. It is extensible, but you
can also modify the core DTD, you just have to rename it, and give it a
different pubic identifier. Most people will use the DTD as is, but if there
is the need, you don't have to start from the beginning.
You beat on me not providing technical arguments, but on the level you are
carrying out the discussion, technical arguments have no effect anymore. You
have made it a matter of opinion. Regardless of what I say, you will always
say something to the effect that standards should not be modificable because
it is bad for the community, you've done this constantly from the beginning
of the discussion. I'll attach a list of quotes I collected from
the discussion, were technical arguments were given.
(Manoj)
Standards are modified by the standards body, not by any tom dick, or
harry that comes along. How would things be if Debian modifies the
FHS, and so does Red Hat, and caldera an so. We all have our own FHS,
and now none of the distributions are using compatible file layouts.
But we are not talking about Debian making modifications to
standards. There is a difference: If you allow modifications or if you use
your right to the full extend. The following has to be kept in mind:
-----
With the name-changing-clause, there will EVER be only ONE version of a
standard, the official one. All derivations from it are renamed and
therefore there is no additional confusion created.
The copyright of a license will have no impact on the fact if parties choose
to follow a standard or not.
-----
Your arguments are essentially basing on the assumptions that people would
start to derive standards and make them incompatible to the official
version. Sure, people would probably try that, but this would have no impact on the
people who follow the standard (the people who derive from the standard
would only harm themselfes by not being compatible to the official standard
anymore). Furthermore, I don't see this fear substantiated by common praxis.
Similar effects could be created in the free software community, but it does not
happen. Because most people have the responsibility to obey standards. So we
get all benefits, but will not actually experience that the "community
suffers from the spread of a subtly or drastically different copies
of what purports to be a standards document.", as you fears.
We will always know what the official standard is.
A standard will ever be a standard, regardless if there are also a few
renamed and changed derivations. If ever one of the derivated works becomes
more popular and known than the standard itself, there must be something
wrong with the original standard.
In the free community the people are leading who do the work. If the
standard commitee does its work well, nobody will feel the need to derive
from the standard.
Please see also the post I forwarded from RSM on this matter. He gives
another example, and a possible solution for standard authors to protect
their work, without disallowing modifications at all.
Thank you,
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.
>
> 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.
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?'
>
> 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...
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.
[...]
> 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.
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.
Guy in response to Manoj:
> > [Everybody following a different standard would make standards
> > pointless.]
>
> Yes, of course everybody will agree with you there.
>
> 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?
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?
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.
[...]
> Marcus's discussions about standards were adequate, I think, while
> still protecting the integrity of the standards.
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, ...
[same applies to standard documents, IMHO --- 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.
[...]
> > 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).
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.
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: