On Sun, Jan 18, 2009 at 7:03 PM, S'orlok Reaves <sorlok_rea...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
