Re: pending interval-3.0.0 release

[Olaf Till]

On Mon, Aug 21, 2017 at 06:07:43AM +0200, Oliver Heimlich wrote:
> On 21.08.2017 04:20, Olaf Till wrote:
> > On Sun, Aug 20, 2017 at 09:27:38PM +0200, Oliver Heimlich wrote:
> >> On the other hand, the itl.mat
> >> file can also be edited easily, since it is just a data file, which can
> >> be processed with Octave.
> > 
> > This would possibly solve the problem, but I'm not sure that a data
> > file is really so easily edited.
> 
> It is a file with numeric data.  Editing it with Octave (for the use in
> this particular Octave package) is easier that editing the original
> file, since you have more options:  You can add data by concatenating
> the vectors and structs.  You can convert it into other formats using
> octave's output functions.  You can query it with indexing expressions,
> which is not even possible with a text editor on the original source.
> 
> For the Octave user, the itl.mat is everything he will ever need.  I
> only want to give him the .itl files to document the license details of
> itl.mat (and to advertise that external software).  We could as well not
> redistribute the .itl source files at all and document the copyright in
> COPYING explicitly.

Having read the GPL3 section 1 again, I really think we have to
provide the preferred form of making modifications (i.e the .itl
files) and all non-standard scripts (i.e. the python code) to generate
the result.

> >> Instead of hosting it on OF we could as well bundle it in the interval
> >> repository.
> > 
> > Yes, if you think you can do this...
> 
> It is just a matter of putting a particular version of the python
> scripts into a folder src/ITF1788.  Then, the user will receive that
> software together with the Octave packages' release.  I am hesitating to
> do this, because (1) I find this not important for the Octave package
> user (see above).  The external software is only important to produce
> test data in a format different from itl.mat for use in an unrelated
> interval library.

But it is your preferred format to make modifications for this
package, too.

> And (2), I want to keep that external software
> separate from the interval package to advertise its use in other
> interval libraries.  Having its source in the interval package's
> repository could leave the impression that it is part of the interval
> package and thus GPL'd and then some potential users would refrain from
> using it, see for example
> 
> https://github.com/JuliaIntervals/ValidatedNumerics.jl/issues/65

If you fear that, you could put a note at the head of "COPYING",
saying that some code of the ITF1788 module is included into the
package, but the module is normally got from elsewhere, and is not
under the GPL3 but the Apache2 license...

I think now including the code is better than the possibility below.

> >> Another possibility could be to publish it in some official
> >> Python repository, so you can pull it from there instead of Github.
> >> Would that end your worries?
> > 
> > Yes, this would also end this worry.
> 
> I'd prefer this compared to bundling the software.  However, I have
> little Python experience and first have to find out about publication.
> IIRC, the setup.py is important for that.  Last time I checked, there
> were at least two competing methods to do this (it's Python!).
> 
> Please look at the COPYING file in the tarball.  Currently, it tells the
> user that if he wanted to compile the test data for another interval
> library (or recompile the test data), he can find the compiler at a
> Github repository.  I find the case of recompilation rather unimportant
> (see above).  Should we really insist on having that generator available
> this way?  If we develop that idea further, does it mean that I also
> have to include the maintainer Makefile in the release tarball?  Even if
> you have that external dependency, it is not trivial to use it.  So, one
> could consider the Makefile rules to be part of the “missing source”.

So they are, if they are non-trivial... the problem, I think, is that
these rules should then actually go into the 'real' package Makefile
(src/Makefile). They can go under a target which is pre-built for
releases.

> > Unfortunately, there is a similar one: the external crlibm.mat is
> > distributed without sources.
> 
> This is a different matter.  The crlibm.mat has been converted manually
> (by me).  If you edited the original files, from which I have derived
> this work, there is no way to apply that change to the crlibm.mat.  So,
> I don't consider the original files as source files (=preferred form of
> makeing changes) anymore.  That's why they are not part of the release
> tarball.

I don't know how you converted it manually. But I think what we are
required to do in this case is to provide the original sources,
necessary scripts (if they are not 'generally available'), and a
script of yours which does what you had done manually.

I agree that the whole thing is exceptionally complicated. An
alternative would be to have all the external matter as build
dependencies, instead of distributing it in the package (but the
disadvantage is obvious, too).

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature