Re: Let's stop feeding the NVidia cuckoo
On Tue, Mar 01, 2005 at 06:17:56AM -0800, Ben Johnson wrote: After a quick search to try and find if the FSF ever voiced an opinion on nv, I unfortunately only dug out the well-known case against NVidia's binary kernel module. Will any of the X nVidia support work without that binary kernel module? Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: latex2html goes GPL? [was: Re: Let's stop feeding the NVidia cuckoo]
On Sun, Mar 06, 2005 at 08:45:21PM -0800, Josh Triplett wrote: Actually, a simple email from the upstream author has been considered in the past to be sufficient authorization for a license change. If upstream were to send an email saying something to the effect of I hereby relicense all versions of latex2html under the GNU GPL, version 2., I believe that would be sufficent. IIRC, latex2html has several authors, several of them not reachable easily... Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Francesco Poli wrote: On Fri, 4 Mar 2005 00:21:39 + Matthew Garrett wrote: Do you think that figuring out the LaTeX markup by looking at the resulting PDF is easy? As a practical example of this, Python ships HTML documentation. This is in a pre-built tarball in the Debian source package, because the original docs are in latex and require latex2html to turn them into HTML. latex2html is non-free, so can't be a build-depend. Should the python docs be moved to contrib, or is the HTML sufficiently modifiable that they can stay in main? Yes, this seems to be a sarge-ignore bug. Possible solutions: * python-doc is moved to contrib[1] and with HTML actually built from actual LaTeX source by latex2html (non-free Build-Depends:) * python-doc is rebuilt from LaTeX source by a DFSG-free LaTeX-HTML compiler (TeX4ht?) [1] note that python only Suggests: python-doc, so pythin would stay in main * latex2html is released under the GPL and moved to main. The author has already said he would do this with the next version, but that next version may be a long time off; the best solution would be a permission statement. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Let's stop feeding the NVidia cuckoo
On Sun, 06 Mar 2005 00:09:56 -0800 Josh Triplett wrote: * latex2html is released under the GPL and moved to main. The author has already said he would do this with the next version, but that next version may be a long time off; the best solution would be a permission statement. Wow! :-) I didn't know (or perhaps didn't remember) this! We should really seek a permission to distribute old latex2html versions under the GNU GPL! Perhaps a (wishlist?) bug should be file against the latex2html package. What do you think? -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpsGQ3VRh4cm.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
Francesco Poli [EMAIL PROTECTED] wrote: Perhaps a (wishlist?) bug should be file against the latex2html package. What do you think? Such a good idea that Roland Stigge already did it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221703 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
latex2html goes GPL? [was: Re: Let's stop feeding the NVidia cuckoo]
On 06 Mar 2005 14:41:23 GMT MJ Ray wrote: Francesco Poli [EMAIL PROTECTED] wrote: Perhaps a (wishlist?) bug should be file against the latex2html package. What do you think? Such a good idea that Roland Stigge already did it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221703 Well, I admit I didn't dig into the BTS before suggesting that... :p Good news: wishlist bug is already filed. Bad news: there seems to be no progress since January 2004. I'm writing to Roland right now to ask for clarifications... -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpRL7kQ0JdVK.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Fri, Mar 04, 2005 at 08:59:19AM +0100, Andreas Barth wrote: * Andrew Suffield ([EMAIL PROTECTED]) [050304 08:50]: They do not have anything to add to the discussion. Particularly since it's not even a discussion at present, but merely those of us who've been thinking about this stuff for a long time shooting down the FUD of those who haven't thought about it at all. Again, it's not the case that you've the absolute truth. Even if you don't like it. Again, it's not the case that you've the absolute truth. Even if you don't like it. [The really neat thing about arbitrary gibberish like this is that it can be used as a justification for absolutely anything] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 03, 2005 at 06:10:21PM +, Matthew Garrett wrote: Andrew Suffield [EMAIL PROTECTED] wrote: What on earth would be the point of that? It won't magically become free just because the wider community doesn't want to make it free. If you are seriously suggesting that we would compromise our principles because the wider community doesn't like them, then sod off. We don't need to compromise our principles. We need to be able to explain them clearly, and be able to counter the arguments made against them. Then it's irrelevant to the topic at hand. You need to go talk to DWN and the anti-freedom advocates, who are the ones who run around creating these PR disasters you talk about. Even now, I'm sure they're preparing a Debian rejects all images from the archive story for massive distribution. Whining about it here won't accomplish anything; none of the people who do these stupid things are even reading this thread. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
Scripsit Francesco Poli [EMAIL PROTECTED] On the other hand, we must adopt a source code definition that allows it to change form: see my Fortran-C example. No, I specifically reject your claim that the source code of the existing work magically changes from being C to Fortran simply because the author changes his mind after the fact. Note that the GPL does not define that it is the author that does the preferring. Yes, but the author's opinion (more precisely the last modifier's one) counts as he/she is the one who actually modifies or modified the work and allowing him/her to translate from a language to another one is really important, IMO. It's important, but it does not trump everything else in cases where it would lead to nonsense. 2) Conversely, we cannot reasonably accuse the author of releasing his work under non-free conditions if he *does* give us every form he himself used to create it, and allows us to distribute them under otherwise free conditions. I agree entirely, but with a s/used to create it/uses to modify it/ So you think that if the author never modified the work after initially creating it, and does not plan to do so, the work can be free without us having anything source-like? In that case every form he himself uses to modify it is an empty set, and under your revised statement the work would be trivially free. Suppose that J. Random Hacker initially generates a work by using some special tool (a non-free tool that generates images representing fractals, for instance); then he goes on modifying it with normal manipulation tools (The Gimp, for instance). What is source code in this case? Does it include the special tool? According to my statement, *if* we do get the special tool and all of the intermediate forms, then the work is free. My statement does not tell anything about the freedom if we don't - then we're in the grey area where we have to apply common sense or other rules of thumb. As with other grey areas we have to fall back to other and more fuzzy criteria here, such as: Which form would a _reasonable_ person with the skills to understand and appreciate the work prefer for modifying?. My only concern with this approach is: what do we mean by 'reasonable'? We will find to reach a consensus about a what a reasonable meaning of reasonable is in each case. Sorry, but we _cannot_ encapsulate our concept of freedom into a mathematical bright-line test that can _always_ be applied without judgement calls. There _will_ always be boundary case where we need to actually _think_ and apply some common sense to find a reasonable solution. -- Henning Makholm The trouble is that the chapter is entirely impenetrable. Its message is concealed behind not just thickets of formalism, but hedges, woods, and forests of formalism. There are whole pages with not even a paragraph break. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On 04 Mar 2005 10:07:20 -0500 Michael Poole wrote: Matthew Garrett writes: [...] Why does it depend on what the upstream author is using as source? How does that affect the recipient's ability to modify the work? One of the underpinnings of the Free Software movement is that users of software should not be made second-class citizens when it comes to altering the software. This is what drives the desire to have sufficiently modifiable source, and it is neatly more objective than a metric of sufficient modifiability. Users should have the same opportunities to modify software as its original author(s) have. If the original author had to pay for a non-free tool, or had to study some advanced topic for years to grok the algorithims, so be it. If the original author uses C source, it violates Free Software's principles to expect others to edit the preprocessor or compiler output to modify the software. Indeed. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpKRvM8aPkiv.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Fri, 4 Mar 2005 12:13:06 -0500 Luke Schierer wrote: assuming there is a meaningful definitionof source for that package. I claim there is at least one: the one found in GPLv2. But as this thread has amply shown, it is entirely possible to come up with things that have no meaningful source. I don't agree. Pictures, graphics in general. Source for graphics is the preferred form for modification, as for other cathegories of works. On a case-by-case basis, source may be coincident with the form exploited when the work is /used/: * scripts * PNG or even JPEG images that are modified in that very format * plain text files that are modified as such * ... or may be distinct: * programs modified as C/C++/Java/Fortran/... code * PNG or JPEG images that are modified in layered form * plain text generated from DocBook source * ... sufficiently complex programs that require knowledge that the average person doesn't have to understand the function of. No, IMHO, knowledge is not part of source code. Of course, it would be highly desirable that upstream author points you to (or even writes him/herself) DFSG-free documentation[1] that teaches the difficult topics you have to be familiar with in order to hack with the program, but that would anyway be a plus (nice but not required for the software to be DFSG-free). [1] There is fairly too few DFSG-free documentation around, so it's always desirable that someone writes or spreads some! ;-) we've even seen someone suggest that if a programmer for some unknown reason *wants* to write in machine language, he or she can never make his program free software! to me, this means that we are taking the necessity of source code too far for it to be useful, important, or meaningful. I'm not the one that suggested that. I agree with you that for a program written in machine language, source code and executable form are coincident, as long as the program is actually maintained and modified in that form. Note that this is thoroughly consistent with the preferred form for modification definition of source code found in the GPLv2 text. cvs or other repositories are nice and all, as is knowing the history of a project, what patches have been proposed, rejected, accepted, so on. and on the other hand, yes a sufficiently skilled person can edit a binary. but the importance and value of free software/open source software necessarily comes between both extremes. you simply cannot require I distribute intangibles like my knowledge of gaim and its history, or Sean Egan's knowledge of yahoo authentication, you can require that he and I distribute the code we actually edit, in whatever form we edit it, if we want to call it free software. I agree. Preferred *form* for modification, not preferred *brain* for modification! but if we choose to edit it as a jpeg, or in machine language, or in hex, that should not be sufficient to make our work, under the same license it was the day before we made that commit, giving you the same rights it did the day before, the same access it did the day before, non-free. Again I agree. And again it follows from the preferred form for modification definition. Gaim has actually had hex (though never, to my knowledge, true machine language.) in it, we did an april fools joke that way once. a hex string is substantialyl harder to edit than the corresponding ascii that does the same thing, does that make that copy of gaim non-free? No, our copies had it in hex as well, some gaim developers just happen to have the ability to read a hex string, your lack of that ability does not restrict your rights. If that hex string was actually modified (or going to be modified in case a modification was needed) in that form, then, yes, it was source. Hard to read source, but still source. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpjcNwGL8wFc.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Fri, 4 Mar 2005 00:21:39 + Matthew Garrett wrote: Do you think that figuring out the LaTeX markup by looking at the resulting PDF is easy? As a practical example of this, Python ships HTML documentation. This is in a pre-built tarball in the Debian source package, because the original docs are in latex and require latex2html to turn them into HTML. latex2html is non-free, so can't be a build-depend. Should the python docs be moved to contrib, or is the HTML sufficiently modifiable that they can stay in main? Yes, this seems to be a sarge-ignore bug. Possible solutions: * python-doc is moved to contrib[1] and with HTML actually built from actual LaTeX source by latex2html (non-free Build-Depends:) * python-doc is rebuilt from LaTeX source by a DFSG-free LaTeX-HTML compiler (TeX4ht?) [1] note that python only Suggests: python-doc, so pythin would stay in main -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpqC2DghmDTf.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Sat, 05 Mar 2005 10:51:11 + Henning Makholm wrote: [please send replies to the list, as I'm a subscriber and didn't asked to get replies twice; thank you] Scripsit Francesco Poli [EMAIL PROTECTED] On the other hand, we must adopt a source code definition that allows it to change form: see my Fortran-C example. No, I specifically reject your claim that the source code of the existing work magically changes from being C to Fortran simply because the author changes his mind after the fact. Perhaps I expressed myself in a misleading way. The source code for already distributed versions will stay the same. What is in a new form, is the source for a more recent version distributed after the author has begun to actually modify Fortran code rather than C. For that version there is no C code from which you can rebuild the executable. And the form the author actually prefers when further modifications are needed is Fortran code. Note that the GPL does not define that it is the author that does the preferring. Yes, but the author's opinion (more precisely the last modifier's one) counts as he/she is the one who actually modifies or modified the work and allowing him/her to translate from a language to another one is really important, IMO. It's important, but it does not trump everything else in cases where it would lead to nonsense. Of course. 2) Conversely, we cannot reasonably accuse the author of releasing his work under non-free conditions if he *does* give us every form he himself used to create it, and allows us to distribute them under otherwise free conditions. I agree entirely, but with a s/used to create it/uses to modify it/ So you think that if the author never modified the work after initially creating it, and does not plan to do so, the work can be free without us having anything source-like? No, if the author never modified the work and does not plan to do so, he/she simply does not give any indication on which is his/her preferred form for modification. In that case, I think we should ask: which form would you prefer, should you make modifications to the work?. The question may be asked to the actual author or to other people with similar skills. In that case every form he himself uses to modify it is an empty set, and under your revised statement the work would be trivially free. Maybe it's clearer with a s/used to create it/uses or would use to modify it/ Suppose that J. Random Hacker initially generates a work by using some special tool (a non-free tool that generates images representing fractals, for instance); then he goes on modifying it with normal manipulation tools (The Gimp, for instance). What is source code in this case? Does it include the special tool? According to my statement, *if* we do get the special tool and all of the intermediate forms, then the work is free. My statement does not tell anything about the freedom if we don't - then we're in the grey area where we have to apply common sense or other rules of thumb. I agree with you that it would be far better if we could get the special tool (and even better if the special tool were DFSG-free!), but would it be *required* for the generated work to be DFSG-free? We have to judge: in most cases my bet is that providing the special tool is optional (an interesting and useful optional, but still not mandatory). As with other grey areas we have to fall back to other and more fuzzy criteria here, such as: Which form would a _reasonable_ person with the skills to understand and appreciate the work prefer for modifying?. My only concern with this approach is: what do we mean by 'reasonable'? We will find to reach a consensus about a what a reasonable meaning of reasonable is in each case. Sorry, but we _cannot_ encapsulate our concept of freedom into a mathematical bright-line test that can _always_ be applied without judgement calls. There _will_ always be boundary case where we need to actually _think_ and apply some common sense to find a reasonable solution. Of course a clear-cut criterion is too hard (or maybe impossible) to find. The preferred form for modification definition seems to work well in all cases I can think of: obviously, there are cases in which we must be careful when applying it, but it works anyway. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpScHPtb5jHi.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
* Andrew Suffield ([EMAIL PROTECTED]) [050305 11:50]: You need to go talk to DWN and the anti-freedom advocates, who are the Whom of your fellow co-developers do you consider as anti-freedeom advocates? Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit Francesco Poli [EMAIL PROTECTED] On Sat, 05 Mar 2005 10:51:11 + Henning Makholm wrote: According to my statement, *if* we do get the special tool and all of the intermediate forms, then the work is free. My statement does not tell anything about the freedom if we don't - then we're in the grey area where we have to apply common sense or other rules of thumb. I agree with you that it would be far better if we could get the special tool (and even better if the special tool were DFSG-free!), but would it be *required* for the generated work to be DFSG-free? I'm wouldn't be comfortable with a genral rule that says that the answer *must* be either yes or no whenever an example matches the general hypothetical situation we are discussing here. We have to judge: in most cases my bet is that providing the special tool is optional (an interesting and useful optional, but still not mandatory). In many concrete cases I would probably agree with you. The preferred form for modification definition seems to work well in all cases I can think of: obviously, there are cases in which we must be careful when applying it, but it works anyway. I agree with this. What I'm objecting to is the idea that it is automatically and unconditionally the _author's_ preferrences that apply. -- Henning MakholmAnd why should I talk slaves' and fools' talk? I don't want him to live for ever, and I know that he's not going to live for ever whether I want him to or not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
MJ Ray [EMAIL PROTECTED] wrote: In the hand-crafted binary example, it would be *possible* to do both of those. Notice that the freedom doesn't require it to be easy. It's near the border, about where the nv driver was accused of being: free but hard to hack. I don't really see how you can blanket-ban them from main. As pointed out elsewhere, practical concerns usually keeps us away from these edge cases and the other few we'll argue about. How are you about the nv driver now? But how do you argue that a hand-crafted binary is sufficiently modifiable without also admitting the possibility that the output of a C compiler may be sufficiently modifiable? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] writes: Jeremy Hankins [EMAIL PROTECTED] wrote: First of all (and most telling, to my view) there's are a lot of reasonably in this definition. I think you're using these to paper over a lot of difficult cases. It doesn't work very well for our purposes because different people will always have different ideas of what's reasonable. This is as opposed to the preferred form which in the end depends on matters of fact (e.g., does the author *actually* prefer that form?) Indeed. It's not intended to be a formal definition - it's how I feel we should treat source code. I don't claim that phrasing it in a useful way would be easy. However, I don't believe that we should be deciding such matters on the basis of ease of phrasing. It doesn't need to be formal, but it does need to be useful. We want a guideline that's not going to be subject (too much) to the whims of the interpreter (d-l, mostly). Nothing you've suggested so far is either of those. Frankly, if you continue to say that the definition we use is bad without suggesting something better, I'm not going to be too interested in listening to you. Secondly, it seems that your definition is going to require extensive documentation in cases where the knowledge required to modify the code is specialized or arcane. Does a kernel patch require a treatise on kernel internals to accompany the patch? For that matter, does it require a copy of the kernel? After all, you can't very effectively modify the patch without the kernel as well. If it's impractical for anyone other than the author to modify the code, then I think it's insufficiently modifiable. If the information needed to modify the code is either fairly widely known or fairly easily learned, then that doesn't apply. So we have yet more nebulous wiggle in your definition: an exception for cases where the necessary bits to modify the work are fairly widely known or fairly easily learned. What about something to interface with a unique protocol only used in a particular industry? The protocol may be available, but no one outside of the industry has even heard of it. You may even have to pay to get a copy of the protocol specification. I don't think the mutt case is desperately important as far as free software is concerned, but if you weren't able to do that it would imply that you couldn't do many other things. It's reasonable to want to be able to incorporate code from an MTA into an MUA - it's not reasonable to expect to be able to do so for any given pair of them. Why not? What guideline are you using to decide that the ascii art dog of mutt code is reasonable, but moving code between works may not be? I'm afraid I simply disagree here. I'm not willing to go to an author and say If you write in machine code your work can never be Free. If nobody other than the author can modify a work, in what way is it free? We'd laugh at a license that attempted to claim that. Making it impossible through technical means should be equally non-free, even if that wasn't the author's intent. Let's be practical here. How many cases are you talking about? Mostly, if the author can do it and I can't it's because of skill level -- assuming I have access to everything the author does, as the preferred form definition requires. If a truly egregious case came up and it was clear to most folks that the author was either insane or malicious -- *and* a DD wanted to package it -- there'd be a lot of discussion of the issue, and we'd resolve it somehow. But it would be an informed discussion, knowing the particulars of the case, and the author might even have a chance to chime in in his defense. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
MJ Ray [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] wrote: But how do you argue that a hand-crafted binary is sufficiently modifiable without also admitting the possibility that the output of a C compiler may be sufficiently modifiable? I think it depends what the upstream author is using as source. How about you? Why does it depend on what the upstream author is using as source? How does that affect the recipient's ability to modify the work? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield wrote: Intermediate cases require the exercise of judgement, as always. A photograph of the Eiffel Tower is probably the best we're going to get; there's only one of them and it won't fit in the archive. A photograph of a PCB layout, constructed by a secret program, is not a reasonable substitute for the program. joke So, if I put a picture of Tour Eiffel in my package, what are the DFSG requirements: 1- pack a full 1tons steel replica of T.E. with each set of Debian/Sarge disks (complete with a crew of 1000 actors that play tourists, with 500 cameras) ; 2- pack a toy model of T.E. with each set of Debian/Sarge disks ; 3- pack a whole set of blueprints of the T.E. , so that any body can build its own /joke :-) a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] wrote: But how do you argue that a hand-crafted binary is sufficiently modifiable without also admitting the possibility that the output of a C compiler may be sufficiently modifiable? I think it depends what the upstream author is using as source. How about you? Why does it depend on what the upstream author is using as source? I don't see how we can obtain source codes which never existed, so that seems like one bound. How does that affect the recipient's ability to modify the work? That's a different question: if a recipient is incapable of modifying the work, does it mean that they do not have the freedom to modify it? I say they have freedom but are incapable of exploiting it. I rephrase: how can you argue that a hand-crafted binary is not sufficiently modifiable to offer the freedom to study and adapt? -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] writes: MJ Ray [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] wrote: But how do you argue that a hand-crafted binary is sufficiently modifiable without also admitting the possibility that the output of a C compiler may be sufficiently modifiable? I think it depends what the upstream author is using as source. How about you? Why does it depend on what the upstream author is using as source? How does that affect the recipient's ability to modify the work? One way to think about it is that one's ability to modify a work using a particular source is better indicated by the author's choice of source than J. Random User's. In other words, what the author chooses as source is a good predictor of what other folks are best off using as source. I'm not willing to override the author's opinion without a _very_ good reason, and even then only on a case-by-case basis with lots of discussion. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 03, 2005 at 06:59:44PM -0800, Michael K. Edwards wrote: On Thu, 3 Mar 2005 17:15:41 -0700, Joel Aelwyn [EMAIL PROTECTED] wrote: [snip] Actually, we aim to throw out 100% of closed-source software. But I'm assuming you were just being careless with trying to make a point. Unfortunately, the point you're trying to make also misses. Well, I was a little bit careless, in that I didn't spell out the bit where 98% 99.5% implies that closed-source software workflows are typically even sloppier about retaining editable image formats than open-source workflows are (unless, of course, regenerating those images is such a frequent task that it overcomes someone's laziness threshold). I think that's a useful benchmark for whether passing JPEGs around is acting in good faith, whether or not you want to throw out 100% of closed-source software. In other respects, you seem to be in violent agreement with the scope of the argument in the message you quoted, which was that the author's actual process is good enough even if it isn't the way that imaging-industry professionals would do it. That's not my entire opinion, though, as I discuss below. I would agree it's a useful consideration; whether it's a benchmark, I'm not so certain, but it certainly affects the question Do we consider the claim that this is the source format insanity? (or, really, more likely, is anyone insane enough to want to deal with this source?). When what we are being purist about is images, we want the trade-off chosen by a sophisticated, experienced manipulator of images of that kind -- which may well not be the earliest machine-parseable source, and may omit the details of intermediate manipulations which are obvious to a skilled practitioner and not worth automating. Similarly, when what we are being purist about is software, we want the thing that a manipulator of software would use, and sometimes similar trade-offs are involved. Agreed. Consider a table of numbers in an approximation algorithm, originally machine-generated using a Perl one-liner heuristic, massaged by hand to truncate to integers (mostly alternating between floor and ceiling but tuned by trial and error), and then embedded in a header file. If I think there's little point in automating these steps because anyone skilled enough to create a useful replacement table could do it themselves easily enough, then it's reasonable for me to call the header file source code when I distribute it. This is true even if 1) I still have the Perl one-liner in a logbook somewhere and would look it up if I ever needed to recapitulate the work myself, 2) the massaging loses information and makes it impractical to do more than a point fix without redoing the heuristic, and 3) next time around I would probably write a second Perl one-liner instead of inserting the syntactic sugar by hand. Agreed. What would make it unreasonable to call the header file source code is if the idea behind these manipulations is an important part of the software design and is hidden from recipients in a way that it would not be if I disclosed the process I followed. If I document the intention behind the heuristic, and the rest is just aesthetic judgment and trial and error, then I have acted in good faith, even if parameterizing and automating all of the steps would show more professionalism. Still agreed. Now for a more controversial opinion. If the reason I'm disinclined to release the heuristic in machine-executable form is that it happens to be not a Perl one-liner but one of many functions of another piece of software that I don't want to give away for free, I think the resulting header file is still acceptable in free software. Just because I say solve this numerical integral as a starting point, then experiment doesn't mean I owe you a numerical integrator, even if that's how I got there to begin with and how I personally would go about subsequent changes. Sometimes the appropriate standard is not is it how the author does it but does it obstruct access to the ideas embodied in the software. I think that this is where the judgement call starts to creep in. If the statement is solve this numerical integral, then the ways of doing that are (fairly) widely known, documented, and there's a good chance that there are tools which will make it practical for the mythical reasonable person to accomplish this task sufficiently well to be able to modify things without it being excessively onerous (especially since, presumably, understanding that the starting point is a solution to one may be an important part of grasping what the table is for in the first place and how the code actually operates). I would say it's still is it how the author does it, with the caveat that it may warrant a broader interpretation. Just as I can edit C source code in Emacs, Vi, or any number of other editors - and that source may have meta-info for
Re: Let's stop feeding the NVidia cuckoo
On Fri, Mar 04, 2005 at 06:52:07PM +, Brett Parker wrote: Matthew Garrett [EMAIL PROTECTED] wrote: snip / I rephrase: how can you argue that a hand-crafted binary is not sufficiently modifiable to offer the freedom to study and adapt? How you can argue that a binary output by a compiler is not sufficiently modifiable to offer the freedom to study and adapt? In that particular case, you've got the output of compiler, therefore the authors prefered form of modification is the source, it's *really* got source, there was a before stage, it wasn't a hand crafted binary. I can see where you're coming from though. I think this is very much an edge case, and I doubt that there are *that many* people that would hand craft an elf binary without using a compiler chain. Of course, providing a binary only also limits which archs you can use it on, which you *might* be able to do given C/C++/ObjC/Fortran/SomethingGoesHere source. I wonder if I'm missing something, somewhere? I know of one example, but it's pathological, and in fact exists *as* an example: the various stages of How small can I make an ELF 'hello world' binary? that someone went through. Actually, I believe the author of that *did* start with a C source - ELF binary step, but that became fairly rapidly irrelevant to the example. I also don't think we should package it as a binary (we might care to package the entire documentation of the sequence, since it demonstrates some interesting things about how ELF binaries are built, but that then becomes a separate question). -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Fri, 04 Mar 2005 01:42:58 + Henning Makholm wrote: Scripsit Francesco Poli [EMAIL PROTECTED] But in the case of the photographer Laura, if she thinks (in good faith) that she has the JPEG only, then JPEG is her preferred form for modification. When she finds out that another format existed, she may or may not change her mind about what is her preferred form for modification. In this case source code may change format. I think basing a definition that strictly on internal psychological properties of the author is going to lead to madness. It is not easily observable and may cause the status of a work to fluctuate unpredictably between free and non-free as the author changes his mind. What you say here is a fair concern, and I agree that following too closely all changes of author's mood is unreasonable. On the other hand, we must adopt a source code definition that allows it to change form: see my Fortran-C example. Note that the GPL does not define that it is the author that does the preferring. Yes, but the author's opinion (more precisely the last modifier's one) counts as he/she is the one who actually modifies or modified the work and allowing him/her to translate from a language to another one is really important, IMO. The what would the author do principle is good for defining the easy cases where no further analysis is necessary: 1) On one side, if the author deliberately refuses to let us have and distribute the form of the work _he_ keeps around for the purposes of editing it later, then we should not consider the work free. Indeed. This is my primary concern and is what I was trying to address when I talked about preferred form for modification and its possible changes. 2) Conversely, we cannot reasonably accuse the author of releasing his work under non-free conditions if he *does* give us every form he himself used to create it, and allows us to distribute them under otherwise free conditions. I agree entirely, but with a s/used to create it/uses to modify it/ Let me (try to) clarify what I mean. Suppose that J. Random Hacker initially generates a work by using some special tool (a non-free tool that generates images representing fractals, for instance); then he goes on modifying it with normal manipulation tools (The Gimp, for instance). What is source code in this case? Does it include the special tool? I don't think it does: that is the preferred *tool* for *creating* the initial version of the work, not the preferred *form* for *modification*. Source code is the work in the format used for making modifications to it. Between these two applications of the rule is a grey area. It is not a particularly large grey area, but it is there, and pretending that it doesn't exist at all (say, by clinging to an interpretation that says we must keep mind-probing the author at intervals to find out whether the work stays free) will not help anybody. As with other grey areas we have to fall back to other and more fuzzy criteria here, such as: Which form would a _reasonable_ person with the skills to understand and appreciate the work prefer for modifying?. This seems to be one of the points Matthew is making, and I think he is right in making that particular point. My only concern with this approach is: what do we mean by 'reasonable'? If someone takes Linux 2.6.11 and translates it in assembly (the whole kernel? most people would call him/her 'unreasonable'!), then modifies it (in assembly!) and distributes the result (as assembly code), do you think that he/she is violating kernel hackers' copyright? I would think that the result is distributed in the preferred form modification (preferred at least by the last modifier, and possibly by other people that may be considered 'unreasonable'). In other words, I think it's OK. (Which doesn't mean that I in any way agree with his apprarent attempts to use that point as a lever to shoehorn works that fail condition (1) above into Debian main). Here I definitely agree with you. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpOTnlIkDxXq.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] writes: Source code is any form of a work that allows any user who might be reasonably expected to modify the work to perform any modifications that they might be reasonably expected to perform. Occasionally a work may have several forms that meet this criterion. First of all (and most telling, to my view) there's are a lot of reasonably in this definition. I think you're using these to paper over a lot of difficult cases. It doesn't work very well for our purposes because different people will always have different ideas of what's reasonable. This is as opposed to the preferred form which in the end depends on matters of fact (e.g., does the author *actually* prefer that form?) Secondly, it seems that your definition is going to require extensive documentation in cases where the knowledge required to modify the code is specialized or arcane. Does a kernel patch require a treatise on kernel internals to accompany the patch? For that matter, does it require a copy of the kernel? After all, you can't very effectively modify the patch without the kernel as well. And how about which modifications we should allow for? Is it reasonable that I want to take the source for mutt, insert whitespace to make it look like an ascii art dog, and put it on display? Or use elisp code in a high performance environment? Or perhaps it's reasonable that I take message processing code from an MTA and use it in some MUA... but the languages are different. Should I demand the author translate it for me? The form that the author used to create a work should be irrelevent to freeness. A 20 megabyte binary-only application is non-free, even if the author wrote and maintains it in a hex-editor. The author's preferred form for modification is a good metric, but not the be-all and end-all of whether a work provides sufficient freedom. I'm afraid I simply disagree here. I'm not willing to go to an author and say If you write in machine code your work can never be Free. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Wed, Mar 02, 2005 at 08:55:53AM -0500, Michael Poole wrote: Andrew Suffield writes: On Wed, Mar 02, 2005 at 12:36:30PM +, Matthew Garrett wrote: Requiring layered formats for source is also going to result in PNGs being non-free in many cases. This sort of mindless sophistry accomplishes nothing. Requiring source does not make programs non-free. Failing to provide source is what makes programs non-free. The contents of the Debian archive is not non-free just because we require source. Who is being a mindless sophist? People who scream every time we find a package with missing source, because obviously it's impossible that any such package could ever be distributed with source, and so by finding them we're making them non-free. It gets really tiresome. Like the people who blame bug reporters, as if the bug didn't exist before it was reported. Take, for example, /usr/share/doc/doc-iana/cctld/jp/sakamoto-sig.jpg from doc-iana, currently in main. It is a JPEG of a signature. We cannot distribute Sakamoto-san. The image was produced in Photoshop, which means there may not be a precursor file that is freely manipulable. What is source? snip rest of examples Wrong part of the thread, we've been here already. This is not directly relevant. In most cases, requiring layered formats for source is going to result in getting layered formats for source. It is obviously the correct thing to be distributing; upstreams who have it but don't distribute it probably just didn't think of it. In a significant number of cases, requiring layered formats for source will mean that DDs must create DFSG-sanitized orig tarballs by removing images that upstream distributes. Or by adding images that upstream did not distribute. You're doing it as well. Delete it is *not* the only possible answer to a buggy package. Stop pretending that it is. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Wed, Mar 02, 2005 at 02:41:43PM +0100, M?ns Rullg?rd wrote: Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Mar 02, 2005 at 01:16:44PM +0100, M?ns Rullg?rd wrote: Matthew Garrett [EMAIL PROTECTED] writes: Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 12:53:34AM +, Matthew Garrett wrote: What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? The freedom to modify the images to suit my purposes, of course. See http://www.fsf.org/licensing/essays/free-sw.html Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. Either this, or a photograph should be considered as source. This is a photograph is not sufficient information to determine whether something might be source. Extreme examples: a photograph of the text of a C file is not source. It could very well be, depending on intent. You know what I meant; twisting my words is a waste of time. Not everything written in every single mail has to stand up in court. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Wed, Mar 02, 2005 at 03:11:47PM -0500, Jeremy Hankins wrote: Andrew Suffield [EMAIL PROTECTED] writes: This is a photograph is not sufficient information to determine whether something might be source. Extreme examples: a photograph of the text of a C file is not source. A photograph of a lightning bolt isn't directly source, but it's the best thing physically possible for us to have short of source. Intermediate cases require the exercise of judgement, as always. A photograph of the Eiffel Tower is probably the best we're going to get; there's only one of them and it won't fit in the archive. A photograph of a PCB layout, constructed by a secret program, is not a reasonable substitute for the program. I think with these examples you're getting away from the preferred form for making modifications definition of source. Yes, I'm accepting or as close as is physically possible. Note that I'm not including economically possible or politically possible. I can easily defend relaxing restrictions enough to accomodate physical laws of the universe; I cannot do so to accomodate somebody else's profit margin. But if I were to take a picture of lightning and decide I wanted a slightly different picture, it seems I'd either edit the jpeg (possibly bitmap, but I don't see the point of making that source in most cases) or take a new picture. That example was carefully selected. You don't *get* another chance to take a picture of a lightning bolt. They only last a second or two, and every one is unique. That photo is the only one that will ever exist. (jpeg-compressed is no good when a non-lossy format is available, though). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 03, 2005 at 12:13:50AM +, Matthew Garrett wrote: Jeremy Hankins [EMAIL PROTECTED] wrote: So yes, I agree that the ability to modify works is key to their freedom. But, as has already been discussed, the best definition of good enough that we know of is the preferred form for modification -- generally the form preferred by the author. If you're still arguing about that then please provide an alternate definition. Source code is any form of a work that allows any user who might be reasonably expected to modify the work to perform any modifications that they might be reasonably expected to perform. Occasionally a work may have several forms that meet this criterion. By this definition, procmail is non-free because it does not have any forms that allow a reasonable person to modify it in reasonable ways. It is not the definition that we use. We accept procmail as free because it can be modified by the author, even though it's impenetrable to most other people. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 03, 2005 at 12:24:21AM +, Matthew Garrett wrote: If we're going to have this debate, then it ought to start by engaging in discussion with the wider community rather than being another Debian takes on the world PR disaster. What on earth would be the point of that? It won't magically become free just because the wider community doesn't want to make it free. If you are seriously suggesting that we would compromise our principles because the wider community doesn't like them, then sod off. They do not have anything to add to the discussion. Particularly since it's not even a discussion at present, but merely those of us who've been thinking about this stuff for a long time shooting down the FUD of those who haven't thought about it at all. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] wrote: That example was carefully selected. You don't *get* another chance to take a picture of a lightning bolt. They only last a second or two, and every one is unique. That photo is the only one that will ever exist. (jpeg-compressed is no good when a non-lossy format is available, though). My camera saves a JPEG of a lightning bolt. I distribute that in the belief that it's the only version of the picture in existence, and nobody argues over whether it's source code. Later on, I find that I'd accidently left my camera in the mode where it saves raw files as well. I add that to the next upload of the package containing the picture. Are older versions of the package now non-free? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] wrote: By this definition, procmail is non-free because it does not have any forms that allow a reasonable person to modify it in reasonable ways. The existence of two authors in the copyright statements suggests that that's not true. It is not the definition that we use. We accept procmail as free because it can be modified by the author, even though it's impenetrable to most other people. There's a difference between most other people and no other people. What use is the freedom to modify if nobody can make practical use of that freedom? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 03, 2005 at 12:51:47PM -0500, Michael Poole wrote: Andrew Suffield writes: On Wed, Mar 02, 2005 at 08:55:53AM -0500, Michael Poole wrote: Andrew Suffield writes: On Wed, Mar 02, 2005 at 12:36:30PM +, Matthew Garrett wrote: Requiring layered formats for source is also going to result in PNGs being non-free in many cases. This sort of mindless sophistry accomplishes nothing. Requiring source does not make programs non-free. Failing to provide source is what makes programs non-free. The contents of the Debian archive is not non-free just because we require source. Who is being a mindless sophist? People who scream every time we find a package with missing source, because obviously it's impossible that any such package could ever be distributed with source, and so by finding them we're making them non-free. That would be an interesting argument if there were no reasonable basis to disagree about what source code means in the context of a JPEG. The point of my mail was that there often is no clear (or usable or freely manipulable; the relevant metric may vary) source code version of a lossily compressed image. Your point is misplaced. It has got nothing to do with what I wrote. Wrong part of the thread, we've been here already. This is not directly relevant. What part of requiring layered formats for images makes it irrelevant that there is no layered format source for certain images? Wrong part of the thread. Despite your repeated efforts to change the subject, the mails you are replying to are still not directly about definitions of 'source'. In most cases, requiring layered formats for source is going to result in getting layered formats for source. It is obviously the correct thing to be distributing; upstreams who have it but don't distribute it probably just didn't think of it. In a significant number of cases, requiring layered formats for source will mean that DDs must create DFSG-sanitized orig tarballs by removing images that upstream distributes. Or by adding images that upstream did not distribute. You're doing it as well. Delete it is *not* the only possible answer to a buggy package. Stop pretending that it is. Delete it *is* the only option for DFSG-incompatible files, although a patch may later substitute a file that satisfies your whims. No. I can only assume malicious intent on your part at this point, as you have now twice directly ignored my indications of alternatives, and continue to spread FUD about them not existing. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 03, 2005 at 05:43:58PM +, Matthew Garrett wrote: Andrew Suffield [EMAIL PROTECTED] wrote: That example was carefully selected. You don't *get* another chance to take a picture of a lightning bolt. They only last a second or two, and every one is unique. That photo is the only one that will ever exist. (jpeg-compressed is no good when a non-lossy format is available, though). My camera saves a JPEG of a lightning bolt. I distribute that in the belief that it's the only version of the picture in existence, and nobody argues over whether it's source code. Later on, I find that I'd accidently left my camera in the mode where it saves raw files as well. I add that to the next upload of the package containing the picture. Are older versions of the package now non-free? Strictly yes, being mistaken is not an excuse. Just like if you discover that old versions of the package contained i386 binaries without source, the old versions are non-free. Also note that in both cases, they were *always* non-free (I really shouldn't have to explain this). The status has not changed, it's just that we weren't aware of it before. We probably wouldn't *worry* about this however, as the archive now contains source to the relevant file, so it's neither a legal nor an ethical issue. (It may be a technical issue that 'apt-get source' won't give you the right thing in the last stable release, but that's somebody else's problem). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
Jeremy Hankins [EMAIL PROTECTED] wrote: First of all (and most telling, to my view) there's are a lot of reasonably in this definition. I think you're using these to paper over a lot of difficult cases. It doesn't work very well for our purposes because different people will always have different ideas of what's reasonable. This is as opposed to the preferred form which in the end depends on matters of fact (e.g., does the author *actually* prefer that form?) Indeed. It's not intended to be a formal definition - it's how I feel we should treat source code. I don't claim that phrasing it in a useful way would be easy. However, I don't believe that we should be deciding such matters on the basis of ease of phrasing. Secondly, it seems that your definition is going to require extensive documentation in cases where the knowledge required to modify the code is specialized or arcane. Does a kernel patch require a treatise on kernel internals to accompany the patch? For that matter, does it require a copy of the kernel? After all, you can't very effectively modify the patch without the kernel as well. If it's impractical for anyone other than the author to modify the code, then I think it's insufficiently modifiable. If the information needed to modify the code is either fairly widely known or fairly easily learned, then that doesn't apply. And how about which modifications we should allow for? Is it reasonable that I want to take the source for mutt, insert whitespace to make it look like an ascii art dog, and put it on display? Or use elisp code in a high performance environment? Or perhaps it's reasonable that I take message processing code from an MTA and use it in some MUA... but the languages are different. Should I demand the author translate it for me? I don't think the mutt case is desperately important as far as free software is concerned, but if you weren't able to do that it would imply that you couldn't do many other things. It's reasonable to want to be able to incorporate code from an MTA into an MUA - it's not reasonable to expect to be able to do so for any given pair of them. The form that the author used to create a work should be irrelevent to freeness. A 20 megabyte binary-only application is non-free, even if the author wrote and maintains it in a hex-editor. The author's preferred form for modification is a good metric, but not the be-all and end-all of whether a work provides sufficient freedom. I'm afraid I simply disagree here. I'm not willing to go to an author and say If you write in machine code your work can never be Free. If nobody other than the author can modify a work, in what way is it free? We'd laugh at a license that attempted to claim that. Making it impossible through technical means should be equally non-free, even if that wasn't the author's intent. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] wrote: What on earth would be the point of that? It won't magically become free just because the wider community doesn't want to make it free. If you are seriously suggesting that we would compromise our principles because the wider community doesn't like them, then sod off. We don't need to compromise our principles. We need to be able to explain them clearly, and be able to counter the arguments made against them. They do not have anything to add to the discussion. Particularly since it's not even a discussion at present, but merely those of us who've been thinking about this stuff for a long time shooting down the FUD of those who haven't thought about it at all. Enjoying the view from inside my head? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Mar 02, 2005 at 02:41:43PM +0100, M?ns Rullg?rd wrote: Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Mar 02, 2005 at 01:16:44PM +0100, M?ns Rullg?rd wrote: Matthew Garrett [EMAIL PROTECTED] writes: Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 12:53:34AM +, Matthew Garrett wrote: What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? The freedom to modify the images to suit my purposes, of course. See http://www.fsf.org/licensing/essays/free-sw.html Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. Either this, or a photograph should be considered as source. This is a photograph is not sufficient information to determine whether something might be source. Extreme examples: a photograph of the text of a C file is not source. It could very well be, depending on intent. You know what I meant; In the context of this thread, I can't be quite sure. We have to distinguish between two cases: 1) the photograph being presented as being the source for the program that would result from compiling the C code depicted, and 2) as a picture of the source code for something. The photograph can quite obviously never be reasonably considered to be the source for the *program*, but a JPEG (or whatever format) can be the source for a *picture of the source for the program*. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] wrote: On Thu, Mar 03, 2005 at 05:49:18PM +, Matthew Garrett wrote: There's a difference between most other people and no other people. What use is the freedom to modify if nobody can make practical use of that freedom? Sounds to me like you are trying to argue that things like procmail shouldn't be free. I'll be sure to stop beating my wife once I have one. I've found several patches to procmail written by people who aren't the original authors. This suggests that it's practically modifiable. But you still haven't answered my question - what use is freedom to modify if nobody can make practical use of that freedom? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
MJ Ray [EMAIL PROTECTED] wrote: Maybe Jeremy could have sprinkled a just or some reasonablys into it to help you, but it looks fairly clear from the original context what narrow aspect he was looking at. Remember, your previous intervention Message-id: [EMAIL PROTECTED] only considered one question 'Is the JPEG your source?' from David Schmitt's list of questions. *You* specialised the subthread, so you shouldn't start playing people offside by regeneralising it. Jeremy said We're not worried about how modifiable the end result is. We're worried about how the author would prefer to make modifications, which was entirely the point I answered. I think the modifiability of a work is the defining characteristic of its freeness (or otherwise), and as a result the mechanism used to generate that work is unimportant. That applies to JPEGs as much as it applies to any other form of work. I haven't had an explanation for why the author should have any special say in the matter. Further, your definition of source code in Message-id: [EMAIL PROTECTED] is full of lawyerbombs and looks unworkable, apart from possibly causing a PR disaster by blanket-banning machine code sources from main if you mean one reasonably possible interpretation. I'm not attempting to claim it's a workable definition. I'm saying that it's my definition. I'm happy to admit that the way I've phrased it is currently inadequate. Having gone back and reread it, I still interpret that way. If that interpretation was wrong, then I wholeheartedly apologise. Given that he's already asked you Are you willfully refusing to understand what I said, I don't see how you can reasonably still claim that your representation of him was accurate. There are two possibilities here. Someone either believes that the modifiability of a work is more important than whether the work is in the author's preferred form for modification, or they don't. I'm having difficulty finding any way to fit Jeremy's statement into the first catagory, regardless of context. Again, I am seriously worried that I agree with Andrew Suffield. :-/ Why does this worry you? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Thu, 3 Mar 2005 18:23:21 +, Matthew Garrett [EMAIL PROTECTED] wrote: I've found several patches to procmail written by people who aren't the original authors. This suggests that it's practically modifiable. But you still haven't answered my question - what use is freedom to modify if nobody can make practical use of that freedom? Free-as-in-speech, remember? What use is a Photoshop file if you don't have Photoshop? What use is an MS Word document if you don't have Word? What use is C++ source if you don't have a C++ compiler? What use is yacc input if you don't have yacc? The latter three cases were just as dependent on non-free tools as the first not so long ago. It was common free software practice to include both input and output for the non-free tool (although I'm not sure I ever saw CFront output in a source tarball) so that the software would be both understandable and compilable. Maintainability was still restricted to those with access to the non-free tool, but that was seen as both 1) somewhat less important to free-as-in-speech concerns as such, and 2) temporary because free alternatives were under construction. But whether or not a free yacc would ever be available, I don't think anyone would have accepted as free-as-in-speech a piece of software that included yacc output without corresponding input. Declining to provide the real source code for a program is not just an obstacle to maintainability, it's a breach of good faith. It's playing lip service to free-as-in-speech without enabling others to understand and use the ideas in your code. That's only an issue for data such as images and formatted text if the ideas involved in the process of creating them are significant to the creative content of the work. I may not be impressed by someone who only provides a JPEG or a PDF if they obviously maintain the data in some more editable form, whether or not they use free software to edit it; but I probably don't care that much unless it's an attempt to channel use of the ideas in the work. Ultimately, that's why I object to the GFDL; and I would object similarly to calling a game free-as-in-speech if it's impractical to remove some trademarked graphic element because it's been pre-composed into many scenes that can't be satisfactorily reproduced without precursor image formats that the author has withheld. I think that it's reasonable (and the majority will of the Project) to override maintainers' judgment about the freeness of data, but only where a free-as-in-speech issue is being significantly compromised. I don't think it should be stretched to cover JPEGs (or PDFs) generally. Personally, I feel the same way about firmware; if the process used to reproduce the firmware blob isn't particularly relevant to the idea content of the driver, then I am happy to let the maintainer decide whether the upstream is acting in good faith with regard to the ostensibly free driver. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Mar 02, 2005 at 03:11:47PM -0500, Jeremy Hankins wrote: I think with these examples you're getting away from the preferred form for making modifications definition of source. Yes, I'm accepting or as close as is physically possible. Note that I'm not including economically possible or politically possible. I can easily defend relaxing restrictions enough to accomodate physical laws of the universe; I cannot do so to accomodate somebody else's profit margin. But I don't think you need to relax the restrictions at all to accommodate this example. But if I were to take a picture of lightning and decide I wanted a slightly different picture, it seems I'd either edit the jpeg (possibly bitmap, but I don't see the point of making that source in most cases) or take a new picture. That example was carefully selected. You don't *get* another chance to take a picture of a lightning bolt. They only last a second or two, and every one is unique. That photo is the only one that will ever exist. (jpeg-compressed is no good when a non-lossy format is available, though). I see the preferred form definition of source as suggesting a thought experiment. For example, I, a novice photographer, take a picture of a lightning bolt (assuming I can do this, as a novice photographer) to include in part of my splash screen for my new game. Later I decide I want a slightly different picture. What do I do? I'd probably either take a new picture or I edit the jpeg. If so, I'd argue that either the jpeg is source, or nothing is necessary for source. You can't simply decide that, for X kind of work, Y is always the correct source -- even if you then make allowances for physical impossibilities. You have to look at (for one thing, at least*) what the author would actually *do*. It's a question of fact, as I mentioned elsewhere. * I haven't yet decided whether there might be cases where the author is so crazy/nasty that his opinion isn't the deciding one. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Wed, 2 Mar 2005 14:15:33 -0800 Steve Langasek wrote: Are you implying that a 2-clause-BSD licensed manual can be distributed in main in PDF format, if the LaTeX source (preferred by upstream for making modifications to it) is kept secret and not available? I think it's sucky and we're better off distributing the LaTeX source as well if we can get access to it, but I'm not convinced that this should be a release-critical bug. I simply do not believe that LaTeX - PDF conversion constitutes a technical barrier to modification to the same degree as compilation of C/C++/Java source to native assembly/bytecode, because the amount of higher-level markup information that's lost differs by an order of magnitude. So it's fine if someone distributes C code after stripping all the comments and renaming all variables to non-significant short identifiers? I call it obsfuscated code, not source code. Note that, to the best of my knowledge, no LaTeX comment ends up in the PDF. Nor any user-defined LaTeX command. Nor any LaTeX label. You can take a PDF and usefully extract the entire text back out of it (even if people set cheesy no copy flags in their PDFs, thanks to non-crippled readers), and all that's missing is the typesetting markup; I don't want to extract plain text: I want to modify the manual because I noticed a typo at, say, page 11. I do not have any free tool to modify PDF files directly. Nor does the upstream author (he/she uses pdflatex !). I know how to write LaTeX code and have pdflatex. So does the upstream author. Why can upstream fix the typo the easy way, while I cannot (without rewriting all the LaTeX markup by reverse engineering)? Do you think that figuring out the LaTeX markup by looking at the resulting PDF is easy? but decompiling a binary gives you none of the text of the original higher-level source. I can extract all the strings contained in the binary executable with a decompiler (or even with the strings command), but no source comments, nor variable/constant identifiers. The same applies to the PDF: none of the original source comments, label, user-defined commands are recoverable. Interestingly enough, you also cited Java - bytecode compilation: I've been told that Java decompilers can recover even variable identifiers from bytecode (but I don't know if this is actually true). For this reason, proprietary programs written in Java are often built from obfuscated code (so that their actual source code cannot be obtained too easily from the distributed bytecode). -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpoy3ZiWz1TC.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 03, 2005 at 11:59:18PM +0100, Francesco Poli wrote: On Wed, 2 Mar 2005 14:15:33 -0800 Steve Langasek wrote: Are you implying that a 2-clause-BSD licensed manual can be distributed in main in PDF format, if the LaTeX source (preferred by upstream for making modifications to it) is kept secret and not available? I think it's sucky and we're better off distributing the LaTeX source as well if we can get access to it, but I'm not convinced that this should be a release-critical bug. I simply do not believe that LaTeX - PDF conversion constitutes a technical barrier to modification to the same degree as compilation of C/C++/Java source to native assembly/bytecode, because the amount of higher-level markup information that's lost differs by an order of magnitude. So it's fine if someone distributes C code after stripping all the comments and renaming all variables to non-significant short identifiers? No, it's not; but I'm not going to argue gray area analogies like this, because they're just not relevant under the DFSG. The DFSG says that for programs, we must have access to the source. It does not say that we have to have access to the source for things that are not programs. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Wed, Mar 02, 2005 at 01:11:38PM -0800, Michael K. Edwards wrote: On Wed, 02 Mar 2005 13:16:44 +0100, Måns Rullgård [EMAIL PROTECTED] wrote: In your case, your best bet would probably be to provide the photograph without the text, or (even better) provide the image in a more advanced format (e.g. XCF) with the photograph and text in different layers. Er, reality check? This is the software industry, not the publishing industry. It's a pain to work around obscured data and compression/decompression cycle artifacts when, say, fixing a spelling error in overlaid text, but amateur image manipulators do it all the time. If an image isn't permitted in a source tarball unless there's a color-glossy-magazine level of professionalism in facilitating later modifications, then you might as well toss out 98% of the GUIs in Debian, not to mention 99.5% of closed-source software. Actually, we aim to throw out 100% of closed-source software. But I'm assuming you were just being careless with trying to make a point. Unfortunately, the point you're trying to make also misses. It's good to encourage people to use sophisticated workflow when creating images, as when creating software. But we don't call software non-free when it isn't developed using Extreme Programming methodology or UML modeling, not least because these techniques are overkill for most module-scale programming projects. And we shouldn't call images non-free just because they weren't shot Camera RAW, imported to a Photoshop clone, and manipulated losslessly at every stage. I deal with archive-quality professional artwork prints (for those who want the fancy word, look up 'giclee'). For that, I start with a scan of the origional (normally 'painted with acrylics on pressed paper') artwork, at anything from 300-1200 dpi (600 is our standard default) on a professional quality scanner. This is done in a 24-bit uncompressed/lossless format because that's what's easy to get as lossless out of the scanner, and it's only travelling a high-speed cable. First thing after that is a conversion to 24-bit PNG with the addition of some metadata (date, artist, copyright info, title, etc), done using Photoshop, followed by color balancing and adjustments as necessary (again, done in PS). This is saved as the 'archive' copy. Additional copies (reduced size and thumbnail) are generated as JPEGs for publication on the sales website, with the quality set lower both to speed up load times and to prevent anyone from just downloading and printing a full-quality print without paying for it. Let's say that I convince the artist to turn this into a desktop theme package of some sort. The choices for What is source are: 1) The origional artwork 2) The raw scan 3) The PNG 4) One of the JPEGs #1 is *not* the preferred form of modification. Among other things, it is quite likely to have been sold, and thus could not possibly be modified (even though the copyright is retained); even if it had not been, it could not practically be given to anyone else, due to the lack of a working unionfs for the universe; one person modifying it would preclude another person doing so. 2) The raw scan might be - but due to the size and lack of useful metadata, it is discarded immediately after being converted to another lossless format. One could argue that it should not be discarded, but again, I wouldn't choose to work on this format, nor would the artist, so it seems like a fair bet that this isn't the preferred source. It might be the earliest machine-parseable source, but that isn't what the GPL cares about, nor do I think Debian should need to. 3) The PNG - lossless, compressed, and containing the relevant metadata. Still not convenient to give to users, perhaps; a lossless PNG can still be several tens of megs for even an 11x14 print at 600 dpi (the print is actually smaller than 11x14, that's the outer edge size of the display matte, not even the print paper). But it *is* the form I would use if I needed to make additional modifications (add a block text overlay, adjust color balance, etc). 4) The JPEGs - lossy, and published with a deliberate intent to prevent easy full-quality reproduction. On the other hand, it is quite possible that these would be the most useful, as packaged images, due to their small size and easy of inclusion as theme elements. 5) Transient formats - other than raw scan - may occur, especially in the process of modifying the preferred format. For example, Load a PNG, put it in a layer, create another layer, put text in it, smash them together, make sure it looks fine, save it as a PNG. I assert that this does not automatically make the temporary layered format the preferred one; it is my preferred *method* of modification, but not my preferred *format* for modification. Now, if I start saving out layered image data because I want to simplify future modifications, it *would* be my preferred format at that point. However, if my
Re: Let's stop feeding the NVidia cuckoo
Francesco Poli [EMAIL PROTECTED] wrote: Why can upstream fix the typo the easy way, while I cannot (without rewriting all the LaTeX markup by reverse engineering)? Do you think that figuring out the LaTeX markup by looking at the resulting PDF is easy? As a practical example of this, Python ships HTML documentation. This is in a pre-built tarball in the Debian source package, because the original docs are in latex and require latex2html to turn them into HTML. latex2html is non-free, so can't be a build-depend. Should the python docs be moved to contrib, or is the HTML sufficiently modifiable that they can stay in main? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Thu, 3 Mar 2005 17:15:41 -0700, Joel Aelwyn [EMAIL PROTECTED] wrote: [snip] Actually, we aim to throw out 100% of closed-source software. But I'm assuming you were just being careless with trying to make a point. Unfortunately, the point you're trying to make also misses. Well, I was a little bit careless, in that I didn't spell out the bit where 98% 99.5% implies that closed-source software workflows are typically even sloppier about retaining editable image formats than open-source workflows are (unless, of course, regenerating those images is such a frequent task that it overcomes someone's laziness threshold). I think that's a useful benchmark for whether passing JPEGs around is acting in good faith, whether or not you want to throw out 100% of closed-source software. In other respects, you seem to be in violent agreement with the scope of the argument in the message you quoted, which was that the author's actual process is good enough even if it isn't the way that imaging-industry professionals would do it. That's not my entire opinion, though, as I discuss below. When what we are being purist about is images, we want the trade-off chosen by a sophisticated, experienced manipulator of images of that kind -- which may well not be the earliest machine-parseable source, and may omit the details of intermediate manipulations which are obvious to a skilled practitioner and not worth automating. Similarly, when what we are being purist about is software, we want the thing that a manipulator of software would use, and sometimes similar trade-offs are involved. Consider a table of numbers in an approximation algorithm, originally machine-generated using a Perl one-liner heuristic, massaged by hand to truncate to integers (mostly alternating between floor and ceiling but tuned by trial and error), and then embedded in a header file. If I think there's little point in automating these steps because anyone skilled enough to create a useful replacement table could do it themselves easily enough, then it's reasonable for me to call the header file source code when I distribute it. This is true even if 1) I still have the Perl one-liner in a logbook somewhere and would look it up if I ever needed to recapitulate the work myself, 2) the massaging loses information and makes it impractical to do more than a point fix without redoing the heuristic, and 3) next time around I would probably write a second Perl one-liner instead of inserting the syntactic sugar by hand. What would make it unreasonable to call the header file source code is if the idea behind these manipulations is an important part of the software design and is hidden from recipients in a way that it would not be if I disclosed the process I followed. If I document the intention behind the heuristic, and the rest is just aesthetic judgment and trial and error, then I have acted in good faith, even if parameterizing and automating all of the steps would show more professionalism. Now for a more controversial opinion. If the reason I'm disinclined to release the heuristic in machine-executable form is that it happens to be not a Perl one-liner but one of many functions of another piece of software that I don't want to give away for free, I think the resulting header file is still acceptable in free software. Just because I say solve this numerical integral as a starting point, then experiment doesn't mean I owe you a numerical integrator, even if that's how I got there to begin with and how I personally would go about subsequent changes. Sometimes the appropriate standard is not is it how the author does it but does it obstruct access to the ideas embodied in the software. Back to the image context: just because I provide some JPEGs as part of a piece of free software shouldn't mean that I owe you my full-resolution lossless inputs and the color calibration framework I also use to produce fine art prints, as long as my image manipulation workflow is not an important part of the way the software itself works. It's not really much different from using my pet non-free prettyprinter as part of the editing workflow for my program's code -- you may have a hard time modifying it and keeping it equally pretty without reformatting it completely, but it isn't really an obstacle to idea reuse. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] wrote: [...] The odds are that we always have something that it is possible to modify *somehow* by necessity of packaging, so why do you think we need to worry about that and ignore upstream? Because taking upstream's preferred form for modification leads us to believe that it's possible for large binary objects to be source, even if nobody other than the author can be realistically expected to modify them. You can argue that that meets the GPL, but I don't think you can reasonably argue that it's free software. The DFSG requirement for source is inspired by one of the FSF's four freedoms: The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this. Providing something that is the preferred form for modification does not necessarily make it possible to study how the program works or to adapt it to your needs. In the hand-crafted binary example, it would be *possible* to do both of those. Notice that the freedom doesn't require it to be easy. It's near the border, about where the nv driver was accused of being: free but hard to hack. I don't really see how you can blanket-ban them from main. As pointed out elsewhere, practical concerns usually keeps us away from these edge cases and the other few we'll argue about. How are you about the nv driver now? [...] Again, I am seriously worried that I agree with Andrew Suffield. :-/ [...] It seemed an odd thing for you to say. I do not consider him a good example to follow. Then again, me neither. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
* Andrew Suffield ([EMAIL PROTECTED]) [050304 08:50]: They do not have anything to add to the discussion. Particularly since it's not even a discussion at present, but merely those of us who've been thinking about this stuff for a long time shooting down the FUD of those who haven't thought about it at all. Again, it's not the case that you've the absolute truth. Even if you don't like it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 12:53:34AM +, Matthew Garrett wrote: What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? The freedom to modify the images to suit my purposes, of course. See http://www.fsf.org/licensing/essays/free-sw.html Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] writes: Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 12:53:34AM +, Matthew Garrett wrote: What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? The freedom to modify the images to suit my purposes, of course. See http://www.fsf.org/licensing/essays/free-sw.html Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. Either this, or a photograph should be considered as source. In your case, your best bet would probably be to provide the photograph without the text, or (even better) provide the image in a more advanced format (e.g. XCF) with the photograph and text in different layers. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Wednesday 02 March 2005 12:28, Matthew Garrett wrote: Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 12:53:34AM +, Matthew Garrett wrote: What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? The freedom to modify the images to suit my purposes, of course. See http://www.fsf.org/licensing/essays/free-sw.html Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? This has two sides: 1) Is the JPEG your source? If you e.g. have edited in the gimp, saved it as .xcf (with the text in a separate layer) probably not. If you have e.g. run it through an automated script, adding attribution (photographed by ... at ...) probably yes. 2) Do you find someone who is interested in maintaining it within Debian and does he accept the JPEG as source? Of course this example falls short of further aspects: * If a photographer adds attributions into the JPEG, what would he think if they are removed (e.g. by cropping the image)? * If the picture contains not a single line of text at the bottom but complex annotations of the picture, it seems stupid to write it directly into the JPEG. Is this worse than not using (possible superfluous) #defines for register values? Regards, Daivd -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Let's stop feeding the NVidia cuckoo
On Wed, Mar 02, 2005 at 01:16:44PM +0100, M?ns Rullg?rd wrote: Matthew Garrett [EMAIL PROTECTED] writes: Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 12:53:34AM +, Matthew Garrett wrote: What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? The freedom to modify the images to suit my purposes, of course. See http://www.fsf.org/licensing/essays/free-sw.html Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. Either this, or a photograph should be considered as source. This is a photograph is not sufficient information to determine whether something might be source. Extreme examples: a photograph of the text of a C file is not source. A photograph of a lightning bolt isn't directly source, but it's the best thing physically possible for us to have short of source. Intermediate cases require the exercise of judgement, as always. A photograph of the Eiffel Tower is probably the best we're going to get; there's only one of them and it won't fit in the archive. A photograph of a PCB layout, constructed by a secret program, is not a reasonable substitute for the program. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] writes: Måns Rullgård [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] writes: Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. Either this, or a photograph should be considered as source. I'm having difficulty reconciling these two statements. The first of those wasn't seriously intended. The point is that talking about the source for a photograph is meaningless. The camera stores JPEGs, and that's what we'll have to use, like it or not. In your case, your best bet would probably be to provide the photograph without the text, or (even better) provide the image in a more advanced format (e.g. XCF) with the photograph and text in different layers. That still results in one layer being a JPEG (effectively). Is that JPEG able to satisfy the source requirements? Requiring layered formats for source is also going to result in PNGs being non-free in many cases. A layered format is only one manner to provide a reasonable source form. The author could also provide the raw JPEG and an ImageMagick command he used to add the text. Whether a PNG should be considered source or not depends on the content. If I made a PNG consisting of a white background with a black rectangle, I probably wouldn't bother to save any other format. If the image were made up from many elements with transparency etc., saving an XCF (or equivalent) would make sense, so the elements could be repositioned and a new PNG generated. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Wed, Mar 02, 2005 at 12:36:30PM +, Matthew Garrett wrote: Requiring layered formats for source is also going to result in PNGs being non-free in many cases. This sort of mindless sophistry accomplishes nothing. Requiring source does not make programs non-free. Failing to provide source is what makes programs non-free. The contents of the Debian archive is not non-free just because we require source. In most cases, requiring layered formats for source is going to result in getting layered formats for source. It is obviously the correct thing to be distributing; upstreams who have it but don't distribute it probably just didn't think of it. Cut it out. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
Daniel Stone wrote: On Wed, Mar 02, 2005 at 12:51:59PM +, Andrew Suffield wrote: No, not really. I can't reasonably alter the text to fix your spelling mistake, for example. We should not be forced to put up with a spelling error just because you couldn't be bothered to provide source. It's not like there's any barrier to you providing source here, you just haven't done it. Er, so what if there's hideous solar flare in his picture? Is the JPEG non-free because you can't correct that, also? How about: If the author could change something but you can't, he probably hasn't given you the source? -- Lewis Jardine IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Mar 02, 2005 at 01:16:44PM +0100, M?ns Rullg?rd wrote: Matthew Garrett [EMAIL PROTECTED] writes: Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 12:53:34AM +, Matthew Garrett wrote: What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? The freedom to modify the images to suit my purposes, of course. See http://www.fsf.org/licensing/essays/free-sw.html Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. Either this, or a photograph should be considered as source. This is a photograph is not sufficient information to determine whether something might be source. Extreme examples: a photograph of the text of a C file is not source. It could very well be, depending on intent. If the photograph is an artistic composition, that happens to include a piece of paper (or a computer monitor) with C source on it, I can't see any reason to require that code as a text file. Program code in machine readable form should only be required if the code in question is intended to be executed by whomever it is distributed to. This is not (typically) the case with code visible in a photograph. A photograph of a lightning bolt isn't directly source, but it's the best thing physically possible for us to have short of source. Exactly my point. We should only be requiring source where there exists a source that can be stored and distributed digitally. Intermediate cases require the exercise of judgement, as always. A photograph of the Eiffel Tower is probably the best we're going to get; there's only one of them and it won't fit in the archive. Here I guess one could give the exact time and coordinates to the location where the photograph was made, and perhaps other details allowing someone to make another similar photograph. A photograph of a PCB layout, constructed by a secret program, is not a reasonable substitute for the program. Again, it depends on intent. If the photograph is intended to primarily depict the *layout*, we might wish to get the layout in a standard file format for PCB layouts. If, on the other hand, the it is a photograph of a PCB board, and the exact layout is not interesting, I can see no need for any source. Requiring the actual program is still unreasonable though. We don't require distribution of a program to be accompanied with the editor used to write the source, we require only the source code as such. Here we are touching on an aspect where the GPL and the Debian rules differ, though. Software released under the GPL can still be such that it can only be compiled with a non-free compiler, whereas Debian requires everything in main to be buildable using only free tools (present in main?). -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Måns Rullgård [EMAIL PROTECTED] wrote: Whether a PNG should be considered source or not depends on the content. If I made a PNG consisting of a white background with a black rectangle, I probably wouldn't bother to save any other format. If the image were made up from many elements with transparency etc., saving an XCF (or equivalent) would make sense, so the elements could be repositioned and a new PNG generated. Ok. I have some sympathy with that viewpoint. However, people should be aware that adopting this standard /will/ put us at odds with the community as a whole, not to mention the practical implications of having to check every single graphic file in the archive. While it would be nice to have that level of ability to modify pictures, it's not clear that lacking them is a significant impediment to the ability to provide free software. If it was, I'd have expected rather more wailing and gnashing of teeth by now. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Mar 02, 2005 at 12:36:30PM +, Matthew Garrett wrote: Requiring layered formats for source is also going to result in PNGs being non-free in many cases. This sort of mindless sophistry accomplishes nothing. Requiring source does not make programs non-free. Failing to provide source is what makes programs non-free. The contents of the Debian archive is not non-free just because we require source. In most cases, requiring layered formats for source is going to result in getting layered formats for source. It is obviously the correct thing to be distributing; upstreams who have it but don't distribute it probably just didn't think of it. Suppose I hired an artist to create some artwork for my programs (logos, icons, etc.), and I was only given PNG files with the completed images. Would this make the entire package non-free? Of course I could as the artist for whatever source he might have, which be may or may not be willing to give me, probably depending on license terms and amount of payment. Even if he did give me all the source files he had, these could still be in a bad format requiring non-free software to be useful (e.g. Photoshop). How should such cases be treated? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield writes: On Wed, Mar 02, 2005 at 12:36:30PM +, Matthew Garrett wrote: Requiring layered formats for source is also going to result in PNGs being non-free in many cases. This sort of mindless sophistry accomplishes nothing. Requiring source does not make programs non-free. Failing to provide source is what makes programs non-free. The contents of the Debian archive is not non-free just because we require source. Who is being a mindless sophist? Take, for example, /usr/share/doc/doc-iana/cctld/jp/sakamoto-sig.jpg from doc-iana, currently in main. It is a JPEG of a signature. We cannot distribute Sakamoto-san. The image was produced in Photoshop, which means there may not be a precursor file that is freely manipulable. What is source? The current interpretation is that it simply is not relevant to the freedoms we want to serve, but if we change that interpretation, it because non-free due to the changed interpretation. Or/usr/share/doc/HOWTO/en-html/MindTerm-SSH-HOWTO/leech.jpg, which is a screen capture of an apparently non-free FTP tool. LeechFTP itself is the apparent source under your argument. Or will someone be obliged to make a new bitmap image capture -- obviously not really the source, but good enough to manipulate? A number of the (old) HOWTOs contain JPEG images; it is plausible that the files used to create them no longer exist. What then? ntp-doc includes a collection of JPEG photos of products that presumably work with ntpd. What is the source for those images? splint-doc includes a tangential photographicl image of a wall at the start of the Splint manual. Will the Debian maintainer be obliged to remove that? In most cases, requiring layered formats for source is going to result in getting layered formats for source. It is obviously the correct thing to be distributing; upstreams who have it but don't distribute it probably just didn't think of it. In a significant number of cases, requiring layered formats for source will mean that DDs must create DFSG-sanitized orig tarballs by removing images that upstream distributes. There may be no layered precursor file; the precursor file may no longer exist; or it may be in a non-free format. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit Lewis Jardine [EMAIL PROTECTED] How about: If the author could change something but you can't, he probably hasn't given you the source? That is a very good rule of thumb, and really should be everybody's first test for deciding whether something is source or not. However, it still isn't robust enough to withstand attacks from determined literalists. For example, you'll want to exclude instances where the reason I cannot change something that the author can is that the author is smart enough to understand the program and I'm not. Conversely, the rule does not cover cases where the author has thrown out the real source with the deliberate intention of preventing anybody from modifying the work easily. -- Henning Makholm Panic. Alarm. Incredulity. *Thing* has not enough legs. Topple walk. Fall over not. Why why why? What *is* it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] writes: How does the mechanism used to generate the text on the picture alter how modifiable the end result is? But we're not worried about how modifiable the end result is. We're worried about how the author would prefer to make modifications. Thus how it's generated is about as relevant as it gets, short of a statement by the author on the subject. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Wed, 02 Mar 2005 13:16:44 +0100, Måns Rullgård [EMAIL PROTECTED] wrote: [snip] No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. Either this, or a photograph should be considered as source. I really, really hope this is sarcasm, or reductio ad absurdum, or something. In your case, your best bet would probably be to provide the photograph without the text, or (even better) provide the image in a more advanced format (e.g. XCF) with the photograph and text in different layers. Er, reality check? This is the software industry, not the publishing industry. It's a pain to work around obscured data and compression/decompression cycle artifacts when, say, fixing a spelling error in overlaid text, but amateur image manipulators do it all the time. If an image isn't permitted in a source tarball unless there's a color-glossy-magazine level of professionalism in facilitating later modifications, then you might as well toss out 98% of the GUIs in Debian, not to mention 99.5% of closed-source software. It's good to encourage people to use sophisticated workflow when creating images, as when creating software. But we don't call software non-free when it isn't developed using Extreme Programming methodology or UML modeling, not least because these techniques are overkill for most module-scale programming projects. And we shouldn't call images non-free just because they weren't shot Camera RAW, imported to a Photoshop clone, and manipulated losslessly at every stage. Cheers, - Michael
Re: Let's stop feeding the NVidia cuckoo
On Wed, 02 Mar 2005 13:16:44 +0100 Måns Rullgård wrote: No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. No, it's not. The actual physical object is not the preferred form for making modifications to the work (i.e. the photograph): it's the preferred form for recreating a similar work from scratch. Either this, or a photograph should be considered as source. Source code is the preferred form for modification. In the case of a photograph, if the digital camera stores pictures in JPEG format, you must start from that. It won't necessarily be your preferred form for making modifications to the work, but it may be. In your case, your best bet would probably be to provide the photograph without the text, or (even better) provide the image in a more advanced format (e.g. XCF) with the photograph and text in different layers. In the case of a photograph with a text over it, preferred form for modification will probably be a layered image format: then that format is the source code form. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp8PwbPUJivq.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Wed, 2 Mar 2005 13:28:44 + Matthew Garrett wrote: Måns Rullgård [EMAIL PROTECTED] wrote: Whether a PNG should be considered source or not depends on the content. If I made a PNG consisting of a white background with a black rectangle, I probably wouldn't bother to save any other format. If the image were made up from many elements with transparency etc., saving an XCF (or equivalent) would make sense, so the elements could be repositioned and a new PNG generated. Ok. I have some sympathy with that viewpoint. Please note that this is the preferred form for modification viewpoint. And I agree with this standpoint. A really simple image may well be preferred in PNG format when you want to make modifications to it. But when the upstream author keeps some other format that he/she modifies in order to regenerate the PNG image, then that other format is the source code: failing to provide it is failing to give others the same modification comfort that upstream has... However, people should be aware that adopting this standard /will/ put us at odds with the community as a whole, not to mention the practical implications of having to check every single graphic file in the archive. Avoiding compromises with freedom is hard, but Debian SC states that the project promises to avoid them. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp1zQQc4vzV6.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Wed, 02 Mar 2005 14:50:20 +0100 Måns Rullgård wrote: Suppose I hired an artist to create some artwork for my programs (logos, icons, etc.), and I was only given PNG files with the completed images. Would this make the entire package non-free? Of course I could as the artist for whatever source he might have, which be may or may not be willing to give me, probably depending on license terms and amount of payment. Even if he did give me all the source files he had, these could still be in a bad format requiring non-free software to be useful (e.g. Photoshop). How should such cases be treated? Let me compare your example, with the following one: Suppose I hired a programmer to create some modules for my programs (low-level functionalities, etc.), and I was only given precompiled object files to link my program against. Would this make the entire package non-free? *Yes* Of course ask the programmer for whaterver source he might have (C, assembly, ...), which he may or may not be willing to give me, probably depending on license terms and amount of payment. Even if he did give me all source files he had, these could still be in a bad language requiring non-free software to be useful (e.g. proprietary compilers or assemblers). How should such cases be treated? *Contrib* (because of non-free or non-packaged Build-Depends:), as long as the package is DFSG-free itself The same applies to images with no source available or with source that requires non-free components. Of course, when source is really unavailable: sometimes the PNG image is source itself, sometimes it's not... -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpCXjmwcANof.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Tue, 1 Mar 2005 16:04:36 + Matthew Garrett wrote: That's, uh, entirely insane. Maybe it's insane, but could please explain why? [...] No. Autogenerated C is not the preferred form for modification, but nor is it a practical form for modification (in most cases - this is not always true). However, in almost all cases it *is* practical to modify a JPEG. OK, let's consider another example. HTML and plain text are practical form for modification. Are they always source code? Even when they are generated from DocBook XML (and upstream prefers to modify XML)? I don't think that a form that's practical for modification necessarily qualifies as source code. It may be source code (if it's also the preferred form for modification), or may not, depending on circumstances. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpmolLzfdX6J.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Wed, 2 Mar 2005 13:11:38 -0800 Michael K. Edwards wrote: It's good to encourage people to use sophisticated workflow when creating images, as when creating software. But we don't call software non-free when it isn't developed using Extreme Programming methodology or UML modeling, not least because these techniques are overkill for most module-scale programming projects. And we shouldn't call images non-free just because they weren't shot Camera RAW, imported to a Photoshop clone, and manipulated losslessly at every stage. I think you're missing the point that, when upstream author really prefers to modify an image using a lossy compressed format, then that format *is* the source for the image. This follows from the preferred form for modification definition of source code. Issues arise when authors keep suitable formats to modify images, but fail to provide the form that they prefer. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpjKlWaiZ3lk.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
Michael K. Edwards [EMAIL PROTECTED] writes: On Wed, 02 Mar 2005 13:16:44 +0100, Måns Rullgård [EMAIL PROTECTED] wrote: [snip] No, for a photograph the source is the actual physical object you've made a picture of, so a photograph can never be free. Either this, or a photograph should be considered as source. I really, really hope this is sarcasm, or reductio ad absurdum, or something. Something like that, yes. In your case, your best bet would probably be to provide the photograph without the text, or (even better) provide the image in a more advanced format (e.g. XCF) with the photograph and text in different layers. Er, reality check? This is the software industry, not the publishing industry. It's a pain to work around obscured data and compression/decompression cycle artifacts when, say, fixing a spelling error in overlaid text, but amateur image manipulators do it all the time. If an image isn't permitted in a source tarball unless there's a color-glossy-magazine level of professionalism in facilitating later modifications, then you might as well toss out 98% of the GUIs in Debian, not to mention 99.5% of closed-source software. It's good to encourage people to use sophisticated workflow when creating images, as when creating software. But we don't call software non-free when it isn't developed using Extreme Programming methodology or UML modeling, not least because these techniques are overkill for most module-scale programming projects. And we shouldn't call images non-free just because they weren't shot Camera RAW, imported to a Photoshop clone, and manipulated losslessly at every stage. I didn't say we should be *requiring* it. I was merely stating what I consider can reasonably be called source for the hypothetical JPEG with overlaid text. -- Måns Rullgård [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Wed, Mar 02, 2005 at 10:05:38PM +0100, Francesco Poli wrote: Well, I'm a bit surprised, here. You were the proposal A proposer in GR 2004-004 and the rationale seems to state that your understanding of both versions of the Social Contract (the one previous GR 2004-003 and the new one as amended by GR 2004-003 itself) implies that DFSG apply to everything we distribute in main, not only programs. See http://www.debian.org/vote/2004/vote_004 Now you seem to claim that DFSG#2 does not apply to non-programs, because its explanation says program. Yes. These two concepts are not in contradiction. Are you implying that a 2-clause-BSD licensed manual can be distributed in main in PDF format, if the LaTeX source (preferred by upstream for making modifications to it) is kept secret and not available? I think it's sucky and we're better off distributing the LaTeX source as well if we can get access to it, but I'm not convinced that this should be a release-critical bug. I simply do not believe that LaTeX - PDF conversion constitutes a technical barrier to modification to the same degree as compilation of C/C++/Java source to native assembly/bytecode, because the amount of higher-level markup information that's lost differs by an order of magnitude. You can take a PDF and usefully extract the entire text back out of it (even if people set cheesy no copy flags in their PDFs, thanks to non-crippled readers), and all that's missing is the typesetting markup; but decompiling a binary gives you none of the text of the original higher-level source. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] writes: Jeremy Hankins [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] writes: How does the mechanism used to generate the text on the picture alter how modifiable the end result is? But we're not worried about how modifiable the end result is. I think we have very, very different ideas about the goals of free software. In my world, we ask for source code because the ability to modify code is fundamental to free software. I'm not quite sure how that works for you. Are you willfully refusing to understand what I said, in the context I said it? I'm sure I could creatively quote you and come up with all sorts of interesting statements too. But that wouldn't actually get us anywhere. Here's what I said, in case you've forgotten: But we're not worried about how modifiable the end result is. We're worried about how the author would prefer to make modifications. Thus how it's generated is about as relevant as it gets, short of a statement by the author on the subject. So yes, I agree that the ability to modify works is key to their freedom. But, as has already been discussed, the best definition of good enough that we know of is the preferred form for modification -- generally the form preferred by the author. If you're still arguing about that then please provide an alternate definition. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Francesco Poli [EMAIL PROTECTED] wrote: On Tue, 1 Mar 2005 16:04:36 + Matthew Garrett wrote: That's, uh, entirely insane. Maybe it's insane, but could please explain why? It's not something that's been well discussed within the project, and I don't think it's an argument you're going to win. In fact, starting by filing release critical bugs is likely to ensure that the opposition is entirely entrenched to begin with. If we're going to have this debate, then it ought to start by engaging in discussion with the wider community rather than being another Debian takes on the world PR disaster. At the moment, we have a great deal of support from the wider community. We should work with them to change their minds, not start telling them that their standards of freedom are inadequate. I'm open to being convinced about the definition of source code we should require, but if I find an RC bug on any of my packages before we (as a project) have agreed on one then I'm not going to be very happy. [...] No. Autogenerated C is not the preferred form for modification, but nor is it a practical form for modification (in most cases - this is not always true). However, in almost all cases it *is* practical to modify a JPEG. OK, let's consider another example. HTML and plain text are practical form for modification. Are they always source code? Always source code? No. There are cases where they're machine-generated in such a way that modification is impractical without destroying function. Even when they are generated from DocBook XML (and upstream prefers to modify XML)? Yes, unless it becomes impractical to create certain classes of derived works that would be practical with the XML. I don't think that a form that's practical for modification necessarily qualifies as source code. It may be source code (if it's also the preferred form for modification), or may not, depending on circumstances. I think we're going to have to agree to differ on this point. If anything, it's clear that not everyone agrees on any one definition of source code. We can't simply make pronouncements on which one is correct - nobody here has that authority. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit Matthew Garrett [EMAIL PROTECTED] In fact, starting by filing release critical bugs is likely to ensure that the opposition is entirely entrenched to begin with. Why are you so determined to keep fighting strawmen? We should work with them to change their minds, not start telling them that their standards of freedom are inadequate. Strawman. We can't simply make pronouncements on which one is correct - nobody here has that authority. Is that the old debian-legal has no authority, and that in itself proves that the debian-legal tradition is wrong argument? -- Henning Makholm - Or hast thee (perverted) designs to attempt (strange, hybrid) procreation experiments with this (virginal female) self? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Thu, 03 Mar 2005, Matthew Garrett wrote: If we apply this to a photograph of a circuit board, we find that the photograph is the source. Quite possibly not, actually. Consider a 2 layer PCB, FE. A 20 megabyte binary-only application is non-free, even if the author wrote and maintains it in a hex-editor. The author's preferred form for modification is a good metric, but not the be-all and end-all of whether a work provides sufficient freedom. Why not? Why must a work be in a form that you prefer when the author finds it ideal for their work? What makes your prefered form of modification special over the author's? The whole point of requiring sourcecode, as I see it, is so that users (and Debian) have the same form that the author uses to modify the code, so we're capable of making the same kind of modifications as the author. Granted, I personally wouldn't package a work that was maintained in a binary only form using a hex-editor for Debian, if for no other reason than the fact that *I* can't modify the thing or audit it to satisfy a reasonable level of quality. But that's not to say that Gods or Goddesses of machine code can't package the thing. Don Armstrong -- She was alot like starbucks. IE, generic and expensive. -- hugh macleod http://www.gapingvoid.com/batch3.htm http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] wrote: I think we have very, very different ideas about the goals of free software. In my world, we ask for source code because the ability to modify code is fundamental to free software. I'm not quite sure how that works for you. I hope that you are never DPL in any world containing any other debian contributors while you think it is acceptable to misrepresent them like that. Even if you disagree with the other contributor, have the dignity to at least mark the abrupt trim before using motherhood and apple pie arguments against a point you seemed to completely miss. Are these word games how you want to be working on controversial issues? For someone who is already fretting about PR disasters in another message on this subject, I think you should heal thyself before lecturing others about communication. Also I fear how you will initiate a discussion about the SC if this is an example of your non-confrontational discussion. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Irony known: http://mjr.towers.org.uk/email.html#arrogance Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Matthew Garrett [EMAIL PROTECTED] In fact, starting by filing release critical bugs is likely to ensure that the opposition is entirely entrenched to begin with. Why are you so determined to keep fighting strawmen? Where's the strawman? The suggestion was made that post-Sarge, it would be appropriate to file RC bugs against packages containing graphics without the perferred form for modification being available. I said that this seemed insane, and then justified my opinion by pointing out that it wouldn't have the desired effect. We can't simply make pronouncements on which one is correct - nobody here has that authority. Is that the old debian-legal has no authority, and that in itself proves that the debian-legal tradition is wrong argument? What? No, it's the debian-legal has no authority, and therefore doesn't get to say 'Debian believes that source code means the preferred form for modification' argument, which is the same as the Matthew has no authority, and therefore doesn't get to say 'Debian believes that source code means any form of the work that makes it acceptably easy to modify' argument. We don't get to make those decisions. The project as a whole does. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Don Armstrong [EMAIL PROTECTED] wrote: On Thu, 03 Mar 2005, Matthew Garrett wrote: If we apply this to a photograph of a circuit board, we find that the photograph is the source. Quite possibly not, actually. Consider a 2 layer PCB, FE. Oh, sorry - I meant to go somewhere with that example, didn't and then left it in a horribly confusing state. I meant that a photograph of a circuit board that isn't intended to provide information about the layout of the circuit board should be acceptable as source, which might not be true if it's supposed to be a reference for board design. A 20 megabyte binary-only application is non-free, even if the author wrote and maintains it in a hex-editor. The author's preferred form for modification is a good metric, but not the be-all and end-all of whether a work provides sufficient freedom. Why not? Why must a work be in a form that you prefer when the author finds it ideal for their work? What makes your prefered form of modification special over the author's? I don't think /my/ preferred form of modification is more special than the author's, but if nobody but the author is in a reasonable position to alter the code then I don't think that's free. Free software is supposed to give us independence from the author - that's not possible if the work is effectively unmodifiable by anyone else. The whole point of requiring sourcecode, as I see it, is so that users (and Debian) have the same form that the author uses to modify the code, so we're capable of making the same kind of modifications as the author. I'd disagree - I think we want sourcecode because we want to be able to modify the work. That's subtly different to what you're suggesting, and there are works that could fall in one and not the other. From the point of view of modifiability, I don't think the author should be considered special. Granted, I personally wouldn't package a work that was maintained in a binary only form using a hex-editor for Debian, if for no other reason than the fact that *I* can't modify the thing or audit it to satisfy a reasonable level of quality. But that's not to say that Gods or Goddesses of machine code can't package the thing. Mm. As I said before, I think I have a fundamentally different take on why we want source code to the general view here. Beyond what I've said already, I don't have a desperately strong argument for why mine is better. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Thu, 03 Mar 2005, Matthew Garrett wrote: I don't think /my/ preferred form of modification is more special than the author's, but if nobody but the author is in a reasonable position to alter the code then I don't think that's free. If this is because the author is withholding information, then I agree... but if it's just because no one else can think in machine code, than I disagree. Free software is supposed to give us independence from the author - that's not possible if the work is effectively unmodifiable by anyone else. If I could find some way of specifying this without going the road of the GFDL, where it unecessarily restricts the license to very specific forms of sourcecode, I would consider it. However, the attempts that I've seen always seem to outlaw rather useful applications that the GPL's definition appears to allow. Don Armstrong [EMAIL PROTECTED] wrote: The whole point of requiring sourcecode, as I see it, is so that users (and Debian) have the same form that the author uses to modify the code, so we're capable of making the same kind of modifications as the author. I'd disagree - I think we want sourcecode because we want to be able to modify the work. That's subtly different to what you're suggesting, and there are works that could fall in one and not the other. From the point of view of modifiability, I don't think the author should be considered special. But who gets to decide? To someone who thinks in machinecode, perl[1] may be just as difficult to modify as machinecode is for me. I can modify the code, and anyone possessing the skillset that I have can modify the code. There's nothing I possess that can possibly be distributed that would help them modify the software that they don't have. As I said before, I think I have a fundamentally different take on why we want source code to the general view here. Yeah, I think we both agree on the main point of why we want sourcecode, we just differ on whether or not we will let the author use things that a normal person[2] wouldn't be capable of modifing that the author (and those with an equivalent skillset) would be. Frankly, there really shouldn't be any works that fall into this narrow region[3] being distributed in Debian anyway, on the purely technical grounds that the maintainer isn't capable of maintaining the code. Don Armstrong 1: To pick my favorite, but much maligned, language 2: Whatever that means 3: Oh yes, firmware. (Rhetorical) Why are we distributing code that we can't maintain? -- The trouble with you, Ibid he said, is that you think you're the biggest bloody authority on everything -- Terry Pratchet _Pyramids_ p146 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Ken Arromdee [EMAIL PROTECTED] writes: On Mon, 28 Feb 2005, Jeremy Hankins wrote: No, it doesn't. The lone JPEG is only non-free if the lossless version is what the original author would use to make a modification to the JPEG. If, for example, the original author threw out the lossless version immediately on making the JPEG, that's strong evidence it's not needed. Not necessarily. It might be that at the time the original author had no intention of any future modifications at all. Sure, I did say strong evidence, after all -- not proof. But we can play hypotheticals all day. What's the point? If we try to anticipate and decide in advance every corner case we'll get bogged down and get nowhere. Wait for a concrete example to discuss. Then we can decide based on the particular situation. Often if the author has no plans to modify the jpeg it's because it'd be trivial to reproduce, I suspect. In that case it may be reasonable to consider *that* the preferred means of modification. Who knows? -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
If people could prefer to code in that way back then, I have no difficulty believing that there are people today who honestly prefer a similar coding style when they write device drivers. Interesting point, yet maybe this coding style was preferred because of much simpler hardware at the time (just an uneducated guess) ? That indeed would not justify using global variables, but it seems there are now hundreds of registers in a video card. If the majority of the values is utilized no more than once or twice, with only a handful that keep being used, it does not really justify giving them human-friendly names, but what if the programmer always needs a large number of them at hand ? Could you clarify this to me please ? Then again, maybe the nv driver does not take advantage of much of the possibilities of the cards, and only uses a handful of registers. Two problems remain in my opinion: -security -the unhackability of the driver, which, if not contrary to the strict letter of the DFSG, are colliding at least with its spirit, in my opinion. Cheers, Camille d'Alméras __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Tuesday 01 March 2005 01:47, Henning Makholm wrote: Scripsit David Schmitt [EMAIL PROTECTED] The DFS_Guidelines_ don't need to hold up in court. Therefore they are able to say that source which is unacceptable for modification because of lack of documentation, poor programming practices, obscure language or any arbitrary criteria you might think of for unmaintainability is no service to our users They certainly _can_ say that, but I don't think they actually _do_. I took a look. The DFSG only talk about the source code. Unqualified. Probably based on the expectation, that every maintainer only packages software he feels able to properly support. I think many people (me first) often forget the greatest plus Debian has over most commercial Software Vendors: No need to pull strings in court and no marketing droids. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Let's stop feeding the NVidia cuckoo
Ben Johnson [EMAIL PROTECTED] writes: In my understanding, for now source code in Debian could as well be precompiled code or code that can only be compiled on a compiler than only can be compiled by itself. In fact, this is the case. Lots of code can only be compiled with GCC, and GCC can only be compiled by itself. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit Ben Johnson [EMAIL PROTECTED] If the majority of the values is utilized no more than once or twice, with only a handful that keep being used, it does not really justify giving them human-friendly names, but what if the programmer always needs a large number of them at hand ? Could you clarify this to me please ? I'm not really sure I understand what you are asking. It may well be that *you* would prefer having symbolic constants instead of magic numbers. My point is just that is quite conceivable that the programmer of the code in question _actually_ prefers working with the raw numbers, and that the code as distributed is therefore source code according to any reasonable definition. Two problems remain in my opinion: -security -the unhackability of the driver, which, if not contrary to the strict letter of the DFSG, are colliding at least with its spirit, in my opinion. In my opinion, the spirit of the DFSG does not express any opinion about hackability. Badly written, horribly bug-ridden code that nobody alive has any idea how to begin fixing can still be free software. Our mechanism for avoiding such code in Debian is not articifically broadening the scope of the concept of legal freedom, but instead the very powerful concept of the mainatiner's discretion. Practical unhackability is a _technical_ problem and should be handled through our procedures for resolving technical problems: 1) The maintainer should not package the code unless he feels that it can be maintained to Debian's standards of non-buggyness. 2) If somebody else thinks that the maintainer is deluding himself when he thinks the code is maintainable, he can try to convince the Technical Committee to override the maintainer's decision. 3) If the TC cannot be bothered to do anything about it, a GR can be proposed. -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit Ben Johnson [EMAIL PROTECTED] What I propose instead is that Debian considered a stricter definition of source code such as that in the GPL. The GPL's defintion of source is already the definition we use in practice when applying DFSG #1 in cases of doubt. This has been the case for years, probably ever since the DFSG was adopted. You seem to be assuming as a given that the code in question is not in the preferred form for modification. You have not been very successful in convincing the rest of the list that this assumption holds. -- Henning Makholm Hør, hvad er det egentlig der ikke kan blive ved med at gå?
Re: Let's stop feeding the NVidia cuckoo
Jeremy Hankins [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] writes: If we actually upheld this standard at present, it would result in us removing a large number of packages from Debian. Which packages? Without specific examples it's difficult to discuss this point. In fact this claim is made frequently (Oh, but that would mean we'd have to remove hundreds of packages!) -- and often it turns out to be wrong. nautilus, xplanet, gnome-games, eterm, gimp, gtkhtml, enlightenment, python-gtk, the mod-perl documentation, apache and openoffice are the ones installed here. Some number of them could just have the artwork removed. Of course, a large number of the pngs on systems would originally have been produced in something like the Gimp. Flattening them to pngs will have lost information, and it's possible that the original files still exist somewhere. If we're actually concerned, we need to contact everyone who produced a png that's present in the distribution and find out whether they still have original source files anywhere. Or, alternatively, we could accept that pngs are modifiable enough. However, even ignoring that, I think your definition leads to some strangeness. It suggests that a JPEG is DFSG-free in and of itself in some cases, but that the existence of a lossless representation of that picture renders the JPEG non-free unless it's distributed with that lossless representation. No, it doesn't. The lone JPEG is only non-free if the lossless version is what the original author would use to make a modification to the JPEG. If, for example, the original author threw out the lossless version immediately on making the JPEG, that's strong evidence it's not needed. What does the original author's intent have to do with it? Can I take the original author's JPEG, modify it and then distribute my modified JPEG in debian? Or does the fact that the author has a better version mean that my JPEG was unmodifiable? but I think that the GPL's definition is stricter than we should require in general. We don't have the DFSG because they provide philosophical freedoms - we have the DFSG because they allow people to engage in practical activities. If a piece of software allows someone to assert their freedom to perform those acts without onerous restrictions, then it ought to be free from a DFSG standpoint. Speak for yourself. One of the things that makes d-l so combustible* is that different people have lots of different opinions on why we need the DFSG and how we should use them. Why do you believe we require source code? Is it so that people can modify software, or is it to obtain some sort of philosophical purity? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 28 Feb 2005 10:16:46 + Matthew Garrett wrote: If we actually upheld this standard at present, it would result in us removing a large number of packages from Debian. I think that these issues are sarge-ignore because of GR2004-004, but will be release-critical bugs post-Sarge. That's, uh, entirely insane. If a JPEG can be considered free enough under some circumstances, I'm confused as to why it's not always good enough. OK, think of a program. I give you a file written in C, that can be compiled by gcc into the binary executable. Am I giving you the source code? Yes, in most cases, I am. Indeed. But what if the program is a parser generated by Bison? Now the C code is not source code anymore. The grammar description is the real source code. Also true. If C code can be considered free enough under some circumstances, why is it not always good enough? Because it's not always the preferred form for modification, that's why! No. Autogenerated C is not the preferred form for modification, but nor is it a practical form for modification (in most cases - this is not always true). However, in almost all cases it *is* practical to modify a JPEG. Machine-generated C code is fundamentally different to hand-written C code, in the same way that a machine-generated JPEG (for instance, something designed to stress test JPEG decoder algorithms) is fundamentally different to the more common sort. There is no fundamental difference between a JPEG that was derived from a lossless format and one that has always been a JPEG. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] wrote: On Mon, Feb 28, 2005 at 10:16:46AM +, Matthew Garrett wrote: Yes, it's odd, but it's odd in the opposite direction to the one you're coming at it from. The unexpected thing is that the binary, or jpeg, can *ever* be considered free. Conversely, any argument which says jpegs are always free enough, also says the same thing about program binaries. There's nothing special about pictures here. In the general case, a binary is insufficient - it's too complex for someone to be able to modify it in any way they want to. In the general case, a JPEG is modifiable in a way that a binary is not. Programs exist that allow you to read in JPEGs and produce new pieces of artwork. People use them on a regular basis. No comparable programs exist for ELF binaries. The obvious conclusion is that derived works can (in general) be produced from JPEGs, but (in general) not from ELF files. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett [EMAIL PROTECTED] writes: Programs exist that allow you to read in JPEGs and produce new pieces of artwork. People use them on a regular basis. No comparable programs exist for ELF binaries. The obvious conclusion is that derived works can (in general) be produced from JPEGs, but (in general) not from ELF files. I'll save this for next time someone claims that linking against a shared library (ELF file) creates a derived work. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Andrew Suffield [EMAIL PROTECTED] wrote: (Mostly cut, because this is the fundamental argument:) Yeesh, this is like the documentation thing all over again. Are we going to have to go through the litany of months of fruitless debates on the issue just to establish that special pleading doesn't apply to images either? What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
* Josh Triplett ([EMAIL PROTECTED]) [050228 02:45]: We do need some ability to determine if we have real source code available; preferred form for modification seems like a well-established definition, and far better than the alternatives. The DFSG doesn't give any specific definition - so, anyone is free to pick up their favourite ones. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
* David Schmitt ([EMAIL PROTECTED]) [050228 23:55]: On Monday 28 February 2005 02:43, Josh Triplett wrote: acceptable form for modification will get you in even worse trouble than (author's) preferred form for modification. The former is a subjective criteria, and could raise issues with any code that someone claims is difficult to maintain (due to lack of documentation, poor programming practices, obscure language, any arbitrary criteria you might think of for unmaintainability). The latter is an objective criteria, which will only ever trigger in cases of obfuscation and/or compilation. The DFS_Guidelines_ don't need to hold up in court. Therefore they are able to say that source which is unacceptable for modification because of lack of documentation, poor programming practices, obscure language or any arbitrary criteria you might think of for unmaintainability is no service to our users but instead does lock them into low quality code which can only be modified at high costs if at all. They would be able to say it, but they don't. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
[EMAIL PROTECTED] wrote: By throwing hardware support out the window? Good plan! We already did this with the firmwares decision. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Ben Johnson [EMAIL PROTECTED] wrote: [...] debian-legal is not *the* place where it should be debated, where else could it be ? Maybe debian-x, maybe debian-devel or maybe you need a new list. [...] Now, not everybody installing Debian on their belief it is the distro most committed to software freedom is aware of the legal finesses that allow nv in main. Just because you don't agree with the view doesn't make it a legal finesse. Keep your linguistic pyrotechnics in a dry metal box. I was baffled to learn nv is neither proprietary, nor free as defined by the FSF, to reach a common ground. [snip] Can you direct me to the reasoning of the FSF on this, please? Please do not top-post/whole-quote. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Mon, Feb 28, 2005 at 10:16:46AM +, Matthew Garrett wrote: Don Armstrong [EMAIL PROTECTED] wrote: What sorts of issues with JPEGs? We should have available and distribute the prefered form for modification for them as well. That is, whatever form upstream actually uses when upstream wants to modify the JPEG. In some cases, this will just be a JPEG. In others, it will be an XCF, SVG or something else entirely. If we actually upheld this standard at present, it would result in us removing a large number of packages from Debian. However, even ignoring that, I think your definition leads to some strangeness. It suggests that a JPEG is DFSG-free in and of itself in some cases, but that the existence of a lossless representation of that picture renders the JPEG non-free unless it's distributed with that lossless representation. If I delete the only copy of the lossless picture, is the JPEG now source? If a JPEG can be considered free enough under some circumstances, I'm confused as to why it's not always good enough. This parallels the case for programs. An i386 binary can be considered free enough under some circumstances, but the existence of source code renders that non-free unless it's distributed with source. Yes, it's odd, but it's odd in the opposite direction to the one you're coming at it from. The unexpected thing is that the binary, or jpeg, can *ever* be considered free. Conversely, any argument which says jpegs are always free enough, also says the same thing about program binaries. There's nothing special about pictures here. We did this one years ago and concluded that in the absence of source, it is possible for these things to be considered free. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
* Daniel Stone: On Sun, Feb 27, 2005 at 10:50:13AM +0100, Andreas Barth wrote: Is there some proof that the files are created that way, or is this just your assumptation? While you cannot prove it, it is incredibly unlikely that anyone would ever choose to write anything that way. After a brief look at the tinydns source code, I'm not so sure. 8- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Mon, 28 Feb 2005, Jeremy Hankins wrote: No, it doesn't. The lone JPEG is only non-free if the lossless version is what the original author would use to make a modification to the JPEG. If, for example, the original author threw out the lossless version immediately on making the JPEG, that's strong evidence it's not needed. Not necessarily. It might be that at the time the original author had no intention of any future modifications at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Maybe debian-x, maybe debian-devel or maybe you need a new list. Ok, debian-wankers, got it. If some people feel the topic is so absurd, why do they waste their time answering rudely ? I expect contradiction, but if gratuitously insulting others is some game, let them play with their sado-masochists friends, that's not my fetish. Just because you don't agree with the view doesn't make it a legal finesse. Keep your linguistic pyrotechnics in a dry metal box. I am already convinced by the arguments of the people who actually bothered to correct me through technical explanations that there is most probably no automatic obfuscation involved -bullying does not cut it on the other hand. What still bothers me is that after Daniel Stone's very opinion, nobody could honestly prefer to write a driver using hex values for registers AND functions, period. This is not just a case of bad coding practices, it is deliberate. What for ? Granted, there are 99,999% of chances this is devised to protect engineering secrets. Remain 0.001% to do whatever wrong. Can you direct me to the reasoning of the FSF on this, please? Certainly. From http://www.fsf.org/licensing/essays/free-sw.html: [software freedom includes] the freedom to improve the program, and release your improvements to the public, so that the whole community benefits. Access to the source code is a precondition for this. What is source code then ? From the GPL: The source code for a work means the preferred form of the work for making modifications to it. Now, only one person working at NVidia maintains the driver. Is this the proof of a lack of interest for NVidia's hardware from the free software developers, or that they are de facto denied the freedom to improve the program because the source is voluntarily obscure ? (Notice I did not say obfusacted.) Bye, Camille d'Alméras __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Ben Johnson wrote: Maybe debian-x, maybe debian-devel or maybe you need a new list. Ok, debian-wankers, got it. If some people feel the topic is so absurd, why do they waste their time answering rudely ? I really don't know the answer to that question. I don't think MJ Ray was answering rudely there, but it is pretty clear that Marco d'Itri was with the debian-wankers remark. debian-legal has picked up a handful of people who seem to find it important to reply to every other thread with an attack on debian-legal, on the legitimacy thereof, on the recent GR regarding non-programs and the DFSG, or on anyone who doesn't support reading the DFSG as a checklist. Perhaps it's a milestone: we've become a sufficiently well-established forum to have picked up regular trolls. :) Please don't let a few people spoil your outlook on debian-legal as a whole. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Let's stop feeding the NVidia cuckoo
--- Josh Triplett [EMAIL PROTECTED] wrote: I don't think MJ Ray was answering rudely there My sincere apologies to MJ Ray if I misunderstood what he was saying. Please don't let a few people spoil your outlook on debian-legal as a whole. - Josh Triplett Thank you, this is refreshing. Camille d'Alméras __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Sun, 27 Feb 2005 18:05:16 -0800 Don Armstrong wrote: What sorts of issues with JPEGs? We should have available and distribute the prefered form for modification for them as well. That is, whatever form upstream actually uses when upstream wants to modify the JPEG. In some cases, this will just be a JPEG. In others, it will be an XCF, SVG or something else entirely. Completely agreed. While there may be a better definition of source code than the prefered form for modification, I haven't seen it yet. Double agreed. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpMOBWlNw032.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
On Mon, 28 Feb 2005 10:16:46 + Matthew Garrett wrote: If we actually upheld this standard at present, it would result in us removing a large number of packages from Debian. I think that these issues are sarge-ignore because of GR2004-004, but will be release-critical bugs post-Sarge. However, even ignoring that, I think your definition leads to some strangeness. It suggests that a JPEG is DFSG-free in and of itself in some cases, but that the existence of a lossless representation of that picture renders the JPEG non-free unless it's distributed with that lossless representation. If I delete the only copy of the lossless picture, is the JPEG now source? If a JPEG can be considered free enough under some circumstances, I'm confused as to why it's not always good enough. OK, think of a program. I give you a file written in C, that can be compiled by gcc into the binary executable. Am I giving you the source code? Yes, in most cases, I am. But what if the program is a parser generated by Bison? Now the C code is not source code anymore. The grammar description is the real source code. If C code can be considered free enough under some circumstances, why is it not always good enough? Because it's not always the preferred form for modification, that's why! -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpUbBRbOM4hb.pgp Description: PGP signature
