Re: Proposal - preserve freedom of choice of init systems - Linux IS about CHOICE
Yes, by all means we should ignore the fake personas, Mr. Natural Linux, whoever you are. On Sun, Mar 2, 2014 at 7:25 PM, Natural Linux naturalli...@dcemail.comwrote: Matthias Urlichs, Why should we believe you or the bullshit excuses given in the article? The fact is, last year none of this crap was needed. Now it suddenly is. Furthermore gnome stole libgtk from the gimp project recently and then they made an incompatable libgtk 3.0. And now they're requiring all these bullshit daemons, and systemd. This is a political coup. We are being lead by the nose. Notice the arguments from the gnome and systemd people are always the same across all forums, for years. It is for your own good You must join the modern era They know better than us and we must join. Over and over again for the past year or two. I think these are the same people. Fake personas, or directed by their employers. They should be thrown out, we should recongise them for what they are. Real, traditional linux includes sysv or bsd style init (or openrc). libgtk2 (not 3). gnome2 (not 3). And no systemd. We should also take heed of Snowden's documents which show that the United States government, which is an evil force that blows up and burns alive little girls and boys in afghanistan iraq and elsewhere, had and has a program to subvert technology and software projects everywhere. Systemd and its shills are likely part of this. They should be thrown out of our community distributions. Pretty much anything by redhat is harmful nowadays. And anyone associated. -- Washington DC's Largest FREE Email service. --- http://www.DCemail.com--- A Washington Online Community Member --- http://www.DCpages.com
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
On Mon, 2010-02-08 at 00:35 +0900, Charles Plessy wrote: 3) Is there a benefit of allowing non-free files to be distributed together with the source of the Debian system ? Have you considered the harm? It means that users can no longer assume that whatever is in the source packages can be distributed by them under the DFSG. Especially since your proposal is all about making copyright information harder to locate, you are making things far harder. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
On Wed, 2009-05-13 at 10:53 +0200, Giacomo A. Catenazzi wrote: DFSG is a guideline and a target: we must no go far as the nearest point we reached, but it still a guideline. Consider: - we never had a full DFSG Debian (also when DFSG was written) - we have RC also on stable releases. What should we do in such cases? Block all dDbian website, all mirrors, etc. because it is clearly against our foundations? No. The Social Contract does not leave vague how we use the DFSG. It could say that we take the DFSG as a guideline, or as a target, but it does not. It does not say that we try to abide by it, or that we weigh it against other things; it says that we *do* abide by it, 100%. I wonder, how could it be written even more strongly? I have the feeling that if it said we will never intentionally include non-free software in Debian, no matter what the circumstances you would still start telling us that this is a mere statement of goals and intentions, but not anything actually binding. Of *course* there will be bugs. We cannot promise not to make mistakes. The argument is *not* about whether non-free things get in unintentionally. We can't make a promise never to make a mistake. But we can promise not to intentionally include non-free software, and it is this promise which we have now broken twice. Note that the Social Contract does *not* say that we treat non-free things as bugs just like other bugs. We make no promise about other bugs, except the general one to prioritize the interests of the free software community and our users, both of which involve fixing bugs. But section one doesn't just say it's a goal, or a priority, but says that it is actually a *promise* not just to try hard, but *never* to release non-free software as part of Debian. Where to put the line? This is the main problem: we have different interpretations and our foundation documents (and related discussions) doesn't provide us a true (and clear) interpretation. I think there is nothing unclear about it. We have a perfectly clear firm promise, and we have some people who do not want a firm clear promise, and are willing to pretend that the social contract doesn't say 100% free software. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote: I think this is the core of the disagreement. I do not call it a temporary override of a foundation document; I call it a temporary practical consensus between the needs of our users and the needs of the free software community. I don't understand. Either Social Contract section one and the DFSG prohibit the distribution of a non-free blob in the release, or they do not. If they prohibit it, then it is an override to distribute notwithstanding the prohibition. If they do not prohibit it, then no resolution is necessary. You seem to say an inconsistent thing: that they do prohibit it, and we can avoid that prohibition by calling it a practical consensus instead of an override. Surely, however, it is the effect that matters, and not the label you give it. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Firmware
On Fri, 2009-05-01 at 13:58 +0200, Stefano Zacchiroli wrote: On Fri, May 01, 2009 at 11:48:58AM +0200, Luk Claes wrote: What do people think of a new vote regarding the status of firmware? One of the options can probably be Peter Palfrader's proposal [1]. I'm very much in favor of having this vote early in the release cycle, and I was pondering about proposing it myself. Ideally, my goal would have been to have a vote on the issue in general, without any release-specific option. Peter's option is the main option I would like to see in, what else did you have in mind? Absolutely I'm in favor of having the decision now, calmly. My fear is that it won't matter what we do; the partisans of semi-free Debian will not get everything they want (simply because nobody ever does), and then will scream as the release is near that we must again have special exceptions. I hope I can be proved wrong. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Sun, 2009-01-11 at 10:32 +0100, Joerg Jaspert wrote: So, I think you made a mistake, a very serious one, and when asked about it, your explanation is completely unsatisfactory. How do we solve this? Currently, the only solution I see is that we ask the developers what they think, and hold another vote. Do you have any other idea in mind? How about accepting that the project wants to release, and not want to have yet another vote by someone who just doesnt like the outcome of the last? Please hurt another project, not Debian, we had enough of this already. It is true that the project wants to release. It is not true that the project wants to release on just any terms whatsoever. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Sun, 2009-01-11 at 11:35 +0100, Joerg Jaspert wrote: Do you have any other idea in mind? Btw, Joerg, that goes for you too. If you have something constructive to say, this would be a good time. How about you going elsewhere until Lenny is released, then coming back as soon as that happens and start working on what is left to fix then? (Not right before a release, right after a release for a change.) Sure, how about a deal. Lenny will be the *last* release with this non-DFSG stuff, and we'll go away for this one. I thought that was the deal last time, but it turns out that just this once is repeated in Debian about as often as copyright extension bills in the US Congress. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Sun, 2009-01-11 at 10:44 -0700, Bdale Garbee wrote: That's why I think the main outcome of this ballot was an assertion of desire by the voters that we release Lenny. Actually, I ranked #1 first, and yet, I have a desire that we release Lenny. However, I don't want a bad release, I want a good one. That means we don't release until it's ready--which in my view includes DFSG bugs just as much as other RC bugs. The option that won the vote does not say release Lenny no matter what, it says, release Lenny, not looking to carefully at DFSG problems in firmware blobs, more or less. It was a carefully worded option, and it won; it is a mistake to substitute for it something like release Lenny no matter what, and then to proceed to ignore the clear statement of the winning option that *only* firmware blobs get the special treatment. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Sun, 2009-01-11 at 21:07 +0100, Frank Küster wrote: Robert Millan r...@aybabtu.com wrote: 4- Bugs which are trivial to fix, such as #459705 (just remove a text file), #483217 (only affects optional functionality that could be removed according to the maintainer) Of course it could be removed, and it's technically trivial. The question is whether it is worth the disadvantages to our users, when we still expect (or hope or something in between) that the files will be released under a DFSG-free license once we manage to attract enough attention from Donald. What concrete strategies would you suggest to attract attention from Donald? I'll bet you that quite likely we will remove this from Debian is about the most effective strategy we have. It may not work, but I suspect if it doesn't, then there is nothing we could do that would work. If *nothing* would work, is it your position that we should ignore the DFSG problem here forever? Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Fri, 2009-01-02 at 16:59 -0800, Steve Langasek wrote: When you say he was asserting a power that was not his, what exactly are you saying? I'm having trouble understanding. It is unquestionably the Secretary's job to prepare the ballot and announce the results; this requires the Secretary to determine which options require a 3:1 supermajority. How do you suppose he should go about this task, other than to do his best job? There is no plain English reading of A Foundation Document requires a 3:1 majority for its supersession that implies the secretary should apply a 3:1 majority requirement to resolutions which aren't even intended to override the Foundation Documents, let alone amend them. Um, it seems to me that's exactly what it says. The question is not whether the resolution intends to override a foundation document, it's whether it actually does so. Nor is it anything short of absurd for the Secretary to declare that a resolution amends a Foundation Document when the actual resolution says nothing of the sort, and the resolution proposer explicitly rejects this interpretation.[1][2][3] So if I propose a resolution that says, say, No uploads made on Tuesday shall be removed from the archive for violations of the DFSG and then I reject the interpretation that this is a supercession of the DFSG, you're saying that such a resolution only requires a simple majority? You seem to be saying that what is determinative is the resolution proposer's statement. I find this implausible in the extreme. The Secretary is at least an official who we can hope will be neutral; the resolution proposer is, by definition, not neutral. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, 2008-12-31 at 12:01 -0800, Steve Langasek wrote: While I understand the desire to add additional checks and balances in response to figures exercising power in ways we don't approve of, I think the fundamental problem with this latest vote was that the Secretary was asserting a power that was *not* his under the letter of the constitution. Splitting up the constitutional powers doesn't really prevent the Secretary from acting counter to the constitution or counter to project consensus, if they're inclined to do that. When you say he was asserting a power that was not his, what exactly are you saying? I'm having trouble understanding. It is unquestionably the Secretary's job to prepare the ballot and announce the results; this requires the Secretary to determine which options require a 3:1 supermajority. How do you suppose he should go about this task, other than to do his best job? I hope that our next Secretary will recognize the importance of not imposing his personal (and contentious) beliefs on the voting process. If they don't recognize this, then I guess it's inevitable that we amend the constitution to limit the Secretary's power. I am distressed that you have this attitude about Manoj's performance, when it is your own decisions as release manager that have also been called into question recently. Would you apply the same standards to yourself? Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, 2008-12-29 at 23:27 +1000, Anthony Towns wrote: Whatever his motives, I think Ted's demonstrably done more to further the cause of free software than most developers, both by making Linux more and more usable for over 15 years now, and for helping other developers work together better, such as by organising the kernel summit. I'm all for having a 100% free system, and then some, but if it comes down to a choice between supporting absolute freeness without exception, and working with folks like Ted, I'm more interested in the latter. I'm not against working with Ted. I completely second your remarks above. I simply don't think that people should have a vote in Debian if they are not committed to following Debian's foundation documents in their Debian work. I do not know if Ted is such a person or not, but I do know that he doesn't share the goal expressed in the Social Contract; he's said as much. If he's willing to put that aside in his Debian work, then that's sufficient for me, and AFAICT, that's exactly what he does. My concern is that not everyone is like Ted. They may share his views about the Social Contract, but rather than put them aside and abide by it in their Debian work, they just ignore the bits they don't like. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, 2008-12-28 at 09:05 +0100, Andreas Barth wrote: What this voting seems to show is that clearly a majority doesn't want to stop the release of Lenny. What it also shows however is that the mixing up of the other options on this ballot and the way the supermajority requirements were set is problematic, and probably supporters of any other option than 1 (and perhaps also except 6) can claim that they would've won if the majority requirements were set in a way they consider more appropriate. It is problematic? Are you saying that the 2/3 requirement for changes to the foundation documents should not apply if a majority thinks otherwise? Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, 2008-12-29 at 11:54 +1100, Ben Finney wrote: Some members do not agree that the supermajority-required ballot options actually required changes to the foundation documents, which is not a comment on how those people think supermajority requirements should be assigned. I can only conclude that we really do need to see a vote (as proposed earlier) on how the SC and DFSG should affect the Debian project. The outcome of that vote would help me, at least, to understand what the project thinks the relationship is between our actions and the foundation documents. Well, the only way your first paragraph can make sense is if the second is almost right. If people think that the foundation documents can be sidestepped by a mere majority vote, then they think that they simply don't *really* apply, and so a decision not to follow them is not tantamount to an amendment of them. But I disagree that we need a vote. We already have the foundation documents, and they already apply. If people want to amend them into mere suggestions (perhaps the way the Bush administration regarded US law), they are welcome to suggest that vote. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, 2008-12-28 at 20:45 -0500, Theodore Tso wrote: On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: I wonder how many DDs were ashamed to vote the titled Reaffirm the social contract lower than the choices that chose to release. I'm not ashamed at all; I joined before the 1.1 revision to the Debian Social Contract, which I objected to them, and I still object to now. If there was a GR which chainged the Debian Social contract which relaxed the first clause to only include __software__ running on the Host CPU, I would enthusiastically vote for such a measure. Can you please define host CPU for us? Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, 2008-12-29 at 15:02 +1000, Anthony Towns wrote: For example, having non-free in the archive and the BTS (and potentially buildds and elsewhere) is implied by point (3) (ie, supporting Debian users who choose to use non-free software to the best of our ability), and potentially using non-free software ourselves (such as qmail or pgp in the past) may be implied by point (2) (using the best available tools and techniques to do the best job we can). I would personally prefer for the project to have the freedom to decide those sorts of things on a day-to-day basis through regular decision making (maintainers, list debate, DPL, ftpmaster, RM, tech-ctte, simple majority vote), but I don't know if the rest of the project will buy that these days. I'm fairly sure some people won't, at any rate. I would prefer this. But I am afraid of it, and so I would vote against it. I am afraid that there are folks in the project who really don't care if Debian is 100% free--even as a goal. I think that Ted Tso is even one of them. My fear is that if we say, It is a goal that Debian be 100% free, and leave it up to the ordinary process of people doing their work, then people who oppose that goal, who think it is a foolish goal, or an unworthy one, will simply obstruct it. It is this which bothered me about the release team's methodology vis-a-vis this issue this time around. Not that I thought they were deliberately obstructing our goals--I have no reason to think they were doing anything but making a pragmatic decision as best as they could at the time--but because I can't know for sure. And, then when the controversy erupted, there were people expressing views that I *do* think are simply contrary to our goals, lauding the release team for ostensibly obstructing the social contract's absolutism. I wish we could have in the world of GNU/Linux one, just one, please--just one--distribution which really took free software as of cardinal importance. Debian has promised to be that, while living up to the promise only in fits and starts. That's ok with me. But I'm afraid that if we stopped the promise, and simply decided it would be our goal, the folks who are against the promise will be against the goal, and will see this as permission to simply *never* work toward the goal, and to obstruct others who do. Since it's worded as a pledge, it might make sense that if it (or something like it) is ever adopted, that existing developers membership being dependent on them agreeing to the pledge. That didn't happen with the previous SC change, but it seems strange to claim to have a social contract when a significant number of members don't actually support it 100%. In my opinion, developers who are unwilling to abide by the Social Contract in their Debian work should resign. But they don't, and this is what has me afraid. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Thu, 2008-10-23 at 18:13 +0100, Neil McGovern wrote: Perhaps I'm mis-reading the above. Which bit of the foundation documents do you think would need overriding for the tech-ctte to rule on which fix to take? One might think that this is the situation: two alternative fixes for the DFSG problem, and a dispute about which one is better. But actually, that's not the situation. We have instead an easy trivial fix, all but complete. (Really, just disabling the hardware, or the accelerations, depending on the case.) And maintainers saying that this is an unacceptable fix--and no actual alternative fix sitting around. I think everyone would regard the fix preferred by the maintainers as superior--there is no technical dispute. The dispute is *not* between the two fixes. It is between these two approaches: 1) Install easy fix now; install fancy fix when it's ready, thus complying with the DFSG at all times; 2) Install no fix now; install fancy fix when it's ready, thus violating the DFSG in the meanwhile. This is not a dispute about technical means or which is the best solution to a technical problem; it is a dispute about whether we are actually supposed to be doing our best to comply with the DFSG at all times. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 15:22 +, Anthony Towns wrote: Thomas: your continued inaction and unwillingness to code an acceptable solution to this issue, in spite of being aware of the problem since at least 2004 -- over four years ago! -- means we will continue to do releases with non-free software. I am *happy* to code an acceptable solution, but I regard not support the hardware for installation as acceptable. I ask simply that the project's standards be *applied*, or that at the very least, we have a resolution as we did before. And yes, I would likely vote against it, as I did before. But in a democratic system, people generally are well advised to accept the result of past votes gracefully and work towards the next one. That's what I did; my vote did not carry the day last time, and I have not objected about that decision since. But I *do* object to the apparent new rule that the ftpmasters and release engineers are now empowered to ignore DFSG violations without any review by anyone else. And now we have people saying, hey, let's exempt firmware from the DFSG! again, even though we have a GR on topic which decided that, no, firmware counts. Hey, you've had four years; we're just going to keep releasing until you fix the bug. Hint: you're not being held hostage by anyone, seriously. You know how you can tell? Two words: Stockholm syndrome. So I can upload an NMU right now that fixes the problem? That will be ok? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Tue, 2008-10-21 at 20:24 +0200, Pierre Habouzit wrote: On Tue, Oct 21, 2008 at 05:52:28PM +, Manoj Srivastava wrote: This is the part I am not comfortable with. I do not think the delegates have the powers to decide when enough progress has been made to violate a foundation document in our release. Just like an individual developer does not have a right to decide to violate the DFSG in their work, I think the release team, which prepares the release, can do so unilaterally either (I did not vote for Bush). And you're comfortable with ftp-master ruling DFSG-iness through NEW then ? I don't really see the difference. I can't speak for Manoj, but for my own part, I have not seen any evidence that ftp-master is letting things through NEW which are in clear violation of the DFSG, so it doesn't come up. FWIW you can query all the lenny-ignore bugs on the BTS, there arent a lot, and check if you agree. Unlike Bush (and the reference is quite offensive, really) we don't hide such matters, and we never said we're not open to discussion. BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're delegated for that (among other things). So far, the release team has shown no awareness in this thread that ignoring a technical RC bug is entirely different from ignoring a violation of the core documents of the project. Nobody is talking about technical bugs, and it would be helpful if y'all stopped bringing them up. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 21:21 +0200, Frans Pop wrote: Thomas Bushnell BSG wrote: I am *happy* to code an acceptable solution, but I regard not support the hardware for installation as acceptable. I'm very glad that history has shown most developers disagree with you. So I can upload an NMU right now that fixes the problem? No, it's not OK. See [EMAIL PROTECTED] for a good description of an approach that would be welcome. I see. So the previous statement that nobody is standing in the way of a fix is simply not so. People certainly are standing in the way. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 14:59 -0500, William Pitcock wrote: If we waited for a release to be 100% perfect, it will likely take several more years. The good news is that the amount of inline firmware in the kernel is decreasing. So, eventually, all non-DFSG redistributable firmware can belong in firmware-nonfree. Do we have an ironclad commitment to not add any additional non-DFSG firmware, period, no matter what? I would accept a compromise which guaranteed an increasing slope. But not a back-and-forth thing. Your reply focuses on regression issues, so is that really sufficient? We guarantee that, say, there will always be *less* non-DFSG firmware in each release, and we guarantee that there will never be *new* non-DFSG firmware. If the NMU involves removing support for hardware, then no, the NMU's solution would be in my opinion unacceptable, and hopefully enough people agree that it would be rejected. Thought so. So the claim that nobody is standing in the way was simply false. People are standing in the way of a simple fix for a simple bug, and insisting on a more complex fix. I agree completely that the more complex fix is better, but it is simply not true that nobody is standing in the way of a fix. Rather, they have declared that only one sort of fix is tolerable, and mostly refused to discuss the question. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 22:47 +0200, Frans Pop wrote: On Tuesday 21 October 2008, Thomas Bushnell BSG wrote: I see. So the previous statement that nobody is standing in the way of a fix is simply not so. People certainly are standing in the way. That's nonsense. Uncoordinated NMUs are never acceptable for packages that are in general actively maintained (which the kernel is), especially not when it concerns controversial or technically complex changes [1]. Doing so would be a violation of basic NMU policy. The claim was, hey, nobody is stopping anyone from fixing it, if it's not fixed, it's lame for people to complain, they should have fixed it. But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Yes, certainly the team has the right to make such roadblocks if they think it best, in principle. But then that's what's happening: they are standing in the way of implementing a quicker simpler fix. You can either blame people for not uploading their own fix or prohibit them from doing so, but you can't do both at the same time. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 16:00 -0500, William Pitcock wrote: Unfortunately, those who contribute to Debian must be dedicated to ensuring future releases of Debian support the latest available hardware at time of release. No matter what our principles are? Wow. Why are we not equally committed to supporting the latest proprietary codecs? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? I would be entirely happy with that. But I have just been told by William Pitcock that apparently we are required somehow to support new hardware with non-free software too. So it's not a decreasing list, it's an accordion list with no real commitment to the DFSG at all. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Tue, 2008-10-21 at 22:31 +0200, Aurelien Jarno wrote: I knew I haven't quote enough parts of DFSG: 5. Works that do not meet our free software standards We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created contrib and non-free areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian. We encourage CD manufacturers to read the licenses of the packages in these areas and determine if they can distribute the packages on their CDs. Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists). Right. We don't put them in Debian. If the kernel team would do what #5 says, I'd be happy, but so far, they are refusing. And remember: We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. Right. Nothing here says that the needs of our users take priority over the free software community. But it *does* say that releasing in a quick way takes a back seat. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 23:23 +0200, Frans Pop wrote: On Tuesday 21 October 2008, you wrote: But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Ever hear of the Technical Committee? This is a technical dispute? Whether your packages need to comply with the DFSG? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 16:27 -0500, William Pitcock wrote: On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote: On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: Would it be a good compromise between SCs #1, #3 and #4 if we made an exhaustive list of non-free bits in main, and make it our goal that the list gets smaller between each release and not to add anything to that list? I would be entirely happy with that. But I have just been told by William Pitcock that apparently we are required somehow to support new hardware with non-free software too. So it's not a decreasing list, it's an accordion list with no real commitment to the DFSG at all. Do not put words into my mouth. I simply stated that user experience is an important factor, and that if free drivers (*FREE*) which depend on non-free firmware are available, and the firmware is inline, then it should not block Lenny's release. Huh? So you would be willing to agree to a rule that we never add anything new to the list of non-free bits? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 17:06 -0500, William Pitcock wrote: I worded that rather badly. You should imply within acceptable terms of the DFSG here... in this case, putting stuff in the nonfree firmware package in non-free is an acceptable solution. Of course; that's an excellent solution. Right now, the failure to have that solution implemented is being used as an excuse for violating SC#1. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 18:45 -0500, Ean Schuessler wrote: I guess the question is, staying in the arena of 100% Free, what if DRM technologies become pervasive in the United States and Europe and it literally becomes illegal to have a computer without some proprietary software in it? What if it becomes impossible to develop on a computer, legally, without compromising? Would it still be better to have a computer that is 99.9% free? Keep in mind that I'm asking this in the scenario where providing the last 0.01% as Free Software would be illegal. If that happens, we will have to make some difficult choices. But we are nowhere near that now. For example, I vote, as a matter of principle. But if I lived in various extreme situations, I would not vote, for example, if I were in a one-party state with no real elections. And then *that* principle might well be one I would compromise on if the state in question enforced serious criminal penalties on non-voters. And so it goes. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote: Actually, I think we need a GR on the lines of , | http://www.debian.org/vote/2006/vote_007 | General Resolution: Handling source-less firmware in the Linux kernel ` To get a special dispensation for lenny. I think this would be insane. It smacks of the nonsense of the US Congress extending copyright over and over again, always for a limited term, but such that the terms just never actually expire. I object to a second round of this. I was ok with it once, as a compromise, but the understanding I had then was that it was a one-time thing, to give time to actually *fix* the problem. The kernel team should *fix the bug* and not just sit on their hands. We should not release until it's fixed. But the continued dishonesty of holding out one set of principles and guarantees, while granting ourselves exceptions on every release, is not tolerable to me. I do not think that willfully violating the social contract is a decision for a few delegates to make -- we, as a project, should acknowledge the need for and make a special exception to release Debian with known non-free bits in it. We did that once. With the understanding that we wouldn't do it again--or at least, that was my understanding--it was proffered as a special case, a one-time thing, because of the urgency of the case. Moreover, at the time, there was an amendment proposed to make it as long as required and it got fewer votes than the one-time thing. Pretty clearly, we *already decided* this issue, and we need no vote. We need the relevant maintainers to be told your unwillingness to fix this means we will not be able to release. I object very strongly to the feeling that I am being held hostage by developers who will not fix the bug, and then protest emergency! we must release! no delay! we'll do it next time! and then sit on their hands again for another go-round. The solution is to refuse to play along, and to say, hey, you had two years; we're just going to wait until you fix the bug. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, 2008-10-20 at 19:11 +0100, Mark Brown wrote: On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote: I object to a second round of this. I was ok with it once, as a compromise, but the understanding I had then was that it was a one-time thing, to give time to actually *fix* the problem. Note that there is currently active upstream work to allow us to address these issues - some of the patches are present in 2.6.27, others are still in flight. This is a vast step forward on where we were with etch if we do decide to go down the route of releasing with exceptions again. I think we have no need to go down that route. We do not have to support the hardware at all. That is an option. The fact that the kernel maintainers would prefer a fancier thing is not the point. We can simply not ship support for that hardware *at all*. That's perfectly acceptable to me--even as a user of such hardware. A patch to fix the bug--which is the inclusion of non-free things in main--can be quickly and easily implemented. I'm oh-so-sorry if a fancier fix is not available--but there has been plenty of time. I'm not willing to see another release with non-free blobs in the kernel, especially since it is really quite trivial to remove them. We need the relevant maintainers to be told your unwillingness to fix this means we will not be able to release. I don't think that's a particularly constructive approach to take, especially not in a volunteer project. I think that it is singularly non-constructive to see the maintainers of packages regard compliance with our foundational documents as wishlist items, and the release team regard such things as anything other than show-stoppers. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: No, really. The kernel team are volunteers. Ordering them to do things doesn't help at all; one could equally well send the same message to everyone working on Debian (or, indeed, the wider community) since they could also step up to the plate and help fix this issue. Of course. These are RC bugs. I would be happy to upload an NMU that fixed the RC issue by removing support for the relevant hardware, and dropping blobs from the source. I don't think it's a very challenging task, but I'm happy to do so. Will that be ok? If they were actively stopping people working on these issues then that would be different but I have not seen them doing this. Great, so since there won't be any active attempts to stop, I can just go ahead with the work, right? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Sun, 2008-03-16 at 04:29 -0500, Manoj Srivastava wrote: All this replacement in favour of a better person sounds very nasty, mean, and likely to be highly subjective to me, and most organizations do not often throw people out while they are still performing their duties. Of course it's subjective. So what? The question is whether good decisions are made, not whether we can always find clear objective criteria for them. Debian has often been hampered by a refusal to make good subjective decisions, because of the hamstringing character of those who insist on deductive proofs before steps can be taken. My question was specifically about whether you would support an amendment that allowed throwing people out when they were *not* doing their duties. Would you? The creiteria can be more than just voting on issues -- look for number of emails on threads on a issue raised, number of emails sent to the bug report, number of fact finding or research or survey or report mails in that mix. Quite right: that's why I suggested that if someone has failed to vote or contribute twice, they should be replaceable at the option of the DPL. If someone fails to vote that's clear; if someone fails to contribute (you mention a number of relevant factors) it's harder to quantify and so I suggested any two of DPL, Project Secretary, or Tech Ctte Chair could certify that a member had failed to contribute to a decision. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, 2008-03-17 at 00:13 +0100, Andreas Barth wrote: * Thomas Bushnell BSG ([EMAIL PROTECTED]) [080316 21:01]: On Sun, 2008-03-16 at 04:29 -0500, Manoj Srivastava wrote: The creiteria can be more than just voting on issues -- look for number of emails on threads on a issue raised, number of emails sent to the bug report, number of fact finding or research or survey or report mails in that mix. Quite right: that's why I suggested that if someone has failed to vote or contribute twice, they should be replaceable at the option of the DPL. I would prefer if people would fix their release goal / critical bugs instead of preparing complex arguments how to change the tech ctte at places where it is not broken. I see; so there are no members of the technical committee who have failed twice to vote? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, 2008-03-17 at 00:33 +0100, Andreas Barth wrote: I see; so there are no members of the technical committee who have failed twice to vote? I'm not sure how not voting twice in a row makes someone a less important contributor by definition. I see; so what number do you think would be wise? Two was just a starting point; I'm not wedded to that. How many votes or conversations should a member be able to miss before it is clear he or she is not participating reliably enough? What do you think about the three-month suggestion? If that's a bad time limit, what would be a better one? But I would really prefer if you would fix your own packages instead of relaying on our BSPers. I'm not sure how this is relevant to the tech ctte. Can you explain it? Maybe we should have BSPers for the tech-ctte, so that if the committee is too busy in a particular week other people can step in and do that work. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, 2008-03-17 at 00:33 +0100, Andreas Barth wrote: But I would really prefer if you would fix your own packages instead of relaying on our BSPers. Actually, I'm very good about uploading fixes for RC bugs promptly. The bugs I think you are referring to were marked severity important. Perhaps the bugs were tagged incorrectly? I must have missed the change in the release goals to require GCC 4.3 when it came out. If the bug had been tagged serious I would have uploaded the fix as soon as possible. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On RC/RG bugs…
On Mon, 2008-03-17 at 02:46 +0100, Cyril Brulebois wrote: On 17/03/2008, Thomas Bushnell BSG wrote: Actually, I'm very good about uploading fixes for RC bugs promptly. The bugs I think you are referring to were marked severity important. Perhaps the bugs were tagged incorrectly? Severity != tag. And the severity is correct. I thought all RC bugs were supposed to have severity serious or higher. Has that been changed? Sorry, I used the word tagged imprecisely; I meant labelled. I must have missed the change in the release goals to require GCC 4.3 when it came out. If the bug had been tagged serious I would have uploaded the fix as soon as possible. You don't read debian-devel-announce, do you? Of course I do. What I said was that I must have missed the announcement. And what exactly does this have to do with the technical committee? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On RC/RG bugs…
On Mon, 2008-03-17 at 03:12 +0100, Cyril Brulebois wrote: On 17/03/2008, Thomas Bushnell BSG wrote: I thought all RC bugs were supposed to have severity serious or higher. Has that been changed? RC != RG. Ah, well then there is no need to berate me for failing to fix the bug immediately. I'm grateful for those NMUers who helped me out, but there was no particular urgency to the bug. You don't read debian-devel-announce, do you? Of course I do. What I said was that I must have missed the announcement. Then please refer (again) to e.g.: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] As soon as the NMU was uploaded I checked the release goals and verified it myself, thanks. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On RC/RG bugs…
On Mon, 2008-03-17 at 03:12 +0100, Cyril Brulebois wrote: And what exactly does this have to do with the technical committee? No idea. It looks like it all started with [EMAIL PROTECTED], and since you're still wondering about RC/RG bugs, I'm answering these questions. It would be a shame to think that the subject was brought up only to distract attention from the actual topic relevant for debian-vote. I remain sure that this cannot have been Andreas' goal, but what the connect is that he must have had in mind does elude me. Andreas, can you explain the relevance to the tech-ctte discussion? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Sat, 2008-03-15 at 00:41 -0700, Steve Langasek wrote: Oh, and we need a way to deal with the structural problem of questions which get posed to tech-ctte and simply never answered at all. Suppose the tech-ctte fails to answer a question in, oh, three months, the entire membership is removable at the discretion of the DPL? How do you define answering a question? I think we should try to get any question resolved in 3 months, but I don't think replacing the committee when this fails to happen is going to improve anything. The analogy has been made to the judiciary. A panel of judges works on a majority rule basis, as a rule, and issues an order for every case giving its disposition. The Wikipedia arbitrators similarly have a clear and published process, with clear and published statements about the current progress of cases, and give clear and published decisions. That's what I mean. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Thu, 2008-03-13 at 23:46 -0700, Russ Allbery wrote: Anthony Towns [EMAIL PROTECTED] writes: Neither is the argument I'm making. The argument I'm making is that because it's likely there are better ways of doing things than the way we're doing things now (ie, though foo is the way we've always done things, there probably exists some bar that is better than foo), we should look at new ways of doing things in the hopes that we'll find one of them that's better that we can then incorporate into our traditions. One of the amazing things about humans that distinguishes them from, say, lumps of rock is that humans are capable of learning and exploring new ideas and trying new things. Hence, it turns out that a group of people can look at new ways of doing things without changing the people. Unfortunately, it seems to me that currently the project has no way of dealing with people who refuse to look at new ways of doing things. It is true that drop the oldest person is randomish. What we have now is *equally* random; it presumes that the person already on the committee is a better member than anyone else that could be found. I suggest that the best way to have good people on the committee is to have some process by which one person or group of people get to decide that it's time to replace person X with person Y, and not simply wait around for person X to resign. This is, fundamentally, what distinguishes a democracy from an autocracy. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Fri, 2008-03-14 at 11:40 -0500, Manoj Srivastava wrote: I do not presume to be omniscient. But I believe lack of time, which is reflected in lack of contribution to the debate on a topic, and, even worse, lack of participation in the voting effort, is definitely a root cause, and with associated indicators. Would you support a resolution which said that if a tech-ctte member failed to contribute, or failed to vote for, say, any two questions, they would be replaceable at the discretion of the DPL? We would need a way to measure contribution. Perhaps any two of the DPL, tech-ctte chair, and project secretary could declare that a member had failed to contribute. Oh, and we need a way to deal with the structural problem of questions which get posed to tech-ctte and simply never answered at all. Suppose the tech-ctte fails to answer a question in, oh, three months, the entire membership is removable at the discretion of the DPL? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re:%20Re: Debian Maintainers GR Proposal
On Mon, 2007-06-25 at 12:53 +0200, Benjamin BAYART wrote: Le Sun, Jun 24, 2007 at 09:50:37PM -0700, Thomas Bushnell BSG: Yes. So, the right solution if I want to help is: - first I spend a lot of time proving that I'm skilled enough to read crazy licenses in a language that is not mine No, you only have to do this if you want to package software and upload it into the archive without review. If you read back to the DM proposal, it is clearly stated that a DM is not allowed to upload a NEW package. So, the approach is not wanting to packageupload anything but a given package. That doesn't change the question about licensing. No DD can upload a NEW package without independent licensing review; but even an upgrade can involve license changes, and a DD must be competent to evaluate them. Thomas signature.asc Description: This is a digitally signed message part
Re: Re:%20Re: Debian Maintainers GR Proposal
Yes. So, the right solution if I want to help is: - first I spend a lot of time proving that I'm skilled enough to read crazy licenses in a language that is not mine No, you only have to do this if you want to package software and upload it into the archive without review. - then I spend another lot of time proving I'm skilled enough to package complex stuff unrelated to my current skills (say python stuff, which I know nothing about, or trying to have a library not breaking everything in an upgrade) No, you only have to do this if you want to package software and upload it into the archive without review. - then I am granted the right to help fixing the bug I found a few months ago No, you don't have to do that to help fix the bug. To help fix the bug, all you have to do is post a patch on the bug log. If you think the patch is being neglected, ask about it on debian-qa. Thomas signature.asc Description: This is a digitally signed message part
Re: A question to the Debian community ... (Was: Question for Sam Hocevar Gay Nigger Association of America)
On Thu, 2007-05-10 at 15:47 +0100, MJ Ray wrote: Sven Luther [EMAIL PROTECTED] wrote: The DAMs, who did not follow their own procedure [...] I contacted Sven Luther directly with an offer to start a GR to rescind the decision and optionally do some other stuff. I've seen no reply. The offer stands and now the problem resurfaces, I will do something to resolve this one way or the other instead of letting this problem (endless mailing list noise) continue. In the absence of feedback from Sven, I'll just make a guess at what's best. Any objections, comments or advice? I object. Starting more GRs will magnify the problem once more. signature.asc Description: This is a digitally signed message part
Re: Call for votes for GR: Re-affirm support to the Debian Project Leader
Matthias Urlichs [EMAIL PROTECTED] writes: On Sat, 07 Oct 2006 23:53:35 +, Debian Project Secretary wrote: [ ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank [ ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects and [ ] Choice 1: Recall the project leader Okay... now what the hell should happen if these ballots both succeed? We would know that Debian developers are insane. The ballots cannot both succeed unless sufficient people vote to Re-affirm the DPL *and* vote to recall him. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Anthony Towns aj@azure.humbug.org.au writes: I believe that distributing firmware written in chunks of hex is in compliance with the GPL, and repetition of your arguments isn't going to change that belief. Do you really think that the GPL contains an exception for firmware blobs? Or that the GPL doesn't mean what it says when it refers to all source? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Recall the Project Leader
MJ Ray [EMAIL PROTECTED] writes: How is the DPL empowered to take that decision when it is so obviously against some developers' opinions? Are you seriously saying that a minority of developers have a vote power over the actions of the DPL? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Manoj Srivastava [EMAIL PROTECTED] writes: I don't care about just the proposers opinion, I want to ensure that what the proposer is telling me is what the people and the sponsors also agreed to. I suppose we could have a lengthy email exchange, and assume that the sponsors are still paying attention to every mail in the deluge that is -vote; or we can have an up front process that does not depend on a culture of heroes for success. As I said, I have no problem with your new process, which certainly has the virtues of clarity and lack-of-ambiguity. (Or are those just a single virtue? Whatever.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Manoj Srivastava [EMAIL PROTECTED] writes: Seems like I'm damned if I do, and damned if I don't. It seems to me as if what happened was: You thought the preamble was rationale and not part of the resolution proper; but the proposer said no, that was an important part of the resolution proper. What's wrong with the proposer's word winning there? You just modify the draft ballot and say thanks for making it clear, and you can, if you wish and are concerned that shenanigans are afoot, ask the seconders whether they wish to keep their second in force. But, that said, I don't object to a clearer procedure if it's easy enough to follow, and the one you just posted seems reasonably easy to follow. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
Manoj Srivastava [EMAIL PROTECTED] writes: What is an issue is that a sloppy proposal mail may have mislead the sponsors to believe that a preamble was an introductory section, or vice versa. Hard to know unless the proposors and ponsors are clear about their intent. Right, so when you disambiguate (either way), especially if your understanding differs from the proposer, it makes sense to check back with the sponsors. I don't see why that couldn't have been done in this case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I second this proposal. Don Armstrong [EMAIL PROTECTED] writes: Because there appears to be some residual confusion[1][2][3] about what I actually proposed and its content, here is the proposal as it currently stands. The proposal is only the content between BEGIN PROPOSAL and END PROPOSAL. == BEGIN PROPOSAL = The Free Software movement is about enabling users to modify the works that they use on their computer; about giving users the same information that copyright holders and upstream developers have. As such, a critical part of the Free Software movement is the availability of source (that is, the form of the work that a copyright holder or developer would use to actually modify the work) to users. This makes sure that users are not held hostage by the whims (or lack of interest or financial incentive) of upstreams and copyright holders. Different types of works have different forms of source. For some works, the preferred form for modification may not actually be digitally transferable.[1] For others, the form that originally was preferred may have been destroyed at some point in time, and is no longer available to anyone. However, to the greatest extent possible,[2] the availability of source code to users is a critical aspect of having the freedom to modify the software that is running upon ones computer. Recognizing this, the Debian Project: A. Reaffirms that programmatic works distributed in the Debian system (IE, in main) must be 100% Free Software, regardless of whether the work is designed to run on the CPU, a subsidiary processing unit, or by some other form of execution. That is, works must include the form that the copyright holder or upstream developer would actually use for modification. B. Strongly recommends that all non-programmatic works distribute the form that the copyright holder or upstream developer would actually use for modification. Such forms need not be distributed in the orig.tar.gz (unless required by license) but should be made available on upstream websites and/or using Debian project resources. C. Reaffirms its continued support of users whose hardware (or software) requires works which are not freely licensed or whose source is not available by making such works available in non-free and providing project resources to the extent that Debian is capable of doing so. D. Requests that vendors of hardware, even those whose firmware is not loaded by the operating system, provide the prefered form for modification so that purchasers of their hardware can exercise their freedom to modify the functioning of their hardware. 1: Consider film negatives, or magnetic tape in the case of audio recordings. 2: Here it must be emphasized that we refer to technically possible or possible for some party as opposed to legally possible for Debian. We also assume digital distribution, and do not attempt to require the distribution of physical objects. = END PROPOSAL === If necessary, consider this an amendment under A.1.2; seconders, you may object to the changes under A.1.5. (If you decide to re-second this proposal, please only second the part between the === lines.) I've also attached the suggested content for the v.d.o webpages for this option in the interest of completeness. Don Armstrong 1: http://cvs.debian.org/webwml/english/vote/2006/vote_004.wml?root=webwmlr1=1.3r2=1.4 2: http://lists.debian.org/debian-vote/2006/09/msg00228.html 3: http://lists.debian.org/debian-vote/2006/09/msg00235.html -- CNN/Reuters: News reports have filtered out early this morning that US forces have swooped on an Iraqi Primary School and detained 6th Grade teacher Mohammed Al-Hazar. Sources indicate that, when arrested, Al-Hazar was in possession of a ruler, a protractor, a set square and a calculator. US President George W Bush argued that this was clear and overwhelming evidence that Iraq indeed possessed weapons of maths instruction. http://www.donarmstrong.com http://rzlab.ucr.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFFD5l+qMsB9b6fcOoRAhSnAJkBPKEyLoh5FO0kiTr7yuHIiDqTEACggFYa FDNpjfb68ifOFzbZzT161oE= =FSx9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sorry
I want to issue a somewhat blanket apology; I'm trying to get better, but I do so only in fits and starts. In my posts about the controversial etch/drivers/freeness issue, I crossed the line more than once into unhelpful and unreflective posts. I am sorry, and if you were hurt or offended by them, please accept my apology. My convictions are strong and well-rooted, but it is not appropriate to post as much as I have done in reiterating the same things, nor was it ok for me to be flippant and rude in some of my messages. I hope only to be able to do better in the future. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
Steve Langasek [EMAIL PROTECTED] writes: On Fri, Sep 08, 2006 at 12:01:37AM -0700, Thomas Bushnell BSG wrote: One of the people hinting at this has been Steve, who basically said to me recently that for some packages, they would get booted from the release for violating the DFSG, and for other packages, we just wink and nod. Now we have it flat out: Steve thinks perhaps we will simply never bring the kernel packages into compliance with the DFSG. I demand that you retract this slanderous remark. It may be the case that the kernel packages are never brought into compliance with the DFSG *as currently written*, or *as you would like them to be interpreted*, but I would not be spending my time on this discussion if I didn't think it mattered to bring the kernel packages in line with the DFSG. What I meant was simply never bring the kernel packages into compliance with the current DFSG. I apologize for the ambiguity. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
[EMAIL PROTECTED] (Marco d'Itri) writes: On Sep 07, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: The widely accepted custom was to interpret the DFSG this way, yes. This is what matters. What is your evidence of this? My experience of 9 years in Debian, which can be verified by browsing the list archives. I have not been the only one to be upset about the firmware situation every time it has been brought up, as can be verified by browsing the list archives. I can see that the controversy is old, but certainly not that your interpretation was widely accepted. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
Anthony Towns [EMAIL PROTECTED] writes: On Wed, Sep 06, 2006 at 10:21:18AM -0700, Thomas Bushnell BSG wrote: We could have met those expectations of the d-i and kernel teams had taken the issue seriously before now. Their failure to do so does not translate to an emergency on my or Debian's part. The failure to do this is no more the responsibility of the d-i or kernel teams than it is yours or mine. They are volunteers, just as you or I are, and they have no more responsibility to work on anything they choose not to do so, than you are personally responsible for ensuring Debian meets its commitment of providing a non-free area in its archive and supporting users who need the software there. I agree completely. So does this work for me too? Can I go and stash non-free stuff in my packages, and if others complain, simply raise a stink and insist that nobody has the right to order me to remove it? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
Josselin Mouette [EMAIL PROTECTED] writes: Le mardi 05 septembre 2006 à 19:07 -0700, Thomas Bushnell BSG a écrit : For me the key question is whether the d-i team is actually doing the work or not. Are they? If the answer is yes, then I might vote for a delay. If the answer is no, then I see no reason that a delay will change things. As Joey's analysis shows, this would lead to a delay of at least 6 months. Given that we're already frozen, I don't think this is something we can afford if we want etch to be consistent. My question is this: If we make the exception, will the d-i team start the work, or instead, will we simply be here again in eighteen months? Thomas
Re: Firmware Social Contract: GR proposal
Marco d'Itri [EMAIL PROTECTED] writes: As usual you forget that we also have that other commitment to our users, and that we used to pride ourselves in providing the best free OS. There is an absolute ranking in Debian, that *first* we must provide 100% free software, and *second* we do whatever we can to help our users consistent with the first. Suggesting the reverse would be a massive change of course for Debian as a whole. thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
Anthony Towns aj@azure.humbug.org.au writes: As best I can see, our users expect us to release etch soon rather than either of the approaches to fixing that that have been mooted so far (drop drivers or delay etch), and I don't believe we can fairly say we're putting the needs of our users (or free software) first if we don't meet those expectations. We could have met those expectations of the d-i and kernel teams had taken the issue seriously before now. Their failure to do so does not translate to an emergency on my or Debian's part. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
[EMAIL PROTECTED] (Marco d'Itri) writes: On Sep 06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: No, it's a contentious issue because some people are trying hard to change the values of Debian replacing what was a compromise widely accepted by everybody in Debian and most people outside Debian with mindlessly following their idea of the DFSG. I'm sorry, when did Debian accept that compromise? When the DFSG was created. Oh, come on. The DFSG says that firmware counts as free? Where? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
[EMAIL PROTECTED] (Marco d'Itri) writes: The widely accepted custom was to interpret the DFSG this way, yes. This is what matters. What is your evidence of this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Russ Allbery [EMAIL PROTECTED] writes: Not for some reason, for some very obvious reasons. They're not adequate as an immediate solution to this problem because separating the firmware from the packages that currently contain it is hard and needs development and because d-i currently can't (as I understand these threads) cope with that split. Right. And the problem is that the d-i team seems to say to themselves, as long as we never do the work, we can badger the rest of Debian into sacrificing the Project's principles, and the work will never be necessary. The solution requires a little stick to go with the carrot: I'm sorry, but the fact that you dithered for eighteen months does not mean the Project must now sacrifice its principles so that you can dither some more. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Marco d'Itri [EMAIL PROTECTED] writes: No, it's a contentious issue because some people are trying hard to change the values of Debian replacing what was a compromise widely accepted by everybody in Debian and most people outside Debian with mindlessly following their idea of the DFSG. I'm sorry, when did Debian accept that compromise? I must have missed the GR. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
Anthony Towns aj@azure.humbug.org.au writes: We'll fail to meet it for firmware and logos in etch, including our own logo, and to the best of my knowledge, we're yet to consider addressing the license of documents like the Debian Manifesto, or the Debian Constitution. What? Are you declaring now that we will release etch in violation of the Social Contract? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
Josselin Mouette [EMAIL PROTECTED] writes: Following the social contract change, we have been able to remove most of non-free stuff from the distribution, especially documentation. It wasn't easy and we couldn't make it in time for sarge, but we can make it in time for etch. For etch, we have the remaining firmware issue. And just because we can't meet our expectations for firmwares, we should abandon them all? For me the key question is whether the d-i team is actually doing the work or not. Are they? If the answer is yes, then I might vote for a delay. If the answer is no, then I see no reason that a delay will change things. First, it is a fact that we are going to release etch with non-free firmwares. There is no decision to make here, it is too late. Those polls are only a means to legitimate this fact in a political way, by making it looking as a decision. Really? I'm flabbergasted. So I can just put whatever nonfree code I want into a package, and boom, it gets into etch? Because our principles do not control our actions? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
Anthony Towns aj@azure.humbug.org.au writes: No. Ceasing to make commitments we can't keep doesn't mean we should stop meeting the commitments we can. Which is why the bullet points you didn't quote were in the proposal. What do you mean that we can't keep the commitment to make the kernel free software? We just stop shipping the relevant drivers. It's *trivial*. If we wanted to keep our commitment, we could do so. Very easily. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Russ Allbery [EMAIL PROTECTED] writes: Point 2.1.1 of the Debian Constitution is relevant here. Under the Debian Constitution, you have no grounds for expecting the d-i team to work on this on your preferred time scale. If you want to get work done that other people have not completed as fast as you would like, I suggest investigating how you can do that work yourself. I am entirely happy for the d-i team to never do the work. But that does not mean that the kernel team should therefore be allowed to go ahead and ship non-free programs in their packages. And I am entirely happy to do the work to make the kernel packages free, but I have the feeling that this isn't what's desired. Point 2.1.1 does not mean that a developer can say nyaa nyaa nyaa, i'm shipping nonfree code and you can't stop me, because you can't order me to remove it, because of point 2.1.1. I see the task as make Debian conform to the Social Contract. I see there are two ways to accomplish this task: 1) Make the installer able to load the firmware from somewhere other than the normal packages, and split the firmware out accordingly, or 2) Drop the relevant drivers from the kernel packages. I would prefer option (1), but I am content with option (2). I regard the following pseudo-option as unacceptible: PO) Release in intentional violation of the Social Contract. If option (1) is too hard to do for the release, then option (2) must be chosen by default, and yes, I am happy to do the work for option (2) if that's necessary. But my unwillingness to do the work for option (1) does not somehow mean that (PO) must be chosen. Well, if our principles mean much at all, that is. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Sven Luther [EMAIL PROTECTED] writes: It seems to me that this GR is unacceptable in this form because it does not give an adequate definition of firmware, and people seem to mean many different things by it. Well, in this case, firmware is clearly the firmware blobs actually into the kernel without sources. This GR speaks only about the linux kernel, and is not really generic like Steve's, and clearly mentions earlier the firmware as being either program or register dumps. So how do I know whether something is firmware instead of just ordinary sourceless code? Or is this supposed to be a blanket exemption for any non-source code in the kernel, of whatever sort? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Raphael Hertzog [EMAIL PROTECTED] writes: So I don't think it's a 3:1 issue. We're not changing our goals, only clarifying the timeline and acknowledging that the etch timeframe is too short for us to reach this goal. I don't believe it. We already clarified the timeline, and created a perfectly clear exception for sarge. We have a precedent that making such exceptions requires a 3:1 vote, as well. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Sven Luther [EMAIL PROTECTED] writes: So how do I know whether something is firmware instead of just ordinary sourceless code? Ah, well, i would say that the definition you search here are : hexdump sourceless blobs which are uploaded to a peripheral device. So you would say that it is logically impossible to have source for firmware? Comon sense and good faith should do just fine, but the above, hinted at in the overview, should help out, no ? No, it doesn't. You've now given *another* definition of firmware, different from all the previous ones, and problematic in its own special way. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Sven Luther [EMAIL PROTECTED] writes: No. The sourceless firmware blobs mentioned in this GR, are identified as those programs or register dumps or fpga config files, which are uploaded to a peripheral processor, and are part of a linux kernel driver in some way, usually an array of chars or some other binary embedded in a variable kind of things. We could also here include the main processor micro-code, since altough it runs on the same processor, it is not running in the same layer of the processor as the one running normal code. Ah, another definition. It's clear from your we could also here that you aren't sure whether certain things should count as firmware or not. Do you see now why I might want some specificity before we have a vote? Since it's you who wants this GR, may I suggest that you'll need to figure out just what you want the GR to say? I can't tell you what you want your own proposal to say. Does this satisfy you as a definition ? It is a little closer to a resolution that could even be plausibly voted on. (It certainly doesn't satisfy me if you mean that I would vote for it.) What satisfies me is simply compliance with our existing standards. But that discussion should happen after the secretary announces a discussion period. Right now I'm concerned that we don't get disastrously vague resolutions into voting. If the above is enough, maybe we could add this or a nicer rewording of it to the GR ? The above includes things like maybe we could include and usually and the like. It may be a step closer, but it isn't there until you decide what you actually want. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Sven Luther [EMAIL PROTECTED] writes: Nope, i am not sure we have such microcode in the kernel tree. It certainly fits the same category as the rest of the stuff, and i think the above identifies perfectly which firmware blobs we are speakign about. Huh? Microcode for the main processor doesn't fit anything like the rest of the stuff. The rest of the stuff you described as: 1) Programs or register dumps or fpga config files 2) Which are uploaded to a peripheral processor 3) And are part of a linux kernel driver. Now of course that's not a definition of firmware; it's just a definition of what you want to grant a Social Contract exception to. Microcode for the main processor does not match (2) or (3). So no, there is no obvious likeness between microcode for the main processor and the rest of the stuff. Use the above as guidelines to classify any such blobs you find, it is decidable enough, so i think there is no doubt on this. I can already see that if we had used your definition, and main processor microcode turned out to be present in Linux, you would start insisting that it meets your definition, and I would insist that it does not. Claiming there is no doubt is hardly likely then. Bah. Remember, common sense and good faith :) We have now at least *eight* different definitions that have been bandied about. Good faith maybe, but common sense is that you people are not yet really sure *what* you are talking about, and I tend to agree. Maybe we could clarify this one a bit, but i think it is pretty clear what is involved here, and in particular it doesn't suffer from the firmware-are-not-programs syndrom, and thus description is less important. It isn't the least bit clear to me. The fact that a request for clarity has been met by vague we all know what we are talking about and now eight inconsistent definitions suggest that it isn't clear to anyone what it is really about. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware proposals
Jacob Hallen [EMAIL PROTECTED] writes: My personal experience is that the larger the company, the smaller the interest in change will be and they will only change when outside pressure forces them to. This leads me to believe that the quickest way to a future where we can distribute free firmware is by getting many users and that is best accomplished by for the time being erring on the lax side - considering unknown firmware to be data. The DFSG requires the full source for *all* such things, without reference to whether they are programs or data. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Sven Luther [EMAIL PROTECTED] writes: Microcode for the main processor does not match (2) or (3). So no, there is no obvious likeness between microcode for the main processor and the rest of the stuff. Microcode does run in a lower level of the cpu than the main code, as thus you could see it as a program (actually a set of small programs probably), which are uploaded to the main cpu in order to make it work as expected. Of course it's a program uploaded to the main cpu to work as expected. Do you think that this definition fits your description as being on a peripheral processor and part of a device driver?? Are you now saying that anything uploaded to the main cpu should be excluded from the DFSG? Wow. So, please come up with an actual case of the above definition not being enough for classification, and once you find something such, we will adapt the definition to clarify its classification. Debian will remain 100% Free Software is the classification I like. I am of the opinion that there *is no* principled classification beyond this one which is anything other than we don't really want 100% Free Software. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Frederik Schueler [EMAIL PROTECTED] writes: 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, without further conditions. It seems to me that this GR is unacceptable in this form because it does not give an adequate definition of firmware, and people seem to mean many different things by it. Further, because this amounts to a decision to disregard the SC, it should require a 3:1 majority. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment
David Nusinow [EMAIL PROTECTED] writes: On Wed, Aug 30, 2006 at 10:41:00PM -0700, Thomas Bushnell BSG wrote: David Nusinow [EMAIL PROTECTED] writes: Would you, or someone else, mind pointing out some examples of firmware with source? Preferrably with some of the breadth you refer to above? I understand firmware in concept, but beyond seeing it as a binary blob I've not really come seriously in to contact with it. If I'm going to vote on this issue, I'd really like to actually understand what I'm going to be voting on. I think it's widely in agreement that hardware manufacturers have assemblers and other tools they use for building firmware. So we don't have any firmware with source? I have no idea. I have heard people in this discussion *define* firmware in terms of the absence of source. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] writes: If it's the latter, I maintain that this is precisely the subject matter of the proposed GR; we obviously *don't* have agreement in Debian over what should or should not be considered a program, so I think that's begging the question. However, your proposed amendment declares that firmware should not be considered a program. Can you please tell me what firmware is? I've seen a half dozen definitions tossed around recently, and I haven't a fig of a clue which one you mean: 1) A program which runs on a peripheral processor 2) A program which is distributed by the hardware manufacturer 3) A program which is controlled by the hardware manufacturer 4) A program which runs out of NVRAM or ROM instead of RAM 5) A program which, if you change it, voids the warranty for the hardware on which it runs, 6) A program which is necessary to support a piece of device hardware and for which we don't happen to have source I can't properly evaluate or think about this amendment while this rather crucial element remains unresolved. Also, it would seem very bizarre to say a program which ... is not really a program, so can you find a wording in which you don't define firmware as a particular sort of program, only to then declare that programs of that sort aren't really programs at all? Yes, these are reasonable definitions of both program and firmware. What is the definition of firmware which you are using? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
I think it is ludicrous to pretend that firmware is not a program. Suppose we had in our possession the source code and an assembler for it. Surely then it would be obviously a program. thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] writes: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I am bothered that there is never a definition of firmware here. It seems to me that if you gave one, it would be something like: firmware is a program which runs on a secondary CPU inside the computer. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] writes: As you and I discussed previously on IRC, I don't agree with this amendment. The premise of my proposal is that we are *not* granting an exception nor redefining any terms, we are merely recognizing a latent definition of programs that has guided Debian since its inception in spite of standing in contrast to the dictionary definition of the word. In other words, Debian has been redefining the word from day one, dishonestly using the word program to mean something much narrower. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: Notice that the bios or other firmware used on most machines today is also refered as firmware. The original definition is, i believe, any kind of code provided by the vendor of said device, and on which he has full control, so firmware was non-free by definition originally. How does the vendor of a device have full control over what firmware I choose to load into it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: In cases like hte NLSU thingy, the firmware goes to include the whole linux + userland stack on top of whatever they use for booting, since it is held in the flash of the board. Wow. I thought that doesn't run on the main CPU was entirely indefensible. It hadn't occurred to me that there is a definition which is even *worse*: runs out of NVRAM instead of DRAM. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: The idea is that the firmware is all the software and other softwarish information which the vendor provides to make use of the board he sells you. I see. If I buy a standard-issue Dell computer, then Windows is firmware, right? (Dell does provide it, for the purpose of making full use of the computer.) He has full control of it, in the sense that it is often binary only, and that he produces it, and not some third party (like the operating system vendor). Also, i believe that modifying the firmware, like you propose, usually voids the waranty. Oh, so because the OEM can't modify Windows it's not firmware. But if I buy a Dell PC that comes with Red Hat installed, it *is* something Dell can modify, so then it is firmware? all software support part that comes from the hardware vendor, to enable or drive or whatever the hardware he sells you, and which is not part of the operating system. Um, this is not a definition. The whole point of a definition is to describe what is firmware and what is the operating system. When I suggest that there is no good principled definition, you can't counter by definining firmware as essentially whatever is not part of the operating system. Pretend I don't have any idea what this word firmware is or operating system. I'm familiar with programming and all that, just not with these words. Can you explain the distinction in a noncircular way? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal - Restricted-media amendments to the DFSG
Josselin Mouette [EMAIL PROTECTED] writes: At the end of DFSG #2, the following text should be added: The license may restrict distribution to some kinds of media if it is still possible to distribute the source code and compiled code together on at least one machine-readable medium. I'm made uncomfortable by this, because it would tolerate licenses which restricted distribution to cassette tape. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal - Restricted-media amendments to the DFSG
Josselin Mouette [EMAIL PROTECTED] writes: Le jeudi 06 avril 2006 à 09:50 -0700, Thomas Bushnell BSG a écrit : Josselin Mouette [EMAIL PROTECTED] writes: At the end of DFSG #2, the following text should be added: The license may restrict distribution to some kinds of media if it is still possible to distribute the source code and compiled code together on at least one machine-readable medium. I'm made uncomfortable by this, because it would tolerate licenses which restricted distribution to cassette tape. How does it differ from the GFDL requirements? The GFDL says you must provide a machine-readable copy. It does not restrict the use of other media. Perhaps it is just your sloppiness in wording, but the words you wrote allow a license which says you may only distribute this on cassette. The GFDL *permits* distribution on cassette, and even treats it as machine-readable, but it does *not* require distribution on cassette. It allows the distributor to choose their choice of machine-readable format, and that's suitable for Debian. Your wording would permit licenses which do *not* allow the distributor to choose their choice of machine-readable format. Thomas
Re: Question to all candidates: What to change?
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Sat, Mar 11, 2006 at 01:20:19PM +, Neil McGovern wrote: If you were elected tomorrow as DPL, and could only pick one thing about Debian to change, what would it be? Make our mailinglists an enjoyable place for technical discussions. What concrete steps would you undertake to make this a reality? How would being DPL enable you to do this better? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Question to Candidates
James Troup [EMAIL PROTECTED] writes: But I never personally replied to Joey's mail about the next point release explicitly saying that fixing sudo was a pre-depends, and I apologise for that. You're not a DPL candidate, and if this question is relevant at all, it's relevant to DPL candidates. So don't think it's a personal question, though I would appreciate hearing your thoughts on the matter also. Especially however, I want to hear what the candidates think. I would appreciate the work done by others in Debian more if there were some kind of rule, principle, or guideline that if a question is not given a serious and thoughtful response, allowing for delays and vacations and whatnot, that any debian developer has the right to go ahead and do something themselves. We already have this rule in the case of NMUs to fix release critical bugs. We also have a procedure for replacing developers who go totally MIA, and an informal procedure for hijacking packages from vaguely-MIA maintainers. But I feel frustrated when I ask a developer a question, and hear nothing back for ages and ages. (And I admit that there have been times when I have myself been guilty of this same problem.) However, if there is an RC bug in a package, and the maintainer has not responded, eventually it's allowed for me to just NMU the package myself. How about extending this to other areas of the project? One difficulty, of course, is that NMUs are massively documented, and fairly easily reversed. Other changes are not so, which may make this too hard, in practice, to accomplish. What about a related idea, in which everyone has some sort of obligation to respond to emails? I appreciate James' apology above for not responding to a message from Joey (or whatever the details are; it's not something that particularly concerns *me* in this case). I have experienced that an email to debian-release nearly always gets a response. I appreciate this, and it means that I can make progress, or at least feel like I can. When I have a release-relevant question, I get an answer, even if I write an over-hasty question, or whatnot. Moreover, since it's a public mailing list, it doesn't matter if the official release managers are overloaded: generally there is someone else who can answer if they don't. And if a question is missed or overlooked, it's fine to repeat it and ask again. What about some sort of general expectation that other developers do the same thing? I would find interactions with ftpmaster more, hrm, comfortable? pleasant? if I could rely on getting some kind of response back. However, when I mail ftpmaster, my recollection is that most of the time the work implied by my question happens, or there is a good reason for it not to, but I almost never have any interaction with the person who did it (except in the case of NEW queue processing, where I do hear back). That's only one example, but perhaps there are others. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Who would you expel from Debian?
Ted Walther [EMAIL PROTECTED] writes: I think the other DPL candidates, especially Steve McIntyre who has been pussy-footing around this issue, should stand forward and say clearly where they stand on the issue of expelling developers; what is a just case for expulsion? Be really clear and specific. Give concrete examples. I think you get to demand answers from other DPL candidates only when you have been forthcoming with the questions asked of you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question to all candidates: What to change?
Anthony Towns aj@azure.humbug.org.au writes: If I could pick /anything/, it'd be to make Debian suddenly 100% fun for everyone involved. Yeah, I'm with you! Can you outline perhaps some of the things you think that keep it from being 100% fun, and what the DPL can do to help them? I'm interested here both in answers of the form when people do X that's not fun for others which show perceptiveness of reality, and also some which show perceptiveness of the unfunness complaints that we hear, whether you think they're well-founded or not. Oh, and all candidates should feel free to reply. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question to all candidates: What to change?
Anthony Towns aj@azure.humbug.org.au writes: If I can only pick the things that're directly achievable, I'll just go with getting the momentum back -- ie, doing cool things quickly and regularly, no matter what they are. What are some of the organizational or institutional factors which you think keep us from doing these? How can the DPL help them? And other candidates should feel free to reply. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
Craig Sanders [EMAIL PROTECTED] writes: the GPL says you must include the full machine-readable/editable source code, so if you can't do that in a given medium (say, a chip with 1KB capacity) then GPL software is not free in any medium. Of course, but that isn't an imposition on changes. If a GPL'd program comes with a bunch of Japanese text, then I could always remove that text if I must transmit the program on ASCII. I might have a weaker less useful program, but I can at least do something. I might also translate the Japanese into English and distribute that instead. I have many options. By contrast, if there is an invariant section written in Japanese, I cannot remove it, I cannot distribute a translation instead, I must instead simply not transmit the document *at all* if I am stuck with an ASCII-only medium. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
Craig Sanders [EMAIL PROTECTED] writes: why are you obsessing with a convenience issue and pretending that it has ANY BEARING AT ALL on freedom issues? it doesn't. I think if you'll look at the header you'll see that this is about a new practical problem. If you aren't interested in the practical problems, then you don't need to worry about them. Those of us who are interested in them should be able to discuss them, right? We have also been told by some that the DFSG should be interpreted only to require permission to make useful modifications. If that is correct, then it immediately becomes relevant whether a given modification is useful, and whether that modification is prohibited. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
Craig Sanders [EMAIL PROTECTED] writes: bullshit. freedom, as used by Debian, is explicitly defined in the DFSG. the DFSG has a number of clauses detailing what we consider free and what we don't consider free. convenience is NOT one of those clauses, and never was. in fact, convenience is implicitly discarded as a criteria by the existence of the patch clause, which explicitly states that the major inconvenience of modification-by-patch-only is free. Modifiability *is* one of those clauses, and a rule that says you cannot modify this essay is in violation of that clause. The *reason* why some care about this clause is for reasons to do with convenience, practicality, or expense, or perhaps other things. It is Anton's apparent conviction that the DFSG only demands modifiability when it is necessary for convenience's or practicality's sake. This is not *my* view. But it is interesting that *even* if we adopt Anton's view, in which suddenly convenience and practicality matter, we can think of reasons why the modifications in question would be useful. But let there be no mistake. My view (and, I think, Manoj's view), is that the freedom to modify a manual by removing invariant sections is one of the freedom's protected by the DFSG, and it is so whether it is practically important to be able to do so or not. Use of the word bullshit constitutes a violation of the policy for this mailing list. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Curious Case Of The Mountainous Molehill
Craig Sanders [EMAIL PROTECTED] writes: On Mon, Feb 13, 2006 at 01:42:44PM -0700, Hubert Chan wrote: 3a only says that a binary has to be *accompanied* with the source code. Hence it can be on a separate medium. So you can distribute your 1KB chip, stapled to a CD-ROM that contains the source, and still comply with the terms of the GPL. you can do the same with GFDL documents. e.g. the stupid coffee cup example so popular with you zealots - if you can't fit the invariant sections on the cup itself, then print it on paper and include it in the box. problem solved. Of course you can distribute it. What you cannot do is *modify* it in a particular way (or rather, any way at all). The DFSG requires the right to *modify*. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
Craig Sanders [EMAIL PROTECTED] writes: once again: you *can* modify an invariant section by patching it. the GFDL does not say you can not modify at all, it says you can not delete or change these small secondary sections, but you can add your own comments to them. A patched version of the manual, which omits the invariant section, cannot be distributed. no, you can not steal credit for someone else's work, or gag someone by removing their words, nor can you put your own words in their mouth. you do have the freedom to add your own words commenting on theirs. i.e. modification-by-patch is allowed. This is true, but it is irrelevant. The DFSG does not only say that I can add my words to the original; it requires that the license preserve my ability to modify it. Of course, the license can require attributions of credit and notice that a change was made; the GPL requires these and causes no problem. for a document, that is more than adequate. hell, it's good enough for actual software according to the DFSG. It doesn't matter whether it's adequate in your opinion; the DFSG demands modifiability. oh, and once again (because i *KNOW* you'll try to obfuscate the crucial fact about invariant sections, you do it every time the argument gets to this point) - AN INVARIANT SECTION CAN *ONLY* BE A SECONDARY SECTION. That's certainly true; nobody has challenged that. However, the DFSG does not just say that the primary parts of the work need to be modifiable; it says that the whole thing must be. Use of the word bullshit constitutes a violation of the policy for this mailing list. your offensive presence is a violation of policy, but hey - i'll let that slide. Whether my presence is a violation of policy is irrelevant to the question of your use of the word bullshit. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
Craig Sanders [EMAIL PROTECTED] writes: don't be an idiot. you only have to keep the invariant sections if you are DISTRIBUTING a copy. you can do whatever you want with your own copy. Right, so you can't *distribute* a copy on an ASCII-only medium, even of the English translation of a Japanese manual, if the Japanese version... Oh, never mind. Craig is not listening, he's just vomiting words out his mouth. Sorry. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
Craig Sanders [EMAIL PROTECTED] writes: there's nothing in the GFDL that prevents you from doing that. the capabilities of your medium are beyond the ability of the GFDL (or any license) to control. This is hardly true. The GFDL says you must transmit the original Japanese text in the case in question, and so if you cannot do so in a given medium, then you cannot use that medium to transmit the text. no, it's lying arseholes like you who aren't listening. like every other argument against the GFDL and every other alleged proof that the GFDL is non-free, this is a mere CONVENIENCE ISSUE, not a FREEDOM ISSUE. the DFSG does not require convenience, it only requires freedom. Ah, once Craig insisted to me that he would never ever read my email messages. Either that was a lie, or heeys'changed his mind. Regardless, more's the pity. I hope that Craig, if he reads this, will not read any more of them. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Nick Phillips [EMAIL PROTECTED] writes: Certainly looks like you think that there is some absolute way to determine that the license is not DFSG-compliant to me. If there isn't, then the if in the first part of your sentence is never satisfied, and the rest is completely hypothetical. Wrong. Stating a hypothetical does not imply that I have some absolute way to determine whether the antecedent is satisfied. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
Anton Zinoviev [EMAIL PROTECTED] writes: On Fri, Feb 10, 2006 at 02:30:43PM -0800, Thomas Bushnell BSG wrote: Anton Zinoviev [EMAIL PROTECTED] writes: On Fri, Feb 10, 2006 at 11:55:11AM -0800, Thomas Bushnell BSG wrote: But that isn't my point. My point is that you can't include the GFDL'd material in any free program. (Or, by doing so, you render the program non-free.) This is not controversial; even the FSF agrees. This won't be true if you use dual licensing. I showed one way to achieve this in http://lists.debian.org/debian-vote/2006/02/msg00472.html However, the resulting program is *not* a free program! I cannot include GFDL'd text in a BSD-licensed program without *changing the license to require the GFDL's terms*. I suppose we are talking about different things. Notice that the procedure I proposed places all pieces taken from the manual inside comments. The binary of GDB doesn't depend on the comments and thats why you can choose the BSD license for it. I'm talking about *doc strings*. Doc strings do not live inside the comments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
Anton Zinoviev [EMAIL PROTECTED] writes: If you want your binary to use pieces from the manual for help strings, then your binary has to read these pieces from auxiliary file which would be (speaking in the terms of GFDL) an opaque copy and would be covered under GFDL. Likely not. In all likelihood the result would be a single combined work. Technical obfuscations do not defeat copyright law or software licenses. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
