Re: RFC: Final version of kernel team's firmware GR proposal, coined to be consensual to all those of good faith involved in the current discussion.
On Sat, Oct 07, 2006 at 09:19:58AM +0100, MJ Ray wrote:
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> > Mmm, i think it is important to mention the fact that they are hexdumps, since
> > all of them are, no ?
>
> If all of them are, then mention it if you like, but why is it important
> what form the binaries are in?
It is for documentation purpose, to make sure they are no misunderstanding.
> > 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.
>
> It increases the amount of research prospective supporters should do. Is it
> important that people agree on the reasons for an action, rather than just
> agreeing on the action?
Well i can understand some, but these are points all DDs should agree to
anyway, and they are pretty clear. They also should help to decide one way or
the other if there are any doubt in the rest.
The other proposals all had such clauses.
> > > > 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 ?
>
> No, I fear that the kernel team may add additional firmware binaries not in
> the upstream kernel, especially as I thought some poster claimed they
> already did in the past.
Ok, a few reality checks here are needed :
1) Etch will release with 2.6.18, or possibly but unlikely 2.6.17. So, we
already know what is in upstream.
2) The kernel team is commited to solving the issue post-etch, as is shown
in the rationale from Frederik, and in the GPL-violation clause, altough not
in the non-free one. We have said so enough times on the lists and irc. So,
we are not going to add such things.
3) In any case, the GR only concerns itself for etch, and not what comes
afterward, and it is relatively clear, given the current timeframe, that the
currently in unstable kernel is the one who will ship with etch.
> > 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.
>
> I think that would cover this case in points 4-6 well, yes.
Cool.
> > > > 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.
>
> Are you sure of that? The GPL instructs: 'each file should have at least
> the "copyright" line and a pointer to where the full notice is found.'
So, then this means that those files have no copyright/license notice at all,
and are thus fully non-distributable.
> > 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.
>
> That's a different, less problematic case.
Why is that less problematic, in all cases, the source is missing, and thus
the firmware non-distributable.
> [...]
> > may wish is better, yes, changing that.
>
> Thank you.
Yeah, thanks for your reply, it seems most people are boycotting me, as there
was no second at all to the proposal, and very little comment.
Sven Luther
Reply to: