By popular demand: this is the english version of my earlier blog post.
It all started mid November at the WP Meetup Würzburg. Topic for that evening was all about cookie banners. And related to this any other questions around privacy policy and GDPR. One attendee pointed to the issue of google fonts which have to be hosted locally to be GDPR compliant, but on the other hand the SIL OFL (Open Font License) would prohibit the conversion into WOFF and WOFF2. Which would mean the choice between either being GDPR- or license compliant. I got curious … but let me start from the beginning:
Google Fonts und GDPR (SIL OFL yet to come)
Google Fonts included via
<link rel="stylesheet"
href="https://fonts.googleapis.com/…">or via
@import url('https://fonts.googleapis.com/css2?…');or directly via
@font-face {
src: url(https://fonts.gstatic.com/s/…) format('…');
}would mean that the request is send to the Google servers. By this the website visitors IP address is exposed to Google. As we know IP address is a personal data. Submitting this data would only be possible if there would be consent from the visitor. Which would be very cumbersome to achieve in terms of techniques involved. And: any given consent can easily be withdraw later. If you really want to make sure that everything is applied correctly a cookie would be the best solution. Which needs to have consent as well. As we are talking of US servers, which per se are difficult to use after the Schrems II judgement from ECJ and the fall of the privacy shield.
As a rule of thumb: If Google fonts are used, make sure to host them locally to be GDPR compliant.
Hosting Google fonts GDPR compliant locally (still no SIL OFL)
A skilled web developer knows how to
- download Google fonts
- convert them (will come to this in a minute)
- upload them to your own server
- include them into your stylesheet or directly into your theme
- and make sure that no plugin uses own routes to the Google server to include fonts on a sidetrack
Sounds too difficult for you? You’re not alone. This is definitely not a task for the average WordPress user.
It’s quite common knowledge that I’m not a big fan of page builders. But in that regard Elementor has to get some appreciation:
Anyone else might want to to try the plugin OMGF – Host Google Fonts Locally. It identifies the used Google fonts in your WordPress installation, downloads and includes them and cuts of the connection to the Google font servers.
Thus far, thus (hopefully) known.
Google Font licenses (as GDPR is covered by now, let’s talk SIL OFL)
This is the new aspect for me. To be honest: I didn’t care too much about the license so far. Google fonts was and is one of the big open source projects in the Google universe. Which meant to me: get it, use it, make the fonts available locally! I wasn’t aware under which license the fonts are published and that there’s a different one with SIL Open Font License beside the commonly known ones like GPL, MIT, Apache, etc. Indeed it’s esay to spot – any Google font commes with a tab for the license:
Roboto in this very case uses the Apache License 2.0. But quite some of the Google hosted fonts (as per 24.11.2020) make use of the SIL Open Font License.
All have in common that they are open source licenses, that allow the usage for your web project. The SIL OFL quotes in their FAQ:
Question: 2.1 Can I make webpages using these fonts?
Answer: Yes! Go ahead! Using CSS (Cascading Style Sheets) is recommended. Your three best options are:
- referring directly in your stylesheet to open fonts which may be available on the user’s system
- providing links to download the full package of the font – either from your own website or from elsewhere – so users can install it themselves
- using @font-face to distribute the font directly to browsers. This is recommended and explicitly allowed by the licensing model because it is distribution. The font file itself is distributed with other components of the webpage. It is not embedded in the webpage but referenced through a web address which will cause the browser to retrieve and use the corresponding font to render the webpage (see 1.11 and 1.15 for details related to embedding fonts into documents). As you take advantage of the @font-face cross-platform standard, be aware that web fonts are often tuned for a web environment and not intended for installation and use outside a browser. The reasons in favour of using web fonts are to allow design of dynamic text elements instead of static graphics, to make it easier for content to be localized and translated, indexed and searched, and all this with cross-platform open standards without depending on restricted extensions or plugins. You should check the CSS cascade (the order in which fonts are being called or delivered to your users) when testing.
Taking care of GDPR it’s obivous that two out of three suggestions (a and c)don’t really work in that regard. And to ask website visitors to first download the font, install it on their computer to make the site look beautiful is not a very feasible idea.
But – encouraging downloads also means: downloading is permitted. Nothing so far, that prohibits the local hosting of fonts published under SIL Open Font License.
So everything is fine! Or?
Well, … not really. Downloading Google fonts will give you TTF or OTF – TrueType or OpenType fonts. Most modern browsers can handle these and will render them correctly. But as usual: The better is the enemy of good. Because of performace you might want to use the compressed WOFF/WOFF2 fonts and just for older or *ehmm* broken browsers you will use TTF/OTF as a fallback. If you want to to dive deeper in to font formats I recommend https://creativemarket.com/blog/the-missing-guide-to-font-formats.
Well, and exactly with WOFF the license hassle starts. Again a quote from the SIL OFL FAQ:
Question: 2.2 Can I make and use WOFF (Web Open Font Format) versions of OFL fonts?
Answer: Yes, but you need to be careful. A change in font format normally is considered modification, and Reserved Font Names (RFNs) cannot be used. Because of the design of the WOFF format, however, it is possible to create a WOFF version that is not considered modification, and so would not require a name change. 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: any RFNs cannot be used and copyright notices and licensing information must be included and cannot be deleted or modified. You must come up with a unique name – we recommend one corresponding to your domain or your particular web application. Be aware that only the original author(s) can use RFNs. This is to prevent collisions between a derivative tuned to your audience and the original upstream version and so to reduce confusion.
Please note that most WOFF conversion tools and online services do not meet the two requirements listed above, and so their output must be considered a Modified Version. So be very careful and check to be sure that the tool or service you’re using is compressing unchanged data and completely and accurately reflecting the original font metadata.
Here comes the nutmeg of the SIL Open Font Licence
Converting the font to another format is considered as a modification. Which would only be permitted if the name is changed both internally and externally. Latter one is simple: just rename the font file, include it in your style sheet with that very name and you’re done. But: that’s only half the truth. Within the font-file you’ll find meta-information which refer to the original name. By this the license violation would even be properly documented.
So – just the choice of either GDPR or license violation?
Yes and no. Here are some possible solutions and todos:
- Only use Google Fonts, that are not published under the SIL Open Font License. You can find a complete list of their attribution at https://fonts.google.com/attribution (thanks „Zwischenwelt“ https://stefankremer.de/2020/11/google-fonts-dsgvo-und-sil-ofl-open-font-license/#comment-62)
- deny yourself and your visitors performance and just use TTF/OTF fonts. Hmm, well … not really as this could mean conflicting goals if your customer asks for performance because of SEO
- use tools for the conversion that do not only change the font format, but both namings internally and externally. The usual suspects of web services just don’t
- Do a risk assessment – which one would be more expensive when fined and can it be mitigated by an insurance or by balance sheet provisions
Short research discovered an open source tool named FontForge which claimes to cover the converison in the right way. Anyone having experience with that? It’s available for Mac, Win and Linux. Any lead to other (better) tools in the comments will be appreciated
Or even better: is there a plugin that converts (correctly) on-the-fly TTF/OTF to WOFF/WOFF2? Anyone?
Another open question from the comments: What about the herokuapp? https://stefankremer.de/2020/11/google-fonts-dsgvo-und-sil-ofl-open-font-license/#comment-56 Which offers the font download directly in all a.m. formats. Is it ok to use them? Is it enough (even possible) to shift the responsibility for a license violation to the tool authors?