On Sun, Nov 25, 2001 at 07:17:05PM -0800, Thomas Bushnell, BSG wrote: > Initial observations or Brandon's proposal: Bzzzt. You lose points for forgetting how to spell my name despite the fact that we've communicated dozens of times before. > 1: Please separate the "whereas" from the actual proposal. People [...] The "whereas" is already separated, natch. It's there to bring the many people who won't bother to read the background material (somewhat) up to speed. If any proposal is adopted, it should contain only the proposed interpretive rules. > 2: The 16K limit should be checked against existing packages before we > say that's the number. It being universally agreed that we aren't > upset by the cases we know about, we should check and make sure they > don't run afoul of any new guideline. I agree. I wanted to kick this out of the nest, though, since I'd been sitting on it for a couple of weeks. > 3: I would *MUCH* prefer a limit that involved some kind of > proportionality to one that has a fixed size. You've got it. See the subsequent section. The GNU FDL is intended for documentation. If people stick to that, they already have the 5% proportionality exception. If somebody tries to license something that isn't documentation under the GNU FDL, they may have problems. I see that as a feature, not a bug. > 4: You are attempting to be "legal" and cover all cases. That's > already outside the spirit of the DFSG. Hence why this is not proposed as an amendment to the DFSG. > Please resist the (understandable) temptation to try and define things > in such a way that nobody ever need exercise any judgment or > understanding in the future. If you have specific objections, I welcome edits, but I reject the above assertion as justification for torpedoing this entire endeavor. We need something better than arbitrary decrees. People look to the DFSG, and to Debian's interpretation of it, for guidance in selecting their licenses. We need to acknowledge this leadership role, and behave responsibly, not capriciously. It's easier to do this if we have interpretive guidelines. > Elaborate definitions of like "instruction code for a computer" are > things that are not helpful: we all already know what that means, and > it's a purely internal guideline, so nothing is served by making it > too rigid. We should never create internal guidelines which have the > effect of perhaps blocking us from doing the right thing at some > future date. Feel free to propose edits. > 5: Your notion of a "work" is unclear. Are we talking about manuals? > Pretty much no manual is "instruction code". Or packages? This is > important if and only if you want to maintain the distinction between > the two sorts of cases, and there is no motivation I can see for doing > that. The FSF sees the need to distinguish the two (code vs. documentation). I myself was pretty happy with the simple old license that was on the FSF manuals. But the GNU FDL is here now and people want to use it, so I'm attempting to roll with the development instead of pretending it doesn't exist. RMS said he'd be unhappy if Debian had to reject stuff licensed under the GNU FDL. I'm trying to provide an avenue for us to prevent that without throwing wide the doors for abuse by people who violate the intent of the GNU FDL. > 6: I am *still* unclear why we need a policy. I don't trust everyone in the world to live up to the standard set by the FSF. The FSF put out a license called the GNU FDL and is asking the world to use it. That's great. The license contains no internal checks on abuse of Invariant Sections. I think that's not so great. I want an established rule that makes it clear that not everything licensed under the GNU FDL is rubberstamped "DFSG-free", since this could lead to violation of our Social Contract. Moreover, I want to reduce the amount of ad hockery that goes on with respect to license checking. If you'll ask around I think you'll find this is a goal of the FSF as well. More generally, Debian is and should remain the final arbiter of what the DFSG means, and how it should be applied. I think it is inappropriate for Debian to permit Richard Stallman, Eric Raymond, or Bruce Perens, among others, to fire off a mail to debian-legal and unilaterally tell Debian what it will and will not accept. To be fair, only one of the above people has done so. Another has his own organization, whose judgment he expects the entire world to accept, and one has, apparently, applied to become a Debian developer, and is willing to engage in reasoned discussion even with people like me[1]. > I would prefer to avoid making policies until and unless they turn out > to be necessary. And I'd rather pre-empt some flamewars. All I'm trying to say is, "you can't piggyback anything you want on the precedent that Debian allows non-modifiable texts like that of the GPL into packages in main". We need boundaries. > 7: Here is the sort of policy I would happily support, presuming you > can explain why, exactly, we need one at all: I'm rapidly reaching the conclusion that there is no explanation I can offer that you will accept. You want Debian to finesse these issues. I don't. > "Some documentation or other matter in Debian packages is sometimes > distributed under licenses that do not permit modification or the > distribution of modified versions. When these portions are small > relative to the size of the package, no harm accrues from distributing > them as part of Debian. However, when it comes to actual programs of > whatever sort, we continue to insist that modification always be > permitted. And, since changes to a program necessitate changes to its > associated documentation, any portion of documentation which might > need to be changed to correctly describe a change in the program must > also permit modification and distribution of modified versions." You are asking us to allow a lot more non-modifiable, and thus non-Free, material into Debian than we currently do. I find this stance unacceptable. > That seems to meet all the requirements. Rather than ordering > developers about what consitutes "small", I think we should trust that > developers are reasonable, and only if a problem seems likely to loom > should we go about trying to be more specific. An ounce of prevention is worth a pound of cure. Nothing about my proposed interpretive guideline is binding. It's not part of the Debian Policy Manual, the Social Contract, the DFSG, the Debian Constitution, or any other formal document. It can be amended freely at any time. I'm asking that we reach consensus on SOME policy (small p) because there are clearly issues of confusion. Sunnavind raised a valid concern; he asked a reasonable question that we can expect other people to ask in the future. The text DFSG provides no obvious answer. Your proposed paragraph above certainly does not follow from the DFSG in any obvious way (that doesn't mean it's bad, it means the issue is insufficiently specified by the DFSG). I'm trying to address this. What kind of crisis do you require to justify action in your opinion? The threat of a lawsuit? Charges that the Debian team are hypocrites because we'll let the GNU Emacs Manual (under the GNU FDL) into main, but not some other manual? What sort of strife will convince you of the need for even the feeblest of gestures, such as the one I have made? [1] You too, can play along at home! Match the name to the tactic! Depending on which web tabloids you read, the actual facts may surprise you! -- G. Branden Robinson | Communism is just one step on the Debian GNU/Linux | long road from capitalism to branden@debian.org | capitalism. http://people.debian.org/~branden/ | -- Russian saying
Attachment:
pgpKuZwCZWXra.pgp
Description: PGP signature