Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote: > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote: > > I don't think you did get a rejection, a few people said that _they_ > > weren't going to do it, but if you want to then go ahead. I think people > > are just fed up of people bringing up the issue and then failing to do > > anything about it -- so prove them wrong ;-) > > Actually patches to add firmware loader support to tg3 got rejected. I think they will be accepted if they first introduce a transition period where tg3 will do request_firmware() and only use the built-in firmware if that fails. Second step is to make the built-in firmware a config option and then later on when the infrastructure matures for firmware loading/providing firmware it can be removed from the driver entirely. One of the sticking points will be how people get the firmware; I can see the point of a kernel-distributable-firmware project related to the kernel (say on kernel.org) which would provide a nice collection of distributable firmwares (and is appropriately licensed). Without such joint infrastructure things will always be a mess and in that context I can see the point of the driver authors not immediately wanting to switch exclusively. Simply because they'll get swamped with email about how the driver doesn't work... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > Second step is to make the built-in firmware a > > config option and then later on when the infrastructure matures for > > firmware loading/providing firmware it can be removed from the driver > > entirely. > > I think the infrasturcture is quite mature. We have a lot of drivers > that require it to function. what seems to be currently missing is distro level support for using firmware for modules needed for booting (and tg3 falls sort of under that via nfsroot) and widespread easy availability of firmware in distros and for users. Both are a bit of a chick-and-egg thing, and this is what a transition period with a few key drivers in dual-mode would hopefully resolve. One of the options is to even ship the firmware in the kernel tarbal but from a separate directory with a clear license clarification text in it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > I agree. And that really doesn't need a lot of infrastructure, > > basically just a tarball that unpacks to /lib/firmware, maybe a specfile > > and debian/ dir in addition. > > > At the moment there is -zero- infrastructure that would allow my tg3 to > continue working, when I upgrade to a tg3 driver with external firmware. > > The user has to put a file in some location manually. > > That's a complete non-starter, from a usability standpoint. but unless we allow the driver to use such things, such infrastructure won't come into existence either. It's a chicken-and-egg situation... except that we can for a while make tg3 and others be both the chicken and egg until the real chicken is there. > Further, several firmwares, including tg3, are really a collection of > bits of information: .text, .bss, and random variables (start addr, > image size, ...). The current interface is complete crap for this sort > of setup. > > The firmware loader really needs to be loading -archives- not individual > files. > > We are a -long- way from moving the firmware out of the tg3 source code. Yet that is no excuse to not at least start addressing the issues. What you just listed are deficiencies in the kernel infrastructure, not doing something because we have slightly suboptimal infrastructure isn't the right thing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [MeeGo-dev] [Pkg-meego-maintainers] Packaging the MeeGo stack on Debian - Use the name ?
On 12/10/2010 4:38 AM, Julian Andres Klode wrote:
On Fr, 2010-12-10 at 11:24 +, MJ Ray wrote:
Ibrahim Haddad wrote:
We would ask you to move away from using {M,m}-e-e-{G,g}-o or any subset of
those letters or sounds in that order, alone or in combination with other
letters, words or marks that would tend to cause someone to make a
reasonable connection of the reference with the MeeGo mark. We specifically
discussed one possibility for illustration purposes – which is to use MG in
the place of MeeGo. We do not think that a plain text MG, when used in
reference to the code, as in a file or project or team name, would cause a
reasonable person to be confused.
OK, so for this to be possible, {M,m}-e-e-{G,g}-o must be never used
in the works of The Meego Project as a functional term. That is to
ask, is it possible to change the name without impacting on other
software which uses the works of The Meego Project? There is no
libmeego* or anything like that?
If there is a libmeego*, then clearly meego should be used in some way
for interoperability and I suggest the trademark policy changes to be
reasonable and explicitly allow use of meego as part of functional
names. That is, drop the file name constraint above. It's just
honest description of the upstream source of the code and not
necessarily used in product names. File names aren't normally covered
by trademarks, are they?
If there isn't a libmeego* or similar, I guess all is well and I
thank everyone for clarifying it.
There is libmeegotouch and a lot of stuff has meego in the package
names, we can't really change that without breaking compatibility.
Some further things for Ibrahim:
* Our team name is a unix group name and it's pkg-meego (meaning
package software from MeeGo). The trademark is used to refer to
the upstream part, so people know what is packaged. That's the
same for pkg-mozilla and all the other teams, and just a
technical detail. We'd like to keep it, since changing it is
impossible (you need to delete the old group and create a new
one instead).
* I propose that we use MeeGo in other things like this:
* Replace:
* Debian MeeGo Team
* Debian MeeGo stack maintainers
* Debian MeeGo packaging Team
* By:
* Packagers of MeeGo-originated and related
software
* This makes it clear that MeeGo refers to upstream only,
and that this is not officially MeeGo.
do you also have a pkg-canonical or pkg-ubuntu group for packaging
Ubuntu software ?
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d023f86.9060...@linux.intel.com
