Re: Defining 'preferred form for making modifications'
Henning Makholm [EMAIL PROTECTED] writes: Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) The more worrisome case, alas, is the person who *does* keep the .xcf, but won't distribute it. No, that is the *easy* case - here we can all agree that the .xcf is source and must be distributed. Worrisome not because we disagree, but because I think it's very common.
Re: Defining 'preferred form for making modifications'
On Tuesday, Jul 1, 2003, at 03:12 US/Eastern, Thomas Bushnell, BSG wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: It's true that the GPL wording implies that there is a single preferred form, Yep. The GPL was designed for compiled programs, and it shows in several places. The relation between a xcf and a gif is precisely one of compilation. No, not at all. One important difference is that a program in source form is easily understood by a human; in object form, it is not. That's one of the big reasons we get to argue over preferred form of an image. It's pretty clear in almost every case what the preferred form of a program is; in images, it is much less so.
Re: Defining 'preferred form for making modifications'
On Tuesday, Jul 1, 2003, at 16:35 US/Eastern, Thomas Bushnell, BSG wrote: Brian T. Sniffen [EMAIL PROTECTED] writes: Nonsense. I edit multiple images into a single image all the time, but rarely save an XCF file: multiple layers live in the image-editor's memory, but never hit the disk. There is no persistent form which represents source any more than there is for a wood carving or a painting. There is, but you delete them. No, there is no persistent form. Or, to use a better word, a fixed form. Let's assume for a moment that I have to keep the otherwise temporary multiple-layered version of an image. Then I want to know which if the following I must also keep: a) Several times while editing an image, I save. Each new save is clearly a derivative work of the previous save. Do I have to keep every save as source? b) (a), but for C source c) When editing a file in vim, I often create multiple panes. Much like having multiple layers in an image, it eases editing. That set up would probably be useful to anyone else who is modifying that file. Normally these panes are destroyed when I dispose of the editor window. Are they source? d) I also use syntax coloring when editing code. If I use my own custom syntax coloring, is that part of the source? I'm particularly interested in how (a) and (b) are any different.
Re: Defining 'preferred form for making modifications'
Brian T. Sniffen [EMAIL PROTECTED] writes: Nonsense. I edit multiple images into a single image all the time, but rarely save an XCF file: multiple layers live in the image-editor's memory, but never hit the disk. There is no persistent form which represents source any more than there is for a wood carving or a painting. There is, but you delete them. This is exactly parallel to writing Scheme code in an online Scheme system, but never saving it, and then at the end, writing out a standalone executable, quitting, and destroying the source. The fact that it may be common practice to destroy the source in image editors is lamentable, but doesn't change the relationship of the parts.
Re: Defining 'preferred form for making modifications'
Thomas Bushnell, BSG said: Brian T. Sniffen [EMAIL PROTECTED] writes: Nonsense. I edit multiple images into a single image all the time, but rarely save an XCF file: multiple layers live in the image-editor's memory, but never hit the disk. There is no persistent form which represents source any more than there is for a wood carving or a painting. There is, but you delete them. This is exactly parallel to writing Scheme code in an online Scheme system, but never saving it, and then at the end, writing out a standalone executable, quitting, and destroying the source. The fact that it may be common practice to destroy the source in image editors is lamentable, but doesn't change the relationship of the parts. It certainly does: if there is no persistent form, it isn't the source. Otherwise, the elisp code which is generated (and used, but usually never seen) by programmers writing C in Emacs would have to be distributed as part of the build scripts -- I don't have to distribute C-mode, the current region stack, or ephemeral keyboard macros with my C programs, right? I'm not entirely convinced it *always* applies, but in general it seems that persistent storage is a good rule of thumb for identifying source. If I didn't save it to work on later, it isn't source, but a single act of creation. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Defining 'preferred form for making modifications'
Brian T. Sniffen [EMAIL PROTECTED] writes: It certainly does: if there is no persistent form, it isn't the source. But an xcf is not some weird thing which is not normally persistent. It is easily and trivially persistent. Otherwise, the elisp code which is generated (and used, but usually never seen) by programmers writing C in Emacs would have to be distributed as part of the build scripts -- I don't have to distribute C-mode, the current region stack, or ephemeral keyboard macros with my C programs, right? I'm not entirely convinced it *always* applies, but in general it seems that persistent storage is a good rule of thumb for identifying source. If I didn't save it to work on later, it isn't source, but a single act of creation. The more worrisome case, alas, is the person who *does* keep the .xcf, but won't distribute it. Or, for example, doesn't distribute whatever source is behind the audio patches distributed. And so forth.
Re: Defining 'preferred form for making modifications'
Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) The more worrisome case, alas, is the person who *does* keep the .xcf, but won't distribute it. No, that is the *easy* case - here we can all agree that the .xcf is source and must be distributed. -- Henning Makholm The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning.
Re: Defining 'preferred form for making modifications'
Anthony DeRobertis [EMAIL PROTECTED] writes: Well, for executable works, we have things like For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. (GPL 3) and Accompany it with the complete corresponding machine-readable source code... (GPL 3a) Right, and in the cases we are talking about, the corresponding source code is going to be more than just what can be automatically translated. Also, all of GPL 3 is about the Program (or a work based on it, under Section 2) in object code or executable form. If there is manual editing sufficient to create a derivative work (e.g., non-trivial edits of a creative nature), it is a work based on [the program], not a form of the program. Right, which is why the C source is not sufficient if the object code came from an edited version of the assembly code. Also, please remember arguing against automatic translation is very much a two-edged sword: If the corresponding source doesn't have to be automatically translatable to the object or executable form, then the corresponding source requirement becomes much weaker. Beware creating that loophole. It's got to be the *real* source, not just anything you put down and say this is the source. In the cases we are talking about, most certainly the modified assembly still has to be completely distributed. The question is does the GPL require distributing the original C code *also*? and I see no way that saying yes could open a loophole. No. Not at all! Changing a string constant is nowhere near the kind of change I'd demand for considering the object file source. That's clearly just an attempt to subvert the license, and I think any reasonable person would see through that. Sure, but I think the same of a few bit tweaks to a gif, or applying a blur transform or... well, almost anything simple. So in the original case, my point remains: that the .xcf really is the source (or part of it), even if a given person happens to want to tweak bits in the gif--and even if they in fact did tweak some bits.
Re: Defining 'preferred form for making modifications'
Anthony DeRobertis [EMAIL PROTECTED] writes: It's true that the GPL wording implies that there is a single preferred form, Yep. The GPL was designed for compiled programs, and it shows in several places. The relation between a xcf and a gif is precisely one of compilation.
Re: Defining 'preferred form for making modifications'
Thomas Bushnell, BSG said: Anthony DeRobertis [EMAIL PROTECTED] writes: It's true that the GPL wording implies that there is a single preferred form, Yep. The GPL was designed for compiled programs, and it shows in several places. The relation between a xcf and a gif is precisely one of compilation. Nonsense. I edit multiple images into a single image all the time, but rarely save an XCF file: multiple layers live in the image-editor's memory, but never hit the disk. There is no persistent form which represents source any more than there is for a wood carving or a painting. The original images might be, but I'm usually using very small subsets of them. Now, in some cases of a GIF there may be a source file, where opening the XCF and essentially hitting save as GIF will produce the object form, but it's hardly the general case. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Defining 'preferred form for making modifications'
On Wednesday, Jun 25, 2003, at 04:21 US/Eastern, Edmund GRIMLEY EVANS wrote: I think I would have to distribute both the original source and the LaTeX source and an explanation of what happened. You forgot one of the most important parts: The perl script. I'd suggest distributing the original, the script, and a diff. It's true that the GPL wording implies that there is a single preferred form, Yep. The GPL was designed for compiled programs, and it shows in several places. but in this case there seem to be several such forms, and it makes more sense to understand the GPL as referring to all of them rather than forcing a choice between them. Agreed. I'd only consider dropping the original unidirectional dictionary as source if there were extremely extensive changes (such that trying to regenerate the final work using the perl script would clearly not be preferred)
Re: Defining 'preferred form for making modifications'
On Wednesday, Jun 25, 2003, at 11:22 US/Eastern, Joe Moore wrote: Nick Phillips said: In the situation where I take a simple GPL'd C program, compile it to assembler, then hand-optimise the assembler before altering the code, initially in small ways, eventually completely re-writing the whole thing, adding huge amounts of new functionality, removing the initial functionality entirely once it becomes obsolete, and then translating the whole thing into assembler for a different architecture (the old one likewise became obsolete), then there is no well-defined point at which the C source ceases to be any kind of source for the end product, but it most certainly does happen somewhere along the way. So, you: take the GPLd orig.c, run gcc -s -o orig.s orig.c, edit (optimize) orig.s - modified.s, eventually replace all the original functionality creating new.s, orig.s is clearly a derived work, Not at all. Title 17 USC §101 says that to be a derivative work, it qualify to be an original work of authorship. Running a compiler doesn't. and distribution (if there is any) must follow the GPL. Yes, as it is object or executable form. In this case, it is clear that orig.c is the source for orig.s and the preferred form for modification is the C programming language. s/is the C programming language/is orig.c/ and we can agree. The GPL speaks of forms of the work; not languages. When you have optimized orig.s to create modified.s, then you have created a work that is derived from orig.s (and therefore orig.c) as well as your copyright. I'm assuming that the changes are substantial enough to warrant copyright. Yes, we now have a derivative work. The preferred form for modification for your changes is assembly code. The preferred form for modification for the rest of the work is the C programming language, so the source is both modified.s and orig.c.[0] If your derivative work can pretty much be seen as just patches to GCC's output, then that definitely holds. After all, it's quite reasonable and preferable to make changes in orig.c, recompile, and repatch. At some point, however, it will no longer be reasonable to do so: Making any change in orig.c will require extensive manual work to re-add in the changes from the patches. It is then clearly NOT preferred to to modify orig.c; rather, modified.s is the preferred form of modification. By the time we get to new.s, all the original code has been removed and reimplemented. Unless SCO is correct, at this point new.s will not be a derived work from orig.c, It depends on if new.s borrows an copyrightable expression from orig.c. SCO has little or nothing to do with it. However, it's not relevant; the GPL gives us permission to create derivative works. I think it's also very clear that orig.c is not the preferred form of modification in either case.
Re: Defining 'preferred form for making modifications'
Thomas Bushnell, BSG said: Joe Moore [EMAIL PROTECTED] writes: Modifying in an interesting and useful way like running strip on the binary? I don't think the GPL can be subverted so easily: Say, to change a string constant, usually pretty easy. I wish I had said that the first time around. I don't think that changing a string constant would be sufficient to create a separate copyright, but even so... In order to distribute your derived work (modified.exe), you'd have to distribute the source (orig.exe) in its preferred form (by making your change, you have established that an ELF executable is the preferred form for your change). But you can't distribute orig.exe without fulfilling the terms of the GPL, since it's a derived (compiled) work of orig.c in non-preferred form. --Joe
Re: Defining 'preferred form for making modifications'
On Wednesday, Jun 25, 2003, at 00:16 US/Eastern, Thomas Bushnell, BSG wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: Well, The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. (GPL 3) To be source code for the new version, the C original would have to: a) be a form of the (new) work b) be a the form that modifications would be made to c) it must be possible to transform the source code form into the object or executable form [implied by (b) and GPL 3(a)] There is nowhere any requirement in the GPL that source can be automatically compiled, and in cases like the ones under consideration, it cannot be. Well, for executable works, we have things like For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. (GPL 3) and Accompany it with the complete corresponding machine-readable source code... (GPL 3a) Also, all of GPL 3 is about the Program (or a work based on it, under Section 2) in object code or executable form. If there is manual editing sufficient to create a derivative work (e.g., non-trivial edits of a creative nature), it is a work based on [the program], not a form of the program. So, I think (c) is very strongly supported. GPL 3(a) says nothing about automatic transformation; it speaks of the corresponding source, but nothing says that the corresponding source must be automatically translatable. Not automatic, but nearly so. Typing a bunch of cc commands is, I think, OK; as is ./configure or maybe even editing a .h file to set defines. Also, please remember arguing against automatic translation is very much a two-edged sword: If the corresponding source doesn't have to be automatically translatable to the object or executable form, then the corresponding source requirement becomes much weaker. Beware creating that loophole. I think it's silly to say that translation to assembly is any different than translation to C, Pascal, Fortran, COBOL, BASIC, Intercal, etc., from a legal standpoint: If it's just an automated translation, it's clearly object form under the GPL, and the preferred form is still the original. If it's a largely manual translation, it's now the preferred form, object or not. It seems to me that if you are right, then there is no way to enforce the GPL: because then someone could simply modify the object file in some interesting and useful way (say, to change a string constant, usually pretty easy), and then claim that the C code isn't source at all, and thus need not be distributed. No. Not at all! Changing a string constant is nowhere near the kind of change I'd demand for considering the object file source. That's clearly just an attempt to subvert the license, and I think any reasonable person would see through that. Note how I speak of a largely manual translation above. That means that if we went through the exercise of of extracting all the copyrightable elements from both the C and the assembly versions, there would be significant, protectable differences, probably so much so that it'd be unreasonable to attempt to modify the assembly version through the C version.
Re: Defining 'preferred form for making modifications'
Anthony DeRobertis [EMAIL PROTECTED] writes: Well, The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. (GPL 3) To be source code for the new version, the C original would have to: a) be a form of the (new) work b) be a the form that modifications would be made to c) it must be possible to transform the source code form into the object or executable form [implied by (b) and GPL 3(a)] There is nowhere any requirement in the GPL that source can be automatically compiled, and in cases like the ones under consideration, it cannot be. GPL 3(a) says nothing about automatic transformation; it speaks of the corresponding source, but nothing says that the corresponding source must be automatically translatable. I think it's silly to say that translation to assembly is any different than translation to C, Pascal, Fortran, COBOL, BASIC, Intercal, etc., from a legal standpoint: If it's just an automated translation, it's clearly object form under the GPL, and the preferred form is still the original. If it's a largely manual translation, it's now the preferred form, object or not. It seems to me that if you are right, then there is no way to enforce the GPL: because then someone could simply modify the object file in some interesting and useful way (say, to change a string constant, usually pretty easy), and then claim that the C code isn't source at all, and thus need not be distributed. I submit that this is therefore clearly *not* the correct interpretation, and that in such a case, the original C code is still an essential part of the source, even though it no longer can be automatically transformed into the binaries that you are distributing.
Re: Defining 'preferred form for making modifications'
People don't edit program binaries usually, so let's take a realistic example: I produce a bidirectional bilingual dictionary using some Perl scripts that automatically generate LaTeX source for both sides of the dictionary from a marked up version of one direction. However, just before going to press I notice some errors or bad formating in the final result and I fix those problems by editing the LaTeX source rather than the original source or the Perl scripts. Now, my original source was based on someone else's GPL data, so, what do I have to distribute together with the PDF? I think I would have to distribute both the original source and the LaTeX source and an explanation of what happened. The preferred form for making modifications depends on the type of modification: to make minor local changes, the preferred form is the LaTeX; to make major global changes, such as adding a lot of new words or replacing one of the languages with a different language, the preferred form is the original marked up source. It's true that the GPL wording implies that there is a single preferred form, but in this case there seem to be several such forms, and it makes more sense to understand the GPL as referring to all of them rather than forcing a choice between them. Edmund
Re: Defining 'preferred form for making modifications'
Thomas Bushnell, BSG said: It seems to me that if you are right, then there is no way to enforce the GPL: because then someone could simply modify the object file in some interesting and useful way (say, to change a string constant, usually pretty easy), and then claim that the C code isn't source at all, and thus need not be distributed. I submit that this is therefore clearly *not* the correct interpretation, and that in such a case, the original C code is still an essential part of the source, even though it no longer can be automatically transformed into the binaries that you are distributing. Modifying in an interesting and useful way like running strip on the binary? I don't think the GPL can be subverted so easily: The stripped binary (foo_stripped.exe) is a derived work from the original binary (foo.exe). In order to distribute a derived work, you must distribute[0] the complete source. The complete source for foo_stripped.exe consists of foo.exe and the command `strip foo.exe`. In order to distribute foo.exe, though, you must distribute[0] its complete source also. That means you must distribute[0] foo.c. --Joe [0] Or give a written offer, or pass along a written offer.
Re: Defining 'preferred form for making modifications'
Joe Moore [EMAIL PROTECTED] writes: Thomas Bushnell, BSG said: It seems to me that if you are right, then there is no way to enforce the GPL: because then someone could simply modify the object file in some interesting and useful way (say, to change a string constant, usually pretty easy), and then claim that the C code isn't source at all, and thus need not be distributed. I submit that this is therefore clearly *not* the correct interpretation, and that in such a case, the original C code is still an essential part of the source, even though it no longer can be automatically transformed into the binaries that you are distributing. Modifying in an interesting and useful way like running strip on the binary? I don't think the GPL can be subverted so easily: Say, to change a string constant, usually pretty easy. I wish I had said that the first time around. Thomas
Re: Defining 'preferred form for making modifications'
Anthony DeRobertis [EMAIL PROTECTED] writes: On Monday, Jun 23, 2003, at 02:44 US/Eastern, Thomas Bushnell, BSG wrote: The reason is quite clear: because otherwise one could very trivially escape the GPL's requirements entirely, by making some little modification directly to the binary for some program, and then claiming that the binary is, ipso facto, the preferred form. No, because a reasonable person (or, more accurately, a court applying that standard) would not find that to be the preferred form of modification. In the very least, he'd have to rise to the standard of creating a derivative work. Nope: the point is that by your act of modifying it, you ipso facto demonstrate that, for that particular modification at least, you preferred it. The whole point of the third-person the preferred form is to allow just this flexibility; it is a very well understood way of legal drafting, precisely because it has a certain very well understood meaning and use. Now, very well understood is exactly another of those distanced third-person terms, and for just the same reason. The license says there is a preferred form, which might well be the union of several forms, and that this is what must be distributed. If one has not distributed a given form, then one will need to demonstrate to the court that it isn't preferred for modification, and the mere fact that you chose it as the way to make a particular modification blocks that. Thomas
Re: Defining 'preferred form for making modifications'
Henning Makholm [EMAIL PROTECTED] writes: What? Who on earth said it was illegal to edit things other than the preferred form? The GPL says that. It says that you mustn't distribute anything without giving the preferred form for it, and if we go by your premise that gifs are not the preferred form, then my modified gifs have no preferred form at all. Hence it is impossible for me to distribute them legally. I have never said that gifs are not the preferred form. I said that it is *contextual*, and depends on a particular history. The history you were considering was a .xcf (or the like), which someone then modified a few parts of in its gif output. The result is certainly within the terms of the GPL, and I believe you would be obligated to distribute both the xcf and the gif. The point is *exactly* the same as for a program: nothing about the GPL says that you cannot program in machine language; nothing says that you must modify things in C rather than machine language. Nothing in the GPL says that, but the fact that you have edited them means that you consider them, for the purpose of that edit, to be preferred. But you just claimed that the xcf is the preferred form for everyone. Please make up your mind. Precisely when the xcf is the exact source of the actual gif in question. If the gif has been modified on its own, then the source is now the combination of both the xcf and the gif. The xcf may be source for somethine, but there is no way it can be source for the modified gifs. The latter pictures look entirely different from the xcfs. Yes, it's not the sole source. The reason is quite clear: because otherwise one could very trivially escape the GPL's requirements entirely, I don't think that a loophole argument is a convincing argument for fixing an unreasonable interpretation of preferred form. So far you don't understand my interpretation, because you misstate it each time you try and reproduce it
Re: Defining 'preferred form for making modifications'
Anthony DeRobertis [EMAIL PROTECTED] writes: What I can't do is edit the image with layers in xcf, then flatten it and call that source. Or call the unedited assembly output of gcc source. NOR can you call the edited assembly the complete source. If you could, the GPL would be pointless.
Re: Defining 'preferred form for making modifications'
Henning Makholm [EMAIL PROTECTED] writes: The GPL'ed source contains ugly xpm's that upstream created pixel for pixel in Emacs because he knew no better and thought he was only making a proof-of-concept implementation anyway. I import the xpm into the Gimp, painstakingly separate the raw pixels into reasonable layers, then add nifty colors and drop shadows. Finally I merge the layers and quantisize the image, then save as xpm again. Will I be in violation of the GPL if I distribute it withough *also* saving it as xcf and distributing that? If no, would that change if it took me several editing sessions to get the look right, and I saved my intermediate work as xcf? The format you preferred to modify the work in was as a layered image. Is this not obvious, especially given the work you did in creating just that layered image? If you saved your intermediate work as xcf, and you didn't distribute it, then you are simply someone who has either refused to distribute source, or who has perhaps deliberately destroyed it. If you never saved the xpf, then I am disinclined to think this is ok. Consider the following scenario: I write a bunch of Scheme code in a fancy Scheme system, never saving my work, using only an editing buffer. When my program is as I like it, I use the system's standalone executable feature to writeout a binary of the program, and then I quit. I do not believe the resulting binary can be distributed with complete source, as the GPL requires. I do not believe this is a wild interpretation of the GPL; it seems exactly right to me. The form I actually preferred, and everyone else, is the Scheme code, not the binary.
Re: Defining 'preferred form for making modifications'
Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) Henning Makholm [EMAIL PROTECTED] writes: The history you were considering was a .xcf (or the like), which someone then modified a few parts of in its gif output. A few parts was never in the history I am talking about. Someone distributed a picture as .xcf and a flattened .gif; I wanted to change the way the picture looked, so I edited the gif. Simple as that, and no mention of a few parts at all. The point is *exactly* the same as for a program: nothing about the GPL says that you cannot program in machine language; However, you're arguing that I must not *distribute* the modified machine language unless I can somehow invent a high-level source that happens to produce my modified machine language, right? But you just claimed that the xcf is the preferred form for everyone. Please make up your mind. Precisely when the xcf is the exact source of the actual gif in question. And I'm talking about a situation where the xcf is *not* the exact source of the actual gif in question. If the gif has been modified on its own, then the source is now the combination of both the xcf and the gif. This combination idea does not make sense to me. a: The xcf does not even look like the modified gif. b: The modified gif contains all the information about how it looks itself. c: There is no way to use the xcf to reproduce the modified gif, save for manually reproducing the exact artistic choices I made while editing the gif. Thus, nobody in their right mind would prefer to use the xcf as the baseline for producing a modified version of the gif. They are two different images! The xcf may be source for somethine, but there is no way it can be source for the modified gifs. The latter pictures look entirely different from the xcfs. Yes, it's not the sole source. It is not source at all. So far you don't understand my interpretation, because you misstate it each time you try and reproduce it In that case your interpretation has been stated very hazily. Do you, or do you not, state that an xcf is somehow the source of a modified image that looks wildly different from anything that can be produced by automatic means using the xcf? -- Henning MakholmIt's kind of scary. Win a revolution and a bunch of lawyers pop out of the woodwork.
Re: Defining 'preferred form for making modifications'
Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) Henning Makholm [EMAIL PROTECTED] writes: The GPL'ed source contains ugly xpm's that upstream created pixel for pixel in Emacs because he knew no better and thought he was only making a proof-of-concept implementation anyway. I import the xpm into the Gimp, painstakingly separate the raw pixels into reasonable layers, then add nifty colors and drop shadows. Finally I merge the layers and quantisize the image, then save as xpm again. Will I be in violation of the GPL if I distribute it withough *also* saving it as xcf and distributing that? The format you preferred to modify the work in was as a layered image. Is this not obvious, especially given the work you did in creating just that layered image? If you never saved the xpf, then I am disinclined to think this is ok. Do you mean by that that if I use an editor that does not have a save format that losslessly reproduces all of its internal state, then I can only distribute the output under the GPL if I also ship a revivable core dump of the editor? I write a bunch of Scheme code in a fancy Scheme system, never saving my work, using only an editing buffer. When my program is as I like it, I use the system's standalone executable feature to writeout a binary of the program, and then I quit. Would you think anybody would be comfortable with (functionally) modifying the output of that process? I can show you dozens of people who would be perfectly comfortable with functionally modifying a gif. -- Henning MakholmI, madam, am the Archchancellor! And I happen to run this University!
Re: Defining 'preferred form for making modifications'
* Henning Makholm [EMAIL PROTECTED] [030624 13:19]: The GPL'ed source contains ugly xpm's that upstream created pixel for pixel in Emacs because he knew no better and thought he was only making a proof-of-concept implementation anyway. I import the xpm into the Gimp, painstakingly separate the raw pixels into reasonable layers, then add nifty colors and drop shadows. Finally I merge the layers and quantisize the image, then save as xpm again. Will I be in violation of the GPL if I distribute it withough *also* saving it as xcf and distributing that? The format you preferred to modify the work in was as a layered image. Is this not obvious, especially given the work you did in creating just that layered image? If you never saved the xpf, then I am disinclined to think this is ok. Do you mean by that that if I use an editor that does not have a save format that losslessly reproduces all of its internal state, then I can only distribute the output under the GPL if I also ship a revivable core dump of the editor? I think you two make the thing more complex by looking at abstract examples. To tell what your prefered form for modification is, just think what you would prefer. I case of a high-level format and a derived low-level format with manual changes, just consider you wanted to make changes in the future. If you can only imagine to take the low-level format and make further changes to it, then this is clearly the prefered form. If you would think Heck, where did I put the layered format and would use this and added the manual changes again to this, then the source is clearly the layered format and the changes (be it as some form of diff or as the low-level file incorporating them). Simple and effective... Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Defining 'preferred form for making modifications'
Henning Makholm a dit: Do you mean by that that if I use an editor that does not have a save format that losslessly reproduces all of its internal state, then I can only distribute the output under the GPL if I also ship a revivable core dump of the editor? Well, xcf does not reproduces all of GIMP internal states anyway ;) But, the real question is, if you want to edit the image later, won't it be prefered to have the xcf rather than the gif ? If it's not, then the gif can surely be free. -- Blessed are those who sit on sharp things, for they shall rise high.
Re: Defining 'preferred form for making modifications'
On Tuesday, Jun 24, 2003, at 02:16 US/Eastern, Thomas Bushnell, BSG wrote: NOR can you call the edited assembly the complete source. I disagree there. Let me make it clear that I'm taking about making major changes: so much so that the executable is substantially different from the original. Not change a few text strings. Not fix a few trivial bugs. Changes that implement major new features, and touch a good deal of the generated assembly code[0]. Changes extensive enough that a reasonable person would no longer call the C code a form of the work, but a separate work. I don't think an interpretation of the GPL that says I wrote this code in C. Forever is C must it stay! is correct. If you could, the GPL would be pointless. How so? Because someone making a change to my program could make it in a programming language I can't read? Yeah, I lose a lot of control over what people do with my software when I decide to make it Free. Tough. [0] On a file-by-file basis, as that seems to be the most granular you can do with most compilers.
Re: Defining 'preferred form for making modifications'
Anthony DeRobertis [EMAIL PROTECTED] writes: I don't think an interpretation of the GPL that says I wrote this code in C. Forever is C must it stay! is correct. Right. All I'm saying is you must distribute the C code; I don't care whether you continue to make changes in that language. How so? Because someone making a change to my program could make it in a programming language I can't read? Yeah, I lose a lot of control over what people do with my software when I decide to make it Free. Tough. It is perfectly reasonable to make the change it whatever language you wish. All I'm saying is you must continue to distribute the original source too.
Re: Defining 'preferred form for making modifications'
Henning Makholm [EMAIL PROTECTED] writes: Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) Henning Makholm [EMAIL PROTECTED] writes: The history you were considering was a .xcf (or the like), which someone then modified a few parts of in its gif output. A few parts was never in the history I am talking about. Someone distributed a picture as .xcf and a flattened .gif; I wanted to change the way the picture looked, so I edited the gif. Simple as that, and no mention of a few parts at all. In such a case, you are certainly within your rights, and if it's gpl'd you must distribute the complete source: which is the xcf and the modified gif. However, you're arguing that I must not *distribute* the modified machine language unless I can somehow invent a high-level source that happens to produce my modified machine language, right? Nope, I did not say that. So far you don't understand my interpretation, because you misstate it each time you try and reproduce it In that case your interpretation has been stated very hazily. Do you, or do you not, state that an xcf is somehow the source of a modified image that looks wildly different from anything that can be produced by automatic means using the xcf? It is *partially* the source. You have steadfastly refused to address the parallel case of a program, and I think it is this refusal that is contributing to your confusion about my position.
Re: Defining 'preferred form for making modifications'
Henning Makholm [EMAIL PROTECTED] writes: Do you mean by that that if I use an editor that does not have a save format that losslessly reproduces all of its internal state, then I can only distribute the output under the GPL if I also ship a revivable core dump of the editor? Is there such an editor? I write a bunch of Scheme code in a fancy Scheme system, never saving my work, using only an editing buffer. When my program is as I like it, I use the system's standalone executable feature to writeout a binary of the program, and then I quit. Would you think anybody would be comfortable with (functionally) modifying the output of that process? I can show you dozens of people who would be perfectly comfortable with functionally modifying a gif. I never said that a gif cannot be source. Repeat. Repeat. Repeat. Geez.
Re: Defining 'preferred form for making modifications'
On Tuesday, Jun 24, 2003, at 13:29 US/Eastern, Thomas Bushnell, BSG wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: I don't think an interpretation of the GPL that says I wrote this code in C. Forever is C must it stay! is correct. Right. All I'm saying is you must distribute the C code; I don't care whether you continue to make changes in that language. Why would C stay the preferred form for modifying a work for eternity, even when the current work bares hardly a resemblence to its C original? How so? Because someone making a change to my program could make it in a programming language I can't read? Yeah, I lose a lot of control over what people do with my software when I decide to make it Free. Tough. It is perfectly reasonable to make the change it whatever language you wish. All I'm saying is you must continue to distribute the original source too. So, essentially, you're saying that for either images or translations to other programming languages, the GPL is a original source + patches license? Does this apply to human-language translations as well? What about changes to C code in C?
Re: Defining 'preferred form for making modifications'
On Tuesday, Jun 24, 2003, at 13:30 US/Eastern, Thomas Bushnell, BSG wrote: Henning Makholm [EMAIL PROTECTED] writes: Do you mean by that that if I use an editor that does not have a save format that losslessly reproduces all of its internal state, then I can only distribute the output under the GPL if I also ship a revivable core dump of the editor? Is there such an editor? gvim is one example. It doesn't save (in the file) such things as command-line history, cursor position, hilite state, last search, window size and position, numerous option settings, etc. Many of those --- especially the command line history --- can be quite useful. I imagine emacs, being bloated, has far more.
Re: Defining 'preferred form for making modifications'
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Precisely when the xcf is the exact source of the actual gif in question. If the gif has been modified on its own, then the source is now the combination of both the xcf and the gif. Would you agree that there could come a point where the gif has been modified enough that the .xcf is no longer relevant source? While I wouldn't say this about a binary, I do think it's reasonable in the case of an image. The analogy of program used to create the image to language used to create a binary breaks down because the boundaries are harder in the case of programming languages. If an original image was created from a .xcf, but for the next 10 years all edits (and we'll assume there are plenty) were done directly to the gif, it seems reasonable to leave out the .xcf at some point. Obviously, how much is enough would be a big question mark, and it isn't reasonable to expect everyone to agree on exactly where that line falls, especially in the abstract. That's why we have judges, after all. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Defining 'preferred form for making modifications'
Anthony DeRobertis [EMAIL PROTECTED] writes: On Tuesday, Jun 24, 2003, at 13:30 US/Eastern, Thomas Bushnell, BSG wrote: Henning Makholm [EMAIL PROTECTED] writes: Do you mean by that that if I use an editor that does not have a save format that losslessly reproduces all of its internal state, then I can only distribute the output under the GPL if I also ship a revivable core dump of the editor? Is there such an editor? gvim is one example. It doesn't save (in the file) such things as command-line history, cursor position, hilite state, last search, window size and position, numerous option settings, etc. Many of those --- especially the command line history --- can be quite useful. I don't think that state is part of the text file, whereas .xcf files *are* frequently saved, copied, stored, and modified.
Re: Defining 'preferred form for making modifications'
Anthony DeRobertis [EMAIL PROTECTED] writes: On Tuesday, Jun 24, 2003, at 13:29 US/Eastern, Thomas Bushnell, BSG wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: I don't think an interpretation of the GPL that says I wrote this code in C. Forever is C must it stay! is correct. Right. All I'm saying is you must distribute the C code; I don't care whether you continue to make changes in that language. Why would C stay the preferred form for modifying a work for eternity, even when the current work bares hardly a resemblence to its C original? It is *PART* of the source. Not the whole source, but part of it. So, essentially, you're saying that for either images or translations to other programming languages, the GPL is a original source + patches license? Does this apply to human-language translations as well? What about changes to C code in C? No, that's not what I'm saying. What I'm saying is that editing a binary cannot remove your obligation to distribute the C source which produced that binary, even if you do a bunch of significant extensive edits, even if you threw away the C source.
Re: Defining 'preferred form for making modifications'
Jeremy Hankins [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Precisely when the xcf is the exact source of the actual gif in question. If the gif has been modified on its own, then the source is now the combination of both the xcf and the gif. Would you agree that there could come a point where the gif has been modified enough that the .xcf is no longer relevant source? While I wouldn't say this about a binary, I do think it's reasonable in the case of an image. The analogy of program used to create the image to language used to create a binary breaks down because the boundaries are harder in the case of programming languages. Yes, there might be such a case, but I would say that a few edits isn't such a case. And that the usual scenario isn't this at all; it's people who simply throw away the xcf or outright refuse to distribute it. Obviously, how much is enough would be a big question mark, and it isn't reasonable to expect everyone to agree on exactly where that line falls, especially in the abstract. That's why we have judges, after all. Agreed.
Re: Defining 'preferred form for making modifications'
On Tuesday, Jun 24, 2003, at 16:37 US/Eastern, Thomas Bushnell, BSG wrote: Yes, there might be such a case, but I would say that a few edits isn't such a case. And that the usual scenario isn't this at all; it's people who simply throw away the xcf or outright refuse to distribute it. Well, we can at least mostly agree on that.
Re: Defining 'preferred form for making modifications'
On Tuesday, Jun 24, 2003, at 16:36 US/Eastern, Thomas Bushnell, BSG wrote: Why would C stay the preferred form for modifying a work for eternity, even when the current work bares hardly a resemblence to its C original? It is *PART* of the source. Not the whole source, but part of it. Well, The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. (GPL 3) To be source code for the new version, the C original would have to: a) be a form of the (new) work b) be a the form that modifications would be made to c) it must be possible to transform the source code form into the object or executable form [implied by (b) and GPL 3(a)] In the scenario above, the C code clearly fails (c) for all reasonable amounts of effort[0]. It does not correspond to the executable; it can not be transformed into the executable. Because it can't be transformed into the executable, (b) fails: No one prefers to modify the wrong program! It's questionable if the C code even passes (a). Thus, since it's not the preferred form for making modifications, it's not source code (under the GPL definition). So, essentially, you're saying that for either images or translations to other programming languages, the GPL is a original source + patches license? Does this apply to human-language translations as well? What about changes to C code in C? No, that's not what I'm saying. What I'm saying is that editing a binary cannot remove your obligation to distribute the C source which produced that binary, even if you do a bunch of significant extensive edits, even if you threw away the C source. I think it's silly to say that translation to assembly is any different than translation to C, Pascal, Fortran, COBOL, BASIC, Intercal, etc., from a legal standpoint: If it's just an automated translation, it's clearly object form under the GPL, and the preferred form is still the original. If it's a largely manual translation, it's now the preferred form, object or not. [0] Its possible to recompile the C code and then re-make (by hand) all the extensive changes to the assembly output, of course.
Re: Defining 'preferred form for making modifications'
Henning Makholm [EMAIL PROTECTED] writes: In such a case, the layered format is the preferred form, Perhaps for you. Not for everybody. No, for everybody: for the simple reason that if you have distributed that, then the raw pixels of the gif are still accessible and can be edited. I wish I had said this the first time round. for the simple reason that if you have distributed that, then the raw pixels of the gif are still accessible and can be edited, But if they are not the preferred form, it is illegal to edit them (at least, it it illegal to distribute the edited gifs). So what's the point of being *able* to do so? What? Who on earth said it was illegal to edit things other than the preferred form? Nothing in the GPL says that, but the fact that you have edited them means that you consider them, for the purpose of that edit, to be preferred. Again, I'm not sure what I think about this question with respect to free software in general. But in the case of the GPL, the answer is easy: don't drop the xcf files from the distribution, period. What would that help? The xcf files are no longer the source of the gifs that are distributed. They may be source of something else, but the GPL has never required that you distribute any source but the one for the binaries you distribute. The source in this case *IS* the xcf files, and the modified gifs. The reason is quite clear: because otherwise one could very trivially escape the GPL's requirements entirely, by making some little modification directly to the binary for some program, and then claiming that the binary is, ipso facto, the preferred form.
Re: Defining 'preferred form for making modifications'
Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) Henning Makholm [EMAIL PROTECTED] writes: for the simple reason that if you have distributed that, then the raw pixels of the gif are still accessible and can be edited, But if they are not the preferred form, it is illegal to edit them (at least, it it illegal to distribute the edited gifs). So what's the point of being *able* to do so? What? Who on earth said it was illegal to edit things other than the preferred form? The GPL says that. It says that you mustn't distribute anything without giving the preferred form for it, and if we go by your premise that gifs are not the preferred form, then my modified gifs have no preferred form at all. Hence it is impossible for me to distribute them legally. Nothing in the GPL says that, but the fact that you have edited them means that you consider them, for the purpose of that edit, to be preferred. But you just claimed that the xcf is the preferred form for everyone. Please make up your mind. What would that help? The xcf files are no longer the source of the gifs that are distributed. They may be source of something else, but the GPL has never required that you distribute any source but the one for the binaries you distribute. The source in this case *IS* the xcf files, The xcf may be source for somethine, but there is no way it can be source for the modified gifs. The latter pictures look entirely different from the xcfs. The reason is quite clear: because otherwise one could very trivially escape the GPL's requirements entirely, I don't think that a loophole argument is a convincing argument for fixing an unreasonable interpretation of preferred form. -- Henning Makholm Monarki, er ikke noget materielt ... Borger!
Re: Defining 'preferred form for making modifications'
On Sunday, Jun 22, 2003, at 08:11 US/Eastern, Henning Makholm wrote: But if they are not the preferred form, it is illegal to edit them (at least, it it illegal to distribute the edited gifs). So what's the point of being *able* to do so? If you merge the layers of an image, then edit pixel-by-pixel the resulting image, the edited version is now the preferred form --- it must be, because it's the ONLY form. No other form contains the same, or substantially same, information. It's the same thing as if I convert the code from Pacal to C (even automatically), then edit that. What I can't do is edit the image with layers in xcf, then flatten it and call that source. Or call the unedited assembly output of gcc source.
Re: Defining 'preferred form for making modifications'
On Monday, Jun 23, 2003, at 02:44 US/Eastern, Thomas Bushnell, BSG wrote: The reason is quite clear: because otherwise one could very trivially escape the GPL's requirements entirely, by making some little modification directly to the binary for some program, and then claiming that the binary is, ipso facto, the preferred form. No, because a reasonable person (or, more accurately, a court applying that standard) would not find that to be the preferred form of modification. In the very least, he'd have to rise to the standard of creating a derivative work. OTOH, a if he made substantial changes, it would be.
Re: Defining 'preferred form for making modifications'
Scripsit Anthony DeRobertis [EMAIL PROTECTED] On Sunday, Jun 22, 2003, at 08:11 US/Eastern, Henning Makholm wrote: But if they are not the preferred form, it is illegal to edit them (at least, it it illegal to distribute the edited gifs). If you merge the layers of an image, then edit pixel-by-pixel the resulting image, the edited version is now the preferred form --- it must be, because it's the ONLY form. No other form contains the same, or substantially same, information. That was the point I was trying to make. What I can't do is edit the image with layers in xcf, then flatten it and call that source. OK, then lets turn the complexity up a notch: The GPL'ed source contains ugly xpm's that upstream created pixel for pixel in Emacs because he knew no better and thought he was only making a proof-of-concept implementation anyway. I import the xpm into the Gimp, painstakingly separate the raw pixels into reasonable layers, then add nifty colors and drop shadows. Finally I merge the layers and quantisize the image, then save as xpm again. Will I be in violation of the GPL if I distribute it withough *also* saving it as xcf and distributing that? If no, would that change if it took me several editing sessions to get the look right, and I saved my intermediate work as xcf? -- Henning Makholm Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere.
Re: Defining 'preferred form for making modifications'
On Fri, Jun 20, 2003 at 02:03:30PM -0500, Steve Langasek wrote: SL I really don't think that the form that contains the *most* SL information is necessarily the best, because this prevents someone SL from improving the source by removing *extraneous* information. If SL two forms of source code compile to give identical binaries, which SL form contains more information -- the one with pointless comments SL and more KLOCs, or the one that's more concise and easier to read? Another case to the point that the source is _both_ versions together, in chronological order. Also, if you want to use 'the most informative' as a guideline to determining the 'preferred form for making modifications', revision history is definitely more informative than either of these versions alone. -- Dmitry Borodaenko
Re: Defining 'preferred form for making modifications'
Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) Henning Makholm [EMAIL PROTECTED] writes: Some people would prefer to edit a layered format, because it gives them better control and allow them to change the semantic contents of the image without losing any overlaid effects. Other people, however, would honestly prefer to edit the raw pixels of the gif, because they don't want to learn how to use an advanced layered editor. In such a case, the layered format is the preferred form, Perhaps for you. Not for everybody. for the simple reason that if you have distributed that, then the raw pixels of the gif are still accessible and can be edited, But if they are not the preferred form, it is illegal to edit them (at least, it it illegal to distribute the edited gifs). So what's the point of being *able* to do so? Again, I'm not sure what I think about this question with respect to free software in general. But in the case of the GPL, the answer is easy: don't drop the xcf files from the distribution, period. What would that help? The xcf files are no longer the source of the gifs that are distributed. They may be source of something else, but the GPL has never required that you distribute any source but the one for the binaries you distribute. -- Henning Makholm I Guds Faders namn, och Sonens, och den Helige Andes! Bevara oss från djävulens verk och från Muhammeds, den förbannades, illfundigheter! Med dig är det värre än med någon annan, ty att lyssna till Muhammed är det värsta av allt.
Re: Defining 'preferred form for making modifications'
Florian Weimer [EMAIL PROTECTED] writes: Sam Hartman [EMAIL PROTECTED] writes: Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was? I know of one Debian package whose source code is the output of a CASE tool (a literate programming tool). I suspect that there are more. Which package, please?
Re: Defining 'preferred form for making modifications'
Jeremy Hankins [EMAIL PROTECTED] writes: The difference is that a gif is a lot richer than binary software, in the sense of humans being able to do stuff with it. This is a real difference. So we have two ways of distinguishing between binary and source: Way one says that binaries cannot be reasonably modified, whereas source can. Way two says that source is the preferred form for modification, and binaries are not. For C code vs. machine language, these give the same answer. I would agree that for other situations, including the case we are considering about images, way number one would allow for more things to be source than the second way. *But*, and this is, *once again*, my point: the GPL clearly and unequivocally goes for the second way. In that context, there is no doubt that it doesn't matter whether the form given *can* be usefully modified or used or whatever. The GPL's definition is perfectly unambiguous as it is, and, I think, perfectly reasonable for a copyleft. I have not yet decided what I think about the broader case of defining free software. I can certainly see the argument that under certain circumstances a gif would be considered a binary and something like a .xcf would be required source (for copyleft). But I think it's quite a stretch to say that that's always the case. That's exactly why the phrase preferred form is so important. Some of the boundary cases would have to be decided on a situational basis; that's not a reason to say that gifs can't be copyleft unless they have accompanying source. I have never said that a gif can't be copyleft. A gif might be the actual source. Similarly, assembly language is usually not source, but sometimes indeed it is. In some weird cases, both C and assembly might *together* be the source: for example, where the assembly is a human-modified version of what the C compiler produced.
Re: Defining 'preferred form for making modifications'
Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) Way two says that source is the preferred form for modification, and binaries are not. Yes, but it is not unambiguous what this would result in in the case of graphics. Some people would prefer to edit a layered format, because it gives them better control and allow them to change the semantic contents of the image without losing any overlaid effects. Other people, however, would honestly prefer to edit the raw pixels of the gif, because they don't want to learn how to use an advanced layered editor. I'm not sure whether the GPL must be interpreted that such that the second group of people may not edit gifs that originate as, say, xcf's at all. But in case it does, I advocate that we don't extend this interpretation to DFSG as a whole. Say, for example, some softare is BSD-licensed and comes with some images as gifs as well as theyr xcf source. Somebody forks the package but, not willing to learn how to use the Gimp, he edits the gifs directly. Then he drops the xcf's from his distribution; they have become severly out of sync with the gifs anyway. Should we then reject the forked software from Debian main, on grounds it does not contain source for the gifs? I say no. -- Henning Makholm Jeg har skabt lammeskyer, piskeris, fingerspidsfornemmelser, polarkalotter, loddenhed, vantro, rutenet, skumtoppe, datid, halvdistancer, restoplag, gigt, pligtdanse, græsrødder, afdrift, bataljer, tyrepis, løvfald, sideblikke, hulrum, røjsere, mislyd, loppetjans, øer, synsrande...
Re: Defining 'preferred form for making modifications'
Henning Makholm [EMAIL PROTECTED] writes: Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG) Way two says that source is the preferred form for modification, and binaries are not. Yes, but it is not unambiguous what this would result in in the case of graphics. Some people would prefer to edit a layered format, because it gives them better control and allow them to change the semantic contents of the image without losing any overlaid effects. Other people, however, would honestly prefer to edit the raw pixels of the gif, because they don't want to learn how to use an advanced layered editor. In such a case, the layered format is the preferred form, for the simple reason that if you have distributed that, then the raw pixels of the gif are still accessible and can be edited, by doing a simple conversion process. Though, I would not be adverse to saying that perhaps both ought to be regarded as source in some cases. Say, for example, some softare is BSD-licensed and comes with some images as gifs as well as theyr xcf source. Somebody forks the package but, not willing to learn how to use the Gimp, he edits the gifs directly. Then he drops the xcf's from his distribution; they have become severly out of sync with the gifs anyway. Should we then reject the forked software from Debian main, on grounds it does not contain source for the gifs? I say no. Again, I'm not sure what I think about this question with respect to free software in general. But in the case of the GPL, the answer is easy: don't drop the xcf files from the distribution, period. End of problem. Thomas
Re: Defining 'preferred form for making modifications'
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Again, again, again, I'm not interested here in the definition of free or proprietary; just with the copyleft. In the context of the copyleft, if you destroy the source, the object code does not somehow mutate into source, and as a result the object code simply cannot be part of a copylefted program. I can see no good reason for distinguishing C code from .xcf files here. The difference is that a gif is a lot richer than binary software, in the sense of humans being able to do stuff with it. I can certainly see the argument that under certain circumstances a gif would be considered a binary and something like a .xcf would be required source (for copyleft). But I think it's quite a stretch to say that that's always the case. That's exactly why the phrase preferred form is so important. Some of the boundary cases would have to be decided on a situational basis; that's not a reason to say that gifs can't be copyleft unless they have accompanying source. I admit to being a bit confused about the positions everyone's taking in this thread, though, so I may not be responding precisely to your point. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Defining 'preferred form for making modifications'
On Tue, Jun 17, 2003 at 02:47:58PM +0200, Thomas Hood wrote: Objection #1: The license must not force the licensee to keep around old crufty versions of the source. Answer: Using my definition, it doesn't. The licensee is only required to provide the most informative form at his disposal. Does this mean that he can destroy his source files and then not distribute source? I really don't think that the form that contains the *most* information is necessarily the best, because this prevents someone from improving the source by removing *extraneous* information. If two forms of source code compile to give identical binaries, which form contains more information -- the one with pointless comments and more KLOCs, or the one that's more concise and easier to read? Yes; but that isn't a problem: if the source has really been destroyed, then no license will bring it back; and we don't want to punish people for losing their source files; and we don't want to rule out the distribution of binaries for which the sources have disappeared. On the contrary, I *do* want to prevent people from claiming such a sourceless program is free software. -- Steve Langasek postmodern programmer pgp0VOnuUNXzv.pgp Description: PGP signature
Re: Defining 'preferred form for making modifications'
Sam Hartman [EMAIL PROTECTED] writes: Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was? I know of one Debian package whose source code is the output of a CASE tool (a literate programming tool). I suspect that there are more.
Re: Defining 'preferred form for making modifications'
On Wed, Jun 18, 2003 at 02:19:12PM -0700, Thomas Bushnell, BSG wrote: snip I'd say this is a pretty strong argument for why we shouldn't talk about preferred forms at all in our definition of freedom. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpfCVWhIcfk9.pgp Description: PGP signature
Re: Defining 'preferred form for making modifications'
On Thu, Jun 19, 2003 at 09:41:55AM +0100, Andrew Suffield wrote: On Wed, Jun 18, 2003 at 02:19:12PM -0700, Thomas Bushnell, BSG wrote: snip I'd say this is a pretty strong argument for why we shouldn't talk about preferred forms at all in our definition of freedom. I agree. It's just too complex an issue for the simple concepts that my proposed Five Freedoms document is designed for. Since writing it didn't get me flamed to hell, I'll see if I can cook up a revised version at some point soon. -- G. Branden Robinson| One man's magic is another man's Debian GNU/Linux | engineering. Supernatural is a [EMAIL PROTECTED] | null word. http://people.debian.org/~branden/ | -- Robert Heinlein pgpDPvS9vmgrU.pgp Description: PGP signature
Re: Defining 'preferred form for making modifications'
Mark Rafn [EMAIL PROTECTED] writes: There are a number of icons and images in products whose original creator preferred to edit in photoshop, with crazy psd files that contain layering, gamma, and other useful information. I made further modifications to the resulting GIF file. My preferred form is gif, hers is psd. I don't even have the psd anymore. On Wed, 18 Jun 2003, Thomas Bushnell, BSG wrote: The .psd is the source. Some people prefer to hack on binary code too, but this is really the same case as that one, except that more people hack .gif than binary code. So I cannot release the GIF freely, given that the PSD no longer exists? But the fact that there are people who prefer to hack binary code (indeed, the fact that it's sometimes useful and valuable) doesn't at all mean that the binary code is therefore source in the context of the copyleft. Can my gif file ever be free? Can her psd file be free if it's in an undocumented format which is only editable in a proprietary tool? Once again, I'm only talking about GPL concerns. It's clear to me that she cannot add the gif to a GPL'd program and refuse to distribute the .psd file. Interesting. I suspect we have some things currently in debian that violate the GPL if this is the common consensus. Additionally, consider that the work was for hire, so I'm the copyright holder, and I didn't keep the psd. Is this gif file forever proprietary because I cannot provide source? Otherwise, consider the disaster: Someone creates a programmatic font, making use of GPL'd code. But they want to keep their program seekrit. So they compile font images, and then tweak a few bits on the bitmaps, claiming now that the bitmaps are the preferred form for modifications, and then refuse to distribute the program. This cannot be permitted! Is intent the deciding factor here? Intentional obfuscation is evil and should be disallowed. Loss of information due to actual edits IMO should be allowed. So we must judge the bitmaps alone to *not* meet the source code requirement (whether or not they have in fact been modified from what the source first produced), and this must be true not just for the person who did the tweaking, but for everyone who got the bitmaps from them. In the case of actual edits, though (I take bitmaps produced algorithmically and make significant bitmap updates), this leads to the strange requirement to provide some bizarre source files that don't produce anything near what you're distributing. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: Defining 'preferred form for making modifications'
(I apologize for the fact that this won't thread. Future messages should thread properly.) I agree that for the purposes of writing guidelines, it is not necessary to be either precise or objective. Therefore my comments below relate to the definition of 'preferred form ...' in the context of license texts. I have decided to reply to many postings in summary form. License texts must be objective, fair and reasonably precisely worded if they are to be enforceable. The question at hand is: In those licenses that dictate that the distributor of a binary must also distribute the source of that binary in the preferred form for making modifications, what does 'preferred' mean? A reply was made against this question demanding to know why it should be answered: What problem does this solve? The answer is that answering the question would at least clear up the confusion evidenced by the variety of different responses to the question in debian-legal. Perhaps answering the question will lead to better wording in future free software licenses. Another reply claimed that the answer is obvious. I don't think so, as evidenced again by the fact that people are disagreeing widely about the answer. A third objection was that the question should not be answered because the license works best if it is vague and subject to interpretation. Answer: Vague terms can be the right ones to use when expressing a vague understanding of a complex situation. However, precise terms are usually better than vague ones in a legal document. If one ever tries to enforce the license, the benefit of doubt is on the side, first, of the richer party (because doubt generates legal costs) and second, of the licensee (because a violation must clearly have occurred before a court will find against the licensee). A fourth objection was that courts will define the term in practice by means of a reasonable man test. But this begs the question of what objective basis the reasonable man would use for his reasoning. Surely that is something we should think about here. In any case, people have suggested several different definitions. One definition of 'preferred' that was suggested was, in effect, 'liked most by the licensee'. Such a license would allow the distributor to distribute whatever he liked. Another definition was: 'liked most by the distributee'. Such a license would not be fair to the distributor. Another definition might be: 'liked most by the licenser'. This seems to give authors too much control over the descendents of their work. Another definition was: 'liked most by us'. That isn't acceptable because it depends on whom 'us' refers to. I suggested that the term be defined, roughly, as 'the form of the program available to the distributor containing the most information'. A number of objections were raised against this suggestion, which I will now discuss. Objection #1: The license must not force the licensee to keep around old crufty versions of the source. Answer: Using my definition, it doesn't. The licensee is only required to provide the most informative form at his disposal. Does this mean that he can destroy his source files and then not distribute source? Yes; but that isn't a problem: if the source has really been destroyed, then no license will bring it back; and we don't want to punish people for losing their source files; and we don't want to rule out the distribution of binaries for which the sources have disappeared. Objection #2: This definition would make it harder to produce free software using non-free tools. Answer: If your codebase is in a proprietary format and you work on this using proprietary tools, and you release binary and source in a non-proprietary format, then you are indeed in violation of the license. Good. The GPL contains one important limitation of what can be done with licensed code: No Distribution of Binaries Derived From This Without Providing Source. Why does it have that prohibition? In order to prevent private parties from taking possession of free code through an embrace-and-extend strategy. Your proprietary codebase gives you an advantage over the rest of the free software community: perhaps enough of an advantage that effectively people will be forced to pay you to make changes. Aha! Do you plead that your contract with your tool vendor doesn't allow you to make your codebase available along with the tools for developing in it? Too bad: you can't distribute. The GPL is very clear about this. Objection #3: Source code can be obfuscated without loss of information. Imagine a developer has a source file S and generates from it a release version R by running it through an obfuscator. He releases R, satisfying the requirement, but clearly hasn't released the preferred form! Answer: This is a useful case to consider. The obfuscator could be an encryptor. Clearly, if R is an encrypted form of S then R is not the preferred form unless the key is also
Re: Defining 'preferred form for making modifications'
On Tue, Jun 17, 2003 at 02:47:58PM +0200, Thomas Hood wrote: Objection #2: This definition would make it harder to produce free software using non-free tools. Answer: If your codebase is in a proprietary format and you work on this using proprietary tools, and you release binary and source in a non-proprietary format, then you are indeed in violation of the license. Good. The GPL contains one important limitation of what can be done with licensed code: No Distribution of Binaries Derived From This Without Providing Source. Why does it have that prohibition? In order to prevent private parties from taking possession of free code through an embrace-and-extend strategy. Your proprietary codebase gives you an advantage over the rest of the free software community: perhaps enough of an advantage that effectively people will be forced to pay you to make changes. Aha! Do you plead that your contract with your tool vendor doesn't allow you to make your codebase available along with the tools for developing in it? Too bad: you can't distribute. I consider this to be an unreasonable restriction, and an inaccurate interpretation of the GPL. For example, as you have described it, it prohibits storing a GPLed application in a bitkeeper repository. Oops. The GPL is very clear about this. No it isn't. It is, at best, murky; a good lawyer should have no trouble getting a ruling the other way. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgp4pwsNfyF8b.pgp Description: PGP signature
Re: Defining 'preferred form for making modifications'
Thomas Hood [EMAIL PROTECTED] writes: License texts must be objective, fair and reasonably precisely worded if they are to be enforceable. This is mostly true, but it is very important to understand that we are talking about *legally* objective, fair, precise. Such things as the preferred form are very normal legal terms, with quite precise standards to be applied. The question at hand is: In those licenses that dictate that the distributor of a binary must also distribute the source of that binary in the preferred form for making modifications, what does 'preferred' mean? Prefer is a perfectly normal English word, I really don't think it's that ambiguous. The preferred form is the form in which people actually (REALLY ACTUALLY) prefer to make modifications. A given format might be preferred for one case, but the same technical format not be preferred for another case. The chief obstacle you point to is that we wonder preferred *by whom*? For the life of me, I cannot think of a case where the *real* preferences would differ depending on who is being measured. It seems to me that *everyone* would prefer modifying the C code for Emacs to modifying the assembly code. Can you give a case where the alleged ambiguity actually comes up? It's not which form do you like most, or even which form do you prefer, but much more specific: which form do you prefer for making modifications, and the use of the passive, is preferred, appeals to a general practice for making modifications to similar works, which general practice, in fact, really does exist. I suggested that the term be defined, roughly, as 'the form of the program available to the distributor containing the most information'. If this form is really the one most preferred for making changes, then you have changed nothing. If it's *not* the most preferred form in any case, then why should we accept it? Thomas
Re: Defining 'preferred form for making modifications'
J.D. Hood [EMAIL PROTECTED] writes: I suggest that the definition of 'preferred form for making modifications' be information-theoretical. No. It is *human*, and focused on actual, real, genuine, human preferences. This is far better than trying to find a specific technical definition of those preferences: much better instead to use the actual standard--that is, whatever format is actually preferred--rather than attempt (perhaps badly) to find a technical definition of the same thing.
Re: Defining 'preferred form for making modifications'
Richard Braakman [EMAIL PROTECTED] writes: On Sun, Jun 15, 2003 at 05:15:14PM -0400, Sam Hartman wrote: Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was? I know of one thorny problem in this area: many graphics are distributed as .png or .jpg files, even though their creator probably used a richer format like .xcf. Is it not obvious that the preferred form is .xcf?
Re: Defining 'preferred form for making modifications'
J.D. Hood said: I suggest that the definition of 'preferred form for making modifications' be information-theoretical. When source code is compiled into binary code there is a loss of information, as indicated by the fact that you cannot get the original source back, given only the binary code. On the other hand, if there is a set of different forms each of which is convertible into the others by means of freely available tools then any member of the set is as good as any other. Unfortunately, there is a class of tools which do not meaningfully change source code, but result in an information-theoretical loss. indent(1) is a prime example of this class. Running indent(1) on Free Source should not make it non-Source. There is also a class of tools which makes source effectively unmodifiable, but is not information-theoretically lossy. For example, an obfuscator which translates everything to C trigraphs. Running this on Free Source makes it non-Source. Finally, there is a very lossy conversion which must be Free, and that is linguistic translation. --Joe
Re: Defining 'preferred form for making modifications'
On Mon, Jun 16, 2003 at 04:10:16PM +0200, Thomas Hood wrote: Thomas Bushnell wrote: No. It is *human*, and focused on actual, real, genuine, human preferences. This is far better than trying to find a specific technical definition of those preferences: much better instead to use the actual standard--that is, whatever format is actually preferred--rather than attempt (perhaps badly) to find a technical definition of the same thing. The focus on human preferences tends to end up either in subjective assessments or in speculation about what other people prefer. Should these questions be settled by conducting surveys? Absolutely not. It is essential that the preference be the *personal* preference of the person who made modifications to the code (not the person who *wishes* to modify the code; such a one should not have the power to impose his personal preference on the person he got the code from). Joe Moore [EMAIL PROTECTED] wrote: Unfortunately, there is a class of tools which do not meaningfully change source code, but result in an information-theoretical loss. indent(1) is a prime example of this class. Running indent(1) on Free Source should not make it non-Source. In general if you possess both a non-indent(1)ed version of the program you are distributing and version of the program that you have run through indent(1), then I want the non-indent(1) ed version. It is quite possible that the hand-indented version is easier to read than the version that has been run through indent(1). If not then I can run indent(1) on it myself; whereas if you give me the indented(1) version then I can't get the hand-indented version back. But I should have the right to discard the screwball hand-indented format of the file after I've run indent(1) over it, make my modifications, and distribute the modified work without having to worry about your indenting preferences. The manually indented file may contain additional information, but the only information I see there is the author of this file has sloppy indenting practices, which I don't find useful to keep around. -- Steve Langasek postmodern programmer pgpLubzae1pMu.pgp Description: PGP signature
Re: Defining 'preferred form for making modifications'
Thomas Hood said:
Joe Moore [EMAIL PROTECTED] wrote:
Finally, there is a very lossy conversion which must be Free,
and that is linguistic translation.
Nope. If you are distributing the binary with English UI then
I don't want the source with the UI translated lossily into
Romanian.
You've misinterpreted what I meant. I'm not referring to the UI, I'm
referring to the source.
Take the following code (written by someone who only understands english):
int number_of_people = 1;
while ( number_of_people full_room ) {
add_person(conference_room);
number_of_people++;
}
and I make it useful for my french friend who doesn't speak english:
int nombre_de_gens = 1;
while ( nombre_de_gens chambre_pleine ) {
adjouter_gen(chambre);
nombre_de_gens++;
}
Now, my friend wants to make improvements, and distribute the results in the
preferred form. Is the preferred for english or french? There is no
lossless transformation between them.
--Joe
Re: Defining 'preferred form for making modifications'
Thomas Hood [EMAIL PROTECTED] writes: The focus on human preferences tends to end up either in subjective assessments or in speculation about what other people prefer. Should these questions be settled by conducting surveys? There's nothing wrong with subjectivity -- note that the debian-legal process is based on a subjective analysis of licenses. That analysis is grounded in the DFSG, but it's inherently (and intentionally) subjective, very much unlike, for example, the OSD. If it were possible to turn the DFSG into something objective, it might be appropriate to argue the merits of doing so, and then come up with a new, objective, DFSG. But that's a considerably more ambitious project that anyone's suggested, and I doubt you'd find many people who think it could even work. I think preferred form makes a lot of sense. It captures the spirit of the idea, it preserves the inherent fuzziness of the issue faithfully, and doesn't try to answer questions that are very, very hard to answer in the abstract but generally trivial under specific circumstances. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Defining 'preferred form for making modifications'
On Mon, Jun 16, 2003 at 04:10:16PM +0200, Thomas Hood wrote: J.D. Hood wrote: On the other hand, if there is a set of different forms each of which is convertible into the others by means of freely available tools then any member of the set is as good as any other. Andrew Suffield [EMAIL PROTECTED] wrote: What if the program is written using proprietary tools and formats, and translated into commented, maintainable C/java for release? By hypothesis we have free tools that convert the C/java program into the proprietary format. So if the proprietary is the format you want to use, simply convert it into that format. You are happy. You cannot modify reality to suit yourself in this fashion. Such tools will generally not exist, in either proprietary or free versions. In general, you are attempting to introduce a prejudice against creating free software with non-free tools; I do not consider such a restriction appropriate. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpuTxfwibZTm.pgp Description: PGP signature
Re: Defining 'preferred form for making modifications'
Thomas Hood [EMAIL PROTECTED] writes: Richard Braakman [EMAIL PROTECTED] writes: I know of one thorny problem in this area: many graphics are distributed as .png or .jpg files, even though their creator probably used a richer format like .xcf. Thomas Bushnell wrote: Is it not obvious that the preferred form is .xcf? I think it is obvious because we do prefer the informationally richer format. My suggestion is that this be made explicit. Suppose in one case we prefer format X, but the informationally richer format happens to be Y. In this case, shouldn't we preserve the one we prefer? Either your standard will be the same as the current one, or it will be different. If it's the same, then no advantage inheres from adopting it. If it's different, then you need to explain why it's better. The focus on human preferences tends to end up either in subjective assessments or in speculation about what other people prefer. Should these questions be settled by conducting surveys? No; in general courts apply things like the reasonable man test. Remember, we are talking about a legal document here, not a network protocol. The ability to be responsive to subjective assessments is precisely why the current language is excellent. Thomas
Re: Defining 'preferred form for making modifications'
On Monday, Jun 16, 2003, at 10:10 US/Eastern, Thomas Hood wrote: In general if you possess both a non-indent(1)ed version of the program you are distributing and version of the program that you have run through indent(1), then I want the non-indent(1) ed version. Generally, one doesn't run indent just for the hell of it. One runs indent because the indentation is horrible, and he wants to modify it. So, likely, the source is indent'd then modified.
Re: Defining 'preferred form for making modifications'
On Sun, Jun 15, 2003 at 10:41:24PM -0700, Thomas Bushnell, BSG wrote: Richard Braakman [EMAIL PROTECTED] writes: On Sun, Jun 15, 2003 at 05:15:14PM -0400, Sam Hartman wrote: Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was? I know of one thorny problem in this area: many graphics are distributed as .png or .jpg files, even though their creator probably used a richer format like .xcf. Is it not obvious that the preferred form is .xcf? It is preferred, but does that make the other formats non-free? Often the .xcf is simply not available anymore, not even to the creator. The strength of the preference for it depends on the complexity of the image and on the exact format (lossy jpeg? blurred png? reduced palette?). It's an area where reasonable people might disagree. There are also variations in usefulness of a .xcf file. Does it have all the layers still separate, or have some of them been merged and smoothed? Combining those layers into the final image is often part of the creative process and is usually not automated. At least, not the way I do it :) Richard Braakman
Re: Defining 'preferred form for making modifications'
Richard Braakman [EMAIL PROTECTED] writes: Is it not obvious that the preferred form is .xcf? It is preferred, but does that make the other formats non-free? I'm not sure. The talk about preferred form first comes up in the requirement of the GPL to provide source. I don't know whether or not the same restriction is the right one in defining free software in general. I was just answering the claim that the term is somehow hopelessly vague. In the context it was originally used, the copyleft, it's just fine. Often the .xcf is simply not available anymore, not even to the creator. The strength of the preference for it depends on the complexity of the image and on the exact format (lossy jpeg? blurred png? reduced palette?). It's an area where reasonable people might disagree. If it isn't available at all, then that's an entirely different question from what if it is available, but a different format is being provided instead. If there is no longer any source code for a program, can the binary still be free software on its own? I don't know the answer, but that's the question. I don't see how the answer is different for image formats than executable programs. The point is that yes, there are unusual cases where it isn't clear exactly which form is preferred. This is precisely why the current language in the GPL is good: because it allows for human beings to try and make reasoned judgments about it, rather than be boxed in by a needlessly too-narrow technical definition. There are also variations in usefulness of a .xcf file. Does it have all the layers still separate, or have some of them been merged and smoothed? Combining those layers into the final image is often part of the creative process and is usually not automated. At least, not the way I do it :) The preferred form for modifications, again, is the *preferred* one. It's the form you would *actually* prefer to use in *modifying* the thing. In general, that's going to be an unflattened .xcf. It is the case that many people make images and then completely destroy the source. This is a shame, and we should stress that it's contrary to the general principles of preserving and providing source. At least in the case of the GPL, it just isn't the preferred form for making modifications, and (again, in the GPL context) I don't think we can allow I lost track of where the source is to count as an exception, much less I deliberately destroyed the source. Thomas
Re: Defining 'preferred form for making modifications'
J == J D Hood [EMAIL PROTECTED] writes: J I suggest that the definition of 'preferred form for making J modifications' be information-theoretical. Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was?
Re: Defining 'preferred form for making modifications'
On Sun, Jun 15, 2003 at 05:15:14PM -0400, Sam Hartman wrote: Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was? I know of one thorny problem in this area: many graphics are distributed as .png or .jpg files, even though their creator probably used a richer format like .xcf. IIRC, there was also a case of a ROM image that was released into the public domain, but the source for it no longer existed. I don't remember enough details to search for it, though. Richard Braakman
Re: Defining 'preferred form for making modifications'
On Sun, Jun 15, 2003 at 07:47:32PM +0100, J.D. Hood wrote: I suggest that the definition of 'preferred form for making modifications' be information-theoretical. When source code is compiled into binary code there is a loss of information, as indicated by the fact that you cannot get the original source back, given only the binary code. On the other hand, if there is a set of different forms each of which is convertible into the others by means of freely available tools then any member of the set is as good as any other. What if the program is written using proprietary tools and formats, and translated into commented, maintainable C/java for release? (Not a straw man; the technologies are being developed and we're going to start seeing them over the next few years. One-dimensional text is not the most effective representation of a program, it's just the easiest to implement) -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpuQrasSc4pO.pgp Description: PGP signature
