This is an interesting question and I would like to back the idea of making this available on COPR.
My 2 cents:
The package *itself* complies to COPR's licensing guidelines, making it eligible for distribution via that service, while the runtime dependency of MatLAB makes it an uneligible candidate for the official Fedora Repos

On Mon, Dec 3, 2018 at 2:49 PM Ankur Sinha <sanjay.ankur@gmail.com> wrote:
On Mon, Dec 03, 2018 12:41:41 +0100, Kevin Kofler wrote:
> Ankur Sinha wrote:
> > Since correctness is really important here, if upstream does not test
> > the toolboxes against Octave, we shouldn't either
>
> I think that if it runs at all, we should ship it.
>
> Some upstreams seem pretty conservative. E.g., SPM seems to have done a lot
> of work on Octave compatibility already, and the page seems to imply that it
> will more or less work, with some issues, they just do not support it still.
> Fedora, in contrast, is a forward-looking distribution that is about
> shipping Features First and with Freedom (i.e., no MATLAB!) included.

No, I disagree with this. These are not user-end applications where an
annoying bug may be fixed in a future release and make everyone happy.
These are toolboxes that are used for analyses of data, and the results
from the analyses contribute to science. Then, other studies will build
on these results, and so on. If there's any hint of lack of correctness,
being conservative makes sense---it is too much of a risk. A minor issue
can undo years of work and progress.

It would be very bad if an issue in our provision of the toolbox with
Octave resulted in a retraction, later on, for example.

If a researcher uses a MATLab toolbox with Octave, it is their
responsibility to check for correctness. If we provide them, it is ours,
and this is not a responsibility we have the man power to take on. We'd
rather rely on upstream.

> In addition, they also write that the issues are mainly in the GUI, not in
> the computation backend where correctness is important.

But they do not say that they test for correctness against Octave
either. We are only speaking about SPM as an example here, and I can
reach out to upstream to confirm, but there will be other toolboxes that
do not discuss Octave compatibility at all and may not have the
resources to look into it either---so this is more general issue.

>
> > - Use COPR to provide Matlab only toolboxes (as I think the above rule
> >   does not apply to COPR).
> >
> > Would that be OK?
>
> I think it is NOT OK, because software in Copr is also supposed to comply
> with Fedora licensing policies:
> https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr
>
> Now, arguably, the package itself is not improperly licensed,

Not "arguably"--very clearly :)
(We do not consider non free toolboxes at all)

> but if the
> Copr is documented as working only with an external proprietary interpreter
> (whether or not that is actually true, though as far as I know you need to
> actually compile the mex file against Octave for it to work with Octave, so
> if you only package the binary for MATLAB, it won't work without MATLAB),
> that is stretching the rules.

Sure. I do agree with this. I've said before that we'd really prefer if
we didn't have to use/support MATLab at all. But that's not the case, so
we're trying to see what can be done here keeping the realities of the
MATLab eco-system in mind.

In the meantime, we will start by providing toolboxes that clearly
document Octave support, and simply documenting that users must get the
others themselves.

--
Thanks,
Regards,

Ankur Sinha "FranciscoD"

https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


--
Chris