[systemd-devel] [RFC 05/12] gfx: add sd-gfx library with unifont section

[Lennart Poettering]

On Wed, 11.12.13 02:14, Kay Sievers (kay at vrfy.org) wrote:

> 
> On Wed, Dec 11, 2013 at 1:56 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Sun, 01.12.13 10:05, David Herrmann (dh.herrmann at gmail.com) wrote:
> >
> >> I'm fine with installing the file into the system, but I doubt we win
> >> much. It's meant as fallback for early-boot, initrd and so on. If we
> >> keep it separate, we must make sure to include it in any systems we
> >> build (initrd, containers, vms, ..). So if there's no reason beside
> >> license issues, I'd like to keep it built-in.
> >>
> >> > So if it is acceptable for systemd-gfx *binary* to be GPLv2+ licensed,
> >> > we could use the system unifont.hex file at build time, and actually
> >> > link it into the binary. I propose that we try to go this way.
> >>
> >> That's what I currently do.
> >>
> >> > Or we could have the package also contain the converted font in appropriate
> >> > format, and mmap it at runtime. But this is more complex, and doesn't actually
> >> > avoid the licensing issue, since the font would still be GPLv2+.
> >>
> >> Where is the difference between build-time linking and mmap()?
> >> (regarding licensing)
> >> Also, where's the point of keeping libsystemd-gfx.so LGPL just to have
> >> a *mandatory* dependency which is GPL?
> >
> > I think embedding the thing into our binary in question is the best
> > choice here. I don't see any license problems, and it's certainly the
> > fastest and most robust thing to do...
> 
> It is huge, ~2MB. We need to be sure that we will never have 2
> different processes carrying it, it would be a waste of memory.

That's a very good point. Given that we link everything in systemd
statically so far, then this is a strong point to store in an external
mmapable binary file if this is used by more than one process...

Lennart

-- 
Lennart Poettering, Red Hat