octave-maintainers
[Top][All Lists]
Advanced

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

Re: pending interval-3.0.0 release


From: Olaf Till
Subject: Re: pending interval-3.0.0 release
Date: Mon, 21 Aug 2017 17:32:27 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Aug 21, 2017 at 04:42:07PM +0200, Oliver Heimlich wrote:
> <snip>
> 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.
> <snip>
> 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.
> <snip>
> 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.
> <snip>
> > 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 left those parts of your post above which seem to be related to my
next remarks.)

I think the argumentation with 'only your' preferred source and 'for
the user it's sufficient...' is a bit adventurous. If we provide GPLed
code, even if you have the sole copyright, we should provide the code
in a way in which this license makes sense.

I believe that the data files are not sufficient as sources, and that
some script to generate them should be provided (this in particular
relates to your last two remarks above -- the script would need to
process the original sources, I think).

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

This means that we can't come to an agreement over this.

But since this is a controversy between two administrators, a solution
could be that you publish the package despite my disapproving.

Olaf

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]