If a font has Reserved Font Names (RFNs) then any change to the font normally disallows use of those names in Modified Versions - unless a separate RFN use agreement is formalized. However, there are good reasons why some changes to fonts to optimize them for web use might not be considered to create Modified Versions. These concepts and principles involved were discussed by designers and industry representatives in 2013, and the following application and interpretation was considered reasonable and fair to copyright holders.

The key concept in this discussion is Functional Equivalence (FE) - whether the resulting font preserves the completeness, behavior, quality and metadata of the original. There are also technical considerations related to the variety of webfont formats and their ability to accurately represent the original. Our position is that use of RFNs for webfonts could be allowable within the intent of the OFL, but only in very specific technical scenarios. Above all, font authors and copyright holders (referred to simply as ‘authors’ throughout this paper) must not feel that the RFN mechanism that protects them and their property is being diluted or abused.

Optimization Processes

In order to provide comprehensive and robust webfont services, webfont engineers and developers often choose to make changes to a font before hosting it. The intent is usually a combination of:

• Improving the breadth and quality of browser support, such as conversion to EOT to support legacy versions of Internet Explorer
• Refining tables and settings to match a higher technical standard, so that the fonts are more robust
• Adjusting font parameters and metadata to match other fonts hosted by the same service
• Reducing the size of the fonts to speed up loading
• Improving screen rendering, such as manual or algorithmic hinting
• Obfuscating metadata and other font details in order to make it more difficult to convert the font into something that could be installed on the desktop

They also prefer to host the fonts using the original names, so there is a clear correspondence between the desktop Original Versions and their optimized web versions.

These intentions are usually good, and improve the user’s experience with the font. However, some of these processes remove important parts of the font - glyphs, behavior, metadata - and so the font as delivered is a Modified Version. Some processes, such as obfuscation, even intentionally remove functionality and hide metadata solely to disable the font - which goes clearly against the spirit and intent of the OFL model.

A list of the common types and methods of optimization are in Appendix A - Processes, with an analysis of whether that process produces something that could reasonably be considered Functionally Equivalent to the Original Version, and within the intent of the OFL’s RFN mechanism.

Functional Equivalence (FE)

Although the OFL requires that Modified Versions must not use RFNs without separate permission, there is reasonable precedent for allowing something similar to modification - WOFF. After long discussion with many parties, that webfont format was deemed to be able to produce fonts that were reasonably representative of the Original Version. For the rest of this discussion WOFF refers to both WOFF and WOFF2 formats, as the two are not substantially different regarding these issues.

There are still restrictions on WOFF (OFL-FAQ 2.2):

• You are allowed to create, use and distribute a WOFF version of an OFL font without changing the font name, but only if:
  • the original font data remains unchanged except for WOFF compression, and
  • WOFF-specific metadata is either omitted altogether or present and includes, unaltered, the contents of all equivalent metadata in the original font.
• If the original font data or metadata is changed, or the WOFF-specific metadata is incomplete, the font must be considered a Modified Version, the OFL restrictions would apply and the name of the font must be changed…

These restrictions were put in place in order to preserve the identity and functionality of the font. If there is to be any allowance beyond this - even the smallest change - there needs to be some principle by which alterations are judged and evaluated, and an assessment made of whether an optimized font reasonably represents the Original Version.

The most useful principle seems to be Functional Equivalence (FE). An optimized font is deemed to be Functionally Equivalent (FE) to the Original Version if it:

• Supports the same full character inventory. If a character can be properly displayed using the Original Version, then that same character, encoded correctly on a webpage, will display properly.
• Provides the same smart font behavior. Any dynamic shaping behavior that works with the Original Version should work when optimized, unless the browser or environment does not support it. There does not need to be guaranteed support in the client, but there should be no forced degradation of smart font or shaping behavior, such as the removal or obfuscation of OpenType, AAT or Graphite tables.
• Presents text with no obvious degradation in visual quality. The lettershapes should be equally (or more) readable, within limits of the rendering platform.
• Preserves original author, project and license metadata. At a minimum, this should include:
  • Copyright and authorship
  • The license as stated in the Original Version, whether that is the full text of the OFL or a link to the web version
  • Any RFN declarations
  • Information already present in the font or documentation that points back to the Original Version, such as a link to the project or author website

If an optimized font meets these requirements, and so is considered to be FE, then it’s very likely that the original author would feel that the optimized font is a good and reasonable equivalent, and that the main purposes of the RFN mechanism - avoids collisions, protects authors. minimizes support, encourages derivatives - continue to be met.

If it falls short of any of these requirements, the optimized font does not reasonably represent the Original, and so should be considered to be a Modified Version. Like other Modified Versions, it would not be allowed to use any RFNs.

Font Format Limitations

Despite very careful and well-intentioned optimization processes, some font formats have basic limitations with regard to their ability to provide FE. Does the format by its very nature make functional equivalence impossible? If so, then it will not be possible to provide that format in a way that adequately represents the Original, and so normal RFN rules with regard to Modified Versions would apply.

Here are most of the font formats that webfonts services want to provide, with comments on how possible it is to provide FE using that format.

TTF/OTF

This is typically the format of the Original Version, and can contain all the necessary glyph data, smart rendering code and metadata. FE can be preserved using this format.

WOFF & WOFF2

This format wraps up the original font in a layer of metadata, and the result is compressed. It has already been shown that FE can be preserved using this format.

EOT/EOTLite

EOT was one of the earliest webfont formats and did not initially support all of what is needed to preserve FE. However, more recent changes in both the format and supporting development tools may provide what is needed. Deeper technical analysis of this is needed before a judgment can be made about this format.

SVG

This format is an application of the broad and powerful SVG language to draw lettershapes. It was the only format supported in early versions of the iOS platform, and so gained some popularity. However since iOS 4.2 the SVG format has not been the only option, and major webfont services (TypeKit, for example) have discontinued support. SVG also has some considerable limitations in its ability to render text with reasonable quality, and supply all needed metadata. It also does not support any shaping behavior. As far as we can tell, it is not possible to preserve FE with this format, and so conversion to SVG needs to be considered a Modified Version for which RFN restrictions apply.

SVG2/SVGOpenType

These enhancements to the SVG format seem to promise better potential to preserve FE, however they are still in flux and so no judgment can be made. Deeper technical analysis of this is needed before a judgment can be made about these formats.

Flash and Javascript

There are a number of flash-based and/or javascript-based techniques intended to deliver text rendered using custom fonts onto a webpage. These might be regarded as delivery of graphics rendered using fonts rather than delivery of optimized fonts, and so would fall out of scope of the OFL. All of these are now deprecated anyway, so we feel that use of such techniques either falls out of scope or does not meet requirements for preserving FE.

Subsetting

One of the major optimization processes, supported by some webfont formats, is subsetting. This can give very substantial speed optimization, and involves removing parts of a font to make it smaller and/or more efficient. Usually this also removes functionality by:

• Removing glyphs, usually by limiting the character set support to a predefined range
• Removing smart font code (OpenType, Graphite, AAT) that may be useless on a particular browser platform, or simply to reduce font size
• Modifying - or eliminating altogether - smart font code to remove support for certain features or characters

Can subsetting be used in such a way as to preserve FE? Possibly, however the technology for this is not yet mature. Subsetting is not a single technology or process. There are four major types of subsetting, only two of which might be able to preserve FE:

Pre-subsetting

This technique prepares subset fonts according to preset specifications, such as Unicode range support, which are then separately made available. There are two techniques for serving these fonts:

• As fully separate, differently-named fonts, such as “Foo ExtLatin”, “Foo ExtCyrillic”, “Foo Armenian” or “Foo IPA”. Such premade subsets may even be part of the Original Version package. As virtually separate fonts, which are specified using parameters in CSS such as “subset=latin-ext”. These are also premade, but delivered as subsets of a single named font.

In both cases the fonts are subset prior to being made available from a server. Because these subsets do not deliver complete functionality, and complete character set support in particular, it is not possible to preserve FE, and so pre-subsetting needs to be considered a Modified Version for which RFN restrictions apply.

Parameterized Subsetting

This technique allows the CSS author to specify specific subset parameters to the webfont service, which then assembles and delivers a customized subset on-the-fly. For example, the CSS might include an option to specify which characters are needed, as in “text=abcde”. This allows for highly optimized delivery. The end result from an RFN perspective is no different than pre-subsetting, even though the delivery mechanism is different. Unless the user specifies the whole character set explicitly - which defeats the purpose of subsetting - FE is not preserved, so pre-subsetting needs to be considered a Modified Version for which RFN restrictions apply.

Dynamic Subsetting

This technique was initially developed for CJK uses, but can be applied more broadly. A script inspects the content of the page, then requests a subset of the font containing only the glyphs required for rendering.

This could effectively provide full character set support, as any glyphs supported in the Original Version could be made available as needed. This is different from Parameterized Subsetting in that the characters would not need to be pre-specified in the CSS. If the dynamic subset were also to provide smart rendering equivalent to the Original Version, include necessary metadata, and provide access to the corresponding Original Version, then this technique might be able to preserve FE.

Dynamic Subsetting with Progressive Client Storage

This is a step further than pure Dynamic Subsetting, and involves storing the results of each individual page’s font request in persistent client storage. The font is then slowly built up on the client machine, allowing for improved performance and reduced payload over time. As with Dynamic Subsetting alone, the specific implementation will determine whether all the requirements for FE are met, but FE may be possible with this technique.

Is It Embedding?

An alternative way of looking at webfonts sees it as only another method of ’embedding’ the font in a document, like is done with PDFs. The OFL-FAQ defines embedding as "…inclusion of the font in a document or file in a way that makes extraction (and redistribution) difficult or clearly discouraged. In many cases the names of embedded fonts might also not be obvious to those reading the document, the font data format might be altered, and only a subset of the font - only the glyphs required for the text - might be included." (OFL-FAQ 1.11) When the modification of the font is clearly only part of the embedding process - such as in a PDF - RFNs are allowed.

So can webfonts be interpreted as embedding? There may even be similar technical processes as are used for PDFs - removing glyphs that are not needed, changing the font format itself, leaving out metadata.

However, there a few ways in which webfont mechanisms differ from traditional embedding:

• Webfonts are normally more complete than document-specific subsets as is common with PDFs (except in the case of Dynamic Subsetting).
• The same webfont can be used by many pages, whereas embedded fonts are integrated into each individual document.
• Most webfonts are not even delivered from the same server as the HTML/CSS, and one font may be served to thousands of pages.
• Webfonts remain separate resources or files, loaded separately from the HTML pages.
• The potential ease by which the general public could download and convert some webfonts into something usable on the desktop has led companies to go to great lengths to obfuscate some webfonts.
• The developer tools which come built-in with the major browsers like Firefox, Chrome or Edge have a Fonts panel where you can see all the details of the webfonts being used and access all the corresponding downloadable files.
• Unlike some PDFs, for example, the content of a webpage is normally still present and readable to the user even if the font is not working.

The main points here are that webfonts are not an integrated part of the document itself, and despite vendor efforts to minimise conversion of webfonts for desktop use such efforts will likely remain desirable, especially for OFL-licensed fonts. There is little reason to discourage this for OFL fonts and some authors may want to encourage it.

In conclusion, webfonts cannot be considered a simple alternative form of document embedding.

Conclusions

Webfont services and developers have four options when wishing to host OFL-licensed fonts using RFNs:

• Host the Original Version without any changes at all. Some authors (including SIL) are now providing web versions of their fonts as part of their normal OFL distribution packages.
• Convince the author to re-license the font without RFNs. This is a valid strategy, but not one we recommend.
• Modify the fonts but sign a separate agreement to allow the use of RFNs. This should be the most common default strategy.
• Optimize the fonts, but do so being very careful to change the fonts only in ways that fully preserve FE, and limit the delivery formats to only those that clearly allow for FE (TTF, OTF, WOFF and WOFF2). This is technically difficult, but possible. However, it may be less effort to sign RFN use agreements with authors.

Any other strategy that modifies fonts for web use, yet uses RFNs, violates the terms of the OFL.

Bottom line: To create a robust, comprehensive and technically optimal webfont service for OFL fonts, the most practical strategy is to sign agreements with authors to allow use of RFNs. While it’s technically and legally possible to avoid separate agreements with very careful engineering, the result is likely to not support all browser environments, nor give users an optimal experience.

Appendix A - Processes

The following list of webfont optimization process is based on information from a variety of webfont services. Each type of optimization is evaluated to determine whether that optimization could be used to preserve FE. Note that this does not give blanket approval for any particular change - it only says that that optimization could potentially be used while still preserving FE - not that use of the technique guarantees FE.

We also recommend that webfont services make their optimization processes open and transparent to authors (such as in a Git repository) so that some optimizations can be reflected in the Original Versions rather than in separate later processes, and others tracked and reviewed.

Glyph subsetting

This is covered in a separate section, above.

Conversion to other font formats

See section on formats, above.

Disabling use on desktop, or conversion for that purpose

This usually involves obfuscation or removal of metadata or name table entries, so that if the font were to be successfully converted to a desktop format it would not work properly. While this may be a valid and necessary technical response to unauthorized use of commercially licensed fonts, it is unnecessary and unhelpful for OFL-licensed fonts. User conversion and desktop use of OFL fonts is fully allowed and encouraged by the license, so to intentionally disable it goes against the spirit and purpose of the OFL. The modifications necessary also likely do not meet the basic requirements for FE - preserving metadata and functionality - so disabling conversion for desktop use needs to be considered a Modified Version for which RFN restrictions apply.

Removing or replacing metadata

Metadata is sometimes removed, abbreviated or replaced. The main argument for this is performance - to make the font as small as possible. This argument is weak, as the metadata - even the OFL itself - is not large and contributes a tiny amount to the size of a font. For OFL fonts, it is very important that all metadata remain intact and travel along with the font when distributed.

Some examples of metadata changes:

• Removing license description and/or RFN declarations - not allowed at all, as this goes against the terms of the OFL
• Replacing the license description with a link to the full license text - does not meet requirements for FE
• Removing font identification information - not FE as it would misrepresent the font to users, such as those using tools to inspect fonts in use
• Obfuscating metadata to hide identification information or to disable conversion for desktop use (discussed earlier)

One argument for allowing metadata removal is that license and identification information can be clearly made visible in the webfont delivery process. However, that only affects designers - those specifying the font - not readers who wish to identify the font in use. It also does not provide the information to secondary users, as in the case of fonts specified in WordPress templates.

Removal, abbreviation or replacement of metadata may be in violation of the terms of the OFL, and even when OFL terms are met, the font would not meet the requirements for FE, so the font would need to be considered a Modified Version for which RFN restrictions apply.

Removal of smart font routines

Smart font routines used in rendering and shaping, such as OpenType, Graphite or AAT code are often removed as they can contribute significantly to the size of the font. This was most common when the smart font code would be useless on the particular delivery platform, for example, AAT code being delivered to Internet Explorer. When this is true, removing the smart font routines does not effectively remove any functionality or reduce quality, and instead provides an improved user experience, so FE can be preserved using this process.

Two important considerations, however:

• Smart font code should not be removed if there is any chance of it being used. For example, recent versions of Firefox support Graphite technology, so stripping Graphite code from a font when delivering to Firefox would not be FE.
• Preserving FE requires preserving any metadata that points back to where the complete Original Version may be obtained.

Changing font default settings

It may be useful to change a font’s default settings for smart font features, or remap characters to different glyphs. In all cases those are significant changes that could not be said to represent the Original Version, would not be considered FE, and would need to be considered a Modified Version for which RFN restrictions apply.

Hinting

Webfont services sometimes replace the hinting present in a font for particular delivery platforms, or add hinting to an unhinted font. The intent in most cases is to improve screen rendering, so is something that some font authors may appreciate. However, hinting can significantly alter the appearance and character of a font, and what some people would consider an improvement others might consider a loss of character. Since responses to these changes are so subjective, it is impossible to guarantee that the font meets the requirements of FE. While in most cases hinting would meet the quality requirement for FE, there is no way to guarantee it, so hinting or rehinting would generally need to be considered a Modified Version for which RFN restrictions apply.

Outline optimizations

Changes to glyph outlines - and simplification in particular - can also reduce font size, especially for complex display fonts. However evaluation of these changes is quite subjective, as with hinting, and so outline changes would generally need to be considered a Modified Version for which RFN restrictions apply.

Table optimizations

Some font development tools produce fonts containing suboptimal table sizes and formats, and internal optimization of those tables can produce faster and more robust fonts. These internal table optimizations may preserve FE, but should be tested carefully to be sure there are no unintended effects.

Minor fixes

Other minor fixes, such as changing OS/2 table bits, Unicode range settings, tiny fixes to name table entries, setting monospace and italic bits are often improvements that make the font work better in a broader range of environments. Authors would generally consider these changes to be ‘friendly’ as long as they preserve FE and are truly minor fixes (not major changes). Ideally, such changes ought to be submitted to the author to be changed in the Original Version, not fixed in a later webfont delivery process. However, even small, minor changes can have very significant effects which alter the font’s function. These type of changes can sometimes be done while still preserving FE, but great care must be taken to ensure that FE is preserved.

Last updated on 24 January 2024