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/
