Hi, I have a few more licensing issues to clarify.
kupu/sarissa : appsrc/ODS-Wiki/kupu/common The LICENSE file is not present. binsrc/oat/toolkit The LICENSE file is not present and several files have dubious licensing status. For example webclip.js is licensed under CC Attribution-ShareAlike 2.5, which is not DFSG compliant and ymapapi.js which has no licensing at all. binsrc/samples/schemaview/xmlsource/schema/README.html: This doesn't appear to be clearly free. binsrc/ws/wsrm/policy.xsd: Same as above but doesn't seem to be used. binsrc/yacutia/ie7/: cc-by-2.0 is not DFSG compliant, but current upstream licenses with MIT so it should be fixable docsrc/stylesheets/docbook This is 4clause bsd which is non-dfsg. libsrc/Wi/sha.h is not DFSG compliant, but doesn't seem to be used. Cheers Arthur On Tue, Dec 29, 2009 at 1:19 PM, Obey Arthur Liu <[email protected]> wrote: > Hi, > > I'm continuing the work on various aspects of the debian virtuoso > packages and I have a few new issues I'd need your help on. > The following refers to the 20091210 6.0.1-rc1 tarball. > > PCRE > ==== > libsrc/util/pcrelib/ > Virtuoso ships and links to a modified version of PCRE 7.9 (with some > additional debugging features). I tested it and vanilla PCRE 7.8 (the > most recent version in Debian) works fine. Could you add a build > option to use the system version instead, like you did for zlib? > > Tidy > ==== > libsrc/Tidy > Virtuoso ships, links to and re-exports an obsolete version of the > Tidy library. There seems to be some switchable code to accommodate > the different API of the newer Tidy but since its interface is > re-exported, the switch doesn't seem that simple. Can you look into > this? While Tidy seems to be less security-critical than zlib or pcre, > it's always better to rely on system libraries. > > Tutorial VAD > ============ > binsrc/tutorial > The tutorial VAD ships numerous pre-built mono .dlls that can't be > rebuilt (or I haven't figured out how). How can I rebuild them from > source ? The .net virtuoso client in binsrc/VirtuosoClient.Net builds > fine with mono. > > All JARs > ======== > *.jar > Virtuoso ships numerous pre-built java .jars built on source that is > not included in the tarball. README.sesame2/3 and README.jena explain > that the user has to get them manually. Because they are BSD-licensed, > you are allowed to do this but this won't work for the Debian archive. > Could you look into the possibility of using system installed versions > of sesame, jena, slf4j... directly into the build system? Otherwise > I'll have to patch one into the source code and I'll rather have you > decide how you prefer to do it. > Note that sesame and jena are not in Debian yet (but slf4j is, so you > can try it with that) but I'm considering packaging them. > > Parallel building > ================= > I still have trouble with parallel building (make -j). It works better > now, but still not all the time. I attached a patch > (build-generated-code-multiple-outputs.patch) that solves one point of > failure for me, there are still many more. > > Use of gmake > ============ > There are a few uses of 'gmake' in makefiles. gmake is not present in > Debian. $(MAKE) should be used instead. > > That's all for now. > > Cheers > > Arthur >
