WOFF2 and Modification Restrictions

RichardW

Is converting a font licensed for use as a web font to WOFF2 generally considered to be modification?

My primary concern is with fonts licensed under the SIL OFL.   There is a caution in the guidance for the licence that an irreversible conversion to WOFF constitutes a modification, so if I need to create a WOFF for somebody else's font, I first check that back conversion to TTF/OTF yields the same font.  (On a very small sample set, I haven't had the problem yet.)  However, there seems to be a far greater likelihood of a conversion to WOFF2 not being reversible.  If one creates a modified font under the SIL OFL, one has to give it a new name, and propagate the licence.

John Hudson

You have to propagate the license, but I think you only need to use a new name if the font has an identified Reserved Name. A lot of OFL fonts are released without a Reserved Name, and my understanding is that in those case a conversion to WOFF2 would not require a new name. I'll ping @Dave Crossland, who can give a more definitive answer to your query.

RichardW

That's a useful point about the name.  How, though, does one interpret "Copyright (c) <dates>, <Copyright Holder> (<URL|email>), with Reserved Font Name <Reserved Font Name>"?  Sometimes the only licensing information is something like "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: http://scripts.sil.org/OFL" in the font's name table.  The referenced licence text starts with that copyright template cited above.  For good measure, the licence_URL name may refer to that SIL page.

If the conversion doesn't require a new name, I think the unchanged name table will normally suffice for licence propagation.

JoyceKetterer

All these words are squishy...  For starters, I think what you're really asking is if it would be a violation of most retail licenses that don't permit modifications.  The answer to that is yes.  

To quote my own EULA (which has pretty standard language on this score) "You are prohibited from decompiling or disassembling the Font Software for the purpose of converting, porting, adapting or modifying it in any manner."  The next sentence explains you need us for "modifications"  (by which we mean changes to the design components).

Reformatting usually isn't permitted as a baseline.   For no fee, many of us will let a licensee who asks do it – so long as we think they know what they are doing.  We just don't want to have to clean up someone's mess after the fact.  

RichardW

@JoyceKetterer: Do you then add an exemption to those restrictions so as to permit embedding subsets in PDFs?  There appears to be a language problem.  I wouldn't think of generating a WOFF2 file as decompiling or disassembling - the file doesn't come near a human-readable form during the conversion.

JoyceKetterer

@RichardW We do exempt pdfs, yes. 

Its a very full sentence.  I wasn't referring to decompiling or disassembling - "converting, adapting".  

RichardW

But that sentence only stops those actions if they require decompilation or disassembly!

Still, the key point is that you see generating WOFF2 as a modification, for which you don't automatically grant permission.

JoyceKetterer

Maybe so, but the next sentence clarifies it. I was trying to not give you the whole thing 

Christopher Slye

@RichardW, Coming in late to this thread, but I just ran across it.

WOFF is completely reversible — it’s really a transport wrapper that supports some additional metadata, but whatever font that goes in comes out exactly the same. (You can think of it as a ZIP archive in that sense.)

WOFF2, as I understand it, will change font data to gain further compression, but will always preserve functional equivalence. I believe tables can be reordered and superfluous data removed, but I’ll bet someone here will correct me if needed!

My point is that WOFF (not WOFF2) will never modify a font.

JoyceKetterer

@Christopher Slye modify, no.  But it's it still constitute a reformatting?  Most of these clause prohibit both.

Christopher Slye

IMO if one is okay with their font being ZIP’d, then WOFF (not WOFF2) should be likewise fine.

JoyceKetterer

@Christopher Slye I think I've seen this argument on typedrawers before.  Your line of reasoning makes some sense technically but the fact is that the file type suffix changes from .otf (or whatever) to .woff so I think most people would consider that reformatting.

RichardW

Well, technically, an OFLed font with reserved name and non-zero padding bytes cannot be WOFFed purely relying on the terms of the OFL.  My concern was rather with the legalities of WOFF2.

John Hudson

I'll be interested to see how licensing adapts to dynamic subsetting and 'enrichment' of font resources on the Web: not only format conversion and modification, but also cutting up fonts, serving partial subsets, and reassembling them on the client end.

JoyceKetterer

@John Hudson our standard web embedding addendum permits subsetting because that seems to be the use case when it is most needed.  It's not permitted for basic use because I've not got the impression it's needed for "desktop" and we don't want to confuse people.  

Christopher Slye

JoyceKetterer said:

Your line of reasoning makes some sense technically but the fact is that the file type suffix changes from .otf (or whatever) to .woff so I think most people would consider that reformatting.

I think the technicalities are important — what is actually happening, versus how it looks superficially. As I said, WOFF is a wrapper, and the font is treated no differently than if it were in a ZIP archive, a disk image, or some other file that acts as a container. WOFF was intended to move a font from a server to a browser inside something that isn’t usable as a font, so that it remains secure until the web client strips away the wrapper and uses it.   

RichardW said:

Well, technically, an OFLed font with reserved name and non-zero padding bytes cannot be WOFFed purely relying on the terms of the OFL.

WOFF (1.0) is explicitly lossless, so I don’t follow this. I mean, OFL-licensed fonts are regularly distributed inside container files like ZIP, and nobody seems concerned about that.

Yes, a WOFF converter could modify the font, but that’s really something outside the WOFF spec, which is designed to allow a font to be WOFF-wrapped with no modification. The OFL FAQ even addresses this.

JoyceKetterer

From a font licensing perspective I think what matters is "what does the end user think they are doing?"  

This is why I permit pdf embedding in my basic license, even though we want to have a hard line that embedding isn't covered at the basic level.  That is, most end users have no clue that "printing to pdf" involves font embedding (unless you actively disable it). So, even though it's not technically correct we permit it because it doesn't feel like embedding.

I'd argue that turning an otf into a woff is the opposite example 

RichardW

The referenced OFL FAQ warns, "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."  I can certainly imagine ancillary data being appended to a font file.  Zip's deflation preserves everything.  A WOFF creator could reasonable omit an FFTM table; this would arguably violate the OFL requirements for keeping a reserved font name.

Stuart Sandler

In general if a desktop .OTF font is being purchased, the foundry intends its use as limited to the desktop platform only. By placing a restriction on modification within the EULA, the foundry is saying you may not use the font in any other platform.

Converting the font to WOFF (or wrapping it in a non-OTF modifying wrapper) means the font can now be used on the web, a platform that is not allowed by the default EULA terms. 

Uploading an OTF font to an online design tool such as Canva so it can render as a web font AND be used to design with violates TWO EULA terms, redistribution of the software and modification just the same as wrapping the OTF font in a configuration profile so it can be used on iOS devices or uploading it to a service that allows its use on iOS devices.

It is incorrect to climb the slippery slope of a technical argument whether the actual OTF font file remains 100% intact or is actually modified. The INTENT of the EULA is to inform the user that they may not use any technical means to change the platform of use or distribute the font software so it may be exploited on 3rd party platforms EVEN if the user has a legitimate commercial use license for the font.

In 100% of these cases, the user should contact the foundry and inquire if they may perform any of these actions with the OTF file and if it violate the EULA they've agreed to. 

This is fully a license issue and not a technical one.

Christopher Slye

It’s fine to discuss licensing issues and the intent of commercial EULA terms. It just wasn’t my point, and I don’t think it was “incorrect” for me to make it in the context of the OP.

Really, my original point was that the original WOFF format does not modify a font. That’s it.

I think it’s interesting to debate, as we have here, whether a font that has been “converted” to WOFF becomes some other kind of font. I obviously think it’s the same font in a wrapper, but I understand the opposing argument. The point of the OP was to ask whether WOFF conversion is considered modification. My intention was to clarify a subtle difference between WOFF and WOFF2 in that regard.

I agree it’s perfectly reasonable for one to specify a EULA prohibition against WOFF conversion if one doesn’t want their EULA to allow web use. That’s one way to accomplish that. Another would be to say, “You do not have permission to use this font on the web.” Again, that was not my point at all.

And since the OP and a lot of this thread is focused on the OFL, I think it’s a distraction to talk about what commercial EULAs “intend.” It’s not controversial to say that the OFL intends to permit web use, is it? We only get tripped up there because of reserved font names and modification.

Stuart, you’re making good points and I agree with some of what you say, but I want to be clear that it has very little to do with the point I’m trying to make and the OP’s question, which was primarily about open source licensing.

Getting back to WOFF and modification: Yes, apparently some WOFF converters are not lossless. The FAQ’s answer to the question, “Can I make and use WOFF (Web Open Font Format) versions of OFL fonts?” is “Yes, but you need to be careful. ...” Of course one should be mindful of what a WOFF converter is doing, but I’m only saying exactly what the FAQ says: “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.”

Personally, from what I know about WOFF2 (I left the working group not long after work on WOFF2 got started), it sounds like its potential modifications are minor enough to preserve Functional Equivalence under the OFL, and Victor’s 7-year-old Web Fonts and Reserved Font Names also says that is likely. I’d love to see that part updated now that WOFF2 is more settled.

John Hudson

While technically WOFF is just a wrapper around an SFNT font file, and not a modification of that font file, functionally it is a separate font format. Indeed, that was the primary purpose of creating WOFF — compression was a happy byproduct that helped sell the idea to browser makers —: the goal was to have a webfont format that would be functionally distinct from the desktop format.

So the question whether a WOFF file is the same font or a different font from its contents depends whether one considers the functional distinction to be part of what defines a distinct font.

Dave Crossland

Weighing in late here, but OFL predates web fonts, so didn't intend or not intend the terms to allow/prohibit/shape font redistribution via http.

I believe the FAQ has been updated a few times in the last decade to attempt to add clarity to common web font redistribution situations.

WOFF 1 doesn't modify the font it compresses at all; it's easy to confirm that with a checksum. And similarly WOFF 2 does modify the font data during compression, but the output should be functionally equivalent to the input.

There's a document by SIL (https://scripts.sil.org/OFL_web_fonts_and_RFNs) that introduces the idea of "functional equivalence" as a kind of modification which might be interpreted as non modification under the OFL terms, that I would summarize as "while the checksum might be different on the binary, if no user can tell a difference, what does it matter?"

But then as Joyce points out, while the uncompressed output of a WOFF 1 or 2 file may be bitstream or functionally equivalent to the input, the intermediate compressed form is inherently different to the user. In the majority of cases this doesn't matter because the user never sees the WOFF file.

But still, to answer the original question, since the copyright notices is a boilerplate, there's no RFN in play, and so this doesn't matter for that particular case.