This argument doesn't hold water. The unpleasant point

for users and distributors isn't the "binary-only"

thing, it's the "no right to distribute" problem.

And that's the same for firmware blobs or binary-only

userspace blobs.
IOW, if you can get the right to redistribute a binary-only

userspace blob which incudes the firmware inside, why

shouldn't you be able to get the right to redistribute

just the firmware?
Or the other way round: Do you think your binary-only software

will be important enough so distributors will go through

all the trouble of trying to get a license to include it in

their distribution? If so, why wouldn't they do the same

for the plain firmware blobs for in-kernel drivers?
Johannes

-

Hi,
In particular xceive based drivers provide a numerous set

of features which cannot be implemented into the kernel

because the API (both V4L and DVB) are limited.

Since to me it seriously has the impression that the project

especially the core of the project is closed to the outside

world (just how someone stated it out recently
I don't have any binary only software just as all the time before.

I am also allowed to publish firmware for several drivers

(not only the em28xx driver). Although as mentioned earlier

already the current existing driver is not really manageable

due the firmware mess and that driver will change completly

and include templates for several other bridge drivers.
Markus

-