Notes on font protection

blokland's picture

One can endlessly discuss to what extend an EULA permits the editing, conversion or wrapping of a font, as long as applications make it possible to freely and uncontrolled apply these actions to fonts by for instance end users, copyrights will be infringed. So, perhaps the developers of font production tools, like DTL, should try to make the applications somewhat more restrictive when it comes to altering fonts (-formats).

One way to do this that came to my mind, is to make use of the vendor ID in the ‘OS/2’ table. A font editor, converter or wrapper looks at this table and checks an online database where the vendor ID is stored plus a key code (which could be just the string ‘public’) supplied by the vendor in question. The font tool checks the database and will make editing/conversion/wrapping possible if the key is ‘public’ or else will ask for the key code. If the entered key code is correct, the program will allow (also future) editing by the app of the fonts of the vendor in question (a vendor should not be hampered by this functionality when it comes to editing his own fonts, of course). This use of the vendor ID would also work with older fonts, i.e., no additional table information is required.

This way the vendor is more in charge, because he can give/sell the key to third parties for the editing of his fonts –or not. The key is not static and can be changed at any time by the vendor. However, if a program is unlocked for a certain vendor, it remains unlocked (although one could think of a mechanism that checks the database for an updated key code once per half year or so). Such a protection also has an advantage for the font tool manufacturers, because illegally distributed copies will not be unlocked or only temporarily unlocked for all or even any vendor ID’s.

At the recent ATypI conference I briefly discussed the matter with some other application developers. Because Microsoft is registering the vendor ID’s, the company comes to mind for storing the vendor keys also. The first reactions from the contacted parties were promising. However, if it comes to the appliance of this idea, it will take some time before apps will include the checking functionality. Older versions of the apps in question can be used to edit fonts then still, of course, but technically these will probably become obsolete in time. Also some older tools will perhaps be difficult to update, or some free tools might circumvent the limitation. But such a system will at least to a certain extend help to protect the rights of the font manufacturers, I reckon. And it is a message to those who work with/on fonts, that copyrights should be respected.

I am curious what the type community thinks of this idea.

FEB

charles ellertson's picture

I am curious what the type community thinks of this idea.

Assumes "type community" = "font designers". Perhaps this is an unproductive way to think of the type community?

blokland's picture

Charles: Assumes “type community” = “font designers”

Basically, with ‘type community’ I was thinking of everyone who designs, produces or works with fonts, and I reckon that everybody in this community wants to protect their and their colleague’s rights as much as possible.

Charles: Perhaps this is an unproductive way to think of the type community?

I am afraid that I completely miss your point here. The only reason that I came up with the vendor ID based plan, is to protect the rights of the type designers and font foundries. It would only affect font production tools or font editors and not for instance desktop publishing applications. So, one can simply not edit, convert, or wrap fonts without the permission of the owner of the font. Such protection would especially cost the programmers of font tools, like ours, extra work and that could be considered unproductive. But I am not sure if you meant that.

FEB

blank's picture

This solution will never work. You’ll never be able to get the open-source crowd on board with any font DRM scheme, so people who want to work around this would just open the font in FontForge and get to work (or clear that part of the OS/2 table and export a new font to work on in another editor.).

charles ellertson's picture

I view the primary type community as people who use fonts, and people who read. We are all grateful to the font designers who provide us with tools, just like we are grateful to the layout programmers who provide us with other tools.

My rants on the subject are probably too common on typophile, but I'll just repeat that not a month goes by that I do not have to modify a font. Usually something trivial, as a character needed that is not included in the foundry version. Say, a diacritical needed. Or, a raised comma, which is not the same character as an apostrophe -- just check the Unicode charts. Often kerning, which is an individual preference. Designers are "always right?" Not when punctuation is so tight as to rival a diacritical. Esp. when the editor marks it "P.E."

It is an exaggeration, but designers think about letterforms and graphic shapes. Much of the type community thinks about texts. Rarely do we hang letterforms in museums; most common is to use them to present texts.

blokland's picture

James: This solution will never work.

This depends on how and what you measure. Whatever the ‘physical’ system for font protection is, It will never be waterproof because there probably will be ways explored and found to circumvent it, or because of legacy limitations. But at least this solution doesn’t cost font producers any extra work, except for controlling the vendor key (assuming that vendor ID’s are always included in the TTF/OTF fonts) and it would be backwards compatible too.

So, I would actually expect owners of font data to embrace any ‘physical’ system that helps (a bit) to protect their intellectual property, especially because there is none at the moment whatsoever –as far as I know. And when it comes to vulnerability, in general most defense systems are built step by step anyway, I reckon.

Charles: […] not a month goes by that I do not have to modify a font.

That is fine as long as the EULA that came with the font allows the end user to do this. And with a vendor ID/key controlled system this will be possible still in case the owner of the font permits this kind of actions.

FEB

charles ellertson's picture

Charles: […] That is fine as long as the EULA that came with the font allows the end user to do this. And with a vendor ID/key controlled system this will be possible still in case the owner of the font permits this kind of actions.

One of the bad things about internet forums is people get nasty and use rough language. I won't do that, but it doesn't mean I haven't uttered those words under my breath.

You want to protect your fonts from piracy. I applaud. So you hire $300-an-hour lawyers to write a restrictive EULA. You propose a software "fix" to enforce it. You are apparently unaware that EULA makes the product unuseable, at least to one segment of what I condsider the type community. A lack of knowledge of the workflows needed to turn letterforms into text is not a laudable trait for one in the "type community."

Or perhaps you don't consider the people who set type, who read books, who search files, as a part of the type community?

There is a growing movement amongst publishers to say "Adobe only." Usually I can get them to also allow fonts from Carter & Cone and Stone. But then, Matthew and Sumner understand the type community to include people who use type.

Thomas Phinney's picture

Besides the other objections, this proposed scheme assumes that a given vendor will have all of their fonts either "public" or "protected" and not have some in each camp.

Also, if a vendor wants to allow a given specific user to modify a "protected" font, what do they do? Seems like they either have to tell the user the key code, or generate a custom version of the font to allow modifications.

Of course, the first thing that will happen is somebody will write a utility that simply takes a font and removes the vendor ID so fonts can be modified. But that's not really the point, this is another "garden fence" class protection, isn't it? But I think the EULA and the fact that one has to actually have and use a font editor already constitute a sufficient "garden fence"....

Regards,

T

Syndicate content Syndicate content