Thanks for the quick responses, Steve and Mike! I should have been more clear on what I needed input on ASAP - which was, a) what info would be helpful to collect (now) about any public domain dedication text found in Fedora?
Which we could then used later to b) determine how to implement a way to better deal with potentially many variations on the same theme. I think you are both skipping to the ‘how to implement’ part, which I was also keeping in the back of my mind, as it somewhat informs what information would be helpful to collect now. I suppose I’m leaning towards exploring what Steve describes below as option #3 which I think is similar to what Mike is describing as well. In regards to the other ideas Steve provided, #2 has been discussed multiple times over the years and I still think the write-up we did to answer that question (when/if it came up again) still holds - see https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files_(DRAFT) <https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files_(DRAFT)> - having an identifier that is supposed to recognize a specific legal concept with no text to match to is prone to misinterpretation and dilution of the value of the identifier to begin with. Which is why I’m leaning towards thinking that a deviation from our 1:1 principle but defined as 1 identifier to a collection of texts that are documented (and thus go through a review cycle by SPDX-legal community) could be an interesting idea… But again, I think having some data to understand what this picture actually looks like is the place to start, hence see (a) above. Thanks! Jilayne > On Aug 15, 2022, at 7:40 PM, Michael Dolan <mdo...@linuxfoundation.org > <mailto:mdo...@linuxfoundation.org>> wrote: > > In addition to Steve's thoughts... I will respond quickly as that was the > request ... and likely miss issues. My only additional though is could we add > a generic public domain license reference to the license list and then keep a > list of discovered uses in the metadata > <https://github.com/spdx/license-list-XML/blob/master/DOCS/license-fields.md>? > It would break from the traditional identifier = 1 specific license text > model, but technically we do allow for variations in the headers already. > > A) Full Name: Public Domain Generic Dedication > B) Identifier: PDGD > C) Other web pages for this license: [insert example URLs where these generic > dedications show up] > D) Notes: Public domain dedications occur in varying texts and contexts. The > PDGD license identifier encompasses all texts dedicating unlicensed works to > the public domain. > E/F) Yes if on either list... unlikely... but possible > G) Full text would be "Public domain" - which seems to encompass all the > examples here > <https://sourcegraph.com/search?q=context:global+r:src.fedoraproject.org+file:.*%5C.spec%24+%5ELicense:%5Cs%2B.*public+domain+TIMEOUT:120s&patternType=regexp>. > There may be other public domain dedications/declarations we could include. > > I do realize its odd to suggest adding a (non-license) public domain > dedication to the License List - but... hey, you asked for fast :-) > -- Mike > > > > On Mon, Aug 15, 2022 at 8:28 PM Steve Winslow <swins...@gmail.com > <mailto:swins...@gmail.com>> wrote: > Hi Jilayne, since you asked for input ASAP, here are a few immediate gut > reactions :) > > I think getting the data of seeing a bunch of different ways that people said > "this code is released into the public domain" is _slightly_ useful, but not > very useful. My guess is that there's a ton of variations that are > substantively saying the same thing but doing so in a way that would be > extremely difficult to meaningfully capture into a few categories with regexs > / pattern matching. > > If the goal is really to find one or a few different > regular-expression-matchable phrases that would go on the license list in its > current form and format, then maybe that would be helpful data. But I guess > I'm skeptical that we would find those patterns in a way that fits the > current approach to license IDs on the license list, without ending up with a > hundred variations of basically the same thing. > > Maybe I'm jumping ahead to "what are the options?" before getting the data, > but it seems to me like there are basically 4 options for whether and how to > capture public domain statements: > > 1. No change: Don't add "this is in the public domain" statements to the > license list. People can use LicenseRef's if they want. > Pro: Maintains the current approach that the License List is for licenses > with specific text. > Con: Doesn't solve the problem people are having, with wanting to represent > public domain statements generally with a common identifier. > > 2. Add a category ID to the spec: Alongside NONE and NOASSERTION as values > defined in the SPDX spec, add PUBLIC-DOMAIN as another option defined in the > spec rather than on the license list. Unlike NONE and NOASSERTION, > PUBLIC-DOMAIN would presumably be useable in complex expressions (e.g. MIT > AND PUBLIC-DOMAIN). > Pro: Provides a general identifier for public domain statements. Also > maintains the current approach that the License List is for licenses with > specific text. > Con: We're frankly too late to get this in as a substantive change for the > SPDX 2.3 spec. > > 3. Add a category ID to the license list: Rather than changing the spec, add > a category ID for "Public-Domain" (or similar) to the License List. Modify > the license list schema somehow to indicate that this ID is meant to > represent the collection of texts stating that a work is in the public > domain, rather than one specific text. > Pro: Wouldn't be tied to a change to the spec. Would probably represent the > way that most human users tend to think about public domain statements. > Con: Breaks expectations about all other License List entries, that they are > tied to a particular text. Might also have implications for the SPDX spec > that aren't coming to mind at the moment. > > 4. Add each statement individually: Add Public-Domain-1, Public-Domain-2, ... > to the License List as separate entries, to capture every non-matching > representation that we run into to say "this is in the public domain". > Pro: Maintains the current approach that the License List is for licenses > with specific text. > Con: Get ready for 700 new Public Domain entries on the license list :) > Probably becomes unwieldy for humans to meaningfully make use of this. > > Definitely open to other options, but these are the ones that come to mind > offhand. (And the above is intentionally ignoring public domain dedications > that really do have a set standard text, such as CC-PDDC.) > > Personally, if we weren't about to have SPDX 2.3 released imminently, I'd > probably lean towards option 2. Given that it is about to be released, I > could be persuaded to consider option 3, though I suspect we would need > significant input from the tooling community as to whether this breaks too > many current expectations on their side. > > Steve > > On Mon, Aug 15, 2022 at 7:15 PM J Lovejoy <opensou...@jilayne.com > <mailto:opensou...@jilayne.com>> wrote: > Hi SPDX-legal, > > I have raised this a couple times in the past few months or so, but now that > it is more of a "ripe" topic, I wanted to get some input on preliminary ideas: > > Background: > Fedora has now officially adopted the use of SPDX ids in packages meta data > (specifically, the license field of the package spec file). Due to Fedora > historically using "category" short names for groups of similar licenses, we > suspect there may be a number of additions to the SPDX License List > needed. > > Public domain category: > Specifically, Fedora has used "public domain" for any public domain > dedication, without capturing the exact text. For Fedora package maintainers > who are keen to update the license info for their packages, we have given > this interim advice: > https://docs.fedoraproject.org/en-US/legal/license-field/#_public_domain > <https://docs.fedoraproject.org/en-US/legal/license-field/#_public_domain> > and > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_callaway_short_name_categories > > <https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_callaway_short_name_categories> > (see section on "public domain") > > SPDX approach: > The SPDX License List has always operated from the principle that an SPDX > license id represents a specific, identifiable license/set of text. This is > critical as part of our project goal of being both human and > machine-readable. > > However, if it turns out that there are a large number of slight variations > of text that mean the same thing (e.g., a simply one line statement of public > domain dedication), then perhaps SPDX might consider a slightly different > approach? > > But, in order to even consider this, we'd need data. > > Idea for going forward: > As Fedora package maintainers find these texts that had been marked > generically as "public domain" - what if we asked them to copy the actual > text of what they found and maybe a link to where they found it (or some > other such pointer) in a simply formatted file in the Fedora > license-list-data repo? > See https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/54 > <https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/54> > > This would be at least a beginning of collecting this data that SPDX-legal > could then review in a more bulk fashion in order to consider the above > potential approach. > > If so, what other info besides the text itself should be collected and how > can it be most easily formatted to enable easy consumption later? > > For example, it could be something like this: > > === > package = Foo > text = This is released into the public domain. > source = <url to file or other such pointer> > === > > I wouldn't want to be more than a few pieces of information. There is also > always the ability to search on the short name "public domain" or the > interiem SPDX id of "LicenseRef-Fedora-Public-Domain", but might as well > start collecting info if package maintainers are looking as well. > > Thoughts? (need input ASAP :) > > thanks, > Jilayne > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3205): https://lists.spdx.org/g/Spdx-legal/message/3205 Mute This Topic: https://lists.spdx.org/mt/93048752/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
