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
Ankur Sinha wrote:
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).
Generally no, if this guideline applies:
https://fedoraproject.org/wiki/Packaging:What_Can_Be_Packaged#Packages_which...
Depends how much of a loophole you want if using octave is a viable runtime option.
-- Rex
Ankur Sinha wrote:
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
Hello,
On Mon, Dec 03, 2018 00:44:15 +0100, Kevin Kofler wrote:
<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?
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.
In addition, they also write that the issues are mainly in the GUI, not in the computation backend where correctness is important.
- 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-i...
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
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-i...
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.
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-i...
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
Christian Glombek wrote:
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
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
"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
On Mon, Dec 03, 2018 12:56:37 -0600, Rex Dieter wrote:
Christian Glombek wrote:
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
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
"You agree not to use Copr to upload software code or other material (“Material”) that: ... 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.
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.
On Mon, Dec 03, 2018 at 07:39:31PM +0000, Ankur Sinha wrote:
On Mon, Dec 03, 2018 12:56:37 -0600, Rex Dieter wrote:
Christian Glombek wrote:
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
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
"You agree not to use Copr to upload software code or other material (“Material”) that: ... 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 legal@lists.fedoraproject.org.
Zbyszek
Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Dec 03, 2018 at 07:39:31PM +0000, Ankur Sinha wrote:
On Mon, Dec 03, 2018 12:56:37 -0600, Rex Dieter wrote:
Christian Glombek wrote:
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
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
"You agree not to use Copr to upload software code or other material (“Material”) that: ... 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 legal@lists.fedoraproject.org.
This is a policy decision (for fesco), not a legal one, imho.
-- Rex
On Tue, Dec 04, 2018 at 06:58:39AM -0600, Rex Dieter wrote:
Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Dec 03, 2018 at 07:39:31PM +0000, Ankur Sinha wrote:
On Mon, Dec 03, 2018 12:56:37 -0600, Rex Dieter wrote:
Christian Glombek wrote:
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
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
"You agree not to use Copr to upload software code or other material (“Material”) that: ... 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 legal@lists.fedoraproject.org.
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
Zbigniew Jędrzejewski-Szmek wrote:
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
On Mon, Dec 3, 2018 at 9:52 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Dec 03, 2018 at 07:39:31PM +0000, Ankur Sinha wrote:
On Mon, Dec 03, 2018 12:56:37 -0600, Rex Dieter wrote:
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
"You agree not to use Copr to upload software code or other material (“Material”) that: ... 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/devel@lists.fedoraproject.org/...
Ben Rosser
On Tue, Dec 04, 2018 14:12:35 +0100, Ben Rosser wrote:
<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 instance:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
I've also filed an issue against COPR regarding this now: https://bugzilla.redhat.com/show_bug.cgi?id=1656026
On Mon, 3 Dec 2018 19:39:31 +0000 Ankur Sinha sanjay.ankur@gmail.com wrote:
On Mon, Dec 03, 2018 12:56:37 -0600, Rex Dieter wrote:
Christian Glombek wrote:
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
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
"You agree not to use Copr to upload software code or other material (“Material”) that: ... 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.
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.
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.
On Mon, Dec 03, 2018 13:50:58 -0700, stan wrote:
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_Lic...) or blocking the "FE-Legal" blocker bug if on a bugzilla review ticket (https://fedoraproject.org/wiki/Package_Review_Process#Special_blocker_ticket...)
On Mon, Dec 03, 2018 at 09:05:58PM +0000, Ankur Sinha wrote:
On Mon, Dec 03, 2018 13:50:58 -0700, stan wrote:
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_Lic...) or blocking the "FE-Legal" blocker bug if on a bugzilla review ticket (https://fedoraproject.org/wiki/Package_Review_Process#Special_blocker_ticket...)
I already sent a question to legal@fp.o regarding the issues in this thread. It seems to be stuck in moderation.
Zbyszek
On Mon, Dec 03, 2018 22:03:57 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Dec 03, 2018 at 09:05:58PM +0000, Ankur Sinha wrote:
On Mon, Dec 03, 2018 13:50:58 -0700, stan wrote:
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_Lic...) or blocking the "FE-Legal" blocker bug if on a bugzilla review ticket (https://fedoraproject.org/wiki/Package_Review_Process#Special_blocker_ticket...)
I already sent a question to legal@fp.o regarding the issues in this thread. It seems to be stuck in moderation.
Thanks very much. :)
On 12/3/18 8:48 AM, Ankur Sinha wrote:
On Mon, Dec 03, 2018 12:41:41 +0100, Kevin Kofler 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.
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.
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.
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.
devel@lists.stg.fedoraproject.org
-
Ankur Sinha -
Ben Rosser -
Christian Glombek -
Kevin Kofler -
Przemek Klosowski -
Rex Dieter -
stan -
Zbigniew Jędrzejewski-Szmek