On Sun, Dec 01, 2013 at 10:05:49AM +0100, David Herrmann wrote: > Hi > > On Sun, Dec 1, 2013 at 6:28 AM, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > On Wed, Nov 27, 2013 at 07:48:40PM +0100, David Herrmann wrote: > >> As a first step, we add the required header+build-chain and add the > >> font-handling. To avoid heavy font-pipelines in systemd, we only provide > >> a statically-sized fallback-font based on GNU-Unifont. > > Hi David, > > I don't think that GNU-Unifont is licensed in a way that allows it to > > be embedded in systemd. Systemd is LGPLv2+, while Unifont is GPLv2+ + > > FontException. > > FontException allows embedding in "documents", so it doesn't apply. > > I disagree. I'm allowed to embed GNU-Unifont in a pdf/postscript file, > right? However, postscript is as turing-complete as x86-assembler, so > I don't see the difference between an ELF-document and a > postscript-document. I don't think you can convincigly argue that either systemd-208.tar.gz or systemd-gfx are "documents". The *intent* of the FontException is pretty clear, and embedding in arbitrary programs is not it.
> > It would be possible have some sources which are GPLv2+ only, but I > > think we want to avoid such complications. > > It's not about sources. Assuming the font-exception doesn't apply, > this only means all binaries linking to libsystemd-gfx are GPLv2. The > sources stay LGPL as usual. It is also about sources. If you include unifont.hex in the systemd tarball, the distribution of the tarball also has to satisfy the license of unifont.hex. > > Also, if the font was embedded in systemd, distributions would then > > remove it in order to replace is with the system version. So I think > > that including the font sources is pointless... Debian has it packaged [1], > > but an old version, I'm not sure if there have been recent updates, and > > possibly in the wrong format. Fedora doesn't seem to have it yet. > > But adding fonts is easy, I'd do the Fedora package myself, and other > > distributions could surely add/update it. > > 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. There's no reason beside license issues. > > 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) With build-time linking the resulting binary is a derivative work of all sources. With mmap you can replace the font file by something different without any trouble, at least theoretically, so there's no derivative work and no license issue. > Also, where's the point of keeping libsystemd-gfx.so LGPL just to have > a *mandatory* dependency which is GPL? We can have dependencies which are GPL only, e.g. dbus. But we don't really care if you can use systemd without GPL-only stuff. The point is to maintain consistency between individual components and the declared LGPLv2+ license of the systemd tarball. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
