CC0 reclassified as "not allowed" for code (reposted from legal list)
by Richard Fontana
Hi,
I posted the following recently to the Fedora legal list, but it was pointed out by Fabio Valentini that the legal list is sort of obscure so I'm reposting it here in the hope that it may reach more interested people:
CC0 has been listed by Fedora as a 'good' license for code and content
(corresponding to allowed and allowed-content under the new system).
We plan to classify CC0 as allowed-content only, so that CC0 would no
longer be allowed for code. This is a fairly unusual change and may
have an impact on a nontrivial number of Fedora packages (that is not
clear to me right now), and we may grant a carveout for existing
packages that include CC0-covered code. While we are moving towards a
process in which license approvals are going to be done primarily
through the Fedora license data repository on gitlab.com, I wanted to
note this on the mailing list because of the significance of the
change.
The reason for the change: Over a long period of time a consensus has
been building in FOSS that licenses that preclude any form of patent
licensing or patent forbearance cannot be considered FOSS. CC0 has a
clause that says: "No trademark or patent rights held by Affirmer are
waived, abandoned, surrendered, licensed or otherwise affected by this
document." (The trademark side of that clause is nonproblematic from a
FOSS licensing norms standpoint.) The regular Creative Commons
licenses have similar clauses.
A few months ago we approved ODbL as a content license; this license
contained its own "no patent license" clause. Up till this time, the
official informal policy of Fedora has been that 'content' licenses
must meet the standards for 'code' licenses except that they can
prohibit modification. The new Fedora legal documentation on the
license approval categories will note that allowed-content licenses
can also have a no-patent-license clause. In a FOSS development and
distribution context, the absence of patent licensing for non-software
material is of significantly less concern than the software case.
1 year, 9 months
dracut bluetooth hang + dbus permission errors are back in rawhide
by Hans de Goede
Hi All,
After upgrading my workstation to rawhide for F37 dogfooding purposes
it hang for 30 seconds at switching root and then anything depending
on dbus would fail to start with permission errors.
Booting the F36 kernel and then creating a:
/etc/dracut.conf.d/nobluetooth.conf
with:
omit_dracutmodules+=" bluetooth "
in there, followed by re-generating the initrd works around this.
Once more people start testing F37 I expect more people to get
bitten by this, so it would be good to fix this soon if possible.
Since all the history about this is in:
https://bugzilla.redhat.com/show_bug.cgi?id=1964879
I've re-opened that bug to track this there.
Regards,
Hans
1 year, 9 months
Request for assistance: zfs-fuse
by Gwyn Ciesla
Good morning!
zfs-fuse is FTBFS starting with f36.
https://bugzilla.redhat.com/show_bug.cgi?id=2047144
I've been banging my head on it for a long time, to no avail. I can get around the SConstruct failure by removing some environment variables, and then I hit a linking issue I can't get past.
Only libguestfs and libvirt require this, other that users with ZFS filesystems, but I'd rather not retire it if it can be avoided.
Thanks in advance,
--
Gwyn Ciesla
she/her/hers
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with Proton Mail secure email.
1 year, 9 months
Process to remove "abandoned" packages?
by Vít Ondruch
Hi,
I have removed last use of rubygem-memcache-client package in Fedora
minutes ago:
https://src.fedoraproject.org/rpms/rubygem-rack/c/7490abe4066b965d222764a...
and I think that rubygem-memcache-client would deserve to be retired
from Fedora, because it is deprecated upstream for ~12 years and it
functionality replaced by rubygem-dalli.
However, if I really wanted to do this, I'd need to ask Mo, possibly use
unresponsive maintainer policy. But that is too much hassle, so I'll
probably leave it alone.
But I'd really love to see some process to get such packages removed in
much easier way. E.g.:
1. Open FESCo ticket with the request request
2. Send email to Fedora devel ML to collect feedback
3. Within some timeout, make a decision based on the feedback
4. Orphan package, which gives some additional time to take the package
or even resurrect the package if it turns out to be needed.
Thoughts?
Vít
1 year, 9 months