Ubuntu Font Family

Bug #648406
Comment #5

Comment 5 for bug 648406

Revision history for this message

Paul Sladen (sladen) wrote on 2010-12-07:

Shiraaz: in addition to going into the distribution, there's another technical project currently in the works that is waiting for the 0.70 release. I've managed to stall that for the last fortnight as a 0.70 was looking close; I will need to have a newer package up on font.ubuntu.com by the end of the week (2010-12-10) that has also been checked over. That date is an absolute upper-bound.

Leaving the fstype DRM bits set we are depriving users of the very Freedoms that we are trying to offer users, a font that does not come with opaqueness or place restrictions on how it can be used; I'm not comfortable with putting out a release with the fstype bits set, as it would be a regression against the previous 0.69 release and the ideology and flexibility trying to be promoted. The short-term gain would not (in my opinion) out weight the downsides.

The main options that come to mind are (please suggest more if there are ones):

  1. I can leave the existing script in the build process, patch the fstype bits to zero, and break the signatures.
  2. Have a new build with fstype bits cleared, and good signatures.
  3. Don't put out a release at all.

(1) requires a little effort, since this time around I would patch to the source .ttfs which I failed to do the last time around (something missed in the extreme hurry the last time around for 0.69) and I don't wish/intend to repeat after it was kindly reported to us.

(2) of course takes time on the Dalton Maag side, but would be the cleanest and most preferable: patching remains a last resort. Fixing minor technical issues: clearing these DRM bits, setting the Copyright strings, restoring the version glyph and ensuring the signature were the very reasons for proposing (on 22 October 2010) to do this otherwise low-change 0.70 release.

(3) normally this would be my preference; waiting and doing things purely in terms of quality (and not time). Whilst I applaud doing another release in a couple of weeks, it is beyond the time-frame available for in this case because it would block progress elsewhere.

Given a choice between a having a good signature, or having a libre/free/open release, the second wins.

Shiraaz: in addition to going into the distribution, there's another technical project currently in the works that is waiting for the 0.70 release.  I've managed to stall that for the last fortnight as a 0.70 was looking close; I will need to have a newer package up on font.ubuntu.com by the end of the week (2010-12-10) that has also been checked over.  That date is an absolute upper-bound.

Leaving the fstype DRM bits set we are depriving users of the very Freedoms that we are trying to offer users, a font that does not come with opaqueness or place restrictions on how it can be used;  I'm not comfortable with putting out a release with the fstype bits set, as it would be a regression against the previous 0.69 release and the ideology and flexibility trying to be promoted.  The short-term gain would not (in my opinion) out weight the downsides.

The main options that come to mind are (please suggest more if there are ones):

(2) of course takes time on the Dalton Maag side, but would be the cleanest and most preferable: patching remains a last resort.  Fixing minor technical issues: clearing these DRM bits, setting the Copyright strings, restoring the version glyph and ensuring the signature were the very reasons for proposing (on 22 October 2010) to do this otherwise low-change 0.70 release.

(3) normally this would be my preference; waiting and doing things purely in terms of quality (and not time).  Whilst I applaud doing another release in a couple of weeks, it is beyond the time-frame available for in this case because it would block progress elsewhere.

Given a choice between a having a good signature, or having a libre/free/open release, the second wins.