Re: various opinions on Debian vs the GFDL
On Thu, May 08, 2003 at 11:30:15AM +0200, Henning Makholm wrote: All the XML scores in the world will not allow me to recreate a particular sound recording (made with real live musicians, in the case it contains music). Therefore, an XML score is not source. All the C code in the world won't let you recreate the last build I did either, unless I also give you the compiler I used. Big deal. If one need to use a compiler that only you have, I'd say that your binary is not free. You'd say that unless I give you a copy of the C compiler I wrote, the perfectly compliant ANSI C code I give you is not free? You'd insist on demanding a copy of my compiler, if I give you a binary that you cannot generate a byte-for-byte copy of with gcc? If so, that's utterly irrational and unreasonable. If not, you're unreasonably limiting the ways sound can be redistributed (it must be *exactly* the same, not merely the same bar production differences). Samples and recordings are more difficult, mainly because the concept of revision doesn't really exist, per se. One possibility is just to do a hex dump -- it's as straightforwardly editable with a hex editor as _anything_ is, after all Any opaque format is straightforwardly editable with a hex editor. Well, no, it's not. It was your claim that sound could be edited in hex form. If that is true, then anything else can be similarly edited in hex form. It was your claim that C source code could be edited with a text editor. If that is true, then anything else can be similarly edited with a text editor. Apart from one matching your preconceptions, and the other not, is there any difference in the logical validity of those two comments? The question is what changes do you want to make. Nowhere in the GFDL does it say that it is OK for a transparent format to make only certain kinds of changes possible. You can make any changes with a hex editor to anything, the question is whether the changes are straightforward or not -- and some aren't. But likewise, many changes you'd make to a document or to source code with a text editor aren't straightforward either -- translation into Elvish, optimisation, converting a reference manual into a tutorial, rearranging sections to be more logical and coherent. Setting the bar at every possible change must be able to be made in a straightforward and thoughtless manner is thus not a reasonable interpretation of the GNU FDL's requirement; the most common and basic changes must be able to be made in a straightforward and thoughtless manner is, and, for sound, where the most basic edits you can make is addition and rearrangement, you can do that with a reasonably marked up WAV hex dump quite easily, in a text editor. If you want to change the location of two icons in a program, I don't think you're going to be able to do that if I give you a hexdump of an ELF executable. And if you want to change the words of a poem read alouf, I don't think you're going to be able to do that if I give you a hexdump of a PCM file. I've already given you an example of how you can change Anthony is my name to is my name Anthony. I don't know what a PCM file looks like -- but the only requirements are being able to work out where the word breaks are, which requires either markup or consistent bit lengths for timing; and that there's no cross-frame dependencies. OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. My point is exactly that *no* way of editing sound files will allow me to do the kind of changes we normally require for freedom. That's nice, but you haven't done anything but repeatedly restate it. Only for certain kinds of changes. That's not enough. Really? How do you remove all the buffer overflows from mozilla with a text editor? A lot of analysis, study, and tedious editing, no? Yes, but it's possible in principle. Yes, it's possible in principle to reconstruct source code from an ELF binary too. Same thing with most of the edits you want to do to a sound file. No, they are not possible in principle. You're both wrong and insane. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpRfljuyrzKa.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
Scripsit Anthony Towns aj@azure.humbug.org.au An XML score satisfies all these requirements as a way of representing music. We're not talking about music; we're talking about *sound recordings*. All the XML scores in the world will not allow me to recreate a particular sound recording (made with real live musicians, in the case it contains music). Therefore, an XML score is not source. Samples and recordings are more difficult, mainly because the concept of revision doesn't really exist, per se. One possibility is just to do a hex dump -- it's as straightforwardly editable with a hex editor as _anything_ is, after all Any opaque format is straightforwardly editable with a hex editor. If you accept it for sound recordings, yoy should accept it for every other kind of data as well, and the whole GFDL concept of opaque/transparent formats goes down the drain. (Which means that yours is not an interpretation of transparent that is likely to be used by a court). Simply being able to cut up the sound and insert your own pre-recorded sound effects is probably enough to satisfy that requirement actually Says who? So you call it free even if you can't remove something? * you can revise it with a text editor easily enough Only for certain kinds of changes. That's not enough. to be is Anthony My name is easy, eg; Not without losing any semblance of sensible prosody. * the format's been designed to make it as easy as possible to modify, not arranged to thward anything As easy as possible is still not easy enough to quialify as possible. The questions at hand here are can you license sound stuff under the GNU FDL, and, if not, can the GNU FDL possible be DFSG-free. I think the answer to the first question is yes, and, even ignoring that, I'm not really convinced the answer to the second is no. If it is not possible to license sound under GFDL (which I believe it is not), then the GFDL says that I must not make a modification of the work that consists of reading it aloud on a sound recording. I think that's quite easily non-free. -- Henning Makholm That's okay. I'm hoping to convince the millions of open-minded people like Hrunkner Unnerby.
Re: various opinions on Debian vs the GFDL
On Thu, May 08, 2003 at 09:24:21AM +0200, Henning Makholm wrote: Please respect Debian list policy and my Mail-Followup-To header, and don't Cc me. An XML score satisfies all these requirements as a way of representing music. We're not talking about music; we're talking about *sound recordings*. Actually, we're just talking about embedding sound in a GNU FDL document. Music, in case you hadn't noticed, is one form sound takes. All the XML scores in the world will not allow me to recreate a particular sound recording (made with real live musicians, in the case it contains music). Therefore, an XML score is not source. All the C code in the world won't let you recreate the last build I did either, unless I also give you the compiler I used. Big deal. Samples and recordings are more difficult, mainly because the concept of revision doesn't really exist, per se. One possibility is just to do a hex dump -- it's as straightforwardly editable with a hex editor as _anything_ is, after all Any opaque format is straightforwardly editable with a hex editor. Well, no, it's not. The question is what changes do you want to make. If you want to change the location of two icons in a program, I don't think you're going to be able to do that if I give you a hexdump of an ELF executable. OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. Simply being able to cut up the sound and insert your own pre-recorded sound effects is probably enough to satisfy that requirement actually Says who? So you call it free even if you can't remove something? Seems pretty easy to me to delete a tag and its contents form an XML file. * you can revise it with a text editor easily enough Only for certain kinds of changes. That's not enough. Really? How do you remove all the buffer overflows from mozilla with a text editor? A lot of analysis, study, and tedious editing, no? Same thing with most of the edits you want to do to a sound file. Some things are easy, some things aren't. Big deal. to be is Anthony My name is easy, eg; Not without losing any semblance of sensible prosody. Again, so what? The sorts of revisions you can do with sound are fundamentally limited; that you can't easily do everything conceivable means nothing at all. * the format's been designed to make it as easy as possible to modify, not arranged to thward anything As easy as possible is still not easy enough to quialify as possible. That's completely irrelevant too: the question that's answering is whether the formats specifically designed to thwart modifications. It's not. The questions at hand here are can you license sound stuff under the GNU FDL, and, if not, can the GNU FDL possible be DFSG-free. I think the answer to the first question is yes, and, even ignoring that, I'm not really convinced the answer to the second is no. If it is not possible to license sound under GFDL (which I believe it is not), then the GFDL says that I must not make a modification of the work that consists of reading it aloud on a sound recording. I think that's quite easily non-free. That's wrong too: that would merely be an opaque copy which is entirely allowable, as long as you distribute a transparent copy as well. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpYONySb4uWG.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
Scripsit Anthony Towns aj@azure.humbug.org.au On Thu, May 08, 2003 at 09:24:21AM +0200, Henning Makholm wrote: We're not talking about music; we're talking about *sound recordings*.=20 Actually, we're just talking about embedding sound in a GNU FDL document. Music, in case you hadn't noticed, is one form sound takes. But not the only one. All the XML scores in the world will not allow me to recreate a particular sound recording (made with real live musicians, in the case it contains music). Therefore, an XML score is not source. All the C code in the world won't let you recreate the last build I did either, unless I also give you the compiler I used. Big deal. If one need to use a compiler that only you have, I'd say that your binary is not free. Samples and recordings are more difficult, mainly because the concept of revision doesn't really exist, per se. One possibility is just to do a hex dump -- it's as straightforwardly editable with a hex editor as _anything_ is, after all Any opaque format is straightforwardly editable with a hex editor. Well, no, it's not. It was your claim that sound could be edited in hex form. If that is true, then anything else can be similarly edited in hex form. The question is what changes do you want to make. Nowhere in the GFDL does it say that it is OK for a transparent format to make only certain kinds of changes possible. If you want to change the location of two icons in a program, I don't think you're going to be able to do that if I give you a hexdump of an ELF executable. And if you want to change the words of a poem read alouf, I don't think you're going to be able to do that if I give you a hexdump of a PCM file. OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. My point is exactly that *no* way of editing sound files will allow me to do the kind of changes we normally require for freedom. Only for certain kinds of changes. That's not enough. Really? How do you remove all the buffer overflows from mozilla with a text editor? A lot of analysis, study, and tedious editing, no? Yes, but it's possible in principle. Same thing with most of the edits you want to do to a sound file. No, they are not possible in principle. Not without losing any semblance of sensible prosody. Again, so what? So I cannot reasonably make trivial edits and have results that have reasonable quality. The sorts of revisions you can do with sound are fundamentally limited; Exactly. Therefore, sound is opaque no matter what format it is in. That's completely irrelevant too: the question that's answering is whether the formats specifically designed to thwart modifications. The thwart modifications language in the GFDL applies only to unconventional uses of otherwise transparent formats. The definition of transparency is; | A Transparent copy of the Document means a machine-readable copy, | represented in a format whose specification is available to the | general public, that is suitable for revising the document | straightforwardly with generic text editors or (for images composed | of pixels) generic paint programs or (for drawings) some widely | available drawing editor, and that is suitable for input to text | formatters or for automatic translation to a variety of formats | suitable for input to text formatters. I maintain that this effectively excludes any conceivable sound format. If it is not possible to license sound under GFDL (which I believe it is not), then the GFDL says that I must not make a modification of the work that consists of reading it aloud on a sound recording. I think that's quite easily non-free. That's wrong too: that would merely be an opaque copy which is entirely allowable, as long as you distribute a transparent copy as well. I *cannot* distribute a transparent copy of my spoken performance, because no such copy is possible, as argued above. -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: various opinions on Debian vs the GFDL
On Thu, May 08, 2003 at 11:30:15AM +0200, Henning Makholm wrote: OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. My point is exactly that *no* way of editing sound files will allow me to do the kind of changes we normally require for freedom. ... If it is not possible to license sound under GFDL (which I believe it is not), then the GFDL says that I must not make a modification of the work that consists of reading it aloud on a sound recording. I think that's quite easily non-free. That's wrong too: that would merely be an opaque copy which is entirely allowable, as long as you distribute a transparent copy as well. I *cannot* distribute a transparent copy of my spoken performance, because no such copy is possible, as argued above. This argument might have been convincing several years ago, but it kinda flounders when coming on the heels of a series of (commercial) games which used text-to-speech technology instead of prerecorded audio data. Given a decently large sample (say, your spoken performance) it is possible to generate a fairly convincing sample with different words in it; the rest is just work with a non-linear audio editor. Or, hey, ever play with soundtracker-style mod files? This is much like saying that transparent copies of paintings are not possible, because once committed to canvas they can't be modified. Technology has improved since then. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK
Re: various opinions on Debian vs the GFDL
On Thu, 2003-05-08 at 03:36, Anthony Towns wrote: We're not talking about music; we're talking about *sound recordings*. Actually, we're just talking about embedding sound in a GNU FDL document. Music, in case you hadn't noticed, is one form sound takes. That's right. You seem to keep wanting to discuss musical scores, which are a small subset of all sound. All the C code in the world won't let you recreate the last build I did either, unless I also give you the compiler I used. Big deal. Depending on the license. Well, no, it's not. The question is what changes do you want to make. If you want to change the location of two icons in a program, I don't think you're going to be able to do that if I give you a hexdump of an ELF executable. Why not? Personally, I've changed programs using hex dumps (though it was PEF, not ELF, but that's doubtfully relevant). OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. OK, try this one: Resample a hex-dumped WAV file from 48KHz to 44.1KHz using your text editor. Or mix several tracks down to one. Or do a phade out. Or, well, do just about anything. Sure, it's possible --- in the sense anything is possible. But it makes my job of moving that icon in an ELF executable look trivial. Same thing with most of the edits you want to do to a sound file. Some things are easy, some things aren't. Big deal. Yeah, and generally, when a license is the cause of the extreme uneasyness of modifying things, we don't call it free That's completely irrelevant too: the question that's answering is whether the formats specifically designed to thwart modifications. It's not. No. It is very relevant. The question is if making revisions is [straightforward] with generic text editors. That's wrong too: that would merely be an opaque copy which is entirely allowable, as long as you distribute a transparent copy as well. Of which, for sound, it appears there is no such thing as far as the FDL is concerned. signature.asc Description: This is a digitally signed message part
Re: various opinions on Debian vs the GFDL
Just noticed another problem: A Transparent copy of the Document means a machine-readable copy, represented in a format ... that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. ... A copy that is not Transparent is called Opaque. Notice that a sound file, movie, etc., in any form, is not suitable for input to text formatters. It thus can't be a transparent format. I apparently can't make a training video from the EMACS manual; remember, my video is a modified version of the EMACS manual, and thus I am obliged to provide a transparent version which, under the definition above, I can't do. signature.asc Description: This is a digitally signed message part
Re: various opinions on Debian vs the GFDL
I'm going to try again... I think somehow, we got off on a tangent of sheet music which blurs the issue. Ignoring my previous message about not being able to have sound be a transparent copy at all: I hope we can agree that: 1) Transparent copies of a document are required for distributing printed copies in significant quantity 2) A transparent copy of a work must actually be a copy of it. Now, let's talk about a specific example: Let's say I want to make a music video with portions of the EMACS manual. Why? I'm crazy, that's why. Being crazy, I decide that the sound track will include the second part of Brahms' German Requiem, Denn Alles Fleisch. Why? Once again, I'm crazy. So, in order to get a recording under a an acceptable copyright license I hire an orchestra, a choir, etc. While listening to the singing Denn alles Fleisch es ist wie Gras und alle Herrlichkeit des Menschen wie des Grases Blumen... I start to wonder: What is a transparent copy of this work? At first, I think I'll just include the score. But upon closer reading of the GFDL, I notice that a transparent copy must be suitable for _automatic_ conversion. So, that rules out the score --- there is no automatic way to convert a musical score of Ein Deutsches Requiem, no matter how represented, to the audible form.[0] So that leaves me with my digital sampling. So I call the 96KHz, 48-bit[1] many-track full recording the transparent copy. Or at least I'd like to. I notice that a transparent format, unless a drawing or a painting, must be straightforwardly [editable] with generic text editors. So now I'm stuck. It's fairly easy to do all kinds of neat editing on sound, with programs designed to do so. But generic text editors sure aren't. Let's say that we allow that completely unmixed PCM data, as long as all editing is done through AJ's Special XML Format. That way, we can claim it's straightforward to modify with a text editor. So to mix the tracks (for example), I do: mix track id=firstViolin src=orch/violin1.wav channel id=1 volume=40 / channel id=2 vulume=60 / ... /track track ... /track ... /mix With 32 tracks[3], that 14:32 of transparent copy is a mere 15.3GB. Nothing major. So, the question is: Where have I erred? AFAICT, I can't use the score as the transparent copy. I can't use the PCM data as the transparent copy. Even if I could, it's too damn big to be of any use. Good thing I didn't even get to trying the do the video part, video is easy to edit with video editors; however, editing video with a text editor is once again, near impossible. [0] Just getting the instruments right is extremely hard even with very expensive synths; doing the singing is right out. [1] Not sure what rate/bit size is actually used today. [3] Google searches turn up studios using many more tracks, e.g., http://www.angelfire.com/id/dkstudios/, http://www.cavemanmusiconline.com/cl_about.html. I saw up to 128... signature.asc Description: This is a digitally signed message part
Re: various opinions on Debian vs the GFDL
On Wed, Apr 30, 2003 at 03:51:06PM +0200, Stephane Bortzmeyer wrote: On Wed, Apr 30, 2003 at 12:15:32AM +0200, Henning Makholm [EMAIL PROTECTED] wrote a message of 33 lines which said: ?) The GFDL is not free when applied to documents if any of the invariant or cover options are exercised. Is it a consensus on debian-legal that a GFDL work *without* any Invariant or Cover is indeed free and has no problem being distributed in main? Not quite. This mailing list's analysis of the GFDL has revealed other, subtler problems with the license, but I think it's safe to say that if the FSF were willing to modify the license to rectify the Invariant or Covert Texts restrictions in a way we'd regard as DFSG-free, they probably wouldn't have a problem making the other much smaller changes we'd likely request. The FSF is standing in defense of Invariant Sections and Cover Texts on principle, however what exactly those principles are have not been clearly articulated as far as I can tell, are not present on the FSF/GNU website, and appear to be different from the FSF's principles regarding software freedom. In my opinion, the FSF has not been completely forthcoming on these matters. I think we would all benefit if they would shed some light on these matters. -- G. Branden Robinson| Why do we have to hide from the Debian GNU/Linux | police, Daddy? [EMAIL PROTECTED] | Because we use vi, son. They use http://people.debian.org/~branden/ | emacs. pgpsPdF5zJDPa.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
On Tuesday, May 6, 2003, at 10:03 AM, Anthony Towns wrote: you should be able to do a text representation of a FFT or something, I would've thought. Long, and ugly, but editable as text, That's no better than a hex dump of the PCM data. It's not any more editable in a text editor (possibly, quite less) than a hex dump of an ELF object. _Technically_ it's editable. Practically, it's not --- and that's what matters for the GFDL. and satisfying the terms of the GNU FDL as far as I can see. ...suitable for revising the document STRAIGHTFORWARDLY with generic text editors... Even editing MIDI-esque XML with a text editor wouldn't be all that straightforward. They allow images to be edited with image editors; drawings to be edited with drawing programs; text files to be edited with text editors; why not sounds with sound editors? And, what about video? Are we supposed to edit that with text editors, too? I'm not claiming anyone would /want/ to distribute sound this way, but the fact that you /can/ means this doesn't make GNU FDL docs non-free, IMO. Making people jump through unreasonable hoops to modify a document isn't, IMO, free.
Re: various opinions on Debian vs the GFDL
On Mon, May 05, 2003 at 11:08:39PM -0400, Anthony DeRobertis wrote: On Fri, 2003-05-02 at 16:48, Anthony Towns wrote: I don't think it could be considered straitforward to revise that with a text editor. - note timbre=trumpetC#/note + note timbre=trumpetD/note Yes, now, where is the source to this trumpet timbre? You may argue, but it's a TRUMPET!, but there are a lot of weird sounds used in music that have a similar issue. Sure, one of the nice things about sheet music is that you don't alway send up with the exact same performace, so that degree of freedom is entirely deliberate. If you /don't/ want that degree of freedom -- you're just trying to include a recording, you should be able to do a text representation of a FFT or something, I would've thought. Long, and ugly, but editable as text, and satisfying the terms of the GNU FDL as far as I can see. I'm not claiming anyone would /want/ to distribute sound this way, but the fact that you /can/ means this doesn't make GNU FDL docs non-free, IMO. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpAhWrXP0Sh2.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
On Fri, 2003-05-02 at 16:48, Anthony Towns wrote: No, you wouldn't. There seem to me to be plenty of ways to have an XML format for music that would be plausibly editable. Think scores and things. Works great for some types of music, but other types is routinely put through a lot of filters, both digital and analogue, that won't work to well with that form. Or is created with artificial sounds. I don't think it could be considered straitforward to revise that with a text editor. - note timbre=trumpetC#/note + note timbre=trumpetD/note Yes, now, where is the source to this trumpet timbre? You may argue, but it's a TRUMPET!, but there are a lot of weird sounds used in music that have a similar issue. And, btw, note how differently two different violinists can render a solo. Seems pretty straightforward to me. Maybe, if all the world were a single MIDI synthasizer. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' off-topic /me suspects that scribbled over the whole test were the words debootstrap woody /mnt /off-topic signature.asc Description: This is a digitally signed message part
Re: various opinions on Debian vs the GFDL
On Thu, May 01, 2003 at 10:19:24PM -0400, Anthony DeRobertis wrote: What's stopping you from doing all your music in some XML format, anyway? [...] Forcing you to convert mp3s to XML I'd assume: A 'Transparent' copy of the Document [is] suitable for revising the document straightforwardly with generic text editors What's stopping you from editing an XML file with a text editor? note pitch=middlec timbre=xylophone You could do something similar for sound effects or recorded sound by dumping the FFT into XML, I think. Being able to edit it with a text editor doesn't mean that's the way you'd want to edit it, necessarily, just that's it a reasonable thing to do. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpxCMynYupvH.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
On Fri, 2003-05-02 at 02:43, Anthony Towns wrote: On Thu, May 01, 2003 at 10:19:24PM -0400, Anthony DeRobertis wrote: What's stopping you from doing all your music in some XML format, anyway? [...] Forcing you to convert mp3s to XML I'd assume: A 'Transparent' copy of the Document [is] suitable for revising the document straightforwardly with generic text editors You could do something similar for sound effects or recorded sound by dumping the FFT into XML, I think. Essentially, you'd be doing a big hex dump. I don't think it could be considered straitforward to revise that with a text editor. Even if it was, a copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent.
Re: various opinions on Debian vs the GFDL
On Fri, May 02, 2003 at 03:06:17PM -0400, Anthony DeRobertis wrote: On Fri, 2003-05-02 at 02:43, Anthony Towns wrote: On Thu, May 01, 2003 at 10:19:24PM -0400, Anthony DeRobertis wrote: What's stopping you from doing all your music in some XML format, anyway? [...] Forcing you to convert mp3s to XML I'd assume: A 'Transparent' copy of the Document [is] suitable for revising the document straightforwardly with generic text editors You could do something similar for sound effects or recorded sound by dumping the FFT into XML, I think. Essentially, you'd be doing a big hex dump. No, you wouldn't. There seem to me to be plenty of ways to have an XML format for music that would be plausibly editable. Think scores and things. I don't think it could be considered straitforward to revise that with a text editor. - note timbre=trumpetC#/note + note timbre=trumpetD/note Seems pretty straightforward to me. Even if it was, a copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. Which doesn't seem to be the case. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgp65xnI58nFB.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
On Wed, Apr 30, 2003 at 06:26:07PM +0200, Henning Makholm wrote: Scripsit Stephane Bortzmeyer [EMAIL PROTECTED] Is it a consensus on debian-legal that a GFDL work *without* any Invariant or Cover is indeed free and has no problem being distributed in main? I believe so. There is some fudging about the precise definition of opaque and transparent formats, but I'm not aware that anyone thinks they would be showstoppers in and of themselves. Actually, I do. I hope this is just a bug in the license that the FSF is willing to rectify, though. The definition of a Transparent copy is so implementation-specific that a sound file can never be part of a GFDLed document. I think this is a significant restriction on modification. Richard Braakman
Re: various opinions on Debian vs the GFDL
On Thu, May 01, 2003 at 01:53:14PM +0300, Richard Braakman wrote: The definition of a Transparent copy is so implementation-specific that a sound file can never be part of a GFDLed document. I think this is a significant restriction on modification. I can't see how that's even meaningful. How do you make a soundfile part of a text document? You could accompany the GNU FDL document with a sound file, you could link a sound file from a GNU FDL web page... Making a GNU FDL document into something that's entirely sound (ie, reading it out, and including some sound effects), could matter, but that's just an opaque copy, and I don't see how you'd have any problems just including a transparent copy of the stuff that's not the sound effects on your CD. What's stopping you from doing all your music in some XML format, anyway? Apart from good sense, I mean. Forcing you to convert mp3s to XML (so that they're editable with a text editor) doesn't seem all that much worse than having to distribute changes in patch format. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpF29GEBHWG5.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
Anthony Towns wrote: I can't see how that's even meaningful. How do you make a soundfile part of a text document? I was amused the other day to find abiword, when I asked it to save a document as html, offering to inline the images in the document in base64 encoding. I'm not sure what browser can display that, perhaps only abiword can deal with images inlined in that fashion. Anyway, just extrapolate from there. -- see shy jo pgpywpC9G8QCY.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
On Thu, 2003-05-01 at 09:52, Anthony Towns wrote: I can't see how that's even meaningful. How do you make a soundfile part of a text document? It'd no longer be a plain-text document. To take a random example, you could create a HyperCard stack (ignoring that HyperCard isn't free, for a moment --- someday). What if there were a free equivalent of Quark, PageMaker, etc? The GFDL seems to have problems with (text) modifications in any format that can't be edited by a text editor. I think that needs closer inspection. You could accompany the GNU FDL document with a sound file, you could link a sound file from a GNU FDL web page... Yes, except that the FSF considers linking creating a derivative work, at least for GPL purposes. (I personally think that is silly in cases like this). No doubt the FSF would be less than happy if, e.g., you were to use IFRAME to link in more text (under a non-free license); why should sound be any different. What if you wanted to embed the sound in the document? HTML allows this... (I forget the RFC number. I'll look it up if I really have to.) What's stopping you from doing all your music in some XML format, anyway? [...] Forcing you to convert mp3s to XML I'd assume: A 'Transparent' copy of the Document [is] suitable for revising the document straightforwardly with generic text editors BTW: Has anyone noticed that one of their examples of a standard image format, XCF, isn't openable with generic paint programs; only with AFAIK GNU GIMP? signature.asc Description: This is a digitally signed message part
Re: various opinions on Debian vs the GFDL
On Thu, 2003-05-01 at 22:15, Joey Hess wrote: I was amused the other day to find abiword, when I asked it to save a document as html, offering to inline the images in the document in base64 encoding. OK, I'll dig it up... RFC2397: http://www.ietf.org/rfc/rfc2397.txt I'm not sure what browser can display that, Mozilla can. See http://www.mozilla.org/quality/networking/testing/datatests.html They even have an MP3 example. signature.asc Description: This is a digitally signed message part
Re: various opinions on Debian vs the GFDL
On Wed, 30 Apr 2003, Stephane Bortzmeyer wrote: On Wed, Apr 30, 2003 at 12:15:32AM +0200, Henning Makholm [EMAIL PROTECTED] wrote a message of 33 lines which said: ?) The GFDL is not free when applied to documents if any of the invariant or cover options are exercised. Is it a consensus on debian-legal that a GFDL work *without* any Invariant or Cover is indeed free and has no problem being distributed in main? I haven't noticed any arguments to the contrary. I'm sure anyone who does will make their views known... g - Matt
Re: various opinions on Debian vs the GFDL
On Wed, Apr 30, 2003 at 12:15:32AM +0200, Henning Makholm [EMAIL PROTECTED] wrote a message of 33 lines which said: ?) The GFDL is not free when applied to documents if any of the invariant or cover options are exercised. Is it a consensus on debian-legal that a GFDL work *without* any Invariant or Cover is indeed free and has no problem being distributed in main?
Re: various opinions on Debian vs the GFDL
On Wed, 30 Apr 2003, Stephane Bortzmeyer wrote: Is it a consensus on debian-legal that a GFDL work *without* any Invariant or Cover is indeed free and has no problem being distributed in main? I believe this is pretty well agreed. However, realize that if you release a work under the GFDL, someone else can add a cover text or invariant section, and it will then be impossible for you to incorporate their changes into your own version. I recommend using the GPL and a notice of interpretation that you consider formatted, printed works binary and machine-readable editable input source. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: various opinions on Debian vs the GFDL
Scripsit Stephane Bortzmeyer [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote ?) The GFDL is not free when applied to documents if any of the invariant or cover options are exercised. Is it a consensus on debian-legal that a GFDL work *without* any Invariant or Cover is indeed free and has no problem being distributed in main? I believe so. There is some fudging about the precise definition of opaque and transparent formats, but I'm not aware that anyone thinks they would be showstoppers in and of themselves. -- Henning Makholm So? We're adaptable. We'll *switch missions*!
Re: various opinions on Debian vs the GFDL
On 20030429T133608-0700, Mark Rafn wrote: Does anyone feel that their opinion does not roughly fall into one of the following categories? If so, it would be nice to get a short statment of opinion which stands on it's own rather than rebutting someone else's statement. You are completely missing the camp that says that documentation is software: Documents under the GFDL are software and hence must be judged by the standard set by the DFSG. (There are similar variants here as in what you discussed.) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgpkEF1RiWsRB.pgp Description: PGP signature
Re: various opinions on Debian vs the GFDL
Scripsit Mark Rafn [EMAIL PROTECTED] Does anyone feel that their opinion does not roughly fall into one of the following categories? I think my opinion fits well enough within category c: c) The GFDL would not be free if applied to software, and is not free when applied to documents. There may or may not be a distinction between the two, but it is unreasonable to have different standards of freedom or different standards of whether Debian should distribute them. But ideally I'd have liked it to be phrased ?) The GFDL is not free when applied to documents if any of the invariant or cover options are exercised. There may or may not be a distinction between software and documents, but it makes sense in itself to require freedom of documentation, just as it makes sense in itself to require freedom of software. Freedom for documents is as important as freedom for software. For certain kinds of documents, it can be argued convincingly that freedom is not important. I reply that it must be because those documents are not naturally parts of an operating system, so Debian would lose little by moving it to non-free. I suppose it's OK to tacitly overlook nonmodifyable license texts for the moment. -- Henning Makholm Det är alldeles för ansvarsfullt att skaffa en flickvän. Det är ju som att skaffa en hundvalp.
Re: various opinions on Debian vs the GFDL
On Wed, 30 Apr 2003, Antti-Juhani Kaijanaho wrote: On 20030429T133608-0700, Mark Rafn wrote: Does anyone feel that their opinion does not roughly fall into one of the following categories? If so, it would be nice to get a short statment of opinion which stands on it's own rather than rebutting someone else's statement. You are completely missing the camp that says that documentation is software: Documents under the GFDL are software and hence must be judged by the standard set by the DFSG. This is a camp which includes me. I had hoped these folks would feel included in: c) The GFDL would not be free if applied to software, and is not free when applied to documents. There may or may not be a distinction between the two, but it is unreasonable to have different standards of freedom or different standards of whether Debian should distribute them. I can split this into two if desired, to cover those who believe there is no useful distinction and those who believe there is a distinction but Debian should hold all things to the same standards of freedom. (There are similar variants here as in what you discussed.) There are likely variants of all of the points of view. I hope to keep the number of basic positions small, so the major topics can be discussed before (or concurrent to but seperately) the variations. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
