[Desktop_printing] PAPI for CUPS: Volunteers needed!

Giuseppe Ghibò ghibo at mandriva.com
Wed Jun 28 12:58:56 PDT 2006

Michael Sweet wrote:
> Roger Leigh wrote:
>> Michael Sweet <mike at easysw.com> writes:
>>> Giuseppe Ghibò wrote:
>>>> Sorry the OT, but what about all the drivers (including printer, 
>>>> scanners
>>>> and wireless) that works only if a binary firmware in the device memory
>>>> (firmware which is not free and which generally can't be even freely 
>>>> redistributed) is uploaded before.
>>> WRT uploading firmware to a device (i.e. the firmware is not executed
>>> by the driver), the GPL isn't an issue because the firmware is just
>>> more data that is sent to the device.  The same firmware file could
>>> be used on any platform you port the code to, and you don't need the
>>> firmware source to recompile the driver.  You *do* need to allow
>>> redistribution and modification of the firmware file, however, just
>>> as documentation or image files in a package can be distributed and
>>> modified.
>> I think the situation gets a little muddier when you consider Section
>> 3 of the GPL:
>> "The source code for a work means the preferred form of the work for
>> making modifications to it."
>> For firmware, the "data" blob may likely /not/ be the preferred form
>> for modification if it was created/generated from some other source.
> Actually, this isn't necessarily the case.  Some firmware files are
> essentially just data files with a little encapsulation that the
> on-board ROMs use - it would be just like running FontForge to edit
> a font file - doesn't make a difference whether you have the original
> "source" files (whatever they would be) or the font file itself.

That's a bit different IMHO. I could provide just a Type1 .pfb or a TrueType .ttf
file without the corresponding .sfd file, because they actually
provide from my point of view the same "information" but maybe then one
might allow or not allowing to modify the font (or if allow to release them, you need to release 
under another name [like the case Vera->DejaVu] or some other kind of restriction
like not selling them as standalone product [same as of Vera font
license where you can bundle with other products, etc., but can't
sell the font itself standalone).

> In any case, when the blob is not executing as part of the driver/
> program, the use falls under the same GPL "loophole" as running a
> separate program.  In most cases, you *can't* run a firmware image
> natively on the local machine, it has to run either in an emulator
> (separate program/library interpreting the data file) or on the
> actual hardware.
> IMHO, the dividing line is whether the firmware file a) runs on the
> local machine and b) runs in the same process space as the GPL'd
> program.  If a and b are both "yes", then the firmware file source
> code must be provided, otherwise not.  An aggregate of a GPL program
> with a non-GPL file/program does not make the non-GPL stuff fall
> under the GPL!
> That said, IANAL and a "definitive" answer is probably best found
> by asking the FSF...

The problem is that drivers developers seems satisfied or
tolerate of this situation (which for and end user and distros is
often a source of pain). I'm not saying that vendors
are obeyed or enforced to release their firmware or for
people to boycott their products or wait they go out of business, but a better
collaboration from vendors in giving the firmware files to the community under
a more  compatible free license so that firmware could be bundled
with GPL and/or OSS drivers would be expected (note that I'm not
talking about things like ndiswrappers...). Ditto from point
of view of driver developers, which maybe might "ask" this to them.
"bundled" mean compatible also from drivers' license point of view.

On the other hand from two devices of more or less the same cost (e.g. a printer or a scanner) 
where you install the software, but your distro doesn't/can't provide the firmware
but only the free driver, and where you have to go in the vendor site, seeking
for the right firmware, seeking for the right file name the driver
is expected and the right firmware version (because in the meanwhile
it has been renamed 20 times), place in the right
place in /usr/share/firmware or /etc/hotplug/firmware or whatever, etc., and
another device where you have just to select the printer
from a list and it already provides the firmware which one you would choose?

So here there is actually the following problems:

- from vendor point of view, share their firmware so that it could
be redistributed freely (which doesn't mean only allowing this for end users
to do the free downloading themselves).

- from driver point of view, how should be the firmware license
(or the firmware itself) so that it could be BUNDLED with the driver in a way compatible with 
the driver/distro open license.

- start a list of firmware according to which OSS drivers supports them, which need to have an
license in way that they could be bundled with the driver itself.


More information about the Printing-summit mailing list