Ah, now we enter into the joyous legal details. I'll do my best to be as helpful as possible in this regard; please let me know if you need any clarifications. I only had to re-build one package this time:
http://mentors.debian.net/debian/pool/main/s/scim-waitzar/ > 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. 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. > Note that fop is in contrib (except in experimental), so > you should either target experimental instead of unstable or move the > package to contrib. Unfortunately, that defeats the purpose of this package. Scim-waitzar is meant for everyday use by Myanmar users of Debian, and I also hope to get it into the "Language" defaults for Ubuntu --so I really can't target experimental or contrib. 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. This solution leverages docbook's flexibility in generating various different formats. > 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." ...in particular, the first half (since libwaitzar allows re-distribution of anything in the repository). Myanmar.model is simply a re-generated form of MyanmarList_v2.txt. The latter is simply a list of mappings: myanmar_word = romanisation ...while the former is basically just a serialized hash table containing all these mappings. Myanmar.model is optimized for speedy lookup and minimum size. If you simply copy the contents of MyanmarList_v2.txt into mywords.txt, scim-waitzar will load the EXACT SAME romanisation on startup, it'll just take a few seconds longer. Myanmar.model also adds trigrams, to try and help typists by guessing the current word from the previously typed words. The choice of trigrams is subjective, and --although I wrote my own code to generate them-- trigrams can be generated by any decent-quality natural langauge processing library. (I have seen free implementations). The entirety of the WaitZar model is open-source. Moreover, even the trigrams are open-source. They are described directly in Myanmar.model, which is a text-based file, and whose format is documented in the library's comments for those who want to hack it. 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. 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". Of course the mentors have the final say in this. But I truly feel that my package is presented in the full spirit of open-source software. > Hmm, experimental lintian tags, didn't know about > those. Thanks Sure thing! As always, please let me know what's required and I'll do my best to work my package around it. I've invested a lot of work into this package, and I'm willing to go the extra mile to get it accepted. -->Seth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
