On Wed, Dec 11, 2013 at 1:56 AM, Lennart Poettering <lenn...@poettering.net> wrote: > On Sun, 01.12.13 10:05, David Herrmann (dh.herrm...@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. Storing it on disk and mmap()ing it from multiple different binaries would be a fine alternative then, I think. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
