Jeff-- Very detailed and well thought-out post here, which is why it's taken me so long to respond. I think I'll address your message point-by-point: On Mon, 15 Sep 1997, jeff covey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > michael, finally got around to reading your howto about non-software > gpl, and the whole gpl itself. > > some questions immediately come to mind about the practical issues in > doing this. it seems to me that software has the advantage in this of > having the end result and the source code very different; i use > x-windows all the time, but i have absolutely no idea what's in the > source code. this makes it very easy for the person modifying the > code to insert comments about what she's changed, or to include them > in a separate "changes" or patch file with the distribution. > > with artworks, it's not so easy, since the end result may not have a > semi-invisible source, and trying to document changes may have a poor > aesthetic effect on the artwork.. the most extreme example is a work > consisting of text: a book or article, poem, webpage, etc. Definitely. For non-software information, the "source" is not so apparant. And I do not advocate this for analog works, because -- in contradistinction to digital information -- they do not exist soley in pure principle, but are conglomerations of physical matter, if you will. > let's say for example that someone wanted to modify one of your gpl'ed > webpages to insert this paragraph: > > "not only do i think windows95 is the savior of computer users > everywhere, i think bill gates is really hot stuff, and i can't wait > to get him in my hot tub in the adirondacks." > > now, you just might want it to be made clear that this is not your > sentiment, but someone else's addition. the gpl takes care of this in > clause 2 by saying: > > a) You must cause the modified files to carry prominent notices > stating that you changed the files and the date of any change. > > but the question is, what constitutes "prominent notices" while not > intruding unfavorably on the work? should this paragraph be > italicized and footnoted, or would that disturb the flow of the work? > if we have to footnote every changed note in a musical score, is it > going to balloon to three times its prior size? This is a very real problem. Detailed comments could always go in the HTML source, but a "prominent notice" would infer that a user, upon viewing the page, would at least understand that this information was modified. I don't think there is any one answer to this, because all these different scenarios are a special case. For instance, my copyleft howto thing at <http://dsl.org/copyleft/> could be easily modified in such a manner, with a notice right after the author byline. But what about a work where the entire screen is used in some fashion that adding additional text would ruin the effect -- this could be a problem. Of course it could be a link; if you look at any work from a painting to a magazine illustration it will have some sort of cryptosystem (such as author's signature) which verifies authorship of the work. Perhaps a link to a PGP-signed "changes" document would work in this case. Part of the problem is that this is all so new -- there are plenty of proprietary or public domain non-software digital works out there, but not many copylefted ones. I think these are all issues that will surface once there begins to be more work published under these terms. > alternately, should we attach a separate "changes" document to the > work, and is this going to be practical in all cases (eg., a one-page > article with a two-page changes document)? It won't be always practical. But just the same, a copyright assertion does not always accompany a document -- there are no audible copyright notices on every song on a CD, for instance. > or should the necessary information be included at the top or bottom > of the work in the same format as the work itself (in writing for a > poem or a printed musical score, spoken before a radio play, etc.)? Probably wherever a normal copyright assertion and/or author's signature would appear is my guess. > this is what most appeals to me personally, and i would like to see > such information at the top of the file, so that someone doesn't get > halfway through an essay purportedly by jeff covey and throw it down, > vowing to ignore in the future anything that comes from this guy who > advocates throwing bowling balls off the tops of tall buildings. Exactly. This would not be right, it would be basically deceptive and in violation of the GPL. Surely people will try it, just as I'm sure people have stolen GPLed code for their own proprietary use. > but if it's still part of the work itself, how do we keep it from > taking up too much space? my suggestion would be to include, instead > of a list of changes, simply the fact that it's been changed, by whom, > and where to find the original. Yes, this works. There still is a problem, which you get to below: > if this is done, i only see one problem: if there's only been one > modification, it's relatively easy to compare the changed version to > the original and see who did what. but what if it's been changed 10 > times by 6 different people? Not only that, but alternate versions could and would branch off at different points, changing in almost a fractal pattern. For text documents, I see a possible solution: version control. This I would like for my own works, too. I have done cursory experiments with tools like rcs, but haven't yet done all that much research in this area. It seems that Linux and other free OSes benefit from superb software development tools, and there are a lot of revision control systems out there -- it's even built into Emacs! So why not try and use them for other texts? I think what's kept me from getting too far into this is that I want _more_. I would like to see a document evolve visually over time in a more seamless way than even checking the document into a version control system. For most cases I think something like rcs would be fine, but I'd like to see the rubouts -- like an eternal undo, I'd like to see the typing that went on, what got cut where. This, to me, is very important. Yes it would take up a lot of disk space, but hey, that's what 6GB hard drives are for. ;D And tying in a question someone had a while back about that Windows Recorder tool -- what if you could see what was typed in a document _at the speed it was originally typed_? I would _love_ to see such a tool, something that saves a text document and all its revisions and deletions etc. at the speed it was typed, complete with pauses. You could look at the "final" text but also at any point from original zero-byte conception in between. Right now we don't have this, but I think we will someday, even if I have to be the one to write it. ;D There is a company called Mirror Worlds who are releasing a Java program that does something like this -- they're at <http://www.mirrorworlds.com/> I believe. > this may sound a little odd at first, but would a solution be to adopt > the solution software uses, namely version numbers? if i made > available my "ode to a box of q-tips, 1.0", someone else could come > along with > > "ode to a box of q-tips, 1.6, 3/5/98 > based on ode to a box of q-tips, 1.0 by jeff covey, > [EMAIL PROTECTED] > modifications by [EMAIL PROTECTED]" This works, too. > if you wanted the original, you could come straight to me. if you > wanted to see what apo added, he would be responsible for providing > you with [EMAIL PROTECTED]'s version 1.5. rhymer would be > responsible for providing you with 1.4, etc. hopefully, someone at > some point would maintain a list of where to get all the different > versions, who's responsible for what, and perhaps even what changed in > each new version. The Information Map files from the Free Information Foundation's Web site? > at some point, someone may decide to make more drastic changes to the > original, such that practically a whole new work is created (think gnu > emacs vs. xemacs). she would be expected to place at the top: > > "when i my medicine cabinet do see, 1.0, 2/14/99 > by [EMAIL PROTECTED] > based on ode to a box of q-tips, 1.6 by [EMAIL PROTECTED] > based on ode to a box of q-tips, 1.0 by jeff covey, > [EMAIL PROTECTED]" > > so that someone who wants to can easily trace everything back to the > source. > > similarly, shall we change brahms's 4th symphony to brahms's symphony > 4.0 so that i can release 4.0.1 when i decide a certain flute passage > should be played by the violins instead? ;^) > > is this all silly, or useful? will appreciate what others have to > say. I think it is very useful. There are a lot of these kind of mechanics that need to be worked out, and I think they will probably differ for each work (much as they do for each software program). I like the analogies you've made to software, but as far as Brahms's 4th symphony I offer something else to think about -- this comes from Ted Nelson's books, especially his _Literary Machines_. He talks about hypertext and linking and how people think it is such a new concept, but he points out that it's _always_ existed in literature, music and everything else. While our society would call a Brahms 4.1 a forgery or copy rather than an alternate version or revision (this attitude is changing, I think), we copy almost everything else from our anscestors: ideas, phrases, words and characters; scales, chords, notes and riffs -- Nirvana's _Smells Like Teen Spirit_ is a great work, an original work, but it contains the essentially the same chord progression, beat, etc. as Boston's _More Than A Feeling_. Granted it's quite different from just changing one note or one second of the recorded music by Boston, but it is, to a degree, similar. Where do we draw the line between original work and copy? I think a miniscule change to an already-made work is one thing -- an alternate take or personal improvement or whatever, but actually creating a new _work_ is something that takes, well, _work_. And that may be the difference. Copyleft allows you to do both -- you could, if you want, make a tiny change to a copylefted work but that would not imply that you did anything other than make that tiny change. But taking a literary GNU Emacs and make an XEmacs out of it, well, that's a big thing. So you can never change authorship of a work that wasn't yours -- if your changes were tiny than you only had a tiny part in it. Like copyright, this all comes down to the community/society it is in. And like copyright, there will probably be people who will exploit it, which is why these legal terms exist in the first place. But copyleft will give people the freedom to interact, share and contribute to humanity's pool of knowledge in a way much more dynamic than current copyright allows. m email [EMAIL PROTECTED] Copyright (c) 1997 Michael Stutz; this information is <http://dsl.org/m/> free and may be reproduced under GNU GPL, and as long as this sentence remains; it comes with absolutely NO WARRANTY; for details see <http://dsl.org/copyleft/>.
