Packaging FOSS that requires MATLab at runtime

[Ankur Sinha]

Hello,

While packaging software for NeuroFedora[1], we've got quite a few
MATLab toolboxes that are commonly used in scientific research on our
list. SPM[2] is a good example. It is *widely* used in NeuroImaging
research. While it is somewhat compatible with Octave, upstream does not
support it[3]. Since correctness is paramount with such toolboxes, at
present, they must be used with MATLab.

What do we think of including such toolboxes in Fedora? They are:
- open source
- require MATLab only at runtime (so they do not need MATLab to build).

I would personally prefer if MATLab wasn't used in research, and the
scientific community is certainly moving to Python. However, the fact is
this will take time and there are current eco-systems around MATLab.

[1] https://pagure.io/neuro-sig/NeuroFedora/issues
[2] https://en.wikibooks.org/wiki/SPM
[3] https://en.wikibooks.org/wiki/SPM/Octave

[Rex Dieter]

Post by Ankur Sinha
Hello,
While packaging software for NeuroFedora[1], we've got quite a few
MATLab toolboxes that are commonly used in scientific research on our
list. SPM[2] is a good example. It is *widely* used in NeuroImaging
research. While it is somewhat compatible with Octave, upstream does not
support it[3]. Since correctness is paramount with such toolboxes, at
present, they must be used with MATLab.
- open source
- require MATLab only at runtime (so they do not need MATLab to build).

Generally no, if this guideline applies:

https://fedoraproject.org/wiki/Packaging:What_Can_Be_Packaged#Packages_which_are_not_useful_without_external_code

Depends how much of a loophole you want if using octave is a viable runtime
option.

-- Rex

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedor

[Kevin Kofler]

Post by Ankur Sinha
While packaging software for NeuroFedora[1], we've got quite a few
MATLab toolboxes that are commonly used in scientific research on our
list. SPM[2] is a good example. It is *widely* used in NeuroImaging
research. While it is somewhat compatible with Octave, upstream does not
support it[3]. Since correctness is paramount with such toolboxes, at
present, they must be used with MATLab.

The rule in Fedora is: If you want this to be in Fedora, this has to be
packaged for Octave with a Requires: octave, even if upstream does not
support it. Software in Fedora cannot depend on software that is not part of
Fedora.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.or

[Ankur Sinha]

Hello,

<snip>
The rule in Fedora is: If you want this to be in Fedora, this has to be
packaged for Octave with a Requires: octave, even if upstream does not
support it. Software in Fedora cannot depend on software that is not part of
Fedora.

Thanks for your replies, Rex, Kevin.

Since correctness is really important here, if upstream does not test
the toolboxes against Octave, we shouldn't either---we don't want users
to interpret the availability of a toolbox for Octave in Fedora as
upstream-support. I think we could:

- provide toolboxes where upstream supports Octave in the Fedora
repositories (for both Octave and Matlab)
- Use COPR to provide Matlab only toolboxes (as I think the above rule
does not apply to COPR).

Would that be OK?

[Kevin Kofler]

Post by Ankur Sinha
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.

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

Post by Ankur Sinha
- 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, 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.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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.or

[Ankur Sinha]

Post by Kevin Kofler

Post by Ankur Sinha
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.

Post by Kevin Kofler
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.

Post by Kevin Kofler

Post by Ankur Sinha
- 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
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)

Post by Kevin Kofler
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.

[Christian Glombek]

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

Post by Kevin Kofler

Post by Kevin Kofler

Post by Ankur Sinha
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

Post by Kevin Kofler
of work on Octave compatibility already, and the page seems to imply

that it

Post by Kevin Kofler
will more or less work, with some issues, they just do not support it

still.

Post by Kevin Kofler
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.

Post by Kevin Kofler
In addition, they also write that the issues are mainly in the GUI, not

in

Post by Kevin Kofler
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.

Post by Kevin Kofler

Post by Ankur Sinha
- 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

https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr

Post by Kevin Kofler
Now, arguably, the package itself is not improperly licensed,

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

Post by Kevin Kofler
but if the
Copr is documented as working only with an external proprietary

interpreter

Post by Kevin Kofler
(whether or not that is actually true, though as far as I know you need

to

Post by Kevin Kofler
actually compile the mex file against Octave for it to work with Octave,

so

Post by Kevin Kofler
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
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

[Rex Dieter]

Post by Christian Glombek
This is an interesting question and I would like to back the idea of
making this available on COPR.
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

https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr

"You agree not to use Copr to upload software code or other material
(“Material”) that:
...
violates any rules or guidelines of the Fedora Project;
"

In short, IMHO, if it's not good for fedora, but this, it is not good for
copr either.


-- Rex


_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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.

[Ankur Sinha]

Post by Kevin Kofler

Post by Christian Glombek
This is an interesting question and I would like to back the idea of
making this available on COPR.
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

https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr
"You agree not to use Copr to upload software code or other material
...
violates any rules or guidelines of the Fedora Project;
"

Surely that's not meant to be interpreted as "your packages must follow
the Fedora packaging guidelines", for if it is, packages in COPR will
need review too.

Post by Kevin Kofler
In short, IMHO, if it's not good for fedora, but this, it is not good for
copr either.

My personal summary of the discussion is as follows:

- these packages are FOSS but do not conform to the Fedora packaging
guidelines as they require non FOSS to run and, therefore, cannot be
included in the main Fedora repos.
- these packages are FOSS and, therefore, can be supplied via COPR where
packages are not required to conform strictly to the Fedora packaging
guidelines.
- the current argument against including these packages in COPR is a
philosophical one, not a technical/policy one---one that I tend to
agree with at this moment.

[stan]

On Mon, 3 Dec 2018 19:39:31 +0000

Post by Ankur Sinha

Post by Kevin Kofler

Post by Christian Glombek
This is an interesting question and I would like to back the idea
of making this available on COPR.
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

https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr
"You agree not to use Copr to upload software code or other
...
violates any rules or guidelines of the Fedora Project;
"

Surely that's not meant to be interpreted as "your packages must
follow the Fedora packaging guidelines", for if it is, packages in
COPR will need review too.

Post by Kevin Kofler
In short, IMHO, if it's not good for fedora, but this, it is not
good for copr either.

- these packages are FOSS but do not conform to the Fedora packaging
guidelines as they require non FOSS to run and, therefore, cannot be
included in the main Fedora repos.
- these packages are FOSS and, therefore, can be supplied via COPR
where packages are not required to conform strictly to the Fedora
packaging guidelines.
- the current argument against including these packages in COPR is a
philosophical one, not a technical/policy one---one that I tend to
agree with at this moment.

Isn't this kind of thing a question for legal? Is there any liability
for fedora that arises from using encumbered software from FOSS? I've
seen other people refer to running things by legal on this list. I'm
not sure how to do it, though.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists

[Ankur Sinha]

Post by stan
Isn't this kind of thing a question for legal? Is there any liability
for fedora that arises from using encumbered software from FOSS? I've
seen other people refer to running things by legal on this list. I'm
not sure how to do it, though.

I wouldn't think so. Legal clears up unclear licensing. The software
here (SPM for example) is clearly under an Open source license. We do
not consider non free software at all.

You can get in touch with legal by e-mailing them on their mailing list
(https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Discussion_of_Licensing)
or blocking the "FE-Legal" blocker bug if on a bugzilla review ticket
(https://fedoraproject.org/wiki/Package_Review_Process#Special_blocker_tickets)

[Zbigniew Jędrzejewski-Szmek]

Post by Ankur Sinha

Post by stan
Isn't this kind of thing a question for legal? Is there any liability
for fedora that arises from using encumbered software from FOSS? I've
seen other people refer to running things by legal on this list. I'm
not sure how to do it, though.

I wouldn't think so. Legal clears up unclear licensing. The software
here (SPM for example) is clearly under an Open source license. We do
not consider non free software at all.
You can get in touch with legal by e-mailing them on their mailing list
(https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Discussion_of_Licensing)
or blocking the "FE-Legal" blocker bug if on a bugzilla review ticket
(https://fedoraproject.org/wiki/Package_Review_Process#Special_blocker_tickets)

I already sent a question to ***@fp.o regarding the issues in this
thread. It seems to be stuck in moderation.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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.

[Ankur Sinha]

Post by Zbigniew Jędrzejewski-Szmek

Post by Ankur Sinha

Post by stan
Isn't this kind of thing a question for legal? Is there any liability
for fedora that arises from using encumbered software from FOSS? I've
seen other people refer to running things by legal on this list. I'm
not sure how to do it, though.

I wouldn't think so. Legal clears up unclear licensing. The software
here (SPM for example) is clearly under an Open source license. We do
not consider non free software at all.
You can get in touch with legal by e-mailing them on their mailing list
(https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Discussion_of_Licensing)
or blocking the "FE-Legal" blocker bug if on a bugzilla review ticket
(https://fedoraproject.org/wiki/Package_Review_Process#Special_blocker_tickets)

thread. It seems to be stuck in moderation.

Thanks very much. :)

[Zbigniew Jędrzejewski-Szmek]

Post by Ankur Sinha

Post by Kevin Kofler

Post by Christian Glombek
This is an interesting question and I would like to back the idea of
making this available on COPR.
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

https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr
"You agree not to use Copr to upload software code or other material
...
violates any rules or guidelines of the Fedora Project;
"

Surely that's not meant to be interpreted as "your packages must follow
the Fedora packaging guidelines", for if it is, packages in COPR will
need review too.

That's my understanding too, since that would make copr semi-pointless.
But strictly speaking the text "any rules or guidelines", which, when interpreted
literally, includes the packaging guidelines.

I fired off a question to ***@lists.fedoraproject.org.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lists.fedoraproject.org

[Rex Dieter]

Post by Zbigniew Jędrzejewski-Szmek

Post by Ankur Sinha

Post by Kevin Kofler

Post by Christian Glombek
This is an interesting question and I would like to back the idea of
making this available on COPR.
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

https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr
"You agree not to use Copr to upload software code or other material
...
violates any rules or guidelines of the Fedora Project;
"

Surely that's not meant to be interpreted as "your packages must follow
the Fedora packaging guidelines", for if it is, packages in COPR will
need review too.

That's my understanding too, since that would make copr semi-pointless.
But strictly speaking the text "any rules or guidelines", which, when
interpreted literally, includes the packaging guidelines.

This is a policy decision (for fesco), not a legal one, imho.

-- Rex
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/lis

[Zbigniew Jędrzejewski-Szmek]

Post by Rex Dieter

Post by Zbigniew Jędrzejewski-Szmek

Post by Ankur Sinha

Post by Kevin Kofler

Post by Christian Glombek
This is an interesting question and I would like to back the idea of
making this available on COPR.
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

https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr
"You agree not to use Copr to upload software code or other material
...
violates any rules or guidelines of the Fedora Project;
"

Surely that's not meant to be interpreted as "your packages must follow
the Fedora packaging guidelines", for if it is, packages in COPR will
need review too.

That's my understanding too, since that would make copr semi-pointless.
But strictly speaking the text "any rules or guidelines", which, when
interpreted literally, includes the packaging guidelines.

This is a policy decision (for fesco), not a legal one, imho.

It's a two-level decision: if legal says "no", then we don't have much
choice. If legal says "ok", fesco could still say "no". But I don't
see any reason for fesco to do this.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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.fedorap

[Kevin Kofler]

Post by Zbigniew Jędrzejewski-Szmek
It's a two-level decision: if legal says "no", then we don't have much
choice. If legal says "ok", fesco could still say "no". But I don't
see any reason for fesco to do this.

The software is almost certainly not illegal to distribute. The question is
whether it is compatible with the ideal of freedom that Fedora is about.
After all, Copr uses infrastructure provided by Fedora. That is the policy
decision FESCo should make.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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.fedoraprojec

[Ben Rosser]

On Mon, Dec 3, 2018 at 9:52 PM Zbigniew Jędrzejewski-Szmek

Post by Zbigniew Jędrzejewski-Szmek

Post by Ankur Sinha

Post by Kevin Kofler
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr
"You agree not to use Copr to upload software code or other material
...
violates any rules or guidelines of the Fedora Project;
"

Surely that's not meant to be interpreted as "your packages must follow
the Fedora packaging guidelines", for if it is, packages in COPR will
need review too.

That's my understanding too, since that would make copr semi-pointless.
But strictly speaking the text "any rules or guidelines", which, when interpreted
literally, includes the packaging guidelines.

I think this has been brought up before, and it was concluded that
this language in the copr guidelines is much too broad and we should
look at changing the wording. In this thread from September, for
instance:

https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/thread/FZZVKXUOW3TNUNX2JV2JGPUWFFGS3V3C/#426PWWHO6FVWBQSC6PP2D5HIKBONY6UE

Ben Rosser
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@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/***@lis

[Ankur Sinha]

<snip>
I think this has been brought up before, and it was concluded that
this language in the copr guidelines is much too broad and we should
look at changing the wording. In this thread from September, for

I've also filed an issue against COPR regarding this now:
https://bugzilla.redhat.com/show_bug.cgi?id=1656026

[Przemek Klosowski]

Post by Ankur Sinha

Post by Kevin Kofler

Post by Ankur Sinha
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.

I assume that the package you propose would work with Octave and Matlab
co-installed. If it didn't, I would think it would be unacceptable,
because it would effectively be evicting Octave.

It seems to me that there has to be some sort of O.vs.M. configuration,
so people who don't want to take the risk can still use the Matlab
setup. We are not making life harder for those folks: they have to
manually install Matlab regardless whether the package Requires Octave
or not.

Post by Ankur Sinha
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.

Software licenses usually claim that "the customer is solely responsible
for selecting the software and determining the software’s suitability
for the customer’s particular purpose". I would not be surprised if
Matlab license contained a similar clause, and the researchers should
check for correctness anyway.

Post by Ankur Sinha
I think that if it runs at all, we should ship it.

It seems to me that 'runs at all' is too low of a bar; I would
personally prefer that it passes some regression tests. Providing such
tests, which presumably would also allow people to sanity-check against
both back ends, would be a nice added value for both end users and for
Fedora.