
Till Jaeger
Dear all, Sorry to bring this up again. 1. I suggest to correct the information on https://spdx.org/licenses/Unicode-TOU.htmlThe link provided under "Other web pages for this license" points to a different text ( http://www.unicode.org/copyright.html) than the one at https://spdx.org/licenses/Unicode-TOU.html. It should be stated that the link points to a newer version of the TOU. Follow-up issue: Unicode files refer to http://www.unicode.org/copyright.html,i.e. as the most recent version of the text provided on that site (a kind of dynamic reference). So people may be confused if they take the text from the Unicode TOU instead of the most recent text. Any suggestions on how to deal with this problem? 2. I suggest to correct the information on https://spdx.org/licenses/Unicode-DFS-2016.htmlThe link provided under "Other web pages for this license" points to the TOU instead of the "UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE. It should be stated that a newer version of this agreement is available at https://www.unicode.org/license.txt. I see the problem with dynamic references on websites but SPDX shouldn't incorrect links. Of course, it would be nice to have SPDX identifiers for the most recent versions of the TOU and Unicode-DFS. Best, Till Am 31.10.22 um 12:20 schrieb Till Jaeger via lists.spdx.org:
toggle quoted message
Show quoted text
Dear all,
I'm wondering why https://spdx.org/licenses/Unicode-TOU.html is (still) part of the license list. Could it be deprecated?
1. First of all, the current text of the "Unicode® Copyright and Terms of Use" is quite different from the text which is referenced at https://spdx.org/licenses/Unicode-TOU.html (SPDX License Diff is very helpful to show the differences - thanks again to Alan Tse).
2. Sec. C.3 of the current version refers to the "Unicode Data Files and Software License":
"Further specifications of rights and restrictions pertaining to the use of the Unicode DATA FILES and SOFTWARE can be found in the Unicode Data Files and Software License."
The "Unicode Data Files and Software License" (https://www.unicode.org/license.txt) is similar but not identical to "https://spdx.org/licenses/Unicode-DFS-2016.html".
3. To me it seems that the "Unicode® Copyright and Terms of Use" are more or less ToU for a website and all redistributables are under "Unicode-DFS".
4. Unicode modifies the "year" within the copyright notice from year to year. The "Unicode Data Files and Software License" provides as follows:
"this copyright and permission notice appear with all copies of the Data Files or Software"
Would this require to identify in which year the data and/or software was copied from the Unicode website to use the license text with the correct year? Would it be sufficient to use the most recent version of the license text? Should this be reflected in the SPDX identifier?
Is there anybody with more background information who can give some assistance?
Best regards,
Till
|
|
Whoops -- accidentally just sent this to Till, re-sending to the full list:
= = = = =
Hi Till, please see my thoughts inline below: Dear all,
Sorry to bring this up again.
1.
I suggest to correct the information on
https://spdx.org/licenses/Unicode-TOU.html
The link provided under "Other web pages for this license" points to a
different text (http://www.unicode.org/copyright.html) than the one at
https://spdx.org/licenses/Unicode-TOU.html.
The purpose of the "other URLs" section of each license is _not_ to be a now-current source for that license text, but rather to include URLs which may have been a source for it in the past (as they may be useful for scanning tools, human review, etc. when finding URLs embedded in source code). We don't remove inactive or no-longer-valid URLs because they may remain useful for identification purposes -- see https://github.com/spdx/license-list-XML/blob/main/DOCS/license-fields.md (section C) for one place where this is mentioned.
It should be stated that the link points to a newer version of the TOU.
[SDW] This could perhaps be added to the "Notes" for the Unicode-TOU license, but I'm a little hesitant to do so. For the reasons mentioned above, any of the "other URLs" for any license on the SPDX license list may be incorrect, and I don't think we go through to regularly re-confirm that any of them match the present text.
Follow-up issue: Unicode files refer to
http://www.unicode.org/copyright.html,i.e. as the most recent version of
the text provided on that site (a kind of dynamic reference). So people
may be confused if they take the text from the Unicode TOU instead of
the most recent text. Any suggestions on how to deal with this problem?
2.
I suggest to correct the information on
https://spdx.org/licenses/Unicode-DFS-2016.html
The link provided under "Other web pages for this license" points to the
TOU instead of the "UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND
SOFTWARE.
It should be stated that a newer version of this agreement is available
at https://www.unicode.org/license.txt.
[ SDW] From a quick look, that does appear to be a valid URL containing the text for Unicode-DFS-2016 (though I haven't checked carefully to confirm it's a match). Assuming it is, I agree that https://www.unicode.org/license.txt could be added as an additional "other URL" for it.
I see the problem with dynamic references on websites but SPDX shouldn't
incorrect links. Of course, it would be nice to have SPDX identifiers
for the most recent versions of the TOU and Unicode-DFS.
Best,
Till
Am 31.10.22 um 12:20 schrieb Till Jaeger via lists.spdx.org:
> Dear all,
>
> I'm wondering why https://spdx.org/licenses/Unicode-TOU.html is (still)
> part of the license list. Could it be deprecated?
>
> 1.
> First of all, the current text of the "Unicode® Copyright and Terms of
> Use" is quite different from the text which is referenced at
> https://spdx.org/licenses/Unicode-TOU.html (SPDX License Diff is very
> helpful to show the differences - thanks again to Alan Tse).
>
> 2.
> Sec. C.3 of the current version refers to the "Unicode Data Files and
> Software License":
>
> "Further specifications of rights and restrictions pertaining to the use
> of the Unicode DATA FILES and SOFTWARE can be found in the Unicode Data
> Files and Software License."
>
> The "Unicode Data Files and Software License"
> (https://www.unicode.org/license.txt) is similar but not identical to
> "https://spdx.org/licenses/Unicode-DFS-2016.html".
>
> 3.
> To me it seems that the "Unicode® Copyright and Terms of Use" are more
> or less ToU for a website and all redistributables are under "Unicode-DFS".
>
> 4.
> Unicode modifies the "year" within the copyright notice from year to
> year. The "Unicode Data Files and Software License" provides as follows:
>
> "this copyright and permission notice appear with all copies
> of the Data Files or Software"
>
> Would this require to identify in which year the data and/or software
> was copied from the Unicode website to use the license text with the
> correct year? Would it be sufficient to use the most recent version of
> the license text? Should this be reflected in the SPDX identifier?
>
>
> Is there anybody with more background information who can give some
> assistance?
>
> Best regards,
>
> Till
>
>
>
>
>
>
>
|
|
I wonder if (at least going forward) it makes sense to use an archival URL service like https://perma.cc/ to create a URL that preserves the relevant site at the time the license was added to the database?
On Feb 21, 2023 at 11:55 AM -0800, Steve Winslow <swinslow@...>, wrote:
toggle quoted message
Show quoted text
Whoops -- accidentally just sent this to Till, re-sending to the full list:
= = = = =
Hi Till, please see my thoughts inline below:
Dear all,
Sorry to bring this up again.
1.
I suggest to correct the information on
https://spdx.org/licenses/Unicode-TOU.html
The link provided under "Other web pages for this license" points to a
different text (http://www.unicode.org/copyright.html) than the one at
https://spdx.org/licenses/Unicode-TOU.html.
The purpose of the "other URLs" section of each license is _not_ to be a now-current source for that license text, but rather to include URLs which may have been a source for it in the past (as they may be useful for scanning tools, human review, etc. when finding URLs embedded in source code). We don't remove inactive or no-longer-valid URLs because they may remain useful for identification purposes -- see https://github.com/spdx/license-list-XML/blob/main/DOCS/license-fields.md (section C) for one place where this is mentioned.
It should be stated that the link points to a newer version of the TOU.
[SDW] This could perhaps be added to the "Notes" for the Unicode-TOU license, but I'm a little hesitant to do so. For the reasons mentioned above, any of the "other URLs" for any license on the SPDX license list may be incorrect, and I don't think we go through to regularly re-confirm that any of them match the present text.
Follow-up issue: Unicode files refer to
http://www.unicode.org/copyright.html,i.e. as the most recent version of
the text provided on that site (a kind of dynamic reference). So people
may be confused if they take the text from the Unicode TOU instead of
the most recent text. Any suggestions on how to deal with this problem?
2.
I suggest to correct the information on
https://spdx.org/licenses/Unicode-DFS-2016.html
The link provided under "Other web pages for this license" points to the
TOU instead of the "UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND
SOFTWARE.
It should be stated that a newer version of this agreement is available
at https://www.unicode.org/license.txt.
[ SDW] From a quick look, that does appear to be a valid URL containing the text for Unicode-DFS-2016 (though I haven't checked carefully to confirm it's a match). Assuming it is, I agree that https://www.unicode.org/license.txt could be added as an additional "other URL" for it.
I see the problem with dynamic references on websites but SPDX shouldn't
incorrect links. Of course, it would be nice to have SPDX identifiers
for the most recent versions of the TOU and Unicode-DFS.
Best,
Till
Am 31.10.22 um 12:20 schrieb Till Jaeger via lists.spdx.org:
> Dear all,
>
> I'm wondering why https://spdx.org/licenses/Unicode-TOU.html is (still)
> part of the license list. Could it be deprecated?
>
> 1.
> First of all, the current text of the "Unicode® Copyright and Terms of
> Use" is quite different from the text which is referenced at
> https://spdx.org/licenses/Unicode-TOU.html (SPDX License Diff is very
> helpful to show the differences - thanks again to Alan Tse).
>
> 2.
> Sec. C.3 of the current version refers to the "Unicode Data Files and
> Software License":
>
> "Further specifications of rights and restrictions pertaining to the use
> of the Unicode DATA FILES and SOFTWARE can be found in the Unicode Data
> Files and Software License."
>
> The "Unicode Data Files and Software License"
> (https://www.unicode.org/license.txt) is similar but not identical to
> "https://spdx.org/licenses/Unicode-DFS-2016.html".
>
> 3.
> To me it seems that the "Unicode® Copyright and Terms of Use" are more
> or less ToU for a website and all redistributables are under "Unicode-DFS".
>
> 4.
> Unicode modifies the "year" within the copyright notice from year to
> year. The "Unicode Data Files and Software License" provides as follows:
>
> "this copyright and permission notice appear with all copies
> of the Data Files or Software"
>
> Would this require to identify in which year the data and/or software
> was copied from the Unicode website to use the license text with the
> correct year? Would it be sufficient to use the most recent version of
> the license text? Should this be reflected in the SPDX identifier?
>
>
> Is there anybody with more background information who can give some
> assistance?
>
> Best regards,
>
> Till
>
>
>
>
>
>
>
|
|
Just one additional bit of information on this topic. The JSON format for the License data was upgraded a couple years back to reflect the state of the “other URL”. The implementation isn’t perfect as it relies on less than perfect pattern matching and sometimes firewalls get in the way if URL validation. But if you want to see that information, you can go to https://spdx.org/licenses/[license-id].json where [license-id] is the ID of the license. You’ll find a section “crossRef” which will have the URL plus the additional information including if we find a match to the license in the text. Here’s the output for the Unicode-TOU: "crossRef": [ { "match": "false", "url": "http://www.unicode.org/copyright.html", "isValid": true, "isLive": true, "timestamp": "2023-02-17T20:57:00Z", "isWayBackLink": false, "order": 0 } ], "seeAlso": [ "http://www.unicode.org/copyright.html" ], Best, Gary
toggle quoted message
Show quoted text
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Luis Villa Sent: Tuesday, February 21, 2023 12:26 PM To: jaeger@...; Steve Winslow <swinslow@...> Cc: Spdx-legal@... Subject: Re: Unicode I wonder if (at least going forward) it makes sense to use an archival URL service like https://perma.cc/ to create a URL that preserves the relevant site at the time the license was added to the database? On Feb 21, 2023 at 11:55 AM -0800, Steve Winslow <swinslow@...>, wrote:
Whoops -- accidentally just sent this to Till, re-sending to the full list: Hi Till, please see my thoughts inline below: Dear all,
Sorry to bring this up again.
1. I suggest to correct the information on https://spdx.org/licenses/Unicode-TOU.html
The link provided under "Other web pages for this license" points to a different text (http://www.unicode.org/copyright.html) than the one at https://spdx.org/licenses/Unicode-TOU.html.
The purpose of the "other URLs" section of each license is _not_ to be a now-current source for that license text, but rather to include URLs which may have been a source for it in the past (as they may be useful for scanning tools, human review, etc. when finding URLs embedded in source code). We don't remove inactive or no-longer-valid URLs because they may remain useful for identification purposes -- see https://github.com/spdx/license-list-XML/blob/main/DOCS/license-fields.md (section C) for one place where this is mentioned. It should be stated that the link points to a newer version of the TOU.
[SDW] This could perhaps be added to the "Notes" for the Unicode-TOU license, but I'm a little hesitant to do so. For the reasons mentioned above, any of the "other URLs" for any license on the SPDX license list may be incorrect, and I don't think we go through to regularly re-confirm that any of them match the present text. Follow-up issue: Unicode files refer to http://www.unicode.org/copyright.html,i.e. as the most recent version of the text provided on that site (a kind of dynamic reference). So people may be confused if they take the text from the Unicode TOU instead of the most recent text. Any suggestions on how to deal with this problem?
2. I suggest to correct the information on https://spdx.org/licenses/Unicode-DFS-2016.html
The link provided under "Other web pages for this license" points to the TOU instead of the "UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE.
It should be stated that a newer version of this agreement is available at https://www.unicode.org/license.txt.
[SDW] From a quick look, that does appear to be a valid URL containing the text for Unicode-DFS-2016 (though I haven't checked carefully to confirm it's a match). Assuming it is, I agree that https://www.unicode.org/license.txt could be added as an additional "other URL" for it. I see the problem with dynamic references on websites but SPDX shouldn't incorrect links. Of course, it would be nice to have SPDX identifiers for the most recent versions of the TOU and Unicode-DFS.
Best,
Till
Am 31.10.22 um 12:20 schrieb Till Jaeger via lists.spdx.org: > Dear all, > > I'm wondering why https://spdx.org/licenses/Unicode-TOU.html is (still) > part of the license list. Could it be deprecated? > > 1. > First of all, the current text of the "Unicode® Copyright and Terms of > Use" is quite different from the text which is referenced at > https://spdx.org/licenses/Unicode-TOU.html (SPDX License Diff is very > helpful to show the differences - thanks again to Alan Tse). > > 2. > Sec. C.3 of the current version refers to the "Unicode Data Files and > Software License": > > "Further specifications of rights and restrictions pertaining to the use > of the Unicode DATA FILES and SOFTWARE can be found in the Unicode Data > Files and Software License." > > The "Unicode Data Files and Software License" > (https://www.unicode.org/license.txt) is similar but not identical to > "https://spdx.org/licenses/Unicode-DFS-2016.html". > > 3. > To me it seems that the "Unicode® Copyright and Terms of Use" are more > or less ToU for a website and all redistributables are under "Unicode-DFS". > > 4. > Unicode modifies the "year" within the copyright notice from year to > year. The "Unicode Data Files and Software License" provides as follows: > > "this copyright and permission notice appear with all copies > of the Data Files or Software" > > Would this require to identify in which year the data and/or software > was copied from the Unicode website to use the license text with the > correct year? Would it be sufficient to use the most recent version of > the license text? Should this be reflected in the SPDX identifier? > > > Is there anybody with more background information who can give some > assistance? > > Best regards, > > Till > > > > > > >
|
|

Till Jaeger
Hi Steve,
Thanks for looking into this issue. I have a few additional
remarks below:
Am 21.02.23 um 20:55 schrieb Steve
Winslow:
Whoops -- accidentally just sent this to Till,
re-sending to the full list:
= = = = =
Hi Till, please see my thoughts inline below:
Well, there are several cases in which there is an indication
that an URL does not work anymore (e.g.
https://spdx.org/licenses/OSL-2.1.html).
But I think that a link to a webpage with a _different_ license
text is even worse than a dead link.
It should be stated that the link points to a newer
version of the TOU.
[SDW] This could perhaps be added to the "Notes"
for the Unicode-TOU license, but I'm a little hesitant to
do so. For the reasons mentioned above, any of the "other
URLs" for any license on the SPDX license list may be
incorrect, and I don't think we go through to regularly
re-confirm that any of them match the present text.
I have a feeling that I did not do a good enough job of
explaining the problem.
The situation that we face when doing FOSS license compliance is
the following:
1.
License scanners detect files as the following:
https://www.unicode.org/Public/emoji/15.0/emoji-sequences.txt
2.
The license information is "For terms of use, see
https://www.unicode.org/terms_of_use.html".
3.
Most license scanners conclude "Unicode-TOU".
4.
Many companies have license checklists or internal assessments
based on SPDX identifiers and such internal analysis is based on
the text of https://spdx.org/licenses/Unicode-TOU.html instead of
the current text of https://www.unicode.org/terms_of_use.html.
This increases the risk to work with the wrong license text.
Furthermore, I know many companies creating license documentation
by using template license texts from SPDX instead of the original
license text of the source.
5.
Files such as
https://www.unicode.org/Public/emoji/15.0/emoji-sequences.txt may
have been licensed under the Unicode TOU at some point. But newer
versions of the files at https://www.unicode.org/Public/ will no
longer be licensed under the (deprecated) text at
https://spdx.org/licenses/Unicode-TOU.html in the future, and
incorrect license text may be used.
6.
There is no SPDX identifier for the current version of the
Unicode TOU at http://www.unicode.org/copyright.html, even though
the vast majority of Unicode files reference it. This makes the
job of compliance officers working with SPDX much more difficult.
This is the reason why I think that a new identifier would be
helpful (and/or we should clarify that the text on
https://spdx.org/licenses/Unicode-TOU.html does not match with the
current TOU on https://www.unicode.org/terms_of_use.html).
Follow-up
issue: Unicode files refer to
http://www.unicode.org/copyright.html,i.e.
as the most recent version of
the text provided on that site (a kind of dynamic
reference). So people
may be confused if they take the text from the Unicode TOU
instead of
the most recent text. Any suggestions on how to deal with
this problem?
I agree. Despite this, or perhaps because of it, obsolete URLs
should not be used. As you say yourself:
https://spdx.org/licenses/GPL-2.0-only.html no longer references
https://www.gnu.org/licenses/gpl.html, even though GPL-2.0 was once
available there.
2.
I suggest to correct the information on
https://spdx.org/licenses/Unicode-DFS-2016.html
The link provided under "Other web pages for this license"
points to the
TOU instead of the "UNICODE, INC. LICENSE AGREEMENT - DATA
FILES AND
SOFTWARE.
This is correct. However, the current text at
http://www.unicode.org/copyright.html refers to
https://www.unicode.org/license.txt, which is not Unicode-DFS-2016.
The license text https://www.unicode.org/license.txt has no SPDX
identifier, even though most Unicode files are licensed under this
license.
It should be stated that a newer version of this agreement
is available
at https://www.unicode.org/license.txt.
[ SDW] From a quick look, that does appear to be
a valid URL containing the text for Unicode-DFS-2016
(though I haven't checked carefully to confirm it's a
match). Assuming it is, I agree that https://www.unicode.org/license.txt could be
added as an additional "other URL" for it.
It does not fully match. The first paragraph is different:
Current version:
See Terms of Use <https://www.unicode.org/copyright.html>
for definitions of Unicode Inc.’s Data Files and Software.
Unicode-DFS-2016:
See Terms of Use for definitions of Unicode Inc.'s Data Files and Software.
Unicode Data Files include all data files under the directories
http://www.unicode.org/Public/,
http://www.unicode.org/reports/,
http://www.unicode.org/cldr/data/,
http://source.icu-project.org/repos/icu/,
http://www.unicode.org/ivd/data/, and
http://www.unicode.org/utility/trac/browser/.
Unicode Data Files do not include PDF online code charts under the directory http://www.unicode.org/Public/.
Software includes any source code published in the Unicode
Standard or under the directories
http://www.unicode.org/Public/,
http://www.unicode.org/reports/,
http://www.unicode.org/cldr/data/,
http://source.icu-project.org/repos/icu/, and
http://www.unicode.org/utility/trac/browser/.
Please find attached a comparison.
Do you have a solution in mind?
Best,
Till
I see the problem with dynamic references on websites but
SPDX shouldn't
incorrect links. Of course, it would be nice to have SPDX
identifiers
for the most recent versions of the TOU and Unicode-DFS.
Best,
Till
Am 31.10.22 um 12:20 schrieb Till Jaeger via lists.spdx.org:
> Dear all,
>
> I'm wondering why https://spdx.org/licenses/Unicode-TOU.html
is (still)
> part of the license list. Could it be deprecated?
>
> 1.
> First of all, the current text of the "Unicode®
Copyright and Terms of
> Use" is quite different from the text which is
referenced at
> https://spdx.org/licenses/Unicode-TOU.html
(SPDX License Diff is very
> helpful to show the differences - thanks again to
Alan Tse).
>
> 2.
> Sec. C.3 of the current version refers to the
"Unicode Data Files and
> Software License":
>
> "Further specifications of rights and restrictions
pertaining to the use
> of the Unicode DATA FILES and SOFTWARE can be found
in the Unicode Data
> Files and Software License."
>
> The "Unicode Data Files and Software License"
> (https://www.unicode.org/license.txt)
is similar but not identical to
> "https://spdx.org/licenses/Unicode-DFS-2016.html".
>
> 3.
> To me it seems that the "Unicode® Copyright and Terms
of Use" are more
> or less ToU for a website and all redistributables
are under "Unicode-DFS".
>
> 4.
> Unicode modifies the "year" within the copyright
notice from year to
> year. The "Unicode Data Files and Software License"
provides as follows:
>
> "this copyright and permission notice appear with all
copies
> of the Data Files or Software"
>
> Would this require to identify in which year the data
and/or software
> was copied from the Unicode website to use the
license text with the
> correct year? Would it be sufficient to use the most
recent version of
> the license text? Should this be reflected in the
SPDX identifier?
>
>
> Is there anybody with more background information who
can give some
> assistance?
>
> Best regards,
>
> Till
>
>
>
>
>
>
>
|
|
Hi Till,
For the existing `Unicode-TOU` identifier, we don't change or remove identifiers from the list, so I think that identifier would still remain present no matter what. But there are two changes that could be considered (I've added an issue at https://github.com/spdx/license-list-XML/issues/1852 for community input):
1. whether to change the "Full name" (which shows up in e.g. the left-hand column at https://spdx.org/licenses) to "Unicode Terms of Use - 2014"; and/or 2. whether to deprecate the `Unicode-TOU` identifier altogether, and add a corresponding `Unicode-TOU-2014` with identical content.
I'm in favor of step 1 either way. For step 2, I am on the fence and interested in what others have to say. This would keep `Unicode-TOU` as a valid identifier with the same text, but would mark it as "deprecated" and move it to the bottom part of the list; and would provide `Unicode-TOU-2014` as a versioned alternative for folks to use.
To be clear, in either case this would _not_ result in removing `Unicode-TOU` as a valid identifier. Even if it's deprecated, it would still be present on the License List, as we do not remove existing identifiers. But deprecating it and adding a new `Unicode-TOU-2014` alternative might help alleviate the issues you're seeing.
Also, I would _not_ be in favor of removing https://www.unicode.org/copyright.html from the "other URLs" list for either identifier. Even if it does not point to the corresponding text today, if someone is using content from 2014 under the old license text, then relying solely on that URL as embodied in the content would also lead to a wrong conclusion if only the current version had the URL associated with it. Any sort of dependence on listed URLs to be accurate for license detection is going to fail in particular cases, and as a policy matter I believe we've taken the position that "other URLs" will not be modified based on evolving content. ( Jilayne or others who may have historical knowledge here, please feel free to jump in if I'm off-base!)
Finally, for the Unicode Data Files and Software license, from the comparison you shared it looks like the only differences between https://www.unicode.org/license.txt and Unicode-DFS-2016 might be in omitable (blue) or replaceable (red) text. With the exception being the inclusion of the URL after "See Terms of Use" at the very beginning. I would be more inclined to add that URL as additional "omitable" text for Unicode-DFS-2016, rather than create a separate license identifier for it. But I've added an issue at https://github.com/spdx/license-list-XML/issues/1853 for folks to weigh in on this one as well.
Best, Steve
toggle quoted message
Show quoted text
On Tue, Feb 21, 2023 at 7:27 PM Till Jaeger < jaeger@...> wrote:
Hi Steve,
Thanks for looking into this issue. I have a few additional
remarks below:
Am 21.02.23 um 20:55 schrieb Steve
Winslow:
Whoops -- accidentally just sent this to Till,
re-sending to the full list:
= = = = =
Hi Till, please see my thoughts inline below:
Well, there are several cases in which there is an indication
that an URL does not work anymore (e.g.
https://spdx.org/licenses/OSL-2.1.html).
But I think that a link to a webpage with a _different_ license
text is even worse than a dead link.
It should be stated that the link points to a newer
version of the TOU.
[SDW] This could perhaps be added to the "Notes"
for the Unicode-TOU license, but I'm a little hesitant to
do so. For the reasons mentioned above, any of the "other
URLs" for any license on the SPDX license list may be
incorrect, and I don't think we go through to regularly
re-confirm that any of them match the present text.
I have a feeling that I did not do a good enough job of
explaining the problem.
The situation that we face when doing FOSS license compliance is
the following:
1.
License scanners detect files as the following:
https://www.unicode.org/Public/emoji/15.0/emoji-sequences.txt
2.
The license information is "For terms of use, see
https://www.unicode.org/terms_of_use.html".
3.
Most license scanners conclude "Unicode-TOU".
4.
Many companies have license checklists or internal assessments
based on SPDX identifiers and such internal analysis is based on
the text of https://spdx.org/licenses/Unicode-TOU.html instead of
the current text of https://www.unicode.org/terms_of_use.html.
This increases the risk to work with the wrong license text.
Furthermore, I know many companies creating license documentation
by using template license texts from SPDX instead of the original
license text of the source.
5.
Files such as
https://www.unicode.org/Public/emoji/15.0/emoji-sequences.txt may
have been licensed under the Unicode TOU at some point. But newer
versions of the files at https://www.unicode.org/Public/ will no
longer be licensed under the (deprecated) text at
https://spdx.org/licenses/Unicode-TOU.html in the future, and
incorrect license text may be used.
6.
There is no SPDX identifier for the current version of the
Unicode TOU at http://www.unicode.org/copyright.html, even though
the vast majority of Unicode files reference it. This makes the
job of compliance officers working with SPDX much more difficult.
This is the reason why I think that a new identifier would be
helpful (and/or we should clarify that the text on
https://spdx.org/licenses/Unicode-TOU.html does not match with the
current TOU on https://www.unicode.org/terms_of_use.html).
Follow-up
issue: Unicode files refer to
http://www.unicode.org/copyright.html,i.e.
as the most recent version of
the text provided on that site (a kind of dynamic
reference). So people
may be confused if they take the text from the Unicode TOU
instead of
the most recent text. Any suggestions on how to deal with
this problem?
I agree. Despite this, or perhaps because of it, obsolete URLs
should not be used. As you say yourself:
https://spdx.org/licenses/GPL-2.0-only.html no longer references
https://www.gnu.org/licenses/gpl.html, even though GPL-2.0 was once
available there.
2.
I suggest to correct the information on
https://spdx.org/licenses/Unicode-DFS-2016.html
The link provided under "Other web pages for this license"
points to the
TOU instead of the "UNICODE, INC. LICENSE AGREEMENT - DATA
FILES AND
SOFTWARE.
This is correct. However, the current text at
http://www.unicode.org/copyright.html refers to
https://www.unicode.org/license.txt, which is not Unicode-DFS-2016.
The license text https://www.unicode.org/license.txt has no SPDX
identifier, even though most Unicode files are licensed under this
license.
It should be stated that a newer version of this agreement
is available
at https://www.unicode.org/license.txt.
[ SDW] From a quick look, that does appear to be
a valid URL containing the text for Unicode-DFS-2016
(though I haven't checked carefully to confirm it's a
match). Assuming it is, I agree that https://www.unicode.org/license.txt could be
added as an additional "other URL" for it.
It does not fully match. The first paragraph is different:
Current version:
See Terms of Use <https://www.unicode.org/copyright.html>
for definitions of Unicode Inc.’s Data Files and Software.
Unicode-DFS-2016:
See Terms of Use for definitions of Unicode Inc.'s Data Files and Software.
Unicode Data Files include all data files under the directories
http://www.unicode.org/Public/,
http://www.unicode.org/reports/,
http://www.unicode.org/cldr/data/,
http://source.icu-project.org/repos/icu/,
http://www.unicode.org/ivd/data/, and
http://www.unicode.org/utility/trac/browser/.
Unicode Data Files do not include PDF online code charts under the directory http://www.unicode.org/Public/.
Software includes any source code published in the Unicode
Standard or under the directories
http://www.unicode.org/Public/,
http://www.unicode.org/reports/,
http://www.unicode.org/cldr/data/,
http://source.icu-project.org/repos/icu/, and
http://www.unicode.org/utility/trac/browser/.
Please find attached a comparison.
Do you have a solution in mind?
Best,
Till
I see the problem with dynamic references on websites but
SPDX shouldn't
incorrect links. Of course, it would be nice to have SPDX
identifiers
for the most recent versions of the TOU and Unicode-DFS.
Best,
Till
Am 31.10.22 um 12:20 schrieb Till Jaeger via lists.spdx.org:
> Dear all,
>
> I'm wondering why https://spdx.org/licenses/Unicode-TOU.html
is (still)
> part of the license list. Could it be deprecated?
>
> 1.
> First of all, the current text of the "Unicode®
Copyright and Terms of
> Use" is quite different from the text which is
referenced at
> https://spdx.org/licenses/Unicode-TOU.html
(SPDX License Diff is very
> helpful to show the differences - thanks again to
Alan Tse).
>
> 2.
> Sec. C.3 of the current version refers to the
"Unicode Data Files and
> Software License":
>
> "Further specifications of rights and restrictions
pertaining to the use
> of the Unicode DATA FILES and SOFTWARE can be found
in the Unicode Data
> Files and Software License."
>
> The "Unicode Data Files and Software License"
> (https://www.unicode.org/license.txt)
is similar but not identical to
> "https://spdx.org/licenses/Unicode-DFS-2016.html".
>
> 3.
> To me it seems that the "Unicode® Copyright and Terms
of Use" are more
> or less ToU for a website and all redistributables
are under "Unicode-DFS".
>
> 4.
> Unicode modifies the "year" within the copyright
notice from year to
> year. The "Unicode Data Files and Software License"
provides as follows:
>
> "this copyright and permission notice appear with all
copies
> of the Data Files or Software"
>
> Would this require to identify in which year the data
and/or software
> was copied from the Unicode website to use the
license text with the
> correct year? Would it be sufficient to use the most
recent version of
> the license text? Should this be reflected in the
SPDX identifier?
>
>
> Is there anybody with more background information who
can give some
> assistance?
>
> Best regards,
>
> Till
>
>
>
>
>
>
>
|
|