Re: OFL license analysis
> [snip]
>
> First off; while I am a Debian Developer, and do have some experience
> in auditing licenses for DFSG compliance, I can't make any claims one
> way or another as to whether software licensed under such a license
> will be acceptable for inclusion in main (main being the part of the
> Debian archive where software that is actually a part of the Debian
> distribution is kept; contrib and non-free are distributed by Debian,
> but are not part of the distribution. All works in main are believed
> to satisfy the DFSG.) That responsibility lies with the ftp-masters, a
> group of Debian Developers who are responsible for the content of the
> archive.
Hi Don,
Thanks for your feedback on the Open Font License.
> Permission is hereby granted, free of charge, to any person
> obtaining a copy of the Font Software, to use, study, copy,
> merge, embed, modify, redistribute, and sell modified and
> unmodified copies of the Font Software, subject to the following
> conditions:
>
> 1) Neither the Font Software nor any of its individual
> components, in Standard or Modified Versions, may be sold by
> itself.
>
> This is likely to be DFSG free, as anyone can trivially bundle the
> font with something else that can be sold and sell it. However, adding
> this sort of clause to the license, especially in light of the clause
> above, where we are granted "Permission [..] to [...] sell modified
> and unmodified copies of the font software." This dissonance is rather
> peculiar.
This small restriction is needed for cultural reasons within the
typography community but is designed to be easily circumventable to
allow wide packaging and distribution so Debian and other distros can
include the fonts in offline or online repositories. It's really no
different than the terms used for the Vera font family which have been
deemed DFSG-free, included in main and used by default for some time
now. It satisfies the requirements of DFSG #1.
> 3) No Modified Version of the Font Software may use the Reserved
> Font Name(s), in part or in whole, unless explicit written
> permission is granted by the Copyright Holder. This restriction
> applies to all references stored in the Font Software, such as
> the font menu name and other font description fields, which are
> used to differentiate the font from others.
>
> Limited naming restrictions are permitted by DFSG §4. However, the
> naming restriction above is significantly more broad than the naming
> restriction that DFSG §4 was written to allow. (Earlier versions of
> the LaTeX Project Public License required renaming the filenames of
> modified versions so that they wouldn't conflict; that restriction has
> since been removed.) As such, it's likely that this clause will
> restrict the inclusion of works which have Reserved Font Names in
> Debian.
This restriction only concerns the name of the font as it appears in a
font menu and not the actual names of the files like in the older LPPL
requirement you are referring to. The goal of the OFL is to avoid naming
conflicts so that documents actually render as expected but it doesn't
impose any of the special requirements of the Latex License.
Here's what OFL FAQ entry 2.8 says:
"Users who install derivatives ("Modified Versions") on their systems
should not see any of the original names ("Reserved Font Names") in
their font menus, font properties dialogs, PostScript streams, documents
that refer to a particular font name, etc. Again, this is to ensure that
users are not confused and do not mistake a font for another and so
expect features only another derivative or the Standard Version can
actually offer. Ultimately, creating name conflicts will cause many
problems for the users as well as for the designer of both the Standard
and derivative versions, so please think ahead and find a good name for
your own derivative. Font substitution systems like fontconfig,
OpenOffice.org or Scribus will also get very confused if the name of the
font they are configured to substitute to actually refers to another
physical font on the user's hard drive. It will help everyone if
Standard and derivative fonts can easily be distinguished from one
another, and from other derivatives."
Basically, it's about keeping the namespace sane while allowing
branching and merging for font designers and - more importantly -
avoiding a big messy breakage of end-user documents.
> Beyond the mere DFSG Freeness issues of this clause, it also has a few
> practical problems, as "in part or in whole" appears to preclude the
> use of any part of the font name in a derivative version. [Taken to an
> insane extreme, if the font was named 'abc', a derivative 'bad' would
> contain the name in part, thus violating the license.] Nathanael
> Nerode pointed this out as well in the discussion on debian-legal in
> December.[1]
Yes, this is an area of possible ambiguity - indeed an extreme case -
that we're looking at clarifying in future refinements of the license.
The "in part" is really meant to cover the case when there are various
words used in reserved font names. If "Foo" and "Org" are both are RFN
for the font "Foo Org", any designer can branch and create his
derivative but calling it "Bar Org" or "Foo Inc" is not allowed. The
unit to consider here is the word and not the letter.
But for now, version 1.0 - which is in use for the Gentium font family
(http://scripts.sil.org/Gentium_linux) and will be for other projects
soon to be released - has been validated by the FSF and the SFLC as a
free copyleft license for fonts:
http://www.fsf.org/licensing/licenses
> 5) The Font Software, modified or unmodified, in part or in
> whole, must be distributed using this license, and may not be
> distributed under any other license.
>
> While not necessary for DFSG compliance, this clause makes the
> inclusion of the font in any GPLed work impossible.
Inclusion no, but aggregation yes. And it's much more useful for fonts
to be aggregated than included. (You really only need the font installed
once in a distro and not shipped with every application).
I don't think using the GPL is really appropriate for fonts because
fonts under the GPL are problematic wrt. embedding and the status of the
resulting document. This is one area where the OFL wants to fix the
problem as clearly as possible: see OFL FAQ entry 1.
Interestingly, the FSF states the following concerning the Arphic license:
"This is a copyleft free software license, incompatible with the GPL.
Its normal use is for fonts, and in that use, the incompatibility does
not cause a problem."
It's worth noting that various fonts released under the Arphic Public
License have been recognized as DFSG-compliant and are included in main.
> Anyway, as you can see there is basically one problematic clause for
> inclusion in Debian, and a few other minor issues that should probably
> be resolved before font authors start using this license.
Are you sure the naming clause is really that problematic for inclusion
in Debian?
What do other debian-legal experts think?
> [I'd like to
> strongly suggest as well that font authors should consider using an
> existing license with well known ramifications, like the GPL or the
> MIT license instead of a license like this which is less battle
> tested.]
Well, we have found that existing licenses felt alien to the vast
majority of font designers. The GPL certainly does not feel right for
fonts, the FSF still calls for input on the subject and the experimental
font exception isn't really getting that much support from designers.
For cultural reasons, taking a license designed for software and adding
a mention of font design at the end is not going to be very appealing to
designers who are only recently discovering the advantages of a more
open and collaborative approach, less restricted by non-free licenses.
We really think that starting with font-specific vocabulary and
methodology is much better, both for the foundry producing the Standard
Version and for contributors building upon this work to create their
Modified Versions and extend the capabilities (and the beauty) of the
free desktop.
The core goal of the OFL was to take a licensing and distribution model
for fonts that made sense to the designers and that the community had
accepted (Vera for example), improve it where it was found problematic
and turn it into a global unified license that could be re-used (not
tied to one particular project or community) and that would help create
what has been missing for too long: a free software collaborative
typographic community.
They're a lot that needs be done to allow many more users to enjoy
Debian in their own script :-D
> 1: <200512172255.55099.neroden@twcny.rr.com>
--
Nicolas Spalinger
http://scripts.sil.org
Reply to: