On Fri, Oct 06, 2006 at 01:40:47PM +0100, MJ Ray wrote:
> Sven Luther <[EMAIL PROTECTED]> wrote:
> > ========================== START OF PROPOSAL ==========================
> > Definition: For the purpose of this resolution, the "firmware" mentioned
> > below
> > design binary data encoded as hexdumps in some of the linux kernel drivers
> > and
>
> s/design/&ates/ ; s/encoded as hexdumps/included/
So :
Definition: For the purpose of this resolution, the "firmware" mentioned below
designatesbinary data included in some of the linux kernel drivers.
Mmm, i think it is important to mention the fact that they are hexdumps, since
all of them are, no ?
> > 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);
>
> no-op! Please delete.
>
> > 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;
>
> no-op! Please delete.
Why should we delete those. Since in these age of dropping rationales from the
proposal, it is important to give a bit of context too. I would like to keep
these points.
> > 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.
>
> Where 'such' = 'problematic' and apparently not limited to those *in* the
Yes, those we are speaking about in clause 3. Do you have a suggestion for
better wording ?
> upstream kernel. I think it should be limited to the upstream kernel.
Point 6. clearly restricts the firmware involved to those in the debian kernel
package and associated .udebs. I take it you fear that the kernel team will
add additional not-kernel-related firmware binaries to the debian kernel
package ?
What about saying this :
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.
> > 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.
>
> Unless we know that its copyright holder is a Linux copyright holder,
> I can't see how its licensing is thus implied just by being there.
The linux kernel tarball has a GPL licensing statement in the root of the
tree. Any file not explicitly given an individual license is thus under the
GPL implicitly.
Furthermore, those firmware hexdump are usually (well, in the cases i
checked), found inside files, which themselves have a GPL copyright statement
at the top, and thus their full content is licensed under the GPL.
> > We will include these firmware in Debian Etch and review them after the
> > release. Vendors of such firmware are advised to investigate the
> > licensing
> > terms, and make sure the GPL distribution conditions are respected,
> > especially with regards to source availability.
>
> Aieeee. Do we really want to say 'advised'? s/are advised/may wish/
may wish is better, yes, changing that.
> > 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 ==========================
>
> Hope that helps,
Yes thanks.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
