legal

legal@lists.fedoraproject.org

1 participants
1396 discussions

OpenAL docs redistribution / modification?
by Marián Konček 17 Jul '24

17 Jul '24

Hi, does the license at the beginning of the document https://www.openal.org/documentation/openal-1.1-specification.pdf allow distribution of versions with the same content but in a different form (HTML) and with some formatting changes? Unfortunately, the other documents like https://www.openal.org/documentation/OpenAL_Programmers_Guide.pdf pretty clearly state "All Rights Reserved", which means no such distribution is legal? -- Marián Konček

2 1

Update on Fedora treatment of Nmap licensing
by Richard Fontana 12 Jul '24

12 Jul '24

I've done a long overdue review of the various Nmap licenses and have updated fedora-license-data accordingly. 1. LicenseRef-Nmap: not-allowed Related issue: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/543 This is Callaway "Nmap", i.e. the GPLv2-incompatible GPLv2 gloss commented on here: https://fedoraproject.org/wiki/Licensing/Nmap This license was classified as "good" but on a new review, that assessment seems unjustified and inconsistent with the analysis of the subsequent licenses. While we should be very reluctant to overturn a past "good" classification I don't see any other option here. But there is a usage exception that says versions of Nmap covered by this license can continue to be included in Fedora Linux indefinitely. (I thought of limiting it to a couple of releases.) 2. LicenseRef-NPSL-0.92: not-allowed Related issue: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/542 This was "NPSL" (on the "bad" list) prior to the migration to SPDX identifiers. See: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org… It was mistakenly imported into fedora-license-data as `LicenseRef-NPSL-0.94`. 3. LicenseRef-NPSL-0.93: not-allowed Related issues: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/541 https://gitlab.com/fedora/legal/fedora-license-data/-/issues/540 This covers the multiple versions of Nmap licenses labeled as "Version 0.93" and "Version 0.94" 4. LicenseRef-NPSL-0.95: not-allowed Related issue: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/539 This covers the multiple versions of Nmap licenses labeled as "Version 0.95". Other relevant issues: https://github.com/nmap/nmap/issues/2199 https://gitlab.com/fedora/legal/fedora-license-data/-/issues/147 https://bugs.gentoo.org/749390 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972216 https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00227.html https://github.com/NixOS/nixpkgs/issues/105119 https://labs.parabola.nu/issues/2966 https://bugzilla.opensuse.org/show_bug.cgi?id=1211571 Richard

4 9

Fwd: SPDX Statistics - Alice Edition
by Miroslav Suchý 04 Jul '24

04 Jul '24

-------- Přeposlaná zpráva -------- Předmět: SPDX Statistics - Alice Edition Datum: Thu, 4 Jul 2024 07:09:55 +0200 Od: Miroslav Suchý <msuchy(a)redhat.com> Společnost: Red Hat Czech, s.r.o. Komu: Development discussions related to Fedora <devel(a)lists.fedoraproject.org> Hot news: * Discussion about trivial conversion did not have consensus. I opened FESCO ticket https://pagure.io/fesco/issue/3230 * Scancode-toolkit is present in Fedora 40 too. If you want to play with it - here is the command line that gives *me* the best result: scancode --license --license-references -n6 --html /tmp/scan.html $DIR_WITH_UNPACKED_TARGZ * Package fedora-license-data now contains License Policy for scancode. The file is /usr/share/fedora-license-data/scancode-license-policy.yaml Or you can download it from https://gitlab.com/fedora/legal/fedora-license-data#artifact I still did not found out how to use it, so if you find it helpful I am eager to hear your success stories. * license-validate now accepts lowercase "and","or" according to SPDX v3. Two weeks ago we had: > * 24113spec files in Fedora > > * 30804license tags in all spec files > > * 10348 tags have not been converted to SPDX yet > > * 4503 tags can be trivially converted using `license-fedora2spdx` > > * Progress: 66,41% ░░░░░░████ 100% > > ELN subset: > > 101 out of 2397 packages are not converted yet (progress 95.79%) > Today we have: * 24117spec files in Fedora * 30788license tags in all spec files * 10271 tags have not been converted to SPDX yet * 4460 tags can be trivially converted using `license-fedora2spdx` * Progress: 66,64% ░░░░░░████ 100% ELN subset: 84 out of 2354 packages are not converted yet (progress 96.43%) Graph of these data with the burndown chart: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807r… The list of packages needed to be converted is here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f… List by package maintainers is here https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f… New version of fedora-license-data has been released. With: 5 new licenses. 6 licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B… Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. New projection when we will be finished is 2025-07-04 (+17 days from last report). Pure linear approximation. If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license tag matches SPDX formula, you can put your package on ignore list https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt Either pull-request or direct email to me is fine. Why Alice edition? Because today's date has *two* relation to Alice in Wonderland: Lorina Charlotte Liddell, Alice Pleasance Liddell, Edith Mary Liddell. Three teenage girls, sisters. On 4th July 1862, Lewis Carroll travelled with them by boat on the River Thames from Oxford to Godstow. During the voyage, Alice asked Carroll to tell them a story - a fairy tale. And so Carroll put down roots for a phenomenal story, with a gesture of assent - beginning by telling the story of Alice, whose fall down the rabbit hole introduced bizarrely fantastic elements into her fairy tale life. Alice begged several times for Carroll to write the story for her to read whenever she wanted, until finally Carroll gave in to the child's wishes and actually produced the writing and gave it to Alice (he titled it: Alice's Adventures Under Ground). Then, at Christmas 1864, Alice received a gift from Carroll - a revised and expanded narrative, complete with illustrations. The following year - on 4th July 1865 - the file was then published with professional illustrations by John Tenniel. https://en.wikipedia.org/wiki/Alice%27s_Adventures_in_Wonderland#Background Miroslav

1 0

Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
by Miro Hrončok 26 Jun '24

26 Jun '24

On 18. 06. 24 18:46, Miroslav Suchý wrote: > Hi. > > I am going to do the mass change of the license from GPLv2 to GPL-2.0-only Hi. How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar? Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically. Same for the other thread about LGPLv3 to LGPL-3.0-only conversion. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

9 30

EXIV2 BMFF Patents situation : we need an official answer
by Robert-André Mauchin 26 May '24

26 May '24

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=1979565 https://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

2 1

bmff and exiv2 update - can we have a clear reply?
by Mattia Verga 25 May '24

25 May '24

I'm sorry to post the question again, but we never received a clear reply from RH Legal team (in 3 years...) Are we finally allowed to enable support in exiv2 for file formats using the BMFF format? https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org… https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org… https://bugzilla.redhat.com/show_bug.cgi?id=1979565 It would be nice to have an official GO/NO-GO before the F41 change deadline. Also consider that if BMFF support is not allowed in Fedora, according to @eclipseo we have several other packages using it that must be retired/stripped of: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/406 Thanks Mattia

1 0

Brainpool Curves in Fedora (openssl, libgcrypt, gnupg)
by Timothée Ravier 21 May '24

21 May '24

Hi everyone, The ECC Brainpool Curves [1][2] are currently not available in Fedora as according to this BZ [3], this needs Fedora Legal approval. Could someone from the legal team take a look to see if there are any blockers regarding Brainpool Curves inclusion in Fedora? Thanks! [1] https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Implementation [2] https://tools.ietf.org/html/rfc5639 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1413618

14 31

GlobalProtect-openconnect - License violation or not?
by Jakub Kadlcik 16 May '24

16 May '24

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

3 2

Unicode licensing of finl_unicode
by Cristian Le 08 May '24

08 May '24

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

1 0

License for Sublime Text language definitions for syntax highlighting
by Fabio Valentini 02 May '24

02 May '24

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

1 0

← Newer
1
2
3
4
5
6
7
...
140
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal