Re: pending interval-3.0.0 release

[Oliver Heimlich]

On 21.08.2017 13:08, Olaf Till wrote:
> 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.

No, I disagree.  They are not the preferred form of making
modifications.  See below.

Even if this would be the case, in COPYING the URL is mentioned, where
the source code can be downloaded, which would also be sufficient.
However, it is not needed.

Also, I own the sole copyright holder for most of these files.  The only
exceptions being some files that have been originally licensed under the
Apache License 2.0, so I don't even have the obligation to provide any
original code form for them if I don't want.  I could just delete any
.itl files from Octave Forge and only put the itl.mat test data there.

>>>> 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.

The .itl files are the preferred format for me and only me, because I
want to make sure that the very same test data can be used in any other
interval library as well, not necessarily in Octave.

For everybody else (= licensee), the itl.mat file is perfectly fine to
be edited to be used with this package.

This has been different with earlier releases, where there was no
itl.mat and only a bunch of generated .tst files in the tarball, which
nobody would want to edit.  Starting with interval 3.0.0 this changes.

>> 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
...
> 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.
>>
>> ...  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.

Yes, this could be done.  However, I think that it is not needed and
should not be done.

I would rather remove any connection to the python scripts and .itl
files from Octave Forge and produce the test data somewhere else to
import it into the package repository when I get updates from other
interval researchers.

>>> 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,

Why should I have to redistribute the original work when I distribute a
derivative work?

> necessary scripts (if they are not 'generally available'), and a
> script of yours which does what you had done manually.

There is no script and never has been.  Why should I make a script?
This doesn't make sense.

> 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).

Yes it is complicated and at the beginning I haven't been sure about
what to do.  But after this discussion my opinion is pretty firm that
the current release arrangement is good and I don't see a need to change
anything regarding the test data files.

If you still have objections regarding the .itl files I can offer to
remove them entirely from the repository and only put the static test
data (itl.mat) in the repository.  Then there will be no confusion about
which rest data files to edit in the package release tarball.

Oliver