[Pkg-fonts-devel] automatically detecting possible SIL OFL license violations?

[Nicolas Spalinger]

Paul Wise wrote:
> Hi all,

Hi Paul,

> I had the idea to automatically detect possible SIL OFL license
> violations using lintian.

More generally the utility who has been developed and released to work
on smart licensing detection of fonts is fontaine:
http://unifont.org/fontaine/


> The SIL OFL allows authors to require font renaming when building from
> source, whether or not the font source is patched. 

You're looking at it from a programmer's point of view: the OFL requires
reserved names to be respected as indicated by authors when the font has
been rebuild. The object code of the ttf itself is source which can be
modified. You can't fully guarantee that the result of building is going
to be bit for bit similar to upstream because of build path issues hence
the need for renaming when redistributing so as to avoid collisions and
resulting document problems and user confusion.

See FAQ entry 2.7, 2.8. 2.9, 2.10, 2.11

> It might be a good
> idea to at a lintian test to attempt to detect this using the
> following criteria:
> 
> debian/copyright contains strings from the SIL OFL.
> 
> debian/copyright contains the phrase "reserved font name" outside of
> the mentions of this phrase in the SIL OFL.
> 
> debian/control contains Build-Depends on fontforge or fonttools.
> 
> debian/rules mentions fonttools/ttx.
> 
> The reserved font name specified in debian/copyright is mentioned in
> the binary font file distributed in the package.
> 
> Any thoughts? Volunteers who know perl?

Mmm, I think we need to work on fixing what is flagged up by the current
font-specific lintian tests first.

Flagging fonts with reserved names is useful for designers who want to
branch, not very useful for packagers at this stage.

Again we don't want to throw out all the very useful open fonts who
currently don't all provide a fully automated fontforge-based buildpath.
IMHO we need to spend time to fix the restricted and duplicated fonts
who has slipped into the archive first. Work on better and more
reproducible buildpaths is underway, especially with the interop promise
from the FontLab authors. It will soon improve the situation on this
front. We need to be a little more patient :-)

> I also wonder if packaging a SIL OFL licensed font could be
> interpreted as "porting the Font Software to a new environment."?

Packaging is not understood as porting to a new font environment, when
packaging is just a wrapper nicely installing the ttf font file in a
font folder. But reworking a full build path obviously will change the
final result hence the need for that derivative to differentiate itself.

As we have discussed various times in the past, if you want to recreate
the full buildpath of a complex font you need to be prepared to spend
time and effort to make it work as expected (not to doubt your artistic
and linguistic engineering skills but it's certainly not trivial to take
on that responsibility) and to maintain all that.  I don't think we have
the time and manpower to do that.

The open font community is working on best practises and better build
paths who are less dependent on restricted software and more easily
reproducible.


HTH,



-- 
Nicolas Spalinger, NRSI volunteer
Debian/Ubuntu font teams / OpenFontLibrary
http://planet.open-fonts.org


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20100602/78f22b78/attachment.pgp>