Re: non-free firmware
Hi,
* Sven Luther (sven.luther@wanadoo.fr) [060108 14:00]:
> On Sun, Jan 08, 2006 at 11:52:20AM +0100, Andreas Barth wrote:
> > What needs to be done to get the infrastructure ready? Do you think it
> > might make sense to try to get it done e.g. at a BSP?
> waldi is working on it, and it is on our todo list, i am not sure it is
> something which can be fixed in a BSP, altough maybe some brainstorm session
> would be of benefit.
Well, if there is anything I can do to help you (including writing mails
to d-d-a :), please tell me.
> > Well, there might be cases where the binary blob is enough, but I think
> > we agree that
> > a) this is probably the exception and not the rule, and
> > b) this requires a case-per-case-inspection.
> And how exactly can you guarantee this is the case without being the guy who
> wrote the code, and even so, how could we be sure to thrust such a guy
> claiming that it is the ultimate source code ?
Well, in most cases, we cannot make ultimate guarantees. But for
example, if you package any software for inclusion in Debian, you
normally read through the accompying files. Usually, you can of course
take it for granted what is written therein - however, if you notice
they look like some GPLed-software, and is now something with an
GPL-incompatible license, some more checks are required. The same is
true here: One can usually make pretty much progress with some basic
common sanity and with looking a bit around. Of course, some corner
cases will stay to continue.
What we as release team really need is some statement from the
maintainers team like "we have done some thorough search through the
sources, and are sure that the reminder is now DFSG-free (according to
the changed DFSG)". We usually trust the maintainers about correctly
summarizing issues, and also about judging correct whether some software
is DFSG-free or not. Of course, we all (and that includes of course also
me) sometimes make mistakes, that is just human.
> > Well, we as release managers have the task to make sure it doesn't slip
> > away (that's one of the reasons there are cheat lis^W^Wtracking lists).
> > If people think it's a non-issues, they can try to change the DFSG - for
> > the release team, the current valid DFSG is part of the RC check list.
>
> But as you said, it is highly unlikely that you will be removing the kernel
> package, so you need to work with the kernel maintainers :)
>
> The main problem is one of ressources, and we need a single person who can
> devote time and effort to follow up on all those drivers, and see if the
> firmware can be removed from them or not. Right now everyone is focused
> on other stuff.
Hm. I have some mean ideas, but let's wait if someone comes up on his
own.
Thanks for this frank status update for me.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: