Re: Medical device support for GNUmed
On Fri, Jan 7, 2011 at 6:02 PM, Andreas Tille <andreas@an3as.eu> 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
(jeff@freemedsoftware.org)
FreeMED Software Foundation, Inc
http://freemedsoftware.org/
Reply to: