Re: linux-2.6: includes nondistributable and non-free binary firmware
On Thu, Aug 17, 2006 at 10:07:42AM -0700, ldoolitt@recycle.lbl.gov wrote:
> Maks -
>
> On Thu, Aug 17, 2006 at 06:05:30PM +0200, maximilian attems wrote:
> > > Something about [bug #242866] seems broken, however,
> > > because RC-buggy linux-2.6 packages keep making it into
> > > testing. Is it obvious how to keep this from happening,
> > > without starting a new bug attached to linux-2.6?
> >
> > if you feel like it reassign it,
> > anyway linux-2.6 is frozen and propagation to testing
> > is coordinated with the release and the d-i team.
>
> Sorry, I don't understand this statement.
linux-2.6 will no more migrate to testing without the RMs explicit aproval.
The RMs in this case being Andreas Barth and Steve Langasek (and some new RM
team members i don't remember exactly offhand), and it is they who have the
ultimate word of what will be included in etch. Please contact the
debian-release@lists.debian.org mailing list to comment on this.
> > on the other side a good example to remove people access to
> > their discs.
>
> That's the argument that sent sarge out the door with
> DFSG violations.
No, what allowed sarge to go out the door with DFSG violations was an
unambigous GR by a majority of the debian developers who decided to include
those non-free firmware (and GFDL docs, and some random fonts, and ...), into
sarge even though they didn't quite meet the DFSG.
That vote is not valid for etch though, as we decided to waive that only for
sarge, so only a new GR will allow debian to release the current kernel with
non-free firmware as part of etch, independently of the migration scripts you
are so worried about above.
> > anyway if you want to improve the legal situtation use:
> > http://wiki.debian.org/KernelFirmwareLicensing
> > dilinger succeeded in various firmware relicensing
> > thanks to his quest to the vendors. feel free to pick up.
>
> For each offending file, there are three possible solutions:
> 1. Get the author to release source code under a DFSG-free license
> 2. Move the firmware to non-free, patching the driver to use
> request_firmware()
> 3. Delete the driver and firmware entirely.
4. Move the whole friver to non-free, without major patching.
5. Reverse engineer the needed firmware, and create a trully free driver.
> AFAIK, the best outcome yet from the relicensing discussions
> on http://wiki.debian.org/KernelFirmwareLicensing is to properly
> permit the redistribution of the binary, without source code.
Indeed, but even that was laughed at back then when we started at it, and you
should have seen the reaction of LKML when i mentioned it there. Maks and
kyle's reaction are child's play compared to them :)
> That's fine for debian non-free, and a necessary step for making
> option (2) above work properly. Until and unless the entire
> Linux kernel is moved to non-free, such relicensing doesn't
> solve the fundamental bug.
Indeed.
> I agree that option (3) is bad, but I still recommend it for
> the short term. It's the quickest path to a legal and
For the short term, 4. is a better solution.
> SC-conforming Linux release, and it will bring people out
> of the closet to volunteer to work on (2). I think (2)
> is the actual goal, but maybe not one that can be finished
> before the proposed etch freeze -- especially since most
> of the blobs need to be relicensed before they can be made
> part of firmware-nonfree.
Indeed, which is because we could also consider :
6. Pass another GR to allow debian/etch to release as is, provided we commit
to a real effort to solve this for etch+1, or better yet, with some
pro-active wording, which say we will make every effort to solve this issue,
but don't provide timelines and schedules, as upstream will probably bring
more problematic firmware in in unsuspecting ways.
> I would be amazed and impressed if option (1) could be made
> to work for any of these files. I don't volunteer to try.
:)
> If the kernel team decides on (2) or (3), I'd be happy to
> help with the coding. (Note that, due to the unfortunate
Your help is welcome, we await the first of your patches breathlessly :)
> state of upstream, most of the patching/deletion has to
> happen in the creation of the .orig.tar.gz file, not the
> .diff.gz file) Unfortunately, due to a lack of hardware,
> I can't help with any testing (other than "does it compile").
This is not a problem, we can easily enough spin a linux-2.6-2.6.18.dfsg1 or
someting when the time is ready.
There is not much time before the actual etch release is at hand, which is why
6. is probably a better solution right now, especially if you consider that
while we delay etch, debian/sarge will still carry those non-free bits, and so
even if we delay etch until around the same time we would have had etch+1 out
the door (18 month from december 6, or june 6 2008), we would have gained
nothing with regard to freeness.
So, let's get etch out the door as is, or with the work we can do until the
freeze and release date, and already start the work for post-etch.
Friendly,
Sven Luther
Reply to: