Re: Documentation/License freeness
On Tue, Jun 09, 1998 at 07:56:31PM +0200, Marcus Brinkmann wrote:
>
> Hello Fabien!
Hello Marcus!
>
> On Tue, Jun 09, 1998 at 10:41:38AM -0500, Fabien Ninoles wrote:
> > I'm not sure I understand you well but here is my opinions about freeness
> > of Documentation:
> >
> > Documentation describing the functionnality of a software are dependant
> > of the software. Then, they should be considered as source by the DFSG.
> > The reason underlying this is the same as why bad documentation is
> > considered like a bug. The DFSG must be apply to them. This included most
> > FAQ, manual and source.
>
> Yes, this is correct.
>
> > Not technical documentation can be divised in two kind. Author works and
> > Official Documents. Author works must not be changed. They express the
> > opinions and observations from a person and can even be a description of
> > something. They have the particularity to be fixed in time and always
> > can't be fixed because heavily link to a given author and a given time.
> > White Paper, most e-mails, and document such as "Homesteading in the
> > Noosphere" or "Le Corbeau et le Renard" from Jean de la Fontaine, are
> > of this kind. I considered this work free enough for Debian when simple
> > verbatim reproduction, with or without a fee, are permitted without
> > conditions. Even unofficial translations can be prohibited because we
> > can't decided if the translation really correctly reflect the thought
> > of the author.
>
> Yes, although it would be very sad if we would have much documents of this
> sort in our distribution. I don't think those sort of documents belong to
> the Debian distribution (are there any of these beside some email quotes in
> /usr/doc?). The most important thing is: We don't *need* to change them.
> There is no reason for us to change them, as we don't do censorship (well,
> we include them or we don't).
>
> I don't know what "Homesteading in the Noosphere" is, but if they are
> literature, well, copyright expires after some fifty years, and then it
> becomes free. Isn't overly important for us, too.
Yes, literature is of this kind of documents. As you say, we don't need
to change them, so why not including them simply because is not allowed
us to do thing we already know we should not do [well, hope you understand
what I try to say.] About the inclusion of such document, white paper
[that's it, paper written to say why such software was written and the
idea behind is design. CVS as one who merits some looks...] can be very
interesting for understanding what the purpose of this kind of software.
Is especially true with specialized software that are mostly distributed
only by Debian [because other distribution don't care.].
>
> > Official document are like author works. They are bound with a specified
> > time and loose all their value if modifications are done freely on them.
> > However, translations should be permitted given it is clearly mark as
> > a translation and that the authors are [may be] not accepting the work
> > as a verbatim copy of the original. DFSG compliance can may be need
> > modifications with version and/or title change [because people need to
> > know what we are talking about], but aren't necessary IMHO.
>
> Do you have examples for this category? The only one I can think of are
> copyright documents. I think copyrights fit very well in your description.
> I can't think of other examples.
RFC, W3C standard, POSIX, etc... Changing anything in this kind of document,
even fixing "bugs", are enough to say that the document is no longer the
RFC 351 or the HTTP 3.0 standard. If we make change to such documents other
than translating them, how someone can say its program are "bug for bug"
compliant with such standard? We should not override the standard mecanism
used for revising such documents who consists mostly in putting out a new
revision of the standard with a different numbers. Remember that's harder
to decided what's a bug in a document than in software. It's like trying
to say if this document works well.
>
> > Finally, it's possible for a document to included both technical part
> > and non-technical part. The license should then permit the technical part
> > to be changed accordingly to the source to be DFSG compliant.
>
> Yes, but it would be better to have them completely seperated. In a book,
> this seperation should be made clear using different chapters or whatever.
> It should probably be easy (and allowed) to remove the "offending"
> non-technical part, although I'm not sure if this is necessary. I'm not sure
> about mixing those types in one source... phew, this gets complicated!
>
Yes, but some people like to put it, in example, in the introduction of
a manual. We should be able to correct the technical and respecting the vow
of the author to not change the introduction. I don't you want to put an info
page in non-free simply because the author don't want you to remove his
thanks to God and his family [Yes, the policy, as apply to some non-free
package, express that's not sufficient free.].
> > What we need to keep in mind with deciding if a document is DFSG compliant
> > is the user point of view. If it does more harm to allow modifications
> > in a document, regarding both the historical aspect and the technical
> > point of view, documents don't need to allow modifications. Allowing
> > no verbatim modifications on Author Works can harm [just see what out-of-
> > context citations can do in press media and you should understand me.].
>
> No, sorry, I don't agree. We should not have in mind the users point of
> view, but the developers point of view. Most users don't care about our
> seperation of non-free and main, they are happy if some program is available
> at no cost and if it works.
Well, I'm not talking about this point of view... I'm talking about using
documentation in the way it intends to be used.
>
> It *can* do harm to modify gcc! It can do more harm to change the
> kernel than the supporting documentation, or the text of some RFC.
>
> We should think about what rights we *need*, and should demand those. For
> technical documents, I think the dfsg are the right demands.
>
> We don't need the same rights for personal email etc. Then format conversion
> and packaging etc is enough. For standards, I'm a bit biased. I think they
> are technical documents.
>
Technical Documentation are used to inform about the functionality of a
software. So, if we change the way the software work, we also need to change
the software. DFSG compliance are a most here.
Standard are technical document, right. But they aren't used to describe
the functionality of a software. Softwares have to comply to them however.
How a programmer can ask for compliance with a standard that change between
RedHat and Debian? Would he have to say "I'm compliant with FSSTND from
Debian 1.3.1" ? Modifying such documents does more harm than good, IMHO.
> > Not allowing translation of Official Documents are, IMHO, discrimination.
> > This documents needs to be known by everybody. However, other modifications
> > can lead to the distribution of different standards whom all share the
> > same name, which as everybody know is worst than not having any standard
> > at all. Finally, source needs to be fixed and technical documentation
> > who are not compliant with the source are already broken. Not allowe the
> > documentation to be fixed is a bug in itself.
>
> Yes. Again, I don't think that standards should be immutable. There'll only
> be one "official" standard anyway, and people who are afraid about
> changeable standard should rethink their position with gcc and the kernel in
> mind.
>
Sorry, unlike a software, I don't think is good to have Debian POSIX standard or
a RedHat HTTP specifications... It will be a real mess if things like this
happen. It's like saying that MS has the right to call the J++ language Java.
> > All that's IM[NS]HO.
>
> Me too.
>
> Thank you for the summary, Fabien!
>
> Marcus
>
> --
> "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
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
------------------------------------------------------------------------
Fabien Ninoles Running Debian/GNU Linux
E-mail: fab@tzone.org
WebPage: http://www.callisto.si.usherb.ca/~94246757
WorkStation [available when connected!]: http://nightbird.tzone.org/
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: