On Sat, 2009-04-25 at 20:02 -0500, Shaun McCance wrote: > I don't really feel like rehashing all of the problems > we've had with the GFDL, but I'll go into it if anybody > is really interested.
I'm going to paste in the text of an email I sent to Luis in January 2008 which lists all my gripes with the GFDL. Note that a number of these gripes are things that affect us as original authors. Dual-licensing means we'd still have to deal with this. ------------------------ Invariant sections suck as far as I'm concerned. But we have a standing policy of not using them in Gnome. Since we don't usually redistribute other people's documentation, it doesn't really pose a problem for us. Basically, our problems all stem from section 4, the part that tells you all the things you have to do if you modify the document and distribute your modified copy. These are the most egregious requirements, paraphrased from FDL v1: A. Use a distinct title. So I originally wrote the Sound Juicer Manual. I own the original copyright. I put it into SVN (then CVS) and let it bitrot. Somebody else comes along, in the grand free software tradition, and updates it. >From a common sense perspective, that person is working on the canonical version of the document, our version, not some offshoot. But from a purely legal perspective, that person is modifying and redistributing my copyrighted work under the terms of the FDL. We don't do copyright assignment for documentation. Since people are transient (especially our writers), this means that documents tend to accrue copyright holders. Each new person coming along is making a modified work. When I took over as GDPFL, we were following this. As a result, all our document titles looked like "Sound Juicer Manual v2.4". Dumb dumb dumb. (It's also not clear when the title has to be changed, since "release" and "publish" are murky concepts. See next complaint.) I made the call to stop this insanity, hoping that none of the copyright holders chose to be pedantic. C. Name the publisher. We've generally listed the GDP as the publisher in the past. This has two problems. First, the very idea of publishing is stretched thin for what we do. We put stuff into SVN where the whole world can see it. With a few exceptions, we the writers don't even control when the documents are "released" in tarballs. What does publishing even mean? Second, the GDP is not a legal entity. Is it even valid to list it as such? H. Include an unaltered copy of the FDL. It's not clear where this should be included. Does it have to be a section in the document itself. Most of our documents don't do this, in part because we already have the FDL (and GPL and LGPL) available in Yelp. I. Preserve "History" section. K. Preserve "Acknowledgments" and "Dedications" sections. M. Delete "Endorsements" section. Special-casing section titles is insane. First, this effectively removes perfectly good titles we could use for sections. Second, translated documents would have to retain the untranslated titles. Crazy. "History", in particular, I could imagine using as a section title for something other than the FDL's intended use. I (again). The requirements for adding to "History". Here are some other issues with the history requirements. When you redistribute a modified document, you're supposed to add an entry with the title, year, authors, and publisher of your modified work to the history section. In Gnome, we don't actually use a section, per se. Instead, we put the history information into the <revhistory> DocBook element. Processors (like Yelp) put this information onto the title page (or equivalent). We're kind of skirting the requirements, especially since documents don't have control over how a processor entitles the revision history blurb on the title page. This is further complicated by the fact that what DocBook provides for revision history doesn't include everything the FDL requires us to state. In Gnome, we sort of abuse DocBook to make this work. But our documents won't correctly display the the FDL requires with anybody else's processing tools. Add to this the fact that it's not clear what granularity is required for the history. Technically, every time I commit to SVN, I'm redistributing a modified work. Do I seriously need to add a <revision> element each time? All of these combined create requirements that we just can't fulfill in Gnome. We've been ignoring and skirting around some of them for a while, but that's not the way I'd prefer us to be working. Honestly, for Gnome, I think we could strike 80% of the text in section 4 and have a license we're happy with. Perhaps the FDL just isn't the right license for us. -- Shaun _______________________________________________ gnome-doc-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-doc-list
