Re: Retiring lpr and lpd

On Sat, 21 Feb 2026 08:39:14 +0100
Tomek CEDRO <[email protected]> wrote:

> On Sat, Feb 21, 2026 at 6:42AM Tomoaki AOKI <[email protected]> wrote:
> > On Sat, 21 Feb 2026 04:47:55 +0100
> > Tomek CEDRO <[email protected]> wrote:
> > > On Sat, Feb 21, 2026 at 3:42AM Tomek CEDRO <[email protected]> wrote:
> > > > (..)
> > > > Would it be possible to move them to ports? Anyone using them would
> > > > still use but from ports :-) Or some working alternatives (plp seems
> > > > dead) maybe in ports already? :-)
> > >
> > > https://www.freshports.org/sysutils/LPRng seems to be replacement /
> > > alternative (note capital LPR).
> >
> > License: ART10 GPLv2
> >                ~~~~~
> >
> > And depends on GPL'ed things.
> > This would mean BSD compatibully licensed alternatives for GPL'ed
> > dependencies and GPL'ed part are needed to be in base.
> 
> Uh, like cups, maybe not a problem for users but definitely a problem
> for vendors.
> 
> Looks like a fix for *BSD lpd is needed to stay in base, or move to
> ports, or removal until someone can do the job?
> 
> Looks like a task for vendor who cares about lpr/lpd :-P
> 
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

If non-GPL'ed part alone works as drop-in replacement of current
lpr and friends in base and only filters and additional management
parts (which base lpr doesn't have) are GPL'ed, it would be OK with
dropping GPL'ed parts to merge into base.

But I've not digging into enough to determine it's possible or not.

Note that before I've switch to cups and stopped using lpr,
I've put ghostscript from ports as a filter to print to LIPS3
printer. Filter part is not a mandatory part to be equivalent
as current in-base lpr imprememtations.
So as additional management parts.

-- 
Tomoaki AOKI    <[email protected]>