Re: RFS: scim-waitzar, libwaitzar (re-submission) Attn: Paul Wise
On Sun, Jan 18, 2009 at 7:03 PM, S'orlok Reaves <sorlok_reaves@yahoo.com> wrote:
>> Which fonts are these? I'm wary of adding fonts to source packages;
>> usually either the font is a copyright violation or should
>> be packaged separately.
>
> It was just the Myanmar 3 font, which (according to a page on fedoraproject.org)
> is LGPL 2+.
> I understand your concern, though, so I removed Myanmar3.ttf, changed the default
> Myanmar font to Padauk.ttf, and added a dependency on ttf-sil-padauk.
Cool.
> The "fonts" directory now contains ONLY the font metrics (xml) files for each
> of the fonts I use in the documentation. This is ok, right? There's certainly
> no glyph data in the package. I can remove these xml files if they violate copyright, it's just that they're fairly difficult for docbook newbies to generate at run-time.
I guess so, no idea where the various jurisdictions stand on that. I'd
err on the side of caution and say that they were/are derivative works
of the fonts they are from. What role to they have in
> I came up with another solution: scim-waitzar-doc now uses only xsltproc, and outputs
> an html file. The makefile contains a "pdf" target, in case a user wants to generate
> the pdf documentation. scim-waitzar ships the pre-generated pdf, so people who
> want to print the user's guide get a nice shiny pdf.
Cool. Did you embed any fonts in the PDF, which ones and what licenses?
>> Hmm, FSVO 'source code' and 'program', this
>> violates DFSG #2.
>
> Let me see if I can clarify the role of Myanmar.model; I don't think this is a
> violation of the spirit of the DFSG.
> For anyone following this discussion, the relevant line is:
> "The program must include source code, and must allow distribution in source code as
> well as compiled form."
...
> My overall feeling about this is summed up here:
> 1) Generating Myanmar.model at run-time is not appropriate, and way outside the scope
> of a romanisation library.
What about at package build time?
> 2) Myanmar.model is essentially a cached version of Myanmarlist_v2.txt, with a few additional
> non-essential features, which is only slightly less readable than MyanmarList_v2.txt. They
> are both "source".
My personal opinion of DFSG #2 (others involved with Debian have
various differing opinions) is that "source" means "preferred form for
modification"; or, whatever upstream would prefer for fixing bugs or
enhancing the 'software'.
The 'source' for a PDF would be the docbook XML, some fonts and images.
To take another example; C code generated from a Glade XML UI
description is generally not source (IMO), rather the Glade file is
the source. However, if the C code is hacked up extensively then the C
code is the source. If the C code is edited slightly, but is often
regenerated after changing the Glade file and then edited slightly;
then the 'source' consists of the
My view of 'source' is a bit complicated but is based on the desire
for equality between upstream and any users of their software.
I'm at LCA so I don't have time right now for much more than this
mail, may take a look later in the week.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: