On 5/11/23 7:22 AM, Warner Losh wrote:
On Thu, May 11, 2023, 7:07 AM Steve Winslow <swins...@gmail.com> wrote:
Thanks all for the thoughts and conversation on this topic over
the past few days. Would love to continue to see others’ thoughts
on this!
A few comments from me:
Trying to break this into options — I think the following are
among the possible approaches here (I imagine there are others):
1. *Current state*: No special treatment for “public domain”
statements. A few specific texts might be on the license list
(e.g. SQLite blessing
<https://spdx.org/licenses/blessing.html>; libselinux-1.0
<https://spdx.org/licenses/libselinux-1.0.html>). But mostly
it’s left to users to define LicenseRef-’s for either
individual texts or a collective
“LicenseRef-Fedora-Public-Domain” as Jilayne described.
2. *Add lots of individual texts to the License List*: Add
separate identifiers to the License List for each variation of
ways to say “this is in the public domain” from the list
Jilayne shared, and from other future similar submissions.
3. *Add a single “Public-Domain” identifier to the License
List*: Create one entry on the License List representing the
category of “this is in the public domain” statements.
3(A): …and, don’t associate any particular text with it
3(B): …or, associate a collection of all of the known texts
from Jilayne’s list with that one identifier
4. *Add a single “PUBLIC-DOMAIN” identifier to the SPDX
License Expression syntax*: Instead of putting a group ID on
the license list, define one in the SPDX license expression
syntax (and the underlying data model). This is similar to how
NONE and NOASSERTION are specially defined in the spec rather
than on the License List.
So, 3(A) and 4 seem effectively the same to me, but adding the
identifier in a different place of the spec?
Among these options, personally I am leaning towards #4 (I can be
convinced otherwise):
* I think that there is interest in the broader SPDX community
in having a collective identifier for “this is in the public
domain” statements which the current state in #1 is not meeting.
* #2 looks like a long road towards adding tons of texts with
minor variations and quibbling over which ones are
sufficiently different to warrant separate identifiers.
* #3 breaks the current assumption with the License List that an
identifier corresponds to a particular license text (applying
matching and replaceable text variations, of course). 3(B)
sort of solves this, but I expect would require substantial
changes to data schemas, tooling, and downstream assumptions
about how to use the License List.
it does break it, but having a specific group of texts for which the
identifier applies gives it a definitive definition which is in keeping
with the point of the SPDX License List (or at least that's my thinking
right now).
In particular, I’d also highlight that the availability of a
general “PUBLIC-DOMAIN” identifier via #4 would /not/ involve SPDX
taking any position on the meaning, implication, or scope of what
“PUBLIC-DOMAIN” means for a user of code; or which specific text
should be tagged with this identifier. By having it as a category
identifier (#4 rather than #3), it’s left to tools and humans to
decide which statements should be tagged as such. Tools such as
ScanCode and other downstream resources like Fedora’s list might
provide recommendations.
Having tools or human decide what statements should be tagged as such,
is part of the reason we haven't done this before.
And ultimately a consumer of an SPDX tag or document with a
“PUBLIC-DOMAIN” identifier would decide to what extent they choose
to rely upon it — just like they decide to what extent they rely
on short-form identifiers in source code or licenses stated in
SPDX Documents.
That's a good point, but it still feels WAY more smushy than trusting
someone to use an SPDX id for a specific license correctly.
If a user or organization decides that they don’t want to rely on
a simple “PUBLIC-DOMAIN” tag and they want to separately track
every single variant, in that case they can assign LicenseRef-’s
for each one. If someone is concerned about differing legal
outcomes depending on the particular wording, the applicable
jurisdiction, or anything else, they can continue to track them
separately.
that's a lot of varied approach, though?
Happy to hear others’ thoughts and anyone who wants to advocate
for one of the other options — or add one that I haven’t thought
of here.
So tag -> license with PUBLIC-DOMAIN is easy: no license needed so no
obligations. But text-> tag is impossible without a database, which
means something more is needed for that aspect of things because the
matching guidelines can't apply. I'm also not sure how a supply chain
chases back a BOM that has PUBLIC-DOMAIN in it to make sure the
original dedication is sufficient for their jurisdiction. So I'm not
sure how each organization deciding something different would work in
practice. That is, unless I've missed something in #4's description.
agree with Warner and Philippe's later comment about losing traceability
Jilayne
On May 8, 2023, at 11:34 PM, J Lovejoy <opensou...@jilayne.com>
wrote:
Hi SPDX-legal
Some time ago, I raised the issue of the possibility of finding a
proliferation of "public domain "dedication" texts in the course
of Fedora reviewing package license info to adopt SPDX ids.
Please see
https://lists.spdx.org/g/Spdx-legal/topic/93048752#3202 for the
background
Fedora has been "collecting" such texts here
https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/public-domain-text.txt
and using a specific LicenseRef-Fedora-Public-Domain as a sort of
placeholder SPDX id.
The idea being, no assessment of how many of these types of
dedications exist has been collected in one place in order for
the SPDX-legal community to assess.
I estimate that Fedora has collected about 48 variations of
public domain statements that are not specifically identified on
the SPDX License List. I'm going to assume many of these
packages also show up in other major distros.
I'd like to raise the conversation as to:
1) Should each unique entry be added to the SPDX License List as
a standalone entry (like normal, in that one SPDX license id
represents a specific, identifiable license/set of text)?
2) Should SPDX consider a different approach by defining one SPDX
id to represent any one of a collection of specifically
identified and vetted texts?
I'd love to hear your yes or no answer to these questions and why
you answered as such :)
Also see for background:
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_updating_existing_packages_callaway_short_name_categories
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_public_domain
We likely won't have time to discuss this on Thursday's call, but
I wanted to start the discussion here and perhaps we can dedicate
some time at an upcoming meeting.
Thanks,
Jilayne
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3398): https://lists.spdx.org/g/Spdx-legal/message/3398
Mute This Topic: https://lists.spdx.org/mt/98776908/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe:
https://lists.spdx.org/g/Spdx-legal/leave/2655900/21656/2011363115/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
