Re: [guppi-list] Guppi as a mime-type handler



> "Steven G. Johnson" wrote:
> > 
> > Note, by the way, that the license of NetCDF
> > (http://www.unidata.ucar.edu/packages/netcdf/copyright.html) is
> > incompatible with the GPL due to the fact that it contains an
> > "advertising clause" restriction not permitted by the GPL (see also
> > http://www.gnu.org/philosophy/bsd.html).  There are ways to resolve
> > this sort of thing: an explicit license exception for NetCDF, for
> > example, or placing certain portions of Guppi under the LGPL, or...
> 
> Well given that its been packaged and doesn't appear under non-free in
> debian, plus the bottom of:
> 
> http://www.unidata.ucar.edu/cgi-bin/mfs/70/2865?54#mfs
> 
> says that a RMS-suggested change means that it does now not restrict
> free redistribution, etc. Also there is reference to GPL software using
> netCDF, which includes Grace.

It's perfectly possible for something to be free software (by
everyone's definition, including GNU's) and yet to be incompatible
with the GPL.  (See
http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses)

I wasn't suggesting that NetCDF isn't free software--it clearly is,
just under a license similar to the original BSD license.  (Actually,
a little bit more restrictive, in that the advertising clause applies
to any "product" or "publication" using NetCDF.)  Clearly it can be
freely distributed (the message above suggests that this perhaps was
not possible in the past).

I was just saying that it is clearly GPL-incompatible, for the same
reason that the original BSD license was.  This makes distribution of
software that is GPLed and uses NetCDF problematic.  (Although there
is no problem with a separate program that converts NetCDF to a
Guppi-readable format, of course.)

(Not having looked at the matter very closely, it is quite possible
that Grace distributions including NetCDF violate the GPL...sometimes
people aren't careful about such things; witness the Qt/KDE fiasco
before the Qt license was changed.  I'm not trying to start a flamewar
here, just making sure that the issues are clearly delineated...it can
cause a lot of controversy, at least, if you're not careful.)

> In addition, there are references elsewhere in their email archive which
> suggest that they think the software is 'public domain', which implies
> there should be *no* problem, or at least that they'd be amenable to a
> license-change, if it is now necessary.

The NetCDF license is quite explicit and is certainly not
public-domain.  However, as you say they may be amenable to a license
change if the matter is explained to them politely.  (The original HDF
license had an advertising clause, too, and they removed it after the
problems were explained to them.)

> Having looked at the docs for both briefly, HDF5 looks much more complex
> and overkill for 'just' data, but there's no reason it couldn't be added
> too :)

Are you sure you aren't thinking of the original HDF(4) API, which is
completely different and had all sorts of special stuff for storing
JPEG images, etcetera?  HDF5 is much cleaner and basically contains
two kinds of objects: multidimensional arrays (of various datatypes)
and groups (essentially virtual directories).  I added HDF5 support to
GNU Octave as an optional replacement for its native file format, and
found it quite well suited.

There are two questions here, though.  First, what file formats do you
want Guppi to be able to import?  The answer is clearly "as many as
possible," I would think.  A more difficult question, however, is
whether you want to select a particular open format as a "native" or
"interchange" format.  Here, you want lots of flexibility, the ability
to add metadata without preventing unrelated programs from reading the
data, etcetera, and the choices for formats become fewer and more
critical, and it may not be practical to support more than one.

Steven




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