Bug 154056 - Language pack are described as "possibly unsafe" and "proprietary code" in Software in Fedora Linux
Summary: Language pack are described as "possibly unsafe" and "proprietary code" in So...
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-08 07:26 UTC by Jakob Kappel
Modified: 2023-03-09 10:33 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakob Kappel 2023-03-08 07:26:30 UTC
Description:
In localized versions of Fedora Linux language packs for Libreoffice are tagged as "proprietary code" and described as possibly unsafe.

Steps to Reproduce:
1. Install Libreoffice via Software on Fedora set to a language other than English
2. Click when a prompt is shown: "Libreoffice requires more packages"
3. Read descriptions of the language pack in Software

Actual Results:
"libreoffice-langpack-da might be unsafe"

"Proprietary code. The code is not publicly accessible. Therefore it can not be audited and might not be safe" 

The above strings are shown in a localized version.
Licenses for the language pack are show correctly though.

Expected Results:
The language pack is described as open source and safe to run.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.4.5.1
Build ID: 40(Build:1)
CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: da-DK (da_DK.UTF-8); UI: en-US
Calc: threaded
Comment 1 Mike Kaganski 2023-03-08 07:53:38 UTC
It seems like an issue in the Fedora package. Have you filed the respective issue at their bug tracker?
Comment 2 Jakob Kappel 2023-03-08 08:42:04 UTC
I'll do that. 

Feel free to close this issue. 

I won't change the status to "Resolved" in case you have another, more fitting status available to you :)
Comment 3 Mike Kaganski 2023-03-08 09:11:03 UTC
(In reply to Jakob Kappel from comment #2)

Please put a link to the issue you create in their bug tracker. Then this could be closed, with enough information to track its resolution, and point similar issues (if they appear).

Indeed, if the distro packager finds out that this is not their issue, but ours, this one can be reopened, and re-evaluated.

Thanks!
Comment 4 Caolán McNamara 2023-03-08 12:28:43 UTC
What this is, is something to do with the license field in our .spec file
and https://gitlab.gnome.org/GNOME/gnome-software/-/wikis/software-metadata#user-content-how-to-fix-incorrect-licensing-information

either our expression is too complex, or some element in it is triggering that "Proprietary" warning

License:        MPL-2.0 AND Apache-2.0 AND LGPL-3.0-only AND LGPL-3.0-or-later AND CC0-1.0 AND BSD-3-Clause AND (LGPL-2.1-only OR SISSL) AND (MPL-2.0 OR LGPL-3.0-or-later) AND (MPL-2.0 OR LGPL-2.1-or-later) AND (MPL-1.1 OR GPL-2.0-only OR LGPL-2.1-only)

though

license-validate -v "MPL-2.0 AND Apache-2.0 AND LGPL-3.0-only AND LGPL-3.0-or-later AND CC0-1.0 AND BSD-3-Clause AND (LGPL-2.1-only OR SISSL) AND (MPL-2.0 OR LGPL-3.0-or-later) AND (MPL-2.0 OR LGPL-2.1-or-later) AND (MPL-1.1 OR GPL-2.0-only OR LGPL-2.1-only)"

claims:

"Approved license"
Comment 5 Jakob Kappel 2023-03-08 13:31:03 UTC
It might be the inclusion of CC0-1.0

According to https://gitlab.gnome.org/GNOME/gnome-software/-/wikis/software-metadata#user-content-how-to-fix-incorrect-licensing-information a license must be approved as valid by OSI or FSF.

According to https://spdx.org/licenses/ CC0 is not approved by Open Source Initiative.

It is approved by FSF, though. But not for documentation: https://www.gnu.org/licenses/license-list.html CC0 is listed under "Licenses for Works of Practical Use besides Software and Documentation" - not as a valid free license for documentation. 

Also, "If an application is being displayed as ‘proprietary’ when you think it shouldn’t be, it’s likely that the <project_license> element includes the documentation license for the project. Remove it."
Comment 6 Caolán McNamara 2023-03-08 17:25:57 UTC
looks more complicated than that, I think the license is extracted from the license tag of the rpm and ends up in some appstream parsing, where the presence of brackets makes it not recognize it as a spdx license so it gets converted into something which then isn't recognized at all and gets flagged as proprietary.

My stab at getting it to work at: https://github.com/ximion/appstream/pull/469
Comment 7 Caolán McNamara 2023-03-08 17:27:21 UTC
before:

$ appstreamcli check-license "MPL-2.0 AND Apache-2.0 AND LGPL-3.0-only AND LGPL-3.0-or-later AND CC0-1.0 AND BSD-3-Clause AND (LGPL-2.1-only OR SISSL) AND (MPL-2.0 OR LGPL-3.0-or-later) AND (MPL-2.0 OR LGPL-2.1-or-later) AND (MPL-1.1 OR GPL-2.0-only OR LGPL-2.1-only)"
License Type: invalid
Suitable for AppStream metadata: no
Free and Open Source: no

after:

$ appstreamcli check-license "MPL-2.0 AND Apache-2.0 AND LGPL-3.0-only AND LGPL-3.0-or-later AND CC0-1.0 AND BSD-3-Clause AND (LGPL-2.1-only OR SISSL) AND (MPL-2.0 OR LGPL-3.0-or-later) AND (MPL-2.0 OR LGPL-2.1-or-later) AND (MPL-1.1 OR GPL-2.0-only OR LGPL-2.1-only)"
bash-5.2$ ./builddir/tools/appstreamcli check-license "MPL-2.0 AND Apache-2.0 AND LGPL-3.0-only AND LGPL-3.0-or-later AND CC0-1.0 AND BSD-3-Clause AND (LGPL-2.1-only OR SISSL) AND (MPL-2.0 OR LGPL-3.0-or-later) AND (MPL-2.0 OR LGPL-2.1-or-later) AND (MPL-1.1 OR GPL-2.0-only OR LGPL-2.1-only)"
License Type: license expression
Suitable for AppStream metadata: no
Free and Open Source: yes
Comment 8 Caolán McNamara 2023-03-09 10:33:59 UTC
moved this now to https://bugzilla.redhat.com/show_bug.cgi?id=2176791