[Openfontlibrary] new release of the Ubuntu titling font

[Dave Crossland]

On 05/01/2008, Victor Gaultney <vtype at gaultney.org> wrote:
>
> One of the many reasons [for no source] is that the great majority of
> font software can be 'decompiled' trivially.

This is applies to outlines and other simple kind of data included
wholly in font object code. But font software is not purely outlines
and other simple kinds of data, and especially in the long term is
dangerous to gloss over this.

The complex non-visual parts of font software are obvious, and you've
explained the hinting and contextual features well. Another complex
non-visual kind of source code is the build scripts used to compile a
font - the perl scripts you mention below.

But there are also simple kinds of data that are discarded when a font
object code file is compiled/"generated."

Consider named guidelines. Access to this "source code" is essential
for fair collaboration; If I was to try to modify Charis, I would be
at a disadvantage compared to the original authors since I can only
guess at what the armature upon which the shapes are drawn looks like.

> For example, Our Charis SIL fonts can be brought
> into FontForge with every glyph shape absolutely intact and editable.
> ...
> There are situations, however, where it is not simple. For example, Charis
> SIL includes very complicated and messy OpenType and Graphite code. We
> produce it and insert it in to the fonts using custom perl scripts that read
> control files. Because of the e will be releasing the scripts and control
> files - a very similar model to traditional free software development.

If I open up Charis in FontForge, make modifications and call it
"Chavis," I expect to be able to compile my font to work just like the
original. That the scripts and control files are not released yet
means I can't do this.

This is basically *nuts* - and is exactly what the GPL protects us all
against and why it is the most popular free software license.

Coincidentally, this week Michel Boyer from the University of Montreal
is falling foul of exactly this problem with Charis on the
fontforge-users list.

> In fact, I would
> argue that it is *more* useful, and far more free, as it avoids any
> requirement to use proprietary software.

It is typical to distribute corresponding pre-compiled object code
files with source code files for convenience. In this case that
alleviates the hard dependency on proprietary font editors.

> Yes, ideally, you would want to
> have the original cubic curves. We have long planned to provide these in a
> useful form, using a reasonably universally readable format (PostScript Type
> 1). But that is not a trivial effort.

The curve data format is a secondary issue; the primary issue is that
full source, whatever the format and whatever the dependencies, ought
to be distributed alongside binaries.

> So why can the OFL still be a free license without requiring full release of
> original sources for a free build path?
> ...
> a traditional free software source code/free build path
> requirement would push away designers and not give the FLOSS community much
> more functionality.

No license requires full release of original source _for a free built path_.

Think of all the free software written in Java :-)

You used FontLab to develop your font software. Although FontLab "VFB"
files depend on FontLab, which is proprietary software, that does not
effect the moral obligation to distribute these source code files when
you distribute the corresponding object code files and "trap" people
like Michel Boyer.

I use the work "trap" to allude to
http://www.gnu.org/philosophy/java-trap.html and this quote is
relevant:

"It was inevitable that our first programs would initially be hampered
by [proprietary] dependencies, but [the GNU project] accepted this
because our plan included rescuing them subsequently. Our overall
goal, a self-hosting GNU operating system, included free replacements
for all those dependencies; if we reached the goal, all our programs
would be rescued. Thus it happened: with the GNU/Linux system, we can
now run these programs on free platforms."

However, because VFBs require other people to use only FontLab, it
leaves out people using other font editors - free or otherwise. Using
a "standard" source code format that is supported by many font editors
would be ideal and "rescue" your fonts.

The "UFO" format from the Robofab project is a strong candidate for
this. But it needs a few tweaks to support complex parts of fonts
(OpenType tables especially, may be more) and isn't ready yet. The
"SFD" format from FontForge is also a strong candidate, but no SFD
export software exists for FontLab yet.

Until a good font source code format is available, I strongly
recommend publishing your VFBs and all the software you use to compile
your fonts.

So, ignoring the "free dependencies":

> can the OFL still be a free license without requiring full release of
> original sources?

Yes the OFL can be still be a free license without requiring full
release of original sources, but it is problematic.

> a traditional [complete] software source code requirement would push away
> designers and not give the FLOSS community much more functionality.

Complete source code does give the free software movement much more
functionality - essential and basic functionality, in fact - so this
requirement is important to have, and I don't think it is complicated,
nor do I think it will push away designers if it is explained simply
and the benefits are clear.

Indeed, I hope that the next version of the OFL (v2?) will include
such a requirement.

The GPL's model of including an offer to distribute source as equal to
actually distributing source avoids the PDF embedding problem.

While writing this I checked the news, and note that McAffee is in the
news today because it has just reported to shareholders that it has
been including GPL software in its proprietary software.
http://yro.slashdot.org/article.pl?sid=08/01/05/0215201

This demonstrates that even a powerhouse of software engineering like
McAffee finds the freedom offered by the software freedom community
too good to pass up; its simply a better way of doing business. But
they have ignored the responsibilities that go with freedom, and which
they are obliged to meet thanks to the GPL's protections.

Will font developers unfamiliar with the software freedom community
norms ignore the responsibilities that go with freedom to modify fonts
if not given simple and clear guidance? I think they will, not out of
malice, but out of innocent ignorance. (Unlike McAffee...)

Therefore informing them about the issue and having a requirement is essential.

Such a requirement also lessens the need for the unusual
selling-bundled-only restriction in the OFL. As with the Creative
Commons' "Non Commercial" licenses, a strong copyleft is a far better
protection against exploitation, because it encourages people to
improve and sell works but allows original authors to include those
improvements so there is a "Return On Value." Non commercial
restrictions  http://freedomdefined.org/Licenses/NC explains this in
detail.

I am currently writing a "Font GPL" guide, on how to best apply the
GPL to fonts.

The GPLv3's section 7 says that "you may (if authorized by the
copyright holders of that material) supplement the terms of this
License with [the following] terms" and one of those is "e. Declining
to grant rights under trademark law for use of some trade names,
trademarks, or service marks." This is the basis of another of the
main features of the OFL, I think.

So it might be that a a "Font GPLv3" guide is all that is necessary.

> Our problem has been that we have used a very convoluted, messy,
> unexportable manual build process for our fonts (ever wondered why our
> releases are only about once a year?). That may not be all that surprising
> for the most complete and complex Latin fonts in the world. :-) But it also
> means that any FontLab files we gave you would be not very useful, as we do
> so much custom post-FontLab processing. Note that we do not have a general
> phobia of releasing FontLab files - we do that for Gentium and other
> projects. It's just that the Doulos/Charis ones are so far removed from the
> resulting fonts themselves.
>
> You would actually do better by working from the fonts as your source, as
> many others have done. We do realise that this is not ideal for us or anyone
> else, so we've been working hard to change it in big ways over the last 2
> years. I just spent two weeks in Dallas in December working on this and
> other issues with our team. We still plan to use FontLab as a production
> tool, but will also provide control files, scripts, outlines in a form that
> is useful in purely free environments.
>
> I would be happy to discuss the details with you, and would value your
> feedback.

This is all amazing news from SIL, and is certainly to be
congratulated :-) However, the general case is still problematic.

> > For this reason, I am planning my future font releases (those created solely
> > by me) under the GPL+font exception.
>
> As I mentioned before, I think that option has some problems, and I
> certainly wouldn't recommend it. If we felt it was an adequate solution
> there would be no need for the OFL. :-)

Please explain what those problems are precisely (or point me to where
you already explained them if I missed it :-)

(When are you next visiting the Department of Typography at the
University of Reading? We could record a podcast discussing these
problem then, if you can't spare the time to write an email :-)

-- 
Regards,
Dave