Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
[Manoj Srivastava] Given this official statement, I also suggest that the GR proposal is moot, since the proposer himself believes that the kernel modules in question can not be distributed by Debian legally. There are a few firmware files which are sourceless but explicitly _not_ GPL - these are still covered by some or all of the GRs under past and present consideration. Whether this subset of firmware matters much to end users, I couldn't say. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Fri, Oct 20, 2006 at 03:46:57PM -0500, Peter Samuelson wrote: [Manoj Srivastava] Given this official statement, I also suggest that the GR proposal is moot, since the proposer himself believes that the kernel modules in question can not be distributed by Debian legally. There are a few firmware files which are sourceless but explicitly _not_ GPL - these are still covered by some or all of the GRs under past and present consideration. I don't understand which GRs cover this one ? Whether this subset of firmware matters much to end users, I couldn't say. tg3, e100 maybe too, those are some very widely widespread ethernet drivers, used among others in servers, where netbooting is a must. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, Oct 15, 2006 at 01:34:11PM -0700, Don Armstrong wrote: On Sun, 15 Oct 2006, Sven Luther wrote: Well, we all know it is sourceless GPLed firmware, and we chose just to say the contrary, because it is convenient to us. If we know[1] a work is a sourceless GPLed work, then we cannot distribute it *at* *all*. Doing otherwise is wholly inappropriate, GR or no GR, and opens up us and our mirror operators to a whole scope of liability that they should not be facing. This is indeed true, but mitigated by the fact that everyone does the same, and that more often than not the copyright holder are distributing it themselves, thus they hardly can sue us (or win the following case) over it. But the whole idea of this GR, was to let this whole issue pass, and ask the copyright holders (if they can be found, difficult in some cases, like the acenic one) to clarify their position and provide an explicit license, post-etch. The new proposal says exactly that : 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. the voted-upon resolution is less clear and precise about this, and will bring more confusion than anything else. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, Oct 15, 2006 at 07:21:49PM -0500, Manoj Srivastava wrote: On Mon, 16 Oct 2006 02:03:59 +0200, Sven Luther [EMAIL PROTECTED] said: On Sun, Oct 15, 2006 at 04:05:57PM -0500, Manoj Srivastava wrote: Can you spell out for us which kernel modules, in the opinion of the kernel team, are certainly sourceless GPL stuff? Please make sure you have the official opinion of the kernel team, and that you are saying that these modules do contain sourceless GPL'd material. The complete list at : http://wiki.debian.org/KernelFirmwareLicensing?action=show#head-93ba883132bc3ebc09131100ec6bb6fbfb5e3e61 Include code which Larry stated where unlikely to be the actual form of modification. I think he even said something along the lines of no sane coder would write such directly in hex. There are some which are big enough that it would not be practical to write them directly in hex, so there is little doubt about the outcome. Folks, if this is indeed the official opinion of the kernel team (since that is what was solicited, then regardless of any GR, we need to remove every thing mentioned by Sven from the kernel immediately, since we are not allowed to distribute them. This is my own opinion this time, and i specifically said that others of the kernel team should give an official statement. Given this official statement, I also suggest that the GR proposal is moot, since the proposer himself believes that the kernel modules in question can not be distributed by Debian legally. I appreciate there not being any more GR's on this subject :), since now we have to remove these modules, as per the official kernel team position. Ah, so now you want to censor an already seconded GR ? And your word on what needs removing has more weight that what the project decides in a GR ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Fri, Oct 13, 2006 at 03:57:28PM -0500, Manoj Srivastava wrote: Probably, but then choice 1. of the ballot currently under vote should have had 3:1 supermajority also, which added to misleading wording of the short title compared to the actual content of the proposal, cast some serious doubt as to the validity of the vote being currently held. Nope. Choice 1 (I am assuming you mean the gr_firmware's release etch despite firmware issues option, though that is not at all clear) in no way requires anything that violates the DFSG or the social contract, so it does not need the super majority. Well, it : 1. allows for releasing firmware binaries under the GPL lacking propper sources. = This is a violation of DFSG 2 (Source Code) : The program must include source code, and must allow distribution in source code as well as compiled form. 2. means removal of support for thos users needing non-free firmware to install. This coupled with the staunch refusal of the d-i team to implement non-free loading in d-i, leads to an inability of some of our users to install on their hardware using debian, even on non-free media. This is especially true with the removal of such popular drivers, like the tg3 driver, which will have to go with the resolution just voted. = This is a violation of SC4 (Our priorities are our users and free software) and SC5 (Works that do not meet our free software standards) : We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. 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). Notice how SC5 says : we support their use and provide infrastructure for non-free packages. This clearly includes support for installing non-free firmware on our installer medias. The first point is probably uninportant, since the resolution passed by 271:42, thus more than getting this 3:1 majority. I wonder how many of those voters didn't realize what they where voting on, but i guess we will never know for sure. On the other hand, thiesecond point is not really violated here, but it also means that we need a GR vote in order to be able to release etch without a proper support for loading non-free firmware .udebs from d-i, and that this would be a 3:1 vote ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, Oct 15, 2006 at 10:52:57AM +0200, Mike Hommey wrote: On Sun, Oct 15, 2006 at 10:17:56AM +0200, Sven Luther [EMAIL PROTECTED] wrote: Notice how SC5 says : we support their use and provide infrastructure for non-free packages. This clearly includes support for installing non-free firmware on our installer medias. Notice how SC5 says : we support their use and provide *infrastructure for non-free packages*, which clearly means we provide ftp space for non-free packages, not installing non-free firmware on our installer medias. Oh ? Please tell me which dictionary says that infrastructure means ftp archive ? We especially removed the ftp area wording from the social contract for this purpose in the pre-sarge GRs. I believe you could call the installer media and their own .udeb archive, infrastructure needed in order to install debian, no ? And anyway, the intent is clear, we promise in SC5 to support our users which need non-free, and purely and simply removing tg3, acenic and a bunch of other modules, without a non-free installer or support for them in our installer is clearly a violation of SC5. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, Oct 15, 2006 at 10:17:56AM +0200, Sven Luther [EMAIL PROTECTED] wrote: Notice how SC5 says : we support their use and provide infrastructure for non-free packages. This clearly includes support for installing non-free firmware on our installer medias. Notice how SC5 says : we support their use and provide *infrastructure for non-free packages*, which clearly means we provide ftp space for non-free packages, not installing non-free firmware on our installer medias. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, 15 Oct 2006 10:17:56 +0200, Sven Luther [EMAIL PROTECTED] said:
On Fri, Oct 13, 2006 at 03:57:28PM -0500, Manoj Srivastava wrote:
Probably, but then choice 1. of the ballot currently under vote
should have had 3:1 supermajority also, which added to misleading
wording of the short title compared to the actual content of the
proposal, cast some serious doubt as to the validity of the vote
being currently held.
Nope. Choice 1 (I am assuming you mean the gr_firmware's release
etch despite firmware issues option, though that is not at all
clear) in no way requires anything that violates the DFSG or the
social contract, so it does not need the super majority.
Well, it :
1. allows for releasing firmware binaries under the GPL lacking
propper sources.
Wrong. It only allows us to distribute drivers that upstream
is implying we have sources for -- and we have no proof that the
sources are not in the preferred form of modification. Guessing that
the preferred form of modification is not proof.
{SNIP a whole lot of hostile text}
manoj
--
The greatest disloyalty one can offer to great pioneers is to refuse
to move an inch from where they stood.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
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] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, Oct 15, 2006 at 08:42:41AM -0500, Manoj Srivastava wrote:
On Sun, 15 Oct 2006 10:17:56 +0200, Sven Luther [EMAIL PROTECTED] said:
On Fri, Oct 13, 2006 at 03:57:28PM -0500, Manoj Srivastava wrote:
Probably, but then choice 1. of the ballot currently under vote
should have had 3:1 supermajority also, which added to misleading
wording of the short title compared to the actual content of the
proposal, cast some serious doubt as to the validity of the vote
being currently held.
Nope. Choice 1 (I am assuming you mean the gr_firmware's release
etch despite firmware issues option, though that is not at all
clear) in no way requires anything that violates the DFSG or the
social contract, so it does not need the super majority.
Well, it :
1. allows for releasing firmware binaries under the GPL lacking
propper sources.
Wrong. It only allows us to distribute drivers that upstream
is implying we have sources for -- and we have no proof that the
sources are not in the preferred form of modification. Guessing that
the preferred form of modification is not proof.
Well, we all know it is sourceless GPLed firmware, and we chose just to say
the contrary, because it is convenient to us. IANAL, so i couldn't say if this
is indeed a proper defense in court if we get sued, but i guess that it may be
problematic. But then on the otherhand, i suppose the risk of getting sued is
as negligible as the risk of getting sued over the other firmwares which are
non-distributable.
Manoj, this is just a matter of how much you can lie to yourself, and i am
sorry, but my own concience is not letting me say to the world something which
we evidently know is wrong. You may have a much loser concience for this one
point though.
{SNIP a whole lot of hostile text}
Manoj, ...
Please tell me (in private) what in the rest of the text you feel is hostile.
It seems a pretty correct analysis of the problem, and i don't see a single
line of agressiveness or hostily in it. But then, naturally, you are the
native english speaker, and i may severly mis-understand some nuances of what
i wrote, so please inform me of where the hostility is, so i may correct this
in the future.
And if, after you reread it, you cannot justify it as hostile, i would
appreciate if you would take the above defaming coment back.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, 15 Oct 2006, Sven Luther wrote: Well, we all know it is sourceless GPLed firmware, and we chose just to say the contrary, because it is convenient to us. If we know[1] a work is a sourceless GPLed work, then we cannot distribute it *at* *all*. Doing otherwise is wholly inappropriate, GR or no GR, and opens up us and our mirror operators to a whole scope of liability that they should not be facing. Don Armstrong 1: We can argue about whether we actually know or suspect or feel, but once it's clear, there's no other choice. I'd personally argue to be on the cautious side unless a copyright holder tells us that we're distributing what they actually use the modify the work, but that's just because I want Debian to continue to exist even in the face of insane copyright holders. -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, 15 Oct 2006 17:16:04 +0200, Sven Luther [EMAIL PROTECTED] said: On Sun, Oct 15, 2006 at 08:42:41AM -0500, Manoj Srivastava wrote: On Sun, 15 Oct 2006 10:17:56 +0200, Sven Luther [EMAIL PROTECTED] said: On Fri, Oct 13, 2006 at 03:57:28PM -0500, Manoj Srivastava wrote: Probably, but then choice 1. of the ballot currently under vote should have had 3:1 supermajority also, which added to misleading wording of the short title compared to the actual content of the proposal, cast some serious doubt as to the validity of the vote being currently held. Nope. Choice 1 (I am assuming you mean the gr_firmware's release etch despite firmware issues option, though that is not at all clear) in no way requires anything that violates the DFSG or the social contract, so it does not need the super majority. Well, it : 1. allows for releasing firmware binaries under the GPL lacking propper sources. Wrong. It only allows us to distribute drivers that upstream is implying we have sources for -- and we have no proof that the sources are not in the preferred form of modification. Guessing that the preferred form of modification is not proof. Well, we all know it is sourceless GPLed firmware, and we chose just to say the contrary, because it is convenient to us. IANAL, so i couldn't say if this is indeed a proper defense in court if we get sued, but i guess that it may be problematic. But then on the otherhand, i suppose the risk of getting sued is as negligible as the risk of getting sued over the other firmwares which are non-distributable. Can you spell out for us which kernel modules, in the opinion of the kernel team, are certainly sourceless GPL stuff? Please make sure you have the official opinion of the kernel team, and that you are saying that these modules do contain sourceless GPL'd material. Thank you, manoj -- Never put off until tomorrow what you can do the day after. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sun, Oct 15, 2006 at 04:05:57PM -0500, Manoj Srivastava wrote: Can you spell out for us which kernel modules, in the opinion of the kernel team, are certainly sourceless GPL stuff? Please make sure you have the official opinion of the kernel team, and that you are saying that these modules do contain sourceless GPL'd material. The complete list at : http://wiki.debian.org/KernelFirmwareLicensing?action=show#head-93ba883132bc3ebc09131100ec6bb6fbfb5e3e61 Include code which Larry stated where unlikely to be the actual form of modification. I think he even said something along the lines of no sane coder would write such directly in hex. There are some which are big enough that it would not be practical to write them directly in hex, so there is little doubt about the outcome. Furthermore, i want to reminid you about the broadcom/tg3 precedent, for such a case which was previously sourceless GPL, and now, after clarification from the copyright holder after *OUR* prompting, shows : * Firmware is: * Derived from proprietary unpublished source code, * Copyright (C) 2000-2003 Broadcom Corporation. * * Permission is hereby granted for the distribution of this firmware * data in hexadecimal or equivalent format, provided this copyright * notice is accompanying it. Notice how it says : Derived from proprietary unpublished source code. This precedent and anlysis shows that a huge portion of the 40+ or so affected firmwares are most probably sourceless GPL files, and thus illegal to distribute. See also various hints concerning variables and defines with CODE in their name, or UCODE or variants thereof. So, you want an official statement of the kernel team ? What about : http://wiki.debian.org/KernelFirmwareLicensing?action=show#head-98e7641feaea08b775f4d5c58d071b77ff172c90 Which says : 2. Sourceless binary blobs distributed under GPL. This situation has been interpreted as a violation of the terms of GPL, which requires the distribution to be accompanied by the source code. Removal of firmware in this category will cause effective removal of a large number of important drivers, resulting in a severe negative impact on our users. No direct list is given here, but again this was based on larry's list. In any case, i will let others reply to this, as it is clear you won't accept my word for this, and it is past time others of the kernel team got involved in this again. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Mon, 16 Oct 2006 02:03:59 +0200, Sven Luther [EMAIL PROTECTED] said: On Sun, Oct 15, 2006 at 04:05:57PM -0500, Manoj Srivastava wrote: Can you spell out for us which kernel modules, in the opinion of the kernel team, are certainly sourceless GPL stuff? Please make sure you have the official opinion of the kernel team, and that you are saying that these modules do contain sourceless GPL'd material. The complete list at : http://wiki.debian.org/KernelFirmwareLicensing?action=show#head-93ba883132bc3ebc09131100ec6bb6fbfb5e3e61 Include code which Larry stated where unlikely to be the actual form of modification. I think he even said something along the lines of no sane coder would write such directly in hex. There are some which are big enough that it would not be practical to write them directly in hex, so there is little doubt about the outcome. Folks, if this is indeed the official opinion of the kernel team (since that is what was solicited, then regardless of any GR, we need to remove every thing mentioned by Sven from the kernel immediately, since we are not allowed to distribute them. Given this official statement, I also suggest that the GR proposal is moot, since the proposer himself believes that the kernel modules in question can not be distributed by Debian legally. I appreciate there not being any more GR's on this subject :), since now we have to remove these modules, as per the official kernel team position. manoj not entirely facetious -- No extensible language will be universal. Cheatham Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Sat, 7 Oct 2006 06:49:17 +0200, Sven Luther [EMAIL PROTECTED] said: 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. This clause is a violation of the DFSG, being able to modify whatever we ship (apart from license texts) is a core part of what free software is. Electing not to apply the DFSG violates the SC, which says everything we produce would be free according to the DFSG. No matter how you look at it, this proposal supersedes either the DFSG or the SC, or both, even though it does so only temporarily -- and superseding a foundation document requires a 3:1 super majority. I suggest eliminating this clause. manoj -- Try to get all of your posthumous medals in advance. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Fri, Oct 13, 2006 at 09:04:48AM -0500, Manoj Srivastava wrote: On Sat, 7 Oct 2006 06:49:17 +0200, Sven Luther [EMAIL PROTECTED] said: 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. This clause is a violation of the DFSG, being able to modify whatever we ship (apart from license texts) is a core part of what free software is. Electing not to apply the DFSG violates the SC, which says everything we produce would be free according to the DFSG. No matter how you look at it, this proposal supersedes either the DFSG or the SC, or both, even though it does so only temporarily -- and superseding a foundation document requires a 3:1 super majority. Probably, but then choice 1. of the ballot currently under vote should have had 3:1 supermajority also, which added to misleading wording of the short title compared to the actual content of the proposal, cast some serious doubt as to the validity of the vote being currently held. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
Manoj Srivastava [EMAIL PROTECTED] wrote: On Sat, 7 Oct 2006 06:49:17 +0200, Sven Luther [EMAIL PROTECTED] said: 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. This clause is a violation of the DFSG, being able to modify whatever we ship (apart from license texts) is a core part of what free software is. Electing not to apply the DFSG violates the SC, which says everything we produce would be free according to the DFSG. No matter how you look at it, this proposal supersedes either the DFSG or the SC, or both, even though it does so only temporarily -- and superseding a foundation document requires a 3:1 super majority. I suggest eliminating this clause. Or voting for this clause with 3:1 majority. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Fri, 13 Oct 2006 16:51:34 +0200, Sven Luther [EMAIL PROTECTED] said: On Fri, Oct 13, 2006 at 09:04:48AM -0500, Manoj Srivastava wrote: On Sat, 7 Oct 2006 06:49:17 +0200, Sven Luther [EMAIL PROTECTED] said: 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. This clause is a violation of the DFSG, being able to modify whatever we ship (apart from license texts) is a core part of what free software is. Electing not to apply the DFSG violates the SC, which says everything we produce would be free according to the DFSG. No matter how you look at it, this proposal supersedes either the DFSG or the SC, or both, even though it does so only temporarily -- and superseding a foundation document requires a 3:1 super majority. Probably, but then choice 1. of the ballot currently under vote should have had 3:1 supermajority also, which added to misleading wording of the short title compared to the actual content of the proposal, cast some serious doubt as to the validity of the vote being currently held. Nope. Choice 1 (I am assuming you mean the gr_firmware's release etch despite firmware issues option, though that is not at all clear) in no way requires anything that violates the DFSG or the social contract, so it does not need the super majority. manoj -- The man who has never been flogged has never been taught. Menander Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
I second the proposal below. It explicitly takes effect only for Etch, and it will allow installation on machines requiring tg3 net drivers (of which I have one). I believe this is the fourth second, so it only needs one more? Sven Luther wrote: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 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, both upstream and in the debian packaging; 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 treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Thu, Oct 12, 2006 at 10:37:50AM -0700, Kevin B. McCarty wrote: I second the proposal below. It explicitly takes effect only for Etch, and it will allow installation on machines requiring tg3 net drivers (of which I have one). I believe this is the fourth second, so it only needs one more? Indeed, it needs only one more second. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
Kevin B. McCarty [EMAIL PROTECTED] wrote: I second the proposal below. It explicitly takes effect only for Etch, and it will allow installation on machines requiring tg3 net drivers (of which I have one). I believe this is the fourth second, so it only needs one more? Yes, me. I was confused earlier (I thought that seconding this proposal would delay the vote on the other ones). So here's my second: Sven Luther wrote: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 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, both upstream and in the debian packaging; 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 treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL Yup. That one. -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) pgpl9FF0JEoj8.pgp Description: PGP signature
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
Hello, sorry for being late on this, I took a couple of days off from everything firmware and this got inbetween. The Proposal worked out by Sven covers the consensual position of the kernel team, as discussed on the last kernel team meeting. I think this GR should be voted upon, as it considers all aspects of the issue. I hope we can vote on this despite the already running GRs, thus I second the following proposal: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 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, both upstream and in the debian packaging; 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 treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
I second the following proposal: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 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, both upstream and in the debian packaging; 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 treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operation System Kürzlich hat mein Radio-teleskop auch ein Signal im Raum Salzburg auf der Frequenz von 99.00 MHz aufgefangen. Referenzmessung in Wien auf der Frequenz 99.9 MHz und in Graz auf 89.2MHz kamen alle zum selben Schluss: Es existiert definitiv kein intelligentes Lebenwese an der Senderquelle. -- lausiv auf futurezone.orf.at signature.asc Description: Digital signature
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
I second the following proposal. === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 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, both upstream and in the debian packaging; 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 treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL signature.asc Description: Digital signature
