On Mon, Dec 29, 2003 at 04:02:42PM -0500, Raul Miller wrote: > While this is better than your previous proposal, I would still vote > it below the default option if it were on a ballot. How is this information useful to anyone? Is there any form the proposal could take that you *wouldn't* rank below the default option? It's well-known that there are people who are vehemently opposed to anything but the status quo, and some others who'd rather demolish the distinction between non-free and main entirely. Mr. Suffield can correct me on this, but I do not think his GR is an effort to appeal to that audience. I suspect it is instead an effort to appeal to those who want to "ditch" non-free, and those who simply want to see this damn issue voted on sometime this decade. > Perhaps, in part, because I will need to install some non-free > software (patent restricted) to be able to vote on that ballot. Can you elaborate on that? Given that the applicability of patents varies by jurisdiction, why is this squarely on point for a non-free GR? France used to ban civilian use of all strong crypto. Did that make such software non-free for the whole Debian Project? > However, I also very much dislike the fact that you would strike the > following language from our social contract: > > We acknowledge that some of our users require the use of programs > that don't conform to the Debian Free Software Guidelines. If you thinking striking this sentence implies the converse (I don't think it does, but your mileage may vary), you are free to propose an amendment to Mr. Suffield's GR. Who knows, he may even accept it. With clause 5 stricken, the best place for it is probably clause 4, near the "commercial software" language. > and > > Thus, although non-free software isn't a part of Debian, we support > its use, and we provide infrastructure (such as our bug-tracking > system and mailing lists) for non-free software packages. > > If someone were to implement a decent alternative for that infrastructure, > I would be amenable to leaving that part out of the social contract, > but I do not like your "drop it on the floor" approach to this issue. Please define "decent alternative for that infrastructure". What specifically do you expect people to be able to accomplish with a parallel infrastructure when the existing suffices? People who raise this point often seem to be constructing a catch-22; if we don't have an "alternative infrastructure" in place before dropping Debian's support for non-free, then there is a "pragmatic" objection to dropping non-free; however, if the alternative infrastructure is expected to be in wide use, then the people who participate in the current infrastructure are going to have to migrate to it pro-actively in expectation that a GR elimninating will pass, which they can help defeat by refusing to move and citing their own stubbornness as evidence that no "alternative infrastructure" exists. I reject such callow and unprincipled[1] tactics. Hopefully you mean something less unsavory. > Furthermore, I think it's important to acknowledge that some of our > users require the use of non-DFSG software, and to support that use. Please define what you mean by "support"; you may find there is more common ground than you suspect. I haven't seen a single advocate of non-free-removal propose that we implement technological "countermeasures" against non-free software on Debian systems. The "vrms" package is about as hostile as anyone seems to intend to get. > More fundamentally, the "line" between "free" and "non-free" is extremely > complex, topologically. I think a fuzzy approach towards handling > stuff on one side of that line vs. the other is much more correct than > an inflexible approach. You're probably interested in repealing clause 1 of the Social Contract, then, which says "We promise to keep the Debian GNU/Linux Distribution entirely free software.". That sure seems like a simple, bright-line approach to me. Moreover, our current approach seems to be quite fuzzy despite the nominal bright-line approach. We have known DFSG-incompatible materials that are going to remain in main for the next release, by the decree of the Release Manager, and questionable materials typically remain in main while debates rage on the debian-legal mailing list. In the "inflexible approach" you deride, presumably there is some "single, correct" categorization of such materials, but we don't collectively know what it is until we reach a consensus through discussion. In short, I think I'll take a page from Bdale ( :) ) and opine that your "more fundamental" point is a red herring. [1] see "pragmatic" -- G. Branden Robinson | Build a fire for a man, and he'll Debian GNU/Linux | be warm for a day. Set a man on branden@debian.org | fire, and he'll be warm for the http://people.debian.org/~branden/ | rest of his life. - Terry Pratchett
Attachment:
signature.asc
Description: Digital signature