Core font afm licensing

[marcespie]

Hello, I am in need of clarification with core fonts afm licensing.

Specifically, the current readme says:

"This file and the 14 PostScript(R) AFM files it accompanies may be used, copied, and distributed for any purpose and without charge, with or without modification,"

this is almost an ISC licence.

That one says:
"Permission to use, copy, modify and distribute this software for any purpose with or without fee..."

I'm pretty sure the difference is accidental. I'm not talking about the font itself, but only about the font metrics file.

It would be cool if the core afm could be made available under a more permissive licence.

Most specifically, this would allow using them in OpenBSD-based software products, including mandoc.

Currently, this is blocking  the generation of PostScript/Pdf without proper kerning, thus leading to the impression that those core fonts look bad.

So I'm looking to talk to whoever is in charge of this at Adobe to clarify the situation.

Note that I'm not talking about the font proper, but just the afm files.

[Dov Isaacs]

Exactly what do you think the current license prohibits you from doing other than charging a fee for those AFM files which you have gotten for free?!?

          - Dov

[marcespie]

It's just incompatible with the basic licence used in BSD software.

Specifically, it prevents people from using it as they see fit, which might include creating an appliance, adding their own work on top of it, and then selling their own work.

I couldn't care less about selling it myself.

Like I said, I'm not talking about the font itself, but just about software that may want to produce correct pdf/PostScript that will then use the actual font.

As the situation stands, such software can't be bundled into anything that's sold without asking Adobe about it. So it's a definite no-go for BSD-licenced software.

[Dov Isaacs]

In the over 30 years that these AFM files have been available, we have never had any “issues” reported about this by any software vendor. Clearly, the font metric information about these base fonts could be embedded into an application that really needed such.

Ironically, virtually no application these days makes any assumption whatsoever about what fonts may or may not be available either on the system of the person composing documents or on the system of the recipient and as such uses whatever fonts and metrics are installed on the content creator's system itself - nothing built into the applications at all in terms of fonts or font information!!!

And old Type 1 fonts are pretty much obsolete now. Content creators typically use either OpenType (either CSF or TrueType outlines) or Windows-flavor TrueType fonts. They make no assumptions about the availability of Helvetica, Times, Courier, etc.

Bottom line is that AFM files were a nice issue for the 1980s and 1990s, not the 21st century!

          - Dov

[marcespie]

So, let me get this straight.

On the one hand, you tell me this hasn't been an issue for 30 years, which actually just means we haven't tried to use it.

Reminder: BSD is not the GPL. We have other constraints. Have a look at www.openbsd.org/policy.html

On the other hand, you're trying to tell me that this doesn't matter because this is the 21st century.

Well, you're trying to have your cake, and eat it too.

If it doesn't matter, what's the bother in getting the afm files truely free, so that anybody can use them for whatever purpose they choose ?

If you guys don't want to help I'll have to think it actually DOES matter, you know.

[Dov Isaacs]

My point is that if your software is assuming that the old Type 1 Helvetica, Times, Courier, etc. fonts are available on any system, you are making a very poor assumption. If your software is composing text for PDF (or even PostScript), you should be querying the operating system for font data including available fonts and the font metrics (advance widths, kerning tables, etc.) for same, not relying on bundling a bunch of external AFM files with your software.

That is why this has not been an issue!

          - Dov

[marcespie]

Surprisingly enough, generated PostScript and PDF files are happy with these.

There's a reason these have been called "core fonts": you can generate conformant PDF and PostScript files using the relevant AFM files, and wow, these actually work even if you don't embed any fonts.

(checked with my lexmark printer, and any free source conformant pdf/PostScript viewer, such as ghostscript, ghostview, mupdf, xpdf... heck, my browser embedded pdf viewer, both chromium and firefox).

Now, it might depend if you think those are still relevant in 2017.  I think they are.

The PostScript level 3 documentation (and PDF 1.7, and various other adobe official documents) are still relevant in my opinion.

They do mean you can actually output PDF or PostScript output without shelling money for any font.

And that includes using 100% free software. Yep, not windows, not MacOS, not commercial linux,

Now, the only stumbling block to 100% using those Core fonts is the afm files.

These are just font geometry. I'm not even talking about the actual intellectual property of the font glyph representation, just font geometry AND kerning.

Heck, the only reasons I care about kerning is because:

• adobe "show" operators (both the PostScript and PDF ones) won't magically handle kerning for me.
• I need kerning info to compute font size and actually do some pretty-printing *before* the printer.

Now, there's also ligatures, but the core fonts only have fi and fl (and all of them have them in the same pattern, so I can actually hardcode them).

... well, when I say "I", I actually mean "we".  Not having kerning information in mandoc(1) is a bummer.

Should we actually drop PostScript and Pdf output in mandoc ? I'm confused, I'm not even sure we're legally entitled to using hardcoded Times metric information in mandoc.

If we have to do the right thing, because core font afm information is actually not BSD-compatible, we will certainly comply, but this is sure to be a bummer for OpenBSD, NetBSD, FreeBSD, DragonFly, and Illumos...

[marcespie]

to cut things short: how about you actually ask the brass/legal department about this ?

If  AFM files do not matter, why not give them a completely free licence?

If it doesn't really matter in the 21st century, it will certainly make things much simpler for us.

I'd hate to have to appeal to the *BSD community to get things moving...

[marcespie]

you are actually making assumptions that do not always make sense.

On my operating system of choice, there are no available fonts. I'm talking pure Unix. Yes, this still does exist in 2017.

Now, according to the adobe standard documents, I can generate PDF documents using the 14 core fonts. I can generated PostScript level 1 documents using the same 14 fonts. And nowadays, I can almost certainly get away with PostScript level 2. Hence, the 35 fonts.

Assume no further operating system support.

Assume simple code.  No dependency on stuff that isn't POSIX. I can open files. Heck I can compile data from AFM files.

These are the constraints I'm working with.

This software is still relevant in 2017.

In particular, because having less external parts makes use less brittle. Less amenable to security issues.

Hence, AFM are more relevant than ever.

[marcespie]

BTW, feel free to take this to private email if you prefer [Personal info removed by Mod]

[marcespie]

Ping ? any news ?