[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Medical device support for GNUmed



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?
 
> > 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.
 
> 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.
 
> (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'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.
 
> > 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.

Kind regards

     Andreas.

-- 
http://fam-tille.de


Reply to: