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
Attachment:
signature.asc
Description: OpenPGP digital signature