On Thu, Feb 09, 2006 at 11:16:45PM +0200, Anton Zinoviev wrote: > On Thu, Feb 09, 2006 at 09:45:43PM +1000, Anthony Towns wrote: > > [ ] Choice 3: GFDL is DFSG-free and suitable for main in all cases [3:1] > I need to correct this. The title for my proposal is > [ ] Choice 3: GFDL is compatible with the current DFSG > First, the whole text of my proposal talks entirely about the current > DFSG. > Second, my proposal doesn't revoke automatically the decision of the > release team to remove the GFDL-documents from main. If my proposal > wins, it is the release team who will have to change this decision Frankly, I have no idea what the release team is expected to do in this circumstance. In spite of the Project Secretary's determination that this ballot option requires a 3:1 supermajority because it modifies the DFSG, given that I can't reconcile these claims that the GFDL always complies with the DFSG with any (IMHO) reasonable reading of the DFSG themselves, I am left without a suitable consistent interpretation that I can apply in the exercise of my own duties. I guess I could: - ignore that the Project seems to have gone insane and issued a position statement that I can't grok, and continue treating GFDL works as RC for etch - ignore the Project Secretary's interpretation that this amendment implicitly modifies the DFSG, and continue treating GFDL works as RC for etch - accept that I don't understand how the Project as a whole interprets the DFSG, and defer to either the Technical Committee or the FTP Team regarding the RC-ness of all licensing bugs - start a new GR - resign and let somebody else deal with it - have an existential crisis Of course, 1 and 2 are pretty monomaniacal options and likely to piss off anyone who voted for the GR, eventually leading me to 5 or 6; 3 sounds pretty unsustainable, and likely to lead directly to 6 and then to 5 anyway over my inability to understand how people think; and 4 is a bunch of crap work that I really have no desire to do because it's a ridiculous side show to the work of actually building a free operating system... so might result in me defaulting to 5. The ambiguity of this ballot option, both in not actually proposing text modifications to the DFSG proper and in advancing a partial, one-off interpretation of the DFSG which does not provide any real guidance on the question of what limits on modification *are* acceptable to Debian, are IMHO a serious problem. Not only will I be voting this option below "None of the above" (which, apparently unlike Anthony[1], I believe to be the normal and proper thing to do with a ballot option I consider unacceptable even if I don't really want to *discuss* it further), I will be fervently hoping that this option doesn't win. Of course, if people actually believe that this ballot option is *true*, they should naturally still vote for it -- I just have no idea what it means for someone to believe it's true, and would much prefer a ballot option that advanced a consistent interpretation of the DFSG. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/ [1] http://lists.debian.org/debian-vote/2006/02/msg00415.html
Attachment:
signature.asc
Description: Digital signature