Re: Redis will no longer be OSS... now what?

On Wed, Mar 20, 2024 at 6:21 PM Neal Gompa wrote: > > It looks like Redis, Inc. has announced that future versions of Redis > are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a > fork of Redis coming up, we will likely need to remove Redis from > Fedora. This is quite

Re: Mass change of LicenseRef-KDE-Accepted-* licenses

On Tue, Jan 23, 2024 at 4:52 AM Miroslav Suchý wrote: > > Lots of packages in Fedora use license LicenseRef-KDE-Accepted-GPL and > LicenseRef-KDE-Accepted-LGPL. These licenses were never approved. It took > lots of time to discuss it and document it. We finally come with: > >

Re: [Fedora-legal-list] SPDX short name for "Redistributable, no modification permitted" (firmware)

On Sun, Oct 15, 2023 at 5:13 AM Robert-André Mauchin wrote: > > Hi, > > I'm doing a MR on an old package that contains firmware data. > > I wanna convert to SPDX, what is the equivalent to "Redistributable, no > modification > permitted" in SPDX. > > The license is: > > The files in the

Re: SPDX Statistics - Munich Agreement edition

On Fri, Sep 29, 2023 at 3:03 AM Miroslav Suchý wrote: > Can I ask for additional help? Robert-André packaged scancode-toolkit for > Fedora. This is license-check on steroids. Very useful and powerful tool. But > it has lots of dependencies. Robert packaged them too. That's great news!

Re: SPDX Statistics - Voyager 2 edition

On Mon, Aug 28, 2023 at 8:30 AM Fabio Valentini wrote: > What's the commended approach for packages that use deprecated > identifiers then? I would rather not just convert "GPL-2.0" to > "GPL-2.0-or-later" or "GPL-2.0-only", since it's almost always not > obvious which one was originally

Re: SPDX Statistics - Voyager 2 edition

On Tue, Aug 22, 2023 at 5:08 PM Miroslav Suchý wrote: > > Dne 22. 08. 23 v 22:55 Richard Fontana napsal(a): > > The use of `+` is documented at > > https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/ > > (there's probably a more recent version) > &g

Re: SPDX Statistics - Voyager 2 edition

On Tue, Aug 22, 2023 at 4:44 PM Fabio Valentini wrote: > > On Tue, Aug 22, 2023 at 10:39 PM Richard Fontana wrote: > > > > On Tue, Aug 22, 2023 at 3:06 PM Fabio Valentini > > wrote: > > > > > > On Tue, Aug 22, 2023 at 1:21 PM Miroslav Suchý wrote: &

Re: SPDX Statistics - Voyager 2 edition

On Tue, Aug 22, 2023 at 3:06 PM Fabio Valentini wrote: > > On Tue, Aug 22, 2023 at 1:21 PM Miroslav Suchý wrote: > > rust-bitmaps warning: not valid neither as Callaway nor as SPDX, please > > check > > This uses MPL-2.0 or later, denoted as "MPL-2.0+". It looks like an > SPDX identifier, but

Re: SPDX Statistics - Voyager 2 edition

On Tue, Aug 22, 2023 at 7:21 AM Miroslav Suchý wrote: > > Dne 22. 08. 23 v 1:08 Fabio Valentini napsal(a): > > On Sun, Aug 20, 2023 at 9:11 AM Miroslav Suchý wrote: > > New projection when we will be finished is 2025-01-11 (we are slowing down. > Again. :( ). Pure linear approximation. > > It

Re: SPDX Statistics - Voyager 2 edition

On Tue, Aug 22, 2023 at 9:08 AM Vít Ondruch wrote: > > > Dne 22. 08. 23 v 13:21 Miroslav Suchý napsal(a): > > 2) rust-btrd: > License: GPL-2.0 > > This is not on SPDX list, it should be either GPL-2.0-only or GPL-2.0-or-later > > > This is not on SPDX list *anymore*. It used to be valid

Re: rubygem-rdiscount license correction

On Fri, Jun 30, 2023 at 9:00 AM Mamoru TASAKA wrote: > > Vít Ondruch wrote on 2023/06/30 21:14: > > Since its review, rubygem-rdiscount was clasified as ASL 1.1, but as far as > > I can tell, it was always BSD licensed. Therefore I have changed the > > license tag to BSD-3-Clause which should

Re: SPDX identifier for Expat license?

On Thu, May 18, 2023 at 8:02 AM Richard Shaw wrote: > > So subject kind of says it all, but to follow up, when I google Fedora known > good licenses I get this: > > https://fedoraproject.org/wiki/Licensing:Main#SoftwareLicenses > > Which uses the old license identifiers, so there's that. And

Re: gimp license corrected

e question would be whether those licenses should > be even used in license tags - meaning most of the files would have the > same destiny as Makefiles, which shouldn't be counted in the SPDX at all. > > Best regards > > Josef Ridky > Senior Software Engineer > Core Services Te

Re: gimp license corrected

On Tue, May 9, 2023 at 3:54 AM Josef Řídký wrote: > The GIMP application core, and other portions of the official GIMP > distribution not explicitly licensed otherwise, are licensed under the > GPL-3.0-only > > Explicitly licensed under GPL-2.0-only is 'file-dds' plugin. > Curious why you say

Re: SPDX Statistics - ZX Spectrum edition

This is a questionable representation though. The license in question is: "Pick your favourite OSI approved license :) http://www.opensource.org/licenses/alphabetical; It might be more appropriate to have a license identifier that consists of those two lines. On Fri, May 5, 2023 at 11:09 AM

Re: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity

On Fri, May 5, 2023 at 9:56 AM Chris Kelley wrote: > > As a purely logical expression, this simplifies to "GPL-2.0-or-later AND > LGPL-2.1-or-later". Is that sort of simplification not allowed? The short answer is, these are not truly logical expressions and therefore they shouldn't necessarily

Re: indent license corrected

On Mon, Apr 17, 2023 at 12:42 PM David Cantrell wrote: > > On Mon, Apr 17, 2023 at 04:49:13PM +0200, Petr Pisar wrote: > > A license of "indent" package was corrected from > > > > GPLv3+ and BSD and Verbatim > > > > to > > > > GPL-3.0-or-later AND BSD-3-Clause AND BSD-4.3TAHOE AND > >

Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later

The guidelines/requirements around things like the license tag are not set in stone. If people think they are impractical or otherwise should be revised, anyone should feel free to make a proposal. I think so far, though, I am not seeing evidence of major impracticality (for the kinds of issues

Re: htdig: about to orphan due to license issues, how to?

On Sat, Mar 11, 2023 at 8:58 AM Petr Menšík wrote: > Hi! > > I own htdig package, which got recently discovered license issue with > bundled libdb version ~3.x [1]. I think the only reason it is still in > Fedora is that just compiled for years back. I doubt anyone is using it > at the moment

Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later

On Fri, Mar 10, 2023 at 4:17 PM Matthew Miller wrote: > > On Thu, Mar 09, 2023 at 11:41:09AM -0500, Todd Zullinger wrote: > > > I am doing the conversion of license tags in my projects and i have a > > > project where some files are under the GPL-2.0-or-later license and other > > > under the

Re: [Fedora-legal-list] Update on SPDX license id adoption in Fedora

On Mon, Feb 20, 2023 at 7:17 PM Jilayne Lovejoy wrote: > Let us know if you have any questions or suggestions for improvements. We've > had two "office hours" so far with no attendees, but happy to schedule a few > more for open discussion or questions! We've also talked about developing more

Re: SPDX Statistics - Pavel edition

On Sun, Jan 29, 2023 at 11:41 AM Miroslav Suchý wrote: > > Tip: do you want to audit licenses in your tarball? Unpack the tarball and > try: > > dnf install askalono-cli > > askalono crawl /path/to/directory Regarding askalono: I had not heard of it prior to getting involved in this whole

Re: [Fedora-legal-list] Re: SPDX Office hours

On Thu, Jan 12, 2023 at 11:33 AM Miro Hrončok wrote: > On 11. 01. 23 20:10, Miroslav Suchý wrote: > > This is intended to be bi-weekly. > > Every two weeks or twice a week? > Since I was at a meeting yesterday where this was discussed I am pretty sure the intention was every two weeks. Yes,

Re: SPDX - How to handle MIT and BSD

On Tue, Nov 15, 2022 at 6:29 AM Miro Hrončok wrote: > > On 14. 11. 22 20:53, Miroslav Suchý wrote: > > 1) You can use https://github.com/spdx/spdx-license-diff and use it to > > identify > > your license. This is a Chrome and Firefox plugin and allows you to select > > the > > text; and in the

Re: SPDX - How to handle MIT and BSD

On Mon, Nov 14, 2022 at 3:29 PM Miroslav Suchý wrote: > Until now, what Fedora described as an "MIT" license was, in fact, a whole > family of licenses. SPDX identify them differently. And the differences can > be subtle. E.g., compare > > https://spdx.org/licenses/MIT.html >

Re: SPDX Change update

On Mon, Nov 7, 2022 at 2:04 PM Miroslav Suchý wrote: > Please, start migrating your spec files **now**. You can use the tool > `license-fedora2spdx` from package `license-validate`. Use this opportunity > to check if your package license matches the upstream version - especially if > you took

Re: List of licenses for documentation builders

On Wed, Aug 31, 2022 at 5:30 PM Jerry James wrote: > > As I've been working on converting license tags to SPDX, I have found > myself frequently needing to determine the license for some file that > is not distributed by the package upstream, such as JavaScript and CSS > files copied in by

Re: [Fedora-legal-list] More Ansible license changes

On Thu, Aug 25, 2022 at 11:32 PM Maxwell G wrote: > > Hi Fedorians, > > I'm back with more ansible license updates. Upstream, some of the community > Ansible Collections have adopted the REUSE specification, which makes it much > easier to determine the overall license. For collections that have

Re: [Fedora-legal-list] Re: Consider changing the license change announcement policy

On Wed, Aug 24, 2022 at 1:00 PM Jilayne Lovejoy wrote: > > > > On 8/24/22 8:56 AM, Richard Fontana wrote: > > Cross-posting this to the devel list. > > > > On Tue, Aug 23, 2022 at 11:41 PM Maxwell G wrote: > >> Hi Legal folks, > >> > >

Re: [Fedora-legal-list] Consider changing the license change announcement policy

Cross-posting this to the devel list. On Tue, Aug 23, 2022 at 11:41 PM Maxwell G wrote: > > Hi Legal folks, > > Can you please consider removing the following rule? > > > Fedora package maintainers are expected to announce upstream license > > changes that they become aware of on the Fedora

Re: [Fedora-legal-list] Updating the Python license tag to SPDX and adjusting the license of Python documentation

On Tue, Aug 23, 2022 at 6:58 AM Miro Hrončok wrote: > Unfortunately, Python-2.0.1 is still not listed at > https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ I've attempted to update the files used to generate the two lists so hopefully this change will show up in the generated

Re: CC0 reclassified as "not allowed" for code (reposted from legal list)

Kevin Kofler wrote: > One more concern I see is that, since CC0 by design does not require > attribution, there is actually no way to know that the package does not > contain unattributed CC0 code that was unilaterally relicensed by a third > party. That is true [1] although the point

Re: CC0 reclassified as "not allowed" for code (reposted from legal list)

> Using that example, packagers wanting to > continue to use CC0 would need to perform > such a review, strip as needed, and need > legal review? > > Is that what you are suggesting? That solution probably wouldn't make sense in typical cases involving CC0 covering code. However, I could

Re: CC0 reclassified as "not allowed" for code (reposted from legal list)

[re FDK-AAC, which has a no-patent-licenses clause] > That is correct. The clause is considered a no-op and the license > isn't approved for use outside of this case. I think it is correct to bring FDK-AAC up in this discussion. For consistency with treatment of CC0, I believe we have to move

Re: CC0 reclassified as "not allowed" for code (reposted from legal list)

> Have you considered reaching out to the Creative Commons group to > revise the license to drop that language from CC0? It seems silly to > drop acceptance of the license without at least engaging to correct > the problem. My understanding from something Kat Walsh said is that this is an issue

Re: CC0 reclassified as "not allowed" for code (reposted from legal list)

> To give some historical context: There was and is still a lot of software > out there sloppily declaring itself as "public domain", which, in many > jurisdictions, is not even legally allowed. So Fedora has over the years > tried to approach those upstreams convincing them to adopt an

CC0 reclassified as "not allowed" for code (reposted from legal list)

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

Re: Important changes to software license information in Fedora packages (SPDX and more!)

Looks like the License: field is limited to 70 characters if I am reading this correctly: https://github.com/rpm-software-management/rpm/blob/2b5b271b0e013c1b023df7f5775a59cb4078d5f5/docs/manual/spec.md#license ___ devel mailing list --

Re: [Fedora-legal-list] Re: Updating several packages to SPDX

On Mon, Aug 1, 2022 at 1:51 PM Maxwell G wrote: > > Do Callway > SPDX license changes where there's a clear mapping and no other > additions or removals still have to be announced? That wasn't my > understanding. My understanding of this rule/expectation is that it does not have anything

Re: Important changes to software license information in Fedora packages (SPDX and more!)

Michael Catanzaro: > Even that would be an unreasonable effort. I only look at the output of > fedora-review's license check if the source project is small and the > output looks readable. For any complex project, it's beyond what humans > can plausibly handle. I'm hoping we will soon provide

Re: Important changes to software license information in Fedora packages (SPDX and more!)

Björn Persson: > Does that also apply to licenses that explicitly say how they may be > combined? Are we supposed to write "GPL-3.0-or-later AND > GPL-2.0-or-later AND LGPL-3.0-or-later AND GPL-3.0-only" or do those > still combine into GPL-3.0-only? They don't "combine". The idea that they

Re: [Fedora-legal-list] Re: Important changes to software license information in Fedora packages (SPDX and more!)

> Am 31.07.22 um 18:57 schrieb Richard Fontana: > I do not agree > with this view and consider this decision not to be helpful. > > These licenses might not be "commonly used", but if they are used, these > are the controversal ones, that need to be

Re: [Fedora-legal-list] Re: Important changes to software license information in Fedora packages (SPDX and more!)

On Sun, Jul 31, 2022 at 1:39 PM Maxwell G wrote: > > On 22/07/31 12:57PM, Richard Fontana wrote: > > I can go into why I don't think it's worthwhile, if there's interest. > > Feel free to go into more details if you'd like :). Sure, well: Fedora had an informal but publicly st

Re: [Fedora-legal-list] Re: Important changes to software license information in Fedora packages (SPDX and more!)

On Sun, Jul 31, 2022 at 11:22 AM Maxwell G wrote: > As part of this change, the data on which licenses are GPL-compatible > seems to have been removed. Other projects were relying on > this (e.g. [1]). Are there any plans to add it back? No, we decided not to maintain this information going

Re: [Fedora-legal-list] API change and License change: python-ezdxf 0.18

On Sat, Jul 30, 2022 at 11:44 AM Ben Beasley wrote: > > In python-ezdxf 0.18, a few new Python modules are included that are > derived from other software. The License is therefore no longer simply > “MIT.” Of the new modules in question, one is a fork of its original > upstream. I have treated

Re: [Fedora-legal-list] How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?

On Tue, Mar 22, 2022 at 12:25 PM Michal Schorm wrote: > > Hello, > > I'm trying to answer this question: > "Under which license are the contributions done to Fedora Project, > unless license is specified - and how make this clear to the > contributors (or whether we make this clear enough)". >

Re: [Fedora-legal-list] Re: List of packages with problematic license

On Wed, Jan 5, 2022 at 3:45 PM Jilayne Lovejoy wrote: > > There were some license combinations (could be AND, OR, or WITH) that > are on the "good" list but a different combination might need separate > approval. > > Off top of head, I think any L/GPL WITH [exception] would fall into the >

Re: [LEGAL] License field not match the content of eigen3-devel?

On Wed, May 26, 2021 at 3:23 PM Jiri Kucera wrote: > > CC'ing Richard Fontana > > - Original Message - > > From: "Jiri Kucera" > > To: "Development discussions related to Fedora" > > > > Sent: Wednesday, May 26, 2021 4:15:21 PM

Re: [Fedora-legal-list] Re: Packaging firmwares

On Fri, Jun 26, 2020 at 5:21 PM Florian Weimer wrote: > In the Git repository > > > > Mellanox does not provide permission to redistribute the firmware, only > required notices of components that they have used to build it. Just

Re: [Fedora-legal-list] Packaging firmwares

On Fri, Jun 26, 2020 at 4:36 PM Robert-André Mauchin wrote: > > Hello, > > I have a review request for a firmware: Boot firmware (ATF, UEFI...) for > Mellanox BlueField: > > https://bugzilla.redhat.com/show_bug.cgi?id=1846139 > > I would like some opinions on whether this is acceptable firmware.

Re: [Fedora-legal-list] Re: Can we please stop enforcing Signed-off-by commits?

copy of the DCO in the source repository in some place where a contributor can reasonably be expected to see it. A couple of examples: https://github.com/ceph/ceph/blob/master/SubmittingPatches.rst (linked to from https://github.com/ceph/ceph/blob/master/CONTRIBUTING.rst ) https://github.com/ansible/awx/bl

Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags

On Thu, Jul 09, 2015 at 03:53:51PM +0200, Stanislav Ochotnicky wrote: On Thu 09 Jul 2015 03:36:54 PM CEST Richard Fontana wrote: Can you elaborate a bit on the MIT(Fedora) != MIT(SPDX)? Is the SPDX text of MIT different from what we'd consider MIT in Fedora? One difference I can see

Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags

On Thu, Jul 09, 2015 at 04:41:00PM +0200, Haïkel wrote: From my PoV, the abbreviation system is already an improvement, if it's commonly shared with other distros (and Suse already switched to it). I don't see how it's an improvement if the underlying meaning of the abbreviations is not

Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags

On Thu, Jul 09, 2015 at 03:22:41PM +0200, Haïkel wrote: 2015-07-09 15:17 GMT+02:00 Miro Hrončok mhron...@redhat.com: On 9.7.2015 14:48, Haïkel wrote: * mass changing all specs = could be automated Actually, openSUSE has a tool for this: https://github.com/openSUSE/spec-cleaner It

Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags

On Thu, Jul 09, 2015 at 03:14:36PM +0200, Haïkel wrote: 2015-07-09 14:24 GMT+02:00 Richard Fontana rfont...@redhat.com: What distros or upstream projects are actually using the SPDX format? I am not aware of any. Currently Suse is using it, they even patched their packaging compliance

Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags

On Thu, Jul 09, 2015 at 02:48:48PM +0200, Haïkel wrote: * Suse: standardized to SPDX * Debian: considering it https://wiki.debian.org/SPDX * Ubuntu: same (Canonical is also part of the SPDX WG) That may be accurate about Canonical, though if you're basing this merely on the Nascar-style logo

Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags

On Thu, Jul 09, 2015 at 09:42:55AM -0400, Tom Callaway wrote: I'm hesitant to go down this road for a number of reasons: [...] 5) It implies that we're planning on implementing the full SPDX specification. And we're not. This last one is a big concern for me. What I've been seeing, and I don't