[Openfontlibrary] On font release practices…

Nicolas Mailhot nicolas.mailhot at laposte.net
Sun Jul 13 10:17:16 PDT 2008


Le dimanche 13 juillet 2008 à 09:02 -0700, George Williams a écrit :
> On Sun, 2008-07-13 at 02:37, Nicolas Mailhot wrote:
> > Hi,
> > 
> > Some of you may have wondered why I insist all the time on detached
> > licenses and other boring bureaucratic stuff. Here is what happens when
> > the font author dumps a raw font file with little context:
> > 
> > (10:43:38) LyosNorezel: nim-nim: ping
> > (10:44:41) nim-nim: LyosNorezel: pong
> > (10:44:47) LyosNorezel: nim-nim: what's the usual recommended course of
> > action when "upstream" of a font only provides a ttf and an otf file?
> > ie., no license or tarball
> Surely the correct procedure in these case SHOULD be to look inside the
> font for the internal license?

To repeat myself (with a few new elements):
1. our workflow is built around detached license files (not just for
fonts, for everything).
2. a detached license file is unambiguous.
3. a detached license file is so in the face you can safely assume
upstream did not ship it inadvertantly
4. a detached license file can be parsed by general-purpose audit
scripts
5. a detached license file can be consulted by everyone (users included)
without special tools or font knowledge
6. we don't trust font metadata. We don't trust it for font versions, we
don't trust it for copyright dates, and we certainly do not trust it for
licensing conditions. It's so often wrong, misfiled, copied from an
unrelated font, or just not up-to-date that's not even funny. If we
trusted it and required fonts to have accurate metadata we'd have to
drop a large number of the fonts we ship. (that does not mean we do not
look at metadata, but that it's no more than a hint to us)
7. As soon as you have more than one font file embedded licences are
just useless duplication. Some users are size-sensitive (granted that's
not the main reason)
8. We have all the infrastructure needed to process and propagate font
files, so they're not a burden to us.

> This seems like a trivial thing, but it isn't even mentioned in this
> conversation.
> 
> If the problem is that packagers don't know how to extract a license
> from a font, then I'll write such a program.

The problem is that everyone except font authors (and not all of them)
is uncomfortable with embedded licenses. Any walk on a "free" font site
will show scores of standalone misfiled font files, when just releasing
them in a zip with a detached license document would have avoided lots
of needless confusion and waste of time.

> So I get annoyed by this because these people are complaining about
> something they can easily solve (assuming the font has a license inside
> it, of course).

If many different people complain about the same thing, that's usually
because there is a problem.

> To me having a license WITHIN the font is far cleaner, far better than
> having separate files. I strongly dislike the idea of separate files
> because I feel it is too easy for a license file to be misplaced, but a
> license within the font will only be removed by malicious users.

We ship gigabites of copyrighted data in thousands of modules all
accompagned by their original license text (when the original author
bothered to provide one). We've been doing it for years. We have regular
legal audits by third-parties. We almost never have problems with
projects that make the effort to publish a detached license text. We
have no end of problems with projects that use license embedding. It's
usually embedded so well no one upstream included can consult it or keep
it up to date. 

Please publish fonts accompagned by detached license files. If you want
you can put it in metadata too, but we really want the detached file
(with the full licence text not an ambiguous reference). And if you
reused material from some other font or artwork, please publish the
permission in a text file alongside the rest too. And zip it all (or put
it in a tarball if you prefer).

Thank you for your attention,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.freedesktop.org/archives/openfontlibrary/attachments/20080713/d7ec25e9/attachment.pgp 


More information about the Openfontlibrary mailing list