[Bug 2304835] New: Review Request: naif-cspice - The NAIF CSPICE Toolkit and library by NASA
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
Bug ID: 2304835 Summary: Review Request: naif-cspice - The NAIF CSPICE Toolkit and library by NASA Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: attipaci@gmail.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org Target Milestone: --- Classification: Fedora
Spec URL: https://download.copr.fedorainfracloud.org/results/attipaci/naif-cspice/fedo... SRPM URL: https://download.copr.fedorainfracloud.org/results/attipaci/naif-cspice/fedo... Description:
The NAIF CSPICE Toolkit, together with data obtained from the JPL Horizons system, is commonly used for obtaining precise orbital data for planets, moons, asteroids, comets, and spacecraft. It can provide precise positions, velocities orientation, and in some cases shape information on the above mentions orbiting bodies.
The Navigation and Ancillary Information Facility (NAIF), acting under the directions of NASA's Planetary Science Division, has built an information system named "SPICE" (Spacecraft, Planet, Instrument, C-matrix, Events) to assist NASA scientists in planning and interpreting scientific observations from space-borne instruments, and to assist NASA engineers involved in modeling, planning and executing activities needed to conduct planetary exploration missions.
This package is redistributed with the explicit permission by NAIF, and in accordance with the upstream licensing terms.
Fedora Account System Username: attipaci
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
Attila Kovacs attipaci@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Doc Type|--- |If docs needed, set a value
--- Comment #1 from Attila Kovacs attipaci@gmail.com --- To the reviewer:
I have a few questions regarding the packaging...
1. The upstream source is published under the Apache 2.0 license, albeit with an exception. The exception relates to the redistribution of the _unmodified_ source only, as released by NAIF. I have obtained explicit permission from the NAIF manager to package CSPICE for Fedora. The packaging is necessarily a modification of the original distribution (both for the SRPM and the RPMS). As such the Fedora packages should be exempt from the upstream licensing exception entirely, and can be further distributed with the unmodified Apache 2.0 license. Nevertheless, the LICENSE file included in the distribution mentions the exception relating to the redistribution of the upstream code, just to be sure. I expect this should be OK. I just wanted to clarify it.
2. The upstream release is versioned as `N0067`. However, all prior releases of the library were API and ABI back-compatible to my knowledge. As such, I added the major version of 1 for the Fedora package, and set the minor version to 67. Is that OK, or should the Fedora package contain the original `N0067` in the version, e.g. a `1.N0067`?
3. The upstream did not include a license file, so I have created one that was approved by the NAIF manager in the prep stage. Would there be a better way to pull this license file from e.g. a separate git repo?
4. The prep stage modifies the unpacked upstream tarball as necessary to remove the prebuilt binaries, to build shared libraries (instead of static ones), and to skip the unwanted steps. Maybe this could live in a shell script externally also, e.g. in a separate git repo (e.g. same one as for the license)?
Thanks in advance for your review.
-- A.
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
--- Comment #2 from Attila Kovacs attipaci@gmail.com --- Somehow the automatic build did not seem to trigger. Here's a link to a Copr build: https://copr.fedorainfracloud.org/coprs/attipaci/naif-cspice/build/7907055/
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
Mattia Verga mattia.verga@proton.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mattia.verga@proton.me
--- Comment #3 from Mattia Verga mattia.verga@proton.me --- I currently do not have enough free time to perform a full review, however here are a couple of notes: - regarding the license file, it is better to ask on the @legal mailing list - in the past I avoided trying to package NAIF cspice exactly because it is a mess and hardly maintainable. Note that in Fedora we have calceph and python-calcephpy which can maybe fit for your needs in place of cspice.
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
--- Comment #4 from Attila Kovacs attipaci@gmail.com --- Thanks Mattia!
I know it's a busy time for Fedora, and there is no rush. We can continue the discussion (and review) after 41 is released :-). In the meantime I'll check out calceph. It looks interesting on first peek, and it looks like it supports most (if not all) JPL ephemeris types. I'll have to see in detail if it provides all the functionality I normally need... I'll also check with @legal on the licensing.
I don't disagree that CSPICE is a mess (it's definitely a dinosaur of sorts). And while it's not pretty by any measure, it's definitely proven and very reliable. You know you can trust its calculations to be correct, and that to me is worth more than anything when considering it for using it to run an observatory. I'm definitely willing to forgive the ancient build approach because of that. And while making the build work for Fedora was (is) a pain, I don't think it's unmaintainable precisely because this library has been in deep freeze for ~40 years. As such, once you 'patch' the build, it will likely work for another 40 years without further modification, as the upstream maintainers at NAIF are unlikely to change a thing about it any time soon.
So yes, it is a mess. But at least it's an unchanging mess.
In any case, I don't insist on a Fedora package. I can happily continue to build CSPICE for my own use. I just thought it might be useful to others who would like to use the library but don't necessarily want to go through the pain of building it themselves.
Let's resume the discussion until 41 comes out... :-)
cheers, -- A.
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
--- Comment #5 from Attila Kovacs attipaci@gmail.com --- Hi Mattia!
Now that f41 is out, I hope it is a good time to continue our discussion on packaging the NAIF CSPICE toolkit for Fedora.
In the meantime, I have checked out CALCEPH, and I agree that it offers a much cleaner interface together with a modern build (proper git repo included!).
However, it is also apparent that CALCEPH is not 100% reliable yet. All recent releases (including the last release in October 2024) have been fixing bugs relating to how it handles JPL ephemeris files. Until the dust settles, I'd be reluctant to use CALCEPH as a CSPICE replacement. I would argue that there is a need for packaging CSPICE because despite the ancient build it is time-tested code, and CALCEPH has a long way to go before it can make that same claim and can be used as a replacement for mission critical applications.
I hope you agree, and that we might proceed with packaging CSPICE.
I did also send a message to the @legal mailing list, but I have never received a response. However, it seems quite clear from the wording of the noted exception from the Apache 2.0 license that the exception applies only to the redistribution of the *unmodified* upstream toolkit (see https://naif.jpl.nasa.gov/naif/rules.html). As the Fedora RPM is not redistributing the unmodified upstream tarball, or the included binaries in any way, but rather a new product (source and binary RPMs) built from the appropriately modified upstream distribution, the packages created should fall under the vanilla Apache 2.0 license.
Perhaps you have more luck contacting @legal to confirm the above. Else, I can ask for clarification from NAIF themselves. As I mentioned, NAIF was 100% on board with packaging the toolkit for Linux, and I have an email which provides explicit permission to do so.
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
Mattia Verga mattia.verga@proton.me changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |182235 (FE-Legal) Flags| |fedora-review? Assignee|nobody@fedoraproject.org |mattia.verga@proton.me Status|NEW |ASSIGNED
--- Comment #6 from Mattia Verga mattia.verga@proton.me --- I think, to stay on the safe side, since upstream refers to a so-called "SPICE Software License" https://naif.jpl.nasa.gov/naif/rules.html it is best to submit the set of rules to https://github.com/spdx/license-list-XML and see what they think.
While the NAIF manager provides explicit permissions, that doesn't mean that the license is written in such a way it is admissible as FOSS. It's a pity, I know, but SPDX folks are lawyers... ;-)
Also, I don't think it is required to provide the license text outside from sources: "It is important to reiterate that in situations where the indicated license does not imply a requirement that the license be distributed along with the source/binaries, Fedora packagers are NOT required to manually include the full license text when it is absent from the source code, but are still encouraged to point out this issue to upstream and encourage them to remedy it." https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
Richard Fontana rfontana@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rfontana@redhat.com
--- Comment #7 from Richard Fontana rfontana@redhat.com --- I did not see any message on the Fedora legal list concerning CSPICE other than one from Mattia from a few years ago. I am not clear (from a very quick review) on what if any license is operative here. I see how these terms https://naif.jpl.nasa.gov/naif/rules.html are informally called a 'license', but they seem to have a SunRPC problem and possibly one additional problem (I did not understand the reference to "Modifications to SPICE kernels"). Also I do not see any indication anywhere that the Apache License 2.0 is applicable with or without an exception. I would suggest opening an issue at gitlab.com/fedora/legal/fedora-license-data if there is actually a license, or a license exception, to review. Otherwise this is too confusing to act on.
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
--- Comment #8 from Attila Kovacs attipaci@gmail.com --- Hi Richard,
No worries about the mailing list. I'm glad you are here to help. (When I sent the email, it said it was subject to approval -- and I never heard anything after that. Perhaps it was was declined to be distributed in the mailing list, or is still pending approval, or perhaps I sent it to the wrong email list...)
I'll try to address your points.
1. The Apache 2.0 is mentioned at https://nasa-pds.github.io/collaborate/jpl-pds-oss-policy.html, which is linked under section "SPICE and Open Source" in "SPICE Software License" page (https://naif.jpl.nasa.gov/naif/rules.html). They just hid it well :-).
2. SPICE kernels are data files that can be downloaded separately. These are not part of the toolkit (the software). And the packaging of the toolkit proposed here will not deal (or modify) the mentioned kernels data files (in any way). (In the future, I was thinking to package the kernels [data files] for Fedora too, but that's for another day, and they would provide the unmodified kernels.)
3. I'm not sure what the SunRPC problem is. (There is no mentioning of SunRPC anywhere..)
Last, but not least, following Mattia's suggestion I have submitted an application for a new SPDX license. Let's see what they come up with...
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
--- Comment #9 from Richard Fontana rfontana@redhat.com --- Okay, I think you may be misunderstanding what is said here https://nasa-pds.github.io/collaborate/jpl-pds-oss-policy.html#exemptions unless I am myself misunderstanding it. I read this as saying "The general policy now is to use the Apache License 2.0, but this policy does not apply to the SPICE toolkit (for now)". You seem to be interpreting this (plus the SPICE toolkit terms) as saying "Permitted modified versions of the toolkit are under the Apache License 2.0" but I don't see any basis for that conclusion.
In a comment above you say "I have obtained explicit permission from the NAIF manager to package CSPICE for Fedora. The packaging is necessarily a modification of the original distribution (both for the SRPM and the RPMS). As such the Fedora packages should be exempt from the upstream licensing exception entirely, and can be further distributed with the unmodified Apache 2.0 license." But it seems to me that if your package is truly under the Apache License 2.0 then it should be possible for a user to modify your package in such a way that they end up with something identical to the original distribution. If that is not the case, that would suggest that the license of your package is something like (in pseudo-SPDX-expressions) "Apache-2.0 WITH AdditionRef-SPICE-toolkit-SunRPC-type-restriction" which would not be allowed for Fedora since it's not an open source license.
The SunRPC principle is that licenses that contain prohibitions on distribution in isolation are not considered open source. The CSPICE terms say: "Redistribution of the unmodified SPICE Toolkit, such as from a mirror site, is prohibited without prior, written clearance from the NAIF manager. However, including the SPICE Toolkit modules (source and object code), documentation, and relevant SPICE Toolkit programs and allied User Guides as part of a package supporting a customer-built SPICE-based tool is entirely appropriate. This includes providing a new 3rd party interface to the SPICE Toolkit, subject to the relevant rules listed elsewhere on this webpage." Which seems to me to be a variant on a SunRPC restriction.
Obviously if NAIF decides in the future to conform to what appears to be the more enlightened present-day JPL open source policy and not insist on holding on to this pre-open-source approach, this can be revisited.
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
--- Comment #10 from Attila Kovacs attipaci@gmail.com --- Thanks Richard!
Now I understand. Thanks for explaining it. And, based on that I agree that their license may be to restrictive for Fedora. I'll let the NAIF Manager (Borys Semenov) know, and see if they want to do anything about it... I guess there is nothing we can do in the meantime.
https://bugzilla.redhat.com/show_bug.cgi?id=2304835
--- Comment #11 from Attila Kovacs attipaci@gmail.com --- PS. I wonder if packaging as RPMFusion (nonfree) would be an appropriate alternative with the existing licensing terms. Any thoughts?
package-review@lists.fedoraproject.org
-
bugzilla＠redhat.com