[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Documentation project status



Ok, it's obvious that my previous post has generated more heat than light.
Let me try to bring some additional photons into the mix... :-)

The software comprising Red Hat Linux is available with very little
restriction.  You can install it on a thousand machines if you like, you
can make money by selling the software (as long as you don't call the
software you sell "Red Hat Linux"), you can obtain the sources and make any
changes you want.  I'm sure everyone here knows all this stuff -- it's
pretty much business-as-usual, from an open source perspective.

The documentation produced by Red Hat for Red Hat Linux is a different
story.  The intent was never to make the documentation open source --
you'll note that the SGML files (or the LaTeX files for the earlier
releases) used to create the manuals are not made available.  The original
thinking was that the documentation was (to use corporate-speak) a
"value-add".

And that was that.  To be honest, we didn't give the matter all that much
thought -- we figured that copyright would be sufficient.  Until this
little gem popped up in the bookstores, that is:

http://www.amazon.com/exec/obidos/tg/detail/-/0965957535/qid=1072710563/sr=1-2/ref=sr_1_2/102-7187390-8046543?v=glance&s=books

The content for this book was taken from the HTML version of the
documentation distributed with Red Hat Linux 6.0.  Unfortunately, it was
not entirely clear to people purchasing the book that they had not
purchased an official Red Hat product, which caused no end of problems when
these people then demanded the free tech support the manual implied was
available to them.  Add to this the fact that whoever did the job
converting the HTML into printable text messed up badly in a number of
areas (it's been a while since I've looked at the book, but iirc
cross-references and certain textual treatments were pretty screwed up),
and you have a real mess.  In addition, the book was advertised as having a
preface written by a Red Hat employee -- Sandra Moore (in an attempt to
give the book more credibility, I guess) when she actually wrote the entire
manual.  She (or Red Hat) was never contacted by the company that produced
the book.  It was just a slimey situation all around.

Granted, we brought this on ourselves by not making very clear the ground
rules regarding how the documentation could be used and distributed.  In
any case, we then looked to clarify things by explicitly putting the
documentation under a license that would hopefully eliminate the problems
we were seeing.  To make a long story short (I doubt you want to hear about
how I tried to get our Legal department to write a documentation license),
we searched for an appropriate license, found the OPL (and its two
options), and decided that it was the best option available to us -- it
allowed the documentation to be distributed as freely as Red Hat Linux
while still preventing:

    o Other entities using the documentation for commercial gain, and
      confusing people as to what was an official Red Hat product versus a
      legitimate (but unofficial) copy.

    o The possibility of a third-party maliciously (or innocently) "putting
      words in our mouth" ("To upgrade your system, issue the following
      command: rm -rf /")

That's why Red Hat Linux documentation is not open source, and how it came
to be licensed as it is.

When the Fedora Project was being born, the question of documentation was
raised internally, as it was a given that the Red Hat Linux documentation
(by this time basically a branch of the same documentation used for Red Hat
Enterprise Linux) was not available for the project.

It was at this time that those of us involved in producing Red Hat's
documentation looked at the the Linux Documentation Project as the most
viable approach for the documentation aspect of the Fedora Project.  We
felt that it would be more likely for interested people to write shorter
tutorial-style documents than it would be for them to create large,
monolithic manuals.  We felt that the "infrastructure" (style guides,
editorial support, etc) would be lower for the smaller, separate documents.
As the documentation project grew, it could be extended to include
full-blown manuals, but our thinking was to start small.

Perhaps we've underestimated the kinds of documentation-related projects
people would like to take on -- certainly the content produced by the
Debian project is a good counter-example of what a dedicated group of
individuals can accomplish (though I'll note that the Debian project has
been around a while, and comparing a brand-new Fedora Project to a
firmly-established Debian Project is not entirely fair)...

That's about all I originally wanted to say; hopefully it has shed a bit
more light on an admittedly confusing situation.  I don't imagine that
those of you unhappy about the unavailability of the Red Hat Linux
documentation are going to be any happier, but at least you know how we got
to where we are today.

It seems that the best way to end this email is to pose a question:

                         Where do we go from here?

                                    Ed
-- 
Ed Bailey        Red Hat, Inc.          http://www.redhat.com/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]