Re: [gentoo-dev] Re: linux-firmware

[Alec Warner <antarus@gentoo.org>]

On Tue, Feb 19, 2013 at 8:43 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rick \"Zero_Chaos\" Farina posted on Tue, 19 Feb 2013 09:18:39 -0500 as
> excerpted:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 02/17/2013 05:04 AM, Ulrich Mueller wrote:
>>>>>>>> On Sun, 17 Feb 2013, Rick \"Zero Chaos\" Farina wrote:
>>>
>>>> I would be very happy to have the licensing issues fixed, it looks
>>>> like it won't be fun, however I was originally told that redist was a
>>>> required right for things to be added to linux-firmware at all so I
>>>> fear a lot of things may be out of sync in the upstream package.
>>>
>>> IIUC, they require new additions to be redistributable, but don't
>>> remove old images if they're not. Which doesn't make sense.
>>>
>>> You should consider mirror restriction for this package.
>>
>> I semi-agree with you except for one issue, we are the ones creating
>> this package. Upstream offers a git repo but no tarball.  So if we stop
>> distributing it then that kinda kills the package.
>>
>> Maybe a bug for which firmware are not-redistributable and I can remove
>> them from our package?  I want people to have working systems but
>> following the law is a bit more important.
>
> If all upstream has is a git tarball, what about git-snapshot builds?
> Use the git2 eclass and set a commit number, thus allowing testing and
> stabilization of a specific commit, but the checkout would be directly
> from upstream, so (for the general case, live-image case discussed below)
> gentoo wouldn't be distributing anything but the ebuild.
>
> That /would/ add git as a dep of linux-firmware, however.  And if linux-
> firmware is to be an rdep of the kernel...
>
> Also, some people might not want even the git-pak-files containing
> firmware with some licenses on their system.  Is it possible to tell git
> to only clone/pull specific files in a repo?  Of course, if upstream has
> the repo modularized enough, that may not be an issue either, but I'd
> guess it'd still be rather complex to setup and test and ebuild designed
> to work that way.

Lets not re-invent the wheel here:

Debian has free and non-free packages.
http://packages.debian.org/sid/firmware-linux

# free copyright
http://packages.debian.org/changelogs/pool/main/f/firmware-free/firmware-free_3.2/firmware-linux-free.copyright

# nonfree copyright
http://packages.debian.org/changelogs/pool/non-free/f/firmware-nonfree/firmware-nonfree_0.36+wheezy.1/firmware-linux-nonfree.copyright

http://pkgs.fedoraproject.org/cgit/linux-firmware.git/tree/linux-firmware.spec
Specifically:
License:	GPL+ and GPLv2+ and MIT and Redistributable, no modification permitted

It looks like OpenSuse has split packages. Most distros are debian or
redhat based these days.

We can easily have a firmware package that is USE="nonfree" and only
install the libre firmware, ala debian. This also fixes 'the license
issue' because if people want ACCEPT_LICENSE=@OSI-APPROVED they just
need to turn the nonfree flag off.

None of this is rocket science, and the work has likely already been
done by others, so just take it and go.

-A

>
>
> Of course, we'd still be distributing any firmware included in the live-
> images, but I'm not sure if we include any there or not.  If so, then
> certainly someone would have to go thru that and verify the
> redistributability of each bit of included firmware.  But that's a rather
> limited special case.
>
>
> But regardless, no upstream tarballs, only a git repo, shouldn't be a
> problem for mirror-restrict.  git2.eclass is already enough to deal with
> that bit.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>