On Thu, May 20, 2004 at 12:39:00PM +0200, Andreas Barth wrote: > > For the whateverth time, it's the project's interpretation of the SC > > that's important, not mine. I don't believe it's possible to interpret > > the current SC to allow that policy; but I might be wrong. > I disagree. Really? You think it's my interpretation that's important? Then quick, make me supreme dictator for life, so folks with unimportant interpretations can't overrule me. Or do you think it's possible to interpret the current SC to allow GFDL'ed docs in main? Then quick, better talk to the tech ctte so they can change the release policy as they seem to think's best without violating the SC, and to Andrew Suffield since his clarifying amendment doesn't seem to have achieved his goals. Or do you think that I can never be wrong? > The SC still says that our priorities are our users and > the free software community. That there are no "Debian User > Interaction Guidelines" doesn't change that. So, if we have to either > neglect a bit the freeness in border cases (as Debian is about > creating a free operating system, hardware-specific low-level firmware > _is_ a border case), or to finally release sarge, I consider that the > SC gives us not only the right to release sarge now, but really tells > us to do it. So, if it was quicker to release sarge by developing d-i using VMWare -- and purchasing licenses for d-i hackers to do so, you'd think that was a good thing? We've previously decided not to do that (or something similar, which people who care can look through the -private archives for), because we've considered ourselves to be too committed to freedom to rely on non-free products as a project, if at all possible. More acutely, if it were easier to provide a GUI by using a non free graphics toolkit (Motif? pre-QPL/GPL Qt?), would you likewise consider the social contract to require us to release using that because it'd be better, or faster, and who cares about violating our commitment to free software in just a couple of cases anyway? (For reference, the SC changes also cover GFDL'ed docs and other data; I think it'll take a reasonable amount of time for us to find and go through all the packages that contain such documentation and get it removed, rewritten or reverted appropriately. I can't tell from the above whether you think make and glibc documentation count as irrelevant and to be ignored, or whether you think they should be all dropped, or something in between. You, or someone similar, will need to work that out if you're trying to be productive rather than rhetorical) In any case, if that's what you really think, you should make your case to the tech ctte, not me. Presumably if your idea's sound and sensible, it'll be easier to convince the handful of guys on that than to do a GR to set the policy as you apparently think is appropriate, but if not, you could do that too. Cheers, aj -- Anthony Towns <firstname.lastname@example.org> <http://azure.humbug.org.au/~aj/> Don't assume I speak for anyone but myself. GPG signed mail preferred. ``Like the ski resort of girls looking for husbands and husbands looking for girls, the situation is not as symmetrical as it might seem.''
Description: Digital signature