Re: Proposal: The DFSG do not require source code for data, including firmware
[Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. signature.asc Description: Digital signature
Re: Hardware
On Mon, Aug 21, 2006 at 07:47:47PM +0200, Florian Weimer wrote: * Pat Tadgerson: I am not a real hardware person, but I would like a server with 2 hard drives with about 160 gigs of storage, with a raid 0 configuration. RAID 0 is usually a very bad idea because you lose all your data if just one disk fails. Isn't that why people have invented backups and S.M.A.R.T.? It also actually makes disk access go slightly faster, so it's not really a *very* bad idea -- depending on context. -- Lo-lan-do Home is where you have to was the dishes. -- #debian-devel, Freenode, 2004-09-22 -- 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
On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Working out whether those expectations match those of the developers as a whole is what this GR -- and the discussion preceeding it -- is about. I'd strongly discourage people who participate in the discussion (whether you've run the n-m gauntlet or not) from dismissing developers' concerns about this as a red herring: if you're right, you shouldn't be afraid to discuss the reasons why you're right in detail when asked. Cheers, aj signature.asc Description: Digital signature
Live image: strategic for Debian or not?
I'd be glad to have your opinion about the two following related issues: 1) According to the documentation [1]: There are no official Debian live CDs available. However, we would like to recommend Knoppix, which is based on Debian - a very useful, full-featured live CD! Now, I love Knoppix and I think it's the best derivative, but I also think it's not pure Debian, nor is Debian-Knoppix (see point 2). Nevertheless, if either Knoppix or whichever other project is recommended, wouldnt it be nice to offer it as an official download, branded as Defiant Live image? I think that having an official live image would improve the project's visibility and acceptance. 2) As a user, I struggle to keep up with the more or less official projects aimed at building a Debian-compliant live cd, such as: - Linux Live [2], - Debian Live Initiative [3] - Debian-knoppix [4] - Debian from Scratch [5] - mklivecd [6] - knoppify [7] and possibly others. Never mind if I was a developer. All of them are in their own singularity valid projects, but they tend to go their own way and eventually some stall. Wouldn't the project benefit from getting the developers involved in the above mentioned projects to talk to each other and eventually produce a Debian live image? Thank you [1]http://www.debian.org/CD/faq/#live-cd [2]http://linux-live.org [3]http://debian-live.alioth.debian.org/ [4]http://debian-knoppix.alioth.debian.org/ [5]http://people.debian.org/~jgoerzen/dfs/html/intro.html [6]http://mklivecd.sourceforge.net/ [7]http://debian.tu-bs.de/knoppix/debian/knoppify/ Ottavio Caruso -- No individual replies, please! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Live image: strategic for Debian or not?
--- Ottavio Caruso [EMAIL PROTECTED] wrote: it as an official download, branded as Defiant Live image? Obviously I meant: Debian live image. Blame the Yahoo spellchecker! Ottavio Caruso -- No individual replies, please! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Working out whether those expectations match those of the developers as a whole is what this GR -- and the discussion preceeding it -- is about. I'd strongly discourage people who participate in the discussion (whether you've run the n-m gauntlet or not) from dismissing developers' concerns about this as a red herring: if you're right, you shouldn't be afraid to discuss the reasons why you're right in detail when asked. This is a commonly held believe, that many DDs have already used in the past, and seems quite common sense to me : - a firmware hold in a rom or flash is in no way different that a firmware hold in a driver binary, as far as DFSG and freeness goes, both are usually non-free. - debian doesn't ship hardware, so the DFSG can hardly apply to some random piece of hardware that the user may have, as it could not apply to let's say a copy of the microsoft-office program a user or DD may have on the same harddisk he installs debian on. To add to that, if i where Peter, i may feel slightly offended by the tone of your reply as well as the content of it. You are the DPL, and as thus speak with the authority given by the whole project, and i think you should as such be a more careful in your wording. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional Amendment GR: Handling assets for the project
2nd'd, also with Don's amendments. Note that the 'in consultation' bit is still in - it could be still clearer that the DPL may on his own take the decisions. But it's improved over the prev. version. cheers -- vbi On Tuesday 22 August 2006 18:46, Manoj Srivastava wrote: 4. The Developers by way of General Resolution or election 4.1. Powers Together, the Developers may: - 3. Override any decision by the Project Leader or a Delegate. - 4. Override any decision by the Technical Committee, provided they - agree with a 2:1 majority. - 6. Together with the Project Leader and SPI, make decisions about - property held in trust for purposes related to Debian. (See §9.1.) 4. The Developers by way of General Resolution or election 4.1. Powers Together, the Developers may: + 3. Make or override any decision authorised by the powers of the Project + Leader or a Delegate. + 4. Make or override any decision authorised by the powers of the Technical + Committee, provided they agree with a 2:1 majority. + 6. Make decisions about property held in trust for purposes + related to Debian. (See §9.). + 7. In case of a disagreement between the project leader and in + the incumbent secretary, appoint a new secretary. - 5. Project Leader 5.1. Powers The Project Leader may: - 10. Together with SPI, make decisions affecting property held in trust - for purposes related to Debian. (See §9.) = == 5. Project Leader 5.1. Powers The Project Leader may: + 10. In consultation with the developers, make decisions affecting + property held in trust for purposes related to Debian. (See + §9.). Such decisions are announced on an electronic mailing + list designated by the Project Leader or their Delegate(s), + which is accessible to all developers. Major expenditures + should be proposed and debated on the mailing list before + funds are disbursed. + 11. Add or remove organizations from the list of trusted + organizations (see §9.3) that are authorized to accept and + hold assets for Debian. The evaluation and discussion leading + up to such a decision occurs on an electronic mailing list + designated by the Project Leader or their Delegate(s), on + which any developer may post. There is a minimum discussion + period of twoo weeks before an organization may be added to + the list of trusted organizations. - -- - -- 7. The Project Secretary 7.2. Appointment If the Project Leader and the current Project Secretary cannot agree - on a new appointment they must ask the board of SPI (see §9.1.) to - appoint a Secretary. = == 7. The Project Secretary 7.2. Appointment If the Project Leader and the current Project Secretary cannot agree + on a new appointment, they must ask the Developers by way of + General Resolution to appoint a Secretary. - -- -9. Software in the Public Interest SPI and Debian are separate organisations who share some goals. Debian - is grateful for the legal support framework offered by SPI. Debian's - Developers are currently members of SPI by virtue of their status as - Developers. - 9.1. Authority - - 1. SPI has no authority regarding Debian's technical or nontechnical - decisions, except that no decision by Debian with respect to any - property held by SPI shall require SPI to act outside its legal - authority, and that Debian's constitution may occasionally use SPI - as a decision body of last resort. - 2. Debian claims no authority over SPI other than that over the use - of certain of SPI's property, as described below, though Debian - Developers may be granted authority within SPI by SPI's rules. - 3. Debian Developers are not agents or employees of SPI, or of each - other or of persons in authority in the Debian Project. A person - acting as a Developer does so as an individual, on their own - behalf. - 9.2. Management of property for purposes related to Debian - Since Debian has no authority to hold money or property, any donations - for the Debian
Re: Proposal: The DFSG do not require source code for data, including firmware
Le mercredi 23 août 2006 à 17:38 +1000, Anthony Towns a écrit : Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. And again, contempt before discussion. If you don't want the debate to be public, you should ask the rules to be changed so that they are held on a moderated mailing list. Otherwise, the rule is that anyone is free to contribute to the discussion. You are the project leader, and as such your are partly responsible for the image of the project. I don't want (and I hope I'm not the only one) the project to be associated with your deliberately obnoxious behaviour. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Working out whether those expectations match those of the developers as a whole is what this GR -- and the discussion preceeding it -- is about. I'd strongly discourage people who participate in the discussion (whether you've run the n-m gauntlet or not) from dismissing developers' concerns about this as a red herring: if you're right, you shouldn't be afraid to discuss the reasons why you're right in detail when asked. On Wed, Aug 23, 2006 at 09:56:25AM +0200, Sven Luther wrote: To add to that, if i where Peter, i may feel slightly offended by the tone of your reply as well as the content of it. You are the DPL, and as thus speak with the authority given by the whole project, and i think you should as such be a more careful in your wording. I was entirely careful in my wording. Peter is in the n-m queue, he isn't a developer, and while he has every right to his personal views, as do you and as do I, those views don't necessarily match those of the majority of other developers or the project as a whole, and we should be very careful not to accidently quash discussion of other points of view by being so vehement in our own views that other people don't think their view is welcome. On Wed, Aug 23, 2006 at 10:28:03AM +0200, Josselin Mouette wrote: And again, contempt before discussion. If you don't want the debate to be public, you should ask the rules to be changed so that they are held on a moderated mailing list. Otherwise, the rule is that anyone is free to contribute to the discussion. Indeed, and I specifically pointed that out in my mail. I hope you agree that I'm also free to participate and point out Peter's participation in the project isn't what people might assume from the authority with which he imbues his views, if I think that's valuable. People posting to Debian lists should be doing so on the strengths of their arguments -- and if they are doing so, pointing out that they're not a maintainer should have absolutely no effect on the success of their arguments. If it emboldens developers to post about their opinions even when they disagree with what appears to be consensus, then that will only help avoid misunderstanding their views in future: because at the end of the day it's the developers' views that determine Debian's view, not any one else's. You are the project leader, and as such your are partly responsible for the image of the project. I don't want (and I hope I'm not the only one) the project to be associated with your deliberately obnoxious behaviour. Then I would suggest you debate the issue on its merits, rather than making the topic of debate be your views on my character. If you believe a comment on a list has no merit, it's very easy to deal with it: just ignore it, and go on discussing the ideas that are worth discussing. Cheers, aj signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Interesting, is this why the discussion is on a public mailing list? Personally I am not a DD either nor am I in the NM queu, however I was always under the impression that my opinion as a users matters (and should matter IMHO) to Debian anyway. In contrast to Sven and Josselin I'm not going to blame you for doing this statement as DPL as your From: address did not say so. But otherwise I wholehartedly agree with them. As for the issue at hand here I must also agree with Peter and Sven: Debian doesn't distribute chips with non-free firmware currently. So if Debian wants to distribute non-free binary-only firmware I do hope it will do so in non-free and not in main. Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- 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
Le mercredi 23 août 2006 à 19:19 +1000, Anthony Towns a écrit : If you believe a comment on a list has no merit, it's very easy to deal with it: just ignore it, and go on discussing the ideas that are worth discussing. Why would I do that, when you are taking the opposite way? When you believe a commend on a list has no merit, you explicitly ask other people to ignore it, based on a stupid DD/non-DD segregation instead of the merits of the comment. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Proposal: The DFSG do not require source code for data, including firmware
Why would I do that, when you are taking the opposite way? When you believe a commend on a list has no merit, you explicitly ask other people to ignore it, based on a stupid DD/non-DD segregation instead of the merits of the comment. This is not my understanding of aj's comment, Josselin. He did not ask to *ignore* Peter's comment, but only to remind that, Peter not being a DD, the comment can't be told to reflect the DD community opinion. Yes, I'm not completely sure that aj's comment was appropriate but I don't put in it the interpretation you seem to put (awful English, sorry, folks). signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 07:19:24PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Working out whether those expectations match those of the developers as a whole is what this GR -- and the discussion preceeding it -- is about. I'd strongly discourage people who participate in the discussion (whether you've run the n-m gauntlet or not) from dismissing developers' concerns about this as a red herring: if you're right, you shouldn't be afraid to discuss the reasons why you're right in detail when asked. On Wed, Aug 23, 2006 at 09:56:25AM +0200, Sven Luther wrote: To add to that, if i where Peter, i may feel slightly offended by the tone of your reply as well as the content of it. You are the DPL, and as thus speak with the authority given by the whole project, and i think you should as such be a more careful in your wording. I was entirely careful in my wording. Peter is in the n-m queue, he isn't a developer, and while he has every right to his personal views, as do you and as do I, those views don't necessarily match those of the majority of other developers or the project as a whole, and we should Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. be very careful not to accidently quash discussion of other points of view by being so vehement in our own views that other people don't think their view is welcome. Well. do we chip hardare, and as thus have the content of their ROMs covered by the DFSG ? I am not aware of such a situation, and altough Peter may have not said it in the best way, remember that for all those non-native english speakers there is a language barrier there, which may not be visible immediately, but which causes choice of non-perfectly-adequate wordings because of lack of vocabulary, or missing the subltetlies of various wording possibilities and misjudging the strength of them. You on the other side don't have this excuse :) Friendly, Sven Luther -- 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
On Wed, Aug 23, 2006 at 12:16:22PM +0200, Christian Perrier wrote: Why would I do that, when you are taking the opposite way? When you believe a commend on a list has no merit, you explicitly ask other people to ignore it, based on a stupid DD/non-DD segregation instead of the merits of the comment. This is not my understanding of aj's comment, Josselin. He did not ask to *ignore* Peter's comment, but only to remind that, Peter not being a DD, the comment can't be told to reflect the DD community opinion. No, but he blamed Peter for participating in the conversation because he was not yet a DD. I doubt that any DD's personal opinion here except aj's would be more representative of the DD community opinion. Yes, I'm not completely sure that aj's comment was appropriate but I don't put in it the interpretation you seem to put (awful English, sorry, folks). Maybe it is not best for us non-english speaker to comment on the content of aj's post, but i am happy that i am was not the only reacting to it. Maybe it is something french people are more sensible too, as both you, me and Josselin are all french-speakers. Friendly, Sven Luther -- 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
No, but he blamed Peter for participating in the conversation because he was That's not my understanding of aj's post. From my point of view, he did not blame Peter. He didn't even address him directly. Maybe it is not best for us non-english speaker to comment on the content of aj's post, but i am happy that i am was not the only reacting to it. Maybe it is something french people are more sensible too, as both you, me and Josselin are all french-speakers. Uh, such statement would likely reinforce the common perception that those French dudes really suck at speaking English..:-) signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Le mer 23 août 2006 12:16, Christian Perrier a écrit : Why would I do that, when you are taking the opposite way? When you believe a commend on a list has no merit, you explicitly ask other people to ignore it, based on a stupid DD/non-DD segregation instead of the merits of the comment. This is not my understanding of aj's comment, Josselin. He did not ask to *ignore* Peter's comment, but only to remind that, Peter not being a DD, the comment can't be told to reflect the DD community opinion. This is still how many people (me included) do perceive it. Moreover, the fact that the opinion that Peter expressed is widespread or not among the DDs is also irrelevant to the discussion. The discussion is about what options we have, and the the GR will be responsible to see which opinion is the most shared among the DD comunity. Until the vote, anybody can express his views opinions, even if it is a minority position ... that is what a public debate really is about. With that in mind, beeing a DD or not is a completely irrelevant information, and reminding is, whichever the original intention of that reminder was, is rude and inappropriate. That's not the first tham that aj does such reminders[1], and especiall beeing the DPL[2], I find that disturbing. Regards, [1] remember the ugly java thread ... [2] that does not mean that it's ok to do such remarks not beeing the DPL, it means that having such words as the DPL makes it worse. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp4FQdINokut.pgp Description: PGP signature
Re: Proposal: The DFSG do not require source code for data, including firmware
reminder was, is rude and inappropriate. That's not the first tham that aj does such reminders[1], and especiall beeing the DPL[2], I find that disturbing. Well, even being the DPL, aj is perfectly allowed to have personal opinions, even some that you (or me) may find irrelevant or wrong. As far as I know, Anthony did not yell out hey, I'm the boss here and here's the Boss opinion. This year we have a DPL who is very active in the ML, whether we like his opinions or not. I actually tend to like it but that's not a reason for me to take all posts by Anthony as the Speech from the Throne...:) signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 12:40:11PM +0200, Christian Perrier wrote: No, but he blamed Peter for participating in the conversation because he was That's not my understanding of aj's post. From my point of view, he did not blame Peter. He didn't even address him directly. well, its the end effect that count, and aj's word could be interpreted as : you are no DD, so your opinion doesn't count, and you should not give counterarguments to a DD. This is how i read it. Maybe it is not best for us non-english speaker to comment on the content of aj's post, but i am happy that i am was not the only reacting to it. Maybe it is something french people are more sensible too, as both you, me and Josselin are all french-speakers. Uh, such statement would likely reinforce the common perception that those French dudes really suck at speaking English..:-) I believe is more that the culture and structure of a given language make the speakers of said language more sensible to certain ways of turning the sentences or using certain words. For example, it seems clear that aj regarder the 'red hearing' word as pretty insulting to whoever it was Peter was replying to, to the point to make the commenthe made, while i found this just plain normal way of saying it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Live image: strategic for Debian or not?
* Ottavio Caruso [EMAIL PROTECTED] [2006-08-23 09:53]: --- Ottavio Caruso [EMAIL PROTECTED] wrote: it as an official download, branded as Defiant Live image? Obviously I meant: Debian live image. Blame the Yahoo spellchecker! Take a look at http://debian-live.alioth.debian.org/ yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System nexflo naja die auf debian.org sind fast ein jahr alt :S erich nexflo: uhm, 17 März 2003 würde ich nicht als alt bezeichnen. youam erich: nicht? man, bist du konservativ! die sind ja fast sprichwoertlich von gestern! [ 18.03.2003 ]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote: Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. Anyone can claim their views are representative of the project, and everyone -- including myself -- would be wrong to do so. The project has procedures for establishing its views on subjects: be that by package maintainers having opinions about their packages, discussions on mailing lists, setting policies, decisions by delegates, the technical committee or the project secretary, or having a vote about it. There are a few people who are authorised to speak on behalf of the project, including myself, Steve McIntyre as 2IC [0], and Joey Schulze as press officer. But none of those people get to cast their own views as the project's -- they simply have been entrusted by the project through the appropriate means to put the project's views into words. But Peter wasn't claiming that his views were the project's by any means -- he simply stated them in a way that, in my opinion, is easily mistaken for a statement of a pre-existing consensus on behalf of the project. There is no such consensus, however -- if there were, there would have been no one to raise this GR in the first place -- and this process of discussion and voting is how the project forms its opinion on the subject, which may well end up being entirely different to Peter's opinion, or yours, or mine. Well. do we chip hardare, and as thus have the content of their ROMs covered by the DFSG ? We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be reasonably argued that non-free firmware encoded in ROMs is involved in both cases. I'm reluctant to argue for or against either of those, since I don't know what the project's view on these things is or will be, and I don't want anyone to be confused into thinking that my personal view on this is the project's. I'm entirely comfortable in saying that it's an issue worth discussing though, because that's both my personal view and, in my opinion, the project's view. I am not aware of such a situation, and altough Peter may have not said it in the best way, remember that for all those non-native english speakers there is a language barrier there, [...] TTBOMK, and according to whois, Peter is US based, and a native speaker... Cheers, aj [0] http://lists.debian.org/debian-devel-announce/2006/04/msg00015.html signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 12:03:17PM +0200, Floris Bruynooghe wrote: On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Interesting, is this why the discussion is on a public mailing list? Personally I am not a DD either nor am I in the NM queu, however I was always under the impression that my opinion as a users matters (and should matter IMHO) to Debian anyway. Just to be clear: you're completely correct, users' opinions do matter, and the opinions of people in the new-maintainer queue are pretty much on a par with individual developers' opinions, except that they don't actually get counted when it comes time to tally the votes. Sometimes, some opinions won't be addressed because others will take precedence -- such as it'd be great if perl weren't essential not being addressed due to the complexity of doing so and the tradeoffs that would involve; but that doesn't mean the opinion isn't valued, or that it won't be addressed later if it becomes possible. I didn't say Peter's take didn't matter, because personally I consider it self-evident and unarguable that it does matter. The followup was only intended to make sure it was clear that it *was* Peter's take, and not necessarily the project's, and that debate is still appropriate. And *this* one I will sign as DPL. Cheers, aj -- Anthony Towns Debian Project Leader signature.asc Description: Digital signature
Re: Live image: strategic for Debian or not?
Ottavio Caruso wrote: I'd be glad to have your opinion about the two following related issues: 1) According to the documentation [1]: There are no official Debian live CDs available. However, we would like to recommend Knoppix, which is based on Debian - a very useful, full-featured live CD! I believe taht Knoppix is maintained with Alioth these days, hence I assume debian-knoppix to be Knoppix. There also the most official (even if still a non-official sub-project) project Debian Live (live.debian.net) which refers to the Debian Live Initiative. Regards, Joey -- Never trust an operating system you don't have source for! -- 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
On Wed, 23 Aug 2006 17:38:07 +1000, Anthony Towns aj@azure.humbug.org.au said: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. In that case, let me reiterate what Peter said -- and I have been a developer longer than you have, and I actually was around when the DFSG was crafted, so my expectations are not as easily dismissed as someone who has but recently joined our community. manoj -- Alas, I am dying beyond my means. Oscar Wilde [as he sipped champagne on his deathbed] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- 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
On Tue, 22 Aug 2006 22:23:29 -0700, Steve Langasek [EMAIL PROTECTED] said: On Tue, Aug 22, 2006 at 06:19:08PM -0500, Manoj Srivastava wrote: On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek [EMAIL PROTECTED] said: Hi folks, Ever since the sarge release, an ongoing question has been: what do the DFSG require for works that are not programs as previously understood in Debian? Several rounds of general resolutions have now given us answers for some subclasses of non-program works, but debate still rages regarding one particularly important class: firmware for peripheral devices. Actually, I disagree What point are you disagreeing with? That there is debate about firmware in Debian? That the previous common understanding of programs in Debian did not include firmware? I am disagreeing that there is a genuine ambiguity. 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. and, even worse, so does the common definition of the phrase computer program: If 55% of the voting developers in Debian don't agree with this common definition as pertains to the DFSG (which I doubt most laymen would agree with either where firmware is concerned), why do they need the consent of another 20% of the voters in order to proceed accordingly? This is like legislating the value of Pi not to be irrational -- I mean, rationality is to be prized, no? What is firmware, then? Speaking as en electrical engineer, I would say that firmware is just compiled binary programs that are meant to be executed by a processor (that often lives on the mainboard) which happens not to be the contral processing unit. Yes, these are reasonable definitions of both program and firmware. They're also not the ones that Debian has been operating under for most of its history; the previous version of the Social Contract said that Debian would remain 100% free software, and I don't think anyone will argue that there are programs which aren't software. So if firmware was already supposed to be covered under the DFSG, how is this reconciled with the fact that no one ever worried about firmware in Debian until the past couple of years? These are not just reasonable definitions -- they are the overwhelming majority of definitions found for the terms. I searched the digital libraries of the ACM and of the IEEE, and I have yet to come across any mention of firmware that does not concede that it is software programs -- perhaps software programs that are read off non-volatile memory, instead of magnetic fields on a hard-drive platter, but in either case the storage media is some kind of (semi) persistent elecro-magnetic field, and the stored instructions are acted upon by a processing unit. No textbook, no reference, no definition in dictionaries of electrical engineering, no online dictionaries, seem to be ambiguous or confused -- seems hard to imagine that people can be genuinely confused for long. It is easy enough to correct ones understanding of the term firmware with a little research. Now, I also understand the convenience factor -- it is vastly more convenient to just let this slide under the carpet, and let what is technically non-free under the DFSG into main by cleverly redefining words to suit -- the users want it, the hardware vendors want it, and the benefit of sticking to principles of freedom seem silly and appear to have little immediate benefit. But pretending that firmware definition is somehow ambiguous is Clintonian (it depends n what the meaning of the word 'is' is) in nature. Oh, as to why we still have non-DFSG material in main, well, cleansing a distribution the size of Debian takes time, and we have been working towards this goal -- and it is not so long ago that an editorial change to the SC clarified the meaning of the SC for some people. manoj -- Even the most boundless love can end. Rhett Butler, to Scarlet O'Hara, _Gone With The Wind_ Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- 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
* Matthew Wilcox [EMAIL PROTECTED] [060823 15:46]: Certainly, it's one of the purposes. But I don't think we've *lost* anything by distributing binary firmware. Consider the cases: 1. Everything in hardware. You're not able to fix anything without a soldering iron ... and good luck to you with that. 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a good deal of skill to fix anything. Again, best of luck. 3. Binary-only firmware in the driver. Slightly better chance of trying to figure out what's going on, but still low. 4. Firmware source in non-preferred form. Modifications probably possible, but when the next round of changes come out from the vendor, you probably have to ditch your mods. 5. Firmware source in preferred form. Can send changes back to vendor, everybody wins. (and I'm sure people can think of other finer distinctions). You seem to want to disallow cases 3 and 4 which makes sense from a here are the rules of data freedom, now i must follow them point of view, but really don't make sense to the vendor, nor to the user. It seems like an all-or-nothing approach. That's not different at all to normal programs. Perhaps it even becomes a bit clearer if you substitute 1) and 2) for programs with no software. Having non-free software is - for the very single developer and any seen locally[1] - better than having no program to do the task all together. We (Debian project) acknowledge the need of users and distribute such stuff in the non-free section in addition to our distribution, so that people are not locked into totaly non-free systems but only have to bear that much unfreeness as it necessary. We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. Hochachtungsvoll, Bernhard R. Link [1] having no software at all increases the pain and makes it more likely someone writes something free, but for the single person that cannot write it, this is too far reached. -- 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
Manoj wrote: Actually, I disagree, and, even worse, so does the common definition of the phrase computer program: asking google about define: computer program gives: , | * A computer program is a set of statements or instructions to be | used directly or indirectly in a computer in order to bring | about a certain result. | www.tms.org/pubs/journals/JOM/matters/matters-9710.html But Debian has a tradition of ignoring the common definition of phrases. Have you tried asking google to define software, for example? I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. I second Steve's proposal (although I can't be bothered to go to the hassle of signing this message right now. If it becomes important to do so, I shall.) -- 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
On Wed, Aug 23, 2006 at 09:24:16PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote: Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. Anyone can claim their views are representative of the project, and everyone -- including myself -- would be wrong to do so. So, why do you denigrate Peter in such a way ? What you said could apply as well to you, no ? The project has procedures for establishing its views on subjects: be that by package maintainers having opinions about their packages, discussions on mailing lists, setting policies, decisions by delegates, the technical committee or the project secretary, or having a vote about it. There are a few people who are authorised to speak on behalf of the project, including myself, Steve McIntyre as 2IC [0], and Joey Schulze as press officer. But none of those people get to cast their own views as the project's -- they simply have been entrusted by the project through the appropriate means to put the project's views into words. Ok. But Peter wasn't claiming that his views were the project's by any means -- he simply stated them in a way that, in my opinion, is easily mistaken for a statement of a pre-existing consensus on behalf of the project. I guess he never said so, he just worded his argumentation in such a way, that he thought his position was comon sense. Also, since in the previous cases i was involved in the non-free firmware issue, many people chose to use the same argument, both in the debian-legal threads and elsewhere. There is no such consensus, however -- if there were, there would have blink There is no such consensus that debian doesn't chip hardware ? I think we don't need consensus, these are plain facts, and we even advertize them on our web site, so i think there is some major misunderstanding about this going on. been no one to raise this GR in the first place -- and this process of discussion and voting is how the project forms its opinion on the subject, which may well end up being entirely different to Peter's opinion, or yours, or mine. Indeed, so, why did you need to resort to such bass tactics as an ad-hominem attack on Peter using his non-DD status ? Well. do we chip hardare, and as thus have the content of their ROMs covered by the DFSG ? We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be reasonably argued that non-free firmware encoded in ROMs is involved in both cases. blink huh ? That would be the first time i hear anyone say this with a straigth face or really meaning it. If you would get look at the logs, i have used that same argumentation in the debian-legal thread last year, but with a proof-as-asburdum, or however it is called, way. If we where really going to argue this, we could just as well stop shiping debian, since there is no way to actually make use of any of the content we ship without some piece of non-free firmware, the first of it being the non-free bios you use on your system. I'm reluctant to argue for or against either of those, since I don't know what the project's view on these things is or will be, and I don't want anyone to be confused into thinking that my personal view on this is the project's. Maybe, but then you don't make statements as you did, going away from arguing about the non-free matter, and into polemics about if non-DDs are allowed to post and comment, or if they should show due respect to the venerable DDs and be silent, and not contradict one's better. I'm entirely comfortable in saying that it's an issue worth discussing though, because that's both my personal view and, in my opinion, the project's view. So ? How does that excuse the comment you made. This is completely irrelevant to the critic raised against your comment. I am not aware of such a situation, and altough Peter may have not said it in the best way, remember that for all those non-native english speakers there is a language barrier there, [...] TTBOMK, and according to whois, Peter is US based, and a native speaker... So much for that then. Friendly, Sven Luther -- 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
On Wed, Aug 23, 2006 at 02:11:39PM +0200, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Why is freedom of software only important for the central processing unit, but immaterial for other processing usints? Who said it's not important? I believe it is, just that it's not a battle which should be pursued by Debian by not distributing sourceless firmwares. It is clear that by banning firmwares from Debian we harm our users (easily verifiable) much more than we help the cause of free software (it's hard to prove that it would be of any help, and the burden of proof lies on who supports it). Indeed, but would it not make more sense, to aknowledge that the firmware is non-free, and then argue that we should include it nonetheless, instead of making obviously false claims like firmware are not programs ? Si, am I silly and alone in thinking that firmware is binary computer programs? Let us ask google to define: firmware: You are silly in pretending that the DFSG and the widely shared consensus among developers always intended considering them non-free and inappropriate for main. The last of the three pre-sarge non-free GRs confirmed the fact that firmware is indeed a code binary, and should have source. A majority of the DDs voted that, and unless there is another GR reverting this, that opinion is binding to the project. That said, Steve's GR is not the most smart way to solve this issue. Friendly, Sven Luther -- 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
On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: Manoj wrote: Actually, I disagree, and, even worse, so does the common definition of the phrase computer program: asking google about define: computer program gives: , | * A computer program is a set of statements or instructions to be | used directly or indirectly in a computer in order to bring | about a certain result. | www.tms.org/pubs/journals/JOM/matters/matters-9710.html But Debian has a tradition of ignoring the common definition of phrases. Have you tried asking google to define software, for example? I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. One of the purposes of having access to the prefered form of modification, is to be able to fix bugs. If the firmware for your fibrechannel card has a bug, are you currently able to fix it ? And if so, do you think the binary-only firmware you have available is the prefered form of modification ? Friendly, Sven Luther -- 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
On Aug 23, Sven Luther [EMAIL PROTECTED] wrote: Indeed, but would it not make more sense, to aknowledge that the firmware is non-free, and then argue that we should include it nonetheless, instead of making obviously false claims like firmware are not programs ? Firmwares are not programs *for the purpose of DFSG compliance* is a statement which may or may not be true, but will not obviously false (or not) until we will known the outcome of this GR. I do not mind either way anyway, my purpose it to make Debian an useful and free (as-in-freedom) Linux distribution, not arguing about the general definition of the word firmware. -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
In linux.debian.vote Sven Luther [EMAIL PROTECTED] wrote: On Wed, Aug 23, 2006 at 09:24:16PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote: Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. Anyone can claim their views are representative of the project, and everyone -- including myself -- would be wrong to do so. So, why do you denigrate Peter in such a way ? What you said could apply as well to you, no ? Why do you believe that remarking that somebody is not a debian developer is denigration? I think aj's post was very appropriate, considering how many non-developers like to explain to us what the DFSG really means. If we where really going to argue this, we could just as well stop shiping debian, since there is no way to actually make use of any of the content we ship without some piece of non-free firmware, the first of it being the non-free bios you use on your system. Unpleasant consequences are not a very good way of refuting a logically sound argument. -- ciao, Marco -- 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
El miércoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns escribía: We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be No, the DFSG are applied to what's provided by Debian, not to what it's required by it. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- 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
On Wed, Aug 23, 2006 at 07:14:03AM -0600, Matthew Wilcox wrote: On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote: On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. One of the purposes of having access to the prefered form of modification, is to be able to fix bugs. Certainly, it's one of the purposes. But I don't think we've *lost* anything by distributing binary firmware. Consider the cases: 1. Everything in hardware. You're not able to fix anything without a soldering iron ... and good luck to you with that. 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a good deal of skill to fix anything. Again, best of luck. 3. Binary-only firmware in the driver. Slightly better chance of trying to figure out what's going on, but still low. 4. Firmware source in non-preferred form. Modifications probably possible, but when the next round of changes come out from the vendor, you probably have to ditch your mods. 5. Firmware source in preferred form. Can send changes back to vendor, everybody wins. (and I'm sure people can think of other finer distinctions). Notice that i don't disagree with you, i even have argued, altough maybe in a more clumsy way, exactly the same thingas you. My point is that if we believe the above, then we should say so, namely : firmware is non-free. but we chose to keep it, because it is globally more free than the firmware-less alternatives or other reasons. This is what you claim, and what everyone thinks who support the keep firmware in main way, so why not be open about it and say it so ? You seem to want to disallow cases 3 and 4 which makes sense from a here are the rules of data freedom, now i must follow them point of view, but really don't make sense to the vendor, nor to the user. It seems like an all-or-nothing approach. I did say nothing of the sort. Actually, I can turn your argument on its head. The point you're making is about ease of fixing bugs. Given case 3, I can't fix the bug myself, but I have in the past been able to get the vendor to fix the bug. In case 2 (which your argument would seem happy with), I can't fix the bug at all. So cases 3 and 4 are *better* from a bug fixing point of view. Nope, my argument is unrelated to this, it is related to calling things as they are and not play word-games just because the reality inconveniences us. Friendly, Sven Luther -- 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
On Wed, Aug 23, 2006 at 03:00:07PM +0200, Marco d'Itri wrote: In linux.debian.vote Sven Luther [EMAIL PROTECTED] wrote: On Wed, Aug 23, 2006 at 09:24:16PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote: Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. Anyone can claim their views are representative of the project, and everyone -- including myself -- would be wrong to do so. So, why do you denigrate Peter in such a way ? What you said could apply as well to you, no ? Why do you believe that remarking that somebody is not a debian developer is denigration? I think aj's post was very appropriate, considering how many non-developers like to explain to us what the DFSG really means. Well, i and at least 2 other people felt it like that, so if nothing else, the wording of Anthony's comment sucked. If we where really going to argue this, we could just as well stop shiping debian, since there is no way to actually make use of any of the content we ship without some piece of non-free firmware, the first of it being the non-free bios you use on your system. Unpleasant consequences are not a very good way of refuting a logically sound argument. No, but they show the consequences of what you are arguing, and ask the question of if we really want to go this way, instead of just saying it for the case that is of interest, and ignore the full consequences of it. Friendly, Sven Luther -- 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
On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote: On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. One of the purposes of having access to the prefered form of modification, is to be able to fix bugs. Certainly, it's one of the purposes. But I don't think we've *lost* anything by distributing binary firmware. Consider the cases: 1. Everything in hardware. You're not able to fix anything without a soldering iron ... and good luck to you with that. 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a good deal of skill to fix anything. Again, best of luck. 3. Binary-only firmware in the driver. Slightly better chance of trying to figure out what's going on, but still low. 4. Firmware source in non-preferred form. Modifications probably possible, but when the next round of changes come out from the vendor, you probably have to ditch your mods. 5. Firmware source in preferred form. Can send changes back to vendor, everybody wins. (and I'm sure people can think of other finer distinctions). You seem to want to disallow cases 3 and 4 which makes sense from a here are the rules of data freedom, now i must follow them point of view, but really don't make sense to the vendor, nor to the user. It seems like an all-or-nothing approach. Actually, I can turn your argument on its head. The point you're making is about ease of fixing bugs. Given case 3, I can't fix the bug myself, but I have in the past been able to get the vendor to fix the bug. In case 2 (which your argument would seem happy with), I can't fix the bug at all. So cases 3 and 4 are *better* from a bug fixing point of view. -- 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
Jacobo Tarrio [EMAIL PROTECTED] wrote: El miércoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns escribía: We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be No, the DFSG are applied to what's provided by Debian, not to what it's required by it. The DFSG apply to The Debian system. The social contract doesn't define what The Debian system is. We could define it as What's shipped by Debian, but we could also define it as A system consisting of a computer and a Debian installation or Whatever is provided by Debian and run on the host processor. -- Matthew Garrett | [EMAIL PROTECTED] -- 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
El miércoles, 23 de agosto de 2006 a las 14:59:37 +0100, Matthew Garrett escribía: No, the DFSG are applied to what's provided by Debian, not to what it's required by it. The DFSG apply to The Debian system. The social contract doesn't define what The Debian system is. We could define it as What's No, but it says that Debian are the producers of the Debian GNU/Linux system (should be fixed some day). So, the Debian system does not include anything not produced (or provided) by Debian. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- 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
Followups set to -vote; why are we cc'ing this across multiple lists? On Wed, Aug 23, 2006 at 03:01:52PM +0200, Jacobo Tarrio wrote: El mi?rcoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns escrib?a: We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be No, the DFSG are applied to what's provided by Debian, not to what it's required by it. The DFSG is Debian's definition of free, so it's applied to everything we think should be free. That includes most of the contents of main and contrib (one notable exception is license texts), everything that main requires, and generally what we run on our servers. The middle one's the one of interest, it's expressed in the first point of the social contract as: We will never make the system require the use of a non-free component. (For reference, that replaced the following text from v1.0 of the social contract: [...] we will never make the system depend on an item of non-free software. ) Cheers, aj signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Bernhard R. Link [EMAIL PROTECTED] wrote: We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. So I think the real question is How does us refusing to ship non-free firmware help free software?. If a user wants to use Debian, then the obvious thing for them to do will be to buy hardware that has the non-free firmware in ROM. Ironically, this will actually make it harder for them to ever use free firmware! I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. -- Matthew Garrett | [EMAIL PROTECTED] -- 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
* Matthew Garrett [EMAIL PROTECTED] [060823 16:40]: We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. This depends whom you ask. Some people will even instist that today a computer without a working (i.e. non-free) flash-plugin is not operational. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. This is not true in either direction. Not every non-free application has a free counterpart[1]. And not every hardware needs firmware. Many hardware for PCs needed ROM-stored instructions in the past. But as chips were expensive they were designed to run on the same processor, then operating systems no longer running in real mode arrived and Linux had to write drivers for almost everything themself. Where is the difference to firmware? Other that the vendor might be unwilling to give specs to write it on your own saying that there is that firmware. (Last time they has the excuse that all is secret...) So I think the real question is How does us refusing to ship non-free firmware help free software?. If a user wants to use Debian, then the obvious thing for them to do will be to buy hardware that has the non-free firmware in ROM. Or which somes with no firmware at all. (Or where it makes no difference, I do not know if any IDE controler has firmware and I did not hear about IDE harddiscs able to replace it). There also is still the non-free section (or split it into non-free-host-apps, non-free-periperical-apps, non-free-docs, ) so that people can still get it working easily without pretending anything if free or can be part of a free operating system. Ironically, this will actually make it harder for them to ever use free firmware! Where is the difference. If firmware is so free that even Debian declares it free, who will write a free one? I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. I'm not saying we should refuse to ship non-free code. I've voted to keep non-free in the last GR about it. I'm against putting things in Debian which are not free. If it is in Debian, I want to be sure that I am allowed to modify it and get it working with some work. If I' bye stuff with ROMed firmware I know it is in there and what I have to expect. If I have to get in from the non-free section, I know I'll have no chance and try to buy something where the manufacturer gave specs and someone worked on them. If everything is in main I'm lured in a false feeling of security and have no easy way to distinguish and choose the vendor with a free firmware. I'm still waiting for a argument how this is in any way different from any other driver for hardware. The only advantage of firmware is that it does not hurt people with minority arches (But given Vancouver that can not be a difference, because we do not care about arches not used by everyone, do we) more than other people. And that it is not that dependent on some interfaces often changing on Linux. Would you also ask to include non-free drivers if they had stable interface and the kernel had a bochs included by default to run them? Hochachtungsvoll, Bernhard R. Link [1] Think of all that little programs speaking some secret protocol, applications for special tasks and so on. -- 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
On Wed, Aug 23, 2006 at 03:40:49PM +0100, Matthew Garrett wrote: Bernhard R. Link [EMAIL PROTECTED] wrote: We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. So I think the real question is How does us refusing to ship non-free firmware help free software?. If a user wants to use Debian, then the obvious thing for them to do will be to buy hardware that has the non-free firmware in ROM. Ironically, this will actually make it harder for them to ever use free firmware! I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. I agree with you. But the point is on how you communicate about the fact. What Steve and others who seconded him propose is to ship non-free firmware in main, and declaring it as data, and thus disguising it as free software. By moving the non-free firmware to non-free, we clearly renew our believe in free software, and encourage effort to reverse engineer or convince vendors, as aurelien and piotr and a few others are reimplementing the apple mac os classic boot sector. It is still relatively easily possible to design the whole non-free firmware support in such a way that it is totally transparent to the user, apart of a message in the installer or something, which will inform him that he needs non-free firmware for its hardware, and asks if he wants to make use of it. So, shiping non-free code because there is no choice is just fine, but shiping it while insisting it is free is not. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Live image: strategic for Debian or not?
Martin Schulze wrote: There also the most official (even if still a non-official sub-project) project Debian Live (live.debian.net) which refers to the Debian Live Initiative. There were much things happened behind the curtains, we are working on having an alpha release soon (in about a week or two), and then asking for beeing accepted as official. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- 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
On Wed, Aug 23, 2006 at 05:18:03PM +0100, Matthew Garrett wrote: OK, never saw that drives. But where is the problem with them. Works without needing any non-free stuff being put in the operating systems and people might be able to replace it. No good example. Wait. So by Non-free stuff being put in the operating systems, you mean Non-free stuff lives on my filesystem? What about non-free stuff shipped by debian ? Friendly, Sven Luther -- 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
Bernhard R. Link [EMAIL PROTECTED] wrote: This is not true in either direction. Not every non-free application has a free counterpart[1]. And not every hardware needs firmware. If you can find a single hard drive on the market that doesn't contain some sort of firmware, I'll be greatly impressed. Or, for that matter, a vaguely modern processor. Let alone bootstrapping a system (LinuxBIOS will suffice for a very small range of hardware), running a modern network card, using a graphics chip for any purpose other than unaccelerated 2D, or, well, pretty much any piece of hardware on the market today. For all practical purposes, it's impossible to obtain hardware that doesn't depend on firmware. Or which somes with no firmware at all. (Or where it makes no difference, I do not know if any IDE controler has firmware and I did not hear about IDE harddiscs able to replace it). Yeah, motherboard chipsets are probably about the only thing on a modern system that isn't obviously microcoded. Shame that the drives you plug into them are - vendors often provide firmware upgrades for IDE drives. There also is still the non-free section (or split it into non-free-host-apps, non-free-periperical-apps, non-free-docs, ) so that people can still get it working easily without pretending anything if free or can be part of a free operating system. I'm entirely happy with us making it clear that firmware isn't free-as-in-DFSG. I'm not happy about us leaving it out of the default install images. I'm not saying we should refuse to ship non-free code. I've voted to keep non-free in the last GR about it. I'm against putting things in Debian which are not free. If it is in Debian, I want to be sure that I am allowed to modify it and get it working with some work. If I' bye stuff with ROMed firmware I know it is in there and what I have to expect. If you believe that you can buy hardware without ROM firmware, then I think it's pretty clear that you don't know it is in there. If I have to get in from the non-free section, I know I'll have no chance and try to buy something where the manufacturer gave specs and someone worked on them. If everything is in main I'm lured in a false feeling of security and have no easy way to distinguish and choose the vendor with a free firmware. Or you'll go and buy some hardware with the firmware in eeprom where it's a pain to replace with free firmware. Would you also ask to include non-free drivers if they had stable interface and the kernel had a bochs included by default to run them? No. There's plenty of hardware with free drivers, and I think that us refusing to provide the non-free ones does make a difference. I run no non-free drivers on any of my hardware. At the point where it's possible for me to run a machine without any non-free firmware, I'll be happy to drop it. -- Matthew Garrett | [EMAIL PROTECTED] -- 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
* Matthew Garrett [EMAIL PROTECTED] [060823 17:31]: If you can find a single hard drive on the market that doesn't contain some sort of firmware, I'll be greatly impressed. Or, for that matter, a vaguely modern processor. Let alone bootstrapping a system (LinuxBIOS will suffice for a very small range of hardware), running a modern network card, using a graphics chip for any purpose other than unaccelerated 2D, or, well, pretty much any piece of hardware on the market today. For all practical purposes, it's impossible to obtain hardware that doesn't depend on firmware. In case it was not clear I was discussing things where firmware is also loadable. I've never seen BIOSes being part of the Operating system, but you can get hardware that runs with LinuxBios. I've not yet met a hard drive (as opposed to all kind of Bus controlers) needing any firmware before operating. I don't know about new graphic cards (all I really need is 2D), but looking at how ugly the drivers are and what a secret even communicating with the hardware is for the vendors, I really doubt any firmware on the card is involved. Network cards I never looked to deeply, but most of them were so small I really doubt they are more than plain hardware. WLan cards might be something different, but I never used them. Yeah, motherboard chipsets are probably about the only thing on a modern system that isn't obviously microcoded. Shame that the drives you plug into them are - vendors often provide firmware upgrades for IDE drives. OK, never saw that drives. But where is the problem with them. Works without needing any non-free stuff being put in the operating systems and people might be able to replace it. No good example. I'm entirely happy with us making it clear that firmware isn't free-as-in-DFSG. I'm not happy about us leaving it out of the default install images. I'm not saying we should refuse to ship non-free code. I've voted to keep non-free in the last GR about it. I'm against putting things in Debian which are not free. If it is in Debian, I want to be sure that I am allowed to modify it and get it working with some work. If I' bye stuff with ROMed firmware I know it is in there and what I have to expect. If you believe that you can buy hardware without ROM firmware, then I think it's pretty clear that you don't know it is in there. If it is direct hardware or a ROM, it does not matter that much in there. If there is a ROM at all. In days where modems have no modulator/demodulator chips any more, there are not that much things where people would put processors in. Put again, what part instead if my BIOS (which mostly runs in CPU so some people might not call it firmware, and at least with PCs is never needed to be shipped by a driver) and IDE drivers (which also always come with some pre-installed firmware, so not relevant), is found in every cheap box? (assuming to wireless). If I have to get in from the non-free section, I know I'll have no chance and try to buy something where the manufacturer gave specs and someone worked on them. If everything is in main I'm lured in a false feeling of security and have no easy way to distinguish and choose the vendor with a free firmware. Or you'll go and buy some hardware with the firmware in eeprom where it's a pain to replace with free firmware. As I said. As long as noone cares for free firmwares, what difference does it make? I the vendor opens the specs, there should be a free one and not problems. If it does not open the specs the eeprom version has the advantage to work even when the firmware-binary gets lost and the manufacturer might have tested it before. (Or introduced something to replace the firmware, which again defeats your point). Hochachtungsvoll, Bernhard R. Link -- 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
Matthew Garrett [EMAIL PROTECTED] I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. The above argument seems to be If I don't see it, it doesn't matter. Of course, evidence is unlikely to appear before the action is taken. I doubt any corporation will declare if debian does this, we'll follow the DFSG instead. Instead, we each get to make our best guesses. I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there's this crap which their operating system uses to support their hardware but doesn't have its normal freedoms. However, I'm undecided whether it's a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won't work without firmware being copied to it? Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs? Thanks for any answers, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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
On Wed, Aug 23, 2006 at 07:25:10PM +0100, MJ Ray wrote: Matthew Garrett [EMAIL PROTECTED] I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. The above argument seems to be If I don't see it, it doesn't matter. Of course, evidence is unlikely to appear before the action is taken. I doubt any corporation will declare if debian does this, we'll follow the DFSG instead. Instead, we each get to make our best guesses. I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there's this crap which their operating system uses to support their hardware but doesn't have its normal freedoms. However, I'm undecided whether it's a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won't work without firmware being copied to it? Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs? I would indeed vote for a solution including a non-free hardware, or even better an additional CD, which contained a non-free version of d-i (which need to include certain non-free firmwares and drivers in the images), and all the additional non-free firmware stuff. This way, we could add a list of pci ids needding non-fre hardware, and do a check pretty early in the installer, and if those non-free hardware is found, inform the user about it, and use the non-free installer CD instead, and all the rest would be taken care for him. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
