Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005, David Nusinow wrote: This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. If the guys at Nvidia maintain the driver by referring to a separate copy of the hardware specs and copying numbers from it into the driver when needed, then the hardware specs are external to the source code of the driver. If the guys at Nvidia maintain the driver by maintaining a version of the code which has symbols in it, and give the driver to us by removing the symbols, then to the extent which the symbols provide information about the specs, the specs are *not* external to the source of the driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 10:40:36AM +0100, Matthew Garrett wrote: Machine generated assembly is, in general, significantly less modifiable than hand-written assembly. And code in which information that the original coder inserted has been removed is less modifiable than code written without that information in the first place. Can give you a good reason why the two situations we described are significantly different? -Peff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 09:50:56AM -0700, Ken Arromdee wrote: On Sat, 23 Jul 2005, David Nusinow wrote: This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. If the guys at Nvidia maintain the driver by referring to a separate copy of the hardware specs and copying numbers from it into the driver when needed, then the hardware specs are external to the source code of the driver. If the guys at Nvidia maintain the driver by maintaining a version of the code which has symbols in it, and give the driver to us by removing the symbols, then to the extent which the symbols provide information about the specs, the specs are *not* external to the source of the driver. But understanding it is contingent on those specs. You have all the rights to modify the code that is the nv driver as it is under a Free license. Upstream also likely keeps the driver in revision control with its own set of comments and metadata that they use to maintain the driver, but not having access to that does not qualify the thing as non-free. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Matthew Garrett: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, We had a GR that is usually interpreted in a manner which disagrees with you. Certainly we require that the DFSG apply to documentation. As I've stated repeatedly, nothing in that GR grants us permission to exempt fonts, artwork or cryptographic certificates from the source code requirements. The certificates part might be somewhat drastic, but I think that it's highly desirable to have source code for all the technical documentation we ship, under reasonably permissive licenses, so that we can update it as needed. This obviously includes technical artwork. Looking at the gsfonts bugs, there even is a completely *technical* justification to have the source code equivalent for fonts. Similar things might happen with artwork whose vectorized (or non-flattened) version we do not require. and it's trivial to demonstrate that this isn't the current situation (see the nv driver in the X.org source tree, for instance). I think the last time the nv reference popped up, nobody could confirm that the source code has been deliberately obfuscated. It seems to be the real thing, but there is not enough public documentation to make any modifications which change the way the driver interacts with the hardware. The DFSG require the availability of source code, and it seems reasonable to believe that anything that can be reasonably modified falls into that catagory. The graphics are available in a form that can be modified with free tools (the .xpm files). Modifiying them is like patching object code. It can be done, but we have chosen not do it that way. We can choose differenly for artwork, of course, but I'm not sure if it's desirable to do so. Some practical limits obviously exist, though, but they don't apply to ray-traced images. 2) Does a GPLed work have to include the preferred form of modification? Probably, and this may include the source code for the graphics. However, this may also be affected by the copyright holder's interpretation of the preferred form of modification and whether the GPLed code is a derived work of the graphics or not. On the other hand, if we accept my opinion on point (1), even if we need to include the pov-ray models we are not required to build from them in order to satisfy the DFSG. I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Florian Weimer ([EMAIL PROTECTED]) [050722 23:47]: * Matthew Garrett: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, We had a GR that is usually interpreted in a manner which disagrees with you. Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. At least I hope so. It would be rather ridiculous if documentation under the GNU FDL (with invariant sections, just to be sure) is not DFSG-compliant, but some BSD-licensed non-editable PDF file is. 8-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 11:47:09PM +0200, Florian Weimer wrote: 2) Does a GPLed work have to include the preferred form of modification? Probably, and this may include the source code for the graphics. However, this may also be affected by the copyright holder's interpretation of the preferred form of modification and whether the GPLed code is a derived work of the graphics or not. On the other hand, if we accept my opinion on point (1), even if we need to include the pov-ray models we are not required to build from them in order to satisfy the DFSG. I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. If you mean images generated from povray are non-free because they can't be built from source without a non-free component, I'd have to disagree on the grounds that the conclusion is so patently absurd, the premises must be flawed (whether or not I'm able to pinpoint that flaw). Looking at it more closely, nothing in DFSG#2 requires that the source be usable; only that it be source. That is, if the source to a program is written in an expensive, proprietary language, it's still source, and satisfies DFSG#2. That doesn't mean Debian has to accept it; meeting the DFSG is a prerequisite, but not a guarantee of inclusion, and Debian is free to refuse to include software for other reasons (such as we can't build this source). I just can't agree that a freely-licensed work, with source (such as an image with povray source) can be accurately branded non- free because the tools to build that source are non-free. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote: * Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. (And there are fewer instances of the word software in the DFSG after the revision than there were before, anyway...) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote: * Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. (To start, in case I'm unclear below, I agree.) At least I hope so. It would be rather ridiculous if documentation under the GNU FDL (with invariant sections, just to be sure) is not DFSG-compliant, but some BSD-licensed non-editable PDF file is. 8-( Collossal flamewars around the time of SC2004-003 revolved around the definition of software, and SC2004-003, as I understand it, made Debian's interpretation of the word very clear: everything in Debian is software. It's depressing that, after we finally finish that massive debate, people want to start all over again with the word program, which is just as ambiguous a word. So, let's not word-lawyer the DFSG, and instead focus on what's important: what's good for Debian's users and Free Software. Figure out if Debian *should* require source for fonts and graphics. Debian can easily and consistently interpret program in the DFSG to mean either executable stuff or all software, and arguments about which should be saying why their choice is better, not merely saying I don't care if it's better, we should do this one because it's my interpretation. (And, as a final note, modern hinted fonts do, in fact, contain programs. I only mention this because Andreas, saying obviously, seems to not know that.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Steve Langasek: It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. So you think that the DFSG clauses 2, 6, 7, 8 do not apply to documentation, only to executables? This is certainly an interesting position. Whether it's a valid one is indeed harder to decide than I thought. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Florian Weimer [EMAIL PROTECTED] wrote: * Matthew Garrett: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, We had a GR that is usually interpreted in a manner which disagrees with you. We had a GR that stated that everything in main must include source code. That's not the same thing in the slightest. I think the last time the nv reference popped up, nobody could confirm that the source code has been deliberately obfuscated. It seems to be the real thing, but there is not enough public documentation to make any modifications which change the way the driver interacts with the hardware. Fine. I'll attempt to obtain confirmation that the obscure hex constants aren't the original and preferred form for modification. I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. Yes, but *WHY* do you think that? Christ. This isn't a difficult conceptual issue. I think that source has to be the preferred form of modification BECAUSE IT IS DAMNIT is not a convincing argument. If there existed reasonable ways of modifying Java bytecode to create new derivative works, then I'd have fewer qualms about shipping Java bytecode without a compiler. But there aren't, so I do. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Matthew Garrett: I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. Yes, but *WHY* do you think that? It makes it very hard to fix bugs in the pregenerated files. Look at the gsfonts mess, it's pretty instructive. If there existed reasonable ways of modifying Java bytecode to create new derivative works, then I'd have fewer qualms about shipping Java bytecode without a compiler. But there aren't, so I do. From a technical point of view, Java bytecode is as good as uncommented source code. The Java-to-bytecode compilers are not very sophisticated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Florian Weimer [EMAIL PROTECTED] wrote: * Matthew Garrett: Yes, but *WHY* do you think that? It makes it very hard to fix bugs in the pregenerated files. Look at the gsfonts mess, it's pretty instructive. Not all pregenerated files are difficult to modify. If there existed reasonable ways of modifying Java bytecode to create new derivative works, then I'd have fewer qualms about shipping Java bytecode without a compiler. But there aren't, so I do. From a technical point of view, Java bytecode is as good as uncommented source code. The Java-to-bytecode compilers are not very sophisticated. We're happy to accept uncommented source code in main. If Java bytecode is as good as that, it would imply that we're happy to accept it in main as well. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On 7/22/05, Florian Weimer [EMAIL PROTECTED] wrote: It makes it very hard to fix bugs in the pregenerated files. Look at the gsfonts mess, it's pretty instructive. That's an argument from maintainability, not from freeness. The two are, in my view anyway, distinct though related judgments. From a technical point of view, Java bytecode is as good as uncommented source code. The Java-to-bytecode compilers are not very sophisticated. Ditto. But observe that bytecode is not only uncomment_ed_, it is effectively uncomment_able_, which makes it far less maintainable by downstream contributors. The freedom to modify is not reduced to a technicality by relative impracticality -- a license to modify is a pretty good defense against complaints about reverse engineering and repurposing -- but it is certainly abridged. Again I would argue that, if the GFingerPoken source tarball contained only the XPM versions of the artwork and did not discuss how they had been created, that would represent at most a minor barrier to ongoing maintenance of the software. The fact that upstream has gone the extra mile and provided povray input is very nice; a future maintainer who wants to render them into, say, Display PostScript for use on a 300 DPI LCD has something to work with. Someday perhaps these will be the bad old days when people didn't turn up their noses at any code or data without a perfect, all-free-tools audit trail. Given the pressure to cram abandonware clones into main, it doesn't look to me like we're going in the direction of higher standards; but maybe that's only a short term trend. I don't like the sort of message it would send to relegate GFingerPoken to contrib while retaining the many (perhaps most) other games in main made of crap-ass code and bitmap images; but as usual IANADD and it's not my problem. :-) Cheers, - Michael
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 12:40:00AM +0100, Matthew Garrett wrote: Florian Weimer [EMAIL PROTECTED] wrote: From a technical point of view, Java bytecode is as good as uncommented source code. The Java-to-bytecode compilers are not very sophisticated. We're happy to accept uncommented source code in main. If Java bytecode is as good as that, it would imply that we're happy to accept it in main as well. Uncommented source is not the same as source with comments stripped to make it harder to understand. The former is merely potentially bad source code, but clearly source. The latter is obfuscation, and is not source at all. Assuming what Florian says is accurate, Java bytecode is not source any more than C code with comments stripped, which would imply that Debian should not be accepting it as source. Of course, it can be difficult or impossible to tell the difference between bad code and lightly obfuscated code, as with the nVidia driver. Again, that only means it's more difficult to determine if what you've been given is really the source. (And I also readily acknowledge that lightly obfuscated code is better than none at all, but that's in the same vein as slightly non-free is better than onerously non-free--better, but not good enough.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: Uncommented source is not the same as source with comments stripped to make it harder to understand. The former is merely potentially bad source code, but clearly source. The latter is obfuscation, and is not source at all. Assuming what Florian says is accurate, Java bytecode is not source any more than C code with comments stripped, which would imply that Debian should not be accepting it as source. So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005, Matthew Garrett wrote: So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? I've no idea if it's fine for main,[1] but it's clearly DFSG Free. Whether a work is DFSG Free is a separate question from whether we should actually distribute a work. Don Armstrong 1: I'd question a maintainer's sanity if they said they were capable of maintaining such a thing. -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 01:32:37AM +0100, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: Uncommented source is not the same as source with comments stripped to make it harder to understand. The former is merely potentially bad source code, but clearly source. The latter is obfuscation, and is not source at all. Assuming what Florian says is accurate, Java bytecode is not source any more than C code with comments stripped, which would imply that Debian should not be accepting it as source. So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? Yes; as noble a goal as is writing good, well-commented code, that's not what the DFSG is about; it's about free software, including source code. If you write a well-commented program, and remove the comments in the copy you give me, you havn't given me the source at all. Why should Debian consider obfuscated code sufficient for DFSG#2? -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: On Sat, Jul 23, 2005 at 01:32:37AM +0100, Matthew Garrett wrote: So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? Yes; as noble a goal as is writing good, well-commented code, that's not what the DFSG is about; it's about free software, including source code. If you write a well-commented program, and remove the comments in the copy you give me, you havn't given me the source at all. Why should Debian consider obfuscated code sufficient for DFSG#2? So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? Let's say I write a program in C code and compile it to assembly language, which I distribute. Somebody else writes an equivalent program directly in assembly language and distributes it. The distributed products contain the same amount of information about how they work. How is one of these free and the other non-free? -Peff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? One provided source, the other did not, and Debian considers having source fundamental to having a free program. Take it a step further, and say we have two drivers: one written in heavily- optimized, uncommented assembly, and one written in C, compiled with optimizations and disassembled. They look pretty much the same; as you say, both provide the same freedoms to our users. Is disassembly output of a compiled program source to you? Is one free and the other non-free? (My answer is probably obvious: a disassembly dump of a program, no matter how good the disassembler, no matter that it used debug information to reconstruct function boundaries and resulted in assembly output practically equivalent to hand-written assembly code, is not source and isn't acceptable as such--even though a program that was actually written in assembly and resulted in the same thing would be.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On 7/22/05, Jeff King [EMAIL PROTECTED] wrote: Let's say I write a program in C code and compile it to assembly language, which I distribute. Somebody else writes an equivalent program directly in assembly language and distributes it. The distributed products contain the same amount of information about how they work. How is one of these free and the other non-free? Nothing stops us from considering the evidence of the upstream developer's intent when they release a program in a less than perfectly maintainable condition. It's natural that they know some things about it we don't, but if it seems obfuscated beyond the limits of good faith, somebody should blow a whistle. We know perfectly well that the NVidia driver is in the condition it's in partly because its development is funded by a profit-seeking entity that has no wish to destabilize its market position, either by making it easier for a competitor to produce a graphics chip to which the driver could easily be ported, or by losing its privileged relationship to Microsoft when an inspired Linux hacker reworks the driver and related bits of the Linux graphics subsystem to get triple the FPS of the Windows (or XBox) version. (I think triple is probably an exaggeration, but there's room for improvement.) It's very clever of NVidia to support both a fully proprietary Linux driver and a driver we can call open source if we don't look too closely. Do we mind being manipulated this way? A little, but we work with it. That's an extreme case, but the fact is that upstreams do all sorts of things to the code and documentation to pursue agendas at best orthogonal to, and often in opposition to, their users' and especially potential forkers' interests. [I was going to add another rant about the FSF here, but got bored with it.] Cheers, - Michael
Re: On the definition of source [Was: Re: generated source files, GPL and DFSG]
Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005, Matthew Garrett wrote: Don Armstrong [EMAIL PROTECTED] wrote: As of yet, no one has put forward a better definition of source code. Anything that allows a form of practical modification consistent with the functionality of the resulting work, What does that mean? That definition brings up two huge questions in itself: 1) What is a practical modification? A modification that can practically be carried out (trivial modification of a binary, rather more in-depth modification of non-obfuscated C source, that sort of thing). This is, obviously, something that would be applied on a case by case basis. 2) What does consistent with the functionality of the resulting work mean, anyway? If I have something that compiles into a picture, it is not reasonable to demand that I be able to modify it into a piece of executable code or a piece of music. However, it is vital that I be able to modify it into a different picture. Preferred form of modification doesn't always cut it - the author's preferred form of modification may not match anyone else on the planet's. This may be true, but if the author uses a specific form to modify the work, surely that's good enough for us?[1] It seems to me that any definition of source that does not include the form that the author actually uses to create the work is fundamentally flawed.[2] No. We don't ask for the freedom to modify because we think it's a kind of neat idea. We ask for the freedom to modify because we want people who receive the software to have the ability to create different works based upon it. If someone spends their life writing a kernel with a hex editor, I utterly reject the idea that the resulting work can be considered free software. It infringes the first of the FSF's four freedoms. But yes, in almost every case the author's preferred form of modification is going to be source. My assertion is that there are other forms that may also be source. A bitmap file containing the output from a 3D renderer is modifiable in a smaller number of ways than the scene and models that the renderer used, but the same is true of a driver in the absence of full documentation for the hardware. But again, if you believe that source means Preferred form of modification, I suggest that you file a bug asking for the nvidia driver to be removed from main. It quite plainly doesn't meet that standard. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: Practicalities aren't a primary issue. If it's not a practical form for modification, it's probably not preferred by anyone, either--but if I really do prefer an unpractical form to modify a program, then it's still my source, and your definition is wrong. Why do you believe we require source code for everything in main? Because it's there? Or because we believe the recipients should be able to create derived works and learn how the software functions? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Thu, Jul 21, 2005 at 10:13:48AM +0100, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: Practicalities aren't a primary issue. If it's not a practical form for modification, it's probably not preferred by anyone, either--but if I really do prefer an unpractical form to modify a program, then it's still my source, and your definition is wrong. Why do you believe we require source code for everything in main? Because it's there? Or because we believe the recipients should be able to create derived works and learn how the software functions? What does this have to do with the definition of source? Sometimes source just isn't enough to figure out how a program (or hardware) works, lacking eg. hardware documentation; that's annoying, but it's still source. If I create a program with a hex editor, it's source, even if it doesn't serve Free Software's goals so well. If you think something more than source code should be required, then propose it. Don't change the very definition of source to suit an agenda, even if your agenda is Free Software. You'll just end up with something that just isn't a definition of source at all. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: Sometimes source just isn't enough to figure out how a program (or hardware) works, lacking eg. hardware documentation; that's annoying, but it's still source. If I create a program with a hex editor, it's source, even if it doesn't serve Free Software's goals so well. This appears to be argument by assertion. Let's try this again: If you define source as the preferred form for modification, then http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c?rev=1.7view=markup is not source. I, on the other hand, believe that it is an acceptable (though borderline) form of source. Do you believe that this file should be part of Debian? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
** Matthew Garrett :: If you define source as the preferred form for modification, then http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86 /drivers/nv/nv_hw.c?rev=1.7view=markup is not source. I, on the other hand, believe that it is an acceptable (though borderline) form of source. Do you believe that this file should be part of Debian? My take: preferred form for modification is a phrase with two verbs, ie, with many combinations of preferred by whom, and modification by whom: 1. preferred (by the author) form for modification (by the author) 2. preferred (by the current licensor) form for modification (by the current licensor) 3. preferred (by the current licensee) form for modification (by the current licensee) 4. preferred (by the author) form for modification (by any third-party) etc. etc. etc. My opinion? Is that we *should* use the GPL definition, but we should also clarify which combinations are acceptable. For instance, the option (4) above can be non-free; OTOH, the option (3) is clearly impractical (how can one guess which form will all of his licensees prefer?) If we think nv_hw.c is source, then our definition is closer to #2, anyway. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the definition of source [Was: Re: generated source files, GPL and DFSG]
On Thu, 21 Jul 2005, Matthew Garrett wrote: Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005, Matthew Garrett wrote: Anything that allows a form of practical modification consistent with the functionality of the resulting work, What does that mean? That definition brings up two huge questions in itself: 1) What is a practical modification? A modification that can practically be carried out Err... that's just a rephrasing of the question. This is, obviously, something that would be applied on a case by case basis. That's my primary problem with it, because I don't yet know how to apply it. 2) What does consistent with the functionality of the resulting work mean, anyway? If I have something that compiles into a picture, it is not reasonable to demand that I be able to modify it into a piece of executable code or a piece of music. Why not? It may be non-trivial to do so; but that's hardly the fault of the original author. [I'm reminded of Aphex Twin here, where he has literally turned pictures into music.] Preferred form of modification doesn't always cut it - the author's preferred form of modification may not match anyone else on the planet's. This may be true, but if the author uses a specific form to modify the work, surely that's good enough for us?[1] It seems to me that any definition of source that does not include the form that the author actually uses to create the work is fundamentally flawed.[2] No. We don't ask for the freedom to modify because we think it's a kind of neat idea. We ask for the freedom to modify because we want people who receive the software to have the ability to create different works based upon it. Exactly. But if we've got all the freedom that the original author has, why is it important to demand more? It seems to me that this line of argument could just as easily apply to any language that doesn't have significant adoption or a perceived lack of readability. [Some people could decide that dpkg-source didn't qualify as source code because it was written in rather unruly perl.] If someone spends their life writing a kernel with a hex editor, I utterly reject the idea that the resulting work can be considered free software. It infringes the first of the FSF's four freedoms. ITYM Freedom 1 (the second) or possibly Freedom 3 (the last). In either case, in this situation, you've got everything that the original author has to be able to modify the work. You're not being restrained by information that the author could theoretically convey, but hasn't. [If you are, then I submit that you haven't been given the prefered form for modification.] To me, the FOSS movement is about giving everyone the same information that the author has; in this way everyone has the same ability to modify the work. When that is the case, the prefered form of modification has really been distributed. My assertion is that there are other forms that may also be source. A bitmap file containing the output from a 3D renderer is modifiable in a smaller number of ways than the scene and models that the renderer used, but the same is true of a driver in the absence of full documentation for the hardware. So you're saying that commented assembly output, which is modifiable in a smaller number of ways than the actual C source would also be source? Or that the ogg file that is the output of a Lilypond file run through timidity would also be source? I'm frankly at a loss to reconcile these examples with your statements above about modifiability. Since modification is so important, why should we accept as source forms that capriciously limit the modifications we can perform, merely because we are not the original author? I suggest that you file a bug asking for the nvidia driver to be removed from main. Which nvidia driver are we talking about here? I briefly looked at the source for the nv driver in X, and the same code that happens to be in the kernel; while there was a lot of non-copyrightable magic numbers being shot around, everything else appeared to be source to me... but admittedly, I don't write device drivers, which is why I had elided it in the previous message. Don Armstrong -- A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'... -- Joshua D. Wachs - Natural Intelligence, Inc. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Thu, Jul 21, 2005 at 11:24:15AM +0100, Matthew Garrett wrote: Sometimes source just isn't enough to figure out how a program (or hardware) works, lacking eg. hardware documentation; that's annoying, but it's still source. If I create a program with a hex editor, it's source, even if it doesn't serve Free Software's goals so well. This appears to be argument by assertion. Let's try this again: I'm asserting what source is, and pointing out that your definition is wrong because it disagrees. That's valid, like pointing to a black cat, asserting this is a cat, to show that a definition of cat (n): four legs and white fur is wrong. The definition follows from the meaning of the word, not vice versa. That assumes that we basically agree on what something's source is (just as we probably agree on what a cat is), and are just trying to find criteria describing what we already agree on. We apparently don't. The fact that you're saying things that amount to that's not source, because it doesn't help Free Software, however, makes me feel that that you're not looking to find a definition for what we all know as source, but rather to redefine source for political reasons. If you define source as the preferred form for modification, then http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c?rev=1.7view=markup is not source. I, on the other hand, believe that it is an acceptable (though borderline) form of source. Do you believe that this file should be part of Debian? Could you back up a bit, first, and explain to me why that is not the preferred form for modification? It certainly looks like it to me. (Of course, I'd probably need register documentation to understand what most of it does, but that doesn't make this any less the preferred form for modification.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the definition of source [Was: Re: generated source files, GPL and DFSG]
On 7/21/05, Don Armstrong [EMAIL PROTECTED] wrote: [snip stuff where I agree with Don 100%] ITYM Freedom 1 (the second) or possibly Freedom 3 (the last). In either case, in this situation, you've got everything that the original author has to be able to modify the work. You're not being restrained by information that the author could theoretically convey, but hasn't. [If you are, then I submit that you haven't been given the prefered form for modification.] To me, the FOSS movement is about giving everyone the same information that the author has; in this way everyone has the same ability to modify the work. When that is the case, the prefered form of modification has really been distributed. Giving everyone the same information that the author has is a lovely ideal, but applying it too strictly can lead to Pyrrhic victories. If you read the primary literature in any scientific field, you will find that people do not write a textbook every time they publish a result, and that very frequently reproducing an author's result would require a degree of ingenuity and an amount of labor comparable to the author's. Since I've got legal lingo on the brain lately, let me suggest a rebuttable presumption that the author has tried to provide enough of a public record for later authors to work with. I can think of several pieces of software, nominally released as open source, for which that presumption wouldn't be hard to rebut; but GFingerPoken certainly isn't one of them. In any case, I think the ftpmasters, in consultation with the security team, are perfectly capable of rejecting uploads because they are in their opinion unmaintainable for lack of adequate disclosure of how the damn thing works. So you're saying that commented assembly output, which is modifiable in a smaller number of ways than the actual C source would also be source? Or that the ogg file that is the output of a Lilypond file run through timidity would also be source? I'm frankly at a loss to reconcile these examples with your statements above about modifiability. Since modification is so important, why should we accept as source forms that capriciously limit the modifications we can perform, merely because we are not the original author? I think it's important to make a distinction between an intent to obfuscate and an intent to enable recipients to make a large class of changes without needing fiddly-to-configure or hard-to-obtain tools. If the truth of the matter is that a given fragment of C code, only needed on a couple of processor families, broke the GCC optimizer in every other point release, then why shouldn't it be OK for the author to supply assembly output from a known good compiler snapshot and call it source pending a stabler compiler? If the ogg file is supplied as input data for a music recognition regression test, how much do we care whether it can be regenerated from Lilypond input? If you're going to accept programs for inclusion in main that are written and maintained by people with an agenda -- which includes but is not limited to corporate backers who profit from the sale of tied produces and services -- you have to recognize that not everything about their design goals and inner wokings is fully disclosed. The classic example is DES; the S-boxes were designed to be resistant to differential cryptanalysis, which was unknown in the public literature at the time (see http://en.wikipedia.org/wiki/Differential_cryptanalysis ). Commercial users just had to take the NSA's (i. e., MITRE's) word for it that S-box tweaking was motivated by a desire to strengthen DES rather than to Trojan it. We trust people all the time not to offer us excessively Faustian bargains. Will the folks at Xiph.org spring a submarine patent covering Ogg Vorbis on the free software world someday? I think that's extraordinarily unlikely, unless they are forced to the conclusion that there is no way to defend against other patent holders without having some proprietary rights of their own to countersue on; and if it came to that, they would doubtless offer no-fee licenses to open source decoder implementations. I am confident in these statements, not for any legalistic reason, but because their public conduct inspires my trust and because I have some sense of the foreseeable consequences to them of doing otherwise. Should we accept just anybody's word about whether we are getting the means of maintaining a program along with its nominal source code? Of course not! Nor should we take their uncorroborated word for its authorship or patent-free-ness. In short: Trust, but verify. (Often attributed to Ronald Reagan, but AFAICTWALHFG translated from a Russian proverb Doveryay, no proveryay of unknown provenance that was a favorite of both Lenin's and Gorbachev's. I will credit Reagan for popularizing it in the US. :-) Cheers, - Michael
Re: On the definition of source [Was: Re: generated source files, GPL and DFSG]
[Please trim your responses so that they only contain the minimal verbiage necessary to present your point; otherwise we'll leave them unread.] On Thu, 21 Jul 2005, Michael K. Edwards wrote: On 7/21/05, Don Armstrong [EMAIL PROTECTED] wrote: To me, the FOSS movement is about giving everyone the same information that the author has; in this way everyone has the same ability to modify the work. When that is the case, the prefered form of modification has really been distributed. Giving everyone the same information that the author has is a lovely ideal, but applying it too strictly can lead to Pyrrhic victories. Why? Clearly if the author can physically share the information, they should do so. Don Armstrong -- Three little words. (In decending order of importance.) I love you -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: Could you back up a bit, first, and explain to me why that is not the preferred form for modification? It certainly looks like it to me. The preferred form for modification has all of the hex constants replaced with preprocessor defines that give you useful register names. It's fairly easy to show that this is the case - the code is plainly derived from NVidia's earlier (Xfree 3.3 era) driver and their open source SDK, which did have useful symbolic constant names. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 12:07:05AM +0100, Matthew Garrett wrote: Could you back up a bit, first, and explain to me why that is not the preferred form for modification? It certainly looks like it to me. The preferred form for modification has all of the hex constants replaced with preprocessor defines that give you useful register names. It's fairly easy to show that this is the case - the code is plainly derived from NVidia's earlier (Xfree 3.3 era) driver and their open source SDK, which did have useful symbolic constant names. That depends. I can see two scenarios: either they removed these constants from their own codebase, and that's how they now maintain it; or they pass the code through a filter to remove these constants before distributing it to the world. If the former, then what you linked is their preferred form for modification. For example, perhaps their register documentation doesn't know anything about the names in those symbolic constants, and it's just more direct for the programmers to maintain it with the numbers directly. (I doubt nVidia's own documentation is that bad.) The latter is classic obfuscation. I hope it's not a controversial claim to say that obfuscated C code is never source[1], and I don't see how anyone could honestly claim that this is the source to the driver. Preferred form for modification seems to work very well here. I believe there have been long flamewars about this code, which I havn't followed, and I don't have time to investigate this particular case in detail. (So, please be reasonable and not ask me to file bugs against packages, when doing so would commit myself to participating in another resurrected flamewar.) On the other hand, if nVidia no longer maintains this code, but someone else does, then it's effectively become their source: that's how they modify it. Similarly, if I take a BSD-licensed blob of obfuscated C code--clearly not source--run it through indent, fix up variable names and otherwise make it usable again, and start releasing my own fork based on that, then the blob of code has become the legitimate source to my fork, even though it wasn't source when the original obfuscator released it. This is uncommon, but worth considering: something which is not source can become source. (I think preferred form for modification works fine here, too.) [1] except when it's actually written that way, eg. obfuscated code contests, just to cover the canonical exception -- Glenn Maynard
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: That depends. I can see two scenarios: either they removed these constants from their own codebase, and that's how they now maintain it; or they pass the code through a filter to remove these constants before distributing it to the world. It's the latter. I believe there have been long flamewars about this code, which I havn't followed, and I don't have time to investigate this particular case in detail. (So, please be reasonable and not ask me to file bugs against packages, when doing so would commit myself to participating in another resurrected flamewar.) I'm asking you to be willing to accept the consequences of the opinion you hold, which (in this case) is inevitably going to be some large amount of irritation from other members of the project. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 02:04:24AM +0100, Matthew Garrett wrote: I'm asking you to be willing to accept the consequences of the opinion you hold, which (in this case) is inevitably going to be some large amount of irritation from other members of the project. I think it would be massive negligence for the project to accept as source something which it knows has been obfuscated. If that's the case, I'm rather disgusted. It's hard to take a project seriously which claims to require source, but whistles and looks the other way when given something that is obviously not source, because it wants that particular piece of software more than it wants to stick to its founding principles. If Debian is going to drop its principles and loosen the Social Contract, so be it, but don't try to hide it by pretending obfuscated code is source. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Tue, Jul 19, 2005 at 04:52:23PM +0200, Bas Wijnen wrote: First of all, GFingerPoken is released under the GPL. GFingerPoken uses xpms for the graphics. Those files are included in the distribution as .h files, and included directly into the source. Some of them, however, were generated from other files by means of pov-ray. Those files are not in the distribution, but they can be downloaded from the same site as a different tarball. The previous maintainer packaged only the distribution tarball, and used the (generated) .h-files for the compilation of the program. Technically, that is not problematic at all. However, when I found that (some of) the graphics had a source from which they could be compiled, I concluded two things: - To satisfy the GPL, the source for those graphics needs to be distributed as well, so it must be in the source package. - I don't know if it's actually written anywhere, but I thought everything that has source and can be compiled should be compiled at package build time. This means the .h-files have to be regenerated (with pov-ray, in this case). The DFSG doesn't actually require that we ship source to everything - just that it be available. That's not an excuse though, since policy *does* require we ship source to everything. Now that's where the problem starts: pov-ray is in non-free, so any package with a Build-depends: on it must be in contrib (if it is itself free). I don't like to have non-free software on my machine, so I didn't like that idea. I thought of two solutions for that: create new artwork, or do some editing on the existing artwork, which cannot be done automatically. The latter would make it technically impossible to generate the result from source, which would probably remove the requirement to do so. However, that just felt too much like going against the gist of the policy, so I chose not to do that. Yes, that wouldn't really benefit anybody. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Wed, 20 Jul 2005, Matthew Garrett wrote: Francesco Poli [EMAIL PROTECTED] wrote: IMHO, yes, as this is the widely accepted definition of source code (it is found in the GPL text, as you know) and DFSG#2 mandates the inclusion of source code. I'm not convinced that it's a widely accepted definition of source code. As of yet, no one has put forward a better definition of source code. Until that time, the prefered form for modification seems to be the best definition of source code that we've got. [If you've got a better definition, by all means, propose it.] Most people would regard the source for the nv driver as source code, even though there's a version of it that would be easier to modify. ITYM I would; it's not clear at all that most people would regard [it] as source. The classes of modification that can be performed upon a binary are highly limited. You can do anything you want to a binary. There are just things that are more difficult to do to binary files. Don Armstrong -- The sheer ponderousness of the panel's opinion ... refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it--and is just as likely to succeed. -- Alex Kozinski in Silveira V Lockyer http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005, Matthew Garrett wrote: I'm not convinced that it's a widely accepted definition of source code. As of yet, no one has put forward a better definition of source code. Until that time, the prefered form for modification seems to be the best definition of source code that we've got. [If you've got a better definition, by all means, propose it.] Anything that allows a form of practical modification consistent with the functionality of the resulting work, or something along those lines. Yes, it's horribly fuzzy, but it's a horribly fuzzy area. Preferred form of modification doesn't always cut it - the author's preferred form of modification may not match anyone else on the planet's. Most people would regard the source for the nv driver as source code, even though there's a version of it that would be easier to modify. ITYM I would; it's not clear at all that most people would regard [it] as source. If you don't regard it as source, then you should file a bug requesting that it be removed from main. Despite the moderately involved thread we had on this in the past, nobody has done so yet. The classes of modification that can be performed upon a binary are highly limited. You can do anything you want to a binary. There are just things that are more difficult to do to binary files. Feel free to insert the word practically there. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On the definition of source [Was: Re: generated source files, GPL and DFSG]
On Wed, 20 Jul 2005, Matthew Garrett wrote: Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005, Matthew Garrett wrote: I'm not convinced that it's a widely accepted definition of source code. As of yet, no one has put forward a better definition of source code. Anything that allows a form of practical modification consistent with the functionality of the resulting work, What does that mean? That definition brings up two huge questions in itself: 1) What is a practical modification? 2) What does consistent with the functionality of the resulting work mean, anyway? I submit that these questions are even more insurmountable than the what is source? question. Preferred form of modification doesn't always cut it - the author's preferred form of modification may not match anyone else on the planet's. This may be true, but if the author uses a specific form to modify the work, surely that's good enough for us?[1] It seems to me that any definition of source that does not include the form that the author actually uses to create the work is fundamentally flawed.[2] Don Armstrong 1: We may decide not to package it for practical reasons as no one else can maintain it, of course. 2: It should be noted that when I say prefered form for modification I'm refering to the form that the author actually uses when the author modifies (or baring that, creates) the work; it has nothing to do with the form J. Random contributor would prefer. -- [this space for rent] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
generated source files, GPL and DFSG
Hello, I am the new maintainer of GFingerPoken, and have had a discussion with the upstream author. I would like to have your opinion about this. Some background about all this: First of all, GFingerPoken is released under the GPL. GFingerPoken uses xpms for the graphics. Those files are included in the distribution as .h files, and included directly into the source. Some of them, however, were generated from other files by means of pov-ray. Those files are not in the distribution, but they can be downloaded from the same site as a different tarball. The previous maintainer packaged only the distribution tarball, and used the (generated) .h-files for the compilation of the program. Technically, that is not problematic at all. However, when I found that (some of) the graphics had a source from which they could be compiled, I concluded two things: - To satisfy the GPL, the source for those graphics needs to be distributed as well, so it must be in the source package. - I don't know if it's actually written anywhere, but I thought everything that has source and can be compiled should be compiled at package build time. This means the .h-files have to be regenerated (with pov-ray, in this case). Now that's where the problem starts: pov-ray is in non-free, so any package with a Build-depends: on it must be in contrib (if it is itself free). I don't like to have non-free software on my machine, so I didn't like that idea. I thought of two solutions for that: create new artwork, or do some editing on the existing artwork, which cannot be done automatically. The latter would make it technically impossible to generate the result from source, which would probably remove the requirement to do so. However, that just felt too much like going against the gist of the policy, so I chose not to do that. That was my take on the story. I am not sure if I disagree with the upstream author, but here's some of his opinions, copied from a mail with his permission: I take issue with your claim that it doesn't meet DFSG. That's kind of like saying that since the source code to my brain isn't available, nothing I write with it is free. The two .h files are in fact GPLed. The means by which they were produced does not impact their free, as in speech, status. You might say that this would allow a person to release object code and call it free. In fact, if the original software release was a binary object that was then compiled into the final binary, it's still free. The problem comes if some other source was released and a person changes this source, releases a new binary based on that source, but does not release the source used. Now, since my game is GPLed, you can replace the artwork. Maybe I'll like it more. But to claim that the original game does not meet DFSG is bogus. If you'd like, we could bring it up with debian-legal, or I could probably get the opinion of a professional lawyer (not to say that debian-legal does not have actual professional lawyers). - Martin On 7/12/05, Bas Wijnen [EMAIL PROTECTED] wrote: Debian dictates that everything in the main archive must be free according to the Debian free software guidelines (DFSG). That means that the full source code must be available. And everything must be compiled from source. To be in the main archive, not only the code must be DFSG free, but also the compiler. So far so good. Now there are two files in the tarball which aren't actually source files: tilepix.h and marblepix.h. They are generated from source files with povray. And unfortunately, povray is not DFSG free (it prohibits commercial use). This left me with some options, of which the reasonable ones were: - Recreate the artwork without povray - Put the package in the contrib section (which is for free software with non-free [build-]dependancies) I don't like having non-free things on my computer, and I don't want to encourage others to have them, so I chose for the first option. Note that some (irrelevant) parts were cut out. Now what I would like to ask you is this: What is your view on this situation? Can GFingerPoken be in main with the original artwork, or not? Thanks in advance for your comments. Please CC me in any reply, I am not on this list. Martin doesn't want his e-mail address harvested, so I Bcc'd him with this message and will send any replies through to him. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, and it's trivial to demonstrate that this isn't the current situation (see the nv driver in the X.org source tree, for instance). The DFSG require the availability of source code, and it seems reasonable to believe that anything that can be reasonably modified falls into that catagory. The graphics are available in a form that can be modified with free tools (the .xpm files). However, I know that other people disagree with my viewpoint on this. 2) Does a GPLed work have to include the preferred form of modification? Probably, and this may include the source code for the graphics. However, this may also be affected by the copyright holder's interpretation of the preferred form of modification and whether the GPLed code is a derived work of the graphics or not. On the other hand, if we accept my opinion on point (1), even if we need to include the pov-ray models we are not required to build from them in order to satisfy the DFSG. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On 7/19/05, Matthew Garrett [EMAIL PROTECTED] wrote: [an assessment with which I agree almost 100%] The game GFingerPoken (which I have played and really quite enjoy) is definitely a derivative work of its artwork. It's a complex work that integrally incorporates substantial portions of a previous (or contemporaneous) work, itself capable of standing alone as a work of authorship. That is, in fact, what derivative work does mean under copyright law (especially 17 USC), as opposed to all of the other things that the FSF claims it might mean. As I've written previously on d-l, derivative works are a particular subset of works requiring authorization from the copyright holder on the original, defined in 17 USC 101 principally for the sake of the derivative works exceptions to the termination clauses in sections 203 and 304. The artwork in GFingerPoken bears precisely the relationship to the game that a song bears to a movie of which it forms part of the soundtrack, and that's the relationship that Congress had in mind as the principal application of those exceptions. Citations to the House Report and the appellate record at http://lists.debian.org/debian-legal/2005/06/msg00116.html . I think the usage of source code in the DFSG bears a closer resemblance to the author's preferred form for modification a la GPL than Matthew seems to. But while that might present a problem for the X.org nv driver, IMHO GFingerPoken is as he says in the clear. There exist perfectly good tools in main for creating alternate versions of the XPM artworks, and I find it quite implausible that recipients engaged in bug fixing would be any less able to do a good job using the XPMs than using the povray input. This is not like massaging the output of a non-free yacc variant instead of porting to bison -y. povray is not a parser generator, treating its output as part of the source tarball does not meaningfully impair the maintainability of the program, and it's stupid to exclude a program from main (i. e., from Debian) simply because upstream was unusually forthcoming about how he created artwork that doesn't look like my one-year-old drew it. Cheers, - Michael (IANADD, IANAL, TINLA)
Re: generated source files, GPL and DFSG
On Tue, 19 Jul 2005 16:13:43 +0100 Matthew Garrett wrote: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? IMHO, yes, as this is the widely accepted definition of source code (it is found in the GPL text, as you know) and DFSG#2 mandates the inclusion of source code. I don't believe so, and it's trivial to demonstrate that this isn't the current situation (see the nv driver in the X.org source tree, for instance). The presence of other bugs does not excuses us from fixing a bug when we find it out. That said, I didn't have time to reread the old thread about the nv driver, and I don't recall what the conclusion was... :-( The DFSG require the availability of source code, and it seems reasonable to believe that anything that can be reasonably modified falls into that catagory. A binary executable can be reasonably modified with a hex editor (warez dudes do exactly that, in order to remove anti-copy or registration mechanisms from proprietary programs). The graphics are available in a form that can be modified with free tools (the .xpm files). However, I know that other people disagree with my viewpoint on this. I belong to that class of people... In other words, I'm sorry to say this, but I disagree. 2) Does a GPLed work have to include the preferred form of modification? Probably, and this may include the source code for the graphics. If the graphics are GPL'd (as in this case), I would have said surely. However, this may also be affected by the copyright holder's interpretation of the preferred form of modification One should show by practice what is his/her preferred form for modification: simply stating I prefer modifying the binary executable with a hex editor while you don't do it (either because you don't modify at all, or because you modify the C++ code and then recompile) should not be considered enough to say that the binary executable *is* the source code... and whether the GPLed code is a derived work of the graphics or not. If the artwork is itself GPL'd, asking what is derived from what seems to be useless... On the other hand, if we accept my opinion on point (1), even if we need to include the pov-ray models we are not required to build from them in order to satisfy the DFSG. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp0ZA282Akk6.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Tue, 19 Jul 2005 16:52:23 +0200 Bas Wijnen wrote: Hello, Hi! :) [...] Some background about all this: First of all, GFingerPoken is released under the GPL. [...] However, when I found that (some of) the graphics had a source from which they could be compiled, I concluded two things: - To satisfy the GPL, the source for those graphics needs to be distributed as well, so it must be in the source package. Yes. - I don't know if it's actually written anywhere, but I thought everything that has source and can be compiled should be compiled at package build time. This means the .h-files have to be regenerated (with pov-ray, in this case). I think so (IANADD). Now that's where the problem starts: pov-ray is in non-free, so any package with a Build-depends: on it must be in contrib (if it is itself free). Yes. I don't like to have non-free software on my machine, so I didn't like that idea. I thought of two solutions for that: create new artwork, That is an option. or do some editing on the existing artwork, which cannot be done automatically. The latter would make it technically impossible to generate the result from source, which would probably remove the requirement to do so. However, that just felt too much like going against the gist of the policy, so I chose not to do that. If you actually modify the images directly in XPM format, you effectively change the form of their source code. After your modifications, the preferred form for further modifications is the xpm format. The situation is similar to a case where you get a GPL'd program written in Fortran77, translate it in C and *then* make modifications to it. The source form is changed, but the GPL allows this. Keep in mind that you actually have to do real modifications to the images, not fake ones just to fool the license... Basically you show that XPM is your preferred form for making modifications, by actually making modifications in that format. [...] Now, since my game is GPLed, you can replace the artwork. Maybe I'll like it more. But to claim that the original game does not meet DFSG is bogus. Actually what you seem to claim is not that the original game does not meet the DFSG. That would be false. What you seem to have stated is: * The original game /is/ Free and passes the DFSG. * It's just not suitable for main, because it build-depends on a component that's not in main. * Thus it belongs in contrib. And this sounds true. [...] Can GFingerPoken be in main with the original artwork, or not? As I said above, IMHO, the answer is no. It belongs in contrib, unless some changes are made (e.g. replacing the artwork). -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpqBMbBABbAN.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
Francesco Poli [EMAIL PROTECTED] wrote: On Tue, 19 Jul 2005 16:13:43 +0100 Matthew Garrett wrote: 1) Does everything in main have to include the preferred form of modification? IMHO, yes, as this is the widely accepted definition of source code (it is found in the GPL text, as you know) and DFSG#2 mandates the inclusion of source code. I'm not convinced that it's a widely accepted definition of source code. Most people would regard the source for the nv driver as source code, even though there's a version of it that would be easier to modify. The DFSG require the availability of source code, and it seems reasonable to believe that anything that can be reasonably modified falls into that catagory. A binary executable can be reasonably modified with a hex editor (warez dudes do exactly that, in order to remove anti-copy or registration mechanisms from proprietary programs). The classes of modification that can be performed upon a binary are highly limited. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: possible licensing issues with some scsh source files
On Nov 18, 2003, at 05:55, Andrew Suffield wrote: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. Harmless. My best effort consists of waving a gerbil at my workstation and hoping something along those lines happens. That's hardly best efforts! It's not even reasonable effort or even, I'd say, and effort. (If this were an actual requirement, rather than a vague request, it would be a problem. agree to make sounds quite like a requirement to me.
Re: possible licensing issues with some scsh source files
On Nov 18, 2003, at 14:07, Barak Pearlmutter wrote: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. This clause is moot, because The T Project at Yale has not existed for the last fifteen years. So a best effort would be a seance at which a psychic medium channels the spirit of a project past. Then said improvements would, I think, be returned to Yale University or to the T projects successor (if any), or to the copyright holders or former members of the project. It'd probably take some lawyer work to determine the appropriate party to deliver them to.
Re: possible licensing issues with some scsh source files
On Tue, Nov 18, 2003 at 11:05:57AM -0500, Brian T. Sniffen wrote: ;;; 3. All materials developed as a consequence of the use of this software ;;;shall duly acknowledge such use, in accordance with the usual standards ;;;of acknowledging credit in academic research. This is close to some things that would be a problem, but with no real constraints on what form acknowledgement must take, harmless (usual standards of acknowledging credit in academic research is a readable citation that is sufficient to find the origin, for anybody who cares enough to do so). This is, at worst, reducible to the BSD advertising clause. It's not reducible to a copyright notice in the binary: if I'm giving a talk about a program I wrote for a professor, I'm obligated by academic honesty to mention inspirations and contributions *in the talk*. No you aren't. I've never met an academic who did this unless it was actually relevant to the talk. Normally you just put a footnote in the associated paper. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: possible licensing issues with some scsh source files
On Tue, Nov 18, 2003 at 10:55:23AM +, Andrew Suffield wrote: On Tue, Nov 18, 2003 at 10:39:56AM +0100, Daniel Kobras wrote: We're currently trying to sort out the non-free status of scsh within Debian. Most of the issues are unambiguous, however, I'd like to see some more opinions on the following two clauses contained in a couple of source files. scsh-0.6.4/scheme/big/sort.scm: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. Harmless. My best effort consists of waving a gerbil at my workstation and hoping something along those lines happens. (If this were an actual requirement, rather than a vague request, it would be a problem. I strongly discourage people from writing noise like this into licenses though - put it in the README where it belongs.) On reflection, we've rejected this exact clause (in its MIT Scheme incarnation) as non-free in the past, after some heavy analysis of the wording. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: possible licensing issues with some scsh source files
On Wed, Nov 19, 2003 at 05:29:03PM +, Andrew Suffield wrote: On reflection, we've rejected this exact clause (in its MIT Scheme incarnation) as non-free in the past, after some heavy analysis of the wording. All I found was the thread starting at http://lists.debian.org/debian-legal/2001/debian-legal-200105/msg00178.html To me it seems to die out with no clear consensus. Regards, Daniel.
Re: possible licensing issues with some scsh source files
On Wed, Nov 19, 2003 at 07:07:43PM +0100, Daniel Kobras wrote: On Wed, Nov 19, 2003 at 05:29:03PM +, Andrew Suffield wrote: On reflection, we've rejected this exact clause (in its MIT Scheme incarnation) as non-free in the past, after some heavy analysis of the wording. All I found was the thread starting at http://lists.debian.org/debian-legal/2001/debian-legal-200105/msg00178.html To me it seems to die out with no clear consensus. To me it seems to end with consensus that it is non-free: in the tree of the thread, all leaves say non-free, except one saying I think barely free, on the verge of non-free, but still free, but if I'm the only one thinking this, then I wont battle for my interpretation. -- Lionel signature.asc Description: Digital signature
Re: possible licensing issues with some scsh source files
On Tue, Nov 18, 2003 at 10:39:56AM +0100, Daniel Kobras wrote: We're currently trying to sort out the non-free status of scsh within Debian. Most of the issues are unambiguous, however, I'd like to see some more opinions on the following two clauses contained in a couple of source files. scsh-0.6.4/scheme/big/sort.scm: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. Harmless. My best effort consists of waving a gerbil at my workstation and hoping something along those lines happens. (If this were an actual requirement, rather than a vague request, it would be a problem. I strongly discourage people from writing noise like this into licenses though - put it in the README where it belongs.) ;;; 3. All materials developed as a consequence of the use of this software ;;;shall duly acknowledge such use, in accordance with the usual standards ;;;of acknowledging credit in academic research. This is close to some things that would be a problem, but with no real constraints on what form acknowledgement must take, harmless (usual standards of acknowledging credit in academic research is a readable citation that is sufficient to find the origin, for anybody who cares enough to do so). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: possible licensing issues with some scsh source files
On Tue, Nov 18, 2003 at 10:55:23AM +, Andrew Suffield wrote: On Tue, Nov 18, 2003 at 10:39:56AM +0100, Daniel Kobras wrote: We're currently trying to sort out the non-free status of scsh within Debian. Most of the issues are unambiguous, however, I'd like to see some more opinions on the following two clauses contained in a couple of source files. scsh-0.6.4/scheme/big/sort.scm: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. Harmless. My best effort consists of waving a gerbil at my workstation and hoping something along those lines happens. (If this were an Be careful he doesn't bite you for waving him around like that. g Seriously, though, wouldn't the definition of best effort most likely be that which the plaintiff could convince the court of? For instance, if there was a contact e-mail address in the package, in a prominent location, and you had a perfectly working e-mail account, how hard would it be to convince a judge that your gerbil-waving wasn't your best effort? It certainly isn't as onerous as we 0wn j00r changes clauses, but I'm worried that best effort isn't up to the user's judgement, if things turn unpleasant. ;;; 3. All materials developed as a consequence of the use of this software ;;;shall duly acknowledge such use, in accordance with the usual standards ;;;of acknowledging credit in academic research. This is close to some things that would be a problem, but with no real constraints on what form acknowledgement must take, harmless (usual standards of acknowledging credit in academic research is a readable citation that is sufficient to find the origin, for anybody who cares enough to do so). I didn't see any practical problems with this clause, either. Portions developed by blah (or even the copyright notice) should be sufficient to satisfy this requirement. - Matt
Re: possible licensing issues with some scsh source files
Andrew Suffield [EMAIL PROTECTED]: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. Harmless. My best effort consists of waving a gerbil at my workstation and hoping something along those lines happens. (If this were an actual requirement, rather than a vague request, it would be a problem. I strongly discourage people from writing noise like this into licenses though - put it in the README where it belongs.) Why do you think this is a vague request rather than an actual requirement? Users ... agree sounds like a requirement to me. The expression best efforts is a strong one. It means more than just reasonable efforts. I don't think your gerbil waving would even count as a reasonable effort.
Re: possible licensing issues with some scsh source files
Andrew Suffield [EMAIL PROTECTED] writes: On Tue, Nov 18, 2003 at 10:39:56AM +0100, Daniel Kobras wrote: We're currently trying to sort out the non-free status of scsh within Debian. Most of the issues are unambiguous, however, I'd like to see some more opinions on the following two clauses contained in a couple of source files. scsh-0.6.4/scheme/big/sort.scm: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. Harmless. My best effort consists of waving a gerbil at my workstation and hoping something along those lines happens. (If this were an actual requirement, rather than a vague request, it would be a problem. I strongly discourage people from writing noise like this into licenses though - put it in the README where it belongs.) Best Effort is a term with specific legal meanings. obligation to attempt to meet a goal using every reasonable means available, isn't a perfect definition, but it's close. In particular, it doesn't consider the costs or consequences of those actions to you: even Chinese dissidents can send e-mail, so they have to do so. This is not a Free license. ;;; 3. All materials developed as a consequence of the use of this software ;;;shall duly acknowledge such use, in accordance with the usual standards ;;;of acknowledging credit in academic research. This is close to some things that would be a problem, but with no real constraints on what form acknowledgement must take, harmless (usual standards of acknowledging credit in academic research is a readable citation that is sufficient to find the origin, for anybody who cares enough to do so). This is, at worst, reducible to the BSD advertising clause. It's not reducible to a copyright notice in the binary: if I'm giving a talk about a program I wrote for a professor, I'm obligated by academic honesty to mention inspirations and contributions *in the talk*. So I would read this clause as requiring acknowledgement of inspiration and origins in advertising material, sales pitches, and documentation. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: possible licensing issues with some scsh source files
Scripsit Barak Pearlmutter [EMAIL PROTECTED] ;;; 2. Users of this software agree to make their best efforts (a) ;;; to return to the T Project at Yale any improvements or ;;; extensions that they make, so that these may be included in This clause is moot, because The T Project at Yale has not existed for the last fifteen years. But somebody else at Yale may start something new that they choose to call The T Project. -- Henning Makholm*Jeg* tænker *strax* på kirkemødet i Konstantinopel i 381 e.Chr. om det arianske kætteri...
Re: possible licensing issues with some scsh source files
Scripsit Barak Pearlmutter [EMAIL PROTECTED] This clause is moot, because The T Project at Yale has not existed for the last fifteen years. I grabbed the source and looked at it. As Daniel wrote, there are three files with this clause in them. The one that references the T Project implements an utility function that sorts a list given a comparison operator. It could be reimplemented from scratch in a few hours, which might even be faster than trying to track down the original authors. Two other files reference the MIT Scheme project in a similar way. These are about three thousand lines in total, with comments that indicate that they have been very heavily modified since they left MIT. No names of individual original-authors-at-MIT are given. MIT Scheme, in the mean time, has evolved into MIT/GNU Scheme, but still seems to be recognizeable as the project those licenses refer to. Considering the GNU-ness of MIT/GNU Scheme (and also the fact that its primary author turns out to be a Debian Developer), it is quite probable that the current MIT/GNU Scheme project will waive their right to receive postcards about character and string primitives in scsh. A request for this should ideally go through Olin Shivers, though. -- Henning Makholm ... and that Greek, Thucydides
Re: possible licensing issues with some scsh source files
On 2003-11-18 19:07:18 + Barak Pearlmutter [EMAIL PROTECTED] wrote: aren't removed, Barak Pearlmutter cannot guarantee that he will not give your phone number to his ex-wife. That should get results. What, no automatic weapons?
