Older blog entries for yosch (starting at number 150)

10 May 2014 (updated 10 May 2014 at 19:46 UTC) »
open fonts vs. DRM-ized online services and desktop distribution channels

The various online webfonts services which now also include open fonts (like fonts under OFL) to bring added value to their existing libraries have a strong tendency to hide the authorship and licensing information as well as put up some DRM walls to make it harder to actually exercize your freedoms or using, distributing, modifying and redistributing these fonts.

The reality is that they have simply dropped open fonts into their proprietary DRM-ized workflows and not done enough due diligence or given enough respect to these authors' copyright, despite all the fancy PR and promises.

If font authors have released their work under a FSF/OSI/community-recognized copyright license then no overarching EULA or subscription agreement can prevent users (and fellow designers) from extracting these open fonts and using them accordingly. And when these online webfont hosting services start providing rich clients to connect into their libraries directly from desktops apps, the DRM scenarios are even worse: they tend not to install them in your font folder directly but into an intermediary hidden folder that you are not supposed to know about or have much control over so they can turn access to the fonts on and off as they wish.

You can understand their desire to lock up the proprietary fonts but they can't do that to the open fonts available through the same channels: in the owning versus renting dichotomy, open fonts are firmly in the camp of owning and even better being able to make it your own and redistribute the modified version. The rights granted to you by any author releasing their creation under an open license doesn't disappear when the software channel is turned off or your subscription is invalid. The whole point of releasing a font under an open license is that it's not under exclusive control any longer and the relationship between the font author(s) and the font user(s) is more direct.

The OFL FAQ is quite clear on this:

1.17 Can Font Software released under the OFL be subject to URL-based access restrictions methods or DRM (Digital Rights Management) mechanisms?

Yes, but these issues are out-of-scope for the OFL. The license itself neither encourages their use nor prohibits them since such mechanisms are not implemented in the components of the Font Software but through external software. Such restrictions are put in place for many different purposes corresponding to various usage scenarios. One common example is to limit potentially dangerous cross-site scripting attacks. However, in the spirit of libre/open fonts and unrestricted writing systems, we strongly encourage open sharing and reuse of OFL fonts, and the establishment of an environment where such restrictions are unnecessary. Note that whether you wish to use such mechanisms or you prefer not to, you must still abide by the rules set forth by the OFL when using fonts released by their authors under this license. Derivative fonts must be licensed under the OFL, even if they are part of a service for which you charge fees and/or for which access to source code is restricted. You may not sell the fonts on their own - they must be part of a larger software package, bundle or subscription plan. For example, even if the OFL font is distributed in a software package or via an online service using a DRM mechanism, the user would still have the right to extract that font, use, study, modify and redistribute it under the OFL.

1.23 Can OFL fonts be included in services that deliver fonts to the desktop from remote repositories? Even if they contain both OFL and non-OFL fonts?

Yes. Some foundries have set up services to deliver fonts to subscribers directly to desktops from their online repositories; similarly, plugins are available to preview and use fonts directly in your design tool or publishing suite. These services may mix open and restricted fonts in the same channel, however they should make a clear distinction between them to users. These services should also not hinder users (such as through DRM or obfuscation mechanisms) from extracting and using the OFL fonts in other environments, or continuing to use OFL fonts after subscription terms have ended, as those uses are specifically allowed by the OFL.

1.24 Can services that provide or distribute OFL fonts restrict my use of them?

No. The terms of use of such services cannot replace or restrict the terms of the OFL, as that would be the same as distributing the fonts under a different license, which is not allowed. You are still entitled to use, modify and redistribute them as the original authors have intended outside of the sole control of that particular distribution channel. Note, however, that the fonts provided by these services may differ from the Original Versions.


Practically, users of Skyfonts with the Google fonts service can simply go to ~/Library/Application Support/skyfonts-google/ on OSX (or C:\Users\%username%\AppData\Roaming\skyfont-google\ on Windows) and retrieve the open fonts they have synchronised.

Similarly users of Creative Cloud with Typekit desktop can go to ~/Library/Application Support/Adobe/CoreSync/plugins/livetype/.r/ on OSX (or C:\Users\%username%\AppData\Roaming\CoreSync\plugins\livetype\r on Windows) and retrieve the open fonts they have synchronised. Note the .r hidden folder and the . in front of the various fonts to hide them. You have to reveal hidden files to be able to see them.

Notice the difference between the two: Skyfonts isn't hiding their dedicated folder any longer and newer versions of the desktop client even provide a menu entry "Reveal in Finder", Typekit Desktop still hides fonts and gives them an arbitrary numerical filename.

Of course, users should always double-check the metadata inside a font to make sure they are not retrieving a restricted proprietary font by mistake but an open font. Various tools are available to expose the font properties. Or just open them in FontForge and go to Element -> Font Info.

Surely it would be simple for them not to apply these DRM measures to any open fonts in their catalogues and keep them in a dedicated separate folder which has no need to be hidden and could just be in the normal user font folder? Or is it because, despite all the noise about open fonts being so horribly dreadful, lots of people are finding them good and useful and they actually continue to draw in subscribers for the proprietary fonts?

Sorry but you can't have the flexibility of taking advantage of open fonts without properly propagating the rights attached to them by their original authors. OK, it's a pretty weak DRM that can be worked around but it's still something that goes against the wishes of original authors and the general spirit of open fonts. If you want complete control and exclusivity then pay the authors the corresponding price and don't just leech off their open fonts without keeping them open. So, please drop that obfuscation trick and give these fonts the place they deserve in your font catalogues. Everybody will benefit.




29 Oct 2013 (updated 29 Oct 2013 at 18:57 UTC) »
Wiki[p|m]edia doesn't like tofu and takes action

No, not that kind of tofu, which is quite delicious actually, but the much less tastier electronic equivalent: empty squares that show up in your digital content when you don't have access to the proper font, which usually leaves you with a bitter taste, especially if it's your own native script and you can't use it.

It's very good to see Wiki[p|m]edia joining others (like Google and Monotype's Noto for example: Noto as in no tofu, see what they did there?) looking into tackling these limitations on the web with their minimal but still quite ambitious Autonym font project.

And I find the font name quite clever too: autonyms (sometimes also called endonyms) are how speakers of a particular language itself call it and also write it ideally: see ScriptSource's list of languages with alternate names.

I suspect it will a huge help in driving home the problems many people still face with not having access to a high-quality open font as a reference implementation of their script but ending up with infamous electronic tofu instead. Starting with getting the name itself right is a great stepping stone.

Go Wiki[m|p]edia!
Update to the OFL FAQ published: version 1.1-update3

Don't miss the newly updated OFL FAQ version 1-1-update3. It may well have the answers you're looking for on the - rather rich and complex - topic of using, distributing and creating open fonts with practical tips and examples.

It takes into account feedback from a wider variety of users of open fonts as well as significant issues within the type design community, like, among other things, delivering optimized webfonts.
Fuentes libres en Madrid, España

Plenty of libre/open font-related sessions on the program at this year's LGM in Madrid...
8 Feb 2013 (updated 9 Feb 2013 at 22:11 UTC) »
New open fonts shipping with LibreOffice 4.0

Interesting to see that LibreOffice 4.0 increases the number of open fonts bundled by default: the release notes mention - among quite a few other nifty new features - that Open Sans by Ascender, PT Serif by ParaType, Source Code Pro and Source Sans Pro by Adobe join the existing Dejavu, Liberation, Gentium and Libertine font families that LibreOffice users can enjoy without having to go through any installation steps.

More quality entries in your font menu :-D

Of course this font repository integration idea sounds very good too!


Some promising aspects of Source Sans Pro, Adobe's recently published open font

So, it looks like Adobe's recent decision to release Source Sans Pro as an open font under the OFL has been well-received in various parts of the interwebs.

I'd like to add big congrats to Paul D Hunt, Ken Lunde, Robert Slimbach, Miguel Souza and Ernie March (and as few others at Adobe I imagine) as well for going open with all this work. May they reap many benefits for this move.

Besides the design quality and the unusual fact that Adobe-affiliated designers and font engineers are directly involved, I think there are some very promising aspects worth pointing out: Source Sans comes with an AFDKO buildpath and the corresponding full set of source files, various smart behaviours (via OpenType), initial focus on supporting languages using extended latin (like Vietnamese and Navajo) and tentative plans for newer writings systems in the published roadmap in which they invite outside participation to the project.

Seeing the authors interact and reply to community input directly in the blog discussion thread is quite promising too: making adjustments to the zip structure of the release, explaining how people can make their own branch if they want, promising more technical documentation on the buildpath, exploring the use of a DVCS and possibly fontforge, etc. IMHO it shows a great willingness to think and act beyond a simple code drop by looking at ongoing maintainership. Many miles ahead compared to somewhat similar open font releases by corporations I've been able to observe previously. Well-done.

I'm looking forward to the Monospace version in the pipeline...

Maybe Adobe will even consider making the AFDKO toolkit more open in the future? There were queries about releasing AFDKO more openly earlier (the python scripts themselves are already under the MIT license)...


28 Nov 2011 (updated 28 Nov 2011 at 18:42 UTC) »
Updating FontForge's localization into French

A few weeks ago, as part of a booksprint on libre/open fonts, some of us started to update the French translation of FontForge, the libre software font editor. Fontforge uses GNU gettext and the UI translation documentation outlines the methodology for getting the messages updated and tested.

This was driven by the need to make the terminology coherent and to illustrate various chapters with screenshots in French for Fontes Libres a book written in French on libre/open fonts and related topics. This book effort has been made possible thanks to FLOSS Manuals fr and the financial support of Organisation Internationale de la Francophonie.

We built upon the previous translation work done by Pierre Hanser and Yannis Haralambous. Interestingly enough, much of the needed translation of po/fr.po was done and tested using gobby in a hotel lobby over a wireless network. There are much better workflows out there but this ad-hoc method was helpful.

There is still a lot left to translate but things are on their way and I hope this can get finished soon and submitted for inclusion upstream.

One more way the wider community will benefit from this booksprint !
3 Nov 2011 (updated 3 Nov 2011 at 09:44 UTC) »
FLOSS Manuals booksprint on libre/open fonts

Thanks to the efforts of the FLOSS Manuals francophone team: namely Elisa Godoy de Castro Guerra and Cédric Gémy, a bunch of us with some knowledge and experience of libre/open fonts are getting together for a few days to do a booksprint on the topic (with the necessary funding provided by OIF).

It should be really interesting to use agile methods to work together on a book to explore this very rich and diverse subject.

A great opportunity for me to discuss and write up in a more structured way thoughts and corresponding best practises on the key issues from the various talks given at FLOSS conferences these past few years. They have been sitting idle on my hard drive for too long...

The resulting book written in French will be released under a libre license and join a growing collection of books (manuals) in various languages such as: Français, English, Suomi, Nederlands and فارسی Farsi .

Looking forward to meeting the other authors and to the whole collaborative writing experience!
Sent from my $DEVICE

Certain mobile devices add their marketing signature by default to outgoing emails. I find this virtual positional goods statement rather annoying, even if unintentionally left as the default configuration. It feels like posturing as well as showing you're unable to configure your device to personalize your own signature and remove corporate ads.

Is the content of your email not discredited by affirming that a $DEVICE is yours, all yours? Does this trigger to compare $DEVICE against $DEVICE bring anything at all? Are you a peon in the platform wars? Especially since I already know what platform and email system you use and can react accordingly?

The best potential comebacks range from sarcastic to constructive:
  • “Sent from my subterranean luxury bunker.”
  • “Sent from my $DEVICE… while eating caviar… on a yacht.”
  • “Sent from my re-flashed toaster.”
  • “Sent from my microwave oven.”
  • “Sent from YOUR $DEVICE.”
  • “Sent through OUR shared interwebs.”


19 Oct 2011 (updated 19 Oct 2011 at 22:28 UTC) »
A look at the fonts in Android 4.0 Ice Cream Sandwich: Roboto and Droid


Plenty of news sources have picked up on today's Android Ice Cream Sandwich SDK release (AFAICT no sign of full source release yet) and among all the various nifty features in this version there's Roboto (Regular|Italic|Bold|BoldItalic) a new font developped in-house, IOW not commissioned via an external foundry. Apparently Christian Robertson is the designer. He is also credited as the author of the AndroidClock font for version 3.1. It looks like an original design (with smallcaps included).

But unfortunately there's no license in the metadata but only the very basic copyright and trademark statement...

IMHO all the smart folks in the Android team should know better than distributing something without any indication of actual licensing, you know it's going to go around the intertubes very fast: just a few hours after the release, plenty of sites offer a download of standalone files which may or may not be a version of Roboto. It's out in the wild but nobody knows exactly if and how you can actually use it, branch from it, etc...

The rather misguided "font data copyright" is still there although fonts are software, the fsType embedding restrictions are set to Preview & Print embedding which will limit various use scenarios of the font, there's nothing in the description field, no upstream URLs and no FONTLOG inside or outside the font. Could do better I guess.

Also in the new SDK I can see that the Droid font family has been expanded with support for Armenian, Ethiopic and Georgian. Great news for users of these writing systems in Android! The Droid fonts now explicitly indicate in the metadata that they are licensed under Apache 2.0 (which wasn't always the case but was thankfully fixed) but today they still have the fsType embedding bits set to Editable embedding which also limits various uses of the fonts. At some point they were potentially going to be available under the OFL as well but apparently this has been put on hold.

So here's to hoping that in upcoming versions the Android team will indicate licensing intent more clearly, fill in the useful metadata fields and fix the embedding buglets in these fonts. Android users and people who may want to use these fonts elsewhere thank you in advance.


141 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!