11:35 a.m.
This is a “heads-up” email about a (non-breaking) major version update
with a (non-disruptive) license change in the fast_float package in Rawhide.
Once I have a successful scratch build in the PR[1], I plan to update
fast_float from 4.0.0 to 5.0.0.
ABI changes are impossible because this is a header-only library; the
upstream release notes[2] do not describe any breaking API changes; and
I have verified compatibility of all dependent packages via local mock
builds. Given all of that, I am not treating this as a breaking update
even though the major version number is incremented.
A significant change in this release is the addition of Boost (BSL-1.0)
as an additional disjunctive license option. The package license
therefore changes from
Apache-2.0 OR MIT
to
Apache-2.0 OR MIT OR BSL-1.0
Since fast_float is a header-only library, and our guidelines treat
these as a kind of static library, directly-dependent packages
should—strictly speaking—include fast_float’s SPDX license expression in
their own. I will take care of the necessary change for c4core[3].
[1] https://src.fedoraproject.org/rpms/fast_float/pull-request/5
[2] https://github.com/fastfloat/fast_float/releases/tag/v5.0.0
[3] https://src.fedoraproject.org/rpms/c4core/pull-request/8
4:37 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On 26/05/2023 18:35, Ben Beasley wrote:
Since fast_float is a header-only library, and our guidelines treat
these as a kind of static library, directly-dependent packages
should—strictly speaking—include fast_float’s SPDX license expression in
their own
Only if they use the version built into the source archive. If they're
using packaged, they don't have to.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:08 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On Sat, May 27, 2023 at 11:37 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 26/05/2023 18:35, Ben Beasley wrote:
> Since fast_float is a header-only library, and our guidelines treat
> these as a kind of static library, directly-dependent packages
> should—strictly speaking—include fast_float’s SPDX license expression in
> their own
Only if they use the version built into the source archive. If they're
using packaged, they don't have to.
No, this information is outdated. Statically linked components must be
taken into consideration, whether bundled or not.
This mostly affects header-only C/C++ libraries and Rust crates (and
theoretically, this would apply to Go and other languages which
statically compile their binaries, as well ...).
Fabio
7:13 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On 27/05/2023 13:08, Fabio Valentini wrote:
No, this information is outdated. Statically linked components must
be
taken into consideration, whether bundled or not.
I only found this:
Some upstream projects bundle code copied from other upstream
projects (a practice some communities sometimes call "vendoring"). In certain
cases Fedora permits packaging of such projects including the bundled dependencies. In
some other cases, a Fedora package may itself bundle dependencies that are not separately
packaged in Fedora. In these cases, assuming the bundled dependencies are built or
otherwise included in the packaged binary, the License: field must reflect the licenses
covering the bundled code.
https://docs.fedoraproject.org/en-US/legal/license-field/#_bundled_or_ven...
I can't find any information about packaged header-only libraries. Could
you post a link please?
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:33 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On Sat, May 27, 2023, 14:15 Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
On 27/05/2023 13:08, Fabio Valentini wrote:
> No, this information is outdated. Statically linked components must be
> taken into consideration, whether bundled or not.
I only found this:
> Some upstream projects bundle code copied from other upstream projects
(a practice some communities sometimes call "vendoring"). In certain cases
Fedora permits packaging of such projects including the bundled
dependencies. In some other cases, a Fedora package may itself bundle
dependencies that are not separately packaged in Fedora. In these cases,
assuming the bundled dependencies are built or otherwise included in the
packaged binary, the License: field must reflect the licenses covering the
bundled code.
https://docs.fedoraproject.org/en-US/legal/license-field/#_bundled_or_ven...
I can't find any information about packaged header-only libraries. Could
you post a link please?
https://docs.fedoraproject.org/en-US/legal/license-field/#_conjunctive_an...
"If your package is built from files under multiple distinct licenses, then
the License: field must reflect this by using the AND operator."
This doesn't explicitly mention statically linked binaries / header-only
libraries, but it's clear that this rule applies to these situations as
well (after all, binaries *are* built from project sources that have
distinct licenses). I don't see how C/C++ header-only libraries (or Go
packages, fwiw) should be treated differently than Rust crates.
It would probably be better if the legal docs made this explicit, and made
Rust no longer a special case. The fact that only Rust is called out is an
artifact of this rule having been moved from the Rust Packaging Guidelines
to the legal docs, but other languages that are in similar situations
didn't even have guidelines for this case.
Fabio
PS: Sent from my phone, sorry for possibly bad formatting.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
8:35 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On 5/27/23 08:33, Fabio Valentini wrote:
This doesn't explicitly mention statically linked binaries /
header-only libraries, but it's clear that this rule applies to these
situations as well (after all, binaries *are* built from project
sources that have distinct licenses). I don't see how C/C++
header-only libraries (or Go packages, fwiw) should be treated
differently than Rust crates.
I agree that C/C++ header-only libraries are effectively the same case
as Rust crates. I do think it is fair to point out that the distinction
between "header” and “source” files in C and C++ is mostly cultural
rather than technical, and that header-only libraries represent a
somewhat arbitrary line in the sand when it comes to considering the
licenses of headers. I’m not complaining about that arbitrariness; it’s
probably necessary.
I doubt that anyone expects it would be practical, or useful to
end-users, to consider every header used in the build in the license
expression, yet header-only libraries are not technically a special
case. The headers of C++ and even C shared-library packages may contain
just as much template or inline code as header-only libraries. Just look
at the standard library implementations of both languages for an
example. This code is compiled into the caller just as a header-only
library would be, but it’s my understanding that we don’t consider it in
the license expression as long as the dependency also has a
dynamically-linked portion.
Asking packagers to manually track licenses of all included headers
(which may change without any change to the package’s spec file or
sources) seems like it would be ridiculously burdensome; so does asking
them to assess some kind of measure of “triviality.” We are left with
considering only header-only libraries (and static libraries, which are
discouraged but occasionally necessary), not because this exactly
reflects the objective truth, but because it seems to be the last
plausibly reasonable step before a descent into madness.
I am not sure that it is possible for Fedora’s policy in this area to be
both practically usable and perfectly logically consistent. It would
certainly be useful to document it a little more clearly.
2:42 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On 27/05/2023 14:33, Fabio Valentini wrote:
It would probably be better if the legal docs made this explicit, and
made Rust no longer a special case. The fact that only Rust is called
out is an artifact of this rule having been moved from the Rust
Packaging Guidelines to the legal docs, but other languages that are in
similar situations didn't even have guidelines for this case.
I have the opposite opinion. Even Rust packages should only include to
the License tag libraries bundled into the source tarball.
All other licenses can be traced, if necessary, from the corresponding
-devel packages.
If one had to manually track each header-only library in the dependency
tree, check their licenses, and document them in the License tag, that
would add useless extra work to the maintainers. It must be automated.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:41 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On Sun, May 28, 2023 at 9:43 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 27/05/2023 14:33, Fabio Valentini wrote:
> It would probably be better if the legal docs made this explicit, and
> made Rust no longer a special case. The fact that only Rust is called
> out is an artifact of this rule having been moved from the Rust
> Packaging Guidelines to the legal docs, but other languages that are in
> similar situations didn't even have guidelines for this case.
I have the opposite opinion. Even Rust packages should only include to
the License tag libraries bundled into the source tarball.
All other licenses can be traced, if necessary, from the corresponding
-devel packages.
If one had to manually track each header-only library in the dependency
tree, check their licenses, and document them in the License tag, that
would add useless extra work to the maintainers. It must be automated.
Sure, I don't like the way we need to do this for Rust packages either ...
But like it or not, your opinion doesn't really matter if Red Hat
Legal says we need to do it this way.
At least for Rust packages, we do have some amount of automation now
to help with this chore.
Fabio
2:31 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On 28/05/2023 17:41, Fabio Valentini wrote:
At least for Rust packages, we do have some amount of automation now
to help with this chore.
I think %autolicense should be added to the rpmautospec project. It will
automatically extract license tags from all BRs "-static" or "crate()"
and concatenate them with AND.
Example:
# main project - MIT
License: MIT AND %autolicense
In future it will be able to use some license validators and replace the
entire License tag:
License: %autolicense
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:07 a.m.
New subject: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a
license change
On Mon, May 29, 2023 at 9:32 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 28/05/2023 17:41, Fabio Valentini wrote:
> At least for Rust packages, we do have some amount of automation now
> to help with this chore.
I think %autolicense should be added to the rpmautospec project. It will
automatically extract license tags from all BRs "-static" or
"crate()"
and concatenate them with AND.
Example:
# main project - MIT
License: MIT AND %autolicense
In future it will be able to use some license validators and replace the
entire License tag:
License: %autolicense
I don't think values of tags like License can be filled based on
information that's only available during %build ...
It might be possible with the shiny new build-time spec fragment
generation, but I'm not even sure about that.
What we have for Rust packages now is basically the "next best thing"
(the %cargo_license_summary macro prints to the build log, from where
you can paste the information into the spec file after a successful
build). It shouldn't be too hard to implement something similar for
statically linked C/C++ / header-only C/C++ libraries / Go packages /
insert other use case of statically linked binaries here.
Fabio
326
days inactive
329
days old
9 comments
3 participants
participants (3)
-
Ben Beasley -
Fabio Valentini -
Vitaly Zaitsev