Hey all,
As part of the discussion going on about Mesa on devel@, the situation
around OpenSSL was brought up, and Adam Williamson brought up that we
might not need to hobble OpenSSL anymore[1]. A quick check seems to
indicate we no longer do it for GnuTLS either, and haven't for many
years[2].
Could we just drop all this stuff and use pristine OpenSSL sources?
All the crypto algorithm usability stuff is controlled through
crypto-policies, so I don't think it makes sense to do this anymore
for OpenSSL since all the patents indicated in the script have expired
for a couple of years now[3].
Dropping this will eliminate a chunk of cruft that nobody needs around
anymore and simplify OpenSSL maintenance.
[1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
[2]: https://src.fedoraproject.org/rpms/gnutls/c/46d865d8451be0f4576dcc56841175a…
[3]: https://src.fedoraproject.org/rpms/openssl//blob/rawhide/f/hobble-openssl
--
真実はいつも一つ!/ Always, there's only one truth!
Hello,
Follow-up from :
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/406
In order to update Exiv2, we need to know if this is okay to enable BMFF
support. Patents have theoretically expired and it is enabled by default
in the latest version.
https://bugzilla.redhat.com/show_bug.cgi?id=1979565https://github.com/Exiv2/exiv2/issues/1679
Upstream seems to think it is okay because it is over 20 years old. Also
other packages in Fedora are already using it, av1, jpeg-xl, any mp4
decoding...
By Jon Sneyers, one of the author of JPEG-XL:
I think this caution is erring on the side of paranoia, and possibly
based on a misunderstanding.
ISOBMFF is pretty old, old enough for it to be impossible to still
have applicable patents (patents expire after 20 years). It is a
simple box-based container format that is used by many formats,
including MP4, JPEG 2000, and JPEG XL.
One particular use of ISOBMFF is HEIF, which is more recent, and for
which there actually are known patent claims by Nokia. HEIF does use
the generic ISOBMFF box structure and extends it by defining
mechanisms to do cropping, layering, grids, rotation etc, which are
described in the HEIF spec. HEIF can be used with various payloads:
when used with HEVC it is called HEIC, when used with AV1 it is
called AVIF.
While most people would consider patents on a container format
ridiculous, it is a fact that, at least in theory, if you use HEIF,
you might risk patent litigation. Note that it would not be the
application implementor who could be sued, but the end-user who uses
the implementation and thereby possibly needs a patent license from
Nokia.
This is only true specifically for HEIF though, not for ISOBMFF in
general. Parsing the MP4 or JPEG 2000 container (which do not use
HEIF) carries absolutely no risk in terms of patents, since they
only use ISOBMFF, not HEIF. The same is true for JPEG XL, which has
explicitly avoided using the HEIF container exactly for this reason.
TL;DR: ISOBMFF is OK, HEIF might be risky.
So just to be clear: reading BMFF is not an issue, it is over 20
years old so even if it was an issue in the past (it wasn't) it now
certainly isn't anymore.
Reading HEIF-specific boxes is something else, but as long as Exiv2
is not doing that, there obviously is no issue either. Note that
other FOSS tools like libheif and libavif actually do read those
boxes, and they do seem to get away with it (but I can understand
why you wouldn't want to do that; those boxes are from 2015 and
Nokia does claim patents on them so it will only really be 'safe' to
use that functionality in 2035).
So while I appreciate the caution, I think it's OK to just enable
the BMFF code by default (perhaps have an option to disable it, if
someone is still for some reason worried, but imo that would be an
unfounded worry). Otherwise most of the modern image codecs (jp2,
jxl, avif and heic) end up being unsupported by default, for no good
reason, which seems a sub-optimal situation.
Thank you for your time.
Best regards,
Robert-André Mauchin,
FAS: eclipseo
Hello Fedora Legal,
a piece of software was recently discovered in Fedora Copr and it is now
causing a contention about whether it should be allowed to be there or not.
I am kindly asking for your ruling.
The project in question is here:
https://copr.fedorainfracloud.org/coprs/yuezk/globalprotect-openconnect/
And its upstream:
https://github.com/yuezk/GlobalProtect-openconnect
Both the upstream project and the package that is built in Copr claim to be
under the GPLv3 license.
The package provides several executables:
/usr/bin/gpauth
/usr/bin/gpclient
/usr/bin/gpgui-helper
/usr/bin/gpservice
All of these seem to be compiled from the mentioned upstream sources. So
far, no problem. However, when executing some of them (with the exception
of gpclient) the following tarball is being downloaded to the user machine:
INFO gpgui_helper::updater] Downloading file:
https://github.com/yuezk/GlobalProtect-openconnect/releases/download/v2.1.4…
It contains just a single binary called gpgui which is licensed under a
proprietary license and developed in a private repository, according to the
author:
https://github.com/yuezk/GlobalProtect-openconnect/issues/296#issuecomment-…
When running the program, it says it is a 10-day trial and prompts for
buying a license here
https://yuezk.lemonsqueezy.com/checkout
I would like to ask you whether this is just a shady practice (but OK from
a legal perspective) or whether this is a violation of either GPLv3 or Copr
conditions
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-…
Thank you very much for your help,
Jakub
Hi legal team,
I am trying to package finl_unicode [1][2], but we are having some
issues with the ambiguous Copyright notice stating that it is licensed
under Unicode license with "All rights reserved". The project uses
generated source code and it is a bit unclear what license these belong
to and what part of the code carries the Unicode license. We are trying
to ask for clarification if some of the code is actually
"Unicode-DFS-2016" licensed, and we are waiting for their reply.
So far we have made 2 PRs [3][4] that can side-step the obvious files
that are under the Unicode license, but we need advice on whether those
are sufficient or do we need to wait for more explicit confirmation form
upstream?
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2279514
[2]: https://github.com/dahosek/finl_unicode
[3]: https://github.com/dahosek/finl_unicode/pull/17
[4]: https://github.com/dahosek/finl_unicode/pull/19
Hi all,
I noticed that there are some packages that bundle data from Sublime
Text, notably data for how to apply syntax highlighting for various
programming languages. The license that applies to this data is in
this file:
https://github.com/sublimehq/Packages/blob/759d6eed9b4beed87e602a23303a121c…
(Yes, in one case that I'm looking at, the bundled data is a 5 years
old snapshot. Apparently only the Sublime Text v3 format is supported
by syntect.)
The contents of this LICENSE file are very short, so I'll just include
it verbatim for convenience:
```
If not otherwise specified (see below), files in this repository fall
under the following license:
Permission to copy, use, modify, sell and distribute this
software is granted. This software is provided "as is" without
express or implied warranty, and with no claim as to its
suitability for any purpose.
An exception is made for files in readable text which contain their
own license information, or files where an accompanying file exists
(in the same directory) with a “-license” suffix added to the
base-name name of the original file, and an extension of txt, html, or
similar. For example “tidy” is accompanied by “tidy-license.txt”.
```
I could not find any SPDX license that matches this text. It looks
very permissive to me, so it should be acceptable for content, but I
would need to know how to classify it - both for existing packages
where this was missed during package review, as well for a new package
for a library that I need to package in order to be able to update an
existing package to the latest version.
Fabio