[Pkg-fonts-devel] non-DFSG postscript embedded in fontforge [was: Re: Imager]

Daniel Kahn Gillmor dkg at fifthhorseman.net
Sat Mar 24 16:59:30 UTC 2012

On 03/23/2012 01:33 AM, Christian PERRIER wrote:
> I guess you intend to raise the issue in upstream's mailing list?

I'm struggling with how best to do this.

The part that i'm most concerned with here (DFSG-freeness) i'm not 
convinced is an upstream issue -- upstream has not stated any commitment 
to DFSG-freeness, and upstream's code is licensed liberally, but not 

The only issue that is clearly upstream's is the most silly/pedantic one 
-- the modification of Adobe's code (at the same time, this is probably 
the most significant legal risk since it's directly in contravention of 
their license, while none of the rest of this is).

Maybe they're in some sort of violation of sourceforge's content hosting 
policy?  https://geek.net/terms-of-use suggests that all code posted to 
sourceforge must use an OSI-approved license, and i doubt Adobe's 
license falls into that category.

I'm not sure what would be the most effective and productive way to 
raise the issue with upstream.  I certainly don't want to create any bad 
blood, or make them sigh and roll their eyes about debian.

So having some concrete/constructive proposals to offer might be good 
(otoh, upstream might be in the best position to offer such proposals, 
if they care about the issue at all).

One strawman proposal for consideration (i don't know how feasible it 
is, or if it would even work; i certainly haven't tested it):

The code in question appears to be collected and emitted during 
generation of Type1 fonts, as part of fontforge's DefaultOtherSubrs() 
function.  Fontforge also allows the user to replace this data with the 
OtherSubrsFile configuration.

What if we did the following:

  0) ripped out the adobe code

  1) made DefaultOtherSubrs() raise some sort of error

  2) made the UI for type1 export default to requesting an 
OtherSubrsFile, and had it look in a standard place in the filesystem

  3) posted the Adobe-owned data in an OtherSubrsFile-compatible format 
somewhere *not* as part of the fontforge package (for debian, 
potentially in a package in non-free that placed the file in the 
standard place in the filesystem)

What do people think about the above proposal?

Any suggestions for how to best raise this issue with upstream?


More information about the Pkg-fonts-devel mailing list