On 8/31/23 1:59 AM, Vít Ondruch wrote:
Dne 30. 08. 23 v 19:07 Fabio Valentini napsal(a):
On Thu, Aug 24, 2023 at 8:52 PM Richard Fontana <rfontana@xxxxxxxxxx>
wrote:
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.
While I can understand the 'aesthetic distaste" for complex license
expressions, they reflect the reality, which is that software licensing
is complex. I'm not sure complex is even the right word - it's extensive
might be a better way to put it. We always knew there were many
variations of open source licenses out there (now I sound like Richard!)
- we are merely reflecting that reality.
I would hope we can get past distastes or complaints or psychological
desires that go against the given reality :)
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.
They do kind of replace the previous system, but I think we have
articulated those categories more explicitly and are capturing the text
so someone can "check" that if they so desire.
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.
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").
I would say that dropping any information about what we actually found
is not only sort of making an analysis, it also creates a potential
"mismatch" with what is reported and what is there, and that can then
undermine the value of what we report to begin as it leaves a downstream
recipient wondering, 'what else did they leave out?'
As with abandoning the "license of the binary" rule, this would
seemingly be a major departure from the principles established under
the Callaway system.
I think keeping the distinction between contents of the upstream
sources and contents of the packages we distribute is worthwhile. It's
one way to make the License information more meaningful for actual
users. 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).
I concur with this paragraph
100% agree. What is distributed is key in terms of compliance for almost
all open source licenses. If you hire an auditor to help you determine
what open source licenses are present in your given code base and that
you need to comply with - that process will begin with a scan of the
source code and then an analysis from there as to what is actually
distributed, which usually involves a conversation with the engineers
involved in creating the code base.
Vít
Fabio
_______________________________________________
legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
