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. 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
