[Fedora-legal-list] Re: Licensing BIP derived files

[Richard Fontana via legal]

On Mon, Aug 5, 2024 at 10:38 AM Cristian Le  wrote:
>
> Hi,
>
> This issue came up when trying to package rust-tiny-bip39 [1]. Basically
> there are some projects that are spun off of Bitcoin Improvement
> Proposals (BIP), in this case BIP39 [2] which establishes a wordlist
> which can be use as mnemonic to encode/decode a long series of bits. Te
> issue is that typically these BIPs are licensed [3], but (maybe) because
> BIP39 has not passed the proposed stage, it did not receive a proper
> license. So the question is, how to deal with the wordlist defined in BIP39?
>
> Contacting the upstream developer is difficult as they don't have an
> open issue page, and the main means of external people to get in touch
> with them is through their google mailing list, which would require
> exposing my personal gmail account to who knows what (given the
> association with bitcoin), which I am not comfortable of doing. In
> Fedora there is another BIP39 based project, python-mnemonic [4], which
> is the reference code for BIP39, where the only license specified is
> MIT. I have looked at the review request ticket [5], but the licensing
> of BIP39 was not discussed there. Any advice on this situation?

Sorry, I thought I had responded to this. If we assume that the
creators of the word lists have copyright on the word lists, the lists
apparently are in python-mnemonic under the MIT license and the author
of the word lists there is one of the authors of BIP39. So I'd
conclude from that that the word lists (which I assume are
substantially the same in rust-tiny-bip39) are under the MIT license.

Richard

> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2297307
> [2]: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
> [3]:
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-licensing
> [4]: https://src.fedoraproject.org/rpms/python-mnemonic
> [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1395867

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: MIT without copyright notice, requires to include the copyright notice

[Richard Fontana]

On Mon, Sep 2, 2024 at 9:23 AM Miro Hrončok  wrote:
>
> I see an important project has decided it's good idea to remove their own
> copyright notice from the top of their MIT license file while preserving the
> requirement for distributors to keep the copyright notice.
>
> """
> The above copyright notice and this permission notice shall be included in
> all copies or substantial portions of the Software.
> """
>
> But there is no such copyright notice to include.
>
> Is it OK for a Fedora package to distribute the project

Yes. I think the only reason this is not more common is that a lot of
people copy-paste the MIT license text (including the copyright notice
template) from other sources like the OSI website or other projects.

However, the detail "their own" is important. If we were aware of a
project where the current maintainers were removing copyright notices
of third parties from MIT license texts, this should be seen as an
error. This seems to be what almost happened with inflect.

> or is it impossible to
> comply with the license terms and hence not allowed?

That itself doesn't concern me. I would interpret it as "the above
copyright notice (if one exists)".

But (in an MIT license scenario, and probably most other open source
license scenarios) I'd see removal of someone else's copyright notice
without their permission as a license violation, unless it was
determined that the original copyright notice was or became incorrect,
as is common. Here's a case of what I believe is an incorrect MIT
license copyright notice that I recently pointed out:
https://github.com/containers/bootc/issues/766

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: tcplay generic_xts* file licenses

[Richard Fontana]

On Mon, Aug 26, 2024 at 9:48 AM Ian McInerney  wrote:
>
> I am working on the Zulucrypt 7.0.0 update and SPDX license audit at the same 
> time, and there is one license listed in their copyright file that isn't 
> obvious to me. Specifically, it is the generic_xts files included in the 
> bundled tcplay 
> (https://github.com/mhogomchungu/zuluCrypt/blob/master/external_libraries/tcplay/generic_xts.c).
>  It is bundled because upstream has made changes to it, and also we no longer 
> have tcplay in Fedora (it was retired 5 years ago for FTBFS).
>
> The file header says:
>
> /*
>  * Copyright (C) 2008, Damien Miller
>  * Copyright (C) 2011, Alex Hornung
>  *
>  * Permission to use, copy, and modify this software with or without fee
>  * is hereby granted, provided that this entire notice is included in
>  * all copies of any software which is or includes a copy or
>  * modification of this software.
>  * You may use this code under the GNU public license if you so wish. Please
>  * contribute changes back to the authors under this freer than GPL license
>  * so that we may further the use of strong encryption without limitations to
>  * all.
>  *
>  * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR
>  * IMPLIED WARRANTY. IN PARTICULAR, NONE OF THE AUTHORS MAKES ANY
>  * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
>  * MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
>  * PURPOSE.
>  */
>
> Is it appropriate to list this under the GPL in the license tag, or does this 
> need its own licenseref in Fedora? (I already have tags for GPL-3.0-or-later 
> AND GPL-2.0-or-later anyway).

Please submit this as a new license for review at
gitlab.com/fedora/legal/fedora-license-data.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Should I mention Build-scripts' licensing terms in a spec's License field?

[Richard Fontana]

On Mon, Aug 5, 2024 at 10:53 AM Vít Ondruch  wrote:
>
> And the second point is that we won't ever be able to 100% cover RPMs by
> license scanners, but we could achieve that for SRPMs.

I don't agree. I think the "less than 100%" would similarly apply to
SRPMs. They're really the same inquiry with the same challenges
(misidentified licenses, false positives, phony licenses ...). The
only difference is that some of the enumerated licenses in a
hypothetical `SourceLicense:` would be removed from `License:`. So
`SourceLicense:` is maybe recording a step in the computation of
`License:` that might otherwise not be recorded.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Should I mention Build-scripts' licensing terms in a spec's License field?

[Richard Fontana]

On Mon, Aug 5, 2024 at 10:39 AM Vít Ondruch  wrote:
>
>
> Dne 05. 08. 24 v 15:24 Richard Fontana napsal(a):
> > On Mon, Aug 5, 2024 at 5:40 AM Daniel P. Berrangé  
> > wrote:
> >> On Mon, Aug 05, 2024 at 11:23:08AM +0200, Vít Ondruch wrote:
> >>> Dne 02. 08. 24 v 21:37 Miroslav Suchý napsal(a):
> >>>> Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> >>>>>
> >>>>> I will love to see more usage of this tag, but I believe the
> >>>>> documentatin has to be updated first. PR for packaging guidelines
> >>>>> and legal doc is welcome.
> >>>>>
> >>>> Here it comes
> >>>> https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306
> >>>>
> >>>>
> >>> Thank you for the PR, because this is hard one. I think that in ideal 
> >>> world,
> >>> the PR should be worded in a way that:
> >>>
> >>> 1) The `SourceLicense` tag is always used and it fully describes the 
> >>> content
> >>> of the SRPM, i.e. it should contain all licenses which would be identified
> >>> by some (ideal) scanner
> >>>
> >>> 2) The `License` tag would be used in cases when the resulting (sub) 
> >>> package
> >>> has different license from the `SourceLicense` (e.g. build scripts are not
> >>> part of the resulting binary obviously).
> >>>
> >>> The question is if we can get from the current state to the state I 
> >>> proposed
> >>> above.
> >> Implementing this requires a (re-)review of everything in the source 
> >> tarball,
> >> which is an exercise we just went through for SDPX in many cases. The idea 
> >> of
> >> doing this again in order to add SourceLicense is not going to fly in terms
> >> of the time investment asked of maintainers.
> > I don't really see the justification. Apart from maybe the
> > complications of Rust and Go packages that were mentioned (which I
> > think raise some deeper issues that haven't really been addressed
> > satisfactorily yet), I see no point in having *both* `License:` and
> > `SourceLicense:`. If a full license breakdown of what's in the SRPM is
> > desired then that should be the standard of what goes in `License:`,
> > instead of the traditional Fedora approach of having `License:` be a
> > subset (or, as it was formerly described, "the license of the binary
> > RPM").
> >
> > If the idea is to record what some particular scanner produced, that
> > may be something like SPDX's ill-defined "Declared License" concept.
> > But even the best scanners produce a lot of junk information and you
> > still have to undertake analysis to exclude things that are spurious
> > licenses, misidentified licenses, things that purport to be licenses
> > for which licenses aren't needed, etc.
> >
> > I feel like the strongest argument for saying something about
> > `SourceLicense:` is that the RPM project adopted this tag so it
> > shouldn't be ignored. Which doesn't feel like a strong argument.
>
>
> My main point is that SRPM is the thing we redistribute. Therefore we
> should care about License of it. It seems strange that we would care
> that much about binary RPMs and not care about SRPM at all.

We do care about the licensing of SRPMs - Fedora legal docs say:

"Fedora’s license approval standards apply to everything that is made
available by the Fedora Project, not just installable binary packages
in Fedora Linux. For example, everything available at Fedora Pagure,
Fedora Source Packages, Fedora Koji, Fedora documentation and Copr
repositories is subject to the same licensing rules as Fedora Linux
packages."

"If a license that covers something in Fedora, or in a package that
has been or is intended to be proposed for inclusion in Fedora Linux,
is not listed on the allowed and not-allowed lists, then it must be
reviewed."

"The Fedora convention is that License: tags describe a relevant
subset of the licenses that apply to the source code of the package.
Any license that applies to anything in the source code must be
Fedora-acceptable (assuming you actually need a license for that
material), even if it is ultimately not included in the License: tag."

The issue is just what gets reflected in license metadata. We could
dispense with `License:` altogether and it wouldn't mean we don't care
about licenses. (For example, I believe Debian and its derivatives
don't have any real concept of package license metadata.)

[Fedora-legal-list] Re: Should I mention Build-scripts' licensing terms in a spec's License field?

[Richard Fontana]

On Mon, Aug 5, 2024 at 5:40 AM Daniel P. Berrangé  wrote:
>
> On Mon, Aug 05, 2024 at 11:23:08AM +0200, Vít Ondruch wrote:
> >
> > Dne 02. 08. 24 v 21:37 Miroslav Suchý napsal(a):
> > > Dne 02. 08. 24 v 9:07 odp. Miroslav Suchý napsal(a):
> > > >
> > > >
> > > > I will love to see more usage of this tag, but I believe the
> > > > documentatin has to be updated first. PR for packaging guidelines
> > > > and legal doc is welcome.
> > > >
> > > Here it comes
> > > https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/306
> > >
> > >
> >
> > Thank you for the PR, because this is hard one. I think that in ideal world,
> > the PR should be worded in a way that:
> >
> > 1) The `SourceLicense` tag is always used and it fully describes the content
> > of the SRPM, i.e. it should contain all licenses which would be identified
> > by some (ideal) scanner
> >
> > 2) The `License` tag would be used in cases when the resulting (sub) package
> > has different license from the `SourceLicense` (e.g. build scripts are not
> > part of the resulting binary obviously).
> >
> > The question is if we can get from the current state to the state I proposed
> > above.
>
> Implementing this requires a (re-)review of everything in the source tarball,
> which is an exercise we just went through for SDPX in many cases. The idea of
> doing this again in order to add SourceLicense is not going to fly in terms
> of the time investment asked of maintainers.

I don't really see the justification. Apart from maybe the
complications of Rust and Go packages that were mentioned (which I
think raise some deeper issues that haven't really been addressed
satisfactorily yet), I see no point in having *both* `License:` and
`SourceLicense:`. If a full license breakdown of what's in the SRPM is
desired then that should be the standard of what goes in `License:`,
instead of the traditional Fedora approach of having `License:` be a
subset (or, as it was formerly described, "the license of the binary
RPM").

If the idea is to record what some particular scanner produced, that
may be something like SPDX's ill-defined "Declared License" concept.
But even the best scanners produce a lot of junk information and you
still have to undertake analysis to exclude things that are spurious
licenses, misidentified licenses, things that purport to be licenses
for which licenses aren't needed, etc.

I feel like the strongest argument for saying something about
`SourceLicense:` is that the RPM project adopted this tag so it
shouldn't be ignored. Which doesn't feel like a strong argument.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Dealing with snippets credited to StackOverflow?

[Richard Fontana]

On Thu, Aug 1, 2024 at 4:18 PM Ben Beasley  wrote:
>
> Although I haven’t signed up to do the official review, I was looking at
> python-meshio[1], and I found that it contains a function substantially
> derived from a StackOverflow answer[2]. While I’m impressed that
> upstream cared enough to give credit, this leaves me with a question.
>
> Normally I would suggest that, to be strictly correct, the license of
> the copied-and-modified snippet should be added to the package’s License
> expression. But all answers on StackOverflow are, depending on when they
> are posted[3], licensed CC-BY-SA-2.5, CC-BY-SA-3.0, or CC-BY-SA-4.0. In
> this case, the applicable license is CC-BY-SA-3.0[4].
>
> All of these licenses are listed as allowed in Fedora for content, but
> not for code. Strictly speaking, then, this appears to be code under a
> not-allowed-for-code license. At the same time, it is hard to believe
> that prohibiting packages containing snippets from StackOverflow would
> be an intended outcome.
>
> Since code copied or heavily inspired by StackOverflow answers is
> extremely widespread, and the only thing that is perhaps unusual here is
> that proper attribution is present, I’m curious how cases like this
> *ought* to be handled.

This situation has come up before. I think there was at least one like
it involving dotnet.

While we shouldn't attempt to uncover hypothetical undisclosed
derivatives of StackOverflow snippets, in the rare cases where there
is an attempt to provide attribution etc., we need to review them, not
only because Fedora has a longstanding policy not allowing (otherwise
allowable) Creative Commons licenses for 'code', but also because in
the typical (rare) case there will be some sort of potential license
compliance issue.

In this case, though, while I see how the meshio function has some
similarities to the cited StackOverflow code, I don't think the
distinctive elements of each are quite close enough that I would
conclude there is a license compliance issue. Therefore the
StackOverflow license issue should not be relevant.

 Richard

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2283539
>
> [2]
> https://github.com/nschloe/meshio/blob/b2ee99842e119901349fdeee06b5bf61e01f450a/src/meshio/stl/_stl.py#L49-L83
>
> [3] https://stackoverflow.com/help/licensing
>
> [4] https://stackoverflow.com/posts/8964779/timeline
>
> --
> ___
> legal mailing list -- legal@lists.fedoraproject.org
> To unsubscribe send an email to legal-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Should I mention Build-scripts' licensing terms in a spec's License field?

[Richard Fontana]

On Thu, Aug 1, 2024 at 7:10 AM Vít Ondruch  wrote:
>
>
> Dne 01. 08. 24 v 12:54 Neal Gompa napsal(a):
> > On Thu, Aug 1, 2024 at 6:33 AM Miroslav Suchý  wrote:
> >> Dne 01. 08. 24 v 12:28 odp. Peter Lemenkov napsal(a):
> >>> Hello!
> >>> I stumbled upon the following situation. I am packaging a library
> >>> under MIT license. However the upstream-provided build-script in a
> >>> tarball explicitly licensed under ISC license (has a header with ISC
> >>> license). If it matters I do not use this script for building at all.
> >>> So I have two questions.
> >>>
> >>> 1. If a tarball has a differently licensed file which is not going to
> >>> a final RPM should I still list its license in a spec's %license
> >>> field?
> >>> 2. Does it change anything if this file wasn't used at all during RPM
> >>> build process?
> >>>
> >> See
> >>
> >> https://gitlab.com/fedora/legal/fedora-legal-docs/-/issues/61
> >>
> >>   > Does not affect the License tag. But the license of the file must be 
> >> from the allowed list.
> >>
> > That's not the full answer. We do have a way to represent this
> > information by using the SourceLicense tag.
>
>
> I don't think this tag is reflected in our guidelines or is it?

No, because hardly anyone seems to be using it.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: License acceptability check for py-sdl

[Richard Fontana]

On Wed, Jul 24, 2024 at 2:20 PM Sandro  wrote:
>
> Hi,
>
> During package review [1] the license terms of py-sdl [2] were flagged
> as problematic. Therefore I'm passing this on to Fedora Legal for
> deciding on
>
> a) Does py-sdl2 come with an acceptable license?
> b) If so, which license should be specified?
>
> For the opposing views on the matter, please see comment 1 and 2 in the
> Bugzilla ticket.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2283541
> [2] https://github.com/py-sdl/py-sdl2/blob/master/doc/copying.rst

I basically side with Sandro here. It's not clear how best to
represent this as an SPDX expression in a spec file License: field (if
that's even a question) because of two complexities that Ben's comment
relates to. First, what is the author saying in the first part? I
think Ben is basically saying we should see that as `CC0-1.0`. But the
author only mentions CC0 because they say "since it is not enough
anymore to tell people: 'hey, just do with it whatever you like to
do'". From the Fedora perspective, it *is* enough, so I would see this
part as `LicenseRef-Fedora-Public-Domain` (assuming the relevant part
of the text were recorded under our current tedious procedure etc.)
and even if you view it as a sort of public domain | CC0 dual license,
for code Fedora would represent that as just
`LicenseRef-Fedora-Public-Domain` since (unless a usage exception
applies) `CC0-1.0` is not-allowed and thus is ignored if it is part of
a dual license where the other license is allowed.

Okay, that brings us to the Zlib part. This suggests that the Zlib
license grant applies "In cases, where the law prohibits the
recognition of Public Domain software". This statement embodies a
deep-rooted confusion in open source legal culture about the nature of
these public domain dedications going back two decades or more at this
point. (I won't bother to go into that whole topic.) Suffice it to
say, that from Fedora's point of view, it is assumed that the law does
not prohibit the recognition of "Public Domain software" in the sense
meant here. So I'd just ignore the Zlib part.

So, I see this as a candidate for `LicenseRef-Fedora-Public-Domain`.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Review and Guidance needed - licenses transforming based on time

[Richard Fontana]

On Wed, Jul 17, 2024 at 2:47 PM Vít Ondruch  wrote:
>
>
> Dne 17. 07. 24 v 15:45 Richard Fontana napsal(a):

> >   I think it's "fine" in theory, but somewhat risky. I imagine that in
> > some cases it won't be clear whether a particular version mixes BUSL
> > (at various stages of the process towards the "change date") and
> > post-BUSL licenses. And if we concluded that the change date had
> > occurred for everything, we might want to require some further action,
> > at a minimum documenting the conclusion (not just in the license tag)
> > and probably also at least including a copy of the post-BUSL allowed
> > license.
>
>
> Chm, I wonder how to for example apply security fix? Imagine there is
> some security issue fixed in the most recent version, will we
> reimplement such patch?

Good example. We generally won't be able to backport a BUSL-licensed
security fix to a now-free old version. Maybe reimplementing a patch
will be a solution.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Review and Guidance needed - licenses transforming based on time

[Richard Fontana]

On Wed, Jul 17, 2024 at 10:37 AM Michal Schorm  wrote:
>
> On Wed, Jul 17, 2024 at 4:14 PM Daniel P. Berrangé  
> wrote:
> > If it is MariaDB who are pushing this, then I'd note they could
> > take steps to make this into a total non-issue.
>
> Sure.
> I'm now here to understand what's the status on Fedora side. Once I
> get a clear understanding, I can start negotiations.
>
> I believe, however, we are about to hit this issue sooner or later
> again, with different similar licenses, and then with increasing
> frequency, as Neal suggested.
> So IMO it's worth debating now.

OK, well I think it's reasonably clear.
If, on a careful review, it is clear that some BUSL (or similar) stuff
has passed its "change date", and the "change license" is a Fedora
allowed license, then
the fact that BUSL is the nominally applicable license should not be a
categorical obstacle to packaging in Fedora. In such a case, Fedora
should take some extra steps to make clear that the operative license
is the Fedora allowed license, which at a minimum would be including a
copy of the allowed license. Ex-BUSL stuff would be associated with
the Fedora allowed license in the spec file license tag. Situations
where still-BUSL and ex-BUSL code are mixed together should be
particularly guarded against. It might be desirable to do more than
this, such as trying to excise all indications of the previous
applicability of the BUSL, but that seems like something Fedora
packagers won't want to do.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Review and Guidance needed - licenses transforming based on time

[Richard Fontana]

On Wed, Jul 17, 2024 at 7:33 AM Michal Schorm  wrote:
>
> Hello,
>
> I'd like a review of 'MariaDB Business Source License (BSL)'.
> Here is a specific instance of the license:
>   
> https://github.com/mariadb-corporation/MaxScale/blob/24.02/licenses/LICENSE2106.TXT
> Here is FAQ about it:
>   https://mariadb.com/bsl-faq-mariadb/
>
> TL;DR:
> the license says it's non-free, but it becomes free (GPL in this case)
> after a specific time.
>
> --
>
> Apart from this specific case, I'd like to hear your guidance in
> similar cases in general - whether they are mostly accepted or rather
> avoided (by Fedora), as more licenses with this idea exists, e.g.:
> https://github.com/getsentry/sentry/blob/master/LICENSE.md

As noted, BUSL-1.1 is already not allowed. The only other distantly
conceptually related license that has been considered by Fedora AFAIK
is the historically significant, but largely unused, license formerly
known as the Transitive Grace Period Public License, which was
classified as "good" under the Callaway system. However, TGPPL is
quite different from BUSL in that it is a copyleft license (OSL
derivative I believe) with a temporary permission for *licensees* to
distribute original or derivative works under a proprietary license.
The BUSL-derived Sentry licenses (currently the subject of an SPDX
issue) have AFAIK not been considered by Fedora, and I hope that these
licenses have no impact on any existing Fedora package.

But you've also asked an interesting question that also hasn't come up before:

"once it reaches the condition to
transform to a free license, whether it is absolutely fine to add the
software to Fedora under that specific free license, or whether there
is any specific point of view the Fedora Legal team holds, or other
specific requirements how to list the license correctly."

 I think it's "fine" in theory, but somewhat risky. I imagine that in
some cases it won't be clear whether a particular version mixes BUSL
(at various stages of the process towards the "change date") and
post-BUSL licenses. And if we concluded that the change date had
occurred for everything, we might want to require some further action,
at a minimum documenting the conclusion (not just in the license tag)
and probably also at least including a copy of the post-BUSL allowed
license.

I think we can cross the bridge when we come to it -- or have we come to it?

Also:

"Fedora package maintainers shouldn't try to guess
the resulting license(s) that applies to the user, they should only
list the licenses of the contents of the binary rpm.
In this case, assuming that the license already transformed to the
free one might be the guessing package maintainer shouldn't do."

I think this is alluding to the "no effective license" principle. But
in lots of situations we have to make guesses and interpretations of
various sorts. I can maybe see adopting the position that these
licenses are so odious that we don't want to distribute anything that
was even formerly under them (until the theoretical trigger to free is
reached) but that seems a little extreme to me if it's just a kind of
political gesture. There's already a license allowed in Fedora -- it's
pretty obscure and I can't remember the name offhand -- where the
license basically says something like "proprietary until the year
2000, then you have the following FOSS license" and this is allowed
because in that case the change date is clearly something that
occurred *long* ago.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: OpenAL docs redistribution / modification?

[Richard Fontana]

On Wed, Jul 17, 2024 at 7:17 AM Marián Konček  wrote:
>
> 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?

Unclear. I would probably assume yes.

> 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?

It's not the "All Rights Reserved" itself but the absence of anything
else at all (including contextual clues) that suggests that even
verbatim distribution is permitted.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Update on Fedora treatment of Nmap licensing

[Richard Fontana]

On Thu, Jul 11, 2024 at 11:48 AM Neal Gompa  wrote:
>
> On Thu, Jul 11, 2024 at 11:45 AM David Cantrell  wrote:
> >
> > On 7/11/24 11:19 AM, Richard Fontana wrote:
> > > On Thu, Jul 11, 2024 at 10:30 AM Richard Fontana  
> > > wrote:
> > >>
> > >> On Thu, Jul 11, 2024 at 10:05 AM David Cantrell  
> > >> wrote:
> > >>>
> > >>> Looking at Fedora now we have nmap-7.95 in Fedora 40 as an update and 
> > >>> it has:
> > >>>
> > >>> License: LicenseRef-NPSL-0.94
> > >>
> > >> Yes. This is erroneous because `LicenseRef-NPSL-0.94` inaccurately
> > >> referred to the license we are now calling `LicenseRef-NPSL-0.92`
> > >> (Callaway/Cotton "NPSL") but the license of Nmap changed several more
> > >> times in the progression to 7.95.
> > >>
> > >>> The exception is only for LicenseRef-Nmap and not these NPSL variants, 
> > >>> right?  Which means nmap will have to be removed?
> > >>
> > >> Yes,
> > >
> > > Actually the Nmap maintainer/licensor has informally offered to let
> > > Fedora continue to use `LicenseRef-Nmap` for 7.95 (if I understood
> > > what they were saying correctly) so that is a possibility. But clearly
> > > not a long-term solution.
> >
> > This idea makes me somewhat nervous.  Why would Fedora get an exception and 
> > not other distributors (or do other distributions also have exceptions)?  
> > And what does that mean for the actual code or patches shared between 
> > distributions?  I think unless the license in the source actually changes, 
> > taking this route would lead to problems.
> >
> > Do we know if upstream is open to discussing relicensing to a well-known 
> > and established open source license that would still offer the protections 
> > and guarantees they want?  That may not be possible.  Reading the 
> > LicenseRef-Nmap license I see a contributor agreement, lots of restrictions 
> > on derived works and how those are licensed, a patent grant, explicit 
> > permission to link with OpenSSL (thanks!), the license is governed by the 
> > laws of the State of Washington (ok, sure), an advertising clause if you 
> > set up a web site to execute nmap and display results -but then- the very 
> > next block says you don't have permission to use the trade names, 
> > trademarks, service marks, or product names.
> >
> > Looking a bit further at Fedora downstreams, I do see that nmap is part of 
> > RHEL.  And has been since RHEL-3.  Right now that's inherited via nmap's 
> > inclusion in Fedora.  If Fedora were to remove nmap, RHEL would have a 
> > decision to make.  I suppose that's fine, we are talking about Fedora here. 
> >  But we would at least want RHEL to be aware if that change were to happen.
>
> All the distributors that asked got the exception. I believe at one
> point it was even publicly stated that everyone could do this without
> requesting it after so many asked.

A further issue here is that many other distros seem to be assuming
that the iterations of the NPSL after the universally-condemned NPSL
0.92 (LicenseRef-NPSL-0.92) are all nonproblematic. I am not sure what
this is based on beyond a well-meaning impulse to believe that any
change to NPSL 0.92 must have been good enough.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Update on Fedora treatment of Nmap licensing

[Richard Fontana]

On Thu, Jul 11, 2024 at 10:30 AM Richard Fontana  wrote:
>
> On Thu, Jul 11, 2024 at 10:05 AM David Cantrell  wrote:
> >
> > Looking at Fedora now we have nmap-7.95 in Fedora 40 as an update and it 
> > has:
> >
> > License: LicenseRef-NPSL-0.94
>
> Yes. This is erroneous because `LicenseRef-NPSL-0.94` inaccurately
> referred to the license we are now calling `LicenseRef-NPSL-0.92`
> (Callaway/Cotton "NPSL") but the license of Nmap changed several more
> times in the progression to 7.95.
>
> > The exception is only for LicenseRef-Nmap and not these NPSL variants, 
> > right?  Which means nmap will have to be removed?
>
> Yes,

Actually the Nmap maintainer/licensor has informally offered to let
Fedora continue to use `LicenseRef-Nmap` for 7.95 (if I understood
what they were saying correctly) so that is a possibility. But clearly
not a long-term solution.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Update on Fedora treatment of Nmap licensing

[Richard Fontana]

On Thu, Jul 11, 2024 at 10:05 AM David Cantrell  wrote:
>
> Looking at Fedora now we have nmap-7.95 in Fedora 40 as an update and it has:
>
> License: LicenseRef-NPSL-0.94

Yes. This is erroneous because `LicenseRef-NPSL-0.94` inaccurately
referred to the license we are now calling `LicenseRef-NPSL-0.92`
(Callaway/Cotton "NPSL") but the license of Nmap changed several more
times in the progression to 7.95.

> The exception is only for LicenseRef-Nmap and not these NPSL variants, right? 
>  Which means nmap will have to be removed?

Yes, the reason for the exception applying to Callaway Nmap
(LicenseRef-Nmap) is mostly because we gave everyone the expectation
for years that the pre-NPSL version of the Nmap license was (barely)
legitimate. That's at least partly my fault. Whereas the only
post-Callaway-Nmap license Fedora passed judgment on (prior to this
thread) was the one we're now calling `LicenseRef-NPSL-0.92` and that
was considered "bad" from the start.

Richard

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Update on Fedora treatment of Nmap licensing

[Richard Fontana]

On Fri, Jul 5, 2024 at 11:33 PM Richard Fontana  wrote:
>
> 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/thread/GZIDC4DHXZP67LFU7P2OT2AQVDJRHZ2M/
> 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

Also, a couple of related SPDX issues:
https://github.com/spdx/license-list-XML/issues/1121
https://github.com/spdx/license-list-XML/issues/2492

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Update on Fedora treatment of Nmap licensing

[Richard Fontana]

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/thread/GZIDC4DHXZP67LFU7P2OT2AQVDJRHZ2M/
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

-- 
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Richard Fontana]

On Wed, Jun 26, 2024 at 10:24 AM Jerry James  wrote:
>
> On Wed, Jun 26, 2024 at 6:17 AM Miroslav Suchý  wrote:
> > We will get valid SPDX formula.
>
> Some legacy license names contain spaces.  Simply slapping
> "LicenseRef-Fedora-" on the front will only affect the first word of
> such multiword license names, resulting in an invalid SPDX formula.
> We would also have to convert those spaces to hyphens, right?

Correct, if I'm reading the SPDX license expression grammar correctly
(https://spdx.github.io/spdx-spec/v3.0//annexes/SPDX-license-expressions/),
spaces would have to be converted and the hyphen is probably the only
sensible separator. So e.g. "BSD with advertising" becomes
"LicenseRef-Callaway-BSD-with-advertising".

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Richard Fontana]

On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok  wrote:
>
> On 25. 06. 24 22:50, Miroslav Suchý wrote:
> > Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
> >>
> >> Could you make the comment something like this?
> >>
> >>   # Automatically converted from old format: GPLv2
> >>   # TODO check if there are other licenses to be listed
> >>   License: GPL-2.0-only
> >
> > We (the Change owners) discussed this on a meeting today. And we agreed on 
> > output:
> >
> ># Automatically converted from old format: GPLv2
> ># TODO convert to correct SPDX identifier
> ># See 
> > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/
> >License:  LicenseRef-Callaway-GPLv2
> >
> > This is valid SPDX identifier. But not on the list of Fedora's allowed
> > licenses, so any QA tool will remind you to check the license.
> >
> > What do you think?
>
> I don't understand what is the benefit of doing this at all. Sorry.

The benefit I see is that it immediately causes all license tags to
conform to the SPDX license expression standard, while also making it
very clear what parts of those license expressions are actually legacy
elements that have to be examined and replaced. (This assumes we
wouldn't use `LicenseRef-Callaway-` for any other purpose.)

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Richard Fontana]

On Mon, Jun 24, 2024 at 6:36 AM Vít Ondruch  wrote:
>
>
> Dne 22. 06. 24 v 12:12 Miroslav Suchý napsal(a):
>
> Dne 21. 06. 24 v 3:11 odp. Richard Fontana napsal(a):
>
> Could we wrap remaining Callaway names in a `LicenseRef-` (similar to
> your "callaway(MIT)" idea but sort of SPDX-conformant)?
> Red Hat is doing something like this in RHEL SBOMs, currently.
>
> Wow. This is good idea. +1 to this.
>
>
> That is certainly in line with what I was proposing => +1
>
> Just to clarify, this could actually be `LicenseRef-Callaway-` prefix, right?

I think it would have to be something like that. You'd need the
"Callaway" element to distinguish them from other LicenseRef's defined
by Fedora. We probably should have done this at the outset of the SPDX
migration.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Richard Fontana]

On Fri, Jun 21, 2024 at 5:27 AM Vít Ondruch  wrote:

> But the intent of both is to be temporary, to help understand where we
> need to put some work. If this was initial status:
>
> ~~~
> License: GPLv2 and MIT
> ~~~
>
> and prior any SPDX work, we would change all .spec files to:
>
> ~~~
> License: callaway(GPLv2 and MIT)
> ~~~
>
> And slowly worked forward to:
>
> ~~~
> License: GPL-2.0-only AND callaway(MIT)
> ~~~
>
> and finally:
>
> ~~~
> License: GPL-2.0-only AND MIT
> ~~~
>
> We would know where we are. Now, nobody knows. We still have to use
> something like changelog messages and what not, which is hardly better.
>
> We could even mark packages with e.g. `Provides: license(callaway)`,
> which would make easier to query where we stand.
>
> IMHO it is still is not late to do something like this!

Could we wrap remaining Callaway names in a `LicenseRef-` (similar to
your "callaway(MIT)" idea but sort of SPDX-conformant)?
Red Hat is doing something like this in RHEL SBOMs, currently.

Jilayne?

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Richard Fontana]

On Wed, Jun 19, 2024 at 11:58 AM Miro Hrončok  wrote:
>
> 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.

The meaning of something like "GPLv2" or "LGPLv3" in the Callaway™
(old notation) system was not consistently defined, documented or
understood. We've had some discussions about this (see legal list
threads on the so-called "effective license" concept). It is true that
under the Callaway system some package maintainers were applying some
sort of idiosyncratic effective license theory when populating license
tags, but prior to Fedora's migration to SPDX expressions I would have
asserted this was incorrect.

It should be noted btw that much (probably most) of the use of SPDX
identifiers in the open source community seems to be based on
application of various kinds of undocumented effective license
theories. So non-use of effective license theory is not an inherent
property of SPDX, at least in practice. The SPDX spec itself, and the
SPDX project, doesn't really assert an opinion on how SPDX expressions
should be used by projects (i.e., what something like `GPL-2.0-only`
*ought* to mean), at least as far as I understand. I'd argue that
proper use of SPDX expressions should lead to the non-use of effective
license analysis, which I guess implies that much of the use of SPDX
expressions is improper.

So anyway what I think you're basically saying is that if you
automatically convert a Callaway-notation package license tag from
`GPLv2` to `GPL-2.0-only`, the resulting license tag will often be
incorrect under the current (post-Callaway/SPDX-based) system. This is
true, but I would say that in such cases the license tag should have
been viewed as incorrect under the Callaway system for at least
partially the same reasons.

Relatedly, I have had some misgivings and mixed feelings about these
mass conversions, because I have worried that the resulting situation
will make people complacent regarding the correctness of the license
tag. That is, they may assume that a converted license tag has some
sort of implied stamp of approval. However, I've mostly gotten
comfortable with the piecemeal
mass conversions over time. I accept that we'll (still) have many
inaccurate license tags, under our current documented standards, and
we'll just have to gradually try to improve them.

I'm not sure it's really better to stick with Callaway license tags
for some longer period of time in the hope that the *first* attempt to
convert a package license tag to SPDX expressions will be relatively
accurate. I do worry that if everyone is complacent about this, Fedora
could become yet another project using SPDX expressions
inappropriately.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Brainpool Curves in Fedora (openssl, libgcrypt, gnupg)

[Richard Fontana]

On Thu, May 16, 2024 at 10:00 AM Fabio Valentini  wrote:
>
> On Tue, Nov 8, 2022 at 4:19 PM Matthew Miller  
> wrote:
> >
> > On Wed, Apr 06, 2022 at 05:31:10PM +0200, Felix Schwarz wrote:
> > > Am 06.04.22 um 16:13 schrieb Matthew Miller:
> > > >So, these things move slowly, but this _is_ being worked on. I'll let
> > > >you know when I can.
> > >
> > > Thanks :-)
> > > The day Red Hat is able to distribute the brainpool curves will be a
> > > great one for us.
> >
> > I have been told that it is okay to include Brainpool ECC in Fedora. Thank
> > you for your patience.
>
> Sorry for resurrecting this old thread.
> I just realized that the wiki has not been updated to reflect the fact
> that the Brainpool curves are considered OK now:
> https://fedoraproject.org/wiki/Legal:ECC
>
> Can somebody with edit privileges on that page update the list?
> Or should this documentation be moved somewhere else altogether (legal
> docs on docs.fp.o)?

It should probably be moved to docs.fp.o, we've been treating the
legal portions of the wiki as deprecated.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: GlobalProtect-openconnect - License violation or not?

[Richard Fontana]

On Thu, May 16, 2024 at 10:31 AM Jakub Kadlcik  wrote:
>
> 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/gpgui_x86_64.bin.tar.xz
>
> 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-1905168220
>
> 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-in-copr

I think the Copr conditions side of this is kind of unclear and it
relates to an issue that came up in the thread about packaging machine
learning models. If something distributed by Fedora (including through
a copr repository) is entirely compliant with Fedora technical and
licensing standards, but when you run it it downloads some additional
proprietary software, does that violate Fedora policy, even if there's
no issue of license noncompliance? As to the GPLv3 issue, I can't
speculate just on the facts you've stated, other than to say it is
probably not inherently a GPLv3 violation.

So I don't know if this should be seen as conformant to Fedora legal
and packaging policy, even leaving aside the issue of how much Copr
repositories can deviate from those policies, which seems itself to be
unclear.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Retiring celestia due to licensing issues

[Richard Fontana]

On Tue, Mar 26, 2024 at 3:10 AM Mattia Verga  wrote:
>
> As announced in [1] the message on devel list, I have retired celestia and 
> celestia-data due to some files have been discovered to be covered under 
> CC-BY-NC-SA-3.0 (plus some other are still waiting for a full check by 
> upstream).
> I wonder if I need to ask fedora-infra to remove all the sources from the 
> lookaside cache?
>
> Mattia
>
> [1] 
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/LAE5JLO3KYVQVSF776H4QLY6DTAUQHWR/

I think you should, since the Fedora legal docs say: "Fedora’s license
approval standards apply to everything that is made available by the
Fedora Project, not just installable binary packages in Fedora Linux."
In theory isn't anything in the lookaside cache being "made
available"?

To be sure, it's probably not the most urgent problem in the world.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Redis will no longer be OSS... now what?

[Richard Fontana]

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 unfortunate.

We haven't encountered RSAL(v2) before in Fedora AFAIK but I've just
reviewed it and concluded (easily) it should be classified it as
*not-allowed*.
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/497

SSPL of course is already classified as *not-allowed*.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: AI/ML Model and Pre-Trained Weight Packaging in Fedora

[Richard Fontana]

On Fri, Mar 1, 2024 at 10:25 PM Neal Gompa  wrote:

> At this point, this discussion is a bit much.
>
> We have game engines with data file downloaders for demo content, we
> have web browsers that auto-download things on launch, and so on.
>
> If you're really worried about it, tweak pytorch to require
> configuration or make a prompt when it triggers the first time or something.
>
> We did this with gdb with the debuginfod, and that's probably the
> closest pattern to go with for this.
>
> But this is not a legal question per se, this is a functionality and
> philosophy question.

I mean, why isn't it a legal question in some cases? What if a package
on first launch downloads an unauthorized copy of _Pirates of the
Caribbean_? I might be okay with the answer that "this has never
happened and we can deal with that problem if it ever arises".

It is a philosophical question, I think, whether Fedora would want to
tolerate the possibility of a package circumventing Fedora licensing
policy through post-installation downloads (leaving aside the issue of
user agency in this). That is directly raised by this pretrained
weights issue since at least some of the weights Tim is talking about
wouldn't satisfy Fedora licensing guidelines if packaged directly. I
don't think there's a right or wrong answer here, but I think Fedora
ought to have a consistent position on this.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: AI/ML Model and Pre-Trained Weight Packaging in Fedora

[Richard Fontana]

On Fri, Mar 1, 2024 at 5:38 PM Tim Flink  wrote:

> > pip, as an example is intended to allow users to install python packages
> > sourced from outside Fedora repos. I don't believe that software which
> > used pip after installation with no direct user interaction would be
> > allowed in Fedora.
> >
> > The pre-trained models that I'm familiar with, however, download things
> > transparently to the user with no warning outside of a log message when
> > the weights are first downloaded.

I feel like you're raising a more general issue here which I don't
really know the answer to. This is not specific to pretrained models.
Couldn't *any* Fedora package have behavior such that it "downloads
things transparently to the user with no warning"? If so, what if any
Fedora technical or packaging policy regulates this?

I can imagine a range of cases, such as:

1. Package provides a tool that can be used by a user to deliberately
obtain arbitrary third-party content under the user's direction. This
undoubtedly describes lots of existing Fedora packages and I think
it's pretty clear that this should normally be okay. Otherwise we
couldn't package firefox, wget, curl or pip.

2. Package causes the download (transparently to the user, unless you
assume a sort of omniscient user) of some content that would not
comply with default Fedora licensing policies if it were packaged
directly in the package. I feel like there must already be examples of
packages like this.

3. Package causes the download (transparently to the user ... ) of
some third-party content that violates some non-license-related Fedora
legal policy and which would not be permitted to be packaged directly.

4. Package causes the download of some third-party content that
violates some non-legal Fedora policy (for example, some sort of
content Fedora has deemed offensive).

5. Package causes the download of some third-party content that gives
rise to a security issue, where knowledge of the security issue would
have prevented direct packaging of the content.

I just skimmed through the Fedora packaging guidelines and the
FESCo-related documentation and didn't seem to find anything on this
sort of topic.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: AI/ML Model and Pre-Trained Weight Packaging in Fedora

[Richard Fontana]

Following Tim's explanations of various things, here are revised
answers to the questions:

On Mon, Feb 26, 2024 at 6:32 PM Tim Flink  wrote:

> Questions
> =
>
> 1. Are pre-trained weights considered to be normal non-code content/data or 
> do they require special handling?

For Fedora license classification purposes, they should be considered
"content". However, I think for any specific pre-trained weights that
will actually be included in Fedora packages, for some initial period
I'd like to do some further review (as noted upthread, because this is
an important policy area and we don't have a lot of prior experience
in it). I don't really care how that's done, that could be through
this list or a Bugzilla or whatever.

We'll add "pre-trained weights" to the list of examples of what
"content" is in the Fedora legal docs.

> 2. If an upstream offers pre-trained weights and indicates that those weights 
> are available under a license which is acceptable for non-code content in 
> Fedora, can those pre-trained weights be included in Fedora packages?

Yes subject to my answer to 1.

> 3. Extending question 2, is it considered sufficient for an upstream to have 
> a license on pre-trained weights or would a packager/reviewer need to verify 
> that the data used to train those weights is acceptable?

A packager/reviewer should not need to do that verification, which
seems highly impractical (which is a point I think you may have
previously made). However, that could be an aspect of the "initial
legal review" I'm suggesting we may want to have for such cases.

> 4. Is it acceptable to package code which downloads pre-trained weights from 
> a non-Fedora source upon first use post-installation by a user if that model 
> and its associated weights are
> a. For a specific model?
> b. For a user-defined model which may or may not exist at the time of 
> packaging?

Given your explanations of these cases, I think this is pretty straightforward.
4a: Yes
4b: Yes

These answers only go to matters of Fedora legal/licensing policy. If
there are technical issues raised by these questions (for example, if
there ought to be some standards around packaging of upstream
pre-trained weights) I can't give guidance or informed opinions on
that beyond my initial suggestion to raise this topic with FESCo which
seems to have been unsuccessful.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: AI/ML Model and Pre-Trained Weight Packaging in Fedora

[Richard Fontana]

On Fri, Mar 1, 2024 at 4:54 PM Neal Gompa  wrote:

> This sounds like it falls in the same bucket as pip, snapd, gem, and
> other similar "package manager" functionality.

I agree, that's a good analogy.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: AI/ML Model and Pre-Trained Weight Packaging in Fedora

[Richard Fontana]

On Tue, Feb 27, 2024 at 5:58 PM Tim Flink  wrote:
>
>
>
> On 2/26/24 19:06, Richard Fontana wrote:
>
> 
>
> >> 4. Is it acceptable to package code which downloads pre-trained weights 
> >> from a non-Fedora source upon first use post-installation by a user if 
> >> that model and its associated weights are
> >>  a. For a specific model?

What do you mean by "upon first use post-installation"? Does that mean
I install the package, and the first time I launch it or whatever, it
automatically downloads some set of pre-trained weights, or is this
something that would be controlled by the user? The example you gave
suggests the latter but I wasn't sure if I was misunderstanding.

Richard




> >>  b. For a user-defined model which may or may not exist at the time of 
> >> packaging?
> >>
> >>
> >>
> >> I can provide examples of any of these situations if that would be helpful.
> >
> > Can you elaborate on 4a/4b with examples?
>
> There are 2 simple examples for the two cases I mentioned (4a and 4b) at the 
> bottom of this email
>
> Tim
>
> -
> 4a - code that downloads pre-trained weights for a specific model
> -
>
> torchvision [1] is a pytorch adjacent library which contains "Datasets, 
> Transforms and Models specific to Computer Vision". torchvision contains code 
> to implement several pre-defined model structures which can be used with or 
> without pre-trained weights [2]. torchvision is distributed under a BSD 
> 3-clause license [3] and is currently packaged in Fedora as 
> python-torchvision but all of the specific model code is removed at package 
> build time and not distributed as a Fedora package.
>
> As an example, to instantiate a vision transformer (ViT) base model variant 
> with 16x16 input patch size and download pre-trained weights, the following 
> python code could be used:
>
> ```
> import torchvision
>
> vitb16 = torchvision.models.vit_b_16()
> ```
>
> The code describing the vit_b_16 model is included in torchvision but the 
> weights are downloaded from an external site when the model is first used. At 
> the time I write this, the weights are downloaded from 
> https://download.pytorch.org/models/vit_b_16-c867db91.pth
>
> In this case and for all the other models contained in torchvision, the exact 
> links to the pretrained weights are all contained within the torchvision code.
>
> Something worthy of note is that the weights for vit_b_16 are from Facebook's 
> SWAG project [4] which is distributed as CC-BY-NC-4.0 [5] and would not be 
> acceptable for use in a Fedora package. For the other models in torchvision, 
> some of the pre-trained weights have an explicit license (like ViT) but many 
> of them are not distributed under any explicit license (ResNet[6] as an 
> example).
>
> [1] https://github.com/pytorch/vision
> [2] https://github.com/pytorch/vision/tree/main/torchvision/models
> [3] https://github.com/pytorch/vision/blob/main/LICENSE
> [4] https://github.com/facebookresearch/SWAG
> [5] https://github.com/facebookresearch/SWAG/blob/main/LICENSE
> [6] https://pytorch.org/hub/pytorch_vision_resnet/
>
>
> 
> 4b - code that downloads an somewhat arbitrary model
> 
>
> One of the newer features of pytorch (which is still considered to be in 
> beta) is the ability to interface with "PyTorch Hub" [7] to use pre-defined 
> and pre-trained models which have been uploaded by other users. At the time 
> of this writing, the pytorch hub appears to be moderated by the pytorch team 
> but the underlying code which supports loading of semi-arbitrary models from 
> user-defined locations at runtime.
>
> As an example, this code loads a MiDaS v3 large model with pre-trained 
> weights directly from intel's github repo [8].
> ```
> model_type = "DPT_Large"
> midas = torch.hub.load("intel-isl/MiDaS", model_type)
>
> ```
>
> Similar to the ViT example above, this model will download weights from a url 
> (https://github.com/isl-org/MiDaS/releases/download/v3/dpt_large_384.pt at 
> the time of this writing) but unlike the ViT example, the definitions of the 
> model and where the weights are located are determined by code contained in 
> the github repository specified by the user [9] and downloaded at runtime to 
> determine the exact link to any code and pre-trained weights. The MiDaS 
> repository is distributed under an MIT lice

[Fedora-legal-list] Re: AI/ML Model and Pre-Trained Weight Packaging in Fedora

[Richard Fontana]

On Mon, Feb 26, 2024 at 6:32 PM Tim Flink  wrote:

> 1. Are pre-trained weights considered to be normal non-code content/data or 
> do they require special handling?

My thought is that they should be considered "content" for Fedora
packaging purposes. The legal docs say:

"For purposes of Fedora license classification, “content” means any
material that is not clearly code, documentation, fonts or firmware.
Here are some examples of content:
graphic image files
audio files
nonfunctional data sets
AppStream metainfo.xml files
standards documents
certain files relating to functionality and management of markup
languages, including XML schema files and resource resolution files,
XSL files, SGML declaration files, and ancillary informal
documentation accompanying such files"

First, aren't trained model weights a kind of "nonfunctional data
set"? (We don't define what "nonfunctional" means -- I'm pretty sure
we copied that phrase from the old wiki documentation -- and frankly
I'm not sure what it means, but I think it goes to the nonexecutable
nature of the data. Weights don't function by themselves.)

Second, it seems to me that pretrained model weights are "not clearly
code, documentation, fonts or firmware". One of the purposes of the
content category is to allow relaxed license criteria for
noncode/non-documentation things needed by Fedora packages. Note
though that the current relaxed criteria only extends to two features:
"The license may restrict or prohibit modification
The license may say that it does not cover patents or grant any patent
licenses" (the latter being a reference to CC0)

However, there is a reason why I felt it was important to bump this
issue to FESCo. I thought FESCo might wish to take a position that
pretrained weights, being the result of a training process on some
training data, are analogous to object code (even if not "code" for
Fedora license classification purposes). It sounds like they don't
want to take a position on this.

This topic relates very closely to certain current issues of interest
in the wider world, for example the Open Source Initiative's effort to
define "Open Source AI" (see: https://discuss.opensource.org/) There
is definitely some sentiment among some participants in that effort
that, for a so-called "AI system" to be "open source", training data
must be "open", largely because it is thought that this is necessary
for users to exercise rights of modification. I don't think that
debate is dispositive of the Fedora question. If a Fedora package
contains pretrained weights, it is not necessarily an assertion that
such a package is "open source" in a precise sense, any more than
Fedora is asserting that firmware packages are "open source". It is
true that Fedora cannot reasonably claim to be 100% FOSS if it
packages stuff like firmware, or "content" under licenses that
prohibit modification.

You might say that holders of those viewpoints in the OSI effort are
adopting a view that model weights are "code", if you map things to
Fedora license approval concepts.

Anyway, I'm struggling to see a justification for not classifying
pretrained weights as "content". I am not sure it is of much practical
significance though.

> 2. If an upstream offers pre-trained weights and indicates that those weights 
> are available under a license which is acceptable for non-code content in 
> Fedora, can those pre-trained weights be included in Fedora packages?

This is what I thought ought to be a FESCo question. If FESCo doesn't
actually care and sees this as a Fedora legal question, then this
question is really equivalent to the first question, isn't it? If it's
"content", and it's under a license acceptable for "content", then as
far as Fedora legal is concerned it can be included in Fedora
packages.

> 3. Extending question 2, is it considered sufficient for an upstream to have 
> a license on pre-trained weights or would a packager/reviewer need to verify 
> that the data used to train those weights is acceptable?

So this is where I think we should initially be a little cautious and
look at these things on a case-by-case basis, perhaps until we get
more experience with handling this topic. Maybe there could be
circumstances where given what is disclosed, or not disclosed, about
how a model was trained, we might want to not package the pretrained
weights in Fedora. I think that is unlikely, but not impossible.

> 4. Is it acceptable to package code which downloads pre-trained weights from 
> a non-Fedora source upon first use post-installation by a user if that model 
> and its associated weights are
> a. For a specific model?
> b. For a user-defined model which may or may not exist at the time of 
> packaging?
>
>
>
> I can provide examples of any of these situations if that would be helpful.

Can you elaborate on 4a/4b with examples?

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send 

[Fedora-legal-list] Re: Using the GPL as MPL Secondary license (Was: [Fedora-legal-list] Re: SPDX Statistics - R.U.R. edition)

[Richard Fontana]

On Mon, Feb 19, 2024 at 12:28 PM Mark Wielaard  wrote:
>
> Hi Richard,
>
> On Wed, 2024-01-17 at 21:22 -0500, Richard Fontana wrote:
> > On Wed, Jan 17, 2024 at 6:57 PM Mark Wielaard  wrote:
> > > On Fri, Nov 24, 2023 at 08:07:02PM +0100, Mark Wielaard wrote:
> > > > On Mon, 2023-09-18 at 20:47 -0400, Richard Fontana wrote:
> > > > > On Sun, Sep 17, 2023 at 11:37 AM Mark Wielaard  wrote:
> > > > > > Likewise for valgrind we have examples of the above. For example the
> > > > > > dhat tool which have a GPLv2+ copyright and license header, but also
> > > > > > say:
> > > > > >
> > > > > > /*
> > > > > >Parts of this file are derived from Firefox, copyright Mozilla 
> > > > > > Foundation,
> > > > > >and may be redistributed under the terms of the Mozilla Public 
> > > > > > License
> > > > > >Version 2.0, as well as under the license of this project.  A 
> > > > > > copy of the
> > > > > >Mozilla Public License Version 2.0 is available at at
> > > > > >https://www.mozilla.org/en-US/MPL/2.0/.
> > > > > > */
> > > > > >
> > > > > > Again, although there is a reference to MPLv2 here, the code is only
> > > > > > available under GPLv2+.
> > > > >
> > > > > But that notice literally says there is code available under MPL 2.0.
> > > > >
> > > > > If the notice is incorrect, that is a bug that should be fixed
> > > > > upstream. But a mere conflict with a project's conception of what its
> > > > > effective license is would not mean that the license notice is
> > > > > incorrect.
> > > >
> > > > In the case of relicensing MPLv2 to GPLv2+ you could indeed argue that
> > > > no notice at all should remain in the source file to the MPLv2. The
> > > > MPLv2 does indeed require you remove all MPL notices when converting a
> > > > source file to the GPL. But again I consider it rude to not even
> > > > mention the origin of the source code and provide a (historical)
> > > > reference.
> > >
> > > So in the above case, what would be your advice? Should upstream
> > > change that notice that tells the user the original code (over there)
> > > is also available under the MPL, but that this derived version is only
> > > distributed under the GPL? Or should they just completely remove the
> > > reference to the original MPL code?
> >
> > What MPL-2.0 actually says on this (if I'm understanding the situation
> > correctly) is:
> >
> > "You may create and distribute a Larger Work under terms of Your
> > choice, provided that You also comply with the requirements of this
> > License for the Covered Software. If the Larger Work is a combination
> > of Covered Software with a work governed by one or more Secondary
> > Licenses, and the Covered Software is not Incompatible With Secondary
> > Licenses, this License permits You to additionally distribute such
> > Covered Software under the terms of such Secondary License(s), so that
> > the recipient of the Larger Work may, at their option, further
> > distribute the Covered Software under the terms of either this License
> > or such Secondary License(s)."
> >
> > If dhat is the 'Larger Work' here (caveat, I haven't actually looked
> > at dhat and I don't know what it actually copies from Firefox source
> > code), what MPL seems to be saying is that the original creator of
> > dhat has to provide the choice of licenses to their recipients. I seem
> > to remember telling Luis Villa that I found this a little puzzling
> > when I first looked at it but that was many years ago now.
>
> Right, the MPL-2.0 "combining" FAQ also says you have to do this double
> step dance. First publish as a dual license subject to the terms of the
> MPL 2.0 and then further distribute it just under the secondary
> license. Which is what seems to have happened in the valgrind git
> repository. It is a little puzzling because the creator and the
> recipient could simply be the same person (but technically in the
> valgrind git repo the commits were made by different people).
>
> > > I assume the License tag in the above case would simply be
> > > GPL-2.0-or-later without any mention of the MPL?
> >
> > Given the wording of that notice, plus the underlying compliance

[Fedora-legal-list] Re: License review for package scummvm

[Richard Fontana]

On Wed, Feb 14, 2024 at 8:12 PM Richard Fontana  wrote:
>
> On Wed, Feb 14, 2024 at 6:55 PM Christian Krause  
> wrote:
> >

> > COPYING.GLAD contains:
> > - an MIT license (although "Software" is substituted with "materials")
> > - an Apache 2.0 license
> > - another MIT license
> > -> SPDX: MIT AND Apache-2.0
>
> The Khronos license uses "the Materials" instead of "the Software".
> There was a recent issue in github.com/spdx/license-list-XML about
> this, I forget where SPDX ended up on this (whether to revise `MIT` or
> to create a new identifier), check the SPDX issues or wait for Jilayne
> to chime in. :)

There is already this open issue:
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/238
although that is about a different version of the license with an
additional admonition paragraph. The SPDX issue is:
https://github.com/spdx/license-list-XML/issues/2017
I'm not clear on whether the SPDX issue is considering the
non-admonition variant.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: License review for package scummvm

[Richard Fontana]

On Wed, Feb 14, 2024 at 6:55 PM Christian Krause  wrote:
>
> Hi,
>
> I would like to ask for some help determining the correct licenses and SPDX 
> tags for "scummvm". Please see my three questions further down the mail.
>
> I'm currently updating the scummvm package to a new upstream version (which 
> introduced a new license) and additionally I'm attempting to migrate the 
> license tags to SPDX.
>
> - current license tag for scummvm-2.7.1
> "License:GPLv3+ and LGPLv2+ and BSD and OFL and MIT and ISC"
>
> - scummvm-2.8.0 lists now the following licenses in its source:
>- main license file https://github.com/scummvm/scummvm/blob/v2.8.0/COPYING
>- additional licenses in 
> https://github.com/scummvm/scummvm/tree/v2.8.0/LICENSES/
>
> - here is my attempt to map the old license tags to the license files and the 
> new SPDX tags:
>
> GPLv3+:
> - COPYING
> - COPYING.FREEFONT
> -> SPDX: GPL-3.0-or-later

COPYING.FREEFONT is GPL-3.0-or-later WITH Font-exception-2.0 (already
allowed in fedora-license-data)

> LGPLv2+:
> - COPYING.LGPL
> -> SPDX: LGPL-2.0-or-later

This should be LGPL-2.1-or-later

> BSD:
> - COPYING.BSD

This file contains multiple licenses. Some are instances of
BSD-3-Clause. The others (the University of California one and the
Erik Corry one) appear to be a match to Cornell-Lossless-JPEG. You
have to submit an issue to get this added to fedora-license-data (IIRC
I was the one who submitted it to SPDX in anticipation of its being
needed for Fedora).

> - COPYING.MKV
> -> SPDX: BSD-3-Clause
>
> MIT:
> - COPYING.MIT
> - COPYING.TINYGL
> -> SPDX: MIT
>
> ISC:
> - COPYING.ISC
> -> SPDX: ISC
>
> OFL:
> - COPYING.OFL
> -> SPDX: OFL-1.1-RFN

> COPYING.GLAD contains:
> - an MIT license (although "Software" is substituted with "materials")
> - an Apache 2.0 license
> - another MIT license
> -> SPDX: MIT AND Apache-2.0

The Khronos license uses "the Materials" instead of "the Software".
There was a recent issue in github.com/spdx/license-list-XML about
this, I forget where SPDX ended up on this (whether to revise `MIT` or
to create a new identifier), check the SPDX issues or wait for Jilayne
to chime in. :)

> COPYING.LUA
> - not the standard MIT license
> - however, LUA homepage (https://www.lua.org/license.html) explicitly states 
> that old lua versions can be used under MIT
> -> SPDX: MIT

IMO this is incorrect, you should either submit a fedora-license-data
issue for the Lua license (which does not seem to have been considered
by Fedora or SPDX before) or get the scummvm project to change the
license notices for the Lua code from the legacy Lua license to the
MIT license.

> QUESTION 1: Are my findings so far correct?

See above.

> QUESTION 2: As far as I understand, there is no need to do any "effective 
> license" analysis, so can I just use these tags concatenated with AND?

If that accurately reflects how these licenses are actually used in
the package, yes.

> new in scummvm-2.8.0: CatharonLicense.txt
> - seems to be previously used for the auto-hinter in FreeType
> - it looks like it is considered compatible to the FreeType license:
> - http://www.fifi.org/doc/libfreetype6/ft2faq.html#autohint-license
> - additional information:
> - https://directory.fsf.org/wiki/Freetype#tab=Details
> - 
> https://changelogs.ubuntu.com/changelogs/pool/main/f/freetype/freetype_2.6.1-0.1ubuntu2/copyright
> - it is not listed in 
> https://docs.fedoraproject.org/en-US/legal/allowed-licenses/
> - the FreeType license is listed as allowed license
>
> QUESTION 3: How to proceed with that license?

Please open an issue at fedora-license-data for review of the license.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: License check

[Richard Fontana]

On Wed, Feb 7, 2024 at 10:02 AM Orion Poplawski  wrote:

> But mainly I was looking for confirmation that I do need to list all of
> the licenses of all of the third_party code.
>
> I think
> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> could be clearer on this point.

That page is somewhat out of date relative to the legal documentation. The page
https://docs.fedoraproject.org/en-US/legal/license-field/
was completely rewritten a few months ago though is still incomplete.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: IBM non-free patent notice

[Richard Fontana]

On Thu, Jan 18, 2024 at 5:23 AM Florian Weimer  wrote:
>
> * Richard Fontana:
>
> > I think the only complication here is that there is currently no
> > active contributor to glibc from IBM,
>
> This is not accurate, several people from IBM are regularly contributing
> to glibc.  IBM is very active in the GNU toolchain in general, and I
> don't see this changing while we use the GNU toolchain to build Fedora.

Indeed, I don't know why I had a mistaken impression.

> However, the glibc code in question has no active maintainer, IBM or
> otherwise, but this doesn't strike me as particularly relevant to
> relicensing (which would not be the appropriate thing to do without
> approval from the copyright holder even if there was an active
> maintainer).  It matters to a potential full rewrite, but that's
> difficult for one of the impacted files because there is no clear
> specification what it should do (it's for debugging output).  But as far
> as I understand it anyway, the rewrite won't be necessary, so I haven't
> explored this approach.

Good news, this has now been fixed:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ae49a7b29acc184b03c2a6bd6ac01b5e08efd54f

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: LicenseRef-Fedora-SourceLicenses (Was: Re: SPDX Statistics - R.U.R. edition)

[Richard Fontana]

On Thu, Jan 18, 2024 at 8:15 AM Vít Ondruch  wrote:
>
> BTW this is interesting discussion about license field not being
> expressive enough:
>
> https://github.com/puma/puma/issues/3311#issuecomment-1886065710
>
> TLDR: "What I do not want is for someone to think BSD, MIT in the
> license field applies to the entire Puma project, as that is not how
> this project is licensed. We're talking about 50 lines of code in a
> 5000+ line library, giving the two equal billing in the licenses field
> doesn't describe what's happening here."

That is an interesting point. In Fedora's case, no one should be
getting the impression that all the licenses in a License: tag
expression have "equal billing" but I understand how that could be
seen as an undesirable effect.

At one time I thought about a convention where the License tag would
only list the top N results of a source code license scanning tool (I
was thinking of ScanCode) but for various reasons that could be
unsatisfactory. This kind of relates to comments about "effective
licenses" and so forth. Sometimes what people seem to mean by this is
"the majority license of the project", but I think it could be
challenging to come up with a precise definition of this.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: LicenseRef-Fedora-SourceLicenses (Was: Re: SPDX Statistics - R.U.R. edition)

[Richard Fontana]

On Thu, Jan 18, 2024 at 8:09 AM Vít Ondruch  wrote:
>
> It seems to me that SPDX on itself supports:

> DocumentRef-"(idstring)"
>
> https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
>
> Therefore if we support SPDX and SPDX supports this, then we support it,
> don't we?

Yes, in theory, but I am not actually not familiar with how
'DocumentRef-' is used (as opposed to 'LicenseRef-' which we use
extensively). I don't see an explanation of this in the SPDX spec so I
assume just from the grammar that 'DocumentRef-' is a way of tying a
'LicenseRef-' to a particular SPDX document. We are not preparing SPDX
documents so we shouldn't need to use 'DocumentRef-'. But hopefully
Jilayne will see this and clarify.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: license-tag purpose/goal (Was: Re: SPDX Statistics - R.U.R. edition)

[Richard Fontana]

On Wed, Jan 17, 2024 at 5:57 PM Mark Wielaard  wrote:

> > > I have no attachment to RPM-style
> > > license tags, though Red Hat finds them marginally useful for some
> > > purposes.
> >
> > What are the purposes for which Red Hat finds the spec license tags
> > useful?
>
> I am still interested in this because I think it will help people
> understand why they are doing all this work.

I think there may be some confusion here. Red Hat originally developed
RPMs as a packaging technology and from what I understand, from an
early period there was a data field in spec files for licensing
information (IIRC it was originally "Copyright:" rather than
"License:"). Many other packaging technologies attempt to document
licensing information. Some are worse than others. When I say that Red
Hat finds spec file License tags useful for some things, this has
nothing to do with the adoption of SPDX license expressions in License
tags; the usefulness predates that recent development by many years.
That said, for those uses, the adoption of SPDX license expressions
makes the License tags significantly more useful because it is
associated with an improvement in the quality of the data. (This has
something to do with the nature of SPDX license expressions but it
also has to do with the process bringing about a wave of active review
of licensing information in Fedora packages.)

Also, to be clear, Fedora's adoption of SPDX identifiers is *not*
being done to help Red Hat, except to the extent that Red Hat is a
major sponsor of and contributor to Fedora.

That said, RPM License tags are sometimes used for these purposes at Red Hat:
(1) Naturally, people have always used them as a quick way of
assessing the license of a package (for example, as a highly flawed
method of answering the question "How many packages in Fedora/RHEL use
LGPLv3" and so forth). Of course this sort of use isn't specific to
Red Hat.
(2) Red Hat historically published so-called package manifests for
RHEL that were basically lists of RPMs with the content of the
License: field. Nowadays I think the equivalent is provided in SBOM
format.
(3) Some Red Hat partners and customers are interested in licensing
details at the level of the package and for RPM-based products or
portions of products the usual way of producing this information is to
provide the content of the License: field for each RPM.
I think that's it.

My view is that by switching to SPDX license expressions, along with
changes we've made to Fedora legal documentation, we are making major
improvements to the quality and sophistication of this kind of
information. But if I thought it was only something that would benefit
downstream product derivatives of Fedora I wouldn't support it.

This all makes it sound like I'm a fan of SPDX so I hope people
understand I'm not. Basically, SPDX is the worst license
representation system we have, but I begrudgingly accept that it's
better than all the others. I think my colleagues on the Fedora Legal
team *are* authentic fans of SPDX. :)

> I am slightly surprised Red Hat (and Fedora) finds the SPDX
> indetifiers as license tags/expression language useful. I thought that
> making sure the company/project always complies with, and makes sure
> that all users can easily comply with, the licenses by distributing
> the complete, corresponding source code and build scripts (in the
> srpm) is way simpler and effective.

We don't use the License: tags for purposes of license compliance, so
these two things are not in conflict. Red Hat indeed normally
approaches license compliance by providing the corresponding source
code, and this is also true of Fedora. The usefulness is for
non-compliance-related activities.

I think some of the confusion may relate to the fact that in the
industry, in open source-related contexts, "compliance" somehow came
to mean, as a colleague once put it, "making lists of stuff", which is
very puzzling. But anyway this has nothing to do with Red Hat, or
Fedora.

It's very legitimate to ask why we have License tags at all, but few
people have asked that. We didn't invent the practice in 2022; it
existed in some form for decades (or at least as far back as the early
years of Fedora, offhand I don't know if it originates in the Red Hat
Linux era). In adopting SPDX license expressions, as I see it, the
justification was basically, "if we're going to continue this
long-established practice of having License tags, we might as well use
the least bad license representation system".

But in saying all this I realize I am continuing to conflate the two
main uses of SPDX license expressions (or at least SPDX license
identifier conventions) in Fedora. We don't just use SPDX identifiers
in License tags. Our original 2022 documentation was really confusing
about this, probably because *we* were initially confused about it,
and I've tried to make a lot of changes to clear this up. We more
fundamentally use SPDX identifiers as a classification system in
approv

[Fedora-legal-list] Re: IBM non-free patent notice (Was: Re: SPDX Statistics - R.U.R. edition)

[Richard Fontana]

On Wed, Jan 17, 2024 at 6:15 PM Mark Wielaard  wrote:
>
> Hi Richard,
>
> On Fri, Nov 24, 2023 at 08:07:02PM +0100, Mark Wielaard wrote:
> > On Mon, 2023-09-18 at 20:47 -0400, Richard Fontana wrote:
> > > While the Sun RPC problem *may* have been excised from glibc, just
> > > last year we found another license in glibc (and at least one other
> > > package), this time an IBM license [1], that we consider non-free by
> > > present day standards, in that case because it involves a patent
> > > license grant that discriminates according to specific use cases. I
> > > think we should aspire to finding, *exposing*, and fixing these kinds
> > > of problems. Exposing should mean at a minimum that we don't
> > > perpetuate a community-wide decades-old practice of covering these
> > > problems up, which seems to be one practical effect of indulging in
> > > effective licensing. I realize all this doesn't itself justify the
> > > resulting use of complex composite SPDX expressions.
> >
> > Right, I assume you are talking about the resolv code which carries a
> > patent notice from IBM saying they might sue you if you use that code
> > for anything else than doing DNS resolving over TCP/IP. Which is indeed
> > a odd notice. Happy you found it and you are making IBM fix it. But
> > IMHO it is just an unintended, license, bug in the upstream package. It
> > will be fixed, so no need for some complicated license tag.
>
> So I noticed this isn't actually fixed yet. glibc is preparing their
> next release, but the code still has two notices saying:
>
>  * To the extent it has a right to do so, IBM grants an immunity from suit
>  * under its patents, if any, for the use, sale or manufacture of products to
>  * the extent that such products are used for performing Domain Name System
>  * dynamic updates in TCP/IP networks by means of the Software.  No immunity 
> is
>  * granted for any product per se or for any other function of any product.
>
> Which I assume is the notice you are worried about because it isn't
> clear if there are actual patents and/or if any other (implied) patent
> license has been granted by IBM.

That's the license but it's not that I'm "worried" about this license
at all (which covers very ancient code, I think from the early 1990s).
Also, as I think I mentioned, IBM has agreed to relicense any IBM code
under this license under the MIT license. Rather, it's an issue of
licensing policy. This is not a free software license, at least by
modern standards, and Fedora's policy is that 'code' must be under
free software licenses (as determined by Fedora), though we now have a
framework for documenting special exceptions.

> Normally I would say just remove the ineffective notice, but sadly
> just above it, IBM states "all paragraphs of this notice appear in all
> copies". Sigh.
>
> So what is the correct license tag to use here? Would SPDX provide an
> identifier for this?

No, we didn't submit this one to SPDX because Fedora's approach is not
to seek SPDX identifiers for licenses that are "not allowed". (I
suspect if we had decided to allow it, SPDX would have added an
identifier.) We have a Fedora-defined identifier,
`LicenseRef-IBM-BIND`. However, the actual problem here is that I
never got back to Florian Weimer about how to actually get this
changed in glibc and it keeps slipping my mind. I think the only
complication here is that there is currently no active contributor to
glibc from IBM, and it would possibly be inappropriate for a non-IBMer
to submit a patch to glibc to change a license that seems to be from
IBM. It's really just a process issue.

Personally, I don't really care too much if, in the License tag, this
is represented as 'MIT' or 'LicenseRef-IBM-BIND', except that with the
latter it will fail rpminspect unless (I think) we document a usage
exception.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: When can license notices be removed or not (Was: Re: SPDX Statistics - R.U.R. edition)

[Richard Fontana]

On Wed, Jan 17, 2024 at 6:34 PM Mark Wielaard  wrote:

> Although I don't like the advice I am interested when such license
> notices can be removed. That would make some discussions about whether
> or not to include extra tags/expressions easier (if it is possible to
> just remove the notice, then it also doesn't need to be mentioned in a
> license tag/expression).
>
> It was my understanding that legal notices can never be removed,
> because most licenses actually say you may not remove them, but that
> might be chicken-egg reasoning :)

It's not chicken-egg reasoning. It's correct that most free software
licenses require notices not to be removed (assuming they're actual
licenses in a given case of course). But with some free software
licenses, there is no such requirement.

However, you say: "if it is possible to just remove the notice, then
it also doesn't need to be mentioned in a
license tag/expression". I have suggested this sort of approach. This
would eliminate all use of `LicenseRef-Fedora-Public-Domain` and
`LicenseRef-Fedora-UltraPermissive` umbrella identifiers from License
tags (note, it would not justify eliminating these identifiers from
Fedora License Data or ending the attempt to catalogue licenses in
these categories). But my Fedora Legal team colleagues seemed to
dislike this suggestion. I think we should continue to consider it.
Also if we adopted this approach, there's the difficult question of
what to do about CC0, which has no notice preservation requirement of
course, but which has something "wrong" with it (the clause about no
patent licenses) which I think may be a good reason to include CC0-1.0
in License tags, at least in those cases where CC0 is applied to code.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Using the GPL as MPL Secondary license (Was: [Fedora-legal-list] Re: SPDX Statistics - R.U.R. edition)

[Richard Fontana]

On Wed, Jan 17, 2024 at 6:57 PM Mark Wielaard  wrote:
>
> Hi Richard,
>
> On Fri, Nov 24, 2023 at 08:07:02PM +0100, Mark Wielaard wrote:
> > On Mon, 2023-09-18 at 20:47 -0400, Richard Fontana wrote:
> > > On Sun, Sep 17, 2023 at 11:37 AM Mark Wielaard  wrote:
> > > > Likewise for valgrind we have examples of the above. For example the
> > > > dhat tool which have a GPLv2+ copyright and license header, but also
> > > > say:
> > > >
> > > > /*
> > > >Parts of this file are derived from Firefox, copyright Mozilla 
> > > > Foundation,
> > > >and may be redistributed under the terms of the Mozilla Public 
> > > > License
> > > >Version 2.0, as well as under the license of this project.  A copy 
> > > > of the
> > > >Mozilla Public License Version 2.0 is available at at
> > > >https://www.mozilla.org/en-US/MPL/2.0/.
> > > > */
> > > >
> > > > Again, although there is a reference to MPLv2 here, the code is only
> > > > available under GPLv2+.
> > >
> > > But that notice literally says there is code available under MPL 2.0.
> > >
> > > If the notice is incorrect, that is a bug that should be fixed
> > > upstream. But a mere conflict with a project's conception of what its
> > > effective license is would not mean that the license notice is
> > > incorrect.
> >
> > In the case of relicensing MPLv2 to GPLv2+ you could indeed argue that
> > no notice at all should remain in the source file to the MPLv2. The
> > MPLv2 does indeed require you remove all MPL notices when converting a
> > source file to the GPL. But again I consider it rude to not even
> > mention the origin of the source code and provide a (historical)
> > reference.
>
> So in the above case, what would be your advice? Should upstream
> change that notice that tells the user the original code (over there)
> is also available under the MPL, but that this derived version is only
> distributed under the GPL? Or should they just completely remove the
> reference to the original MPL code?

What MPL-2.0 actually says on this (if I'm understanding the situation
correctly) is:

"You may create and distribute a Larger Work under terms of Your
choice, provided that You also comply with the requirements of this
License for the Covered Software. If the Larger Work is a combination
of Covered Software with a work governed by one or more Secondary
Licenses, and the Covered Software is not Incompatible With Secondary
Licenses, this License permits You to additionally distribute such
Covered Software under the terms of such Secondary License(s), so that
the recipient of the Larger Work may, at their option, further
distribute the Covered Software under the terms of either this License
or such Secondary License(s)."

If dhat is the 'Larger Work' here (caveat, I haven't actually looked
at dhat and I don't know what it actually copies from Firefox source
code), what MPL seems to be saying is that the original creator of
dhat has to provide the choice of licenses to their recipients. I seem
to remember telling Luis Villa that I found this a little puzzling
when I first looked at it but that was many years ago now.

> I assume the License tag in the above case would simply be
> GPL-2.0-or-later without any mention of the MPL?

Given the wording of that notice, plus the underlying compliance issue
noted above, I think the License tag should include `(GPL-2.0-or-later
OR MPL-2.0)`.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: LicenseRef-Fedora-SourceLicenses (Was: Re: SPDX Statistics - R.U.R. edition)

[Richard Fontana]

On Wed, Jan 17, 2024 at 5:47 PM Mark Wielaard  wrote:
>
> Hi Richard,
>
> Going to chop this discssion into smaller parts.
>
> On Fri, Nov 24, 2023 at 08:07:02PM +0100, Mark Wielaard wrote:
> > On Mon, 2023-09-18 at 20:47 -0400, Richard Fontana wrote:
> > > I think anyone should be free to propose a new umbrella identifier (in
> > > SPDX expression format) that would cover multiple licenses, as we've
> > > done with `LicenseRef-Fedora-Public-Domain` and
> > > `LicenseRef-Fedora-UltraPermissive`. The important thing is that it be
> > > well defined in some way.
>
> One idea would be to just collect all licenses, copyrights and notices
> as found in the actual sources and put them into one file put in the
> srpm. Kind of like debian/copyright. The advantage is that you then
> don't have to find some exact (or inexact) match with specific
> identifiers and that it can be shared with upstream and/or other
> distros. For the packager they can just put
> LicenseRef-Fedora-SourceLicenses in the License field instead of
> trying to come up with some expression that mimics the actual license
> texts. For the users it is also easier to have the actual license
> notices text all together in a known place/file.

I would support this idea if we were starting from scratch. The
problem is that Fedora (and Red Hat) have had this tradition of *not*
doing that, and this tradition of (instead?) using the License: tag
for RPMs, so a move to  Debian copyright sort of system would be a
much more radical change than, say, the switch from Callaway notation
to SPDX license expressions. I expect it would meet massive resistance
from Fedora package maintainers. I could be wrong though. :)

A possible idea is to have this be an optional approach the package
maintainer could take, more or less as you describe. I have thought of
something like that. When I suggested something similar to this idea
to my fellow Fedora Legal/SPDX Migration team members, I think their
general sentiment was skeptical to negative.

Anyway, I don't think this idea should be dismissed, but it would be
challenging to adopt. We should possibly admit to ourselves that the
License: tag approach was always highly flawed and we've basically
been putting bandaids on it.

It should be noted that if we switched to this sort of approach it
wouldn't mean abandoning the use of SPDX identifiers since we'd still
use them for purposes of license approval and license classification,
and conceivably also in the equivalent of the "copyright" file itself.

If I remember correctly, someone on this list (Neal?) said they
weren't overly fond of the dep5 format.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Request additions to allowed licenses for Fedora (Multics & GAL).

[Richard Fontana]

On Sat, Jan 13, 2024 at 5:01 PM Jeff Johnson  wrote:
>
> Greetings,
>
> In hopes of eventually packaging DPS8M (https://dps8m.gitlab.io), the 36‑bit 
> GE Large Systems / Honeywell / Bull 600/6000‑series mainframe computer 
> simulator (and the associated Multics operating system files), I'd like to 
> request that some license details be reviewed by the Fedora project.
>
> Of the source code licenses used, only the Multics License is not currently 
> listed as allowed for Fedora.  The Multics License is an OSI approved open 
> source license (and a Blue Oak Council Certified permissive license).  See 
> https://opensource.org/license/multics-txt/ for details.
>
> As an aside, the use of the Multics license in DPS8M might be unique amongst 
> software distributed by Fedora, if DPS8M would eventually be packaged.  The 
> Multics License covers **only** some of the simulator’s source code comments, 
> and is **not** applicable to compiled object code or binary distributions of 
> the simulator, so the compiled packages would be allowed in Fedora, but not 
> the source code, which would be a weird Catch-22 indeed.

To be sure I understand: you're saying that in this particular case,
the Multics license only covers *comments* (in the sense that, other,
non-comment elements of the source code of the simulator are covered
by other [Fedora-allowed] licenses)?

The license itself looks like it would be allowed (it's another
example of a legacy permissive license in the HPND family) but we
don't formally review and approve licenses on this list. You have to
follow the process described here:
https://docs.fedoraproject.org/en-US/legal/license-review-process/

> In addition, I'd like to request that the CF-GAL ([Copyfree] General 
> Attribution License) be allowed as a content and documentation license.  See 
> https://gitlab.com/dps8m/dps8m/-/blob/master/LICENSES/LicenseRef-CF-GAL.txt 
> for the license text.  This license originates from 
> https://copyfree.org/content/standard/licenses/gal/license.txt, and is a 
> variant of the SAL 
> (https://copyfree.org/content/standard/licenses/sal/license.txt) which is not 
> specific to software, and is similar to the already allowed zlib license.  
> This license covers the use of certain logos, artwork, and documentation.

This also looks like it would probably be allowed, but again you have
to follow the documented process for review of new licenses.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Suggested user and developer actions

[Richard Fontana]

On Tue, Jan 9, 2024 at 1:28 PM Neal Gompa  wrote:
>
> On Tue, Jan 9, 2024 at 1:24 PM Benson Muite  
> wrote:
> >
> > Hi,
> >
> > Am reviewing remind, a calendar application:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2246133
> >
> > It has a strong encouragement for users and developers:
> > https://git.skoll.ca/Skollsoft-Public/Remind/src/branch/master/MICROSOFT-AND-APPLE
> >
> > Assume this does not require a license review and classification, but
> > can request this if it is needed.
>
> It does not.

Agreed, there's no licensing issue here.  (I pondered whether the
remarks about Apple raise a Fedora packaging guidelines issue but I
don't think so.)

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: SPDX Statistics - R.U.R. edition

[Richard Fontana]

On Sat, Dec 9, 2023 at 6:48 PM Mark Wielaard  wrote:

> > SPDX is community-driven project. Under Linux Foundation. With all
> > materials open and all decisions done in public.
>
> Even if it is, then it is still problematic to request Fedora
> contributors to file issues in these external third-pary proprietary
> trackers.

I agree that this is problematic though we are already using a
third-party proprietary system (gitlab.com) to host the Fedora License
Data repository, so does the fact that SPDX is hosted on GitHub really
make things materially worse? (Surely the fact that gitlab is open
core shouldn't make much of a difference for use of their hosted
version, though I get the sense that
some people feel this way.) I personally wouldn't be opposed to
hosting Fedora License Data on pagure.io (or finding some other FOSS
solution) but I think some others on the team would. :)

If anyone objects to direct use of GitHub, we can file issues on their
behalf. Same goes for anyone who objects to gitlab.com. I'll make a
note to put this in the Fedora legal documentation.

> Also we never just relied on third parties even if we
> closely worked together with the FSF and OSI,

Fedora never really worked closely with the OSI. It did, at one time,
work closely with the FSF's license compliance lab, during the Brett
Smith era, but that was well over a decade ago.

But this is a concern I had too - when we started this I was worried
about SPDX taking too long to review issues coming from Fedora. This
has actually not turned out to be a significant problem in practice.
The delays in the process have had more to do with things on our side.

> Fedora always reviewed
> more licenses than either of them, and I doubt the SPDX project will
> either.

Over the past year and a half, I believe SPDX has made an
unprecedented expansion of the SPDX license list and this is mostly
due to SPDX accommodating issues from Fedora.

Also, SPDX is a standard that does not lock us in to the SPDX license
list. We can bypass the SPDX license list inclusion process by using
Fedora-defined `LicenseRef-` identifiers, and indeed we have done this
in quite a few cases (including for allowed licenses). The current
policy is to aim for SPDX license list inclusion at least for all
Fedora-allowed FOSS licenses. This is less a benefit for Fedora than
it is for SPDX and the larger community that is likely to make
increasing use of SPDX identifiers. Also, in an extreme scenario (for
example, if the SPDX project dies out or becomes impossible to work
with) we can fork SPDX, or more precisely the limited aspects of SPDX
that are relevant to Fedora.

> I don't mind the SPDX project trying to create a collection of Free
> Software licenses with comment identifier names that can be used to
> refer to them. But some of the other things they seem to promote, like
> these SBOMs, feel like just setup to promote proprietary software
> "based on" Free Software (without a commitment to make sure the user
> will actually get the complete and corresponding source code). I
> cannot say I can get very excited about that.

I don't especially like SBOMs either, and I don't think SBOMs have
any relevance to Fedora, but I don't think this is a good
argument for not using the SPDX license expression standard, which is
really separate from other aspects of the SPDX project.


Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: OpenSSL CRYPTOGAMS / golang-x-crypto license

[Richard Fontana]

On Mon, Dec 4, 2023 at 1:00 PM Daniel P. Berrangé  wrote:
>
> I'm looking at the package (golang-x-crypto) which has a file containing
> this header:
>
>   // Copyright 2019 The Go Authors. All rights reserved.
>   // Use of this source code is governed by a BSD-style
>   // license that can be found in the LICENSE file.
>
>   // Based on CRYPTOGAMS code with the following comment:
>   // # 
>   // # Written by Andy Polyakov  for the OpenSSL
>   // # project. The module is, however, dual licensed under OpenSSL and
>   // # CRYPTOGAMS licenses depending on where you obtain it. For further
>   // # details see http://www.openssl.org/~appro/cryptogams/.
>   // # 
>
>
> The top level LICENSE referenced is BSD-3-Clause. The CRYPTOGAMS licenses
> appear to be a combination of BSD-2-Clause and GPL (no version) which I
> intepret as GPL-2.0 unless someone knows of a compelling reason for it to
> be considered GPL-1.0 in this case.
>
> The golang-x-crypto spec license currently declares BSD-3-Clause as its
> only license. I expect that the rational is that the first paragraph has
> claimed to re-license the original code it was derived from, so it could
> be ignored (or maybe it was simply missed during review).
>
>
> I wouldn't tend to view this as re-licensing though. To me I think that
> the derivation is keeping the original license (OpenSSL + CRYPTOGAMS) for
> existing code, and augmenting the work with new code under a compatible
> license (BSD 3-Clause).
>
> IOW, I'm inclined to think we need to include the origin license too,
> which I would interpret to be
>
>"( OpenSSL OR BSD-2-Clause OR GPL-2.0 )"
>
> and thus the overall license as
>
>"BSD-3-Clause AND ( OpenSSL OR BSD-2-Clause OR GPL-2.0 )"
>
> Thoughts ?

I think the BSD portion of the Cryptograms license is almost a match
to SPDX BSD-3-Clause (ignoring the reference to the GPL) except it has
"nor the names of its copyright holder and contributors" in clause 3
(rather than "nor the names of its contributors"), so an issue should
be submitted to SPDX to revise BSD-3-Clause accordingly. Assuming that
is done, I would treat the license as:

BSD-3-Clause AND (OpenSSL OR BSD-3-Clause OR GPL-2.0-or-later)

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: License of test that tests SPDX ids?

[Richard Fontana]

On Thu, Nov 23, 2023 at 9:27 AM Miroslav Suchý  wrote:
>
> I started packaging Cavil and I stumbled upon this gem
>
> https://github.com/openSUSE/cavil/blob/master/t/legal-bot/error-invalid-xml-kiwi/fffe100e5a9a3e7f6d1fd97512215287/error-invalid-xml-kiwi.kiwi
>
> there are more like this.
>
> It has a SPDX header that say it is MIT license. But it is just test whether 
> Cavil can detect the SPDX header.
>
> The code and project itself is GPL-2.0-only.
>
> What is the license of that file? Is it GPL-2.0-only and we ignore the header 
> because the meaning is just to test code
> and not declare license. Or we cannot ignore it and the license of that file 
> is MIT?

I would assume this file is too trivial to be licensable.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: SPDX Statistics - R.U.R. edition

[Richard Fontana]

On Fri, Nov 24, 2023 at 2:07 PM Mark Wielaard  wrote:
>
> But then for the Hybrid BSD license that parts of bzip and valgrind
> uses it actually has different identifiers depending on the version of
> the package (it actually has both bzip2-1.0.5 and bzip2-1.0.6 which are
> literally exactly the same except for the version string and the
> copyright year).

Ah, now I see that bzip2-1.0.5 is deprecated by SPDX in favor of
bzip2-1.0.6: https://spdx.org/licenses/bzip2-1.0.5.html
If I understand the explanation correctly, anything that is a match
for bzip2-1.0.5 should also be a match for bzip2-1.0.6, so the latter
should be used. (Jilayne probably has direct knowledge of the history
there.)

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: valgrind devel headers license tag (bzip2-1.0.6?)

[Richard Fontana]

On Fri, Nov 24, 2023 at 11:36 AM Mark Wielaard  wrote:
>
> Hi Richard,
>
> On Mon, 2023-11-20 at 09:41 -0500, Richard Fontana wrote:

> > You could propose this change to the SPDX legal team by submitting an
> > issue at https://github.com/spdx/license-list-XML but historically
> > they've been very resistant to identifier deprecations (with the
> > notable exception of the GPL identifiers :)
>
> Hohum, github. That does seems to use a lot of proprietary javascript
> and doesn't allow reporting issues without a github account, which I
> don't have and don't really want. Too bad that seems to be the way to
> discuss with the SPDX legal team :{

They also have a mailing list but from what I understand it uses
groups.io, a non-FOSS web service. You could also ask Jilayne Lovejoy
to consider it, she's one of the SPDX-legal leads and also reads this
list.

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: valgrind devel headers license tag (bzip2-1.0.6?)

[Richard Fontana]

On Mon, Nov 20, 2023 at 6:26 AM Mark Wielaard  wrote:
>
> Hi Richard,
>
> On Fri, 2023-11-17 at 13:52 -0500, Richard Fontana wrote:
> > This seems indeed to match bzip2-1.06 -- Jilayne, I assume the full
> > text of what is wrapped in the  tag could be ignored
> > for purposes of matching? i.e.
> > https://github.com/spdx/license-list-XML/blob/main/src/bzip2-1.0.6.xml#L10-L13
> >
> > The SPDX Matching Guidelines say: "To avoid a license mismatch merely
> > because the copyright notice (usually found above the actual license
> > or exception text) is different. The copyright notice is important
> > information to be recorded elsewhere in the SPDX document, but for the
> > purposes of matching a license to the SPDX License List, it should be
> > ignored because it is not part of the substantive license text."
> >
> > but this does not define what a "copyright notice" is.  If we don't
> > hear from Jilayne, I'd go ahead with assuming that this is a perfect
> > match. :)
>
> OK, but can we use a more appropriate tag. bzip2-1.0.6 seems a little
> odd (it is a version of bzip2 with a CVE[*] from a couple of years
> back). Maybe just call it 'bzip2' or 'Hybrid-BSD' as Fedora used to
> call it (although it seems to still use the plain 'BSD' tag for it)
> since it seems to be a generic license used by different projects:
> https://fedoraproject.org/wiki/Licensing:BSD#Hybrid_BSD_(half_BSD,_half_zlib)

We're trying to standardize on using SPDX License List
(https://spdx.org/licenses/) license identifiers as much as possible.
I think we'd only deviate from that where use of the SPDX identifier
would be highly misleading or confusing. There's sort of an example of
this: 
https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/data/LicenseRef-Bacula.toml?ref_type=heads
but that's where there would otherwise be a composite SPDX expression.

You could propose this change to the SPDX legal team by submitting an
issue at https://github.com/spdx/license-list-XML but historically
they've been very resistant to identifier deprecations (with the
notable exception of the GPL identifiers :)

Richard
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: valgrind devel headers license tag (bzip2-1.0.6?)

[Richard Fontana]

On Fri, Nov 17, 2023 at 1:18 PM Mark Wielaard  wrote:
>
> Hi,
>
> valgrind as a whole is licensed under the GPLv2+, but has a couple of
> development headers, all separately packaged in the valgrind-devel
> subpackage) with a lax-permissive license. Since they are meant to
> embed valgrind specific (code) annotations into other
> programs/libraries they carry an explicit exception from the GPL.
>
> There are 7 such files, all exactly the same, except for the embedded
> file name, "This file is part of..." description and Copyright notice.
> See below for the exact text and variants.
>
> It would be nice to give this binary subpackage its own License tag.
>
> But I have some trouble figuring out which (SPDX) tag to use.
>
> The closest seems to be what SPDX calls "bzip2-1.0.6" (which kind of
> makes sense since Julian Seward started both the bzip2 and valgrind
> projects). https://spdx.org/licenses/bzip2-1.0.6.html
>
> I could use that identifier. But it seems to be an oddly specific
> identifier, for an older version of bzip2. And the Fedora bzip2 package
> just uses BSD-4-Clause. I could also use BSD-4-Clause since that is
> more generic. But the text of what SPDX calls BSD-4-Clause doesn't
> really match (so maybe the Fedora bzip2 package got that wrong?)

Sounds like it, but I'll try to look into that later.

> What would be to best license tag to use here?
>
> They all look as follows:
>
> /* -*- c -*-
>
>
>Notice that the following BSD-style license applies to this one
>file (valgrind.h) only.  The rest of Valgrind is licensed under the
>terms of the GNU General Public License, version 2, unless
>otherwise indicated.  See the COPYING file in the source
>distribution for details.
>
>
>
>This file is part of Valgrind, a dynamic binary instrumentation
>framework.
>
>Copyright (C) 2000-2017 Julian Seward.  All rights reserved.
>
>Redistribution and use in source and binary forms, with or without
>modification, are permitted provided that the following conditions
>are met:
>
>1. Redistributions of source code must retain the above copyright
>   notice, this list of conditions and the following disclaimer.
>
>2. The origin of this software must not be misrepresented; you must
>   not claim that you wrote the original software.  If you use this
>   software in a product, an acknowledgment in the product
>   documentation would be appreciated but is not required.
>
>3. Altered source versions must be plainly marked as such, and must
>   not be misrepresented as being the original software.
>
>4. The name of the author may not be used to endorse or promote
>   products derived from this software without specific prior written
>   permission.
>
>THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
>OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
>WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
>ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
>DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
>DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
>GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
>INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
>WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
>NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
>

This seems indeed to match bzip2-1.06 -- Jilayne, I assume the full
text of what is wrapped in the  tag could be ignored
for purposes of matching? i.e.
https://github.com/spdx/license-list-XML/blob/main/src/bzip2-1.0.6.xml#L10-L13

The SPDX Matching Guidelines say: "To avoid a license mismatch merely
because the copyright notice (usually found above the actual license
or exception text) is different. The copyright notice is important
information to be recorded elsewhere in the SPDX document, but for the
purposes of matching a license to the SPDX License List, it should be
ignored because it is not part of the substantive license text."

but this does not define what a "copyright notice" is.  If we don't
hear from Jilayne, I'd go ahead with assuming that this is a perfect
match. :)

- Richard




>
>Notice that the above BSD-style license applies to this one file
>(valgrind.h) only.  The entire rest of Valgrind is licensed under
>the terms of the GNU General Public License, version 2.  See the
>COPYING file in the source distribution for details.
>
>
> */
>
> They only differ in "this one file
> ([valgrind|cachegrind|callgrind|drd|helgrind|memcheck|dhat

[Fedora-legal-list] Re: License of SPDX license list data itself

[Richard Fontana]

On Mon, Nov 13, 2023 at 3:54 PM Fabio Valentini 
wrote:

> Hi all,
>
> I'm currently working on packaging cargo-deny, and it includes (a very
> old version) of a compressed form of the SPDX license data from
> https://github.com/spdx/license-list-data.
>
> The package needs the SPDX license-list-data in a format that can be
> read by "askalono", and it is used to match unknown license files with
> licenses known to SPDX. I was able to include a new version of that
> data by rebuilding that compressed blob from the SPDX
> license-list-data on GitHub.
>
> However, I could not determine under which license terms this data is
> made available. The repository for spdx/license-list-data only states
> that all contents are automatically generated from
> https://github.com/spdx/license-list-XML, which itself specifies no
> license for the data, either.
>
> I assume this data is redistributable *somehow*? The documentation
> explains how to *use* the data for various purposes, but not which
> license (if any) applies to it.
>
> Note that the existing askalono-cli package also bundles this data,
> which seems to have been missed during the original package review. I
> will apply any necessary changes both to cargo-deny (which is still
> being reviewed) and askalono-cli.
>

I *think* SPDX's position is that anything copyrightable (created by the
SPDX project) that's in https://github.com/spdx/license-list-XML is under
CC0 (er, CC0-1.0).
See: https://github.com/spdx/license-list-XML/issues/1044
https://github.com/spdx/license-list-XML/issues/986
But Jilayne would have the authoritative answer :)

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: CC0 license of dlmalloc in sgx-sdk package review

[Richard Fontana]

On Thu, Nov 2, 2023 at 12:29 PM Daniel P. Berrangé  wrote:

> To close the loop on this, after a little more email discussion with
> Doug Lee, he graciously agreed to replace the CC0 license with MIT-0
> as seen here, so there should no longer be any license problem for
> projects bundling dlmalloc in Fedora:
>
>   https://gee.cs.oswego.edu/pub/misc/malloc.c
>
> [quote]
> * Version 2.8.6 Wed Aug 29 06:57:58 2012  Doug Lea
>   Re-licensed 25 Sep 2023 with MIT-0 replacing obsolete CC0
>   See https://opensource.org/license/mit-0/
> [/quote]

Great! Thanks for pursuing this.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Effective license analysis: required or not?

[Richard Fontana]

On Mon, Oct 30, 2023 at 8:45 AM Vít Ondruch  wrote:
>
> The worst thing is that it appears to me, that often only we care about
> such subtleties.

Welcome to my life. :)

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Effective license analysis: required or not?

[Richard Fontana]

On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer  wrote:

> Below, I'm collecting a list of observations of what I believe is the
> current approach in this area, as taken by package maintainers carrying
> out the SPDX conversion.  To me, it strongly suggest that the SPDX
> identifiers we derive today do not accurately reflect binary RPM package
> licensing, even when lots of package maintainers put in the extra effort
> to determine binary package licenses.

I recently noticed something that could be added to this list. There's
a package that generates a '-docs' subpackage using Doxygen.
Apparently Doxygen injects various pieces of minified JavaScript
(mostly from the jQuery ecosystem, mostly MIT-licensed) in a way that
is not obvious from analyzing the source code of the package that uses
Doxygen. I assume this must be compliant with Fedora packaging
guidelines -- although I could not verify this from reading Fedora
guidelines on bundling and JavaScript.

Anyway, I would guess no Fedora package maintainer of a package that
has a Doxygen docs subpackage is taking this issue into account when
thinking about License: tags. Should they? I am having trouble seeing
why the licensing of the Doxygen pieces should be deliberately
ignored. But I also am not sure if a Fedora package maintainer should
realistically be expected to know that this situation occurs. I was
moving toward the view that if the package build process results in
the inclusion of some licensed material from another package, this can
be ignored if (a) the inclusion occurs in huge numbers of Fedora
packages and (b) most normal Fedora installs will have the other
package. I was thinking that would take care of Florian's gcc and
glibc statically-linked startup code examples, but surely neither (a)
nor (b) apply to the Doxygen case which seems sort of analogous.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: license of empty file

[Richard Fontana]

On Sun, Oct 22, 2023 at 2:00 AM Miroslav Suchý  wrote:
>
> Webkitgtk has interresting file:
>
>Documentation/jsc-glib-4.1/fonts.css
>
> The file has this content:
>
> /*
> * SPDX-FileCopyrightText: 2021 GNOME Foundation
> *
> * SPDX-License-Identifier: Apache-2.0 OR GPL-3.0-or-later
> */
>
> And that is all. No other content is there. So it is literaly an empty file 
> with license declaration.
>
> Should this license be honored and put in License tag of spec file? Or is it 
> copyright of not-copyrightable file and
> should be ignored?

As a general rule, empty files should be ignored. It should certainly
not be accounted for in the License tag.

There are some cases where something like this could be a clue to how
*another* file is licensed but I think that is unlikely here because
this looks like it is the result of an attempt to make a repository
REUSE-conformant.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: License for perl-Math-Random-ISAAC

[Richard Fontana]

On Fri, Oct 20, 2023 at 4:37 PM Emmanuel Seyman  wrote:
>
>
> Hello, all.
>
> I was updating the spec file of perl-Math-Random-ISAAC and wanted to
> migrate the License field to the SPDX format.
>
> The license field says "MIT or GPL+ or Artistic" but the upstream
> package README says:
>
> " Legally speaking, this package and its contents are:
>
> Copyright (c) 2011 by Jonathan Yu .
>
>   But this is really just a legal technicality that allows the author to
>   offer this package under the public domain and also a variety of licensing
>   options. For all intents and purposes, this is public domain software,
>   which means you can do whatever you want with it.
>
>   The software is provided "AS IS", without warranty of any kind, [...]"
>
> Can anyone tell me how I express this in SPDX terms?

The full upstream license file:
https://metacpan.org/release/JAWNSY/Math-Random-ISAAC-1.004/source/LICENSE

The issue is not so much how to express it in SPDX terms, but how to
express it in accordance with our (evolving) Fedora conventions which
use SPDX license expressions.

I would suggest: (1) open an issue in fedora-license-data to add some
portion of this text to the `public-domain-text.txt` file, and then
(2) in the License tag, use one of the following:

option 1:
LicenseRef-Fedora-Public-Domain OR Artistic-1.0-Perl+ OR GPL-1.0-or-later
[this would require also opening an issue in fedora-license-data to
add `GPL-1.0-or-later OR Artistic-1.0-Perl+` as an allowed license
similar to the special cases of `GPL-1.0-or-later OR
Artistic-1.0-Perl` and `GPL-2.0-or-later OR Artistic-1.0-Perl`]

option 2:
LicenseRef-Fedora-Public-Domain OR Artistic-2.0 OR GPL-1.0-or-later

There are a few interesting issues here that I'm not getting into,
including whether `Artistic-1.0-Perl+` encompasses `Artistic-2.0`
(surely `Artistic-1.0+` would not since Artistic-1.0 is as far as
anyone has been able to ascertain a variant of the "real" Artistic
License 1.0 that was never authorized by Larry Wall or the Perl
Foundation).

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: License of sip

[Richard Fontana]

On Thu, Oct 19, 2023 at 6:03 AM Miroslav Suchý  wrote:
>
> Dne 19. 10. 23 v 11:18 Sandro Mani napsal(a):
>
> Hi
>
> Updating mingw-sip I've re-verified the license to convert it to SPDX, and 
> came across the SIP license which does not exist as a SPDX identifier. [1] 
> states
>
> """
>
> SIP is available under the following licenses.
>
> SIP License. This is very similar to the Python Software Foundation license 
> used for Python itself.
> GNU General Public License v2
> GNU General Public License v3
>
> """
>
> I take this should be
>
> License: SIP OR GPL-v2.0-only OR GPL-v3.0-only
>
> (provided SIP existed as a SPDX identifier)?
>
> The full SIP License text is attached.
>
> See:
>
> https://gitlab.com/fedora/legal/fedora-license-data/-/issues/377
>
> https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/421

The License: tag in this case should be `GPL-2.0-only OR GPL-3.0-only`
because we normally don't include not-allowed licenses in
OR-expressions having allowed operands (the big exception being Perl
packages which are allowed to use `GPL-1.0-or-later OR
Artistic-1.0-Perl` and `GPL-2.0-or-later OR Artistic-1.0-Perl).

I'm working on a big revision to the documentation on license tags and
am using the sip package as an example.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: License of rpm-local-generator-support

[Richard Fontana]

On Tue, Oct 17, 2023 at 4:55 AM Vít Ondruch  wrote:
>
> Thank you for elaborating. But unfortunately, the only thing this
> definitely answers is that I can "ignore" the license file for the
> moment. But how to proceed?
>
> One thing to note about the package is that in ideal world, it would not
> exist, because either 1) the file would be included and shipped by RPM
> or even better 2) the file would not be needed, because there are other
> ways to implement this functionality in RPM [1]. I want to submit this
> to upstream, but upstream is not responsible to this issue :/ So would
> it make things simple, if the package have the same license as RPM, i.e.
> `GPLv2+`.

Because it would make it more likely that the RPM maintainers will
ship this empty file? I don't know. My only thought is that it is not
good to give the impression that a license like GPLv2+ or the MIT
license can apply to an empty file. But I guess it's not the worst
thing in the world.

Richard




>
> Don't forget that part of my question was if the content is
> copyrightable and with the context above, if it was shipped directly by
> RPM, the answer would probably be yes.
>
>
> Vít
>
>
> [1]
> https://github.com/rpm-software-management/rpm/issues/782#issuecomment-1748317568
>
>
>
> Dne 16. 10. 23 v 17:53 Richard Fontana napsal(a):
> > On Mon, Oct 16, 2023 at 11:01 AM Vít Ondruch  wrote:
> >> Hi,
> >>
> >> I have submitted rpm-local-generator-support package for a review [1]. It 
> >> can't be simpler:
> >>
> >> https://fedorapeople.org/cgit/vondruch/public_git/rpm-local-generator-support.git/plain/rpm-local-generator-support.spec?id=469fcda122c5856dc10bae4cb75daee0cdf61d15
> >>
> >> It essentially just creates empty file and places it into directory 
> >> structure. I have used `License: MIT` tag, because what else.
> > This reminds me of some packages that used "Public domain" under the
> > Callaway system in the less typical sense of "true" public domain. For
> > one example, see:
> > https://gitlab.com/fedora/legal/fedora-license-data/-/issues/347 where
> > I suggest the use of `LicenseRef-Not-Copyrightable`. This is not
> > currently in the fedora-license-data set of licenses, but it is used
> > in fedora-license-data itself as part of its attempt to conform the
> > repository to the REUSE specification. where REUSE would generally
> > recommend the use of CC0-1.0.
> >
> > I have been assuming that License tags cannot be empty under Fedora
> > packaging rules (the legal docs are silent on this currently) or that
> > non-empty License tags are enforced by certain tools.
> >
> > For policy reasons, I wouldn't recommend using the MIT license (or
> > CC0) but I wouldn't be surprised to learn there are similar packages
> > that use MIT,  GPLv2, etc.
> >
> > Whether a package that says it's under "MIT" has to or should ship the
> > license file is a mostly separate question. Under the Callaway system
> > there was an expectation that Fedora should "correct" the omission of
> > license files by upstream projects. The current Fedora legal
> > documentation deliberately avoids the whole topic of license files
> > because last year we wanted to move ahead with the new guidelines
> > around SPDX identifiers and so forth without waiting to figure out how
> > to deal with license files, and we still haven't figured that out.
> >
> > The default Fedora license for spec files is the MIT license by virtue
> > of the FPCA (which Fedora should get rid of). Even if the spec file in
> > this case is covered by the MIT license it would not mean the package
> > itself is covered by the MIT license. The FPCA wouldn't even reach the
> > case of a package like this one if you accept the position that the
> > contents of the package are not copyrightable.
> >
> > Richard
> >
> >
> >> But the package review correctly pointed out that I should also ship the 
> >> license file, which would substantially complicate everything. And now I 
> >> wonder, is there even anything what would be licensable? Is the empty file 
> >> created somewhere in the directory structure worth of anything? Can the 
> >> License tag be omitted and would the file be covered by the default Fedora 
> >> license for .spec files?
> >>
> >>
> >> Vít
> >>
> ___
> legal mailing list -- legal@lists.fedoraproject.org
> To unsubscribe send an 

[Fedora-legal-list] Re: License of rpm-local-generator-support

[Richard Fontana]

On Mon, Oct 16, 2023 at 11:01 AM Vít Ondruch  wrote:
>
> Hi,
>
> I have submitted rpm-local-generator-support package for a review [1]. It 
> can't be simpler:
>
> https://fedorapeople.org/cgit/vondruch/public_git/rpm-local-generator-support.git/plain/rpm-local-generator-support.spec?id=469fcda122c5856dc10bae4cb75daee0cdf61d15
>
> It essentially just creates empty file and places it into directory 
> structure. I have used `License: MIT` tag, because what else.

This reminds me of some packages that used "Public domain" under the
Callaway system in the less typical sense of "true" public domain. For
one example, see:
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/347 where
I suggest the use of `LicenseRef-Not-Copyrightable`. This is not
currently in the fedora-license-data set of licenses, but it is used
in fedora-license-data itself as part of its attempt to conform the
repository to the REUSE specification. where REUSE would generally
recommend the use of CC0-1.0.

I have been assuming that License tags cannot be empty under Fedora
packaging rules (the legal docs are silent on this currently) or that
non-empty License tags are enforced by certain tools.

For policy reasons, I wouldn't recommend using the MIT license (or
CC0) but I wouldn't be surprised to learn there are similar packages
that use MIT,  GPLv2, etc.

Whether a package that says it's under "MIT" has to or should ship the
license file is a mostly separate question. Under the Callaway system
there was an expectation that Fedora should "correct" the omission of
license files by upstream projects. The current Fedora legal
documentation deliberately avoids the whole topic of license files
because last year we wanted to move ahead with the new guidelines
around SPDX identifiers and so forth without waiting to figure out how
to deal with license files, and we still haven't figured that out.

The default Fedora license for spec files is the MIT license by virtue
of the FPCA (which Fedora should get rid of). Even if the spec file in
this case is covered by the MIT license it would not mean the package
itself is covered by the MIT license. The FPCA wouldn't even reach the
case of a package like this one if you accept the position that the
contents of the package are not copyrightable.

Richard


>
> But the package review correctly pointed out that I should also ship the 
> license file, which would substantially complicate everything. And now I 
> wonder, is there even anything what would be licensable? Is the empty file 
> created somewhere in the directory structure worth of anything? Can the 
> License tag be omitted and would the file be covered by the default Fedora 
> license for .spec files?
>
>
> Vít
>
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: python-dateutil SPDX license -- some code is Apache-2.0 and all code is BSD-3-Clause

[Richard Fontana]

On Mon, Oct 16, 2023 at 10:41 AM Petr Pisar  wrote:
>
> V Mon, Oct 16, 2023 at 03:20:30PM +0200, Miro Hrončok napsal(a):
> > https://github.com/dateutil/dateutil/blob/2.8.2/LICENSE
> >
> > tl;dr:
> >
> > > ...snip Apache-2.0...
> > >
> > > The above license applies to all contributions after 2017-12-01, as well 
> > > as
> > > all contributions that have been re-licensed (see AUTHORS file for the 
> > > list of
> > > contributors who have re-licensed their code).
> > >
> > > ...snip BSD-3-Clause...
> > >
> > > The above BSD License Applies to all code, even that also covered by 
> > > Apache 2.0.
> >
> > In other words. There is a subset of the code which is covered by Apache-2.0
> > and *at the same time* all of the code is covered by BSD-3-Clause.
> >
> > Is that an OR case?
> >
> In my humble understanding it is: (Apache-2.0 OR BSD-3-Clause) AND 
> BSD-3-Clause.

Agreed.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Richard Fontana]

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 directory src/miniloader are provided pursuant to the
> following license agreement:
>
> License For Customer Use of NVIDIA Software
>

>
> What can I use for SPDX?

The license first has to be reviewed; this will ultimately result in a
license identifier that can be used in place of "Redistributable, no
modification permitted" assuming the license is allowed or otherwise
tolerated. Please open a new issue in fedora-license-data.

I think this would be the first firmware license we would specifically
consider since instituting the new license review process last year.
The policy on allowed firmware licenses is described here:
https://docs.fedoraproject.org/en-US/legal/license-approval/#_license_requirements_for_firmware
These criteria were based on an analysis of known firmware licenses in
Fedora done sometime around ... maybe 2010 or so? To accommodate this
license we might have to make some additions to those criteria.

We haven't yet had to address the question of how to deal with license
identifiers for firmware. There are three possibilities:
1. Ask SPDX to assign an identifier, the usual approach for allowed
licenses. This is unlikely to be viable because these kinds of
firmware licenses are pretty far from SPDX's license inclusion
criteria (which are generally much looser than Fedora's).
2. Create a unique LicenseRef- identifier for each firmware license.
3. Create an umbrella LicenseRef- identifier for all allowed Fedora
firmware licenses (similar to how 'Redistributable, no modification
permitted' was used in the Callaway system).

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Need help with x2godrive licensing.

[Richard Fontana]

On Thu, Sep 28, 2023 at 9:45 PM Orion Poplawski  wrote:
>
> I'm trying to package x2gokdrive for Fedora (review [1]), but running
> into some questions/issues with the licensing:
>
> 1 - There is no license file in the released tarball
>
> 2 - The debian/copyright file in the git repo [2] states that the
> license is GPL-2+ except for testscripts/* at GPL-2.  However,
> licensecheck reports:
>
> ./x2gokdrive.c: Historical Permission Notice and Disclaimer - sell variant
> ./x2gokdrive.h: GNU General Public License v3.0 or later
> ./x2gokdrivecursor.c: GNU General Public License v3.0 or later
> ./x2gokdriveinit.c: GNU General Public License v3.0 or later
> ./x2gokdrivelog.h: Historical Permission Notice and Disclaimer - sell
> variant
> ./x2gokdriveremote.c: GNU General Public License v3.0 or later
> ./x2gokdriveremote.h: GNU General Public License v3.0 or later
> ./x2gokdriveselection.c: GNU General Public License v3.0 or later
> ./x2gokdriveselection.h: GNU General Public License v3.0 or later
>
> 3 - This code is combined with the Xorg server code which is under the
> MIT license.
>
>
> This is quite a mess.  I've asked upstream here [3] for some
> clarification, but I was hoping that the Fedora folks could speak to
> some of this, particularly item #3.

The licensecheck results look accurate as far as detection of license
notices goes. If I had to guess, the included debian/copyright file is
based on an older version where the x2gokdrive* files used
GPLv2-or-later and the project never bothered to update it when they
updated the license to GPLv3-or-later (so too with the bundled spec
file).  For whatever reason, the testscripts indicate GPLv2-only.

I would probably assume for simplicity that the Xorg patches are under
whatever version(s) of the GPL apply to the project generally, except
that's not clear here. But in general your best bet is to try to get
the project to explain what's going on, and maybe also persuade them
to add one or more license files.

Richard


>
> [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2215421
> [2] -
> https://code.x2go.org/gitweb?p=x2gokdrive.git;a=blob_plain;f=debian/copyright;h=88c3411550b8f79d29f1b9a7a3c20996126375db;hb=HEAD
> [3] - https://lists.x2go.org/pipermail/x2go-dev/2023-September/014093.html
>
> Orion
>
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Updates of licenses

[Richard Fontana]

On Wed, Sep 27, 2023 at 1:35 PM Daniel P. Berrangé  wrote:
>
> On Wed, Sep 27, 2023 at 08:29:05PM +0300, Benson Muite wrote:
> > Would be helpful to add HPND-export-US-modify to allowed licenses:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2238438
> > https://github.com/spdx/license-list-XML/pull/2170
>
> This is already tracked for adding to Fedora at
>
>   https://gitlab.com/fedora/legal/fedora-license-data/-/issues/343
>
>
> since the SPDX change is now merged, adding to Fedora is unblocked

I have updated the Fedora issue.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Does the FPCA automatically relicense older unlicensed contributions if a Later Default License is added?

[Richard Fontana]

On Tue, Sep 26, 2023 at 2:05 PM Aaron Rainbolt  wrote:
>
> (I already signed the FPCA, as I'm fine even if the answer to my
> question is "yes", but I would like to make sure I understand how this
> works.)
>
> "Once a Later Default License has been designated, Your Unlicensed
> Contribution shall also be licensed to the Fedora Community under that
> Later Default License." I believe that means that if I make an
> Unlicensed Contribution to Fedora, and later a new license is designated
> as a Later Default License, that Unlicensed Contribution is now licensed
> under both the Current Default License and the Later Default License,
> despite having been made prior to the Later Default License being added.
> Is this the case?

Yes, that was the intention.

 Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: SPDX Statistics - R.U.R. edition

[Richard Fontana]

On Sun, Sep 17, 2023 at 11:37 AM Mark Wielaard  wrote:
>
> To be clear I don't mind using a different set of short-hands in the
> License tags. Although it feels a little odd to try to create separate
> identifiers for lax-permissive MIT/BSD like licenses which sometimes
> just different in one or two words.

FWIW, usually a difference of one or two words wouldn't be enough to
result in creation of a distinct SPDX identifier. The standard applied
by SPDX is, informally, whether the difference is "legally
substantive" (this has its flaws but seems to work OK in practice).

I think anyone should be free to propose a new umbrella identifier (in
SPDX expression format) that would cover multiple licenses, as we've
done with `LicenseRef-Fedora-Public-Domain` and
`LicenseRef-Fedora-UltraPermissive`. The important thing is that it be
well defined in some way.

> However I really don't understand the purpose or goal of this idea of
> creating a large expression of all the license/permission notices that
> might be found in the sources that possibly make up the binary to the
> License tag. Because in my experience those are often not relevant or
> accurate at all.

The more important objective is to have package reviewers periodically
review packages to ensure that all licenses are 'allowed' by Fedora,
or covered by some documented exception. This activity should then
make it possible to create a license tag reflecting the licenses found
(to the extent they are relevant to the Fedora context beyond merely
existing in the source code). "Relevant" includes any situation where
a license covers something in an installable package. I think we may
disagree on the "covers" part.

This is not really a new requirement. The idea that the license tag
should reflect the various licenses that apply to a binary is
something that has been in place for ~15 years, though it may have
been documented in an inconsistent or contradictory way. I think the
use of umbrella identifiers in the Callaway system somewhat obscured
the fact that this was the expected approach.

> > > What is the goal of dropping the effective license and make packagers
> > > list all the licences of some code snippets originally incorporated
> > > under lax-permissive licenses? Is that not just make work for the
> > > packager if upsteam just uses one effective license?
> >
> > One rationale is given in Fedora legal documentation:
> > "There is no agreed-upon set of criteria or rules under which one can
> > make conclusions about “effective” licenses or reduce composite
> > license expressions to something simpler."
>
> Isn't that not just like most other things fedora, we follow
> upstream. Upstream states the (effective) license and we just adopt
> that. If we notice that there might be a bug and the effective license
> isn't exactly as the upstream project states, then we fix that
> upstream?

I basically don't recognize "effective license" as a valid concept. I
see people using it, perhaps increasingly, but I never see any
definition of what it means.
It sounds like you are using it to mean "whatever the upstream project
seems to say the license is, despite possible evidence to the
contrary".  I'm not sure that's how other people are using "effective
license".

I think Jilayne would disagree with this, but in practice, I also
don't see what we could fix upstream, since there is no standard for
how you communicate or document what the effective license is
(regardless of what it means). The only related standard I know of for
documenting licensing of projects is REUSE (https://reuse.software)
which I think implicitly also rejects the concept of "effective
licensing".

> > Basically, everyone has been making up their own interpretive system
> > for deciding what an "effective license" is, with no consistencies
> > across upstream packages and Fedora package maintainers.
>
> Is this really a problem? Could you show an example where an upstream
> or package maintainer stated in the license tag that the effective
> license was say "GPLv3+", but it would have been more "correct" to state
> that it was "GPL-3.0-or-later AND GPL-3.0-or-later WITH
> Autoconf-exception-generic-3.0 AND GPL-3.0-or-later WITH
> Bison-exception-2.2 AND GPL-2.0-or-later AND GPL-2.0-or-later WITH
> Autoconf-exception-generic AND LGPL-2.1-or-later AND LGPL-2.0-or-later
> AND X11"?

I will not argue this, but I will make two observations. One is
something I've said before, which is that people seem to be
complaining about the current standards for license tags only when
they are lengthy. I think it would be more consistent to argue that we
don't need license tags at all. I have no attachment to RPM-style
license tags, though Red Hat finds them marginally useful for some
purposes.

The other thing is that the discipline that produces license tags at
this level of detail is what is needed to uncover licensing problems
in packages, from Fedora's perspective as a distribution that aims to
be made u

[Fedora-legal-list] Re: SPDX license when no GPL version is listed in source ?

[Richard Fontana]

On Mon, Sep 18, 2023 at 2:16 PM Daniel P. Berrangé  wrote:
>
> Auditing the augeas project source file licenses I found a handful of
> files where the license was not specified sufficiently clearly. I've
> raised this upstream:
[ . . . ]
> For the files which merely say:
>
> This file is licensed under the GPL.
>
> I'm not sure what the best practice is ? Can I justify "GPL-1.0-or-later"
> in the Fedora spec on the basis that the non-version specific declaration
> in the source could legitimately cover any GPL version ?

That seems to be the approach that the Linux kernel has generally
taken in their conversion of source file license notices to
SPDX-License-Identifier: strings. Obviously it's defensible on GPL
interpretation grounds. I personally don't like it, among other
reasons because I think in probably most of these cases the author
must not have meant to encompass GPLv1 in the license grant, since
GPLv1 became rapidly obsolete after the introduction of GPLv2 (unlike
the situation with the introduction of GPLv3). This is pretty
obvioiusly the case for the kernel, which did not adopt the GPL until
(shortly) after the introduction of GPLv2 and which AFAIK always had a
copy of GPLv2, but not GPLv1, in the source code. There might be some
rare exceptions for GPL code copied into the kernel that originated
with pre-Linux projects.

I also think it's a flaw in SPDX, or the application of SPDX
identifiers anyway, that "any version of the GPL" is equated with "GPL
version 1 or later", which I think subtly communicates somethint
different,  but I don't think I would succeed in convincing anyone of
this.

Richard


Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: msv (xsdlib) licensing review

[Richard Fontana]

On Wed, Aug 9, 2023 at 7:35 AM Marián Konček  wrote:
>
> Yes, I would like to package only that part.
>
> Does license review need to be done before or after submitting a package
> review in Bugzilla?

I don't think we (Fedora Legal people) care about that in general
(unless there's some specific reason to think that a package wouldn't
be allowed in Fedora for some non-license-related reason).

> Regarding opening issues on fedora / spdx:
> * one part is about adding / not adding Oracle / Sun's variant of
> BSD-3-Clause
> * the other is about accepting differently formatted Apache-1.1?
>
> Does formatting matter to SPDX?

I have lost track of this but I think the issue was not formatting but
some of the language of the Apache Software License 1.1 variant did
not match the SPDX identifier. In general, formatting is irrelevant.

Richard



>
> On 8. 8. 2023 20:24, Richard Fontana wrote:
> > On Tue, Aug 8, 2023 at 9:00 AM Marián Konček  wrote:
> >> As part of the jaxb 4.0.2 -> 4.0.3 update, part of this package is
> >> needed for its code generation. Therefore, I would like to package it in
> >> Fedora. This package has complex licensing which is why I am asking for
> >> a review. Note that I only need the "xsdlib" subdirectory.
> >>
> >> I only need a stripped-down version of this package as if by
> >> downloading:
> >> https://github.com/xmlark/msv/archive/refs/tags/msv-2022.7.tar.gz
> >>
> >> and running (inside the msv-msv-2022.7 directory):
> >>
> >> find . -mindepth 1 -maxdepth 1 -type d ! -name 'xsdlib' -exec rm -rf {} +
> >> rm -rf xsdlib/src/main/resources
> >> rm -rf xsdlib/src/test
> >> grep -l -r --ignore-case 'proprietary' | xargs rm -v
> >>
> >> Most problematic license files are: copyright.txt and license.txt in
> >> https://github.com/xmlark/msv/tree/main/docs/xsdlib. To my knowledge,
> >> all files that remained use explicit BSD-3-Clause or Apache-1.1.
> >> Question is whether we could have removed the copyright.txt and
> >> license.txt files in the first place.
> >>
> >> Current upstream: https://github.com/xmlark/msv
> >> Previous package in Fedora (used different source repository):
> >> https://koji.fedoraproject.org/koji/packageinfo?packageID=2576
> >> Previous bug related to licensing:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=87684
> >>
> >> Also grep --ignore-case for "proprietary" "confidential", "nuclear".
> > Can you create  a package just from that subset of the xsdlib
> > directory as you indicated above?
> >
> > In those files, what I saw on a quick review was:
> >
> > - pom.xml : there's a Sun BSD license that is probably OK for Fedora
> > but does not seem to match any known variant. (It's tempting to just
> > ignore this but since it's probably OK we might as well add it.)
> >
> > - Oracle 3-clause BSD licenses: most of these seem to be BSD-3-Clause,
> > but there was one for which SPDX would need to revise the markup, I
> > think ( xsdlib/src/main/java/com/sun/msv/datatype/regexp/InternalImpl.java)
> >
> > - The Apache 1.1 license appearing on a number of source files does
> > not quite match SPDX Apache-1.1, would require SPDX revision to the
> > Apache-1.1 markup
> >
> > So these seem fairly nonproblematic but it would be helpful if you
> > could create issues for these in fedora-license-data and then at
> > github.com/spdx/license-list-XML.
> >
> > But if you need to package any of the other stuff in this repository
> > that may complicate things further.
> >
> > Richard
> >
> --
> Marián Konček
> ___
> legal mailing list -- legal@lists.fedoraproject.org
> To unsubscribe send an email to legal-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Simplification of package license expressions involving dual licenses

[Richard Fontana]

Fedora legal docs currently say:

"If your package is built from files under multiple distinct licenses,
and some files are licensed under a choice of two (or more) licenses,
then the License: field must include the appropriate OR and AND
expressions The license expression must reflect the disjunctive
license choice even if one or both of the license identifiers in the
OR expression also appear separately in the composite license
expression."

I am coming around to the view that we can revise the last sentence
there: For an SPDX expression involving licenses foo and bar,

foo AND bar AND (foo OR bar)

can acceptably be "reduced" to

foo AND bar

since both elements of the OR-expression are separately atomic
elements of the larger AND expression.

In insisting on preservation of all dual licenses (involving
Fedora-allowed licenses that is), we were following what I understood
to be the Callaway tradition. However, this is not entirely clear; see
for example: 
https://web.archive.org/web/20190801152043/https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#Combined_Dual_and_Multiple_Licensing_Scenario
As far as I can tell, the scenario we're talking about wasn't
explicitly addressed in the old guidelines.

The other part of this is that insisting on preservation of dual
licenses was making an important cultural or political point. To
understand this, you need to understand that some companies consuming
open source have a silly practice of taking steps to explicitly select
one of the licenses. As you might expect this usually happens when one
of the licenses is in the *GPL family. A related phenomenon involves
taking GPLv2-or-later code "as" GPLv2-only. Apart from being sort of
ridiculous, this practice conflicts with the usual practice in
upstream open source of passing through all disjunctive licenses. So
by *not* doing this, Fedora was expressing a sort of solidarity with
normal open source development and distancing itself from the
practices of those companies.

Since in the (foo AND bar AND (foo OR bar)) -> (foo AND bar) case the
simplified expression has all of the elements that were in the dual
license, I think the simplification is still in the spirit of the old
rule. We would not be removing any of the license symbols on either
side of the dual license; we are just hiding the fact that there was a
dual license.

If anyone thinks this would be a bad, or good, change to make let me
know. It probably wouldn't affect too many packages and wouldn't do a
whole lot to make their license tags that much shorter. I don't feel
too strongly about it but I am trying to think of ways we could make
SPDX expressions a little simpler without abandoning all integrity.

Note that adoption of this approach this would not be an assertion
that (foo AND bar AND (foo OR bar)) is *equivalent* to (foo AND bar).

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: CC0 license of dlmalloc in sgx-sdk package review

[Richard Fontana]

On Thu, Sep 7, 2023 at 11:35 AM Daniel P. Berrangé  wrote:
>
> Does anyone have feedback on this license review questionmark
>
> On Tue, Aug 29, 2023 at 12:11:38PM +0100, Daniel P. Berrangé wrote:
> > Hi Legal
> >
> > The 'sgx-sdk' package is currently open for review  with a view to
> > adding to Fedora:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=2085444
> >
> > One of the last stumbling blocks is that it includes a copy of the
> > "dlmalloc" code under the CC0 license, which is now a forbidden
> > code license for packages being newly added to Fedora.
> >
> > The authors of sgx-sdk have contacted the original author of
> > dlmalloc, and he apparently suggested that since CC0 is a public
> > domain license, they can just add a second license header of their
> > choosing to the source files and Fedora can then ignore the orignial
> > CC0 license.
> >
> > This smells fishy to me, as I can't come with rationale for why
> > adding a second "BSD" license header to the source file and justify
> > Fedora ignoring the original CC0. The original code would still
> > explicitly not have a patent grant, and an extra license doesn't
> > seem to alter that fact.
> >
> > It was pointed out that this approach has already been taken by
> > OpenJDK, where they took CC0 code and added a GPL-v2-only header:
> >
> >   
> > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
> >
> > OpenJDK though would be grandfathered in, since it existed in
> > Fedora before CC0 was forbidden, so I'm not sure that can be
> > relied on as a precedent.
> >
> > I am not a lawyer, so I want an expert opinion on this suggestion
> > that adding a 2nd license header allows Fedora to ignore the
> > original CC0 license. If it is true, then it would appear to
> > make the whole exercise of banning CC0 effectively pointless.

Yes, I agree. If this happened upstream and we were unaware of it,
that would be one thing, but this is not the case.

This 'trick' has been suggested before. Aside from the policy issue,
it's actually not clear that CC0 allows this because CC0 contains a
clause prohibiting sublicensing which AFAIK is in all the CC licenses
(though possibly its inclusion in CC0 is a bug).

I had the impression previously that Doug Lea didn't mean to use CC0
in a serious sense and that he was just recharacterizing an earlier
public domain dedication release, but I guess that might not be right.
However, if earlier versions of this code were under CC-PDDC or a more
informal public domain dedication, it may be that the quantum of stuff
actually under CC0 is fairly minimal.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Making no-conditions identifiers optional in the License: field

[Richard Fontana]

On Mon, Sep 4, 2023 at 10:03 AM Miroslav Suchý  wrote:
>
> Dne 01. 09. 23 v 9:54 Daniel P. Berrangé napsal(a):
> > Shorter is indeed better because it is far easier for humans to read when 
> > it is more concise, especially so because
> > once the expression is flattened, the SPDX identifiers could be 
> > alphabetically orered as in this example above.
>
> Do we want to have it easier for humans or for machines?
>
> I think that we now target more machines (especially because of the 
> "exchange" part from SPDX abbrev). If you want more
> human friendly way you can feed the formula to some library and get 
> abbreviated form. E.g., you can use `simplify()` from
>
> https://github.com/nexB/license-expression#usage-examples
>
> It is packaged in Fedora.
>
> And I agree that once we migrate to SPDX we should always present to 
> **users** the simplified formula. But in sources
> (in spec) we should track the full formula.

I'm not sure if that `simplify()` does anything interesting - seems
like it either just applies commutativity and associativity or else it
may attempt to make further algebraic reductions that are questionable
as equivalent expressions. I believe Mulhern made the related point in
another thread that algebraic simplifications may not be possible (and
I think the underlying point is that these are not true boolean
expressions).

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Making no-conditions identifiers optional in the License: field

[Richard Fontana]

On Wed, Aug 30, 2023 at 1:08 PM Fabio Valentini  wrote:

> Wouldn't dropping licenses (or exceptions) that entail no conditions
> just be another way to do "effective license analysis" (i.e. who needs
> to decide whether the license entails no conditions)?
> Listing everything might be verbose, but it at least has the benefit
> of being *simple*, and doesn't involve judgement calls like "this
> license doesn't matter in this case").

The assumption here is that packages will continue to be reviewed
carefully wrt licensing and that new licenses encountered in source
code will continue to go through the Fedora review process and be
added to fedora-license-data.  I was thinking that the excludability
characteristic could be recorded at the time that a license identifier
is added to fedora-license-data. It wouldn't be package-specific,
except that if the otherwise excludable license is the only
identifiable license text applicable to a package, it would have to be
listed.

> Just listing the licenses of the files in the upstream project
> (whether the contents end up shipped in our packages or not) is "just
> passing through" information and not particularly useful (in which
> case we could just say "the license of this package is the license of
> this upstream project, go look it up yourself" instead of including a
> License tag in the RPM).

Agreed, I think this was one of the main reasons why we ended up not
adopting a "license of the source code" approach.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Making no-conditions identifiers optional in the License: field

[Richard Fontana]

On Mon, Aug 28, 2023 at 10:31 AM Vít Ondruch  wrote:
>
>
> Dne 24. 08. 23 v 20:52 Richard Fontana napsal(a):
> > Some of the complaints that have surfaced since the migration from the
> > Callaway system to SPDX seem to be, at root, an aesthetic distaste for
> > complex license expressions in RPM license metadata. This may explain
> > why some favor application of "effective license" analysis. I suspect
> > there is also a sort of psychological desire to hide the underlying
> > licensing complexity that characterizes many packages.
> >
> > I do think that the current approach can be criticized as being overly
> > pedantic, and perhaps also internally contradictory (some of Florian's
> > recent comments get at the various ways in which we are being
> > contradictory). We have a still-undocumented rule that what I call
> > "true public domain" should not be reflected in the License: field
>
>
> The problem is that leaving out this "true public domain" tag makes
> license review harder in a sense.
>
> Let me explain. If I am reviewing license and find some file being "true
> public domain", leaving it out might mean that it won't be recorded
> anywhere that it was already identified as a "true public domain". Doing
> the review next time, I (or somebody else) will need to find it the hard
> way again.
>
> I think that the current license field is unfortunately very limited in
> expressing the source license. I wish if we were able to record the
> license per file or even per file lines. But admittedly, this won't be
> easier.

I guess we have been stretching the "License: " field beyond whatever
purpose it was originally supposed to have (probably never well
defined or thought out). It is not useful by itself for keeping track
of source-file-specific license review.

The REUSE specification (https://reuse.software), which enforces a
per-source-file license identification discipline, might be a way to
facilitate that, but that is something that is generally adopted by
upstream projects, not by downstream packagers.

fedora-license-data and fedora-legal-docs themselves conform to REUSE,
largely relying on the use of a dep5 file (even though I think REUSE
disapproves of that approach) and using some custom-defined license
identifiers that I think REUSE might frown upon (but which do serve to
keep track of "true public domain" stuff). See:
https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/.reuse/dep5?ref_type=heads
https://gitlab.com/fedora/legal/fedora-legal-docs/-/blob/main/.reuse/dep5?ref_type=heads

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Making no-conditions identifiers optional in the License: field

[Richard Fontana]

On Fri, Sep 1, 2023 at 11:56 AM Iñaki Ucar  wrote:
>
> Apologies if this has been discussed before, but why not something
> like the debian/copyright file? The License tag could be just a list
> of all licenses found, without AND or OR, to avoid the combinatorial
> issue, and then a copyright file could exactly list what applies to
> what.

It has basically not been discussed before. I think if we were
starting over from scratch I would probably suggest something like the
Debian approach. That also has the advantage of solving the problem of
what standards to adopt around license file inclusion (which currently
haven't been touched in our post-July-2022 documentation and which
really don't make much sense, at least in relation to the rest of the
current Fedora legal guidelines).

My past assumption has been that it would be culturally too hard for
Fedora to copy the Debian approach (although it occurs to me that
Fedora could just reuse a lot of the Debian package data with limited
modification). Maybe that's wrong? Maybe the current guidelines
involve the same sort of effort that Debian package maintainers engage
in.

One reason I don't like the "without AND or OR" approach is it is
basically abandoning the idea of using per-RPM or per-package SPDX
expressions, while retaining the idea that we should be using SPDX
expressions at a more atomic level. But if we adopted the Debian
approach I don't see why we should need to continue populating the
License: field at all (not sure how Debian deals with this, offhand).

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Making no-conditions identifiers optional in the License: field

[Richard Fontana]

On Fri, Sep 1, 2023 at 8:09 AM Vít Ondruch  wrote:
>
> Can we attach percentage to each license? E.g. "Kernel is from 99,9625 %
> GPL-2.0-only license"
>
> I am proposing this mostly as a joke. Nevertheless, it is interesting
> information IMHO.

This sounds similar to an idea I had a few years ago, when I was
somewhat more enthusiastic about general use of ScanCode as a tool. I
think ScanCode can give you results of licenses identified in source
code in a percentage ranking, so my idea was "just list the top few
detected licenses". The idea had the problem of being
scanner-dependent (or else associated with inconsistent approaches
based on the scanner used) and also the mere fact that a license shows
up a lot in detections doesn't necessarily mean it *covers* content in
the package to the extent that would suggest (i.e., some results would
be pretty misleading, seemingly).

It also conflicts with what I think of as a  "truth in labeling"
principle which may be something that should guide us here, to some
degree. It is not uncommon for a package to have a small portion of
code covered by a license that is in some sense problematic or
unexpected in a way that is disproportionate to how often it appears.
To use the example of the kernel, there's the presence of Clear BSD
(SPDX: BSD-3-Clause-Clear) on some source files. Arguably there is a
value in exposing that fact, especially for those of us who don't
consider that to be an open source license. But truth in labelling
doesn't mean "list everything in precise detail" necessarily.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Making no-conditions identifiers optional in the License: field

[Richard Fontana]

On Thu, Aug 31, 2023 at 7:13 PM Jilayne Lovejoy  wrote:

> >License: Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND 
> > BSD-3-Clause-Clear AND CDDL-1.0 AND copyleft-next-0.3.1 AND 
> > GPL-1.0-or-later AND GPL-1.0-or-later-WITH-Linux-syscall-note AND 
> > GPL-2.0-only AND GPL-2.0-only-WITH-Linux-syscall-note AND GPL-2.0-or-later 
> > AND GPL-2.0-or-later-WITH-GCC-exception-2.0 AND 
> > GPL-2.0-or-later-WITH-Linux-syscall-note AND ISC AND LGPL-2.0-or-later AND 
> > LGPL-2.0-or-later-WITH-Linux-syscall-note AND LGPL-2.1-only AND 
> > LGPL-2.1-only-WITH-Linux-syscall-note AND LGPL-2.1-or-later AND 
> > LGPL-2.1-or-later-WITH-Linux-syscall-note AND Linux-OpenIB AND MIT AND 
> > MPL-1.1 AND Redistributable, no modification permitted AND X11 AND Zlib
> >
> but then this would be an exception to our original policy? and how
> would we articulate that? I'm not sure why this is really any "better"
> than your original - it's just shorter and truncated.
>
> oh, and we should take a look at the "Redistributable, no modification
> permitted" ones... that is likely the firmware licenses that were never
> captured

In the kernel specifically, I think 'Redistributable, no modification
permitted' resulted from a bugzilla ticket filed many years ago by
Alexandre Oliva where he pointed out that 'GPLv2' as the kernel
license tag was incorrect because there was some firmware hex code in
at least one source file (this was some years after the creation of
the linux-firmware repository upstream). I remember verifying that he
was correct but I wonder if that code is still in the kernel today.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Effective license analysis: required or not?

[Richard Fontana]

On Mon, Aug 28, 2023 at 3:25 PM Fabio Valentini  wrote:

> So yes, we rely on and adhere to the "License tag reflects binary
> package contents" rule.

So you are reasonably happy with the current rules as they affect the
License: field for Rust crate packages? Or is there anything you would
like to see changed?

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Bundled Public Domain/CC0-1.0 blake2 library in Python

[Richard Fontana]

On Tue, Aug 29, 2023 at 7:18 AM Miro Hrončok  wrote:
>
> Hello,
>
> when reviewing a pull request by Yaakov [1], I realized Python bundles [2] the
> reference blake2 implementation known as libb2 [3]. We already have that
> packaged in Fedora as libb2, licensed as CC0. The library itself has:
>
> > To the extent possible under law, the author(s) have dedicated all copyright
> > and related and neighboring rights to this software to the public domain
> > worldwide. This software is distributed without any warranty.
> >
> > You should have received a copy of the CC0 Public Domain Dedication along 
> > with
> > this software. If not, see 
> > .
>
> In the source files.
>
> So this is "public domain" but it also mentions CC0 Public Domain Dedication
> explicitly. Is this LicenseRef-Fedora-Public-Domain or CC0-1.0? And if it is
> the latter, how do I deal with that?
>
> [1] https://src.fedoraproject.org/rpms/python3.12/pull-request/63
> [2] https://github.com/python/cpython/tree/main/Modules/_blake2/impl
> [3] https://github.com/BLAKE2/libb2

I'd treat this as CC0-1.0 (I don't think that is altered by the form
of license notice on individual source files). Presumably it's covered
by the grandfathering exception
https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/data/CC0-1.0.toml?ref_type=heads#L11-14

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Bundled Public Domain/CC0-1.0 blake2 library in Python

[Richard Fontana]

On Tue, Aug 29, 2023 at 11:16 AM Petr Pisar  wrote:
>
> V Tue, Aug 29, 2023 at 10:48:46AM +0200, Miro Hrončok napsal(a):
> > > To the extent possible under law, the author(s) have dedicated all 
> > > copyright
> > > and related and neighboring rights to this software to the public domain
> > > worldwide. This software is distributed without any warranty.
> > >
> > > You should have received a copy of the CC0 Public Domain Dedication along 
> > > with
> > > this software. If not, see 
> > > <http://creativecommons.org/publicdomain/zero/1.0/>.
> >
> > In the source files.
> >
> > So this is "public domain" but it also mentions CC0 Public Domain Dedication
> > explicitly. Is this LicenseRef-Fedora-Public-Domain or CC0-1.0?
>
> I think it's LicenseRef-Fedora-Public-Domain.
>
> First, it does not match any SPDX-known license text.
> Second, "CC0 Public Domain Dedication" probably refers to SPDX license CC-PDDC
> <https://creativecommons.org/licenses/publicdomain/>.
> Third, the <http://creativecommons.org/publicdomain/zero/1.0/> link refers to
> CC0-1.0, a different license from CC-PDDC.
>
> Last, recently I asked a similar case (a public domain dedication with
> a fallback to a license)
> <https://gitlab.com/fedora/legal/fedora-license-data/-/issues/306#note_1530527250>
> and Richard Fontana concluded that these kind of texts fall into
> LicenseRef-Fedora-Public-Domain bucket.

In the case of blake2 though there is a copy of the CC0 text in the
COPYING (previously named LICENSE) file in the repository.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Anarch's CC0 licence

[Richard Fontana]

On Mon, Aug 28, 2023 at 3:42 AM Artur Frenszek-Iwicki
 wrote:
>
> Hi all,
>
> so some time ago... oh my, it's been a year already. Either way -
> Creative Commons Zero has been re-classified in Fedora
> as allowed for content, but not for code. [0]
>
> I maintain a package, anarch [1], which is licensed under CC0.
>
> For what it's worth, in the upstream readme, the author expresses
> their intent for the project to be placed in the public domain: [2]
> > tl;dr: everything in this repository is CC0 + a waiver of all rights,
> > completely public domain as much as humanly possible, do absolutely 
> > anything you want
> > ...
> > I therefore release everything in this repository under CC0 1.0
> > + a waiver of all other IP rights (including patents), which is as follows:
> > ...
>
> So I guess my question is: what do I do with it?
> 1) Can the package stay as-is, with a "CC0-1.0" license tag, basically 
> grandfathered in?
> 2) Can the package stay, but with the license tag changed to 
> "LicenseRef-Fedora-PublicDomain"?
> 3) No-go and should be retired?

4) Please submit an issue in fedora-license-data to have the "usage
rights" reviewed - this may be OK.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Effective license analysis: required or not?

[Richard Fontana]

On Tue, Aug 22, 2023 at 9:41 AM David Cantrell  wrote:
>
> We did portray this as a re-audit and not simply a change in abbreviations.  
> I did many presentations on just that and we held numerous hack fests where 
> we helped people analyze packages to determine the correct license expression 
> in SPDX.
>
> There are definitely maintainers who thought it was just a change in 
> abbreviations and I do not think there is an easy way to stop that.  But as 
> we have been going through this process, the number of maintainers auditing 
> packages has been high and we are seeing more licenses captured and added to 
> SPDX that were not previously represented.

+1. Whatever else one thinks of the changes over the past year, this
'license re-audit' side effect has been a great ongong success and
improvement for Fedora and its downstreams, probably without parallel
in Linux distributions (apart from Debian), and also has resulted in a
vast improvement to SPDX.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Effective license analysis: required or not?

[Richard Fontana]

On Tue, Aug 22, 2023 at 3:34 AM Petr Pisar  wrote:
>
> V Mon, Aug 21, 2023 at 01:04:29PM +0200, Florian Weimer napsal(a):
> > * Most package maintainers probably assume that License: tags on all
> >   built RPMs (source RPMs and binary RPMs) should reflect binary package
> >   contents, at least when all subpackages are considered in aggregate.
> >   Often, Source RPMs contain the same License: line as binary RPMs.
> >
> That's a shortcomming of RPM. It reuses License tag of the main subpackage for
> source RPM.

Out of curiosity, is what subpackage is the "main" subpackage a well
defined concept, or is it just "the builit package that is described
first in the spec file" and beyond that a matter of convention? I
couldn't find the answer to this in a few minutes of naive searching.

> > In the light of this, I would like to suggest updating the guidelines in
> > the following way:
> >
> >   The License: line should be based on the sources only.  Using a tool
> >   such as Fossology to discover relevant licenses and their SPDX tags is
> >   sufficient.  No analysis how licenses from package source code or the
> >   build environment propagate into binary RPMs should be performed.
> >   Individual SPDX identifiers that a tool has listed should be separated
> >   by AND.  Package maintainers are encouraged to re-run license analysis
> >   tooling on the source code as part of major package rebases, and
> >   update the License: tag accordingly.
> >
> > To me, that seems to be much more manageable.
> >
> Yes, that's a very realistic approach of what we can expect from the
> packagers.
>
> I only worry whether the resulting License tag will be any helpful for our
> users.  E.g. most of the subpackages of perl.spec are "GPL-1.0-or-later OR
> Artistic-1.0-Perl". With your approach their license tag would gain
> a ridiculous license identifiers that are not really contained.

This could possibly be addressed by Daniel's idea of a "use your
judgment to exclude what is clearly irrelevant" standard (as I would
put it).

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Effective license analysis: required or not?

[Richard Fontana]

On Fri, Aug 25, 2023 at 5:58 AM Florian Weimer  wrote:
>
> * Richard Fontana:

> > When we (a bunch of us inside Red Hat that is) started to think about
> > revamping the rules on RPM license metadata, we thought about a number
> > of options. One thing I should note is that my enthusiasm for a
> > "license of the binary" rule was never really shared by anyone else I
> > talked to at Red Hat
>
> There might now be downstream requirements for something like this.
> Some people are trying to figure out.
[. . .]
> One the one hand, I'd be exciting about tooling support for this.
> (There is significant overlap with recording “this program has
> components that used include files from glibc-devel-2.36-9.fc37.x86_64
> for compilation”.)  But it's a lot of work to implement across many
> components before such information can be propagated automatically.  But
> I don't know if that matches commercial needs, and to what these needs
> can be met with tooling alone and without per-source-file markup.
>
> It's also possible that people who are looking for “license of the
> binary” actually want information about potential run-time executions
> and what is constructed by very late binding.
>
> Personally, I'm also worried that the data may be used to minimize
> shipping source code, although I don't think it's technically suited to
> that.
>
> > I'm deliberately ignoring most of the rest of your comments in this
> > message because I think they raise some additional topics, because I
> > want to make sure there is some focus on this one. What do we do about
> > the "license of the binary" rule?
>
> I think we should definitely try to get a downstream view on this, if
> there is one.

I assume you primarily mean the view of engineers working on packaging
for CentOS Stream/RHEL, but the main downstream interest in package
license metadata I am aware of doesn't relate directly to engineering.
Red Hat periodically gets requests from some customers or partners for
detailed lists of information about components, primarily licensing
information. For reasons that go well beyond the need to respond to
such requests, Red Hat Product Security has also invested in
developing systems for producing SBOMs and this is now being used as a
basis for responding to those kinds of requests.

Anyway, the approach that has always been taken in responding to these
requests for RPMs, at least those coming from RHEL specifically, has
been to use the License: field contents (ignoring any varying
information for subpackages). So basically there is one list item
corresponding to each SRPM. This is justified partly by the quality we
associate with the Fedora-based approach, i.e. we feel we can report
the contents of the License: field in most cases rather than scan or
otherwise review the package anew.

Note that there are other important ways in which the license review
and categorization work done by Fedora benefits Red Hat. Most notably,
the data on allowed and not allowed licenses serves as Red Hat's own
policy on what licenses are allowed and not allowed. The switch to
SPDX identifiers has facilitated this because it enables a much more
precise definition of allowed/not allowed than was possible under the
Callaway system. But none of that is really directly dependent on any
particular rule adopted for what license information gets reported in
RPM license metadata.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Making no-conditions identifiers optional in the License: field

[Richard Fontana]

Some of the complaints that have surfaced since the migration from the
Callaway system to SPDX seem to be, at root, an aesthetic distaste for
complex license expressions in RPM license metadata. This may explain
why some favor application of "effective license" analysis. I suspect
there is also a sort of psychological desire to hide the underlying
licensing complexity that characterizes many packages.

I do think that the current approach can be criticized as being overly
pedantic, and perhaps also internally contradictory (some of Florian's
recent comments get at the various ways in which we are being
contradictory). We have a still-undocumented rule that what I call
"true public domain" should not be reflected in the License: field
(unless it would otherwise be empty), yet we have carefully attempted
to collect nonstandard public domain dedication statements and cover
those by `LicenseRef-Fedora-Public-Domain`. We have been using a
similar approach with `LicenseRef-Fedora-UltraPermissive`. These
basically replace Callaway system names "Public domain" (though this
was sometimes used for "true public domain") and "Freely
redistributable without restrictions", respectively.

I think it can reasonably be argued that there is little point in
including `LicenseRef-Fedora-Public-Domain` and
`LicenseRef-Fedora-UltraPermissive` in the License: field since they
are associated with no conditions or obligations. In those special
cases where the License: field would otherwise be empty, we can ask
SPDX to create unique identifiers for the license text in question.

We might want to extend this principle to other things, such as GPL
exceptions that entail no conditions in the use case encountered in
particular packages. (There is already an old issue about this, I
think concerning the Bison exception.)

This wouldn't do *that* much to make License: fields simpler, so maybe
it's not particularly worthwhile. There is also the problem that if we
make it optional, package maintainers may be less likely to scrutinize
things that are assumed to fall into these kinds of categories, when
in some cases they actually wouldn't, although I think it's now clear
that those situations are uncommon. In theory we'd still expect
package maintainers to submit issues to have things that seem to
qualify for LicenseRef-Fedora-Public-Domain reviewed, but it might be
challenging to enforce that expectation and the Fedora Legal team
would have to end up doing all that work themselves, which might be a
justifiable result.

As with abandoning the "license of the binary" rule, this would
seemingly be a major departure from the principles established under
the Callaway system.

Any thoughts on this?

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Effective license analysis: required or not?

[Richard Fontana]

On Mon, Aug 21, 2023 at 7:04 AM Florian Weimer  wrote:
>
> I think Richard said that he would start a thread like this, but it
> hasn't happened, so I feel like should get this off my chest now.

> 
> starts with this:
>
> | No “effective license” analysis
> |
> | The License: field is meant to provide a simple enumeration of the
> | licenses found in the source code that are reflected in the binary
> | package. No further analysis should be done regarding what the
> | "effective" license is, such as analysis based on theories of GPL
> | interpretation or license compatibility or suppositions that
> | “top-level” license files somehow negate different licenses appearing
> | on individual source files.
>
> This is contradictory.  I think there are two aspects here:
>
> * Determine possible licenses that end up in the binary package.
>
> * Perform algebraic simplifications on the license list.
>
> Both analyses are forms of effective licensing analysis.  Of course, you
> cannot derive an SPDX identifier without doing any analysis.  However, I
> strongly believe that the first approach (determining the binary package
> license) is itself a form of effective licensing analysis, and similar
> reasons for package maintainers not doing this applies.  The derived
> SPDX identifier will reflect both the package source code and what went
> into the build system.

We were using "effective license" somewhat more narrowly, referring to
how that phrase was used in some of the legacy Fedora documentation as
well as how it is used sometimes in non-Fedora FLOSS-legal contexts. I
am certain the phrase was not invented by Fedora but somehow it crept
into FLOSS legal commentary about 10 or so years ago and I wasn't even
aware it was used in Fedora documentation until last year. It
partially embodies (usually in a highly distorted way) a much older
set of folk-understandings of the operation of the *GPL license family
in particular but is often used more generally. It may have some
connection to what SPDX calls the "concluded license" (which is
contrasted with the "declared license") but to be honest I am not sure
what those concepts mean.

It's true that in a less specific way we are doing lots of "effective
license analysis", for example anytime I have said that something is
"not a license" despite the license text appearing in some source
code.

> Below, I'm collecting a list of observations of what I believe is the
> current approach in this area, as taken by package maintainers carrying
> out the SPDX conversion.  To me, it strongly suggest that the SPDX
> identifiers we derive today do not accurately reflect binary RPM package
> licensing, even when lots of package maintainers put in the extra effort
> to determine binary package licenses.
>
> * Most package maintainers probably assume that License: tags on all
>   built RPMs (source RPMs and binary RPMs) should reflect binary package
>   contents, at least when all subpackages are considered in aggregate.
>   Often, Source RPMs contain the same License: line as binary RPMs.

This is the most important issue I was hoping to raise, if we mean the
same thing.

We (Jilayne and I and others who worked on the new Fedora
license-related docs) did not invent this concept. The old Fedora
documentation had a "license of the binary" policy, I assume developed
mainly by Tom Callaway, that I always thought was a great analytical
or representational advance. Here's what the old Fedora docs said:

The oldest archived version of
http://fedoraproject.org/wiki/Packaging:LicensingGuidelines(dated from
2008) says "The License: field refers to the licenses of the contents
of the *binary* rpm." The author was clearly at pains to make clear
that it was not meant to encompass the entirety of the source code as
packaged in source RPMs.

At least since 2009, this was followed by: "If a source package
generates multiple binary packages, the License: field may differ
between them if necessary. This implies that a single spec may have
multiple per-subpackage License: tags. Each of those License: tags
must comply with all applicable guidelines."

I thought I understood what that meant and I thought I saw examples of
that in operation. Recently, I've started to wonder whether I
misunderstood that all along, though I don't see how. The text seems
very clear to me.

When I look randomly at spec files of Fedora packages, I begin to
suspect that most Fedora package maintainers must have always ignored
this directive and have continued to ignore it after the rule was
recast in the post-July-2022 docs. In *most* cases of packages other
than possibly those coming from ecosystems or historical contexts
featuring highly uncomplicated licensing structures, there will be
some differences in the makeup of binary packages from a built source
code licensing standpoint. I only rarely see attempts to reflect this
via multiple L

[Fedora-legal-list] Re: Nonfree font(s) in 90-Second-Portraits (was: Effective license analysis: required or not?)

[Richard Fontana]

On Thu, Aug 24, 2023 at 12:57 PM Jeremy Newton
 wrote:
>
> Yeah, I also noticed another one of my packages has a possible problematic 
> font, but it's unclear to me:
> https://src.fedoraproject.org/rpms/safetyblanket
> https://github.com/SimonLarsen/safetyblanket/blob/master/res/fonts/notalot35.ttf
>
> For the yb.ttf, I just replaced it with another font included in the source 
> that's OFL in the %prep section. I assume this is sufficient?

I think so.

However, it's possible the atari.tff file is problematic too. It was
not clear to me how this was licensed even after locating a likely
origin for the file.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Nonfree font(s) in 90-Second-Portraits (was: Effective license analysis: required or not?)

[Richard Fontana]

On Wed, Aug 23, 2023 at 4:00 PM Robert-André Mauchin  wrote:

> https://src.fedoraproject.org/rpms/90-Second-Portraits/pull-request/1
>
> Surprise, surprise, we have non free code, this is just amazing!
>
> Analysis:
>
> OFL-1.1
> ---
> 90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/data/fonts/neuton.ttf
>
> CC-BY-SA-4.0 AND CC-BY-3.0 AND Zlib
> ---
> 90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/LICENSE.txt
>
> LicenseRef-proprietary-license
> ---
> 90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/data/fonts/yb.ttf
>
>
> After research: https://www.dafont.com/young-beautiful.font
>
> Note of the author:
> My fonts are free for PERSONAL use only. For any commercial use (anything you 
> make money
> from), you must send a paypal donation.
>
> Please visit my website http://mistifonts.com/ to see my affordable prices.
>
> And on that site we have:
>
> Terms Of Use
>
> This font is free for personal use and non-profit use.
> If you make money from using this font, you must purchase a license.
> You may not trace or edit my fonts and then resell them as your own creation. 
> For example:
> Taking my font, tracing over the letters or editing some of the letters, and 
> then selling
> that font.
>
> Please download, install and test the font before purchasing a license to 
> ensure that it
> works for your intended use.
>
> You can read license Terms of Use >>here<<
>
>
> => NON FREE (AS IN SPEECH, NOT BEER)

Thanks, I agree and also confirmed using 'strings' on the data/yb.ttf file.

I submitted this ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2234478

I think the atari.ttf font file may also be problematic.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Is this still Boehm-GC?

[Richard Fontana]

On Mon, Aug 21, 2023 at 9:04 AM Florian Weimer  wrote:
>
> The SPDX reference pattern uses “Copyright (c)”, and the second
> paragraph is in ALL CAPS.  Furthermore, the Boehm-GC text says
> “program” instead of “shellscript”.
>
> # Copyright 2018 B. Persson, bj...@rombobeorn.se
> #
> # This material is provided as is, with absolutely no warranty expressed
> # or implied. Any use is at your own risk.
> #
> # Permission is hereby granted to use or copy this shellscript
> # for any purpose, provided the above notices are retained on all copies.
> # Permission to modify the code and to distribute modified code is granted,
> # provided the above notices are retained, and a notice that the code was
> # modified is included with the above copyright notice.

The SPDX XML file for Boehm-GC:
https://github.com/spdx/license-list-XML/blob/main/src/Boehm-GC.xml
does not account for "shellscript" as an alternative to "program".

In SPDX 
(https://spdx.github.io/spdx-spec/v2-draft/license-matching-guidelines-and-templates/)
Details of copyright notices are ignored for matching purposes and
matching is case insensitive. Fedora is basically adopting the SPDX
understanding of what "matching" means for purposes of using SPDX
identifiers.

So probably what would need to be done here is getting SPDX to modify
the XML for Boehm-GC rather than assign a new identifier for this
variant.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Support of modern file formats in exiv2

[Richard Fontana]

On Sun, Aug 13, 2023 at 4:18 AM Mattia Verga  wrote:
>
> I have found an old (2021) ticket in BZ regarding exiv2 support being 
> disabled for some modern file formats.
> https://bugzilla.redhat.com/show_bug.cgi?id=1979565
>
> There it is said that the ticket is awaiting for some conclusion from Fedora 
> Legal, yet I cannot find any discussion was ever opened here on ML, nor any 
> comment was ever posted by legal there.
> Can someone drop a comment there? BTW support in exiv2 is now enabled by 
> default, but disabled in Fedora specfile.

I don't think I am familiar with this one. From the ticket it sounds
like Ben was working with the Red Hat patent team on this a few years
ago, so I'll forward this to their attention.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: License of perl-Data-UUID

[Richard Fontana]

On Wed, Aug 9, 2023 at 6:31 AM Jitka Plesnikova  wrote:
>
> Hi,
>
> I want to update License tag to SPDX format in perl-Data-UUID [1], and
> the Makefile.PL in source is declared as being BSD:
>
>https://metacpan.org/release/RJBS/Data-UUID-1.226/source/Makefile.PL#L75
>
> There is no text which contains any variant of BSD license.
>
> However, it also contains this file:
>
>https://metacpan.org/release/RJBS/Data-UUID-1.226/source/LICENSE
>
> It was approved as HP-1989 [2].
>
> The issue to clarify the license was already reported to upstream [3],
> but it wasn't solved yet.
>
> Current License tag for the package is "BSD and MIT".
>
> Could you please help me to find correct License tag value?
>
> Thank you,
> Jitka
>
> [1] https://src.fedoraproject.org/rpms/perl-Data-UUID
> [2] 
> https://github.com/spdx/license-list-XML/issues/2019#issuecomment-1634809827
> [3] https://github.com/bleargh45/Data-UUID/issues/26

Without some further clarification from the maintainer, I would assume
the references to "bsd" were an attempt to describe the license
(HP-1989 as SPDX now calls it) that is in the LICENSE file, which says
"The same terms apply to this code". It is not uncommon to see "BSD"
used to refer somewhat arbitrarily to old permissive licenses
including ones bearing no obvious similarity to the actual BSD license
family. I would only revise this conclusion if the maintainer said
that later changes were supposed to be under some version of the BSD
license or something like that.

Also it looks like this:
https://metacpan.org/release/RJBS/Data-UUID-1.226/source/ptable.h
would be under the standard Perl 5 license?

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: msv (xsdlib) licensing review

[Richard Fontana]

As for https://github.com/xmlark/msv/blob/main/docs/xsdlib/copyright.txt
I think this should be ignored.

On Tue, Aug 8, 2023 at 2:24 PM Richard Fontana  wrote:
>
> On Tue, Aug 8, 2023 at 9:00 AM Marián Konček  wrote:
> >
> > As part of the jaxb 4.0.2 -> 4.0.3 update, part of this package is
> > needed for its code generation. Therefore, I would like to package it in
> > Fedora. This package has complex licensing which is why I am asking for
> > a review. Note that I only need the "xsdlib" subdirectory.
> >
> > I only need a stripped-down version of this package as if by
> > downloading:
> > https://github.com/xmlark/msv/archive/refs/tags/msv-2022.7.tar.gz
> >
> > and running (inside the msv-msv-2022.7 directory):
> >
> > find . -mindepth 1 -maxdepth 1 -type d ! -name 'xsdlib' -exec rm -rf {} +
> > rm -rf xsdlib/src/main/resources
> > rm -rf xsdlib/src/test
> > grep -l -r --ignore-case 'proprietary' | xargs rm -v
> >
> > Most problematic license files are: copyright.txt and license.txt in
> > https://github.com/xmlark/msv/tree/main/docs/xsdlib. To my knowledge,
> > all files that remained use explicit BSD-3-Clause or Apache-1.1.
> > Question is whether we could have removed the copyright.txt and
> > license.txt files in the first place.
> >
> > Current upstream: https://github.com/xmlark/msv
> > Previous package in Fedora (used different source repository):
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=2576
> > Previous bug related to licensing:
> > https://bugzilla.redhat.com/show_bug.cgi?id=87684
> >
> > Also grep --ignore-case for "proprietary" "confidential", "nuclear".
>
> Can you create  a package just from that subset of the xsdlib
> directory as you indicated above?
>
> In those files, what I saw on a quick review was:
>
> - pom.xml : there's a Sun BSD license that is probably OK for Fedora
> but does not seem to match any known variant. (It's tempting to just
> ignore this but since it's probably OK we might as well add it.)
>
> - Oracle 3-clause BSD licenses: most of these seem to be BSD-3-Clause,
> but there was one for which SPDX would need to revise the markup, I
> think ( xsdlib/src/main/java/com/sun/msv/datatype/regexp/InternalImpl.java)
>
> - The Apache 1.1 license appearing on a number of source files does
> not quite match SPDX Apache-1.1, would require SPDX revision to the
> Apache-1.1 markup
>
> So these seem fairly nonproblematic but it would be helpful if you
> could create issues for these in fedora-license-data and then at
> github.com/spdx/license-list-XML.
>
> But if you need to package any of the other stuff in this repository
> that may complicate things further.
>
> Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: msv (xsdlib) licensing review

[Richard Fontana]

On Tue, Aug 8, 2023 at 9:00 AM Marián Konček  wrote:
>
> As part of the jaxb 4.0.2 -> 4.0.3 update, part of this package is
> needed for its code generation. Therefore, I would like to package it in
> Fedora. This package has complex licensing which is why I am asking for
> a review. Note that I only need the "xsdlib" subdirectory.
>
> I only need a stripped-down version of this package as if by
> downloading:
> https://github.com/xmlark/msv/archive/refs/tags/msv-2022.7.tar.gz
>
> and running (inside the msv-msv-2022.7 directory):
>
> find . -mindepth 1 -maxdepth 1 -type d ! -name 'xsdlib' -exec rm -rf {} +
> rm -rf xsdlib/src/main/resources
> rm -rf xsdlib/src/test
> grep -l -r --ignore-case 'proprietary' | xargs rm -v
>
> Most problematic license files are: copyright.txt and license.txt in
> https://github.com/xmlark/msv/tree/main/docs/xsdlib. To my knowledge,
> all files that remained use explicit BSD-3-Clause or Apache-1.1.
> Question is whether we could have removed the copyright.txt and
> license.txt files in the first place.
>
> Current upstream: https://github.com/xmlark/msv
> Previous package in Fedora (used different source repository):
> https://koji.fedoraproject.org/koji/packageinfo?packageID=2576
> Previous bug related to licensing:
> https://bugzilla.redhat.com/show_bug.cgi?id=87684
>
> Also grep --ignore-case for "proprietary" "confidential", "nuclear".

Can you create  a package just from that subset of the xsdlib
directory as you indicated above?

In those files, what I saw on a quick review was:

- pom.xml : there's a Sun BSD license that is probably OK for Fedora
but does not seem to match any known variant. (It's tempting to just
ignore this but since it's probably OK we might as well add it.)

- Oracle 3-clause BSD licenses: most of these seem to be BSD-3-Clause,
but there was one for which SPDX would need to revise the markup, I
think ( xsdlib/src/main/java/com/sun/msv/datatype/regexp/InternalImpl.java)

- The Apache 1.1 license appearing on a number of source files does
not quite match SPDX Apache-1.1, would require SPDX revision to the
Apache-1.1 markup

So these seem fairly nonproblematic but it would be helpful if you
could create issues for these in fedora-license-data and then at
github.com/spdx/license-list-XML.

But if you need to package any of the other stuff in this repository
that may complicate things further.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: kickstart files and trademark licensing question on Ask Fedora

[Richard Fontana]

I would suggest discussing it further with Kristin - it may be that I
mis-explained the nature of what kickstart files are and how they're
used.

- Richard

On Mon, Aug 7, 2023 at 1:32 PM Matthew Miller  wrote:
>
> Hmmm. That seems pretty strong — they're just sharing a kickstart file,
> after all.
>
>
> On Mon, Aug 07, 2023 at 11:41:37AM -0400, Richard Fontana wrote:
> > I had a discussion with Kristin Borths (Red Hat's trademark lawyer)
> > last week about this and also refreshed my memory on the license of
> > fedora-logos. The conclusion was that the person asking the question
> > should comply with all the requirements that apply to use of the
> > Fedora Remix secondary mark
> > (https://docs.fedoraproject.org/en-US/legal/trademarks/#_distributing_combinations_of_fedora_software_with_non_fedora_or_modified_fedora_software)
> >
> > BTW I think that part of the Fedora trademark guidelines is somewhat
> > confusing because it doesn't speak to situations where one is creating
> > something that would qualify as a 'remix' but doesn't use the
> > secondary mark.
> >
> > Richard
> >
> > On Wed, Aug 2, 2023 at 2:09 PM Richard Fontana  wrote:
> > >
> > > On Wed, Aug 2, 2023 at 10:14 AM Matthew Miller  
> > > wrote:
> > > >
> > > > https://discussion.fedoraproject.org/t/does-distributing-a-kickstart-file-containing-non-free-repositories-violate-fedora-licensing-guidelines/86697
> > >
> > > Question is: "I have a kickstart file that uses rpmfusion non-free
> > > repos in the %post section to install Nvidia drivers. I do not remove
> > > Fedora branding packages in the kickstart file. Would I be in
> > > violation of Fedora’s Licensing Guidelines if I were to publish this
> > > kickstart file on my blog or in a Gist on GitHub? Or do the licensing
> > > guidelines only apply to installation media like an ISO?
> > >
> > > Also, if it is in violation, would it then be acceptable if I just
> > > removed the Fedora branding packages in the kickstart file?"
> > >
> > > For a definitive answer this should probably be run by Red Hat's
> > > trademark counsel, but my thought is that merely publishing such a
> > > kickstart file on a blog or Github gist would not require trademark
> > > permission. But if it's part of some larger effort to create and
> > > distribute a Fedora derivative, the requirements relating to branding
> > > of Fedora remixes should be followed.
> > >
> > > Richard
> >
>
> --
> Matthew Miller
> 
> Fedora Project Leader
>
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: kickstart files and trademark licensing question on Ask Fedora

[Richard Fontana]

I had a discussion with Kristin Borths (Red Hat's trademark lawyer)
last week about this and also refreshed my memory on the license of
fedora-logos. The conclusion was that the person asking the question
should comply with all the requirements that apply to use of the
Fedora Remix secondary mark
(https://docs.fedoraproject.org/en-US/legal/trademarks/#_distributing_combinations_of_fedora_software_with_non_fedora_or_modified_fedora_software)

BTW I think that part of the Fedora trademark guidelines is somewhat
confusing because it doesn't speak to situations where one is creating
something that would qualify as a 'remix' but doesn't use the
secondary mark.

Richard

On Wed, Aug 2, 2023 at 2:09 PM Richard Fontana  wrote:
>
> On Wed, Aug 2, 2023 at 10:14 AM Matthew Miller  
> wrote:
> >
> > https://discussion.fedoraproject.org/t/does-distributing-a-kickstart-file-containing-non-free-repositories-violate-fedora-licensing-guidelines/86697
>
> Question is: "I have a kickstart file that uses rpmfusion non-free
> repos in the %post section to install Nvidia drivers. I do not remove
> Fedora branding packages in the kickstart file. Would I be in
> violation of Fedora’s Licensing Guidelines if I were to publish this
> kickstart file on my blog or in a Gist on GitHub? Or do the licensing
> guidelines only apply to installation media like an ISO?
>
> Also, if it is in violation, would it then be acceptable if I just
> removed the Fedora branding packages in the kickstart file?"
>
> For a definitive answer this should probably be run by Red Hat's
> trademark counsel, but my thought is that merely publishing such a
> kickstart file on a blog or Github gist would not require trademark
> permission. But if it's part of some larger effort to create and
> distribute a Fedora derivative, the requirements relating to branding
> of Fedora remixes should be followed.
>
> Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: relaxng-datatype license

[Richard Fontana]

See: https://github.com/java-schema-utilities/relaxng-datatype-java/pull/4

On Sat, Aug 5, 2023 at 1:16 PM Richard Fontana  wrote:
>
> On Fri, Aug 4, 2023 at 2:32 PM Richard Fontana  wrote:
> >
> > On Fri, Aug 4, 2023 at 9:20 AM Marián Konček  wrote:
> > >
> > > It looks like this project
> > > (https://github.com/java-schema-utilities/relaxng-datatype-java) will
> > > need to be added to Fedora as a part of jaxb 4.0.2 -> 4.0.3 update.
> > >
> > > The sources of this package have already been bundled and differently
> > > namespaced part of jaxb (see
> > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=35187399) and present
> > > in Fedora. The jaxb project decided to unbundle them and depend on the
> > > upstream relaxng.
> > >
> > > The upstream relaxng has no LICENSE but from other sources it is
> > > more-less clear that it should be BSD:
> > > * https://relaxng.org/
> > > * https://sourceforge.net/projects/relaxng/
> > > * comment from Richard Fontana in open Issues in GitHub
> > > (https://github.com/java-schema-utilities/relaxng-datatype-java/issues/1)
> > >
> > > Nevertheless I would need to be completely sure that I can declare the
> > > package as being BSD-4-Clause, if I wanted to add it to Fedora.
> > >
> > > Can I get an official statement from Fedora legal team regarding
> > > acceptability of this package?
> >
> > I think I may have been wrong in ~2017 (I have no recollection of
> > making that comment). It will require a little research to figure out
> > what the license of that relaxng code is, if indeed there ever was any
> > explicit license.
>
> Okay, I was probably basically not wrong, but I may have been looking
> in the wrong place. it appears that these files:
> https://github.com/java-schema-utilities/relaxng-datatype-java/tree/master/src/main/java/org/relaxng/datatype
> are identical to the files in the zip file available here:
> https://sourceforge.net/projects/relaxng/files/datatype%20%28java%29/2001_10_11/relaxngDatatype.java.zip/download
> at src/org/relaxng/datatype
>
> That zip file also contained a license file,
> ThaiOpenSourceCenter-copying.txt, the contents of which are a match to
> SPDX `BSD-3-Clause`.
>
> So Marián Konček the thing to do here is (a) use `BSD-3-Clause` to
> represent the license of those files in
> https://github.com/java-schema-utilities/relaxng-datatype-java and (b)
> make sure the Fedora package corrects the upstream error in omitting
> the license file by including the ThaiOpenSourceCenter-copying.txt
> file contents, i.e.:
>
> Copyright (c) 2001, Thai Open Source Software Center Ltd
> All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are
> met:
>
> Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer.
>
> Redistributions in binary form must reproduce the above copyright
> notice, this list of conditions and the following disclaimer in
> the documentation and/or other materials provided with the
> distribution.
>
> Neither the name of the Thai Open Source Software Center Ltd nor
> the names of its contributors may be used to endorse or promote
> products derived from this software without specific prior written
> permission.
>
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
> CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
> PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: relaxng-datatype license

[Richard Fontana]

On Fri, Aug 4, 2023 at 2:32 PM Richard Fontana  wrote:
>
> On Fri, Aug 4, 2023 at 9:20 AM Marián Konček  wrote:
> >
> > It looks like this project
> > (https://github.com/java-schema-utilities/relaxng-datatype-java) will
> > need to be added to Fedora as a part of jaxb 4.0.2 -> 4.0.3 update.
> >
> > The sources of this package have already been bundled and differently
> > namespaced part of jaxb (see
> > https://koji.fedoraproject.org/koji/rpminfo?rpmID=35187399) and present
> > in Fedora. The jaxb project decided to unbundle them and depend on the
> > upstream relaxng.
> >
> > The upstream relaxng has no LICENSE but from other sources it is
> > more-less clear that it should be BSD:
> > * https://relaxng.org/
> > * https://sourceforge.net/projects/relaxng/
> > * comment from Richard Fontana in open Issues in GitHub
> > (https://github.com/java-schema-utilities/relaxng-datatype-java/issues/1)
> >
> > Nevertheless I would need to be completely sure that I can declare the
> > package as being BSD-4-Clause, if I wanted to add it to Fedora.
> >
> > Can I get an official statement from Fedora legal team regarding
> > acceptability of this package?
>
> I think I may have been wrong in ~2017 (I have no recollection of
> making that comment). It will require a little research to figure out
> what the license of that relaxng code is, if indeed there ever was any
> explicit license.

Okay, I was probably basically not wrong, but I may have been looking
in the wrong place. it appears that these files:
https://github.com/java-schema-utilities/relaxng-datatype-java/tree/master/src/main/java/org/relaxng/datatype
are identical to the files in the zip file available here:
https://sourceforge.net/projects/relaxng/files/datatype%20%28java%29/2001_10_11/relaxngDatatype.java.zip/download
at src/org/relaxng/datatype

That zip file also contained a license file,
ThaiOpenSourceCenter-copying.txt, the contents of which are a match to
SPDX `BSD-3-Clause`.

So Marián Konček the thing to do here is (a) use `BSD-3-Clause` to
represent the license of those files in
https://github.com/java-schema-utilities/relaxng-datatype-java and (b)
make sure the Fedora package corrects the upstream error in omitting
the license file by including the ThaiOpenSourceCenter-copying.txt
file contents, i.e.:

Copyright (c) 2001, Thai Open Source Software Center Ltd
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.

Neither the name of the Thai Open Source Software Center Ltd nor
the names of its contributors may be used to endorse or promote
products derived from this software without specific prior written
permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: relaxng-datatype license

[Richard Fontana]

On Fri, Aug 4, 2023 at 9:20 AM Marián Konček  wrote:
>
> It looks like this project
> (https://github.com/java-schema-utilities/relaxng-datatype-java) will
> need to be added to Fedora as a part of jaxb 4.0.2 -> 4.0.3 update.
>
> The sources of this package have already been bundled and differently
> namespaced part of jaxb (see
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=35187399) and present
> in Fedora. The jaxb project decided to unbundle them and depend on the
> upstream relaxng.
>
> The upstream relaxng has no LICENSE but from other sources it is
> more-less clear that it should be BSD:
> * https://relaxng.org/
> * https://sourceforge.net/projects/relaxng/
> * comment from Richard Fontana in open Issues in GitHub
> (https://github.com/java-schema-utilities/relaxng-datatype-java/issues/1)
>
> Nevertheless I would need to be completely sure that I can declare the
> package as being BSD-4-Clause, if I wanted to add it to Fedora.
>
> Can I get an official statement from Fedora legal team regarding
> acceptability of this package?

I think I may have been wrong in ~2017 (I have no recollection of
making that comment). It will require a little research to figure out
what the license of that relaxng code is, if indeed there ever was any
explicit license.

Richard
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue