Re: [Fedora-legal-list] Legal issues with new font guidelines

2009-01-28 Thread Nicolas Mailhot


Le Mer 28 janvier 2009 14:18, Tom \spot\ Callaway a écrit :
  If this obsoletes the need for a -common
 package, then do not create one.

However if you don't you'll have to deal with the directory ownership
of the common font directory (I purposefully didn't want to open this
particular can of worm) and other common files.

Also documentation can be bulky, especially when upstream provides in
in pdf or .doc form with embedded bitmaps of what the font looks like.

-- 
Nicolas Mailhot

___
Fedora-fonts-list mailing list
Fedora-fonts-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-list


Re: [Fedora-legal-list] Legal issues with new font guidelines

2009-01-28 Thread Behdad Esfahbod
Nicolas Mailhot wrote:
 
 Le Mer 28 janvier 2009 15:54, Tom \spot\ Callaway a écrit :
 ke.
 Well, it seems like there wouldn't be much of a case to obsolete
 -common
 in that scenario, just move the license into each subpackage.
 
 I was not clear, sorry.
 
 In that case documentation is a multi-meg .doc or .pdf file that
 includes windows installation instructions, examples of the font use
 in bitmap image form, and the § that says oh, and BTW, the font is ©
 X and released under the OFL

Shouldn't it be -docs then?  -common sounds like something the rest of the
packages should depend on, which apparently is not the case here.

I don't really like the sans and serif separation.  It may make sense for
megafonts like DejaVu, or CJK fonts, but can't think of any other case.

behdad

 And to repeat my first message, the hypothetical use case is selective
 extraction of rpm content without using rpm, and re-distribution of
 selective parts of the distribution by third-parties without
 respecting constrains we enforce via rpm, which is not something we
 can be sued from since *we* would not be the ones doing the selective
 incomplete re-distribution.
 
 If we start worrying about this we may as well refuse to package all
 the fonts that do not include full licensing information in their
 metadata, since nothing would stop the hypothetical third-party to
 re-distribute the font files without the detached license file anyway
 (regardless in which package we deploy it)
 

___
Fedora-fonts-list mailing list
Fedora-fonts-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-list


Re: [Fedora-legal-list] Legal issues with new font guidelines

2009-01-28 Thread Nicolas Mailhot
Le mercredi 28 janvier 2009 à 13:38 -0500, Behdad Esfahbod a écrit :
 Nicolas Mailhot wrote:
  
  Le Mer 28 janvier 2009 15:54, Tom \spot\ Callaway a écrit :
  ke.
  Well, it seems like there wouldn't be much of a case to obsolete
  -common
  in that scenario, just move the license into each subpackage.
  
  I was not clear, sorry.
  
  In that case documentation is a multi-meg .doc or .pdf file that
  includes windows installation instructions, examples of the font use
  in bitmap image form, and the § that says oh, and BTW, the font is ©
  X and released under the OFL
 
 Shouldn't it be -docs then?  -common sounds like something the rest of the
 packages should depend on, which apparently is not the case here.

It's not -doc because
1. the common packages has also a technical role as owner of common
directory
2. several font packages put more than just doc in it (core font
indexes, etc)
3. and anyway that's just a name, so please everyone take a break and
not start another bike-shedding stage. If you want to comment comment on
the technical spec templates, I've taken enough grief over renamings
others inflicted on me I won't support in any way a new renaming
crusade.

 I don't really like the sans and serif separation.  It may make sense for
 megafonts like DejaVu, or CJK fonts, but can't think of any other case.

I can't think of a single srpm in the repository where sans and serif
are updated in lockstep at the same coverage (or style) level, except
perhaps liberation (and I wouldn't expect this state to survive any
serious community contribution). So in theory, I may agree with you, but
in practice, sans and serif have different lives.

And even if there were some, I wouldn't want to introduce exceptions
that induce documentation and maintenance burdens just to make it a
little prettier. Brutal simple same rules for everyone is much easier on
packagers.

-- 
Nicolas Mailhot


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
Fedora-fonts-list mailing list
Fedora-fonts-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-list