public domain dedications proliferation
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
and
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
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
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.
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
and
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
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
-- Mike
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.SteveOn Mon, Aug 15, 2022 at 7:15 PM J Lovejoy <opensource@...> 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
and
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
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
On Aug 15, 2022, at 7:40 PM, Michael Dolan <mdolan@...> 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? 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 DedicationB) Identifier: PDGDC) 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 possibleG) Full text would be "Public domain" - which seems to encompass all the examples here. 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 <swinslow@...> 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.SteveOn Mon, Aug 15, 2022 at 7:15 PM J Lovejoy <opensource@...> 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
and
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
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
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
and
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_callaway_short_name_categories
(see section on "public domain")
Yocto Project ran into this in a single case in our core layer for a
single file which was listed as "PD". This was the one source file we
couldn't therefore put an SPDX license identifier on.
After a bit of thought we decided that "Public Domain" allowed us to
license the file under a license the rest of the code was under (MIT)
so we adjusted it accordingly.
It avoided us having to say YP was very slightly under public domain
and keeps things slightly simpler.
https://git.yoctoproject.org/poky/commit/?id=21c3f09880332bf0723952c6e1ba4fcbbf4cb1cc
It doesn't directly help but perhaps worth keeping in mind that PD has
some interesting properties.
Cheers,
Richard
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) - 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!JilayneOn Aug 15, 2022, at 7:40 PM, Michael Dolan <mdolan@...> 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? 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 DedicationB) Identifier: PDGDC) 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 possibleG) Full text would be "Public domain" - which seems to encompass all the examples here. 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 <swinslow@...> 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.SteveOn Mon, Aug 15, 2022 at 7:15 PM J Lovejoy <opensource@...> 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
and
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
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
and license compliance in (most) European countries.
Please note that in many countries there is no "public domain" in the
field of software since expiration of the term of protection still needs
a few decades and there is no waiver of copyrights possible.
Furthermore, the public domain of US government works is limited to the
territory of the US but does not mean that you are permitted to use the
software abroad (typical example:
https://github.com/ncbi/ngs/blob/master/LICENSE#L8).
Therefore, it is helpful information whether the PD is based on a
goverment work or a "Public Domain Generic Dedication". The latter can
be interpreted as an unlimited license.
There are typical examples for such a dedication:
- https://sqlite.org/copyright.html ("All of the code and documentation
in SQLite has been dedicated to the public domain by the authors.")
- https://www.antlr2.org/license.html ("We reserve no legal rights to
the ANTLR--it is fully in the public domain. ...In countries where the
Public Domain status of the work may not be valid, the author grants a
copyright licence to the general public to deal in the work without
restriction and permission to sublicence derivates under the terms of
any (OSI approved) Open Source licence.")
- https://github.com/thoni56/gopt/blob/master/gopt.c
-
https://github.com/mjosaarinen/brutus/blob/master/crypto_aead/shellaes128v2d6n64/ref/aes.c
("This code is hereby placed in the public domain.")
-
https://github.com/jquerytools/jquerytools/blob/master/src/tabs/tabs.js
("NO COPYRIGHTS OR LICENSES. DO WHAT YOU LIKE.")
Of course, there are unclear cases:
- https://github.com/douglascrockford/JSON-js/blob/master/json2.js
- https://imapsync.lamiral.info/NOLIMIT
- https://github.com/usnistgov/jsip/blob/master/README#L122
But I think it is worth to cover the typical cases for such a dedication.
Best,
Till
Am 16.08.22 um 03:40 schrieb Michael Dolan:
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 <swinslow@...
<mailto:swinslow@...>> 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 <opensource@...
<mailto:opensource@...>> 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
<phk@...> wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
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
and
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
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
There is an obligation in there (“as long as you retain this notice”) so it really is a license not a PD dedication (if something is PD, it comes with no obligations).
Plus, beerware is already SPDXed as a license: https://spdx.org/licenses/Beerware.html
Sent: Tuesday, August 16, 2022 8:58 AM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <Spdx-legal@...>
Subject: Re: public domain dedications proliferation
On a related question, there's several licenses that are close to the public domain. Eg:
"THE BEER-WARE LICENSE" (Revision 42):
<phk@...> wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
which, apart from the markup issues being tied to a specific author, is very close to the public domain.... unless you desire to but phk a beer, and he wants one when you offer... but if he'd dedicated it to the public domain and I wanted to buy him a beer the end results would be identical. Likewise if I didn't want to buy him a beer in both cases. This is a current license in the SPDX list, however. And I think that's proper because the additional term "retain notice" makes it a license to use with mild conditions, rather than a repudiation of ownership.
A number of posters raise the points about EU law differing enough from US law that public domain creates difficulties, which people have worked around with additional words in different ways.
So, what separates those workarounds from the above beer-ware license, apart from the lack of the phrase 'public domain'? Is that the defining characteristic? Or is there some other touchstone to separate the vague "sure, whatever" from the "I disclaim ownership" from the "I disclaim ownership, but if I can't do that and still own the damn thing, here's the deal"? We can assume a large disparity in the care that these dedications are drafted, and as such we should expect a continuum of actual grants when all of them basically wanted people to do whatever with it.
Warner
On Mon, Aug 15, 2022 at 5:15 PM J Lovejoy <opensource@...> 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
and
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
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
There is an obligation in there (“as long as you retain this notice”) so it really is a license not a PD dedication (if something is PD, it comes with no obligations).
Plus, beerware is already SPDXed as a license: https://spdx.org/licenses/Beerware.html
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Warner Losh
Sent: Tuesday, August 16, 2022 8:58 AM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <Spdx-legal@...>
Subject: Re: public domain dedications proliferation
On a related question, there's several licenses that are close to the public domain. Eg:
"THE BEER-WARE LICENSE" (Revision 42):
<phk@...> wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
which, apart from the markup issues being tied to a specific author, is very close to the public domain.... unless you desire to but phk a beer, and he wants one when you offer... but if he'd dedicated it to the public domain and I wanted to buy him a beer the end results would be identical. Likewise if I didn't want to buy him a beer in both cases. This is a current license in the SPDX list, however. And I think that's proper because the additional term "retain notice" makes it a license to use with mild conditions, rather than a repudiation of ownership.
A number of posters raise the points about EU law differing enough from US law that public domain creates difficulties, which people have worked around with additional words in different ways.
So, what separates those workarounds from the above beer-ware license, apart from the lack of the phrase 'public domain'? Is that the defining characteristic? Or is there some other touchstone to separate the vague "sure, whatever" from the "I disclaim ownership" from the "I disclaim ownership, but if I can't do that and still own the damn thing, here's the deal"? We can assume a large disparity in the care that these dedications are drafted, and as such we should expect a continuum of actual grants when all of them basically wanted people to do whatever with it.
Warner
On Mon, Aug 15, 2022 at 5:15 PM J Lovejoy <opensource@...> 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
and
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
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
I’m not sure SPDX makes qualitative assessments of licenses or statements (nor should it, since practically every license does have some degree of ambiguity).
So a PD dedication that is unquestionably valid in the US but not in other countries can still get a SPDX tag, I think. It’s up to the user to determine if that statement is effective for them.
I think CC0 is probably the best attempt to come up with a truly comprehensive PD dedication, but that requires including a backstop highly permissive license attached. Whether that (or things like it) ought to be classified as a ‘license’ or a ‘PD dedication’ is moderately interesting although I tend to think of it as both. But to me, anything that recites a permission, or which has obligations – however mild – and doesn’t say “public domain” is a license.
Sent: Tuesday, August 16, 2022 9:13 AM
To: McCoy Smith <mccoy@...>
Cc: J Lovejoy <opensource@...>; SPDX-legal <Spdx-legal@...>
Subject: Re: public domain dedications proliferation
I was using beerware as an example to ask the question: what separates it from PD, especially with the public domain dedications that try to work around EU law in different ways. Is it the grant of permission to copy? Is it the lack of any other terms and condition? So the PD except where can't do that where you can use any OSI license would fall on the 'needs SPDX id' and is outside of the data Jilayne was asking for, but a 'do whatever you want' would be in scope?
Warner
On Tue, Aug 16, 2022 at 10:01 AM McCoy Smith <mccoy@...> wrote:
There is an obligation in there (“as long as you retain this notice”) so it really is a license not a PD dedication (if something is PD, it comes with no obligations).
Plus, beerware is already SPDXed as a license: https://spdx.org/licenses/Beerware.html
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Warner Losh
Sent: Tuesday, August 16, 2022 8:58 AM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <Spdx-legal@...>
Subject: Re: public domain dedications proliferation
On a related question, there's several licenses that are close to the public domain. Eg:
"THE BEER-WARE LICENSE" (Revision 42):
<phk@...> wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
which, apart from the markup issues being tied to a specific author, is very close to the public domain.... unless you desire to but phk a beer, and he wants one when you offer... but if he'd dedicated it to the public domain and I wanted to buy him a beer the end results would be identical. Likewise if I didn't want to buy him a beer in both cases. This is a current license in the SPDX list, however. And I think that's proper because the additional term "retain notice" makes it a license to use with mild conditions, rather than a repudiation of ownership.
A number of posters raise the points about EU law differing enough from US law that public domain creates difficulties, which people have worked around with additional words in different ways.
So, what separates those workarounds from the above beer-ware license, apart from the lack of the phrase 'public domain'? Is that the defining characteristic? Or is there some other touchstone to separate the vague "sure, whatever" from the "I disclaim ownership" from the "I disclaim ownership, but if I can't do that and still own the damn thing, here's the deal"? We can assume a large disparity in the care that these dedications are drafted, and as such we should expect a continuum of actual grants when all of them basically wanted people to do whatever with it.
Warner
On Mon, Aug 15, 2022 at 5:15 PM J Lovejoy <opensource@...> 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
and
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
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
On Mon, 2022-08-15 at 17:15 -0600, J Lovejoy wrote: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 and https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_callaway_short_name_categories (see section on "public domain")Yocto Project ran into this in a single case in our core layer for a single file which was listed as "PD". This was the one source file we couldn't therefore put an SPDX license identifier on. After a bit of thought we decided that "Public Domain" allowed us to license the file under a license the rest of the code was under (MIT) so we adjusted it accordingly. It avoided us having to say YP was very slightly under public domain and keeps things slightly simpler. https://git.yoctoproject.org/poky/commit/?id=21c3f09880332bf0723952c6e1ba4fcbbf4cb1cc It doesn't directly help but perhaps worth keeping in mind that PD has some interesting properties. Cheers, Richard
You both raise some good points which has made me realized I should clarify this topic a bit:
First, yes, some "public domain dedications" or things that are similar-ish are already on the SPDX License List. As more of such things are found, there is no reason we couldn't simply keep adding them with their individual SPDX license ids, just like usual. See Steve's summary, as this would be what he describes in #4.
The reason I started with "public domain" is due to Fedora's category short name used in the package spec files for things that Fedora package maintainers have identified and then labeled as such. Because this is a sort of umbrella short name, there is no way to know what the text actually says. Maybe some of these are actually licenses in the sense that they contain conditions upon some grant under copyright. The only way to know is to collect that text.
Yes, SPDX does not make qualitative assessments of licenses or statements.
The issue/question here is: if there are many, many variations on the same kind of statement (I suppose it could purport to be public domain or maybe even something more akin to a permissive license) - should SPDX deviate from it's one id = one license text and come up with a way to capture a number of texts that could "match" and be represented to the same id?
At this point, I don't think we should answer that question, but I want to capture enough information (data) about the magnitude of what's out there in order to then discuss this.
Hope that helps,
Jilayne
I’m not sure SPDX makes qualitative assessments of licenses or statements (nor should it, since practically every license does have some degree of ambiguity).
So a PD dedication that is unquestionably valid in the US but not in other countries can still get a SPDX tag, I think. It’s up to the user to determine if that statement is effective for them.
I think CC0 is probably the best attempt to come up with a truly comprehensive PD dedication, but that requires including a backstop highly permissive license attached. Whether that (or things like it) ought to be classified as a ‘license’ or a ‘PD dedication’ is moderately interesting although I tend to think of it as both. But to me, anything that recites a permission, or which has obligations – however mild – and doesn’t say “public domain” is a license.
From: Warner Losh <imp@...>
Sent: Tuesday, August 16, 2022 9:13 AM
To: McCoy Smith <mccoy@...>
Cc: J Lovejoy <opensource@...>; SPDX-legal <Spdx-legal@...>
Subject: Re: public domain dedications proliferation
I was using beerware as an example to ask the question: what separates it from PD, especially with the public domain dedications that try to work around EU law in different ways. Is it the grant of permission to copy? Is it the lack of any other terms and condition? So the PD except where can't do that where you can use any OSI license would fall on the 'needs SPDX id' and is outside of the data Jilayne was asking for, but a 'do whatever you want' would be in scope?
Warner
On Tue, Aug 16, 2022 at 10:01 AM McCoy Smith <mccoy@...> wrote:
There is an obligation in there (“as long as you retain this notice”) so it really is a license not a PD dedication (if something is PD, it comes with no obligations).
Plus, beerware is already SPDXed as a license: https://spdx.org/licenses/Beerware.html
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Warner Losh
Sent: Tuesday, August 16, 2022 8:58 AM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <Spdx-legal@...>
Subject: Re: public domain dedications proliferation
On a related question, there's several licenses that are close to the public domain. Eg:
"THE BEER-WARE LICENSE" (Revision 42):
<phk@...> wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
which, apart from the markup issues being tied to a specific author, is very close to the public domain.... unless you desire to but phk a beer, and he wants one when you offer... but if he'd dedicated it to the public domain and I wanted to buy him a beer the end results would be identical. Likewise if I didn't want to buy him a beer in both cases. This is a current license in the SPDX list, however. And I think that's proper because the additional term "retain notice" makes it a license to use with mild conditions, rather than a repudiation of ownership.
A number of posters raise the points about EU law differing enough from US law that public domain creates difficulties, which people have worked around with additional words in different ways.
So, what separates those workarounds from the above beer-ware license, apart from the lack of the phrase 'public domain'? Is that the defining characteristic? Or is there some other touchstone to separate the vague "sure, whatever" from the "I disclaim ownership" from the "I disclaim ownership, but if I can't do that and still own the damn thing, here's the deal"? We can assume a large disparity in the care that these dedications are drafted, and as such we should expect a continuum of actual grants when all of them basically wanted people to do whatever with it.
Warner
On Mon, Aug 15, 2022 at 5:15 PM J Lovejoy <opensource@...> 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
and
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
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
I should have been more clear on what I needed input on ASAP - whichI think it would be useful to understand the split between three classes
was, a) what info would be helpful to collect (now) about any public
domain dedication text found in Fedora?
of things that I suspect SPDX will want to treat differently:
* A pure statement of public domain for the reasons spelled out in the
copyright law of some country, such as "this is a work product of the
United States government" or "the copyright on this work has expired"
(while no software, strictly speaking, probaby falls into the latter
category, data files within software projects may well do so). Those
will probably have to be broken down by country for the reasons stated
elsewhere in this thread. This is *not* for software where the author
wrote something under copyright and then attempted to relinquish that
copyright, but for things that fall within the public domain legal
definition (or at least the available information accompanying the
software asserts that it does).
* Software placed in the public domain (or at least attempted) by the
author without any other licensing statement. For example, the tz
time zone database: "This database is in the public domain."
* Software placed in the public domain with supporting legal wording as a
fallback for jurisdictions where that concept may not be legally
possible. For example, at one point the IETF suggested wording similar
to this:
The authors (on behalf of themselves and their employers) hereby
relinquish any claim to any copyright that they may have in this
work, whether granted under contract or by operation of law or
international treaty, and hereby commit to the public, at large, that
they shall not, at any time in the future, seek to enforce any
copyright in this work against any person or entity, or prevent any
person or entity from copying, publishing, distributing or creating
derivative works of this work.
There are numerous variations of this idea.
Separating these seems important from a cataloging standpoint. In
particular, I would argue that statements of the third form *are a
license* and should be tracked like any other license, because the wording
of the fallback provision may matter in some jurisdictions and should be
identified and merged using all the normal SPDX license tracking
infrastructure.
--
Russ Allbery (eagle@...) <https://www.eyrie.org/~eagle/>
Thanks Richard, that's interesting. I'm really surprised Yocto onlyThis was for OpenEmbedded-Core, there will be other issues in other
ran into one example of this kind of thing though!
layers which we'll no doubt hit as other they adopt the identifiers but
it at least let us resolve things for our core.
Cheers,
Richard
The points you make are very pertinent indeed. I think that statements
of the third type should probably be included in the SPDX License
List, as they are usually very distinctive and their wording may make
a difference to their legal interpretation.
If we were to add a Public-Domain identifier, strictly speaking I
believe it should only apply to the first type, where there can't be
'license text' because there is no copyright holder to license it!
However, I imagine there would be frequent misuse/abuse of this
identifier when something is genuinely public domain in one
jurisdiction but not all.
Best wishes,
Sebastian
"J Lovejoy" <opensource@...> writes:I should have been more clear on what I needed input on ASAP - whichI think it would be useful to understand the split between three classes
was, a) what info would be helpful to collect (now) about any public
domain dedication text found in Fedora?
of things that I suspect SPDX will want to treat differently:
* A pure statement of public domain for the reasons spelled out in the
copyright law of some country, such as "this is a work product of the
United States government" or "the copyright on this work has expired"
(while no software, strictly speaking, probaby falls into the latter
category, data files within software projects may well do so). Those
will probably have to be broken down by country for the reasons stated
elsewhere in this thread. This is *not* for software where the author
wrote something under copyright and then attempted to relinquish that
copyright, but for things that fall within the public domain legal
definition (or at least the available information accompanying the
software asserts that it does).
* Software placed in the public domain (or at least attempted) by the
author without any other licensing statement. For example, the tz
time zone database: "This database is in the public domain."
* Software placed in the public domain with supporting legal wording as a
fallback for jurisdictions where that concept may not be legally
possible. For example, at one point the IETF suggested wording similar
to this:
The authors (on behalf of themselves and their employers) hereby
relinquish any claim to any copyright that they may have in this
work, whether granted under contract or by operation of law or
international treaty, and hereby commit to the public, at large, that
they shall not, at any time in the future, seek to enforce any
copyright in this work against any person or entity, or prevent any
person or entity from copying, publishing, distributing or creating
derivative works of this work.
There are numerous variations of this idea.
Separating these seems important from a cataloging standpoint. In
particular, I would argue that statements of the third form *are a
license* and should be tracked like any other license, because the wording
of the fallback provision may matter in some jurisdictions and should be
identified and merged using all the normal SPDX license tracking
infrastructure.
--
Russ Allbery (eagle@...) <https://www.eyrie.org/~eagle/>
I think CC0 is probably the best attempt to come up with a truly comprehensiveIt's interesting that you mention CC0, as it has recently been decided that CC0
PD dedication, but that requires including a backstop highly permissive
license attached. Whether that (or things like it) ought to be classified as a
‘license’ or a ‘PD dedication’ is moderately interesting although I tend to
think of it as both. But to me, anything that recites a permission, or which
has obligations – however mild – and doesn’t say “public domain” is a license.
is no longer suitable for Fedora code packages due to its explicit non-grant of
patent licences. I imagine other distributions will follow suit eventually,
which might potentially leave a gap: for something as permissive as 0BSD but as
rigorous (regarding interpretation and patent licences) as the GPL.
Let me know if you fancy writing that with me, McCoy ;)
Best wishes,
Sebastian
-----Original Message-----I think it'd be better to have a CC0+Patent. I've raised that concept with them a couple of times, but they were too busy or didn't have the internal consensus to do something like that, although I tried again recently with their new General Counsel so there may be again hope they'd pick it up.
From: Sebastian Crane <seabass-labrax@...>
Sent: Wednesday, August 17, 2022 3:06 PM
To: Spdx-legal@...; 'Warner Losh' <imp@...>; McCoy
Smith <mccoy@...>
Subject: Re: public domain dedications proliferation
It's interesting that you mention CC0, as it has recently been decided that CC0
is no longer suitable for Fedora code packages due to its explicit non-grant of
patent licences. I imagine other distributions will follow suit eventually, which
might potentially leave a gap: for something as permissive as 0BSD but as
rigorous (regarding interpretation and patent licences) as the GPL.
As highly as I think of myself (as perhaps you Sebastian do of yourself), I kind of feel like if it's just two people on the internet putting something together it might not have as much traction as if a well-respected copyright freedom-respecting non-profit did it instead.
On Aug 17, 2022, at 4:22 PM, McCoy Smith <mccoy@...> wrote:really, McCoy, you are not going to suggest https://spdx.org/licenses/BSD-2-Clause-Patent.html ?!? Don’t be coy now… :)-----Original Message-----I think it'd be better to have a CC0+Patent. I've raised that concept with them a couple of times, but they were too busy or didn't have the internal consensus to do something like that, although I tried again recently with their new General Counsel so there may be again hope they'd pick it up.
From: Sebastian Crane <seabass-labrax@...>
Sent: Wednesday, August 17, 2022 3:06 PM
To: Spdx-legal@...; 'Warner Losh' <imp@...>; McCoy
Smith <mccoy@...>
Subject: Re: public domain dedications proliferation
It's interesting that you mention CC0, as it has recently been decided that CC0
is no longer suitable for Fedora code packages due to its explicit non-grant of
patent licences. I imagine other distributions will follow suit eventually, which
might potentially leave a gap: for something as permissive as 0BSD but as
rigorous (regarding interpretation and patent licences) as the GPL.
As highly as I think of myself (as perhaps you Sebastian do of yourself), I kind of feel like if it's just two people on the internet putting something together it might not have as much traction as if a well-respected copyright freedom-respecting non-profit did it instead.
(McCoy drafted that license, for those who are not aware.)
J.
For what it's worth, looks like someone tried to come up with something along these lines, and called it the Worldwide Public Domain Dedication https://wpdd.info/wpdd.htmlOn Aug 17, 2022, at 4:22 PM, McCoy Smith <mccoy@...> wrote:(regarding interpretation and patent licences) as the GPL.-----Original Message-----
From: Sebastian Crane <seabass-labrax@...>
Sent: Wednesday, August 17, 2022 3:06 PM
To: Spdx-legal@...; 'Warner Losh' <imp@...>; McCoy
Smith <mccoy@...>
Subject: Re: public domain dedications proliferation
It's interesting that you mention CC0, as it has recently been
decided that CC0 is no longer suitable for Fedora code packages due
to its explicit non-grant of patent licences. I imagine other
distributions will follow suit eventually, which might potentially
leave a gap: for something as permissive as 0BSD but as rigorousI think it'd be better to have a CC0+Patent. I've raised that concept withthem a couple of times, but they were too busy or didn't have the internal
consensus to do something like that, although I tried again recently with their
new General Counsel so there may be again hope they'd pick it up.kind of feel like if it's just two people on the internet putting something
As highly as I think of myself (as perhaps you Sebastian do of yourself), I
together it might not have as much traction as if a well-respected copyright
freedom-respecting non-profit did it instead.
Looks to be based on CC0, but with a patent dedication and patent license backstop.
Not sure if anyone has actually used it, and I suspect the patent dedication might cause some people heartburn, but there is something out there.
Whether it ought to go into the SPDX public domain list I'll leave as an exercise for the readers.