chore(license): updates to LICENSE, README.md, CONTRIBUTING.md #3875
Conversation
srl295
commented
Aug 15, 2023
srl295
commented
- Drop SPDX for now - change license to license-file in Cargo.toml https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields (the SPDX identifier will come back soon!)
- Central tracking: updated Unicode LICENSE, README.md, CONTRIBUTING.md .github#6
- followon to chore(license): update license to Unicode-DFS-2016 #2303
srl295
requested review from
a team,
Manishearth,
sffc,
robertbastian,
zbraniecki,
gregtatum,
gnrunge,
filmil,
pdogr,
hsivonen,
snktd,
eggrobin,
nordzilla,
aethanyc,
makotokato,
echeran,
dminor and
nciric
as code owners
- Drop SPDX for now - change license to license-file in Cargo.toml https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields (the SPDX identifier will come back soon!) - Central tracking: unicode-org/.github#6 - followon to #2303
srl295
force-pushed
the
srl295/licensev3
branch
from
aa74210 to
9f7081a
Compare
I would say do not wait for it. Even if we had it in 2 weeks, i'm probably not going to do another run through everything in the next month. |
Co-authored-by: Shane F. Carr <[email protected]>
Ah, sure; we can do that ourselves if needed. Partly my question is from the POV of internal compliance: the next time we update ICU4X within Google we'll need to get this license approved and it's easier if there's an SPDX. But if that's not going to be ready in time, would I be okay in getting preliminary internal approval for https://www.unicode.org/license.txt and say the SPDX is coming? Is there a preliminary SPDX I can get them to use internally? |
|
I don't know how long it takes for SPDX to assign an identifier to a new license. Our outside counsel on this is on vacation this week, but will be submitting the new license to SPDX (and OSI) next week. I have to think it will take at least a couple weeks after that. Once outside counsel is back from vacation, I'll ask him again, but I don't have an answer right now. |
you could have them compare it to Unicode-DFS-2016 perhaps? |
|
Who does the approving within Google - is it Dashiell?
Also, I think we need to change the name of the license to "Unicode License
v3" - that is the name we are using in our applications to SPDX and OSI.
Plus, it's way shorter and easier than "Unicode, Inc. License Agreement -
Data Files & Software. I know you have already started populating repos
with the license under the old name, but if it's not too big a deal to swap
it out now, that could be best.
…On Thu, Aug 17, 2023 at 1:53 PM Steven R. Loomis ***@***.***> wrote:
I would say do not wait for it. Even if we had it in 2 weeks, i'm probably
not going to do another run through everything in the next month.
Ah, sure; we can do that ourselves if needed.
Partly my question is from the POV of internal compliance: the next time
we update ICU4X within Google we'll need to get this license approved and
it's easier if there's an SPDX. But if that's not going to be ready in
time, would I be okay in getting preliminary internal approval for
https://www.unicode.org/license.txt and say the SPDX is coming? Is there
a preliminary SPDX I can get them to use internally?
you could have them *compare* it to Unicode-DFS-2016 perhaps?
—
Reply to this email directly, view it on GitHub
<#3875 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2S6UI5JZ64WXDBFZMA6XO3XV2AERANCNFSM6AAAAAA3RW3X5A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I think in part, I plan to email the open source licensing group in a while. Most of the tooling around this uses SPDX but I suppose we could figure out something temporarily to use internally.
The tricky thing is not the review, the tricky thing is once the review has completed the documentation and tooling needs to be updated to say that something is approved and it's nice when that thing has a name. But like I said we can make something up. |
|
Basically landing a LICENSE file without an SPDX triggers a compliance workflow (Dashiell might be CC'd but it's mainly driven by people on the tech side), and since we land ICU4X as a bunch of individual crates we'll probably need to spin this up for each one of them. It's all doable, just more paperwork and red tape than if we landed this with an SPDX. |
I don't think this is true fwiw, as long as the internal tooling is aware of the license. |
|
However, it is true that updating the license (regardless of SPDX) is going to make the import process much more painful. But that's inevitable; I think there are workarounds I can come up with. |
|
I checked further with counsel and he says it takes about a month give or
take to get the SPDX identifier. Do you want to delay the new license for
ICU4X until we have it. I'd prefer not to delay it across all repos, but we
could hold off on ICU4X if it really helps.
…On Thu, Aug 17, 2023 at 2:09 PM Manish Goregaokar ***@***.***> wrote:
However, it *is* true that updating the license (regardless of SPDX) is
going to make the import process much more painful.
—
Reply to this email directly, view it on GitHub
<#3875 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2S6UIZPTSE6LEQHKYT2JG3XV2B75ANCNFSM6AAAAAA3RW3X5A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
No, it's fine, we can merge this, just wanted an idea. |
|
minor update, license title name change |
That's not what I'm seeing… You might be seeing the diffs (comparisons), but if you click the "…" menu and choose "View File" you will see what the updated file looks like. Otherwise lines starting with a 
|
|
I understand how to View File and I did. I was just in the wrong "chore". So, approved now. |
