On Sun, Dec 02, 2001 at 05:04:32PM +1000, Anthony Towns wrote: > On Sun, Dec 02, 2001 at 12:03:09AM -0500, Branden Robinson wrote: > > On Sun, Dec 02, 2001 at 02:14:51PM +1000, Anthony Towns wrote: > > > On Sat, Dec 01, 2001 at 05:51:29PM -0500, Branden Robinson wrote: > > > > [Debian Policy group: I am not sure if the Debian Policy Manual is an > > > > appropriate forum for any of the following material. I invite your > > > > opinions.] > > > -policy is traditionally for technical policy, which the DFSG isn't. A > > > -legal FAQ or HOWTO or similar isn't an unreasonable thing to start. > > Okay, consider me smacked down for daring to raise this on -policy. > > Opinions are invited, as long as they aren't mine? You're the one who told me to take my guidelines to a FAQ or HOWTO instead of wasting the Policy group's time, despite the precedent of Policy 13.6. I stand by my (colorful) characterization of your remark. FWIW, I was inviting opinions of whether any portion, large or small, of my proposal might be germane to the Debian Policy Manual, not general opinions on anything that tickles your fancy. Since Debian Policy specifies the contents of debian/copyright and my proposal contains further indications of material that should be placed there, I thought it would be reasonable to make the Policy team aware of the possibility that my proposal might impact Policy 13.6. I apologize for being so ludicrously mistaken. > The -policy list is at its best when focussing on technical issues, not > legal ones. If you want to discuss legal issues, you won't get much useful > comment from the -policy list that you won't get from the -legal list. Geez. Should we get rid of Policy 13.6, then? > The Debian Free Software *Guidelines* are just that; they get interpreted, > not plugged into a script and acted upon literally. The GPL, even with > its "changing [..] is not allowed" clause is perfectly legitimate in > DFSG free packages. Do we get to interpret the DFSG as freely as we like? Do we have to interpret it consistently? If the answers to these questions are "yes" and "no", respectively, then you've made an excellent point and I should consider withdrawing my proposal. Otherwise, I suggest my proposal, in whatever form it ultimately ends up, as the first formal step towards a set of clarifications or interpretive guidelines (a term which, as you'll recall from the thread you exhaustively perused, I have used to refer to them before). > > > > 2) License text used as such (i.e., not as an example) [...] is permitted > > > > to be held non-modifiable. [...] > > > This doesn't particularly match current practice. > > Do you mean particularly, or precisely? > > The copyright and license text and authorship information and upstream > info and whatever else doesn't have to be freely modifiable, whether > its contractually obligating, or whatever. > > Separating out contractual terms and optional terms doesn't match > current practice. Is your argument that my explanatory text is overly simplistic, that we should throw out clause 2) entirely, or that we should expand it to include whatever the copyright holder wants? > > Let me guess. You're one of the people who didn't read the thread > > before replying! > > Yes, clearly that must be true. Any disagreements or misunderstandings are > always due to someone else not reading what you wrote. Okay, perhaps you're just deliberately disregarding what I write, instead. Wouldn't be the first time. > It doesn't make sense because: > > * It's unjustified. Why 32,768 bytes? Why not 32,000 bytes? You want 32,000 instead? You've got it. I don't care. It's in what appears to be the correct ballpark to not disrupt the status quo too badly. > What if the author doesn't speak English, and wants to include > some text in Korean or Japanese that happens to not be encoded > as efficiently? A good point; if rare, I'd suggest this is a good place to let the "guideline" escape hatch take effect; if not rare, the guideline should be elaborated to not compel recoding into inefficient forms. For what it's worth, applying the quantity to "codepoints in ISO 10646-1" instead of "bytes" where appropriate, strikes me as perfectly satisfactory. > If it's not about disk space, why not make it > 32k characters? If it's about disk space, why not let people > put their text in an accompanying gzipped file and limit the > total length of that to 32k? It's about disk space as a useful metric of ensuring that we don't bend DFSG 3 so far that we break it. > * It's awkward. The definition alone is awkward enough, but trying > to work out how many "non-obligating, squeezed-whitespace bytes" > are taken up isn't a reasonable thing to expect. While I'm certain this is actually an argument on principle as opposed to practicality, it's pretty easy to write a sed script to perform the whitespace squeezing you denigrate. (I did it in vim in just a few seconds with s/[[:space:]]\+/ /g and s/^[[:space:]]//). This may stun you, but I included the bit about whitespace so that invariant text that was heavy on whitespace wouldn't be unfairly "taxed" by my proposal. At any rate, one possible way to apply this would be to have a lintian check that performs this squeeze internally and then warns if the text is too long. Whether certain language is legally binding or not is always a determination that will have to be made by a human. I'd be happy to author or co-author such a lintian check if that would assuage some of your concerns (and would probably do so anyway), but, as I said, I get the feeling that technical impracticality is a veil for some deeper level of offense you're taking. > Now sometimes you certainly do have to set a particular, arbitrary, limit > on things and just live with problems: voting or drinking ages, and speed > limits come to mind. This is an unfair analogy because these are statutory constructs of governments and explicit exceptions are practically unknown. I know of none to voting or drinking ages in the United States, and only law enforcement and emergency vehicle officers are explicitly permitted to violate the speed limit. I do not see any good analogy between "law enforcement" packages versus "civilian driver" packages in main. If you're in main, you're in main. > This doesn't seem like one of them though. Indeed. I am not proposing something with the force of law. Hence the term "interpretive guidelines". > > Therefore, leaving terms like "fairly small" open to the > > interpretation of the developers presumes a common standard of > > reasonableness that may not exist, because some developers do not > > feel the existence of any non-modifiable text is justifiable. > > And? If you can come to a consensus that the developer who thinks zero > bytes is wrong, I am not proposing that we make any such determination. Are you? > why do you think you can't come to any consensus on whether things > are overly long, or aren't? I cannot accept your conclusion if I do not accept your premise. > > Therefore, one logical way of resolving this difference of opinion is by > > specifying a numeric limit, rather than expecting them to be able to > > duplicate the judgement of some specific other developer who may elect > > to take them to task for not being "reasonable enough" in their > > interpretation of inherently approximate terms like "big" and "small". > > These are *guidelines*, remember. > > Yes, they are, they're not laws So, you argue that they are bad because they are like laws on the one hand, and bad because they are not like laws on the other. It's reasoning like this that frequently leads me to conclude that resolving disagreements with you is a futile effort. > that have to have every ambiguity nailed down so that no one could > possibly misinterpret them. As you have pointed out, they do not have this feature. And as I have replied, they need not. > Pretending that they are (by nailing down some ambiguities) The fact that I have bothered to tie an explicit number to some operative, interpretive guideline, is not a pretense that misinterpretation is impossible, and I'm pretty sure that you know that. Do you take moral offense to cookbooks that specify quantitative values for the amount of butter or salt that should be used in a recipe, as opposed to phrases like "a pinch of", "a dollop of", "some dabs of"? > is just going to cause more problems in future when people start > imaginging that more clauses have been nailed down and must be > interpreted exactly as written. I'm happy to restore the original clause 5) if you feel that would help prevent this misunderstanding. Are you familiar with it? I feel you must be, since I was (purportedly) wrong to assert that you hadn't read the thread. > In any event, people who can't tell the difference between a copyright > file that says something about petting your dog, and one that includes > the full text of every speech made to Congress in the 1990s simply > have to be ignored. I take you're asserting that the former is unobjectionable while the latter is not? What about the GNU Manifesto? Does it belong in a copyright file or not? > On Sun, Dec 02, 2001 at 12:13:11AM -0500, Branden Robinson wrote: > > Maybe this is how you feel, but I so far haven't seen general agreement > > on anything. Especially now that Anthony Towns has spoken up and > > characterized the entire proposal as a waste of time. > > Perhaps you should do some rereading yourself. I said "characterized", not "stated". Your arguments continue to imply to me that we'd all be better off if I'd never bothered to make a proposal (or perhaps even discuss) the issue of documentation licenses in conjunction with DFSG 3 in the first place. Please feel free to correct me on this point. > > In other words, if the total amount if Invariant text in a GNU > > FDL-licensed work totals 48k, I can't put 24k of that in one package and > > 24k of it in another, because the GNU FDL won't let me. All the > > invarient text has to go in both packages. > > However, if you have to GNU manuals, licensed under the FDL, with 20kB > of invariant sections each, you can't combine them into a single package, > even if that might be more convenient for you and for your users. Who says you can't? Are you forgetting the "guideline" part again? (In actual fact, any such package might manage to meet the guidelines anyway -- because there is a large intersection between the manuals' respective Invariant Sections; unless you interpreted the GNU FDL to mean that if you published 10 manuals the GNU Manual Omnibus, you'd be in violation of the license if you had only one copy each of the GNU GPL and GNU FDL, instead of 10 each for a grand total of 20 copies. I won't speculate on either the reasonableness or the enforceability of such an interpretation.) -- G. Branden Robinson | Human beings rarely imagine a god Debian GNU/Linux | that behaves any better than a branden@debian.org | spoiled child. http://people.debian.org/~branden/ | -- Robert Heinlein
Attachment:
pgppqclpU1A6w.pgp
Description: PGP signature