I heard Richard Stallman talk at the recent open source show The Bazaar in New York. He gave his usual stump speech about free vs. open source, how he got involved in and developed the idea of free software and so forth. One of the newer pieces of his speech was a call for free documentation so people who update software could simultaneously update the documentation. But what really caught my ear was his simultaneous assertion that he didn't think novels needed to be open source. As a writer of documentation myself, this got me thinking.
Stallman's point was that novels have and need a certain artistic integrity. One shouldn't be able to rewrite Gone With The Wind so that Rhett and Scarlett live happily ever after. And no matter how weird and implausible and totally unbelievable and untrue to the characters the ending of Hannibal was (and it really was all those things, definitely one of the worst endings of a novel I've read in a long time) you still shouldn't be able to change that ending and republish a better one against Thomas Harris's wishes. And although Huck Finn has entered the public domain, I still wouldn't suggest you should rewrite it to take out the frequent occurrences of the "N" word.
Although Stallman didn't state it explicitly, the clear implication was that software documentation doesn't have or need any such artistic protections. I'm not so sure I agree. Now, as chance would have it at the show I also bought a couple of Stallman's own books, the GNU Emacs Manual and Debugging with GDB: The GNU Source-Level Debugger. I like Debugging with GDB; I'm not so fond of the GNU Emacs Manual though mostly that's because I'm not so fond of emacs; but, leaving that aside, if this is what he writes for software documentation, I can see why Stallman wouldn't be upset if someone rewrote them. Both are very dry, technical explanations of the software. Stallman's own very forceful personality only really comes out in the introductory material where he discusses the nature of free software. There's not a lot of artistry here; just simple competence and explanation; which is certainly a valid way to write. I'm not knocking it, but it's far from the only way to write software documentation.
My own books are much more personal. I use examples from my own life and work. I have a fairly obvious first person voice. I make frequent editorial comments about particular companies, individuals, professions, and politicians. I sneak hidden themes into the examples that become obvious only in aggregate. And I try a host of other tricks to make my books sound like me. And I don't necessarily want someone else changing my voice, or sometimes even inserting their own.
For instance, I make a lot of negative (as well as a lot of positive) statements about Sun Microsystems in my Java books. In my XML books, Microsoft is frequently singled out for blame and praise on different pages. I'd be very upset if Sun decided to excise my negative comments about them and republish Java Network Programming. I'd be equally upset if Microsoft removed all the sections from the XML Bible where I warn against vendor-proprietary solutions and replaced them with details about technologies that will lock users into Internet Explorer (as too much of Microsoft's own XML documentation does). And I'd be positively livid if some religious fundamentalist clued in to the hidden thread in the XML Bible and republished it with all my examples replaced with fundamentalist approved examples.
I don't have any problems with gratis documentation. I think one reason the XML Bible is selling so well is precisely because I have given some significant parts away gratis on my Web site. I continue to try to talk my publishers into giving more away. But I've got a real problem with the idea of libre documentation. I can see it working for very dry, technical works like the GNU Emacs Manual. But for anything with more of an author's voice than that, every bit of your voice you add to my writing, helps drown out mine. Every time you change something I wrote, you silence me a little bit more. That's not free speech. It's the opposite.
This idea of artistic integrity goes beyond software documentation and manuals as well. In particular I think this meme affects the issue of free software as well. Certainly, most software is purely practical. Microsoft Word is not artistic. Emacs is not artistic. In fact, they're almost the opposite. But this isn't true of all software. Kai Krause's software like Kai's Power GOO and Kai's Power Tools is extremely artistic. That's an explicit goal Krause had in designing this software. I don't like his designs. I think standardization of user interfaces is a good thing. Krause thinks that's boring. But I wouldn't try to change Krause's artistic vision by rewriting his software.
Of course, Krause is a very unusual programmer and software designer. Most user interfaces are purely functional. But there is one area where I think that isn't true: games. Today's games are artistic in all senses of the word: visual, auditory, literary, and so on. A game like Resident Evil, Seventh Guest or Tomb Raider has plot, characters, music, painting, and more. The actual programming code is the smallest part of the gamer's experience. Now you can certainly argue that the art is bad art, or even more likely cliched art; but I think it's undeniable that it is art, and therefore deserving of the same protection as a novel, a movie, a symphony, or a play. Just as with functional software, some games might be hugely improved by open sourcing them; (Indeed some publishers are taking this step. Quake I is now open source and going at least as far back as Doom, games have allowed players to design and edit new levels.) but that's a decision for the artist to make, not the player. One of the freedoms an artist needs to produce art is the freedom to produce bad art.
Stallman's always been focused on freedom for programmers: freedom to modify code, freedom to distribute the modified code, and so forth; but what happens to this idea when most software isn't code? And when most of the people producing software aren't programmers? Programming may be an art but it isn't Art. The licenses that are appropriate for software that's 90% code may not be the same licenses we want or need for software that's 90%+ art.