Re: hplip and use of the "driver plugin"
On Sat 19 Nov 2016 at 12:30:47 -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 18 Nov 2016, Jape Person wrote:
> > What about hplip? Doesn't inclusion of the hp-setup program in hplip sort of
> > violate the spirit of having only FOSS in the main repository when executing
>
> No, it doesn't violate the spirit. HPLIP is FLOSS, including the
> hp-setup program itself. The binary blob is minor funcionality as far
> as HPLIP usage is concerned (although it isn't minor functionality for
> the unfortunate onwers of the subset of HP devices that require the
> binary blob to work).
>
> Now, if HPLIP was composed only of the hp-setup program, *and* hp-setup
> was only good for downloading/interfacing to the binary blob in the
> first place (as far as I recall, it does more than that), it would be
> "contrib" material (instead of Debian main material).
hp-plugin's sole purpose is to download and install the plugin but, by
the same argument, it still doesn't make hplip a candidate for contrib.
> That is not true, however. So, HPLIP belongs in Debian main. A package
> in main cannot build packages for contrib or non-free (and vice-versa),
> and it doesn't make sense to duplicate the entire HPLIP *source* package
> just to have a neutered-by-patching hp-setup utility in main, and a
> complete one in contrib.
>
> > it will result in installation of a proprietary blob? I just ran it as a
>
> Well, Debian is not in the business of neutering software to remove
> support for binary blobs[1]. There are Linux distros that cather for
> that market, though, such as Linux-Libre.
>
> [1] We don't distribute such blobs in Debian main, but software in main
> may make use of such blobs when available -- such as the Linux kernel.
> And while the blobs would go in non-free if their license permits that
> much, the software that downloads or uses it may go in contrib, non-free
> or even Debian main, depending a _lot_ on the specific details.
>
> > I've been pretty ill and not paying careful attention to the list for a long
> > time now. has this already been discussed? If so, didn't find any pertinent
> > threads.
>
> Yes, it was. Somewhat recently, too. I don't recall the thread,
> though.
It was sub-thread of another thread. Starts here:
https://lists.debian.org/debian-user/2016/10/msg01016.html
> > This seems to be a step backward in HP's technical support for open source
> > software. I'm disappointed.
>
> HP's printer division is nowadays very different from the one you might
> know from a decade ago. You might want to inform yourself better about
> their recent attempts at ink cartridge lockdown, for example.
>
> Basically, if an HP printer is not a high-end model that has a
> software-driver-less network port that can take PDF/1A directly using
> the IPP protocol natively, I wouldn't recommend it. If it does, I'd
> still recommend that you get yourself informed about its operational
> costs (ink/toner, replacement fusers and periodic maintenance kit) first
> -- but that is valid for any printer vendor.
>
> > So, does anyone know of a laser MFP (or a separate laser printer and
> > scanner) which I can hook up to my network (preferably wirelessly) and use
> > in Debian testing without violating my planned avoidance of proprietary
> > software and drivers?
>
> I'd like to know that, too. I need a new home color printer, my
> 10-year-old HP PhotoSmart (blobless) MFP has finally broken down and
> good second-hand parts are not easy to find in Brazil :-(
Why is it important for the printer to be blobless? Look at it this way:
A printer is choc-a-bloc full of firmware. None of this firmware is
accessible to a user, even if something like an interpreter is based on
an open standard such as PostScript. Indeed, there may be a rasteriser
which itself uses a proprietary format such as URF.
Suppose there are some bugs in the firmware; for example, the AirPrint
facility ceases to work reliably with an i-device. This has happened in
the past and the manufacturer provided a binary blob to fix it. What
would you do?
Ok, I'll tell you what I would do. I would get the blob and upload it to
the printer to bring it back to a working state. I would do the same for
a troublesome PDF rasteriser. I see no difference between doing that and
getting an hplip plugin to have the printer (or scanner) working at its
full potential.
--
Brian.
Reply to: