Allowing "regular" Apache/MIT dual in utils/

[Manishearth]

This cropped up when I was thinking about importing https://github.com/zbraniecki/tinystr into utils since it is in an awkward position where it uses zerovec but is also used in icu4x so breaking zerovec changes can make it hard to update.

utils/ contains crates that we feel will be generally useful beyond just ICU4X. Currently, they follow the "ICU4X license", which is essentially "Apache/MIT but with some appropriately marked data/code under the ICU or Unicode license".

However, it is extremely unlikely for many of the utilities to ever need such code. Given that the Rust ecosystem has a standard license, what do people think about moving at least zerovec/yoke/litemap/writeable, and perhaps some other utilities, over to a "regular" Apache/MIT license? Of course with modifications to our CI and tooling to support that, perhaps as an allowlist of crates to start. I suspect this will reduce friction in using these crates, and it seems worth it to not overcomplicate licenses where possible.

Needs approval from:

• @sffc
• @zbraniecki
• (feel free to add yourself if you care)

[Manishearth]

In particular I'd like to be able to import tinystr without having to muck with licenses too much

[zbraniecki]

Approve!

[sffc]

What is the advantage to making this change? You said this:

I suspect this will reduce friction in using these crates, and it seems worth it to not overcomplicate licenses where possible.

1. Can you elaborate on what "friction" you foresee?
2. Right now the whole repo has a single license. Any changes to that, like an allowlist, seem more complicated, not less.

[zbraniecki]

I think it's a similar situation as with build systems. Adding a new one increases internal complexity but reduces integration friction.

[sffc]

integration friction

Can you provide clarity on what you mean by "integration friction" here?

I thought we chose the current licensing scheme specifically to reduce friction relative to the Unicode license alone.

[zbraniecki]

See top comment from Manish. Importing code to ICU4x has a friction because ICU4x set of libraries have non standard licensing set

[Manishearth]

Also, importing ICU4X elsewhere has similar friction since tooling does not recognize the license.

We've had trouble with that within Google itself already, and Google helped write this license!

I'm not advocating for changing the license everywhere, of course, just on some of the utils: if someone wishes to use icu4x and they are picky about licenses it's reasonable for them to need to spend some time on a big dependency. But it becomes less reasonable for folks who wish to use standalone utils like zerovec/yoke/litemap and we want more people using those (eventually).

Bear in mind, these utilities already are under the regular rust license by virtue of not having any ICU/Unicode code, the question is really just about enshrining that in the code comments and license files.

[sffc]

I don't see a compelling reason to optimize the experience of importing code into ICU4X, because it's rare that we do that and when we do it's a team member who does it.

As far as clients trying to use ICU4X, I agree that's something to optimize for. @Manishearth says "tooling does not recognize the license". I'd like to know:

1. What is the tooling that doesn't recognize the license?
2. Can we fix that tooling?
3. If not, what can we do to make the ICU4X license more friendly for that tooling?

Ideally we can make all ICU4X crates equally easy to consume. If and only if that is not possible, then I think we can study the implications of having mixed licenses in the monorepo.

[Manishearth]

What is the tooling that doesn't recognize the license?

It's not any single tool (and not just a tooling problem); it's often bespoke CI scripts as well as bespoke policies. In Google's case*, there are various license allowlists that need legal approval to add to. Rustc has another such allowlist and you need to get higher approval for modifying that allowlist in any way. In general, it's additional friction: a developer choosing to add a dependency can no longer add it with the usual level of friction, they need to get approval, and perhaps get access to a lawyer (which is not easy for a lot of devs in open source).

This can also propagate to crate authors who typically have no inherent license-based-friction where their users pressure them to drop a dependency because they have license based friction. I've seen this happen with other crates that have bespoke licenses.

* n.b. what I've proposed here would not have fixed the problem we had with Google systems because we were importing the entire repo; but it would help if e.g. Fuchsia wanted to use yoke (which they've been somewhat interested in)

Can we fix that tooling?

No, because it isn't any single tool, and also is often policy complexity.

If not, what can we do to make the ICU4X license more friendly for that tooling?

If we stopped using the bespoke ICU4X license entirely and picked a preestablished one (like Apache/MIT). I don't think this option is on the table.

Though given that we have a relatively small amount of actual code that's based off of Unicode/ICU License stuff, I do wonder if it makes sense to keep the root-level "mixed" LICENSE the same but by default have crate licenses be Apache/MIT with them falling back to the broader license when they either statically pull in data or depend on Unicode License stuff. Again, this is already what the license says, it's just that we default to the "mixed" ICU4X license on the crates instead of being more specific.

This would make using most of ICU4X more friendly for that tooling, aside from the few crates that actually need the "mixed" license.

I am not proposing this here, though, just thinking about it, this might need a broader check-in with the lawyers.

Ideally we can make all ICU4X crates equally easy to consume

Ultimately I see the potential user base for a lot of our utilities to be much broader than internationalization users (though ICU4X is for all i18n users, whereas the utility crates will likely only be desired by Rustaceans).

Also, I fundamentally do not consider many of the the utility crates to be "ICU4X crates" as much as they are "really useful crates primarily developed by the ICU4X project that are more general purpose and exist in the monorepo for convenience". Once they're well documented and more stable I intend to talk about some of them more and hopefully get more users/contributions, and there may even be a point where it's more convenient to develop them as their own repo (that point is no time soon, though).

[sffc]

Thanks for that documentation.

I am continuing the discussion in the following forum: https://github.com/orgs/unicode-org/teams/icu4x-sc/discussions/2

[sffc]

Action: Schedule meeting to discuss.

[sffc]

@Manishearth to send more follow-ups. Stick with the status quo for 1.0.

[ijackson]

Hi. I came to this issue because our licence auditing (which we run in CI) detected an anomalous situation with the licence of the tinystr crate. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1791#note_2972532

I am continuing the discussion in the following forum: https://github.com/orgs/unicode-org/teams/icu4x-sc/discussions/2

Unfortunately that link is 404 for me.

[Manishearth]

@ijackson yes, that is the internal team/legal discussion for the license, it should not be public.

As mentioned in the README:

The project is released under LICENSE, the free and open-source Unicode License, which is based on the well-known MIT license, with the primary difference being that the Unicode License expressly covers data and data files, as well as code. For further information please see The Unicode Consortium Intellectual Property, Licensing, and Technical Contribution Policies.

The changes from Unicode-DFS-2016 are slight and most other clients are treating it as a variant of that license. Apologies for the liminal state.

---

In general yes, this discussion has stalled. I do think we have had sufficient examples of friction caused by the strange license, but at this point of discussion I don't see the status quo changing any time soon. I'm closing this issue, if I end up restarting that discussion I could reopen it.

[ijackson]

The changes from Unicode-DFS-2016 are slight and most other clients are treating it as a variant of that license.

Of course "slight" textual changes can sometimes have very significant effects. I have for example experienced myself a situation where changing "during" to "in" made the critical difference between forbidding and allowing me to do some important work.

So "slight" changes which don't serve a real legal purpose generate a lot of needless clerical work and should ideally be avoided. This is the licence proliferation which organisations like OSI rightly argue against.

And, another consequence, it is important that when the same licence is intended exactly the same text is used everywhere. And that the same name always refers to exactly the same text. That doesn't always appear to be the case. For example, the text in tinystr/LICENCE is not the same as the text at https://opensource.org/license/unicode-license-v3/ but they both claim to be "UNICODE LICENSE V3".

The FLOSS world nowadays has very widely adopted SPDX as a way of unambiguously naming and declaring licences. One of its key benefits is that no-one needs to do word-by-word textual review of prose. So it is important that the SPDX identifier proposal is pursued vigorously, but also carefully: after all, the text named by the proposed SPDX identifier must be nailed down and then used everywhere consistently.

[Manishearth]

Yes, I understand the issues here. I have made similar points myself in the past. I highlighted the "slight" because I know that multiple clients are treating it as a variant, which may be useful information for you. I was not trying to argue the impact is minimal.

Like, I get this situation is frustrating. I was not in favor of it. But it it what it is now, I'm giving you a read of the situation as it is, I do not think it is something that would be changed from discussing here.

[Manishearth]

it is important that when the same licence is intended exactly the same text is used everywhere. And that the same name always refers to exactly the same text.

(I'm also looking into this; I suspect this is a consequence of "stuff is still in flux" but we'll see)