Re: LicenseRef-Fedora-SourceLicenses (Was: Re: SPDX Statistics - R.U.R. edition)
by Richard Fontana
On Thu, Jan 18, 2024 at 8:15 AM Vít Ondruch <vondruch(a)redhat.com> 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
3 months, 2 weeks
Re: LicenseRef-Fedora-SourceLicenses (Was: Re: SPDX Statistics - R.U.R. edition)
by Richard Fontana
On Thu, Jan 18, 2024 at 8:09 AM Vít Ondruch <vondruch(a)redhat.com> 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
3 months, 2 weeks
Re: LicenseRef-Fedora-SourceLicenses (Was: Re: SPDX Statistics - R.U.R. edition)
by Vít Ondruch
Dne 18. 01. 24 v 14:09 Vít Ondruch napsal(a):
>
> Dne 18. 01. 24 v 0:01 Richard Fontana napsal(a):
>> On Wed, Jan 17, 2024 at 5:47 PM Mark Wielaard <mark(a)klomp.org> 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.
>
>
> 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?
>
>
> Vít
>
>
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."
And that is the context where I hit the DocumentRef
Vít
>>
>> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to legal-leave(a)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
3 months, 2 weeks
Re: LicenseRef-Fedora-SourceLicenses (Was: Re: SPDX Statistics - R.U.R. edition)
by Vít Ondruch
Dne 18. 01. 24 v 0:01 Richard Fontana napsal(a):
> On Wed, Jan 17, 2024 at 5:47 PM Mark Wielaard <mark(a)klomp.org> 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.
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?
Vít
>
> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to legal-leave(a)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
3 months, 2 weeks
Re: IBM non-free patent notice (Was: Re: SPDX Statistics - R.U.R. edition)
by Dan Horák
On Wed, 17 Jan 2024 21:58:34 -0500
Richard Fontana <rfontana(a)redhat.com> wrote:
> On Wed, Jan 17, 2024 at 6:15 PM Mark Wielaard <mark(a)klomp.org> 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.
IBM is still contributing to glibc, although primarily for their
hardware support, not for the common parts in glibc.
Dan
>
> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to legal-leave(a)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
3 months, 2 weeks
Re: license-tag purpose/goal (Was: Re: SPDX Statistics - R.U.R. edition)
by Miroslav Suchý
Dne 18. 01. 24 v 5:23 Richard Fontana napsal(a):
> This all makes it sound like I'm a fan of SPDX so I hope people
> understand I'm not.
You made my day :)))
> Basically, SPDX is the worst license
> representation system we have
From the set made of one. That makes it worst and best at the same time. :)
Or I missed interresting system?
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
3 months, 2 weeks
Re: license-tag purpose/goal (Was: Re: SPDX Statistics - R.U.R. edition)
by Richard Fontana
On Wed, Jan 17, 2024 at 5:57 PM Mark Wielaard <mark(a)klomp.org> 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
approving and disapproving particular licenses, some of which would
never normally be used in a License tag. When we say a given license
is allowed, or not allowed, we have to define more or less precisely
what we mean by that license, and SPDX (for all its many faults)
provides the best system I know of for doing that.
Richard
3 months, 2 weeks
Re: IBM non-free patent notice (Was: Re: SPDX Statistics - R.U.R. edition)
by Richard Fontana
On Wed, Jan 17, 2024 at 6:15 PM Mark Wielaard <mark(a)klomp.org> 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
3 months, 2 weeks
Re: When can license notices be removed or not (Was: Re: SPDX Statistics - R.U.R. edition)
by Richard Fontana
On Wed, Jan 17, 2024 at 6:34 PM Mark Wielaard <mark(a)klomp.org> 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
3 months, 2 weeks
