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
