User: Password:
Subscribe / Log in / New account

The Ubuntu font and a fresh look at open font licensing

The Ubuntu font and a fresh look at open font licensing

Posted Oct 14, 2010 13:27 UTC (Thu) by yosch (guest, #4675)
In reply to: The Ubuntu font and a fresh look at open font licensing by pabs
Parent article: The Ubuntu font and a fresh look at open font licensing

Mmm, we've had conversations about this many times already. And the interim UFL or the attempts at fixing problems with the GPL font exception don't bring anything new to this particular issue. The OFL-FAQ ( explains the reasoning and practical working model for the OFL on this particular topic:

"5.9 Do font rebuilds require a name change? Do I have to change the name of the font when my packaging workflow includes a full rebuild from source?
Yes, all rebuilds which change the font data and the smart code are Modified Versions and the requirements of the OFL apply: you need to respect what the Author(s) have chosen in terms of Reserved Font Names. However if a package (or installer) is simply a wrapper or a compressed structure around the final font - leaving them intact on the inside - then no name change is required. Please get in touch with the author(s) and copyright holder(s) to inquire about the presence of font sources beyond the final font file(s) and the recommended build path. That build path may very well be non-trivial and hard to reproduce accurately by the maintainer. If a full font build path is made available by the upstream author(s) please be aware that any regressions and changes you may introduce when doing a rebuild for packaging purposes is your responsibility as a package maintainer since you are effectively creating a separate branch. You should make it very clear to your users that your rebuilt version is not the canonical one from upstream."

In short, if your resulting packaging changes the font and alters the rendering, why should users be confused when features, coverage, metrics, etc are missing or changed and bother upstream about bugs and regressions which you have introduced?

The fact is that the quality open fonts we now have in the distro archives are created with a build path we can't fully reproduce with unrestricted tools at this stage (or some kind of self-contained autobuilder). More precisely we can't fully rebuild to reach the same quality and feature parity than the upstream release. Sure anyone can make a crude makefile and churn something out from existing released sources but it's very unlikely to result in the same final fonts than what upstream produces so for the sake of the end-users and to respect the upstreams it shouldn't masquerade as the upstream trunk but clearly advertise itself as a branch via the renaming mechanism. That's what it's designed for. Obviously if a maintainer recreates a different buildpath from the upstream author then that means he/she is effectively committing to fully maintain a derivative version and not just the packaging. Only a tiny handful of open fonts currently provide a usable reproducable makefile integrated in the workflow of the upstream author(s). The usual software creation and maintainership practises don't apply directly to the specific methodologies of font software. We can easily see that distro maintainers don't have the manpower to fork and separately maintain all the quality open fonts currently in the distro archives. We need to be realistic about this situation. Right now we actually lack maintainers to properly get the various new open fonts into the distros as such. We should probably focus on that first.

If ambitious maintainers want to fully re-create a build path and take full responsibility for maintaining a dedicated autobuild system for their particular environment, then more power to them, but they need to realise that it probably takes more long-term effort than they are prepared to invest and they need to interact with upstream to see if that new level of automation can be properly added to their workflow. Carrying a big delta in the build system is definitely not easy. It boils down to respecting the upstream's creation, using their granted right to modify and branch without creating a huge namespace mess and creating problems with users's documents.

SIL script engineers are working hard to provide a common cross-platform build system that major open font projects will be able to reuse. These efforts take time and a lot of effort.

It would be a pity (a rather self-defeating approach really) to discard all the usable, distributable, modifiable, redistributable fonts we have managed to get released under FSF/OSI-validated font licenses over the past few years because not all designers are using fontforge on Debian/Ubuntu/Fedora as their preferred design environment.

Even big commissioning efforts like the Ubuntu font (I assume the costs are rather significant) don't provide fully automated rebuilds any maintainer can play with. Thankfully extended font sources have been released by DaltonMaag and there is definite interest in growing the open font design toolkit. That's already very good and promising for the future.

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds