On Fri, Jan 7, 2011 at 6:02 PM, Andreas Tille <[email protected]> wrote: > On Fri, Jan 07, 2011 at 11:16:35AM -0500, Jeff Buchbinder wrote: >> Thanks. As far as I know, rxtx would need to be either packaged more >> recently or built from source, since the 2.1b7 version that's out >> there now doesn't work properly for the parallel port devices on linux >> (including label printers), and I don't think anyone is actively >> maintaining the packaging for some reason. > > ??? > ~$ apt-cache policy librxtx-java > librxtx-java: > Installiert: (keine) > Kandidat: 2.2pre2-2 > Versionstabelle: > 2.2pre2-3 0 > 5 http://ftp.de.debian.org/debian/ experimental/main amd64 Packages > 2.2pre2-2 0 > 501 file:/home/ftp/pub/debian/ testing/main amd64 Packages > 501 http://ftp.de.debian.org//debian/ testing/main amd64 Packages > 50 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages > > This looks like the recent upstream version. Am I missing something?
Apologies, that looks good. I think I looked for package versions a while back. The "install-deps.sh" script(s) importing the rxtx library could be rearranged to import the distribution copy of the jar file for packaging purposes. >> > Can you provide a license file which clarifies this issue (preferably in >> > the downloadable tarball because it is not only relevant for Debian >> > packaging) >> >> Could you provide me with an example of a document doing this so that >> I can correctly word the license file? > > From a Debian perspective it is just required to mention any file which > is not covered by the "main" license (which is GPL in your case). I'm > not sure whether this strict handling is appropriate for your case and > whether these are good examples but here are two copyright files I > created for some more complex packages: > > > svn://svn.debian.org/svn/debian-med/trunk/packages/arb/trunk/debian/copyright > > svn://svn.debian.org/svn/debian-science/packages/R/r-cran-maptools/trunk/debian/copyright > > In these (and a lot of other cases) upstream used parts from other > projects, which are in these cases non-free and thus make the packages > non-free. My impression from your description of FreeSHIM is that this > is the same because you include binary code without source. If you do > so you should at least explicitely state (or at least link to a website) > the license which clarifies the conditions of usage somehow. The Debian > packager needs to check this anyway because ftpmaster is quite picky > about this - but IMHO you should mention this in your upstream source > as well. We have the option of just not including the particular driver which requires that library, if that's a better alternative. It was broken into separate drivers for this sort of purpose. You'll notice that the topaz driver is shim-drivers/shim-driver-signature-topaz and can be excluded if need be. Unfortunately, as the final product to be installed/distributed is a war file, it's a bit more difficult to include that "after the fact", although it could be distributed in an "exploded" format (as a directory of files rather than the single war file) with additional drivers packaged separately. I added a LICENSE file which is now in Subversion with the additional licensing information, etc. >> Also, the link from which I downloaded the Topaz library was: >> >> http://www.topazsystems.com/software/download/java/index.htm > > This should be mentioned in any case and probably also a deeper link to > the license. I just made that change in the LICENSE file. >> (Again, if someone wants to help reverse engineer it, that's fantastic... ;) >> ) > > I do not expect that anybody on this list will spend some time into > it ... but for sure freeing the code would be great. I agree. I believe that the JNI shim is just an HID driver. >> I'm honestly not sure how to proceed, since obviously the Topaz stuff >> isn't going to work without their non-GPL jar file, but I'd like to >> GPL license the code for purely philosophical reasons. > > I admit I'm no lawyer. I welcome that you are using GPL for your code. > Whether it is possible to use the Topaz stuff or not with this is not my > point. My point is that the Topaz license (and any other licenses of > code which might be used in addition) should just be mentioned to inform > the user. Done in the LICENSE file. >> > for all the *.java files - perhaps you might like to fix this address. >> >> Sure, hadn't seen that before. I just fixed that upstream in Subversion. > > Fine. Just for your information: If you have access to a Debian system > the script in question is named licensecheck. Just run it on your code > to check the licenses. Thanks! -- Thanks, Jeff ([email protected]) FreeMED Software Foundation, Inc http://freemedsoftware.org/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
