The Open Font License and Reserved Font Names

The SIL Open Font License (OFL) is the dominant software license in the open font community, for a variety of reasons—including the fact that it was written specifically to meet the needs of type designers, as opposed to being an adaptation of another license. But one of its most controversial clauses has long been the Reserved Font Name (RFN) clause, an option that allows the licensor to require any derivatives of the licensed font be renamed. To some, RFNs are an essential tool necessary to cope with the peculiarities of digital fonts, but to others, they are a non-free relic that causes multiple practical problems. Recently, the OFL's authors asked for comments on an update to the official license FAQ, which spawned the latest debate on whether RFNs are ultimately beneficial or harmful in the context of free software, and, if they are harmful, how best to resolve the problem.

The OFL was written by Nicolas Spalinger and Victor Gaultney at SIL International, and specifically attempts to adhere to the Free Software Foundation (FSF)'s definition of free software, the Open Source Definition (OSD), and the Debian Free Software Guidelines. In general, it grants the licensee the right to use, copy, modify, and redistribute the licensed font, with the expected requirements on preserving the copyright notice and not changing the license terms when redistributing.

But it does contain some clauses that are atypical among free software licenses. For one, it requires that the font not be sold as a standalone offering. The FSF highlights this as "unusual", but harmless, since even the inclusion of a simple "Hello world" script satisfies the requirement. The RFN requirement is more strict, requiring a new name to be assigned for any modification, not just for formal or ongoing forks:

Any RFNs claimed by the designer must be specified as such in the copyright statement placed at the beginning of the license. SIL's FAQ goes into additional detail about RFNs, noting that transforming the font into a different format normally does constitute creating a modified version, and that giving a modified version a name that incorporates the RFN (such as Foo Sans or Foo Remade, in reference to an RFN Foo) is not permitted. It even notes that rebuilding the font from source counts as creating a modified version (thus triggering the need for a rename) if the rebuild produces a final version that is not identical to the font as released by the designer.

Nevertheless, a type designer is not required to specify any RFNs when releasing a font under the OFL. SIL encourages type designers to use RFNs, however, citing four reasons in a paper entitled "Web Fonts and Reserved Font Names." First, the paper says, RFNs help to avoid confusing name collisions when a user has both the original and a modified version of a font installed (particularly in application "Font" menus, which offer limited space for displaying font names). Second, they help "protect" the designer from dilution concerns—i.e., broken or inferior derivatives of the font being presented to users with the same name. The third reason is a corollary; sparing the designer of the original font from responding to support requests that actually stem from bugs in a modified version. Finally, an RFN requirement "encourages derivatives" by forcing modifiers to consciously choose a new, distinct name for their derivative fonts.

This paper is a draft, currently posted for public comment. Gaultney emailed the Open Font Library mailing list in May to ask for feedback on the paper, and on a new revision to the OFL FAQ, which adds new questions about deploying OFL fonts in mobile or embedded devices and about bundling OFL fonts in web templates.

Reservations

The historical justification for the RFN clause is that the font name is one of type designers' few ways to distinguish their work from that of the competition (after all, however much metadata may exist in the actual file, an application's "Font" menu still presents the name alone). Requiring derivative works to use a different name is not unheard of in free software (the OSD permits it), but it is rare; as Khaled Hosny pointed out, the LaTeX license also requires renaming. But some in the open font world say that the RFN clause poses an unreasonable burden in practice, especially when seen in light of HTTP-delivered web fonts.

After all, the clause requires explicit written permission from the original designer in order to release a modification that reuses the RFN, and the designer may be difficult or impossible to contact (e.g., a designer who has subsequently passed away). Moreover, the standard for what constitutes a modified version of a font is extremely low; as SIL's draft paper explains in detail, even common practices like subsetting (stripping out unused characters) or optimizing the font for delivery are considered modifications. This standard is certainly lower than the clauses found in most other free software licenses; it is hard to imagine any license requirement being triggered by rebuilding the software from source.

In fact, since optimizing a font for delivery in a web page is considered creating a modified version, then every web server that hosts an OFL font with RFNs must rename its copy of the font or else get prior written permission from the original designer to serve it as-is. Neither choice is particularly appealing; as Dave Crossland said in the thread "it's unreasonable to expect every person publishing a blog who makes their own subset to contact every copyright holder every time they want to use a new OFL-RFN web font." For a popular font, that could quickly add up to tens of thousands of requests. Alternatively, those tens of thousands of servers will deliver the font under a score of other names, and that might not hurt the designer's reputation, but it does little to improve it.

Plan B

To some open font designers, specifying an RFN simply is not worth it, and they attach no RFNs to their fonts. Barry Schwartz argued that it is too much trouble, and the benefits too small; the majority of the free software world managed to cope with the potential of name collisions and misdirected support requests just fine:

But other designers are interested in maintaining the "brand" established by their OFL fonts. Without assigning an RFN, the question remains whether such brand protection is possible. In the email cited above, Crossland advocated using trademarks to protect font names. Trademarks offer similar protections of the font name, and it is a common practice in free software to publish trademark usage guidelines that spell out acceptable uses without requiring prior permission. He pointed to the Subversion project's guidelines, although there are plenty of examples.

Of course, a trademark approach has its problems. How trademarks work varies from jurisdiction to jurisdiction (and may even involve registration fees). Is it also common for a trademark infringement claim to be weakened or denied if the trademark holder demonstrably allows other infringement. Vernon Adams proposed an alternative solution; writing a "preemptive permission" statement to accompany the OFL, which grants permission to modify an RFN font in specific ways—in particular, an "engineering exception" listing the common modifications made when deploying a web font.

Crossland replied that SIL is unlikely to compose such a boilerplate exception, since it would dilute the OFL. Gaultney concurred, adding that writing such an exception would also involve "the basic conceptual difficulty of defining and evaluating what changes would be allowed." Adams, however, disagreed about the notion of diluting the OFL:

It could be a while before there is any resolution to the debate over RFNs. SIL has certainly not expressed an interest in revising the license, which it sees as meeting the desired goals. Both an RFN "engineering exception" permission grant and a trademark usage policy would require careful thinking and writing before deployment. Expecting each type designer to write their own policy is unlikely to bear fruit, but as this debate illustrates, the open font community clearly has many more issues to discuss before it could produce any general consensus on a suite of options. In the meantime, the rest of the free software community might find the discussion informative; as we saw in XBMC's case, trademarks and name collisions can affect software of any stripe.