Date   

Re: public domain dedications proliferation

Sebastian Crane
 

On Tue, Aug 16, 2022 at 09:25:38AM -0700, McCoy Smith wrote:

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.
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.

Let me know if you fancy writing that with me, McCoy ;)

Best wishes,

Sebastian


Re: public domain dedications proliferation

Sebastian Crane
 

Dear Russ,

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

On Tue, Aug 16, 2022 at 10:38:57AM -0700, Russ Allbery wrote:
"J Lovejoy" <opensource@...> writes:

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?
I think it would be useful to understand the split between three classes
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/>





Re: public domain dedications proliferation

Richard Purdie
 

On Tue, 2022-08-16 at 11:08 -0600, J Lovejoy wrote:
 Thanks Richard, that's interesting. I'm really surprised Yocto only
ran into one example of this kind of thing though!
This was for OpenEmbedded-Core, there will be other issues in other
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


Re: public domain dedications proliferation

Russ Allbery
 

"J Lovejoy" <opensource@...> writes:

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?
I think it would be useful to understand the split between three classes
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/>


Re: public domain dedications proliferation

J Lovejoy
 

Hi Warner, McCoy,

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

On 8/16/22 10:25 AM, McCoy Smith wrote:

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




Re: public domain dedications proliferation

J Lovejoy
 

Thanks Richard, that's interesting. I'm really surprised Yocto only ran into one example of this kind of thing though!

On 8/16/22 4:01 AM, Richard Purdie wrote:

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



Re: public domain dedications proliferation

McCoy Smith
 

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



Re: public domain dedications proliferation

Warner Losh
 

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




Re: public domain dedications proliferation

McCoy Smith
 

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




Re: public domain dedications proliferation

Warner Losh
 

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





Re: public domain dedications proliferation

Till Jaeger
 

I support the idea of Mike. In particular, this would help for both use
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





Re: public domain dedications proliferation

Steve Winslow
 

Thanks for the clarification Jilayne!

If the idea is to collect information about the different forms used to say "this is in the public domain" with an eye towards option 3, then yes, I think your proposed data structure would be all we'd really need at the exploration stage.

Primarily it would be (1) a copy of the text used by the "licensor", and (2) a URL so we can go see for ourselves in context. Package name is helpful but I think it's primarily the first two data points that are most relevant.

After that we can review the set of examples collected, and see if it makes sense to have a single "Public-domain" identifier or multiple categories. My guess is that it'll just be the former but we can see what makes sense based on the data.

Steve

On Tue, Aug 16, 2022 at 12:29 AM J Lovejoy <opensource@...> wrote:
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!
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 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. 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.

Steve

On 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










Re: public domain dedications proliferation

Richard Purdie
 

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


Re: public domain dedications proliferation

J Lovejoy
 

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!
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 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. 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.

Steve

On 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










Re: public domain dedications proliferation

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? 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. 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.

Steve

On 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





Re: public domain dedications proliferation

Steve Winslow
 

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@...> 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





public domain dedications proliferation

J Lovejoy
 

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





3.18 License List release

Steve Winslow
 

Hello all,

The version 3.18 release of the license list is now tagged and live at https://spdx.org/licenses.

10 new licenses / exceptions were added to the list:
  • CC-BY-3.0-IGO
  • GStreamer-exception-2005
  • GStreamer-exception-2008
  • LZMA-SDK-9.11-to-9.20
  • LZMA-SDK-9.22
  • MS-LPL
  • Minpack
  • mpi-permissive
  • NICTA-1.0
  • Python-2.0.1
The release also included updates to various documentation, adjustments to markup for various licenses and other minor changes.

More details can be found in the release notes at https://github.com/spdx/license-list-XML/releases/tag/v3.18.

Thank you as always to the participants in the SPDX Legal community and license request submitters who contributed to this release.

Steve


meeting at top of the hour

J Lovejoy
 

Hi all,

Just a last minute reminder of our regular call today at the top of the hour.

As mentioned previously, for the next release cycle (through end of Sept) we are going to focus on updating and improving documentation related to the SPDX License List. Please have a look at the issues labeled “documentation” - we’ll discuss whether there is anything else we should add to our list on the call and start divvying up tasks!

https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.19+%28documentation%29%22

Thanks,
Jilayne


Idea: SPDX-DCO-File-License-Identifier

Richard Fontana
 

I've thought some more about certain unintended problems some of us
were previously discussing regarding the use of
SPDX-License-Identifier: in source files. In particular it's occurred
to me that the practice is in tension with the use of the Developer
Certificate of Origin. This is significant given that Linux is the
most important project to have adopted both the DCO and the use of
SPDX-License-Identifier.

Somewhat problematically, the DCO makes reference to a license of a
*file* in its certification: "The contribution was created in whole or
in part by me and I have the right to submit it under the open source
license indicated in the file." Most open source projects (including
possibly most DCO-using open source projects, a tiny minority of open
source projects) do not use explicit licensing of source files, a
practice I understand SPDX at least implicitly disapproves of. In
typical situations, the use of SPDX-License-Identifier: has the nice
feature of clarifying what the "open source license indicated in the
file" is in a standard way.

But for any source file that properly uses SPDX-License-Identifier and
is based on multiply-licensed code (for example, a file properly
reflecting contributions under both GPLv2 and the 3-clause BSD
license), the DCO-related benefit goes away. I don't know if there is
an example like this in the kernel, but suppose the kernel had such a
source file, saying "SPDX-License-Identifier: GPL-2.0-only AND
BSD-3-Clause". What is the "license indicated in the file" for
purposes of the DCO? Prior to the use of SPDX-License-Identifier, the
variously-worded GPL headers might have made it sufficiently clear
that the license for purposes of the DCO is GPLv2 (GPL-2.0-only). Or
the situation was ambiguous but you could then rely on the note from
Linus Torvalds in the kernel COPYING file (or wherever that lives
now). Now, it appears that a DCO-certifying contributor to a file that
already has (based on an analysis of past-incorporated license
notices) "SPDX-License-Identifier: GPL-2.0-only AND BSD-3-Clause" is
certifying that they have the right to submit it under the stated
composite license. It's not even clear this is non-nonsensical -- how
can a single isolable contribution by one person be licensed under two
different open source licenses in a conjunctive, not disjunctive,
sense? (As I said previously, the snippet construct is probably not
going to be practical to use in most cases and I'm not sure it solves
the problem anyway.)

So I am wondering if it would be a good solution to introduce an
additional construct like "SPDX-DCO-File-License-Identifier" for those
cases involving source files where SPDX-License-Identifier: would
imply a licensing policy at odds with the actual policy of the
project. For example, you could have a source file with the following
header:

SPDX-License-Identifier: GPL-2.0-only AND BSD-3-Clause
SPDX-DCO-File-License-Identifier: GPL-2.0-only

Note this is different from the issue that McCoy was asking about in
an earlier thread, but I think it is somewhat related.

The issue of course is not really limited to projects using the DCO,
but rather any project that informally or otherwise adopts an
"inbound=outbound" approach to licensing of contributions, which is
the vast majority of open source projects (so maybe a solution
shouldn't seem to be DCO-specific). A concern I have is that the use
of SPDX-License-Identifier: may be unintentionally optimized for the
use of that minority of projects that use asymmetric contributor
license agreements to handle licensing in of contributions.

Richard

On Mon, Jul 18, 2022 at 8:14 PM Richard Fontana <rfontana@...> wrote:

I feel like what some projects might find useful is something like:

SPDX-License-Identifier-Concluding-What's-Been-Contributed-As-Of-Some-Past-Time:
SPDX-License-Identifier-Of-What's-Been-Contributed-After-That-Past-Time-And-Default-License-of-Future-Contributions:

since these might point to different licenses. The snippet construct
can possibly express this adequately in some cases but I think
reliable identification of a snippet will normally be impractical.

Richard

On Sun, Jul 17, 2022 at 3:18 PM McCoy Smith <mccoy@...> wrote:

At the risk of sounding like I’m hijacking this to re-raise my prior issue:
If AND is the operator to be used when having different inbound vs outbound, then AND may not be commutative, since the order of listing the licenses may convey information about which license is inbound vs outbound, and (maybe) which license applies to different parts of the code.
Which militates to me toward a new expression, but I’ve made that point already.

On Jul 17, 2022, at 11:22 AM, Richard Fontana <rfontana@...> wrote:

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard





b

61 - 80 of 3278