As built in the Fedora infrastructure, Flatpak containers are composed of packages that are not of direct interest to users: packages built with prefix=/app. The modules that these packages come from should not be included in the modular compose.
Since we're not composing these packages in a normal way, the source code distribution mechanism we normally use - put the srpms into the compose - isn't applicable.
So I wanted to check in on what we consider our legal (and other) responsibilities for distributing and retaining source in this situation. This will figure in figuring out a final plan for how we handle tagging/garbage collecting Flatpak modules in Koji.
I am not a lawyer and this is not legal advice... Tagging @spot to chime in on that score.
Is src.fedoraproject.org sufficient? It clearly represents the preferred mechanism for working with the source code - it is what someone would want to use if fixing a problem.
I'll add that, unlike traditional RPMs, the module builds DO actually encode the exact git hash that was used for the build in the output modulemd (for example, see the data.xmd.rpms section of this nodejs module build.
data.xmd.rpms
With this, there's a clear mapping back to src.fedoraproject.org for the builds, so I would expect that this would satisfy the requirement of shipping the source for any build we do. We can always write up a public document (or even a script) to clone the git repos of a module's components and check out the specific commits. This is probably better and less storage-intensive than an SRPM-based approach.
The legal questions need to be answered by the Fedora Legal Team @spot IMHO.
I'll add that, unlike traditional RPMs, the module builds DO actually encode the exact git hash that was used for the build in the output modulemd (for example, see the data.xmd.rpms section of this nodejs module build. With this, there's a clear mapping back to src.fedoraproject.org for the builds, so I would expect that this would satisfy the requirement of shipping the source for any build we do. We can always write up a public document (or even a script) to clone the git repos of a module's components and check out the specific commits. This is probably better and less storage-intensive than an SRPM-based approach.
Given that there is a clear mapping back to src.fedoraproject.org to the exact git revision for the source tree (and assuming that the source tree at that git revision is always accessible), I feel like this will meet our compliance requirement. We should clearly (and prominently) document how a user can get to the corresponding source for a binary flatpak that is generated (and distributed) by us. Having a script which does this for a user would also be very nice.
My only worry is that src.fedoraproject.org might somehow no longer contain the matching source due to something in the lookaside cache going away, which we had not worried about until now because the SRPMs always contain that source tarball. I do not know if this is a practical concern though, I defer to someone in rel-eng to confirm that this is possible/impossible. If it is possible that src.fp.o would not have the matching source (even if unlikely), then we cannot rely on it to meet our source compliance.
@kevin, @mohanboddu, @puiterwijk : Can one of you answer the question above regarding the lookaside cache?
The only time we ever delete anything from the lookaside cache is when asked to for legal reasons. Otherwise sources there should be assumed to stay around forever.
Then I see no reason why src.fp.o cannot meet your source compliance requirements. Please do document/script it though.
OK, src.fp.o + the lookaside cache provide permanent and unambiguous mapping to the sources using for the build based on the git hash and this satisfies the legal requirements. Let's close this.
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.